mirror of
https://github.com/bitcoin-s/bitcoin-s.git
synced 2025-01-19 05:43:51 +01:00
Added Tables of Content to the bigger docs using doctoc, updated signing-transactions.md (#1319)
This commit is contained in:
parent
b3250dcfba
commit
8ffd2d11ae
@ -179,6 +179,37 @@ def build(
|
||||
scriptWitness: Option[ScriptWitness]): Gen[BitcoinUTXOSpendingInfoFull] = ???
|
||||
```
|
||||
|
||||
<!-- START doctoc generated TOC please keep comment here to allow auto update -->
|
||||
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
|
||||
<!-- END doctoc -->
|
||||
|
||||
- [Adding a New ScriptPubKey Type](#adding-a-new-scriptpubkey-type)
|
||||
- [Step 0: Design Philosophy](#step-0-design-philosophy)
|
||||
- [Step 1: Create a New ScriptPubKey Trait](#step-1-create-a-new-scriptpubkey-trait)
|
||||
- [Step 2: Create Companion Object](#step-2-create-companion-object)
|
||||
- [Step 3: Add to Relevant fromAsm Methods](#step-3-add-to-relevant-fromasm-methods)
|
||||
- [Step 4: Create a ScriptSignature If Necessary](#step-4-create-a-scriptsignature-if-necessary)
|
||||
- [Step 5: Add to ScriptSignature.fromAsm If Applicable](#step-5-add-to-scriptsignaturefromasm-if-applicable)
|
||||
- [Step 6: Create Relevant BitcoinUTXOSpendingInfo](#step-6-create-relevant-bitcoinutxospendinginfo)
|
||||
- [Non-Nested Single-Key Spending Info](#non-nested-single-key-spending-info)
|
||||
- [Non-Nested Multi-Key Spending Info](#non-nested-multi-key-spending-info)
|
||||
- [Nested Spending Info](#nested-spending-info)
|
||||
- [Step 7: Add to Relevant Apply Methods](#step-7-add-to-relevant-apply-methods)
|
||||
- [Step 8: Create a Signer](#step-8-create-a-signer)
|
||||
- [Non-Nested Single-Key Spending Info](#non-nested-single-key-spending-info-1)
|
||||
- [Non-Nested Multi-Key Spending Info](#non-nested-multi-key-spending-info-1)
|
||||
- [Nested Spending Info](#nested-spending-info-1)
|
||||
- [Step 9: Add to BitcoinSigner.sign](#step-9-add-to-bitcoinsignersign)
|
||||
- [Step 10: Add to ScriptGenerators](#step-10-add-to-scriptgenerators)
|
||||
- [ScriptPubKey Generator](#scriptpubkey-generator)
|
||||
- [ScriptSignature Generator](#scriptsignature-generator)
|
||||
- [ScriptPubKey with Paired ScriptSignature Generator](#scriptpubkey-with-paired-scriptsignature-generator)
|
||||
- [Step 11: Add to CreditingTxGen](#step-11-add-to-creditingtxgen)
|
||||
- [Step 12: Fix all Non-Exhaustive Matches](#step-12-fix-all-non-exhaustive-matches)
|
||||
- [Step 13: Run tests and debug](#step-13-run-tests-and-debug)
|
||||
|
||||
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
||||
|
||||
# Adding a New ScriptPubKey Type
|
||||
|
||||
In this document, we will describe how to add new script implementations and types in Bitcoin-S. We will use the following script template example which we have called P2PK with Timeout to illustrate the process:
|
||||
|
@ -7,6 +7,6 @@ title: Signing Transactions
|
||||
|
||||
There are two kinds of transaction signing in Bitcoin-S, as defined in `Signer.scala`: Single Signing and Full Signing.
|
||||
|
||||
Single signing, which is implemented by the subtypes of `SingleSigner`, consists of using a single `ECPrivateKey` (or other [Sign implementation](sign.md)) to generate a `PartialSignature` of the given transaction. This consists of an `ECDigitalSignature` and a `ECPublicKey`. This is useful any time you have a single private key and wish to get a single `ECDigitalSignature` for that private key as is the case when using [Partially Signed Bitcoin Transactions](psbts.md). In order to call `signSingle` on any instance of `SingleSigner`, you must have access to the unsigned transaction, as well as a `BitcoinUTXOSpendingInfoSingle`, which encapsulates all the information needed to sign with a single key. Note that if the unsigned transaction has signatures on it, they will be ignored.
|
||||
Single signing, which is implemented as a simple function in `BitcoinSigner`, consists of using a single `ECPrivateKey` (or other [Sign implementation](sign.md)) to generate a `PartialSignature` of the given transaction. This consists of an `ECDigitalSignature` and a `ECPublicKey`. This is useful any time you have a single private key and wish to get a single `ECDigitalSignature` for that private key as is the case when using [Partially Signed Bitcoin Transactions](psbts.md). In order to call `signSingle`, you must have access to the unsigned transaction, as well as a `BitcoinUTXOSpendingInfoSingle`, which encapsulates all the information needed to sign with a single key. Note that if the unsigned transaction has signatures on it, they will be ignored.
|
||||
|
||||
Full signing, which is implemented by the subtypes of `FullSigner`, consists of using any number of `ECPrivateKey`s (or other [Sign implementations](sign.md)) to generate a fully signed, `TxSigComponent` for a given transaction. In order to call `sign` on any instance of `FullSigner`, you must have access to the unsigned transaction, as well as a `BitcoinUTXOSpendingInfo`, which encapsulates all the information needed to sign with any number of keys. Note that the unsigned transaction can have signatures on it, just not on the input being signed. Specifically, a fully signed `TxSigComponent` has a member called `input` which will contain the fully signed `TransactionInput` as well as `scriptSignature` which contains the `ScriptSignature` that was just generated. Additionally, `TxSigComponent` has a member called `transaction` which returns a transaction which has all inputs of the input unsigned transaction except for it uses the new input that was just generated by the call to `sign` instead of an `EmptyScriptSignature`.
|
||||
Full signing, which is implemented by the subtypes of `Signer`, consists of using any number of `ECPrivateKey`s (or other [Sign implementations](sign.md)) to generate a fully signed, `TxSigComponent` for a given transaction. In order to call `sign` on any instance of `Signer`, you must have access to the unsigned transaction, as well as a `BitcoinUTXOSpendingInfo`, which encapsulates all the information needed to sign with any number of keys. Note that the unsigned transaction can have signatures on it, just not on the input being signed. Specifically, a fully signed `TxSigComponent` has a member called `input` which will contain the fully signed `TransactionInput` as well as `scriptSignature` which contains the `ScriptSignature` that was just generated. Additionally, `TxSigComponent` has a member called `transaction` which returns a transaction which has all inputs of the input unsigned transaction except for it uses the new input that was just generated by the call to `sign` instead of an `EmptyScriptSignature`.
|
@ -5,6 +5,19 @@ title: Getting Bitcoin-S installed on your machine
|
||||
|
||||
## Getting Setup With Bitcoin-S
|
||||
|
||||
<!-- START doctoc generated TOC please keep comment here to allow auto update -->
|
||||
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
|
||||
<!-- END doctoc -->
|
||||
|
||||
- [Step 1: Java and Scala](#step-1-java-and-scala)
|
||||
- [Step 2: Bitcoin-S Repository](#step-2-bitcoin-s-repository)
|
||||
- [Step 3: Configuration](#step-3-configuration)
|
||||
- [Step 4 (Optional): Discreet Log Contract Branch](#step-4-optional-discreet-log-contract-branch)
|
||||
- [Step 5: Setting Up A Bitcoin-S Server (Neutrino Node)](#step-5-setting-up-a-bitcoin-s-server-neutrino-node)
|
||||
- [Step 6 (Optional): Moving To Testnet](#step-6-optional-moving-to-testnet)
|
||||
|
||||
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
||||
|
||||
## Step 1: Java and Scala
|
||||
|
||||
The first step in getting setup will be getting the [Java Development Kit](https://www.oracle.com/java/technologies/javase-downloads.html) (JDK) installed on your machine. Bitcoin-S works best with Java 8 but _should_ also work with Java 11 and Java 13.
|
||||
|
Loading…
Reference in New Issue
Block a user