Core/grin
0
0
Fork 0
mirror of https://github.com/mimblewimble/grin.git synced 2025-01-21 03:21:08 +03:00
Code Issues Projects Releases Packages Wiki Activity Actions

update docs to reflect new file layout (#1444)

Browse source
This commit is contained in:
Yeastplume 2018-08-30 11:47:04 +01:00 committed by GitHub
parent 1ded3f3972
commit 11d24fe0c1
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
7 changed files with 84 additions and 336 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

35
doc/build.md
View file

@ -47,12 +47,20 @@ A successful build gets you:
- `target/release/grin` - the main grin binary
Grin is still sensitive to the directory from which it's run. Make sure you
always run it within a directory that contains a `grin.toml` configuration and
stay consistent as to where it's run from.
All data, configuration and log files created and used by grin are located in the hidden
`~/.grin` directory (under your user home directory) by default. You can modify all configuration
values by editing the file `~/.grin/grin-server.toml`.
With the included `grin.toml` unchanged, if you execute `cargo run` you get a
`.grin` subfolder that grin starts filling up with blockchain data.
It is also possible to have grin create its data files in the current directory. To do this, run
```
grin server config
```
Which will generate a `grin-server.toml` file in the current directory, pre-configured to use
the current directory for all of its data. Running grin from a directory that contains a
`grin-server.toml` file will use the values in that file instead of the default
`~/.grin/grin-server.toml`.
While testing, put the grin binary on your path like this:
@ -66,19 +74,12 @@ You can then run `grin` directly (try `grin help` for more options).
# Configuration
Grin attempts to run with sensible defaults, and can be further configured via
the `grin.toml` file. You should always ensure that this file is available to grin.
The supplied `grin.toml` contains inline documentation on all configuration
options, and should be the first point of reference for all options.
The `grin.toml` file can placed in one of several locations, using the first one it finds:
1. The current working directory
2. In the directory that holds the grin executable
3. {USER_HOME}/.grin
the `grin-server.toml` file. This file is generated by grin on its first run, and
contains documentation on each available option.
While it's recommended that you perform all grin server configuration via
`grin.toml`, it's also possible to supply command line switches to grin that
override any settings in the `grin.toml` file.
`grin-server.toml`, it's also possible to supply command line switches to grin that
override any settings in the file.
For help on grin commands and their switches, try:
@ -105,7 +106,7 @@ troubleshooting, etc.
# or in background
docker run -it -d -v grin:/usr/src/grin grin
If you decide to use a persistent storage (e.g. ```-v grin:/usr/src/grin```) you will need grin.toml configuration file in it.
If you decide to use a persistent storage (e.g. ```-v grin:/usr/src/grin```) you will need grin-server.toml configuration file in it.
### Cross-platform builds

2
doc/code_structure.md
View file

@ -48,7 +48,7 @@ After checking out grin, building and using, these are the folders you'll have:
Low-level rust utilities.
- wallet
Simple command line wallet implementation. Will generate:
- wallet.dat - your "outputs", that once confirmed and matured, can be spent with the [`grin wallet send`](wallet.md) command. (locally created, _not_ in git)
- wallet_data - a database storing your "outputs", that once confirmed and matured, can be spent with the [`grin wallet send`](wallet.md) command. (locally created, _not_ in git)
- wallet.seed - your secret wallet seed. (locally created, _not_ in git)
## grin dependencies

134
doc/local_net.md
View file

@ -1,134 +0,0 @@
# Grin Local Testing Network
## Basic Execution
For a basic example simulating a single node network, create a directory called `node1` and change your working directory to it. You'll use this directory to run a wallet and create a new blockchain via a server running in mining mode.
You'll need a config file - the easiest is to copy over the `grin.toml` file from the root grin directory into the `node1` directory you just made.
Before running your mining server, a wallet server needs to be set up and listening so that the mining server knows where to send mining rewards. This can all be configured in the `grin.toml` file. We will use the defaults, with the wallet listener automatically started on port 13415.
See [wallet](wallet.md) for more info on the various Grin wallet commands and options.
Next enable the test miner with the following change to your `grin.toml` file:
#Whether to run a test miner. This is only for developer testing (chaintype
#usertesting) at cuckoo 16, and will only mine into the default wallet port.
run_test_miner = true
Also make sure to uncomment the following line, or else the mined coins will be burned:
test_miner_wallet_url = "http://127.0.0.1:13415"
Now, start up the grin server:
node1$ grin server run
This creates a new `.grin` database directory in the current directory, and begins mining new blocks (with no transactions, for now). Note this starts two services listening on two default ports:
* **13414** for the peer-to-peer (P2P) service which keeps all nodes synchronized
* **13413** for the Rest API service used to verify transactions and post new transactions to the pool (for example)
These ports can be configured via command line switches, or via a `grin.toml` file in the working directory.
Let the mining server find a few blocks, then stop (just ctrl-c) the grin server. You'll notice grin has created a database directory (.grin) in which the blockchain and peer data is stored. There should also be a wallet.dat file in the current directory, which contains a few coinbase mining rewards created each time the server mines a new block.
Alternatively, if mining at Cuckoo 30 is desired, you can utilize the `grin-miner` instead of the test miner (Cuckoo 16). After starting the grin server, open another terminal, navigate to the `grin-miner` directory, and start up the grin miner (we will again use the default configuration):
grin-miner$ grin-miner
## Advanced Example
The following outlines a more advanced example simulating a multi-server network with transactions being posted.
For the sake of example, we're going to run three nodes with varying setups. Create two more directories beside your `node1` directory, called `node2` and `node3` and copy over the `grin.toml` file from the root into each directory.
There are a few configurations we will change for all three nodes:
#UserTesting - For regular user testing (cuckoo 16)
chain_type = "UserTesting"
#flag whether stratum server is enabled
enable_stratum_server = false
If you want to clear data from your previous run (or anytime you want to reset the blockchain and all peer data) just delete the wallet.dat file in the `node1` directory and run rm -rf .grin to remove grin's database.
### Node 1: Genesis and Miner
As before, node 1 will create the blockchain and begin mining. As we'll be running many servers from the same machine, we'll configure specific ports for other servers to explicitly connect to.
First, we'll edit our `grin.toml` file to receive rewards on port 15000.
# Port for wallet listener
api_listen_port = 15000
# Where the wallet should find a running node
check_node_api_http_addr = "http://localhost:10001"
We will also turn on the test miner and designate a wallet url for mined coinbase rewards. Again in the `grin.toml` change the following:
#Whether to run a test miner. This is only for developer testing (chaintype
#usertesting) at cuckoo 16, and will only mine into the default wallet port.
run_test_miner = true
#test miner wallet URL (burns if this doesn't exist)
test_miner_wallet_url = "http://127.0.0.1:15000"
#the wallet receiver to which coinbase rewards will be sent
wallet_listener_url = "http://127.0.0.1:15000"
Then we start node 1 mining with its P2P server bound to port 10000 and its api server at 10001.
node1$ grin server -p 10000 -a 10001 run
### Node 2: Regular Node (not mining)
We'll set up Node 2 as a simple validating node (i.e. it won't mine but we'll pass in the address of node 1 as a seed). Therefore, we can turn off the wallet listener by making the following change to `grin.toml` (on by default):
#Whether to run the wallet listener with the server by default
run_wallet_listener = false
Node 2 will join the network founded by node 1 and then sync its blockchain and peer data. In a new terminal, tell node 2 to run a server using node 1's P2P address as a seed. Node 2's P2P server will run on port 20000 and its API server will run on port 20001.
node2$ grin server -s "127.0.0.1:10000" -p 20000 -a 20001 run
Node 2 will then sync, processing and validating new blocks that node 1 may find.
### Node 3: Regular node running wallet listener
Similar to Node 2, we'll set up node 3 as a non-mining node seeded with node 2 (node 1 could also be used). We'll also run another wallet in listener mode on this node and specify the port as we did for node 1:
# Port for wallet listener
api_listen_port = 35000
# Where the wallet should find a running node
check_node_api_http_addr = "http://localhost:30001"
We'll specify the port as we did for node 1 and start up node 3:
node3$ grin server -s "127.0.0.1:20000" -p 30000 -a 30001 run
Node 3 is now running it's P2P service on port 30000 and its API server on 30001. You should be able to see it syncing its blockchain and peer data with nodes 1 and 2.
In contrast to other blockchains, a feature of a MimbleWimble is that a transaction cannot just be directly posted to the blockchain. It first needs to be sent from the sender to the receiver,
who will add a blinding factor before posting it to the blockchain. The above command tells the wallet server to listen for transactions on port 35000, and, after applying it's own blinding factor to the transaction, forward them on to the listening API server on node 1. (NB: we should theoretically be able to post transactions to node 3 or 2, but for some reason transactions posted to peers don't seem to propagate properly at present)
### Send grins from node 1 to node 3
With all of your servers happily running and your terminals scrolling away, let's spend some of the coins mined in node 1 by sending them to node 3's listening wallet.
In yet another terminal in node 1's directory, create a new partial transaction spending 10 coins and send them on to node 3's wallet listener. We'll also specify that we'll
use node 2's API listener to validate our transaction inputs before sending:
node1$ grin wallet -a "http://127.0.0.1:20001" send 10 -d "http://127.0.0.1:35000"
Your terminal windows should all light up now. Node 1 will check its inputs against node 2, and then send a partial transaction to node 3's wallet listener. Node 3 has been configured to
send signed and finalized transactions to the api listener on node 1, which should then add the transaction to the next block and validate it via mining.
To check how many confirmations your transaction has received, change back to the terminal running node 3 and type the following:
node3$ grin wallet -a "http://127.0.0.1:30001" outputs
You can feel free to try any number of permutations or combinations of the above, just note that grin is very new and under active development, so your mileage may vary. You can also simplify these command line switches by further editing the `grin.toml` file in each server's directory.

