https://wiki.bitcoinsv.io/api.php?action=feedcontributions&feedformat=atom&user=AlexGrahamBitcoin Wiki - User contributions [en]2026-05-12T20:50:58ZUser contributionsMediaWiki 1.33.0https://wiki.bitcoinsv.io/index.php?title=Getminingcandidate&diff=2419Getminingcandidate2020-04-14T09:17:14Z<p>AlexGraham: </p>
<hr />
<div>''getminingcandidate'' and ''getblocktemplate'' are Remote Procedure Call (RPC) programs. The RPC calls are located at an SV node and are currently managed and configured through Maestro software, though a number of software packages may perform these tasks.<br />
<br />
A node can make a request with either of the above calls for block information:<br />
* The ''getblocktemplate'' returns a full block.<br />
* The ''getminingcandidate'' program returns the block header.<br />
The returned data is the block candidate data for mining. It is expressed in the JSON language for data processing.<br />
<br />
''getminingcandidate'' returns a mining candidate block to the node which originally requested it. The node requests a block to mine. ''getminingcandidate'' is the program that obtains a block header to mine.<br />
<br />
The ''getminingcandidate'' program or call is a replacement for ''getblocktemplate'' program. <br />
The replacement requirement arose from the need to process bigger blocks with Merkle tree paths in the block header. The Merkle tree proof in the block header allows for confirmation of transactions rather than reading the transactions as a whole. Consequently there can be more transactions within a block and more efficient external processing of the block.<br />
<br />
===Block header parameters for getminingcandidate===<br />
<table><br />
<tr><td>Parameter</td> <td>Description</td></tr><br />
<tr><td>Id</td> <td>Candidate identifier for submitminingsolution</td></tr><br />
<tr><td>Prevhash</td> <td>Hash of the previous block (hex string)</td></tr><br />
<tr><td>Coinbase</td> <td>Coinbase transaction (optional hex string encoded binary transaction)</td></tr><br />
<tr><td>Version</td> <td>Block version</td></tr><br />
<tr><td>nBits</td><br />
<td>Difficulty given as hex string.</td></tr><br />
<tr><td>Time</td> <td>Block time.</td></tr><br />
<tr><td>Height</td> <td>Current block height</td></tr><br />
<tr><td>merkleProof</td> <td>Merkle branch of the block (list of hex strings)</td></tr><br />
</table><br />
<br />
===Example Block Header in the json format===<br />
{<br />
"id": "0d49aa74-0986-474f-a6eb-5913fbbbba02",<br />
"prevhash": "0000000000000000012811f570b3c0ff8cb93c44d707499dc2fcfdd611f38d93",<br />
"coinbaseValue": 1251906370,<br />
"version": 536870912,<br />
"nBits": "1802c73f",<br />
"time": 1585156824,<br />
"height": 627795,<br />
"merkleProof": [<br />
"f4cba40673d5573ca1aab2ee8fbd300102767561190cad7aa6211e04223ff6c3",<br />
"2d69511004ba72b60a10e6482491d689470b9f8527aff0f550c197d8a2446c45",<br />
"6eb9f4ef18f9669db60b21dc52292eba5318d684f7c476bb12da03b6d97d7c4f",<br />
"7a69a2fb7b132b36496501357d923ce584f913b37879a1930a10682d284bc2a9",<br />
"976089f04a73862fac14d2eec8b3f23aef9167f9804c40ade23c4f385cd92928",<br />
"73ec68c1692643e7edd22a34729f4bc8529fed48eca8ac0cd6e8b2929fb44064",<br />
"ee59af2b7964c1c0f48cd06b4e4e77c783711746030cc20d46a339f3d9993709",<br />
"6c0a33f1a1778ebec5d63172c55edb433ae365dbf7cd37bfa3535c864e9b9ea7",<br />
"d59744d6f3548adda90444a44eb16c56022554fdd4a0448632acd36058c96599",<br />
"6bd2d6dcdea8dd04345b7b706ba125ed73394be899355cb7b355d258eea20ff5",<br />
"3842aadab31a0e3bb5c484d58262f052afbe7f684935bf4d19ed614521e750e5",<br />
"91dec854c6f222b9be0cc78bd34b2405e98f34c6d2c7db8f84db6d85a83eb51e",<br />
"2b07dc2afdcafa3719c4ef440ef5c5f0c332efa174d23bbb72749680b36575a7"<br />
]<br />
}<br />
<br />
The Maestro software handles the call to and from the SV node to the ASIC miner. The ASIC miner then performs the hashing process to discover the next suitable block to be placed on the blockchain.<br />
<br />
===UML Sequence Diagram for getminingcandidate===<br />
<br />
<br />
<br />
<br />
<br />
[[File:getmining_rpc_6.png|600px|centre|alt=UML Sequence Diagram for getminingcandidate]]</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=File:Getmining_rpc_6.png&diff=2418File:Getmining rpc 6.png2020-04-14T09:16:45Z<p>AlexGraham: updated UML diagram for block template and block header exchange between sv node, maestro and ASIC miner.</p>
<hr />
<div>== Summary ==<br />
updated UML diagram for block template and block header exchange between sv node, maestro and ASIC miner.</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Getminingcandidate&diff=2417Getminingcandidate2020-04-09T13:51:19Z<p>AlexGraham: </p>
<hr />
<div>''getminingcandidate'' and ''getblocktemplate'' are Remote Procedure Call (RPC) programs. The RPC calls are located at an SV node and are currently managed and configured through Maestro software, though a number of software packages may perform these tasks.<br />
<br />
A node can make a request with either of the above calls for block information:<br />
* The ''getblocktemplate'' returns a full block.<br />
* The ''getminingcandidate'' program returns the block header.<br />
The returned data is the block candidate data for mining. It is expressed in the JSON language for data processing.<br />
<br />
''getminingcandidate'' returns a mining candidate block to the node which originally requested it. The node requests a block to mine. ''getminingcandidate'' is the program that obtains a block header to mine.<br />
<br />
The ''getminingcandidate'' program or call is a replacement for ''getblocktemplate'' program. <br />
The replacement requirement arose from the need to process bigger blocks with Merkle tree paths in the block header. The Merkle tree proof in the block header allows for confirmation of transactions rather than reading the transactions as a whole. Consequently there can be more transactions within a block and more efficient external processing of the block.<br />
<br />
===Block header parameters for getminingcandidate===<br />
<table><br />
<tr><td>Parameter</td> <td>Description</td></tr><br />
<tr><td>Id</td> <td>Candidate identifier for submitminingsolution</td></tr><br />
<tr><td>Prevhash</td> <td>Hash of the previous block (hex string)</td></tr><br />
<tr><td>Coinbase</td> <td>Coinbase transaction (optional hex string encoded binary transaction)</td></tr><br />
<tr><td>Version</td> <td>Block version</td></tr><br />
<tr><td>nBits</td><br />
<td>Difficulty given as hex string.</td></tr><br />
<tr><td>Time</td> <td>Block time.</td></tr><br />
<tr><td>Height</td> <td>Current block height</td></tr><br />
<tr><td>merkleProof</td> <td>Merkle branch of the block (list of hex strings)</td></tr><br />
</table><br />
<br />
===Example Block Header in the json format===<br />
{<br />
"id": "0d49aa74-0986-474f-a6eb-5913fbbbba02",<br />
"prevhash": "0000000000000000012811f570b3c0ff8cb93c44d707499dc2fcfdd611f38d93",<br />
"coinbaseValue": 1251906370,<br />
"version": 536870912,<br />
"nBits": "1802c73f",<br />
"time": 1585156824,<br />
"height": 627795,<br />
"merkleProof": [<br />
"f4cba40673d5573ca1aab2ee8fbd300102767561190cad7aa6211e04223ff6c3",<br />
"2d69511004ba72b60a10e6482491d689470b9f8527aff0f550c197d8a2446c45",<br />
"6eb9f4ef18f9669db60b21dc52292eba5318d684f7c476bb12da03b6d97d7c4f",<br />
"7a69a2fb7b132b36496501357d923ce584f913b37879a1930a10682d284bc2a9",<br />
"976089f04a73862fac14d2eec8b3f23aef9167f9804c40ade23c4f385cd92928",<br />
"73ec68c1692643e7edd22a34729f4bc8529fed48eca8ac0cd6e8b2929fb44064",<br />
"ee59af2b7964c1c0f48cd06b4e4e77c783711746030cc20d46a339f3d9993709",<br />
"6c0a33f1a1778ebec5d63172c55edb433ae365dbf7cd37bfa3535c864e9b9ea7",<br />
"d59744d6f3548adda90444a44eb16c56022554fdd4a0448632acd36058c96599",<br />
"6bd2d6dcdea8dd04345b7b706ba125ed73394be899355cb7b355d258eea20ff5",<br />
"3842aadab31a0e3bb5c484d58262f052afbe7f684935bf4d19ed614521e750e5",<br />
"91dec854c6f222b9be0cc78bd34b2405e98f34c6d2c7db8f84db6d85a83eb51e",<br />
"2b07dc2afdcafa3719c4ef440ef5c5f0c332efa174d23bbb72749680b36575a7"<br />
]<br />
}<br />
<br />
The Maestro software handles the call to and from the SV node to the ASIC miner. The ASIC miner then performs the hashing process to discover the next suitable block to be placed on the blockchain.<br />
<br />
===UML Sequence Diagram for getminingcandidate===<br />
<br />
<br />
<br />
<br />
<br />
[[File:getmining_rpc_5.png|600px|centre|alt=UML Sequence Diagram for getminingcandidate]]</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Getminingcandidate&diff=2416Getminingcandidate2020-04-09T13:49:23Z<p>AlexGraham: </p>
<hr />
<div>''getminingcandidate'' and ''getblocktemplate'' are Remote Procedure Call (RPC) programs. The RPC calls are located at an SV node and are currently managed and configured through Maestro software, though a number of software packages may perform these tasks.<br />
<br />
A node can make a request with either of the above calls for block information:<br />
* The ''getblocktemplate'' returns a full block.<br />
* The ''getminingcandidate'' program returns the block header.<br />
The returned data is the block candidate data for mining. It is expressed in the JSON language for data processing.<br />
<br />
''getminingcandidate'' returns a mining candidate block to the node which originally requested it. The node requests a block to mine. ''getminingcandidate'' is the program that obtains a block header to mine.<br />
<br />
The ''getminingcandidate'' program or call is a replacement for ''getblocktemplate'' program. <br />
The replacement requirement arose from the need to process bigger blocks with Merkle tree paths in the block header. The Merkle tree proof in the block header allows for confirmation of transactions rather than reading the transactions as a whole. Consequently there can be more transactions within a block and more efficient external processing of the block.<br />
<br />
===Block header parameters for getminingcandidate===<br />
<table><br />
<tr><td>Parameter</td> <td>Description</td></tr><br />
<tr><td>Id</td> <td>Candidate identifier for submitminingsolution</td></tr><br />
<tr><td>Prevhash</td> <td>Hash of the previous block (hex string)</td></tr><br />
<tr><td>Coinbase</td> <td>Coinbase transaction (optional hex string encoded binary transaction)</td></tr><br />
<tr><td>Version</td> <td>Block version</td></tr><br />
<tr><td>nBits</td><br />
<td>Difficulty given as hex string.</td></tr><br />
<tr><td>Time</td> <td>Block time.</td></tr><br />
<tr><td>Height</td> <td>Current block height</td></tr><br />
<tr><td>merkleProof</td> <td>Merkle branch of the block (list of hex strings)</td></tr><br />
</table><br />
<br />
===Example Block Header in the json format===<br />
{<br />
"id": "0d49aa74-0986-474f-a6eb-5913fbbbba02",<br />
"prevhash": "0000000000000000012811f570b3c0ff8cb93c44d707499dc2fcfdd611f38d93",<br />
"coinbaseValue": 1251906370,<br />
"version": 536870912,<br />
"nBits": "1802c73f",<br />
"time": 1585156824,<br />
"height": 627795,<br />
"merkleProof": [<br />
"f4cba40673d5573ca1aab2ee8fbd300102767561190cad7aa6211e04223ff6c3",<br />
"2d69511004ba72b60a10e6482491d689470b9f8527aff0f550c197d8a2446c45",<br />
"6eb9f4ef18f9669db60b21dc52292eba5318d684f7c476bb12da03b6d97d7c4f",<br />
"7a69a2fb7b132b36496501357d923ce584f913b37879a1930a10682d284bc2a9",<br />
"976089f04a73862fac14d2eec8b3f23aef9167f9804c40ade23c4f385cd92928",<br />
"73ec68c1692643e7edd22a34729f4bc8529fed48eca8ac0cd6e8b2929fb44064",<br />
"ee59af2b7964c1c0f48cd06b4e4e77c783711746030cc20d46a339f3d9993709",<br />
"6c0a33f1a1778ebec5d63172c55edb433ae365dbf7cd37bfa3535c864e9b9ea7",<br />
"d59744d6f3548adda90444a44eb16c56022554fdd4a0448632acd36058c96599",<br />
"6bd2d6dcdea8dd04345b7b706ba125ed73394be899355cb7b355d258eea20ff5",<br />
"3842aadab31a0e3bb5c484d58262f052afbe7f684935bf4d19ed614521e750e5",<br />
"91dec854c6f222b9be0cc78bd34b2405e98f34c6d2c7db8f84db6d85a83eb51e",<br />
"2b07dc2afdcafa3719c4ef440ef5c5f0c332efa174d23bbb72749680b36575a7"<br />
]<br />
}<br />
<br />
The Maestro software handles the call to and from the SV node to the ASIC miner. The ASIC miner then performs the hashing process to discover the next suitable block to be placed on the blockchain.<br />
<br />
[[File:getmining_rpc_5.png|600px|centre|alt=UML Sequence Diagram for getminingcandidate]]</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=File:Getmining_rpc_5.png&diff=2415File:Getmining rpc 5.png2020-04-09T13:46:56Z<p>AlexGraham: UML Sequence diagram for getminingcandidate</p>
<hr />
<div>== Summary ==<br />
UML Sequence diagram for getminingcandidate</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2414Complex Script Options2020-04-07T15:47:14Z<p>AlexGraham: </p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and 'customized' (previously known as‘Non-Standard’) scripts for transaction inputs and outputs.<br />
<br />
The 'customized' scripts allow for complex scripts to be added to transactions containing additional functionality for the locking and redeeming process.<br />
<br />
==Standard scripts==<br />
<br />
There are 5 standard scripts for Bitcoin SV (Referred to in WP1321)<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with the Genesis upgrade after Feb 4th 2020)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
These scripts have been available as locking and redeeming scripts in Bitcoin.<br />
<br />
==Benefits of Customised scripts==<br />
<br />
===Upgrade to Bitcoin SV Node===<br />
<br />
(Extracted from WP1321:)<br />
<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
<br />
(other comments)<br />
<br />
The use of non standard scripts allows flexibility in the outputs potentially providing conditionality, enhanced security and computational possibilities.<br />
These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities activity.<br />
<br />
The use of customised scripts should lead to the extension of BSV services. Customizing of scripts should provide tailored services for wallets, subnets and overlays in BSV network.<br />
<br />
===Customised Scripts under development===<br />
<br />
Currently, there are three customized scripts under development as defined in WP1321.<br />
* R Puzzle - use of the r component of a digital signature<br />
* Rabin Signature - use of Rabin addresses and signatures (see Rabin Signatures)<br />
* Multi Signature Accumulator - manage multi signature scenarios through conditional scripting instuctions.<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established through a Miner ID.<br />
<br />
==Other Customised declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
The creation of payment addresses as the transaction output within a script that is non-standard or customised (See WP1322).</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2413Complex Script Options2020-04-07T15:46:04Z<p>AlexGraham: /* Other 'customised' declarations can include: */</p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and 'customized' (previously known as‘Non-Standard’) scripts for transaction inputs and outputs.<br />
<br />
The 'customized' scripts allow for complex scripts to be added to transactions containing additional functionality for the locking and redeeming process.<br />
<br />
==Standard scripts==<br />
<br />
There are 5 standard scripts for Bitcoin SV (Referred to in WP1321)<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with the Genesis upgrade after Feb 4th 2020)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
These scripts have been available as locking and redeeming scripts in Bitcoin.<br />
<br />
==Benefits of Customised scripts==<br />
<br />
===Upgrade to Bitcoin SV Node===<br />
<br />
(Extracted from WP1321:)<br />
<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
<br />
(other comments)<br />
<br />
The use of non standard scripts allows flexibility in the outputs potentially providing conditionality, enhanced security and computational possibilities.<br />
These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities activity.<br />
<br />
The use of customised scripts should lead to the extension of BSV services. Customizing of scripts should provide tailored services for wallets, subnets and overlays in BSV network.<br />
<br />
===Customised Scripts under development===<br />
<br />
Currently, there are three customized scripts under development as defined in WP1321.<br />
* R Puzzle - use of the r component of a digital signature<br />
* Rabin Signature - use of Rabin addresses and signatures (see Rabin Signatures)<br />
* Multi Signature Accumulator - manage multi signature scenarios<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established through a Miner ID.<br />
<br />
==Other Customised declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
The creation of payment addresses as the transaction output within a script that is non-standard or customised (See WP1322).</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2412Complex Script Options2020-04-07T15:45:07Z<p>AlexGraham: </p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and 'customized' (previously known as‘Non-Standard’) scripts for transaction inputs and outputs.<br />
<br />
The 'customized' scripts allow for complex scripts to be added to transactions containing additional functionality for the locking and redeeming process.<br />
<br />
==Standard scripts==<br />
<br />
There are 5 standard scripts for Bitcoin SV (Referred to in WP1321)<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with the Genesis upgrade after Feb 4th 2020)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
These scripts have been available as locking and redeeming scripts in Bitcoin.<br />
<br />
==Benefits of Customised scripts==<br />
<br />
===Upgrade to Bitcoin SV Node===<br />
<br />
(Extracted from WP1321:)<br />
<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
<br />
(other comments)<br />
<br />
The use of non standard scripts allows flexibility in the outputs potentially providing conditionality, enhanced security and computational possibilities.<br />
These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities activity.<br />
<br />
The use of customised scripts should lead to the extension of BSV services. Customizing of scripts should provide tailored services for wallets, subnets and overlays in BSV network.<br />
<br />
===Customised Scripts under development===<br />
<br />
Currently, there are three customized scripts under development as defined in WP1321.<br />
* R Puzzle - use of the r component of a digital signature<br />
* Rabin Signature - use of Rabin addresses and signatures (see Rabin Signatures)<br />
* Multi Signature Accumulator - manage multi signature scenarios<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established through a Miner ID.<br />
<br />
==Other 'customised' declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
The creation of payment addresses as the transaction output within a script that is non-standard or customised (See WP1322).</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2411Complex Script Options2020-04-07T15:44:30Z<p>AlexGraham: </p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and 'customized' (previously known as‘Non-Standard’) scripts for transaction inputs and outputs.<br />
<br />
The 'customized' scripts allow for complex scripts to be added to transactions containing complex functionality for the locking and redeeming process.<br />
<br />
==Standard scripts==<br />
<br />
There are 5 standard scripts for Bitcoin SV (Referred to in WP1321)<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with the Genesis upgrade after Feb 4th 2020)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
These scripts have been available as locking and redeeming scripts in Bitcoin.<br />
<br />
==Benefits of Customised scripts==<br />
<br />
===Upgrade to Bitcoin SV Node===<br />
<br />
(Extracted from WP1321:)<br />
<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
<br />
(other comments)<br />
<br />
The use of non standard scripts allows flexibility in the outputs potentially providing conditionality, enhanced security and computational possibilities.<br />
These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities activity.<br />
<br />
The use of customised scripts should lead to the extension of BSV services. Customizing of scripts should provide tailored services for wallets, subnets and overlays in BSV network.<br />
<br />
===Customised Scripts under development===<br />
<br />
Currently, there are three customized scripts under development as defined in WP1321.<br />
* R Puzzle - use of the r component of a digital signature<br />
* Rabin Signature - use of Rabin addresses and signatures (see Rabin Signatures)<br />
* Multi Signature Accumulator - manage multi signature scenarios<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established through a Miner ID.<br />
<br />
==Other 'customised' declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
The creation of payment addresses as the transaction output within a script that is non-standard or customised (See WP1322).</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2410Complex Script Options2020-04-07T15:38:38Z<p>AlexGraham: /* Benefits of 'Customised' scripts */</p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and 'customized' (previously known as‘Non-Standard’) scripts for transaction inputs and outputs.<br />
<br />
==Standard scripts==<br />
<br />
There are 5 standard scripts for Bitcoin SV (Referred to in WP1321)<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with the Genesis upgrade after Feb 4th 2020)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
These scripts have been available as locking and redeeming scripts in Bitcoin.<br />
<br />
==Benefits of Customised scripts==<br />
<br />
===Upgrade to Bitcoin SV Node===<br />
<br />
(Extracted from WP1321:)<br />
<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
<br />
(other comments)<br />
<br />
The use of non standard scripts allows flexibility in the outputs potentially providing conditionality, enhanced security and computational possibilities.<br />
These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities activity.<br />
<br />
The use of customised scripts should lead to the extension of BSV services. Customizing of scripts should provide tailored services for wallets, subnets and overlays in BSV network.<br />
<br />
===Customised Scripts under development===<br />
<br />
Currently, there are three customized scripts under development as defined in WP1321.<br />
* R Puzzle - use of the r component of a digital signature<br />
* Rabin Signature - use of Rabin addresses and signatures (see Rabin Signatures)<br />
* Multi Signature Accumulator - manage multi signature scenarios<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established through a Miner ID.<br />
<br />
==Other 'customised' declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
The creation of payment addresses as the transaction output within a script that is non-standard or customised (See WP1322).</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2409Complex Script Options2020-04-07T15:38:19Z<p>AlexGraham: /* ‘Standard’ scripts */</p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and 'customized' (previously known as‘Non-Standard’) scripts for transaction inputs and outputs.<br />
<br />
==Standard scripts==<br />
<br />
There are 5 standard scripts for Bitcoin SV (Referred to in WP1321)<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with the Genesis upgrade after Feb 4th 2020)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
These scripts have been available as locking and redeeming scripts in Bitcoin.<br />
<br />
==Benefits of 'Customised' scripts==<br />
<br />
===Upgrade to Bitcoin SV Node===<br />
<br />
(Extracted from WP1321:)<br />
<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
<br />
(other comments)<br />
<br />
The use of non standard scripts allows flexibility in the outputs potentially providing conditionality, enhanced security and computational possibilities.<br />
These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities activity.<br />
<br />
The use of customised scripts should lead to the extension of BSV services. Customizing of scripts should provide tailored services for wallets, subnets and overlays in BSV network.<br />
<br />
===Customised Scripts under development===<br />
<br />
Currently, there are three customized scripts under development as defined in WP1321.<br />
* R Puzzle - use of the r component of a digital signature<br />
* Rabin Signature - use of Rabin addresses and signatures (see Rabin Signatures)<br />
* Multi Signature Accumulator - manage multi signature scenarios<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established through a Miner ID.<br />
<br />
==Other 'customised' declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
The creation of payment addresses as the transaction output within a script that is non-standard or customised (See WP1322).</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2408Complex Script Options2020-04-07T15:36:58Z<p>AlexGraham: /* Benefits of 'Customised' scripts (known as Non-standard) */</p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and 'customized' (previously known as‘Non-Standard’) scripts for transaction inputs and outputs.<br />
<br />
==‘Standard’ scripts==<br />
<br />
There are 5 standard scripts for Bitcoin SV (Referred to in WP1321)<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with the Genesis upgrade after Feb 4th 2020)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
These scripts have been available as locking and redeeming scripts in Bitcoin.<br />
<br />
==Benefits of 'Customised' scripts==<br />
<br />
===Upgrade to Bitcoin SV Node===<br />
<br />
(Extracted from WP1321:)<br />
<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
<br />
(other comments)<br />
<br />
The use of non standard scripts allows flexibility in the outputs potentially providing conditionality, enhanced security and computational possibilities.<br />
These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities activity.<br />
<br />
The use of customised scripts should lead to the extension of BSV services. Customizing of scripts should provide tailored services for wallets, subnets and overlays in BSV network.<br />
<br />
===Customised Scripts under development===<br />
<br />
Currently, there are three customized scripts under development as defined in WP1321.<br />
* R Puzzle - use of the r component of a digital signature<br />
* Rabin Signature - use of Rabin addresses and signatures (see Rabin Signatures)<br />
* Multi Signature Accumulator - manage multi signature scenarios<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established through a Miner ID.<br />
<br />
==Other 'customised' declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
The creation of payment addresses as the transaction output within a script that is non-standard or customised (See WP1322).</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2407Complex Script Options2020-04-07T15:36:14Z<p>AlexGraham: /* ‘Standard’ scripts */</p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and 'customized' (previously known as‘Non-Standard’) scripts for transaction inputs and outputs.<br />
<br />
==‘Standard’ scripts==<br />
<br />
There are 5 standard scripts for Bitcoin SV (Referred to in WP1321)<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with the Genesis upgrade after Feb 4th 2020)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
These scripts have been available as locking and redeeming scripts in Bitcoin.<br />
<br />
==Benefits of 'Customised' scripts (known as Non-standard)==<br />
<br />
===Upgrade to Bitcoin SV Node===<br />
<br />
(Extracted from WP1321:)<br />
<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
<br />
(other comments)<br />
<br />
The use of non standard scripts allows flexibility in the outputs potentially providing conditionality, enhanced security and computational possibilities.<br />
These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities activity.<br />
<br />
The use of customised scripts should lead to the extension of BSV services. Customizing of scripts should provide tailored services for wallets, subnets and overlays in BSV network.<br />
<br />
===Customised Scripts under development===<br />
<br />
Currently, there are three customized scripts under development as defined in WP1321.<br />
* R Puzzle - use of the r component of a digital signature<br />
* Rabin Signature - use of Rabin addresses and signatures (see Rabin Signatures)<br />
* Multi Signature Accumulator - manage multi signature scenarios<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established through a Miner ID.<br />
<br />
==Other 'customised' declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
The creation of payment addresses as the transaction output within a script that is non-standard or customised (See WP1322).</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2406Complex Script Options2020-04-07T15:35:46Z<p>AlexGraham: /* Customised Scripts under development */</p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and 'customized' (previously known as‘Non-Standard’) scripts for transaction inputs and outputs.<br />
<br />
==‘Standard’ scripts==<br />
<br />
There are 5 standard scripts for Bitcoin SV (Referred to in WP1321)<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with Genesis after Feb 4th 2020)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
These scripts have been available as locking and redeeming scripts in Bitcoin.<br />
<br />
==Benefits of 'Customised' scripts (known as Non-standard)==<br />
<br />
===Upgrade to Bitcoin SV Node===<br />
<br />
(Extracted from WP1321:)<br />
<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
<br />
(other comments)<br />
<br />
The use of non standard scripts allows flexibility in the outputs potentially providing conditionality, enhanced security and computational possibilities.<br />
These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities activity.<br />
<br />
The use of customised scripts should lead to the extension of BSV services. Customizing of scripts should provide tailored services for wallets, subnets and overlays in BSV network.<br />
<br />
===Customised Scripts under development===<br />
<br />
Currently, there are three customized scripts under development as defined in WP1321.<br />
* R Puzzle - use of the r component of a digital signature<br />
* Rabin Signature - use of Rabin addresses and signatures (see Rabin Signatures)<br />
* Multi Signature Accumulator - manage multi signature scenarios<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established through a Miner ID.<br />
<br />
==Other 'customised' declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
The creation of payment addresses as the transaction output within a script that is non-standard or customised (See WP1322).</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2405Complex Script Options2020-04-07T15:35:22Z<p>AlexGraham: /* Customised Scripts under development */</p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and 'customized' (previously known as‘Non-Standard’) scripts for transaction inputs and outputs.<br />
<br />
==‘Standard’ scripts==<br />
<br />
There are 5 standard scripts for Bitcoin SV (Referred to in WP1321)<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with Genesis after Feb 4th 2020)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
These scripts have been available as locking and redeeming scripts in Bitcoin.<br />
<br />
==Benefits of 'Customised' scripts (known as Non-standard)==<br />
<br />
===Upgrade to Bitcoin SV Node===<br />
<br />
(Extracted from WP1321:)<br />
<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
<br />
(other comments)<br />
<br />
The use of non standard scripts allows flexibility in the outputs potentially providing conditionality, enhanced security and computational possibilities.<br />
These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities activity.<br />
<br />
The use of customised scripts should lead to the extension of BSV services. Customizing of scripts should provide tailored services for wallets, subnets and overlays in BSV network.<br />
<br />
===Customised Scripts under development===<br />
<br />
Currently, there are some customized scripts under development as defined in WP1321.<br />
* R Puzzle - use of the r component of a digital signature<br />
* Rabin Signature - use of Rabin addresses and signatures (see Rabin Signatures)<br />
* Multi Signature Accumulator - manage multi signature scenarios<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established through a Miner ID.<br />
<br />
==Other 'customised' declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
The creation of payment addresses as the transaction output within a script that is non-standard or customised (See WP1322).</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2404Complex Script Options2020-04-07T15:35:04Z<p>AlexGraham: /* Other 'customised' (non-standard) declarations can include: */</p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and 'customized' (previously known as‘Non-Standard’) scripts for transaction inputs and outputs.<br />
<br />
==‘Standard’ scripts==<br />
<br />
There are 5 standard scripts for Bitcoin SV (Referred to in WP1321)<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with Genesis after Feb 4th 2020)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
These scripts have been available as locking and redeeming scripts in Bitcoin.<br />
<br />
==Benefits of 'Customised' scripts (known as Non-standard)==<br />
<br />
===Upgrade to Bitcoin SV Node===<br />
<br />
(Extracted from WP1321:)<br />
<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
<br />
(other comments)<br />
<br />
The use of non standard scripts allows flexibility in the outputs potentially providing conditionality, enhanced security and computational possibilities.<br />
These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities activity.<br />
<br />
The use of customised scripts should lead to the extension of BSV services. Customizing of scripts should provide tailored services for wallets, subnets and overlays in BSV network.<br />
<br />
===Customised Scripts under development===<br />
<br />
Currently, there are some customized scripts under development as defined in WP1321.<br />
* R Puzzle - use of the r component of a signature<br />
* Rabin Signature - use of Rabin addresses and signatures (see Rabin Signatures)<br />
* Multi Signature Accumulator - manage multi signature scenarios<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established through a Miner ID.<br />
<br />
==Other 'customised' declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
The creation of payment addresses as the transaction output within a script that is non-standard or customised (See WP1322).</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2403Complex Script Options2020-04-03T13:04:49Z<p>AlexGraham: /* Defining ‘Standard’ */</p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and 'customized' (previously known as‘Non-Standard’) scripts for transaction inputs and outputs.<br />
<br />
==‘Standard’ scripts==<br />
<br />
There are 5 standard scripts for Bitcoin SV (Referred to in WP1321)<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with Genesis after Feb 4th 2020)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
These scripts have been available as locking and redeeming scripts in Bitcoin.<br />
<br />
==Benefits of 'Customised' scripts (known as Non-standard)==<br />
<br />
===Upgrade to Bitcoin SV Node===<br />
<br />
(Extracted from WP1321:)<br />
<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
<br />
(other comments)<br />
<br />
The use of non standard scripts allows flexibility in the outputs potentially providing conditionality, enhanced security and computational possibilities.<br />
These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities activity.<br />
<br />
The use of customised scripts should lead to the extension of BSV services. Customizing of scripts should provide tailored services for wallets, subnets and overlays in BSV network.<br />
<br />
===Customised Scripts under development===<br />
<br />
Currently, there are some customized scripts under development as defined in WP1321.<br />
* R Puzzle - use of the r component of a signature<br />
* Rabin Signature - use of Rabin addresses and signatures (see Rabin Signatures)<br />
* Multi Signature Accumulator - manage multi signature scenarios<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established through a Miner ID.<br />
<br />
==Other 'customised' (non-standard) declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
The creation of payment addresses as the transaction output within a script that is non-standard or customised (See WP1322).</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2402Complex Script Options2020-04-03T13:02:29Z<p>AlexGraham: </p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and 'customized' (previously known as‘Non-Standard’) scripts for transaction inputs and outputs.<br />
<br />
==Defining ‘Standard’==<br />
<br />
There are 5 standard scripts for Bitcoin SV (Referred to in WP1321)<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with Genesis after Feb 4th 2020)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
These scripts have been available as locking and redeeming scripts in Bitcoin.<br />
<br />
==Benefits of 'Customised' scripts (known as Non-standard)==<br />
<br />
===Upgrade to Bitcoin SV Node===<br />
<br />
(Extracted from WP1321:)<br />
<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
<br />
(other comments)<br />
<br />
The use of non standard scripts allows flexibility in the outputs potentially providing conditionality, enhanced security and computational possibilities.<br />
These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities activity.<br />
<br />
The use of customised scripts should lead to the extension of BSV services. Customizing of scripts should provide tailored services for wallets, subnets and overlays in BSV network.<br />
<br />
===Customised Scripts under development===<br />
<br />
Currently, there are some customized scripts under development as defined in WP1321.<br />
* R Puzzle - use of the r component of a signature<br />
* Rabin Signature - use of Rabin addresses and signatures (see Rabin Signatures)<br />
* Multi Signature Accumulator - manage multi signature scenarios<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established through a Miner ID.<br />
<br />
==Other 'customised' (non-standard) declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
The creation of payment addresses as the transaction output within a script that is non-standard or customised (See WP1322).</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2401Complex Script Options2020-04-03T12:59:24Z<p>AlexGraham: /* Other non-standard declarations can include: */</p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and 'customized' (previously known as‘Non Standard’) scripts for transaction inputs and outputs.<br />
<br />
==Defining ‘Standard’==<br />
<br />
There are 5 standard scripts for Bitcoin SV (Referred to in WP1321)<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with Genesis after Feb 4th 2020)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
These scripts have been available as locking and redeeming scripts in Bitcoin.<br />
<br />
==Benefits of 'Customised' scripts (known as Non-standard)==<br />
<br />
===Upgrade to Bitcoin SV Node===<br />
<br />
(Extracted from WP1321:)<br />
<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
<br />
(other comments)<br />
<br />
The use of non standard scripts allows flexibility in the outputs potentially providing conditionality, enhanced security and computational possibilities.<br />
These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities activity.<br />
<br />
The use of customised scripts should lead to the extension of BSV services. Customizing of scripts should provide tailored services for wallets, subnets and overlays in BSV network.<br />
<br />
===Customised Scripts under development===<br />
<br />
Currently, there are some customized scripts under development as defined in WP1321.<br />
* R Puzzle - use of the r component of a signature<br />
* Rabin Signature - use of Rabin addresses and signatures (see Rabin Signatures)<br />
* Multi Signature Accumulator - manage multi signature scenarios<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established through a Miner ID.<br />
<br />
==Other 'customised' (non-standard) declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
The creation of payment addresses as the transaction output within a script that is non-standard or customised (See WP1322).</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2400Complex Script Options2020-04-03T12:58:47Z<p>AlexGraham: /* Upgrade to Bitcoin SV Node */</p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and 'customized' (previously known as‘Non Standard’) scripts for transaction inputs and outputs.<br />
<br />
==Defining ‘Standard’==<br />
<br />
There are 5 standard scripts for Bitcoin SV (Referred to in WP1321)<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with Genesis after Feb 4th 2020)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
These scripts have been available as locking and redeeming scripts in Bitcoin.<br />
<br />
==Benefits of 'Customised' scripts (known as Non-standard)==<br />
<br />
===Upgrade to Bitcoin SV Node===<br />
<br />
(Extracted from WP1321:)<br />
<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
<br />
(other comments)<br />
<br />
The use of non standard scripts allows flexibility in the outputs potentially providing conditionality, enhanced security and computational possibilities.<br />
These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities activity.<br />
<br />
The use of customised scripts should lead to the extension of BSV services. Customizing of scripts should provide tailored services for wallets, subnets and overlays in BSV network.<br />
<br />
===Customised Scripts under development===<br />
<br />
Currently, there are some customized scripts under development as defined in WP1321.<br />
* R Puzzle - use of the r component of a signature<br />
* Rabin Signature - use of Rabin addresses and signatures (see Rabin Signatures)<br />
* Multi Signature Accumulator - manage multi signature scenarios<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established through a Miner ID.<br />
<br />
==Other non-standard declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
The creation of payment addresses as the transaction output within a script that is non-standard or customised (See WP1322).</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2399Complex Script Options2020-04-03T12:58:21Z<p>AlexGraham: /* Defining ‘Non-standard’ */</p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and 'customized' (previously known as‘Non Standard’) scripts for transaction inputs and outputs.<br />
<br />
==Defining ‘Standard’==<br />
<br />
There are 5 standard scripts for Bitcoin SV (Referred to in WP1321)<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with Genesis after Feb 4th 2020)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
These scripts have been available as locking and redeeming scripts in Bitcoin.<br />
<br />
==Benefits of 'Customised' scripts (known as Non-standard)==<br />
<br />
===Upgrade to Bitcoin SV Node===<br />
<br />
(Extracted from WP1321:)<br />
<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
===Customised Scripts under development===<br />
<br />
Currently, there are some customized scripts under development as defined in WP1321.<br />
* R Puzzle - use of the r component of a signature<br />
* Rabin Signature - use of Rabin addresses and signatures (see Rabin Signatures)<br />
* Multi Signature Accumulator - manage multi signature scenarios<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established through a Miner ID.<br />
<br />
==Other non-standard declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
The creation of payment addresses as the transaction output within a script that is non-standard or customised (See WP1322).</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2398Complex Script Options2020-04-03T12:57:23Z<p>AlexGraham: </p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and 'customized' (previously known as‘Non Standard’) scripts for transaction inputs and outputs.<br />
<br />
==Defining ‘Standard’==<br />
<br />
There are 5 standard scripts for Bitcoin SV (Referred to in WP1321)<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with Genesis after Feb 4th 2020)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
These scripts have been available as locking and redeeming scripts in Bitcoin.<br />
<br />
==Benefits of 'Customised' scripts (known as Non-standard)==<br />
<br />
===Upgrade to Bitcoin SV Node===<br />
<br />
(Extracted from WP1321:)<br />
<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
==Defining ‘Non-standard’==<br />
<br />
The use of non standard scripts allows flexibility in the outputs potentially providing conditionality, enhanced security and computational possibilities.<br />
These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities activity.<br />
<br />
The use of customised scripts should lead to the extension of BSV services. Customizing of scripts should provide tailored services for wallets, subnets and overlays in BSV network.<br />
<br />
===Customised Scripts under development===<br />
<br />
Currently, there are some customized scripts under development as defined in WP1321.<br />
* R Puzzle - use of the r component of a signature<br />
* Rabin Signature - use of Rabin addressses and signatures (see Rabin Signatures)<br />
* Multi Signature Accumulator - manage multi signature scenarios<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established through a Miner ID.<br />
<br />
==Other non-standard declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
The creation of payment addresses as the transaction output within a script that is non-standard or customised (See WP1322).</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2397Complex Script Options2020-04-03T12:47:54Z<p>AlexGraham: /* Defining ‘Non-standard’ */</p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and ‘Non Standard’ or ‘customized’ scripts for transaction inputs and outputs.<br />
<br />
==Defining ‘Standard’==<br />
<br />
There are 5 standard scripts for Bitcoin SV (Referred to in WP1321)<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with Genesis after Feb 4th 2020)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
These scripts have been available as locking and redeeming scripts in Bitcoin.<br />
<br />
==Benefits of Non-standard - Why do we need non-standard scripts?==<br />
<br />
===Upgrade to Bitcoin SV Node===<br />
<br />
(Extracted from WP1321:)<br />
<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
==Defining ‘Non-standard’==<br />
<br />
The use of non standard scripts allows flexibility in the outputs potentially providing conditionality, enhanced security and computational possibilities.<br />
These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities activity.<br />
<br />
The use of customised scripts should lead to the extension of BSV services. Customizing of scripts should provide tailored services for wallets, subnets and overlays in BSV network.<br />
<br />
===Customised Scripts under development===<br />
<br />
Currently, there are some customized scripts under development as defined in WP1321.<br />
* R Puzzle - use of the r component of a signature<br />
* Rabin Signature - use of Rabin addressses and signatures (see Rabin Signatures)<br />
* Multi Signature Accumulator - manage multi signature scenarios<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established through a Miner ID.<br />
<br />
==Other non-standard declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
The creation of payment addresses as the transaction output within a script that is non-standard or customised (See WP1322).</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2396Complex Script Options2020-04-02T16:28:17Z<p>AlexGraham: /* Defining ‘Non-standard’ */</p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and ‘Non Standard’ or ‘customized’ scripts for transaction inputs and outputs.<br />
<br />
==Defining ‘Standard’==<br />
<br />
There are 5 standard scripts for Bitcoin SV (Referred to in WP1321)<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with Genesis after Feb 4th 2020)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
These scripts have been available as locking and redeeming scripts in Bitcoin.<br />
<br />
==Benefits of Non-standard - Why do we need non-standard scripts?==<br />
<br />
===Upgrade to Bitcoin SV Node===<br />
<br />
(Extracted from WP1321:)<br />
<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
==Defining ‘Non-standard’==<br />
<br />
The use of non standard scripts allows flexibility in the outputs potentially providing conditionality, enhanced security and computational possibilities.<br />
These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities activity.<br />
<br />
The use of customised scripts should lead to the extension of BSV services. Customizing of scripts should provide tailored services for wallets, subnets and overlays in BSV network.<br />
<br />
Currently, there are some customized scripts under development as defined in WP1321.<br />
* R Puzzle - use of the r component of a signature<br />
* Rabin Signature - use of Rabin addressses and signatures (see Rabin Signatures)<br />
* Multi Signature Accumulator - manage multi signature scenarios<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established through a Miner ID.<br />
<br />
==Other non-standard declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
The creation of payment addresses as the transaction output within a script that is non-standard or customised (See WP1322).</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2395Complex Script Options2020-04-02T14:58:10Z<p>AlexGraham: </p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and ‘Non Standard’ or ‘customized’ scripts for transaction inputs and outputs.<br />
<br />
==Defining ‘Standard’==<br />
<br />
There are 5 standard scripts for Bitcoin SV (Referred to in WP1321)<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with Genesis after Feb 4th 2020)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
These scripts have been available as locking and redeeming scripts in Bitcoin.<br />
<br />
==Benefits of Non-standard - Why do we need non-standard scripts?==<br />
<br />
===Upgrade to Bitcoin SV Node===<br />
<br />
(Extracted from WP1321:)<br />
<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
==Defining ‘Non-standard’==<br />
<br />
The use of non standard scripts allows flexibility in the outputs potentially providing conditionality, enhanced security and computational possibilities.<br />
These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities activity.<br />
<br />
The use of customised scripts should lead to the extension of BSV services. Customizing of scripts should provide tailored services for wallets, subnets and overlays in BSV network.<br />
<br />
Currently, there are some customized scripts under development as defined in WP1321.<br />
* R Puzzle - use of the r component of a signature<br />
* Rabin Signature - use of Rabin addressses and signatures (see Rabin Signatutes)<br />
* Multi Signature Accumulator - manage multi signature scenarios<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established through a Miner ID.<br />
<br />
==Other non-standard declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
The creation of payment addresses as the transaction output within a script that is non-standard or customised (See WP1322).</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2394Complex Script Options2020-04-02T14:57:15Z<p>AlexGraham: /* Defining ‘Non-standard’ */</p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and ‘Non Standard’ or ‘customized’ scripts for transaction inputs and outputs.<br />
<br />
==Defining ‘Standard’==<br />
<br />
There are 5 standard scripts for Bitcoin SV (Referred to in WP1321)<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with Genesis after Feb 4th 2020)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
These scripts have been available as locking and redeeming scripts in Bitcoin.<br />
<br />
==Benefits of Non-standard - Why do we need non-standard scripts?==<br />
<br />
===Upgrade to Bitcoin SV Node===<br />
<br />
(Extracted from WP1321:)<br />
<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
==Defining ‘Non-standard’==<br />
<br />
The use of non standard scripts allows flexibility in the outputs potentially providing conditionality, enhanced security and computational possibilities.<br />
These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities activity.<br />
<br />
The use of customised scripts should lead to the extension of BSV services. Customizing of scripts should provide tailored services for wallets and subnets in BSV network.<br />
<br />
Currently, there are some customized scripts under development as defined in WP1321.<br />
* R Puzzle - use of the r component of a signature<br />
* Rabin Signature - use of Rabin addressses and signatures (see Rabin Signatutes)<br />
* Multi Signature Accumulator - manage multi signature scenarios<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established through a Miner ID.<br />
<br />
==Other non-standard declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
The creation of payment addresses as the transaction output within a script that is non-standard or customised (See WP1322).</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Getminingcandidate&diff=2393Getminingcandidate2020-04-02T13:56:26Z<p>AlexGraham: </p>
<hr />
<div>''getminingcandidate'' and ''getblocktemplate'' are Remote Procedure Call (RPC) programs. The RPC calls are located at an SV node and are currently managed and configured through Maestro software, though a number of software packages may perform these tasks.<br />
<br />
A node can make a request with either of the above calls for block information:<br />
* The ''getblocktemplate'' returns a full block.<br />
* The ''getminingcandidate'' program returns the block header.<br />
The returned data is the block candidate data for mining. It is expressed in the JSON language for data processing.<br />
<br />
''getminingcandidate'' returns a mining candidate block to the node which originally requested it. The node requests a block to mine. ''getminingcandidate'' is the program that obtains a block header to mine.<br />
<br />
The ''getminingcandidate'' program or call is a replacement for ''getblocktemplate'' program. <br />
The replacement requirement arose from the need to process bigger blocks with Merkle tree paths in the block header. The Merkle tree proof in the block header allows for confirmation of transactions rather than reading the transactions as a whole. Consequently there can be more transactions within a block and more efficient external processing of the block.<br />
<br />
===Block header parameters for getminingcandidate===<br />
<table><br />
<tr><td>Parameter</td> <td>Description</td></tr><br />
<tr><td>Id</td> <td>Candidate identifier for submitminingsolution</td></tr><br />
<tr><td>Prevhash</td> <td>Hash of the previous block (hex string)</td></tr><br />
<tr><td>Coinbase</td> <td>Coinbase transaction (optional hex string encoded binary transaction)</td></tr><br />
<tr><td>Version</td> <td>Block version</td></tr><br />
<tr><td>nBits</td><br />
<td>Difficulty given as hex string.</td></tr><br />
<tr><td>Time</td> <td>Block time.</td></tr><br />
<tr><td>Height</td> <td>Current block height</td></tr><br />
<tr><td>merkleProof</td> <td>Merkle branch of the block (list of hex strings)</td></tr><br />
</table><br />
<br />
===Example Block Header in the json format===<br />
{<br />
"id": "0d49aa74-0986-474f-a6eb-5913fbbbba02",<br />
"prevhash": "0000000000000000012811f570b3c0ff8cb93c44d707499dc2fcfdd611f38d93",<br />
"coinbaseValue": 1251906370,<br />
"version": 536870912,<br />
"nBits": "1802c73f",<br />
"time": 1585156824,<br />
"height": 627795,<br />
"merkleProof": [<br />
"f4cba40673d5573ca1aab2ee8fbd300102767561190cad7aa6211e04223ff6c3",<br />
"2d69511004ba72b60a10e6482491d689470b9f8527aff0f550c197d8a2446c45",<br />
"6eb9f4ef18f9669db60b21dc52292eba5318d684f7c476bb12da03b6d97d7c4f",<br />
"7a69a2fb7b132b36496501357d923ce584f913b37879a1930a10682d284bc2a9",<br />
"976089f04a73862fac14d2eec8b3f23aef9167f9804c40ade23c4f385cd92928",<br />
"73ec68c1692643e7edd22a34729f4bc8529fed48eca8ac0cd6e8b2929fb44064",<br />
"ee59af2b7964c1c0f48cd06b4e4e77c783711746030cc20d46a339f3d9993709",<br />
"6c0a33f1a1778ebec5d63172c55edb433ae365dbf7cd37bfa3535c864e9b9ea7",<br />
"d59744d6f3548adda90444a44eb16c56022554fdd4a0448632acd36058c96599",<br />
"6bd2d6dcdea8dd04345b7b706ba125ed73394be899355cb7b355d258eea20ff5",<br />
"3842aadab31a0e3bb5c484d58262f052afbe7f684935bf4d19ed614521e750e5",<br />
"91dec854c6f222b9be0cc78bd34b2405e98f34c6d2c7db8f84db6d85a83eb51e",<br />
"2b07dc2afdcafa3719c4ef440ef5c5f0c332efa174d23bbb72749680b36575a7"<br />
]<br />
}<br />
<br />
The Maestro software handles the call to and from the SV node to the ASIC miner. The ASIC miner then performs the hashing process to discover the next suitable block to be placed on the blockchain.</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Getminingcandidate&diff=2392Getminingcandidate2020-04-02T13:55:57Z<p>AlexGraham: </p>
<hr />
<div>''getminingcandidate'' and ''getblocktemplate'' are Remote Procedure Call (RPC) programs. The RPC calls are located at an SV node and are currently managed and configured through Maestro software, though a number of software packages may perform these tasks.<br />
<br />
The miner can make a request with either of the above calls for block information:<br />
* The ''getblocktemplate'' returns a full block.<br />
* The ''getminingcandidate'' program returns the block header.<br />
The returned data is the block candidate data for mining. It is expressed in the JSON language for data processing.<br />
<br />
''getminingcandidate'' returns a mining candidate block to the node which originally requested it. The node requests a block to mine. ''getminingcandidate'' is the program that obtains a block header to mine.<br />
<br />
The ''getminingcandidate'' program or call is a replacement for ''getblocktemplate'' program. <br />
The replacement requirement arose from the need to process bigger blocks with Merkle tree paths in the block header. The Merkle tree proof in the block header allows for confirmation of transactions rather than reading the transactions as a whole. Consequently there can be more transactions within a block and more efficient external processing of the block.<br />
<br />
===Block header parameters for getminingcandidate===<br />
<table><br />
<tr><td>Parameter</td> <td>Description</td></tr><br />
<tr><td>Id</td> <td>Candidate identifier for submitminingsolution</td></tr><br />
<tr><td>Prevhash</td> <td>Hash of the previous block (hex string)</td></tr><br />
<tr><td>Coinbase</td> <td>Coinbase transaction (optional hex string encoded binary transaction)</td></tr><br />
<tr><td>Version</td> <td>Block version</td></tr><br />
<tr><td>nBits</td><br />
<td>Difficulty given as hex string.</td></tr><br />
<tr><td>Time</td> <td>Block time.</td></tr><br />
<tr><td>Height</td> <td>Current block height</td></tr><br />
<tr><td>merkleProof</td> <td>Merkle branch of the block (list of hex strings)</td></tr><br />
</table><br />
<br />
===Example Block Header in the json format===<br />
{<br />
"id": "0d49aa74-0986-474f-a6eb-5913fbbbba02",<br />
"prevhash": "0000000000000000012811f570b3c0ff8cb93c44d707499dc2fcfdd611f38d93",<br />
"coinbaseValue": 1251906370,<br />
"version": 536870912,<br />
"nBits": "1802c73f",<br />
"time": 1585156824,<br />
"height": 627795,<br />
"merkleProof": [<br />
"f4cba40673d5573ca1aab2ee8fbd300102767561190cad7aa6211e04223ff6c3",<br />
"2d69511004ba72b60a10e6482491d689470b9f8527aff0f550c197d8a2446c45",<br />
"6eb9f4ef18f9669db60b21dc52292eba5318d684f7c476bb12da03b6d97d7c4f",<br />
"7a69a2fb7b132b36496501357d923ce584f913b37879a1930a10682d284bc2a9",<br />
"976089f04a73862fac14d2eec8b3f23aef9167f9804c40ade23c4f385cd92928",<br />
"73ec68c1692643e7edd22a34729f4bc8529fed48eca8ac0cd6e8b2929fb44064",<br />
"ee59af2b7964c1c0f48cd06b4e4e77c783711746030cc20d46a339f3d9993709",<br />
"6c0a33f1a1778ebec5d63172c55edb433ae365dbf7cd37bfa3535c864e9b9ea7",<br />
"d59744d6f3548adda90444a44eb16c56022554fdd4a0448632acd36058c96599",<br />
"6bd2d6dcdea8dd04345b7b706ba125ed73394be899355cb7b355d258eea20ff5",<br />
"3842aadab31a0e3bb5c484d58262f052afbe7f684935bf4d19ed614521e750e5",<br />
"91dec854c6f222b9be0cc78bd34b2405e98f34c6d2c7db8f84db6d85a83eb51e",<br />
"2b07dc2afdcafa3719c4ef440ef5c5f0c332efa174d23bbb72749680b36575a7"<br />
]<br />
}<br />
<br />
The Maestro software handles the call to and from the SV node to the ASIC miner. The ASIC miner then performs the hashing process to discover the next suitable block to be placed on the blockchain.</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2391Complex Script Options2020-04-02T13:23:55Z<p>AlexGraham: /* Other non-standard declarations can include: */</p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and ‘Non Standard’ or ‘customized’ scripts for transaction inputs and outputs.<br />
<br />
==Defining ‘Standard’==<br />
<br />
There are 5 standard scripts for Bitcoin SV (Referred to in WP1321)<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with Genesis after Feb 4th 2020)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
These scripts have been available as locking and redeeming scripts in Bitcoin.<br />
<br />
==Benefits of Non-standard - Why do we need non-standard scripts?==<br />
<br />
===Upgrade to Bitcoin SV Node===<br />
<br />
(Extracted from WP1321:)<br />
<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
==Defining ‘Non-standard’==<br />
<br />
The use of non standard scripts allows flexibility in the outputs potentially providing conditionality, enhanced security and computational possibilities.<br />
These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities activity.<br />
The use of customised scripts should lead to the extension of BSV services.<br />
<br />
Currently, there are some customized scripts under development as defined in WP1321.<br />
* R Puzzle - use of the r component of a signature<br />
* Rabin Signature - use of Rabin addressses and signatures (see Rabin Signatutes)<br />
* Multi Signature Accumulator - manage multi signature scenarios<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established through a Miner ID.<br />
<br />
==Other non-standard declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
The creation of payment addresses as the transaction output within a script that is non-standard or customised (See WP1322).</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2390Complex Script Options2020-04-02T13:22:19Z<p>AlexGraham: /* Defining ‘Non-standard’ */</p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and ‘Non Standard’ or ‘customized’ scripts for transaction inputs and outputs.<br />
<br />
==Defining ‘Standard’==<br />
<br />
There are 5 standard scripts for Bitcoin SV (Referred to in WP1321)<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with Genesis after Feb 4th 2020)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
These scripts have been available as locking and redeeming scripts in Bitcoin.<br />
<br />
==Benefits of Non-standard - Why do we need non-standard scripts?==<br />
<br />
===Upgrade to Bitcoin SV Node===<br />
<br />
(Extracted from WP1321:)<br />
<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
==Defining ‘Non-standard’==<br />
<br />
The use of non standard scripts allows flexibility in the outputs potentially providing conditionality, enhanced security and computational possibilities.<br />
These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities activity.<br />
The use of customised scripts should lead to the extension of BSV services.<br />
<br />
Currently, there are some customized scripts under development as defined in WP1321.<br />
* R Puzzle - use of the r component of a signature<br />
* Rabin Signature - use of Rabin addressses and signatures (see Rabin Signatutes)<br />
* Multi Signature Accumulator - manage multi signature scenarios<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established through a Miner ID.<br />
<br />
==Other non-standard declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
The creation of payment addresses within a transaction script that is non-standard or customised (See WP1322).</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2389Complex Script Options2020-04-02T13:21:27Z<p>AlexGraham: /* == */</p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and ‘Non Standard’ or ‘customized’ scripts for transaction inputs and outputs.<br />
<br />
==Defining ‘Standard’==<br />
<br />
There are 5 standard scripts for Bitcoin SV (Referred to in WP1321)<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with Genesis after Feb 4th 2020)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
These scripts have been available as locking and redeeming scripts in Bitcoin.<br />
<br />
==Benefits of Non-standard - Why do we need non-standard scripts?==<br />
<br />
===Upgrade to Bitcoin SV Node===<br />
<br />
(Extracted from WP1321:)<br />
<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
==Defining ‘Non-standard’==<br />
<br />
The use of non standard scripts allows flexibility in the outputs potentially providing conditionality, enhanced security and computational possibilities.<br />
These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities activity.<br />
The use of customised scripts should lead to the extension of BSV services.<br />
<br />
Currently, there are some customized scripts under development as defined in WP1321.<br />
* R Puzzle - use of the r component of a signature<br />
* Rabin Signature - use of Rabin addressses<br />
* Multi Signature Accumulator - manage multi signature scenarios<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established through a Miner ID.<br />
<br />
==Other non-standard declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
The creation of payment addresses within a transaction script that is non-standard or customised (See WP1322).</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2388Complex Script Options2020-04-02T13:20:58Z<p>AlexGraham: /* Benefits of Non-standard - Why do we need non-standard scripts? */</p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and ‘Non Standard’ or ‘customized’ scripts for transaction inputs and outputs.<br />
<br />
==Defining ‘Standard’==<br />
<br />
There are 5 standard scripts for Bitcoin SV (Referred to in WP1321)<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with Genesis after Feb 4th 2020)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
These scripts have been available as locking and redeeming scripts in Bitcoin.<br />
<br />
==Benefits of Non-standard - Why do we need non-standard scripts?==<br />
<br />
===Upgrade to Bitcoin SV Node===<br />
<br />
(Extracted from WP1321:)<br />
<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
==================================================================================<br />
<br />
==Defining ‘Non-standard’==<br />
<br />
The use of non standard scripts allows flexibility in the outputs potentially providing conditionality, enhanced security and computational possibilities.<br />
These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities activity.<br />
The use of customised scripts should lead to the extension of BSV services.<br />
<br />
Currently, there are some customized scripts under development as defined in WP1321.<br />
* R Puzzle - use of the r component of a signature<br />
* Rabin Signature - use of Rabin addressses<br />
* Multi Signature Accumulator - manage multi signature scenarios<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established through a Miner ID.<br />
<br />
==Other non-standard declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
The creation of payment addresses within a transaction script that is non-standard or customised (See WP1322).</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2387Complex Script Options2020-04-02T12:58:31Z<p>AlexGraham: /* Defining ‘Standard’ */</p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and ‘Non Standard’ or ‘customized’ scripts for transaction inputs and outputs.<br />
<br />
==Defining ‘Standard’==<br />
<br />
There are 5 standard scripts for Bitcoin SV (Referred to in WP1321)<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with Genesis after Feb 4th 2020)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
These scripts have been available as locking and redeeming scripts in Bitcoin.<br />
<br />
==Benefits of Non-standard - Why do we need non-standard scripts?==<br />
<br />
Extracted from WP1321:<br />
<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
==================================================================================<br />
<br />
==Defining ‘Non-standard’==<br />
<br />
The use of non standard scripts allows flexibility in the outputs potentially providing conditionality, enhanced security and computational possibilities.<br />
These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities activity.<br />
The use of customised scripts should lead to the extension of BSV services.<br />
<br />
Currently, there are some customized scripts under development as defined in WP1321.<br />
* R Puzzle - use of the r component of a signature<br />
* Rabin Signature - use of Rabin addressses<br />
* Multi Signature Accumulator - manage multi signature scenarios<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established through a Miner ID.<br />
<br />
==Other non-standard declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
The creation of payment addresses within a transaction script that is non-standard or customised (See WP1322).</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2386Complex Script Options2020-04-02T12:51:21Z<p>AlexGraham: /* Defining ‘Non-standard’ */</p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and ‘Non Standard’ or ‘customized’ scripts for transaction inputs and outputs.<br />
<br />
==Defining ‘Standard’==<br />
<br />
There are 5 standard scripts for Bitcoin SV (Referred to in WP1321)<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with Genesis….?)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
These scripts have been available as locking and redeeming scripts in Bitcoin.<br />
<br />
==Benefits of Non-standard - Why do we need non-standard scripts?==<br />
<br />
Extracted from WP1321:<br />
<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
==================================================================================<br />
<br />
==Defining ‘Non-standard’==<br />
<br />
The use of non standard scripts allows flexibility in the outputs potentially providing conditionality, enhanced security and computational possibilities.<br />
These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities activity.<br />
The use of customised scripts should lead to the extension of BSV services.<br />
<br />
Currently, there are some customized scripts under development as defined in WP1321.<br />
* R Puzzle - use of the r component of a signature<br />
* Rabin Signature - use of Rabin addressses<br />
* Multi Signature Accumulator - manage multi signature scenarios<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established through a Miner ID.<br />
<br />
==Other non-standard declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
The creation of payment addresses within a transaction script that is non-standard or customised (See WP1322).</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2385Complex Script Options2020-04-02T11:27:22Z<p>AlexGraham: /* Defining ‘Non-standard’ */</p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and ‘Non Standard’ or ‘customized’ scripts for transaction inputs and outputs.<br />
<br />
==Defining ‘Standard’==<br />
<br />
There are 5 standard scripts for Bitcoin SV (Referred to in WP1321)<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with Genesis….?)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
These scripts have been available as locking and redeeming scripts in Bitcoin.<br />
<br />
==Benefits of Non-standard - Why do we need non-standard scripts?==<br />
<br />
Extracted from WP1321:<br />
<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
==================================================================================<br />
<br />
==Defining ‘Non-standard’==<br />
<br />
The use of non standard scripts allows flexibility in the outputs potentially providing conditionality, enhanced security and computational possibilities.<br />
These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities activity.<br />
The use of customised scripts should lead to the extension of BSV services.<br />
<br />
Currently, there are some customized scripts under development as defined in WP1321.<br />
* R Puzzle<br />
* Rabin Signature<br />
* Multi Signature Accumulator<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established through a Miner ID.<br />
<br />
==Other non-standard declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
The creation of payment addresses within a transaction script that is non-standard or customised (See WP1322).</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2384Complex Script Options2020-04-02T11:26:05Z<p>AlexGraham: </p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and ‘Non Standard’ or ‘customized’ scripts for transaction inputs and outputs.<br />
<br />
==Defining ‘Standard’==<br />
<br />
There are 5 standard scripts for Bitcoin SV (Referred to in WP1321)<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with Genesis….?)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
These scripts have been available as locking and redeeming scripts in Bitcoin.<br />
<br />
==Benefits of Non-standard - Why do we need non-standard scripts?==<br />
<br />
Extracted from WP1321:<br />
<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
==================================================================================<br />
<br />
==Defining ‘Non-standard’==<br />
<br />
The use of non standard scripts allows flexibility in the outputs potentially providing conditionality, enhanced security and computational possibilities.<br />
These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities activity.<br />
The use of customised scripts should lead to the extension of BSV services.<br />
<br />
Currently, there are some customized scripts under development as defined in WP1321.<br />
* R Puzzle<br />
* Rabin Signature<br />
* Multi Signature Accumulator<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established.<br />
<br />
==Other non-standard declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
The creation of payment addresses within a transaction script that is non-standard or customised (See WP1322).</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2383Complex Script Options2020-04-02T11:25:13Z<p>AlexGraham: </p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and ‘Non Standard’ or ‘customized’ scripts for transaction inputs and outputs.<br />
<br />
==Defining ‘Standard’==<br />
<br />
There are 5 standard scripts for BitcoinSV (Referred to in WP1321)<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with Genesis….?)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
These scripts have been available as locking and redeeming scripts in Bitcoin.<br />
<br />
==Benefits of Non-standard - Why do we need non-standard scripts?==<br />
<br />
Extracted from WP1321:<br />
<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
==================================================================================<br />
<br />
==Defining ‘Non-standard’==<br />
<br />
The use of non standard scripts allows flexibility in the outputs potentially providing conditionality, enhanced security and computational possibilities.<br />
These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities activity.<br />
The use of customised scripts should lead to the extension of BSV services.<br />
<br />
Currently, there are some customized scripts under development as defined in WP1321.<br />
* R Puzzle<br />
* Rabin Signature<br />
* Multi Signature Accumulator<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established.<br />
<br />
==Other non-standard declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
The creation of payment addresses within a transaction script that is non-standard or customised (See WP1322).</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Getminingcandidate&diff=2382Getminingcandidate2020-04-02T10:26:39Z<p>AlexGraham: /* Example Block Header in the json format in getminingcandidate */</p>
<hr />
<div>''getminingcandidate'' and ''getblocktemplate'' are Remote Procedure Call (RPC) programs. The RPC calls are located at an SV node and are currently managed and configured through Maestro software, though a number of software packages may perform these tasks.<br />
<br />
The miner can make a request with either of the above programs for block information:<br />
* The ''getblocktemplate'' returns a full block.<br />
* The ''getminingcandidate'' program returns the block header.<br />
The returned data is the block candidate data for mining. It is expressed in the JSON language for data processing.<br />
<br />
''getminingcandidate'' returns a mining candidate block to the node which originally requested it. The node requests a block to mine. ''getminingcandidate'' is the program that obtains a block header to mine.<br />
<br />
The ''getminingcandidate'' program or call is a replacement for ''getblocktemplate'' program. <br />
The replacement requirement arose from the need to process bigger blocks with Merkle tree paths in the block header. The Merkle tree proof in the block header allows for confirmation of transactions rather than reading the transactions as a whole. Consequently there can be more transactions within a block and more efficient external processing of the block.<br />
<br />
===Block header parameters for getminingcandidate===<br />
<table><br />
<tr><td>Parameter</td> <td>Description</td></tr><br />
<tr><td>Id</td> <td>Candidate identifier for submitminingsolution</td></tr><br />
<tr><td>Prevhash</td> <td>Hash of the previous block (hex string)</td></tr><br />
<tr><td>Coinbase</td> <td>Coinbase transaction (optional hex string encoded binary transaction)</td></tr><br />
<tr><td>Version</td> <td>Block version</td></tr><br />
<tr><td>nBits</td><br />
<td>Difficulty given as hex string.</td></tr><br />
<tr><td>Time</td> <td>Block time.</td></tr><br />
<tr><td>Height</td> <td>Current block height</td></tr><br />
<tr><td>merkleProof</td> <td>Merkle branch of the block (list of hex strings)</td></tr><br />
</table><br />
<br />
===Example Block Header in the json format===<br />
{<br />
"id": "0d49aa74-0986-474f-a6eb-5913fbbbba02",<br />
"prevhash": "0000000000000000012811f570b3c0ff8cb93c44d707499dc2fcfdd611f38d93",<br />
"coinbaseValue": 1251906370,<br />
"version": 536870912,<br />
"nBits": "1802c73f",<br />
"time": 1585156824,<br />
"height": 627795,<br />
"merkleProof": [<br />
"f4cba40673d5573ca1aab2ee8fbd300102767561190cad7aa6211e04223ff6c3",<br />
"2d69511004ba72b60a10e6482491d689470b9f8527aff0f550c197d8a2446c45",<br />
"6eb9f4ef18f9669db60b21dc52292eba5318d684f7c476bb12da03b6d97d7c4f",<br />
"7a69a2fb7b132b36496501357d923ce584f913b37879a1930a10682d284bc2a9",<br />
"976089f04a73862fac14d2eec8b3f23aef9167f9804c40ade23c4f385cd92928",<br />
"73ec68c1692643e7edd22a34729f4bc8529fed48eca8ac0cd6e8b2929fb44064",<br />
"ee59af2b7964c1c0f48cd06b4e4e77c783711746030cc20d46a339f3d9993709",<br />
"6c0a33f1a1778ebec5d63172c55edb433ae365dbf7cd37bfa3535c864e9b9ea7",<br />
"d59744d6f3548adda90444a44eb16c56022554fdd4a0448632acd36058c96599",<br />
"6bd2d6dcdea8dd04345b7b706ba125ed73394be899355cb7b355d258eea20ff5",<br />
"3842aadab31a0e3bb5c484d58262f052afbe7f684935bf4d19ed614521e750e5",<br />
"91dec854c6f222b9be0cc78bd34b2405e98f34c6d2c7db8f84db6d85a83eb51e",<br />
"2b07dc2afdcafa3719c4ef440ef5c5f0c332efa174d23bbb72749680b36575a7"<br />
]<br />
}<br />
<br />
The Maestro software handles the call to and from the SV node to the ASIC miner. The ASIC miner then performs the hashing process to discover the next suitable block to be placed on the blockchain.</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Getminingcandidate&diff=2381Getminingcandidate2020-04-02T10:25:02Z<p>AlexGraham: /* Block header parameters in getminingcandidate */</p>
<hr />
<div>''getminingcandidate'' and ''getblocktemplate'' are Remote Procedure Call (RPC) programs. The RPC calls are located at an SV node and are currently managed and configured through Maestro software, though a number of software packages may perform these tasks.<br />
<br />
The miner can make a request with either of the above programs for block information:<br />
* The ''getblocktemplate'' returns a full block.<br />
* The ''getminingcandidate'' program returns the block header.<br />
The returned data is the block candidate data for mining. It is expressed in the JSON language for data processing.<br />
<br />
''getminingcandidate'' returns a mining candidate block to the node which originally requested it. The node requests a block to mine. ''getminingcandidate'' is the program that obtains a block header to mine.<br />
<br />
The ''getminingcandidate'' program or call is a replacement for ''getblocktemplate'' program. <br />
The replacement requirement arose from the need to process bigger blocks with Merkle tree paths in the block header. The Merkle tree proof in the block header allows for confirmation of transactions rather than reading the transactions as a whole. Consequently there can be more transactions within a block and more efficient external processing of the block.<br />
<br />
===Block header parameters for getminingcandidate===<br />
<table><br />
<tr><td>Parameter</td> <td>Description</td></tr><br />
<tr><td>Id</td> <td>Candidate identifier for submitminingsolution</td></tr><br />
<tr><td>Prevhash</td> <td>Hash of the previous block (hex string)</td></tr><br />
<tr><td>Coinbase</td> <td>Coinbase transaction (optional hex string encoded binary transaction)</td></tr><br />
<tr><td>Version</td> <td>Block version</td></tr><br />
<tr><td>nBits</td><br />
<td>Difficulty given as hex string.</td></tr><br />
<tr><td>Time</td> <td>Block time.</td></tr><br />
<tr><td>Height</td> <td>Current block height</td></tr><br />
<tr><td>merkleProof</td> <td>Merkle branch of the block (list of hex strings)</td></tr><br />
</table><br />
<br />
===Example Block Header in the json format in getminingcandidate===<br />
{<br />
"id": "0d49aa74-0986-474f-a6eb-5913fbbbba02",<br />
"prevhash": "0000000000000000012811f570b3c0ff8cb93c44d707499dc2fcfdd611f38d93",<br />
"coinbaseValue": 1251906370,<br />
"version": 536870912,<br />
"nBits": "1802c73f",<br />
"time": 1585156824,<br />
"height": 627795,<br />
"merkleProof": [<br />
"f4cba40673d5573ca1aab2ee8fbd300102767561190cad7aa6211e04223ff6c3",<br />
"2d69511004ba72b60a10e6482491d689470b9f8527aff0f550c197d8a2446c45",<br />
"6eb9f4ef18f9669db60b21dc52292eba5318d684f7c476bb12da03b6d97d7c4f",<br />
"7a69a2fb7b132b36496501357d923ce584f913b37879a1930a10682d284bc2a9",<br />
"976089f04a73862fac14d2eec8b3f23aef9167f9804c40ade23c4f385cd92928",<br />
"73ec68c1692643e7edd22a34729f4bc8529fed48eca8ac0cd6e8b2929fb44064",<br />
"ee59af2b7964c1c0f48cd06b4e4e77c783711746030cc20d46a339f3d9993709",<br />
"6c0a33f1a1778ebec5d63172c55edb433ae365dbf7cd37bfa3535c864e9b9ea7",<br />
"d59744d6f3548adda90444a44eb16c56022554fdd4a0448632acd36058c96599",<br />
"6bd2d6dcdea8dd04345b7b706ba125ed73394be899355cb7b355d258eea20ff5",<br />
"3842aadab31a0e3bb5c484d58262f052afbe7f684935bf4d19ed614521e750e5",<br />
"91dec854c6f222b9be0cc78bd34b2405e98f34c6d2c7db8f84db6d85a83eb51e",<br />
"2b07dc2afdcafa3719c4ef440ef5c5f0c332efa174d23bbb72749680b36575a7"<br />
]<br />
}<br />
<br />
The Maestro software handles the call to and from the SV node to the ASIC miner. The ASIC miner then performs the hashing process to discover the next suitable block to be placed on the blockchain.</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Getminingcandidate&diff=2380Getminingcandidate2020-04-02T10:16:44Z<p>AlexGraham: </p>
<hr />
<div>''getminingcandidate'' and ''getblocktemplate'' are Remote Procedure Call (RPC) programs. The RPC calls are located at an SV node and are currently managed and configured through Maestro software, though a number of software packages may perform these tasks.<br />
<br />
The miner can make a request with either of the above programs for block information:<br />
* The ''getblocktemplate'' returns a full block.<br />
* The ''getminingcandidate'' program returns the block header.<br />
The returned data is the block candidate data for mining. It is expressed in the JSON language for data processing.<br />
<br />
''getminingcandidate'' returns a mining candidate block to the node which originally requested it. The node requests a block to mine. ''getminingcandidate'' is the program that obtains a block header to mine.<br />
<br />
The ''getminingcandidate'' program or call is a replacement for ''getblocktemplate'' program. <br />
The replacement requirement arose from the need to process bigger blocks with Merkle tree paths in the block header. The Merkle tree proof in the block header allows for confirmation of transactions rather than reading the transactions as a whole. Consequently there can be more transactions within a block and more efficient external processing of the block.<br />
<br />
===Block header parameters in getminingcandidate===<br />
<table><br />
<tr><td>Parameter</td> <td>Description</td></tr><br />
<tr><td>Id</td> <td>Candidate identifier for submitminingsolution</td></tr><br />
<tr><td>Prevhash</td> <td>Hash of the previous block (hex string)</td></tr><br />
<tr><td>Coinbase</td> <td>Coinbase transaction (optional hex string encoded binary transaction)</td></tr><br />
<tr><td>Version</td> <td>Block version</td></tr><br />
<tr><td>nBits</td><br />
<td>Difficulty given as hex string.</td></tr><br />
<tr><td>Time</td> <td>Block time.</td></tr><br />
<tr><td>Height</td> <td>Current block height</td></tr><br />
<tr><td>merkleProof</td> <td>Merkle branch of the block (list of hex strings)</td></tr><br />
</table><br />
<br />
===Example Block Header in the json format in getminingcandidate===<br />
{<br />
"id": "0d49aa74-0986-474f-a6eb-5913fbbbba02",<br />
"prevhash": "0000000000000000012811f570b3c0ff8cb93c44d707499dc2fcfdd611f38d93",<br />
"coinbaseValue": 1251906370,<br />
"version": 536870912,<br />
"nBits": "1802c73f",<br />
"time": 1585156824,<br />
"height": 627795,<br />
"merkleProof": [<br />
"f4cba40673d5573ca1aab2ee8fbd300102767561190cad7aa6211e04223ff6c3",<br />
"2d69511004ba72b60a10e6482491d689470b9f8527aff0f550c197d8a2446c45",<br />
"6eb9f4ef18f9669db60b21dc52292eba5318d684f7c476bb12da03b6d97d7c4f",<br />
"7a69a2fb7b132b36496501357d923ce584f913b37879a1930a10682d284bc2a9",<br />
"976089f04a73862fac14d2eec8b3f23aef9167f9804c40ade23c4f385cd92928",<br />
"73ec68c1692643e7edd22a34729f4bc8529fed48eca8ac0cd6e8b2929fb44064",<br />
"ee59af2b7964c1c0f48cd06b4e4e77c783711746030cc20d46a339f3d9993709",<br />
"6c0a33f1a1778ebec5d63172c55edb433ae365dbf7cd37bfa3535c864e9b9ea7",<br />
"d59744d6f3548adda90444a44eb16c56022554fdd4a0448632acd36058c96599",<br />
"6bd2d6dcdea8dd04345b7b706ba125ed73394be899355cb7b355d258eea20ff5",<br />
"3842aadab31a0e3bb5c484d58262f052afbe7f684935bf4d19ed614521e750e5",<br />
"91dec854c6f222b9be0cc78bd34b2405e98f34c6d2c7db8f84db6d85a83eb51e",<br />
"2b07dc2afdcafa3719c4ef440ef5c5f0c332efa174d23bbb72749680b36575a7"<br />
]<br />
}<br />
<br />
The Maestro software handles the call to and from the SV node to the ASIC miner. The ASIC miner then performs the hashing process to discover the next suitable block to be placed on the blockchain.</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2379Complex Script Options2020-04-02T10:12:30Z<p>AlexGraham: /* Benefits of Non-standard - Why do we need non-standard scripts? */</p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and ‘Non Standard’ or ‘customized’ scripts for transaction inputs and outputs.<br />
<br />
==Defining ‘Standard’==<br />
<br />
There are 5 standard scripts for BitcoinSV (Referred to in WP1321)<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with Genesis….?)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
==Benefits of Non-standard - Why do we need non-standard scripts?==<br />
<br />
Extracted from WP1321:<br />
<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
==================================================================================<br />
<br />
==Defining ‘Non-standard’==<br />
<br />
The use of non standard scripts allows flexibility in the outputs potentially providing conditionality, enhanced security and computational possibilities.<br />
These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities activity.<br />
The use of customised scripts should lead to the extension of BSV services.<br />
<br />
Currently, there are some customized scripts under development as defined in WP1321.<br />
* R Puzzle<br />
* Rabin Signature<br />
* Multi Signature Accumulator<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established.<br />
<br />
==Other non-standard declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
The creation of payment addresses within a transaction script that is non-standard or customised (See WP1322).</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2378Complex Script Options2020-04-02T10:11:19Z<p>AlexGraham: /* Defining ‘Standard’ */</p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and ‘Non Standard’ or ‘customized’ scripts for transaction inputs and outputs.<br />
<br />
==Defining ‘Standard’==<br />
<br />
There are 5 standard scripts for BitcoinSV (Referred to in WP1321)<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with Genesis….?)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
==Benefits of Non-standard - Why do we need non-standard scripts?==<br />
<br />
=======================taken from WP1321 ==================================================<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
==================================================================================<br />
<br />
==Defining ‘Non-standard’==<br />
<br />
The use of non standard scripts allows flexibility in the outputs potentially providing conditionality, enhanced security and computational possibilities.<br />
These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities activity.<br />
The use of customised scripts should lead to the extension of BSV services.<br />
<br />
Currently, there are some customized scripts under development as defined in WP1321.<br />
* R Puzzle<br />
* Rabin Signature<br />
* Multi Signature Accumulator<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established.<br />
<br />
==Other non-standard declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
The creation of payment addresses within a transaction script that is non-standard or customised (See WP1322).</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2377Complex Script Options2020-04-02T10:10:29Z<p>AlexGraham: </p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and ‘Non Standard’ or ‘customized’ scripts for transaction inputs and outputs.<br />
<br />
==Defining ‘Standard’==<br />
<br />
According to WP1321 there are 5 standard scripts for BitcoinSV<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with Genesis….?)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
==Benefits of Non-standard - Why do we need non-standard scripts?==<br />
<br />
=======================taken from WP1321 ==================================================<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
==================================================================================<br />
<br />
==Defining ‘Non-standard’==<br />
<br />
The use of non standard scripts allows flexibility in the outputs potentially providing conditionality, enhanced security and computational possibilities.<br />
These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities activity.<br />
The use of customised scripts should lead to the extension of BSV services.<br />
<br />
Currently, there are some customized scripts under development as defined in WP1321.<br />
* R Puzzle<br />
* Rabin Signature<br />
* Multi Signature Accumulator<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established.<br />
<br />
==Other non-standard declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
The creation of payment addresses within a transaction script that is non-standard or customised (See WP1322).</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Complex_Script_Options&diff=2376Complex Script Options2020-04-02T10:08:06Z<p>AlexGraham: /* Defining ‘Non-standard’ */</p>
<hr />
<div>Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. <br />
<br />
A difference occurs in Bitcoin SV between ‘Standard’ and ‘Non Standard’ or ‘customized’ scripts for transaction inputs and outputs.<br />
<br />
==Defining ‘Standard’==<br />
<br />
According to WP1321 there are 5 standard scripts for BitcoinSV<br />
* P2PK – Pay to Public Key<br />
* P2PKH – Pay to Public Key Hash<br />
* P2MS – Pay to MultiSignature<br />
* P2SH – Pay to Script Hash (deprecated with Genesis….?)<br />
* OP_RETURN – opcode able to contain data<br />
<br />
==Benefits of Non-standard - Why do we need non-standard scripts?==<br />
<br />
=======================taken from WP1321 ==================================================<br />
The upgrade to the Bitcoin SV node software (v1.0.0) will introduce a number of consensus changes intended to enable Bitcoin to fulfil its original design as digitally programmable money. This includes lifting several scripting restrictions currently imposed by the network, thereby enabling users to create custom scripts. These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. However, this will be the first time in Bitcoin’s history that restrictive limits imposed on script will be lifted and therefore caution is required to avoid security risks.<br />
==================================================================================<br />
<br />
==Defining ‘Non-standard’==<br />
<br />
The use of non standard scripts allows flexibility in the outputs potentially providing conditionality, enhanced security and computational possibilities.<br />
These changes are being made to enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities activity.<br />
The use of customised scripts should lead to the extension of BSV services.<br />
Currently, there are some customized scripts under development as defined in WP1321.<br />
* R Puzzle<br />
* Rabin Signature<br />
* Multi Signature Accumulator<br />
Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific miner may need to be established.<br />
<br />
==Other non-standard declarations can include:==<br />
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)<br />
Where authenticating or verification information can be placed within a transaction.<br />
* Use of customized Address Generation <br />
See WP1322 – which allows for the creation of payment addresses within a transaction script that is non-standard or customised.</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Getminingcandidate&diff=2375Getminingcandidate2020-04-02T10:05:10Z<p>AlexGraham: </p>
<hr />
<div>''getminingcandidate'' and ''getblocktemplate'' are Remote Procedure Call (RPC) programs. The RPC calls are located at an SV node and are currently managed and configured through Maestro software, though a number of software packages may perform these tasks.<br />
<br />
The miner can make a request with either of the above programs for block information:<br />
* The ''getblocktemplate'' returns a full block.<br />
* The ''getminingcandidate'' program returns the blockheader.<br />
The returned data is the block candidate data for mining. It is expressed in the JSON language for data processing.<br />
<br />
''getminingcandidate'' returns a mining candidate block to the node which originally requested it. The node requests a block to mine. ''getminingcandidate'' is the program that obtains a block header to mine.<br />
<br />
The ''getminingcandidate'' program or call is a replacement for ''getblocktemplate'' program. <br />
The replacement requirement arose from the need to process bigger blocks with Merkle tree paths in the block header. The Merkle tree proof in the block header allows for confirmation of transactions rather than reading the transactions as a whole. Consequently there can be more transactions within a block and more efficient external processing of the block.<br />
<br />
===Block header parameters in getminingcandidate===<br />
<table><br />
<tr><td>Parameter</td> <td>Description</td></tr><br />
<tr><td>Id</td> <td>Candidate identifier for submitminingsolution</td></tr><br />
<tr><td>Prevhash</td> <td>Hash of the previous block (hex string)</td></tr><br />
<tr><td>Coinbase</td> <td>Coinbase transaction (optional hex string encoded binary transaction)</td></tr><br />
<tr><td>Version</td> <td>Block version</td></tr><br />
<tr><td>nBits</td><br />
<td>Difficulty given as hex string.</td></tr><br />
<tr><td>Time</td> <td>Block time.</td></tr><br />
<tr><td>Height</td> <td>Current block height</td></tr><br />
<tr><td>merkleProof</td> <td>Merkle branch of the block (list of hex strings)</td></tr><br />
</table><br />
<br />
===Example Block Header in the json format in getminingcandidate===<br />
{<br />
"id": "0d49aa74-0986-474f-a6eb-5913fbbbba02",<br />
"prevhash": "0000000000000000012811f570b3c0ff8cb93c44d707499dc2fcfdd611f38d93",<br />
"coinbaseValue": 1251906370,<br />
"version": 536870912,<br />
"nBits": "1802c73f",<br />
"time": 1585156824,<br />
"height": 627795,<br />
"merkleProof": [<br />
"f4cba40673d5573ca1aab2ee8fbd300102767561190cad7aa6211e04223ff6c3",<br />
"2d69511004ba72b60a10e6482491d689470b9f8527aff0f550c197d8a2446c45",<br />
"6eb9f4ef18f9669db60b21dc52292eba5318d684f7c476bb12da03b6d97d7c4f",<br />
"7a69a2fb7b132b36496501357d923ce584f913b37879a1930a10682d284bc2a9",<br />
"976089f04a73862fac14d2eec8b3f23aef9167f9804c40ade23c4f385cd92928",<br />
"73ec68c1692643e7edd22a34729f4bc8529fed48eca8ac0cd6e8b2929fb44064",<br />
"ee59af2b7964c1c0f48cd06b4e4e77c783711746030cc20d46a339f3d9993709",<br />
"6c0a33f1a1778ebec5d63172c55edb433ae365dbf7cd37bfa3535c864e9b9ea7",<br />
"d59744d6f3548adda90444a44eb16c56022554fdd4a0448632acd36058c96599",<br />
"6bd2d6dcdea8dd04345b7b706ba125ed73394be899355cb7b355d258eea20ff5",<br />
"3842aadab31a0e3bb5c484d58262f052afbe7f684935bf4d19ed614521e750e5",<br />
"91dec854c6f222b9be0cc78bd34b2405e98f34c6d2c7db8f84db6d85a83eb51e",<br />
"2b07dc2afdcafa3719c4ef440ef5c5f0c332efa174d23bbb72749680b36575a7"<br />
]<br />
}<br />
<br />
The Maestro software handles the call to and from the SV node to the ASIC miner. The ASIC miner then performs the hashing process to discover the next suitable block to be placed on the blockchain.</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Getminingcandidate&diff=2374Getminingcandidate2020-04-02T10:02:59Z<p>AlexGraham: </p>
<hr />
<div>''getminingcandidate'' and ''getblocktemplate'' are Remote Procedure Call (RPC) programs. The RPC calls are located at an SV node and are currently managed and configured through Maestro software, though a number of software packages may perform these tasks.<br />
<br />
The miner can make a request with either of the above programs for block information:<br />
* The ''getblocktemplate'' returns a full block.<br />
* The ''getminingcandidate'' program returns the blockheader.<br />
The returned data is the block candidate data for mining. It is expressed in the JSON language for data processing.<br />
<br />
''getminingcandidate'' returns a mining candidate or candidate block to the node which originally requested it. The node requests a block to mine. ''getminingcandidate'' is the program that obtains a block header to mine.<br />
<br />
The ''getminingcandidate'' program or call is a replacement for ''getblocktemplate'' program. <br />
The replacement requirement arose from the need to process bigger blocks with Merkle tree paths in the block header. The Merkle tree proof in the block header allows for confirmation of transactions rather than reading the transactions as a whole. Consequently there can be more transactions within a block and more efficient external processing of the block.<br />
<br />
===Block header parameters in getminingcandidate===<br />
<table><br />
<tr><td>Parameter</td> <td>Description</td></tr><br />
<tr><td>Id</td> <td>Candidate identifier for submitminingsolution</td></tr><br />
<tr><td>Prevhash</td> <td>Hash of the previous block (hex string)</td></tr><br />
<tr><td>Coinbase</td> <td>Coinbase transaction (optional hex string encoded binary transaction)</td></tr><br />
<tr><td>Version</td> <td>Block version</td></tr><br />
<tr><td>nBits</td><br />
<td>Difficulty given as hex string.</td></tr><br />
<tr><td>Time</td> <td>Block time.</td></tr><br />
<tr><td>Height</td> <td>Current block height</td></tr><br />
<tr><td>merkleProof</td> <td>Merkle branch of the block (list of hex strings)</td></tr><br />
</table><br />
<br />
===Example Block Header in the json format in getminingcandidate===<br />
{<br />
"id": "0d49aa74-0986-474f-a6eb-5913fbbbba02",<br />
"prevhash": "0000000000000000012811f570b3c0ff8cb93c44d707499dc2fcfdd611f38d93",<br />
"coinbaseValue": 1251906370,<br />
"version": 536870912,<br />
"nBits": "1802c73f",<br />
"time": 1585156824,<br />
"height": 627795,<br />
"merkleProof": [<br />
"f4cba40673d5573ca1aab2ee8fbd300102767561190cad7aa6211e04223ff6c3",<br />
"2d69511004ba72b60a10e6482491d689470b9f8527aff0f550c197d8a2446c45",<br />
"6eb9f4ef18f9669db60b21dc52292eba5318d684f7c476bb12da03b6d97d7c4f",<br />
"7a69a2fb7b132b36496501357d923ce584f913b37879a1930a10682d284bc2a9",<br />
"976089f04a73862fac14d2eec8b3f23aef9167f9804c40ade23c4f385cd92928",<br />
"73ec68c1692643e7edd22a34729f4bc8529fed48eca8ac0cd6e8b2929fb44064",<br />
"ee59af2b7964c1c0f48cd06b4e4e77c783711746030cc20d46a339f3d9993709",<br />
"6c0a33f1a1778ebec5d63172c55edb433ae365dbf7cd37bfa3535c864e9b9ea7",<br />
"d59744d6f3548adda90444a44eb16c56022554fdd4a0448632acd36058c96599",<br />
"6bd2d6dcdea8dd04345b7b706ba125ed73394be899355cb7b355d258eea20ff5",<br />
"3842aadab31a0e3bb5c484d58262f052afbe7f684935bf4d19ed614521e750e5",<br />
"91dec854c6f222b9be0cc78bd34b2405e98f34c6d2c7db8f84db6d85a83eb51e",<br />
"2b07dc2afdcafa3719c4ef440ef5c5f0c332efa174d23bbb72749680b36575a7"<br />
]<br />
}<br />
<br />
The Maestro software handles the call to and from the SV node to the ASIC miner. The ASIC miner then performs the hashing process to discover the next suitable block to be placed on the blockchain.</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Getminingcandidate&diff=2373Getminingcandidate2020-04-02T10:01:25Z<p>AlexGraham: </p>
<hr />
<div>''getminingcandidate'' and ''getblocktemplate'' are Remote Procedure Call (RPC) programs. The RPC calls are located at an SV node and are currently managed and configured through Maestro software, though a number of software packages may perform these tasks.<br />
<br />
The miner can make a request with either of the above programs for block information:<br />
* The ''getblocktemplate'' returns a full block as the mining candidate.<br />
* The ''getminingcandidate'' program returns the blockheader only for the mining candidate.<br />
The returned data is the block candidate data. It is expressed in the JSON language for data processing.<br />
<br />
''getminingcandidate'' returns a mining candidate or candidate block to the node which originally requested it. The node requests a block to mine. ''getminingcandidate'' is the program that obtains a block header to mine.<br />
<br />
The ''getminingcandidate'' program or call is a replacement for ''getblocktemplate'' program. <br />
The replacement requirement arose from the need to process bigger blocks with Merkle tree paths in the block header. The Merkle tree proof in the block header allows for confirmation of transactions rather than reading the transactions as a whole. Consequently there can be more transactions within a block and more efficient external processing of the block.<br />
<br />
===Block header parameters in getminingcandidate===<br />
<table><br />
<tr><td>Parameter</td> <td>Description</td></tr><br />
<tr><td>Id</td> <td>Candidate identifier for submitminingsolution</td></tr><br />
<tr><td>Prevhash</td> <td>Hash of the previous block (hex string)</td></tr><br />
<tr><td>Coinbase</td> <td>Coinbase transaction (optional hex string encoded binary transaction)</td></tr><br />
<tr><td>Version</td> <td>Block version</td></tr><br />
<tr><td>nBits</td><br />
<td>Difficulty given as hex string.</td></tr><br />
<tr><td>Time</td> <td>Block time.</td></tr><br />
<tr><td>Height</td> <td>Current block height</td></tr><br />
<tr><td>merkleProof</td> <td>Merkle branch of the block (list of hex strings)</td></tr><br />
</table><br />
<br />
===Example Block Header in the json format in getminingcandidate===<br />
{<br />
"id": "0d49aa74-0986-474f-a6eb-5913fbbbba02",<br />
"prevhash": "0000000000000000012811f570b3c0ff8cb93c44d707499dc2fcfdd611f38d93",<br />
"coinbaseValue": 1251906370,<br />
"version": 536870912,<br />
"nBits": "1802c73f",<br />
"time": 1585156824,<br />
"height": 627795,<br />
"merkleProof": [<br />
"f4cba40673d5573ca1aab2ee8fbd300102767561190cad7aa6211e04223ff6c3",<br />
"2d69511004ba72b60a10e6482491d689470b9f8527aff0f550c197d8a2446c45",<br />
"6eb9f4ef18f9669db60b21dc52292eba5318d684f7c476bb12da03b6d97d7c4f",<br />
"7a69a2fb7b132b36496501357d923ce584f913b37879a1930a10682d284bc2a9",<br />
"976089f04a73862fac14d2eec8b3f23aef9167f9804c40ade23c4f385cd92928",<br />
"73ec68c1692643e7edd22a34729f4bc8529fed48eca8ac0cd6e8b2929fb44064",<br />
"ee59af2b7964c1c0f48cd06b4e4e77c783711746030cc20d46a339f3d9993709",<br />
"6c0a33f1a1778ebec5d63172c55edb433ae365dbf7cd37bfa3535c864e9b9ea7",<br />
"d59744d6f3548adda90444a44eb16c56022554fdd4a0448632acd36058c96599",<br />
"6bd2d6dcdea8dd04345b7b706ba125ed73394be899355cb7b355d258eea20ff5",<br />
"3842aadab31a0e3bb5c484d58262f052afbe7f684935bf4d19ed614521e750e5",<br />
"91dec854c6f222b9be0cc78bd34b2405e98f34c6d2c7db8f84db6d85a83eb51e",<br />
"2b07dc2afdcafa3719c4ef440ef5c5f0c332efa174d23bbb72749680b36575a7"<br />
]<br />
}<br />
<br />
The Maestro software handles the call to and from the SV node to the ASIC miner. The ASIC miner then performs the hashing process to discover the next suitable block to be placed on the blockchain.</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Getminingcandidate&diff=2372Getminingcandidate2020-04-02T09:59:53Z<p>AlexGraham: </p>
<hr />
<div>''getminingcandidate'' and ''getblocktemplate'' are Remote Procedure Call (RPC) programs. The RPC calls are located at an SV node and are currently managed and configured through Maestro software, though a number of software packages may perform these tasks.<br />
<br />
The miner can make a request with either of the above programs for block information:<br />
* The ''getblocktemplate'' returns a full block.<br />
* The ''getminingcandidate'' program returns the blockheader only for the mining candidate.<br />
The returned data is the block candidate data. It is expressed in the JSON language for data processing.<br />
<br />
''getminingcandidate'' returns a mining candidate or candidate block to the node which originally requested it. The node requests a block to mine. ''getminingcandidate'' is the program that obtains a block header to mine.<br />
<br />
The ''getminingcandidate'' program or call is a replacement for ''getblocktemplate'' program. <br />
The replacement requirement arose from the need to process bigger blocks with Merkle tree paths in the block header. The Merkle tree proof in the block header allows for confirmation of transactions rather than reading the transactions as a whole. Consequently there can be more transactions within a block and more efficient external processing of the block.<br />
<br />
===Block header parameters in getminingcandidate===<br />
<table><br />
<tr><td>Parameter</td> <td>Description</td></tr><br />
<tr><td>Id</td> <td>Candidate identifier for submitminingsolution</td></tr><br />
<tr><td>Prevhash</td> <td>Hash of the previous block (hex string)</td></tr><br />
<tr><td>Coinbase</td> <td>Coinbase transaction (optional hex string encoded binary transaction)</td></tr><br />
<tr><td>Version</td> <td>Block version</td></tr><br />
<tr><td>nBits</td><br />
<td>Difficulty given as hex string.</td></tr><br />
<tr><td>Time</td> <td>Block time.</td></tr><br />
<tr><td>Height</td> <td>Current block height</td></tr><br />
<tr><td>merkleProof</td> <td>Merkle branch of the block (list of hex strings)</td></tr><br />
</table><br />
<br />
===Example Block Header in the json format in getminingcandidate===<br />
{<br />
"id": "0d49aa74-0986-474f-a6eb-5913fbbbba02",<br />
"prevhash": "0000000000000000012811f570b3c0ff8cb93c44d707499dc2fcfdd611f38d93",<br />
"coinbaseValue": 1251906370,<br />
"version": 536870912,<br />
"nBits": "1802c73f",<br />
"time": 1585156824,<br />
"height": 627795,<br />
"merkleProof": [<br />
"f4cba40673d5573ca1aab2ee8fbd300102767561190cad7aa6211e04223ff6c3",<br />
"2d69511004ba72b60a10e6482491d689470b9f8527aff0f550c197d8a2446c45",<br />
"6eb9f4ef18f9669db60b21dc52292eba5318d684f7c476bb12da03b6d97d7c4f",<br />
"7a69a2fb7b132b36496501357d923ce584f913b37879a1930a10682d284bc2a9",<br />
"976089f04a73862fac14d2eec8b3f23aef9167f9804c40ade23c4f385cd92928",<br />
"73ec68c1692643e7edd22a34729f4bc8529fed48eca8ac0cd6e8b2929fb44064",<br />
"ee59af2b7964c1c0f48cd06b4e4e77c783711746030cc20d46a339f3d9993709",<br />
"6c0a33f1a1778ebec5d63172c55edb433ae365dbf7cd37bfa3535c864e9b9ea7",<br />
"d59744d6f3548adda90444a44eb16c56022554fdd4a0448632acd36058c96599",<br />
"6bd2d6dcdea8dd04345b7b706ba125ed73394be899355cb7b355d258eea20ff5",<br />
"3842aadab31a0e3bb5c484d58262f052afbe7f684935bf4d19ed614521e750e5",<br />
"91dec854c6f222b9be0cc78bd34b2405e98f34c6d2c7db8f84db6d85a83eb51e",<br />
"2b07dc2afdcafa3719c4ef440ef5c5f0c332efa174d23bbb72749680b36575a7"<br />
]<br />
}<br />
<br />
The Maestro software handles the call to and from the SV node to the ASIC miner. The ASIC miner then performs the hashing process to discover the next suitable block to be placed on the blockchain.</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Getminingcandidate&diff=2371Getminingcandidate2020-04-02T09:59:36Z<p>AlexGraham: </p>
<hr />
<div>''getminingcandidate'' and ''getblocktemplate'' are Remote Procedure call (RPC) programs. The RPC calls are located at an SV node and are currently managed and configured through Maestro software, though a number of software packages may perform these tasks.<br />
<br />
The miner can make a request with either of the above programs for block information:<br />
* The ''getblocktemplate'' returns a full block.<br />
* The ''getminingcandidate'' program returns the blockheader only for the mining candidate.<br />
The returned data is the block candidate data. It is expressed in the JSON language for data processing.<br />
<br />
''getminingcandidate'' returns a mining candidate or candidate block to the node which originally requested it. The node requests a block to mine. ''getminingcandidate'' is the program that obtains a block header to mine.<br />
<br />
The ''getminingcandidate'' program or call is a replacement for ''getblocktemplate'' program. <br />
The replacement requirement arose from the need to process bigger blocks with Merkle tree paths in the block header. The Merkle tree proof in the block header allows for confirmation of transactions rather than reading the transactions as a whole. Consequently there can be more transactions within a block and more efficient external processing of the block.<br />
<br />
===Block header parameters in getminingcandidate===<br />
<table><br />
<tr><td>Parameter</td> <td>Description</td></tr><br />
<tr><td>Id</td> <td>Candidate identifier for submitminingsolution</td></tr><br />
<tr><td>Prevhash</td> <td>Hash of the previous block (hex string)</td></tr><br />
<tr><td>Coinbase</td> <td>Coinbase transaction (optional hex string encoded binary transaction)</td></tr><br />
<tr><td>Version</td> <td>Block version</td></tr><br />
<tr><td>nBits</td><br />
<td>Difficulty given as hex string.</td></tr><br />
<tr><td>Time</td> <td>Block time.</td></tr><br />
<tr><td>Height</td> <td>Current block height</td></tr><br />
<tr><td>merkleProof</td> <td>Merkle branch of the block (list of hex strings)</td></tr><br />
</table><br />
<br />
===Example Block Header in the json format in getminingcandidate===<br />
{<br />
"id": "0d49aa74-0986-474f-a6eb-5913fbbbba02",<br />
"prevhash": "0000000000000000012811f570b3c0ff8cb93c44d707499dc2fcfdd611f38d93",<br />
"coinbaseValue": 1251906370,<br />
"version": 536870912,<br />
"nBits": "1802c73f",<br />
"time": 1585156824,<br />
"height": 627795,<br />
"merkleProof": [<br />
"f4cba40673d5573ca1aab2ee8fbd300102767561190cad7aa6211e04223ff6c3",<br />
"2d69511004ba72b60a10e6482491d689470b9f8527aff0f550c197d8a2446c45",<br />
"6eb9f4ef18f9669db60b21dc52292eba5318d684f7c476bb12da03b6d97d7c4f",<br />
"7a69a2fb7b132b36496501357d923ce584f913b37879a1930a10682d284bc2a9",<br />
"976089f04a73862fac14d2eec8b3f23aef9167f9804c40ade23c4f385cd92928",<br />
"73ec68c1692643e7edd22a34729f4bc8529fed48eca8ac0cd6e8b2929fb44064",<br />
"ee59af2b7964c1c0f48cd06b4e4e77c783711746030cc20d46a339f3d9993709",<br />
"6c0a33f1a1778ebec5d63172c55edb433ae365dbf7cd37bfa3535c864e9b9ea7",<br />
"d59744d6f3548adda90444a44eb16c56022554fdd4a0448632acd36058c96599",<br />
"6bd2d6dcdea8dd04345b7b706ba125ed73394be899355cb7b355d258eea20ff5",<br />
"3842aadab31a0e3bb5c484d58262f052afbe7f684935bf4d19ed614521e750e5",<br />
"91dec854c6f222b9be0cc78bd34b2405e98f34c6d2c7db8f84db6d85a83eb51e",<br />
"2b07dc2afdcafa3719c4ef440ef5c5f0c332efa174d23bbb72749680b36575a7"<br />
]<br />
}<br />
<br />
The Maestro software handles the call to and from the SV node to the ASIC miner. The ASIC miner then performs the hashing process to discover the next suitable block to be placed on the blockchain.</div>AlexGrahamhttps://wiki.bitcoinsv.io/index.php?title=Getminingcandidate&diff=2370Getminingcandidate2020-04-02T09:57:34Z<p>AlexGraham: /* Parameter table for the block header in getminingcandidate */</p>
<hr />
<div>''getminingcandidate'' and ''getblocktemplate'' are Remote Procedure call (RPC) programs. The RPC calls are located at an SV node and are currently managed and configured through Maestro software, though a number of software packages may perform these tasks.<br />
<br />
The miner can make a request with either of the above programs for block information:<br />
* The ''getblocktemplate'' returns a full block.<br />
* The ''getminingcandidate'' program returns the blockheader only for the mining candidate.<br />
The returned data is the block candidate data. It is expressed in the JSON language for data processing.<br />
<br />
''getminingcandidate'' returns a mining candidate or candidate block to the node which originally requested it. The node requests a block to mine. ''getminingcandidate'' is the program that obtains the block to mine.<br />
<br />
The ''getminingcandidate'' program or call is a replacement for ''getblocktemplate'' program. <br />
The replacement requirement arose from the need to process bigger blocks with Merkle tree paths in the block header. The Merkle tree proof in the block header allows for confirmation of transactions rather than reading the transactions as a whole. Consequently there can be more transactions within a block and more efficient external processing of the block.<br />
<br />
===Block header parameters in getminingcandidate===<br />
<table><br />
<tr><td>Parameter</td> <td>Description</td></tr><br />
<tr><td>Id</td> <td>Candidate identifier for submitminingsolution</td></tr><br />
<tr><td>Prevhash</td> <td>Hash of the previous block (hex string)</td></tr><br />
<tr><td>Coinbase</td> <td>Coinbase transaction (optional hex string encoded binary transaction)</td></tr><br />
<tr><td>Version</td> <td>Block version</td></tr><br />
<tr><td>nBits</td><br />
<td>Difficulty given as hex string.</td></tr><br />
<tr><td>Time</td> <td>Block time.</td></tr><br />
<tr><td>Height</td> <td>Current block height</td></tr><br />
<tr><td>merkleProof</td> <td>Merkle branch of the block (list of hex strings)</td></tr><br />
</table><br />
<br />
===Example Block Header in the json format in getminingcandidate===<br />
{<br />
"id": "0d49aa74-0986-474f-a6eb-5913fbbbba02",<br />
"prevhash": "0000000000000000012811f570b3c0ff8cb93c44d707499dc2fcfdd611f38d93",<br />
"coinbaseValue": 1251906370,<br />
"version": 536870912,<br />
"nBits": "1802c73f",<br />
"time": 1585156824,<br />
"height": 627795,<br />
"merkleProof": [<br />
"f4cba40673d5573ca1aab2ee8fbd300102767561190cad7aa6211e04223ff6c3",<br />
"2d69511004ba72b60a10e6482491d689470b9f8527aff0f550c197d8a2446c45",<br />
"6eb9f4ef18f9669db60b21dc52292eba5318d684f7c476bb12da03b6d97d7c4f",<br />
"7a69a2fb7b132b36496501357d923ce584f913b37879a1930a10682d284bc2a9",<br />
"976089f04a73862fac14d2eec8b3f23aef9167f9804c40ade23c4f385cd92928",<br />
"73ec68c1692643e7edd22a34729f4bc8529fed48eca8ac0cd6e8b2929fb44064",<br />
"ee59af2b7964c1c0f48cd06b4e4e77c783711746030cc20d46a339f3d9993709",<br />
"6c0a33f1a1778ebec5d63172c55edb433ae365dbf7cd37bfa3535c864e9b9ea7",<br />
"d59744d6f3548adda90444a44eb16c56022554fdd4a0448632acd36058c96599",<br />
"6bd2d6dcdea8dd04345b7b706ba125ed73394be899355cb7b355d258eea20ff5",<br />
"3842aadab31a0e3bb5c484d58262f052afbe7f684935bf4d19ed614521e750e5",<br />
"91dec854c6f222b9be0cc78bd34b2405e98f34c6d2c7db8f84db6d85a83eb51e",<br />
"2b07dc2afdcafa3719c4ef440ef5c5f0c332efa174d23bbb72749680b36575a7"<br />
]<br />
}<br />
<br />
The Maestro software handles the call to and from the SV node to the ASIC miner. The ASIC miner then performs the hashing process to discover the next suitable block to be placed on the blockchain.</div>AlexGraham