> For the complete documentation index, see [llms.txt](https://hub.bsvblockchain.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hub.bsvblockchain.org/wiki/bitcoin-script-and-opcodes/script/r-puzzles.md).

# R-Puzzles

An R-Puzzle is a new type of script that allows for the spending party to sign the input UTXO using any valid Bitcoin keypair. This can be used to sign Metanet node addresses or addresses that hold tokens, or be randomly generated.

1. k In an R-puzzle, a knowledge proof of a value called 'k\*\*' is used to allow coins to be spent.'k\*\*' is from the same mathematical set as Bitcoin Private Keys and must be known to the spender and used to generate'r\*\*', which is the x-coordinate of 'k\*\*' multiplied by the Generator point.'r\*\*' is extracted from the signature used in the transaction and tested against a hash stored in the ScriptPubKey. k-chains can be managed using the same deterministic techniques as Bitcoin keychains. Generating an ECDSA signature involves a few steps. Inputs to the signature:

```bash
#k value** 'k**'
#keypair** 'P1**' =** 'S1**' · G
#Message** 'm**'
Method:
#Calculate** R = k · G**
#Define **r = x-coordinate of R**
#Calculate **s = k-1(H(m) + S1 * r)mod n**
```

Signature is \*\*\*\* plus 5 bytes of formatting and a SIGHASH type

1. Signature Structure

| Data Structure              | Length | Data (hex)                                                     |
| --------------------------- | ------ | -------------------------------------------------------------- |
| Sequence Identifier         | 1      | 30                                                             |
| Length of Sequence          | 1      | 46                                                             |
| Integer Identifier          | 1      | 02                                                             |
| Byte-length of r            | 1      | 21                                                             |
| Needed when left(r, 1) > 7f | 1      | 00 NOTE: This byte is not always needed                        |
| r                           | 32     | e9d34347e597e8b335745c6f8353580f4cbdb4bcde2794ef7aab915d996642 |
| Integer identifier          | 1      | 02                                                             |
| Byte-length of s            | 1      | 21                                                             |
| Needed when left(s, 1) > 7f | 1      | 00                                                             |
| s                           | 32     | df2ccb52c7243c55bde34934bd55efbdac21c74a20bb7b438d1b6de3311f   |
| Sighash type                | 1      | 01                                                             |

When serialised the signature looks like this: *3046022100e9d34347e597e8b335745c6f8353580f4cbdb4bcde2794ef7aab915d996642022100df2ccb52c7243c55bde34934bd55efbdac21c74a20bb7b438d1b6de3311f01*

1. Extracting r The following piece of script pulls r out of the signature string by extracting, first the length of R, which is the 4th byte of the packet, and then using it to split r from the signature. **OP\_3 OP\_SPLIT OP\_NIP OP\_1 OP\_SPLIT OP\_SWAP OP\_SPLIT OP\_DROP**

| Stack | Script                                                              | Description                                   |
| ----- | ------------------------------------------------------------------- | --------------------------------------------- |
|       | OP\_3 OP\_SPLIT OP\_NIP OP\_1 OP\_SPLIT OP\_SWAP OP\_SPLIT OP\_DROP | scriptSig is loaded, signature on the stack   |
|       | OP\_NIP OP\_1 OP\_SPLIT OP\_SWAP OP\_SPLIT OP\_DROP                 | First 3 bytes of signature are split          |
|       | OP\_1 OP\_SPLIT OP\_SWAP OP\_SPLIT OP\_DROP                         | 3 byte data item is removed                   |
|       | OP\_SWAP OP\_SPLIT OP\_DROP                                         | 1 byte containing r length is split from sig' |
|       | OP\_SPLIT OP\_DROP                                                  | r Length parameter is moved to top of stack   |
|       | OP\_DROP                                                            | r is split from sig"                          |
|       |                                                                     | sig'"== is dropped from stack, leaving r      |

1. P2RPH Packaging this subscript into the following gives a Pay to R-Puzzle Hash script: **OP\_OVER** OP\_3 OP\_SPLIT OP\_NIP OP\_1 OP\_SPLIT OP\_SWAP OP\_SPLIT OP\_DROP **OP\_HASH160 OP\_EQUALVERIFY OP\_CHECKSIG**
2. Security Considerations
3. Protecting Private Keys If two signatures are published using the same *k*, then anyone who knows the value of *k* can derive the secret key used to create the signatures. To mitigate this issue, ensure that the same *k* value and private key are never used to create more than one signature.
4. Signature Forgeability Given an R-puzzle signature, a public key **P**, and a message **m**, a forger can create a different message **m**', and calculate a new public key **P**' such that:

```bash
P' = P + [ r -1 [ H(m) - H(m') ] ] · G**
```

Then signature is a valid signature on message m' with respect to the public key **P**'. Note that, the forger does not know, and does not need to know, the private key corresponding to **P**' in this forgery. When implementing R-puzzle, it is important to take this into account. One way to mitigate this is to require another signature, to prove that the signer knows the private key corresponding to the public key used in the R-puzzle. That is, two signatures in the unlocking script, **and**, and one public key **P**. It is important to have **r** not equal **r**' for the first security consideration. Both signatures should be valid subject to the same public key **P**. This solution would propose the following input solution:

* r>\*\* which spends outputs with the following script: **OP\_DUP OP\_3 OP\_SPLIT OP\_NIP OP\_1 OP\_SPLIT OP\_SWAP OP\_SPLIT OP\_DROP OP\_HASH160 OP\_EQUALVERIFY OP\_OVER OP\_CHECKSIGVERIFY OP\_CHECKSIG** =R-Puzzle Use Cases=
* Delegation of authority
* Tokens
* Multi-signature schemes (with advanced scripting)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://hub.bsvblockchain.org/wiki/bitcoin-script-and-opcodes/script/r-puzzles.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.