143
doc/rangeproofs.md
View file

@ -1,143 +0,0 @@
# Range Proofs - A Primer
This document is intended to give the reader a high level conceptual overview of what range proofs are and how they're constructed. It's assumed that the reader has read and is familiar with more basic MimbleWimble concepts, in particular Pedersen commitments and MimbleWimble outputs as outlined in the [Introduction to MimbleWimble](intro.md).
While understanding range proofs is not 100% necessary in order to understand MimbleWimble, a few points about them should be noted, even if just from a 'black box' perspective:
* Range Proofs are used to prove, with zero-knowledge (i.e. without revealing the amount or the blinding factor), that the value committed to in a given commitment falls within a certain range. The inclusion of a range proof in a MimbleWimble commitment demonstrates that the amount committed to is positive, and therefore doesn't create any new money.
* The blinding factor used to create an output on the block chain must be known in order to create a valid range proof. The existence of a valid range proof therefore also proves that the signer has knowledge of the blinding factor and therefore all of the private keys used in the creation of a new output.
The following outlines a simple example, which builds up the concept of a range proof and demonstrates why the blinding factor in an output must be known beforehand in order to create one.
Note that this document is derived from Greg Maxwell's [Confidential Transactions Paper](https://www.elementsproject.org/elements/confidential-transactions/investigation.html), in which the concept of a range proof originated. This document simply further illustrates the concepts found in that paper. [Further reading](#further-reading) is provided at the end of the document.
## Signing an Output
Say I have this output:
```
C = (113G + 20H)
```
And I want to prove that the amount I'm committing to (20) is positive, and in within the range for my coin.
Firstly, remember a commitment actually appears in the UTXO set as a large, mostly unintelligible number, for example:
```
C = 2342384723497239482384234....
```
This number is made up of two public keys, one that only exists as a point on curve G, and one that only exists on curve H. (More specifically, the key 113G is only usable for signature operations when using generator G as a parameter to the ECDSA algorithm, and the key 20H can only create a signature when using the generator H as a parameter). In reality, the private key 113 is a very large 256 bit integer while 20 is a relatively tiny value that represents a usable currency amount, so the large number that appears on the blockchain is made up of something that looks more like:
```
C = (32849234923..74932897423987G + 20H)
```
Our commitments are of the form (bG + vH), where b is a blinding factor and v is the value. It's important to note that bG is a valid public key on G, and vH is a valid public key on H, but the large number created by adding these two values together is more or less meaningless in the context of either G or H. The sum of these two values, for any possible values of b or v, will not create a public key that's valid using either generator G or H.
## Commitments to Zero
However, it is indeed possible for the total commitment value to represent a valid public key on G or H: if either b is 0 or v is 0. For example:
```
C = (113G + 0H) = 113G -> Is a point on G
```
Since we're using vH to represent our currency values, it follows that if the output C can be used as a public key to verify a signature against the blinding factor generator G, the value v cannot be anything other than zero. Therefore if I can provide a signature for an output that is a point on G and can be verified using the commitment as a public key, I've demonstrated that I knew the blinding factor (which is the private key that created the signature), and that the amount committed to must be zero.
## Commitments to Any Number
Of course, that's not very useful in a blockchain context, as amounts will never be zero. Let's continue and consider the case where the value is 1, i.e:
```
C = (113G + 1H) -> Not a point on G or H
```
Since C is not a point on G or H, on its own this output can't be signed for. However, I can easily prove it's a commitment to 1 without revealing the blinding factor by simply subtracting 1*H from it, and observing that the result is a valid key on G.
Consider:
```
C = 113G + 1H
C' = 113G + 1H - 1H = 113G
```
As long as a signature is provided that can be verified using C' as the public key, C' is a point on G and therefore, without the verifier necessarily knowing the value 113G beforehand, it's been demonstrated that that C is a commitment to 1.
This works for any pair of numbers, not just for 1. For any value I can pick for v, I can construct a similar proof that demonstrates C is a commitment to that value without revealing the blinding factor.
## Ring Signatures
Of course, the problem here is that I'm also revealing the amount. What we need now is a way to prove that the value v in the vH value of a commitment lies within a certain range (that is, greater than zero but less than the maximum currency value), without being able to determine either the blinding factor or the amount.
To demonstrate how we do this, let's assume that the only valid values for v that we could have in our currency are zero and one. Therefore, to show that the value we've committed to is positive it's sufficient to demonstrate that either v is zero, or that v is one. And we need to do this without actually revealing which value it is.
In order to do this, we need another type of signature called a [ring signature](https://en.wikipedia.org/wiki/Ring_signature). For our purposes, a ring signature is a signature scheme where there are multiple public keys, and the signature proves that the signer knew the corresponding private key for at least one (but not necessarily more) of the public keys.
So, using a ring signature, it's possible to create what's called an OR proof that demonstrates C is either a commitment to zero OR a commitment to one as follows:
As before, take an output commitment C and compute C':
```
C' = C - 1H
```
Following from the example:
```
C' = 113G + 1H - 1H
```
If a ring signature is provided over {C, C'}, it proves that the signer knows the private key for either C or C', but not both. If C was a commitment to zero, the signer was able to use C to create the ring signature. If C was a commitment to one, the signer was able to use C' to create the ring signature. If C is neither a commitment to one or zero, the signer would not have been able to create the ring signature at all. However, no matter how the ring signature was created, the private key that was used to create it was not revealed. If a ring signature exists at all, C must have been either a commitment to zero, OR a commitment to one.
As before, this works for all values of v I can pick... I can choose v=256 and construct a similar ring signature that proves v was zero OR that v was 256. In this case, the verifier just needs to subtract 256H from C and verify the ring signature used to produce the resulting C'.
## Confidential Proofs
Now that we have this construct, it's possible to use another less direct method of proving that the value v lies in a certain range using the established additive properties of commitments. To demonstrate, consider the original commitment in our example:
```
C = 113G + 20H
```
Now let's break up this commitment into parts while being careful to break the blinding factor into something that sums to the original 113 value:
```
C1 + C2 + C3 + C4 + C5 = C
or
(24G + 1H) + (25G + 2H) + (26G + 4H) + (27G + 8H) + (11G + 16H) = C
```
Obviously, this summation is not necessarily true because 1+2+4+8+16 is not equal to 20. But note that the values for v have been deliberately chosen to be powers of two. Therefore, I can use them to create the binary representation of any number up to 2<sup>5</sup> so long as I assume that some of the values actually chosen for v won't be what's shown above, but 0 instead. And a method of proving whether a commitment is a commitment to 0 OR a particular value has just been demonstrated above.
So all I need to do is provide a ring signature over each commitment value C1..C5, which demonstrates that:
```
C1 is 1 OR 0 C2 is 2 OR 0 C3 is 4 OR 0 C4 is 8 OR 0 C5 is 16 OR 0
```
Therefore, so long as my committed value can be represented in less than 2<sup>5</sup> bits, I've proven that its value must lie somewhere between 0 and 2<sup>5</sup> without revealing anything further about its value.
## Conclusion
This is the essence of a Range Proof, used to demonstrate that commitments are positive values and that the signer has knowledge of all of the private keys used in the commitment. Note that I absolutely needed to know the private key used as a blinding factor in the output, as I needed to choose blinding values for C1 though C5 that add up to the original private key. However, I can provide the values C1..C5 to a verifier, and a verifier can use them to verify the range proof and add them up to ensure the values in the range proof equal the original commitment. However, the verifier can't break down C1..C5 into their constituent bG+vH components, and thus has no way of determining what the original private key 113 was.
## Further Details
Note that for efficiency reasons, the range proofs used in Grin actually build up numbers in base 4 instead of base 2. However, binary is easier for the sake of the example, as binary is more familiar to most people than base 4 arithmetic.
## FAQ
Q: If I have an output `C=bG+vH` on the blockchain, and there is only a finite number of usable amounts for vH, why can't I reveal the amount by just subtracting each possible vH value from C until I get a value that can be used to create a signature on H?
A: Pedersen Commitments are information-theoretically private. For any value of v I choose in `bG+vH`, I can choose a value of b that will make the entire commitment sum to C. Even given infinite computing power, it remains impossible to determine what the intended value of v in a given commitment is without knowing the blinding factor.
# Further Reading
[Confidential Transactions](https://www.elementsproject.org/elements/confidential-transactions/investigation.html) - The original paper with further technical details on internal representation
[Confidential Assets](https://blockstream.com/bitcoin17-final41.pdf) - A more formalised version of the above with further improvements

4
doc/table_of_contents.md
View file

@ -14,14 +14,12 @@
- [merkle](merkle.md) - Technical explanation of grin's favorite kind of merkle trees
- [merkle_proof graph](merkle_proof/merkle_proof.png) - Example merkle proof with pruning applied
- [pruning](pruning.md) - Technical explanation of pruning
- [rangeproofs](rangeproofs.md) - Technical explanation of range proofs
- [stratum](stratum.md) - Technical explanation of Grin Stratum RPC protocol
- [transaction UML](transaction/aggregating transaction without lock_height) - UML of an interactive transaction
## Build and use
- [build](build.md) - Explaining how to build and run the Grin binaries
- [usage](usage.md) - Explaining how to use grin in Testnet1
- [local_net](local_net.md) - Technical explanation of how to test Grin locally, simulating several peers, for full integration testing and network simulations
- [usage](usage.md) - Explaining how to use grin in Testnet3
- [wallet](wallet/usage.md) - Explains the wallet design and `grin wallet` sub-commands
# External (wiki)

96
doc/wallet/usage.md
View file

@ -2,26 +2,40 @@
## Wallet Files
A Grin wallet maintains its state in an LMDB database, with the master seed stored in a separate file.
A wallet directory should contain:
A Grin wallet maintains its state in an LMDB database, with the master seed stored in a separate file.
When creating a new wallet, the file structure should be:
```
wallet.seed # *** passphrase protected seed file (keep this private) ***
wallet_data # The lmdb data directory in which wallet outputs and transaction information are stored
~/[Wallet Directory]
-wallet_data/
-db/
-/lmdb
wallet.seed
grin-wallet.toml
grin-wallet.log
```
By default Grin will look for these in the current working directory.
* `grin-wallet.toml` contains configuration information for the wallet. You can modify values within
to change ports, the address of your grin node, or logging values.
* `wallet_data/wallet.seed` is your master seed file. You must back this file up somewhere in order to
be able to recover or restore your wallet (along with its password, if given).
##### Data Directory
By default grin will create all wallet files in the hidden directory `.grin` under your home directory (i.e. `~/.grin`).
You can also create and use a wallet with data files in the current directory, as explained in the `grin wallet init`
command below.
### Logging + Output
Logging configuration for the wallet is read from `grin.toml`. To modify the wallet's logging output, copy `grin.toml` from the main grin directory
into the current wallet directory, and modify logging parameters. (Only parameters relevant to the wallet will be read.)
Logging configuration for the wallet is read from `grin-wallet.toml`.
### Switches common to all wallet commands
##### Grin Node Address
The wallet generally needs to talk to a running grin node in order to remain up-to-date and verify its contents. By default, the wallet
tries to contact a node at `127.0.0.1:13413`. To change this, provide the `-a` switch to the wallet command, e.g.:
tries to contact a node at `127.0.0.1:13413`. To change this, modify the value in the wallet's `grin_wallet.toml` file. Alternatively,
you can provide the `-a` switch to the wallet command, e.g.:
```
[host]$ grin wallet -a "http://192.168.0.2:1341" info
@ -33,22 +47,13 @@ and the results verified against the latest chain information.
##### Password
All keys generated by your wallet are combinations of the master seed + a password. If no password is provided, it's assumed this
password is blank. If you do provide a password, all operations will use the seed+password and you will need to password to view or
password is blank. If you do provide a password, all operations will use the seed+password and you will need the password to view or
spend any generated outputs. The password is specified with `-p`
```
[host]$ grin wallet -p mypassword info
```
##### Data Directory
You can override the directory to use for wallet files with the `-d` flag, e.g:
```
[host]$ grin wallet -d ./path/to/other/dir info
```
## Basic Wallet Commands
`grin wallet --help` will display usage info and all flags.
@ -56,17 +61,24 @@ You can override the directory to use for wallet files with the `-d` flag, e.g:
### init
Before using a wallet a new seed file `wallet.seed` and storage database needs to be generated via `grin wallet init` -
Before using a wallet a new `grin-wallet.toml` configuration file, seed file `wallet.seed` and storage database need
to be generated via the init command as follows:
By default this will place your wallet files into `~/.grin`. It is VERY IMPORTANT that you back up the `~/.grin/wallet_data/wallet.seed`
file somewhere safe and private, and ensure you somehow remember the password used to generate the wallet.
Alternatively, if you'd like to run a wallet in a directory other than the default, you can run:
```
[host]$ grin wallet init
Jul 30 15:25:20.999 INFO This is Grin version 0.3.0 (git testnet3-47-gaa64854), built for x86_64-unknown-linux-gnu by rustc 1.27.0 (3eda71b00 2018-06-19).
Jul 30 15:25:20.999 DEBG Built with profile "debug", features "" on Tue, 24 Jul 2018 14:53:51 GMT.
Jul 30 15:25:20.999 DEBG Generating wallet seed file at: ./wallet.seed
Jul 30 15:25:20.999 INFO Wallet seed file created
Jul 30 15:25:21.085 INFO Wallet database backend created
[host]$ grin wallet [-p password] init -h
```
This will create a `grin-wallet.toml` file in the current directory configured to use the data files in the current directory,
as well as all needed data files. When running any `grin wallet` command, grin will check the current directory to see if
a `grin-wallet.toml` file exists. If not it will use the default in `~/.grin`
### info
A summary of the wallet's contents can be retrieved from the wallet using the `info` command. Note that the `Total` sum may appear
@ -97,7 +109,7 @@ to other machines, use the `-e` switch:
[host]$ grin wallet -e listen
```
To change the port on which the wallet is listening, use the `-l` flag, e.g:
To change the port on which the wallet is listening, either configure `grin-wallet.toml` or use the `-l` flag, e.g:
```
[host]$ grin wallet -l 14000 listen
```
@ -105,7 +117,6 @@ To change the port on which the wallet is listening, use the `-l` flag, e.g:
The wallet will listen for requests until the process is cancelled with `<Ctrl-C>`. Note that external ports/firewalls need to be configured
properly if you're expecting requests from outside your local network (well out of the scope of this document).
### send
This builds a transaction interactively with another running wallet, then posts the final transaction to the chain. As the name suggests,
@ -261,15 +272,34 @@ running `grin wallet cancel`
##### restore
**NB the wallet restore command still needs some development work.. you may have issues with a restored wallet for the time being. If you're just trying,
to unlock outputs locked by failed test transactions, use the `cancel` command above**
If for some reason the wallet cancel commands above don't work, or you need to restore from a backed up `wallet.seed` file and password, you can perform a full wallet restore.
It is possible to restore a wallet from nothing but the seed file. To do this, ensure you're in an empty directory with nothing but the wallet seed file,
(and not mining into it with your grin node) and run the command:
To do this, generate an empty wallet somewhere with:
```
grin wallet init -h
```
Delete the newly generated wallet data directory and seed file:
```
[host@new_wallet_dir]# rm -rf wallet_data/db
[host@new_wallet_dir]# rm wallet_data/wallet.seed
```
Then copy your backed up `wallet.seed` file into the new `wallet_data` directory, ensuring it's called `wallet.seed`
```
[host@new_wallet_dir]# cp OLD_WALLET.seed wallet_data/wallet.seed
```
Then ensure that you're running a grin node, and makes sure nothing is attempting to mine into your wallet. Then, in the
wallet directory:
```
grin wallet restore
```
Note this operation can potentially take a long time. (More detail will be filled in about this operation after further development).
Note this operation can potentially take a long time. Once it's done, your wallet outputs should be restored, and you can
transact with your restored wallet as before the backup.

6
wallet/src/libwallet/api.rs
View file

@ -260,11 +260,7 @@ where
/// sender as well as the private file generate on the first send step.
/// Builds the complete transaction and sends it to a grin node for
/// propagation.
pub fn file_finalize_tx(
&mut self,
receiver_file: &str,
) -> Result<Slate, Error> {
pub fn file_finalize_tx(&mut self, receiver_file: &str) -> Result<Slate, Error> {
let mut pub_tx_f = File::open(receiver_file)?;
let mut content = String::new();
pub_tx_f.read_to_string(&mut content)?;