Difference between revisions of "Complex Script Options"
AlexGraham (talk | contribs) |
|||
| (30 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. | Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity. | ||
| − | A difference occurs in Bitcoin SV between ‘Standard’ and | + | A difference occurs in Bitcoin SV between ‘Standard’ and 'customized' (previously known as‘Non-Standard’) scripts for transaction inputs and outputs. |
| − | == | + | The 'customized' scripts allow for complex scripts to be added to transactions containing additional functionality for the locking and redeeming process. |
| + | |||
| + | ==Standard scripts== | ||
There are 5 standard scripts for Bitcoin SV (Referred to in WP1321) | There are 5 standard scripts for Bitcoin SV (Referred to in WP1321) | ||
| Line 9: | Line 11: | ||
* P2PKH – Pay to Public Key Hash | * P2PKH – Pay to Public Key Hash | ||
* P2MS – Pay to MultiSignature | * P2MS – Pay to MultiSignature | ||
| − | * P2SH – Pay to Script Hash (deprecated with | + | * P2SH – Pay to Script Hash (deprecated with the Genesis upgrade after Feb 4th 2020) |
* OP_RETURN – opcode able to contain data | * OP_RETURN – opcode able to contain data | ||
These scripts have been available as locking and redeeming scripts in Bitcoin. | These scripts have been available as locking and redeeming scripts in Bitcoin. | ||
| − | == | + | ===Bitcoin SV Node Capability=== |
| − | + | The [[Genesis upgrade]] introduced 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 enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities. | |
| − | + | Script's flexible nature allows outputs to be created that provide conditionality, enhanced security and computational possibilities. | |
| − | |||
| − | + | The use of customised scripts can extend BSV to provide tailored services for wallets, subnets and overlays in the BSV network. | |
| − | + | ===Customised Scripts under development=== | |
| − | |||
| − | |||
| − | Currently, there are | + | Currently, there are three customized scripts under development as defined in WP1321. |
| − | * R Puzzle | + | * R Puzzle - use of the r component of a digital signature |
| − | * Rabin Signature | + | * Rabin Signature - use of Rabin addresses and signatures (see Rabin Signatures) |
| − | * Multi Signature Accumulator | + | * Multi Signature Accumulator - manage multi signature scenarios through conditional scripting insrtuctions. |
| − | Non-standard or customised scripts need to be declared. A registration process is involved. A link with a specific | + | 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. |
| − | ==Other | + | ==Other customised declarations can include:== |
* Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures) | * Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures) | ||
Where authenticating or verification information can be placed within a transaction. | Where authenticating or verification information can be placed within a transaction. | ||
| − | * Use of | + | * Use of customised Address Generation |
| − | The creation of payment addresses within a | + | The creation of payment addresses as the transaction output within a script that is non-standard or customised (See WP1322). |
Latest revision as of 00:12, 19 November 2020
Transactions are mostly input and output to a number of standard scripts that cover 99% of transactional activity.
A difference occurs in Bitcoin SV between ‘Standard’ and 'customized' (previously known as‘Non-Standard’) scripts for transaction inputs and outputs.
The 'customized' scripts allow for complex scripts to be added to transactions containing additional functionality for the locking and redeeming process.
Standard scripts
There are 5 standard scripts for Bitcoin SV (Referred to in WP1321)
- P2PK – Pay to Public Key
- P2PKH – Pay to Public Key Hash
- P2MS – Pay to MultiSignature
- P2SH – Pay to Script Hash (deprecated with the Genesis upgrade after Feb 4th 2020)
- OP_RETURN – opcode able to contain data
These scripts have been available as locking and redeeming scripts in Bitcoin.
Bitcoin SV Node Capability
The Genesis upgrade introduced 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 enable the Bitcoin SV network to support a range of complex spending conditions and computational capabilities.
Script's flexible nature allows outputs to be created that provide conditionality, enhanced security and computational possibilities.
The use of customised scripts can extend BSV to provide tailored services for wallets, subnets and overlays in the BSV network.
Customised Scripts under development
Currently, there are three customized scripts under development as defined in WP1321.
- R Puzzle - use of the r component of a digital signature
- Rabin Signature - use of Rabin addresses and signatures (see Rabin Signatures)
- Multi Signature Accumulator - manage multi signature scenarios through conditional scripting insrtuctions.
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.
Other customised declarations can include:
- Public Key Infrastructure (Root Authority, Certificate Issuer, Certificates, Signatures)
Where authenticating or verification information can be placed within a transaction.
- Use of customised Address Generation
The creation of payment addresses as the transaction output within a script that is non-standard or customised (See WP1322).