Minor edits throughout, apostrophes
parent
a3a0633160
commit
80be3d2cc6
GPG key ID:
3F8B1861E32B7DA2
12 changed files with 93 additions and 72 deletions
|
|
@ -1,9 +1,9 @@
|
|||
The text file editors that come with Windows, “edit” and “notepad”, are
|
||||
unsuitable for editing files in an MSYS environment for many reasons, but above
|
||||
all because they can't handle Unix line endings. So it's imperative you install
|
||||
all because they can’t handle Unix line endings. So it’s imperative you install
|
||||
a Unix-capable text editor such as Nano or Vim.
|
||||
|
||||
[Nano][00] is an easy-to-use editor designed for less experienced users. It's
|
||||
[Nano][00] is an easy-to-use editor designed for less experienced users. It’s
|
||||
available [here][04] as a precompiled Windows binary. Just extract `nano.exe`
|
||||
and `cygwin1.dll` from the archive and copy them to `C:\windows` or some other
|
||||
location on your execution path.
|
||||
|
|
|
|||
|
|
@ -26,13 +26,13 @@ MMGen uses Parity to communicate with the Ethereum blockchain. For information
|
|||
on installing Parity on your system, visit the Parity Ethereum [homepage][h] or
|
||||
[Git repository][g]. [MMGenLive][l] users can install Parity automatically from
|
||||
signed binaries using the [`mmlive-daemon-upgrade`][U] script. Parity is not
|
||||
used for transaction signing, so you needn't install it on your offline machine.
|
||||
used for transaction signing, so you needn’t install it on your offline machine.
|
||||
|
||||
Parity must be invoked with the `--jsonrpc-apis=all` option so that MMGen can
|
||||
communicate with it. If you're running the daemon and MMGen on different
|
||||
machines you'll also need the following:
|
||||
communicate with it. If you’re running the daemon and MMGen on different
|
||||
machines you’ll also need the following:
|
||||
|
||||
--jsonrpc-hosts=all --jsonrpc-interface=<IP of Parity's host>
|
||||
--jsonrpc-hosts=all --jsonrpc-interface=<IP of Parity’s host>
|
||||
|
||||
To transact Ethereum Classic, use `--chain=classic --jsonrpc-port=8555`
|
||||
|
||||
|
|
@ -62,9 +62,9 @@ will prevent pip from installing a lot of unneeded stuff:
|
|||
Basic operations with ETH, ETC and ERC20 tokens work as described in the
|
||||
[Getting Started][bo] guide, with some differences. Please note the following:
|
||||
|
||||
* Don't forget to invoke all commands with either `--coin=eth` or `--coin=etc`.
|
||||
* Don’t forget to invoke all commands with `--coin=eth` or `--coin=etc`.
|
||||
* Use the `--token` switch with all token operations. When importing addresses
|
||||
into your token tracking wallet you must use the token's address as the
|
||||
into your token tracking wallet you must use the token’s address as the
|
||||
argument. After this, the token symbol, e.g. `--token=eos`, is sufficient.
|
||||
* Addresses and other hexadecimal values are given without the leading `0x`.
|
||||
* Fees are expressed in Gas price, e.g. `12G` for 12 Gwei or `1000M` for 1000
|
||||
|
|
@ -85,7 +85,7 @@ Create an EOS token tracking wallet and import the addresses into it:
|
|||
|
||||
*Unlike the case with BTC and derivatives, ETH and ETC tracking wallets are
|
||||
created and managed by MMGen itself and located under the MMGen data directory.
|
||||
Token tracking wallets are located inside their underlying coin's
|
||||
Token tracking wallets are located inside their underlying coin’s
|
||||
`tracking-wallet.json` file. Address (account) balances are retrieved directly
|
||||
from the blockchain. Tracking wallet views are separate for each token.*
|
||||
|
||||
|
|
@ -200,17 +200,17 @@ MMGen requires that the bitcoin-abc daemon be listening on non-standard
|
|||
`--usecashaddr=0` option.
|
||||
|
||||
Then just add the `--coin=bch` or `--coin=ltc` option to all your MMGen
|
||||
commands. It's that simple!
|
||||
commands. It’s that simple!
|
||||
|
||||
### <a name='a_zec'>Key/address generation for Zcash (ZEC)</a>
|
||||
|
||||
MMGen's enhanced support for Zcash includes generation of **z-addresses.**
|
||||
MMGen’s enhanced support for Zcash includes generation of **z-addresses.**
|
||||
|
||||
Generate ten Zcash z-address key/address pairs from your default wallet:
|
||||
|
||||
$ mmgen-keygen --coin=zec --type=zcash_z 1-10
|
||||
|
||||
The addresses' view keys are included in the output file as well.
|
||||
The addresses’ view keys are included in the output file as well.
|
||||
|
||||
NOTE: Since your key/address file will probably be used on an online computer,
|
||||
you should encrypt it with a good password when prompted to do so. The file can
|
||||
|
|
@ -223,18 +223,22 @@ To generate Zcash t-addresses, just omit the `--type` argument:
|
|||
|
||||
### <a name='a_xmr'>Key/address generation and wallet creation/syncing for Monero (XMR)</a>
|
||||
|
||||
MMGen's enhanced support for Monero includes automated Monero wallet creation
|
||||
Generate ten Monero address pairs from your default wallet:
|
||||
|
||||
$ mmgen-keygen --coin=xmr 1-10
|
||||
|
||||
MMGen’s enhanced support for Monero includes automated Monero wallet creation
|
||||
and syncing.
|
||||
|
||||
*Note that the use of these commands requires private data to be exposed on a
|
||||
network-connected machine in order to unlock the Monero wallets, which is a
|
||||
violation of MMGen’s security policy.*
|
||||
|
||||
Install the following dependencies:
|
||||
|
||||
$ sudo -H pip3 install pysha3
|
||||
$ sudo -H pip3 install ed25519ll # optional, but greatly speeds up address generation
|
||||
|
||||
Generate ten Monero address pairs from your default wallet:
|
||||
|
||||
$ mmgen-keygen --coin=xmr 1-10
|
||||
|
||||
In addition to spend and view keys, Monero key/address files also include a
|
||||
wallet password for each address (the password is the double SHA256 of the spend
|
||||
key, truncated to 16 bytes). This allows you to generate a wallet from each
|
||||
|
|
@ -254,7 +258,7 @@ completely automates this process:
|
|||
This will generate a uniquely-named Monero wallet for each key/address pair in
|
||||
the key/address file and encrypt it with its respective password. No user
|
||||
interaction is required. By default, wallets are synced to the current block
|
||||
height, as they're assumed to be empty, but this behavior can be overridden:
|
||||
height, as they’re assumed to be empty, but this behavior can be overridden:
|
||||
|
||||
$ mmgen-tool keyaddrlist2monerowallets *XMR*.akeys.mmenc blockheight=123456
|
||||
|
||||
|
|
@ -268,7 +272,7 @@ have a large batch of wallets requiring long sync times.
|
|||
|
||||
### <a name='a_kg'>Key/address generation support for 144 Bitcoin-derived altcoins</a>
|
||||
|
||||
To generate key/address pairs for these coins, just specify the coin's symbol
|
||||
To generate key/address pairs for these coins, just specify the coin’s symbol
|
||||
with the `--coin` argument:
|
||||
|
||||
# For DASH:
|
||||
|
|
@ -280,13 +284,13 @@ For compressed public keys, add the `--type=compressed` option:
|
|||
|
||||
$ mmgen-keygen --coin=dash --type=compressed 1-10
|
||||
|
||||
If it's just the addresses you want, then use `mmgen-addrgen` instead:
|
||||
If it’s just the addresses you want, then use `mmgen-addrgen` instead:
|
||||
|
||||
$ mmgen-addrgen --coin=dash 1-10
|
||||
$ mmgen-addrgen --coin=dash --type=compressed 1-10
|
||||
|
||||
Regarding encryption of key/address files, see the note for Zcash above.
|
||||
|
||||
Here's a complete list of supported altcoins as of this writing:
|
||||
Here’s a complete list of supported altcoins as of this writing:
|
||||
|
||||
2give,42,611,ac,acoin,alf,anc,apex,arco,arg,aur,bcf,blk,bmc,bqc,bsty,btcd,
|
||||
btq,bucks,cann,cash,cat,cbx,ccn,cdn,chc,clam,con,cpc,crps,csh,dash,dcr,dfc,
|
||||
|
|
@ -298,10 +302,10 @@ Here's a complete list of supported altcoins as of this writing:
|
|||
sys,taj,tit,tpc,trc,ttc,tx,uno,via,vpn,vtc,wash,wdc,wisc,wkc,wsx,xcn,xgb,
|
||||
xmg,xpm,xpoke,xred,xst,xvc,zet,zlq,zoom,zrc,bch,etc,eth,ltc,xmr,zec
|
||||
|
||||
Note that support for these coins is EXPERIMENTAL. Many of them have received
|
||||
only minimal testing, or no testing at all. At startup you'll be informed of
|
||||
the level of your selected coin's support reliability as deemed by the MMGen
|
||||
Project.
|
||||
Note that support for most of these coins is EXPERIMENTAL. Many of them have
|
||||
received only minimal testing, or no testing at all. At startup you’ll be
|
||||
informed of the level of your selected coin’s support reliability as deemed by
|
||||
the MMGen Project.
|
||||
|
||||
[h]: https://www.parity.io/ethereum
|
||||
[g]: https://github.com/paritytech/parity-ethereum/releases
|
||||
|
|
|
|||
|
|
@ -550,9 +550,9 @@ actually displayed. MMGen never prints decrypted private data to screen unless
|
|||
you ask it to.
|
||||
|
||||
The output of any MMGen command may be written to a directory of your choice
|
||||
using the `-d` option. For example, on a Linux system you can use
|
||||
`-d /dev/shm` to write keys and seeds to volatile memory instead of disk,
|
||||
ensuring that no trace of secret data remains once your computer’s been
|
||||
using the `--outdir` or `-d` option. For example, on a Linux system you can use
|
||||
`--outdir=/dev/shm` to write keys and seeds to volatile memory instead of disk,
|
||||
ensuring that no traces of your secret data are left once your computer’s been
|
||||
powered down.
|
||||
|
||||
#### <a name='a_ic'>Incognito wallets</a>
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ binaries are available for Bitcoin Core, Bitcoin ABC and Litecoin. See the
|
|||
|
||||
sudo apt-get install libboost-system-dev libboost-filesystem-dev libboost-program-options-dev libboost-chrono-dev libboost-test-dev libboost-thread-dev
|
||||
|
||||
> You'll also need the following standard dependencies, if they're not already on
|
||||
> You’ll also need the following standard dependencies, if they’re not already on
|
||||
> your system:
|
||||
|
||||
sudo apt-get install build-essential libtool autotools-dev autoconf pkg-config libssl-dev libdb-dev libdb++-dev libevent-dev
|
||||
|
|
@ -31,7 +31,7 @@ binaries are available for Bitcoin Core, Bitcoin ABC and Litecoin. See the
|
|||
|
||||
> The '-j4' option will speed the build process up by using 4 cores of a 4-core
|
||||
> processor, if you have them. If overheating issues are a problem for your CPU
|
||||
> or you're short on memory, you may want to omit the option or reduce the
|
||||
> or you’re short on memory, you may want to omit the option or reduce the
|
||||
> number of cores used.
|
||||
|
||||
> For more detailed build information, consult the file [doc/build-unix.md][bu]
|
||||
|
|
@ -64,7 +64,7 @@ binaries are available for Bitcoin Core, Bitcoin ABC and Litecoin. See the
|
|||
$ cd src
|
||||
$ sudo install -sv bitcoind /usr/local/bin/bitcoind-abc
|
||||
|
||||
> From now on, you'll invoke the daemon as 'bitcoind-abc' instead of 'bitcoind'.
|
||||
> From now on, you’ll invoke the daemon as 'bitcoind-abc' instead of 'bitcoind'.
|
||||
|
||||
### Compile and install Litecoin Core (optional):
|
||||
|
||||
|
|
|
|||
|
|
@ -7,14 +7,14 @@ machine.
|
|||
|
||||
The bitcoin daemon on the **online computer** requires a complete and
|
||||
up-to-date blockchain for tracking addresses. Since its work is more CPU and
|
||||
disk intensive, a more powerful computer is required here. You'll also need
|
||||
disk intensive, a more powerful computer is required here. You’ll also need
|
||||
plenty of free disk space for the growing blockchain (~265GB at the time of
|
||||
writing).
|
||||
|
||||
Two blockchain operations are especially resource-intensive: **synchronizing
|
||||
the blockchain** and **importing existing addresses with balances**. If you
|
||||
synchronize often (once a week, for example) and take care to import your
|
||||
addresses **before** spending into them, then it's possible to get by with a
|
||||
addresses **before** spending into them, then it’s possible to get by with a
|
||||
more low-powered computer as your online machine.
|
||||
|
||||
### <a name='a_d'>Download:</a>
|
||||
|
|
@ -74,7 +74,7 @@ more low-powered computer as your online machine.
|
|||
|
||||
> **Windows:**
|
||||
|
||||
>> In the Windows command-line environment processes don't fork to run in the
|
||||
>> In the Windows command-line environment processes don’t fork to run in the
|
||||
>> background, so to run multiple daemons simultaneously you must start each
|
||||
>> one in a separate terminal window. Start your daemons like this:
|
||||
|
||||
|
|
@ -115,11 +115,11 @@ more low-powered computer as your online machine.
|
|||
# Litecoin:
|
||||
$ litecoin-cli help
|
||||
|
||||
> Warning: If you're using an existing Bitcoin or Litecoin installation, **move
|
||||
> your wallet.dat out of harm's way** before starting the daemon. The new
|
||||
> Warning: If you’re using an existing Bitcoin or Litecoin installation, **move
|
||||
> your wallet.dat out of harm’s way** before starting the daemon. The new
|
||||
> wallet now created will be used as your **tracking wallet**.
|
||||
|
||||
> If you're connected to the Internet, the daemon(s) will begin downloading and
|
||||
> If you’re connected to the Internet, the daemon(s) will begin downloading and
|
||||
> verifying the blockchain. This can take from several hours to several days
|
||||
> depending on the speed of your computer, the size of the blockchain(s) in
|
||||
> question and your Internet connection. You can speed up your initial block
|
||||
|
|
|
|||
|
|
@ -2,10 +2,10 @@
|
|||
|
||||
Install required Debian/Ubuntu packages:
|
||||
|
||||
$ sudo apt-get install autoconf git libgmp-dev libssl-dev libtool wipe
|
||||
$ sudo apt-get install autoconf git libgmp-dev libssl-dev libpcre3-dev libtool wipe
|
||||
$ sudo apt-get install python3-dev python3-ecdsa python3-pexpect python3-setuptools python3-cryptography python3-nacl python3-pip python3-gmpy2 python3-sha3
|
||||
|
||||
Using the [pip3][P] installer, install the Python scrypt library
|
||||
Using the [pip3][P] installer, install the Python scrypt library:
|
||||
|
||||
$ sudo -H pip3 install scrypt
|
||||
|
||||
|
|
@ -28,10 +28,8 @@ Install MMGen:
|
|||
$ sudo ./setup.py install
|
||||
$ cd ..
|
||||
|
||||
Install the bitcoind daemon(s):
|
||||
|
||||
To install prebuilt binaries, go [here][01]. To install from source, go
|
||||
[here][02].
|
||||
Install your coin daemon(s). To install prebuilt binaries, go [here][01]. To
|
||||
install from source, go [here][02].
|
||||
|
||||
#### *Note for offline machines:*
|
||||
|
||||
|
|
@ -41,17 +39,21 @@ To install prebuilt binaries, go [here][01]. To install from source, go
|
|||
> install is done, preferably removing or disabling its network interfaces.
|
||||
|
||||
> However, if your machine is already offline and you wish to leave it that way,
|
||||
> or if it lacks a network interface entirely, then you'll need to take roughly
|
||||
> or if it lacks a network interface entirely, then you’ll need to take roughly
|
||||
> the following steps:
|
||||
|
||||
>> From your online machine, download the Debian/Ubuntu packages and their
|
||||
>> dependencies manually from packages.debian.org or packages.ubuntu.com, and
|
||||
>> the Python packages from pypi.python.org/pypi/<packagename>. Transfer
|
||||
>> these files and the cloned Git repositories to your offline computer using a
|
||||
>> USB stick or other storage medium. Install the Debian/Ubuntu packages with
|
||||
>> 'sudo dpkg -i', unpack each Python module and install it using 'sudo
|
||||
>> ./setup.py install', and install MMGen and the secp256k1 library from the
|
||||
>> copied Git repositories as described above.
|
||||
>> If your offline and offline machines have the same architecture, then just
|
||||
>> download the Debian/Ubuntu packages and their dependencies on your online
|
||||
>> machine using `apt-get download`. Otherwise, you must download the packages
|
||||
>> manually from `packages.debian.org` or `packages.ubuntu.com`.
|
||||
>>
|
||||
>> Download the Python packages using `pip3 download`.
|
||||
>>
|
||||
>> Transfer the downloaded files and cloned Git repositories to your offline
|
||||
>> computer using a USB stick or other removable medium. Install the
|
||||
>> Debian/Ubuntu packages with `sudo dpkg -i` and the Python packages with `pip3
|
||||
>> install`. Install MMGen and the secp256k1 library from the copied Git
|
||||
>> repositories as described above.
|
||||
|
||||
Congratulations, your installation is now complete! Now proceed to [**Getting
|
||||
Started with MMGen**][gs].
|
||||
|
|
|
|||
|
|
@ -49,6 +49,14 @@ text window, append a space followed by the text `C:\\msys64\usr\bin\bash.exe
|
|||
Save your changes and double click the icon to launch your MSYS2-enabled
|
||||
PowerShell. From now on, all your work will be done in this terminal.
|
||||
|
||||
Note that the root of your MSYS2 installation is located in `C:\\msys64`, so the
|
||||
following commands, for example:
|
||||
|
||||
$ ls /etc # the path as seen within MSYS2
|
||||
$ ls 'C:\\msys64\etc' # the path as seen by Windows
|
||||
|
||||
will produce a listing of the same directory.
|
||||
|
||||
### 3. Upgrade MSYS2
|
||||
|
||||
#### Online users:
|
||||
|
|
@ -167,7 +175,12 @@ Install the packages and their dependencies:
|
|||
mingw64/mingw-w64-x86_64-python3-pip \
|
||||
mingw64/mingw-w64-x86_64-gcc
|
||||
|
||||
### 5. Set your PATH environmental variable
|
||||
### 5. Set up your environment
|
||||
|
||||
Create the `/usr/local/bin` directory. This is where you’ll place various
|
||||
binaries required by MMGen:
|
||||
|
||||
$ mkdir -p /usr/local/bin # seen by Windows as C:\\msys64\usr\local\bin
|
||||
|
||||
Open your shell’s runtime configuration file in a text editor:
|
||||
|
||||
|
|
@ -185,12 +198,12 @@ Three of MMGen’s Python dependencies, `ecdsa`, `py_ecc` and `mypy_extensions`,
|
|||
are not provided by MSYS2. If you’re online, you can install them using the pip
|
||||
package installer as follows:
|
||||
|
||||
$ pip3 install --no-deps ecdsa==0.13 py_ecc==1.6.0 mypy_extensions==0.4.1
|
||||
$ pip3 install --no-deps ecdsa==0.13 py_ecc==1.6.0 mypy_extensions==0.4.1 scrypt==0.8.13
|
||||
|
||||
For an offline install, first download the packages on your online machine like
|
||||
this:
|
||||
|
||||
$ pip3 download --no-deps ecdsa==0.13 py_ecc==1.6.0 mypy_extensions==0.4.1
|
||||
$ pip3 download --no-deps ecdsa==0.13 py_ecc==1.6.0 mypy_extensions==0.4.1 scrypt==0.8.13
|
||||
|
||||
Then transfer the `*.whl` files to your offline machine, `cd` to the directory
|
||||
containing the files and install them as follows:
|
||||
|
|
|
|||
|
|
@ -2,8 +2,8 @@
|
|||
information on this page is provided for the benefit of legacy installations
|
||||
only*
|
||||
|
||||
Chances are you'll want to use MMGen not only for cold storage but for
|
||||
day-to-day transactions too. For this you'll need to place a portion of your
|
||||
Chances are you’ll want to use MMGen not only for cold storage but for
|
||||
day-to-day transactions too. For this you’ll need to place a portion of your
|
||||
funds in a “hot wallet” on your online computer. With hot wallet funds you
|
||||
can use the command `mmgen-txdo` to quickly create, sign and send transactions
|
||||
in one operation.
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
## Introduction
|
||||
|
||||
In addition to low-level subsystems, the suite tests the overall operation of
|
||||
MMGen's commands by running them interactively as a user would. Thus the test
|
||||
MMGen’s commands by running them interactively as a user would. Thus the test
|
||||
suite is useful not only for ensuring the MMGen system is correctly installed
|
||||
and working on your platform but also for observing how it works.
|
||||
|
||||
For BTC-only testing, only Bitcoin Core need be installed. For altcoin testing,
|
||||
requirements are listed below. Non-standard RPC ports and data directories are
|
||||
always used, so there’s no need to stop your running node or nodes.
|
||||
requirements are discussed below. Non-standard RPC ports and data directories
|
||||
are always used, so there’s no need to stop your running node or nodes.
|
||||
|
||||
On Linux/x86\_64 with a reasonably fast processor, the full suite should run in
|
||||
under 15 minutes when invoked with the `-F` option. On other platforms,
|
||||
|
|
@ -75,11 +75,13 @@ users can omit MoneroPy, Zcash-Mini and Ethkey):
|
|||
|
||||
#### Ethkey
|
||||
|
||||
Download a [binary][pb] for your architecture, or install from source:
|
||||
Download a [binary][pb] for your architecture and copy it to `/usr/local/bin`,
|
||||
or install from source:
|
||||
|
||||
$ sudo apt-get install rustc # skip this if Rust is already installed
|
||||
$ git clone https://github.com/paritytech/parity-ethereum
|
||||
$ cd parity-ethereum
|
||||
$ git checkout v2.6.6 # this version builds on ARM boards - your mileage may vary
|
||||
$ cargo build -p ethkey-cli --release
|
||||
$ sudo install --strip ./target/release/ethkey /usr/local/bin
|
||||
$ cd ..
|
||||
|
|
@ -104,7 +106,7 @@ to simulate interactive operation of MMGen commands. Running `test/test.py`
|
|||
with the `-e` switch will produce the same output as if the commands had been
|
||||
run by a user.
|
||||
|
||||
| Test | What is tested |
|
||||
| Test | What it tests |
|
||||
|:----------------------|:-----------------------------------------------------|
|
||||
| `test/colortest.py` | terminfo parsing; terminal colors |
|
||||
| `test/gentest.py` | key/address generation - profiling and data validity |
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
The tool API provides a convenient interface to selected methods in the
|
||||
mmgen.tool module. Type `pydoc3 mmgen.tool.tool_api` to view available
|
||||
methods and call signatures.
|
||||
mmgen.tool module. Type `pydoc3 mmgen.tool.tool_api` for available methods
|
||||
and call signatures.
|
||||
|
||||
## Examples
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
## Tracking and spending ordinary Bitcoin (non-MMGen) addresses
|
||||
|
||||
While not recommended, it is possible to use MMGen to track and spend ordinary
|
||||
Bitcoin addresses too, i.e. addresses whose keys you control but which haven't
|
||||
Bitcoin addresses too, i.e. addresses whose keys you control but which haven’t
|
||||
been spent to your MMGen wallet.
|
||||
|
||||
#### Import the Bitcoin addresses for tracking (online computer):
|
||||
|
|
@ -13,13 +13,13 @@ into the tracking wallet:
|
|||
|
||||
NOTE: The '--rescan' option forces a rescan of the entire block chain, which is
|
||||
required for all addresses with existing balances. The rescanning process is
|
||||
very slow, and Bitcoin Core unfortunately doesn't support rescanning in batch
|
||||
very slow, and Bitcoin Core unfortunately doesn’t support rescanning in batch
|
||||
mode. This is why you should always import new addresses into the tracking
|
||||
wallet *before* spending into them, whenever possible.
|
||||
|
||||
#### Create a keylist file for signing transactions (online computer):
|
||||
|
||||
To sign transactions that spend from the Bitcoin addresses you've imported, you
|
||||
To sign transactions that spend from the Bitcoin addresses you’ve imported, you
|
||||
need their corresponding private keys.
|
||||
|
||||
If the key or keys in question are in a bitcoind wallet ('wallet.dat'), you can
|
||||
|
|
@ -38,7 +38,7 @@ on your online computer using a utility such as 'wipe'.
|
|||
|
||||
You may also create your own 'my_secret.keys' (or whatever you choose to call
|
||||
it) file in a plain text editor. In it, just list the WIF-format keys
|
||||
corresponding to the addresses you've imported, one key per line.
|
||||
corresponding to the addresses you’ve imported, one key per line.
|
||||
|
||||
#### Sign a transaction using the keylist (offline computer):
|
||||
|
||||
|
|
@ -50,9 +50,9 @@ it with the keylist file:
|
|||
...
|
||||
Signed transaction written to file 'F9DCBA[6.6].sigtx'
|
||||
|
||||
If your transaction also contains MMGen inputs, you'll need to provide a wallet
|
||||
If your transaction also contains MMGen inputs, you’ll need to provide a wallet
|
||||
for them too, listing it at the end of the command line, like this:
|
||||
|
||||
$ mmgen-txsign -k my_secret.keys F9DCBA[6.6].rawtx 89ABCDEF-76543210[256,3].mmdat
|
||||
|
||||
That's it! Your signed transaction is ready to broadcast.
|
||||
That’s it! Your signed transaction is ready to broadcast.
|
||||
|
|
|
|||
|
|
@ -173,7 +173,7 @@ deterministic method outlined above, we can only generate the same set of
|
|||
pseudorandom shares over and over again. The obvious solution here is to give
|
||||
each split a name: for our split with Bob, we’ll add “bob” to the share
|
||||
identifier, for our split with Alice, we’ll add “alice”, and so forth. Using
|
||||
this approach, we can create an arbitrary number of uniquely named splits.
|
||||
this approach, we can create an arbitrary number of uniquely named splits.
|
||||
|
||||
Create a 2-way split with Bob:
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue