mirrors/bitcoin-s
1
0
Fork 0
mirror of https://github.com/bitcoin-s/bitcoin-s.git synced 2025-02-23 14:50:42 +01:00
Code Issues Projects Releases Packages Wiki Activity

Fix broken links in docs (#2439)

Browse source
This commit is contained in:
benthecarman 2020-12-29 14:34:37 -06:00 • committed by GitHub
parent 20af4a3cda
commit 76cdcb50f9
6 changed files with 13 additions and 10 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
docs/applications/cli.md
View file

@ -6,7 +6,7 @@ title: CLI
## Bitcoin-s command line interface
The [cli](../../app/cli/) project is meant to be a bitcoin-s command line interface (cli).
The [cli](/api/org/bitcoins/cli) project is meant to be a bitcoin-s command line interface (cli).
### Building the command line interface

2
docs/config/configuration.md
View file

@ -15,7 +15,7 @@ bitcoin-s, the values there take precedence over the ones found in our
Bitcoin-S data directory.
The resolved configuration gets parsed by
[`AppConfig`](api/org/bitcoins/db/AppConfig).
[`AppConfig`](/api/org/bitcoins/db/AppConfig).
`AppConfig` is an abstract class that's implemented by corresponding case
classes in the `wallet`, `chain` and `node` projects. Here's some examples of how to
construct a wallet configuration:

2
docs/crypto/sign.md
View file

@ -30,7 +30,7 @@ trait Sign {
```
The `ByteVector` that is input to the `signFunction` should be the hash that is output from [`TransactionSignatureSerializer`](/api/org/bitcoins/core/crypto/TransactionSignatureSerializer)'s `hashForSignature` method. Our in-memory [`ECKey`](/api/org/bitcoins/crypto/ECKey) types implement the `Sign` API.
The `ByteVector` that is input to the `signFunction` should be the hash that is output from [`TransactionSignatureSerializer`](/api/org/bitcoins/core/crypto/TransactionSignatureSerializer)'s `hashForSignature` method. Our in-memory [`BaseECKey`](/api/org/bitcoins/crypto/BaseECKey) types implement the `Sign` API.
If you wanted to implement a new `Sign` api for a hardware wallet, you can easily pass it into the `TxBuilder`/`Signer` classes to allow for you to use those devices to sign with Bitcoin-S.

9
docs/node/node.md
View file

@ -29,10 +29,11 @@ Let's make an easy one
Here is an example of constructing a neutrino node and registering a callback so you can be notified of an event.
To run the example, we need a bitcoind binary that has neutrino support. Unforunately bitcoin core has not merged neutrino
p2p network support yet ([pr here](https://github.com/bitcoin/bitcoin/pull/16442)) which means that we have built a custom binary and host it ourselves. You need
to make sure to run `sbt downloadBitcoind` and then look for the `bitcoind` binary with neutrino support in
`$HOME/.bitcoin-s/binaries/bitcoind/bitcoin-0.18.99/`. This binary is built from the open PR on bitcoin core.
To run the example, we need a bitcoind binary that has neutrino support.
Bitcoin Core only has p2p neutrino support as of version 0.21.0.
You will need to use a version of Bitcoin Core at least as old as 0.21.0.
For your node to be able to service these filters you will need set
`blockfilterindex=1` and `peerblockfilters=1` in your `bitcoin.conf` file.
```scala mdoc:invisible
import akka.actor.ActorSystem

2
docs/testkit/testkit.md
View file

@ -164,7 +164,7 @@ A generator is a piece of code that generates a random object for a data strucut
There is also a robust set of generators available in the [org.bitcoins.testkit.gen](../../testkit/src/main/scala/org/bitcoins/testkit/core/gen) package.
This allows you to integrate property based testing into your library and feel confident about implementing your application specific logic correctly.
You can see examples of us using these generators inside of testkit in our [Private Key test cases](../../core-test/src/test/scala/org/bitcoins/core/crypto/ECPrivateKeyTest.scala)
You can see examples of us using these generators inside of testkit in our [Private Key test cases](https://github.com/bitcoin-s/bitcoin-s/blob/master/crypto-test/src/test/scala/org/bitcoins/crypto/ECPrivateKeyTest.scala)
### Other modules

6
docs/wallet/wallet.md
View file

@ -17,9 +17,11 @@ ready. Use at your own risk, and without too much money depending on it.
The bitcoin-s wallet is a scalable way for individuals up to large bitcoin exchanges to safely and securely store their bitcoin in a scalable way.
All key interactions are delegated to the [key-manager](../key-manager/key-manager.md) which is a minimal dependecy library to store and use key material.
All key interactions are delegated to the [key-manager](../key-manager/key-manager.md) which is a minimal dependency library to store and use key material.
By default, we store the encrypted root key in `$HOME/.bitcoin-s/encrypted-bitcoin-s-seed.json`. This is the seed that is used for each of the wallets on each bitcoin network.
By default, we store the encrypted root key in `$HOME/.bitcoin-s/seeds/encrypted-bitcoin-s-seed.json`. This is the seed that is used for each of the wallets on each bitcoin network.
Multiple wallet seeds can be saved using the `bitcoin-s.wallet.walletName` config option.
You can read more in the [key manager docs](../key-manager/server-key-manager.md).
The wallet itself is used to manage the utxo life cycle, create transactions, and update wallet balances to show how much money you have the on a bitcoin network.