<h1 align="center">NANO</h1>

<a href="#NAME">NAME</a><br>
<a href="#SYNOPSIS">SYNOPSIS</a><br>
<a href="#INTRODUCTION">INTRODUCTION</a><br>
<a href="#PROCEDURES">PROCEDURES</a><br>
<a href="#EXAMPLES">EXAMPLES</a><br>
<a href="#AUTHOR">AUTHOR</a><br>

<hr>


<h2>NAME
<a name="NAME"></a>
</h2>


<p style="margin-left:11%; margin-top: 1em">nano &minus;
Tcl bindings for Nano</p>

<h2>SYNOPSIS
<a name="SYNOPSIS"></a>
</h2>



<p style="margin-left:11%; margin-top: 1em"><b>nano::</b></p>

<p style="margin-left:14%;"><b>address::</b></p>

<p style="margin-left:17%;"><b>toPublicKey</b>
<i>address</i> ?<b>-hex</b>|<b>-binary</b>?
?<b>-verify</b>|<b>-no-verify</b>? <b><br>
fromPublicKey</b> <i>pubKey</i> ?<b>-xrb</b>|<b>-nano</b>?
<b><br>
fromPrivateKey</b> <i>privateKey</i>
?<b>-xrb</b>|<b>-nano</b>?</p>


<p style="margin-left:14%; margin-top: 1em"><b>key::</b></p>

<p style="margin-left:17%;"><b>newSeed</b>
?<b>-hex</b>|<b>-binary</b>? <b><br>
newKey</b> ?<b>-hex</b>|<b>-binary</b>? <b><br>
fromSeed</b> <i>seed</i> ?<i>index</i>?
?<b>-hex</b>|<b>-binary</b>? <b><br>
publicKeyFromPrivateKey</b> <i>privateKey</i>
?<b>-hex</b>|<b>-binary</b>?</p>


<p style="margin-left:14%; margin-top: 1em"><b>block::</b></p>

<p style="margin-left:17%;"><b>json::toBlock</b>
<i>blockJSON</i> <b><br>
json::fromDict</b> <i>blockDict</i> <b><br>
json::fromBlock</b> <i>blockData</i>
?<b>-xrb</b>|<b>-nano</b>? ? <b>-type=</b><i>blockType</i> ?
? <b>-signKey=</b><i>privateKey</i> ? <b><br>
json::sign</b> <i>blockJSON privateKey</i>
?<b>-update</b>|<b>-signature</b>
?<b>-hex</b>|<b>binary</b>?? <b><br>
json::verifySignature</b> <i>blockJSON</i> <b><br>
json::work</b> <i>blockJSON</i> ?<b>-update</b>|<b>-work</b>
?<b>-hex</b>|<b>-binary</b>?? <b><br>
json::validateWork</b> <i>blockJSON</i></p>


<p style="margin-left:17%; margin-top: 1em"><b>dict::toBlock</b>
<i>blockDict</i> <b><br>
dict::fromJSON</b> <i>blockJSON</i> <b><br>
dict::fromBlock</b> <i>blockData</i>
?<b>-xrb</b>|<b>-nano</b>? ? <b>-type=</b><i>blockType</i> ?
? <b>-signKey=</b><i>privateKey</i> ? <b><br>
dict::sign</b> <i>blockDict privateKey</i>
?<b>-update</b>|<b>-signature</b>
?<b>-hex</b>|<b>binary</b>?? <b><br>
dict::verifySignature</b> <i>blockDict</i> <b><br>
dict::work</b> <i>blockDict</i> ?<b>-update</b>|<b>-work</b>
?<b>-hex</b>|<b>-binary</b>?? <b><br>
dict::validateWork</b> <i>blockDict</i></p>

<p style="margin-left:17%; margin-top: 1em"><b>hash</b>
<i>blockData</i> ?<b>-hex</b>|<b>-binary</b>? <b><br>
signBlockHash</b> <i>blockHash privateKey</i>
?<b>-hex</b>|<b>-binary</b>? <b><br>
sign</b> <i>blockData privateKey</i>
?<b>-hex</b>|<b>-binary</b>? <b><br>
verifyBlockHash</b> <i>blockHash signature publicKey</i>
<b><br>
verify</b> <i>blockData signature publicKey</i></p>


<p style="margin-left:17%; margin-top: 1em"><b>create::send</b>
<i>args</i> <b><br>
create::receive</b> <i>args</i> <b><br>
create::setRepresentative</b> <i>args</i></p>


<p style="margin-left:14%; margin-top: 1em"><b>work::</b></p>

<p style="margin-left:17%;"><b>fromWorkData</b>
<i>blockHashOrPublicKey</i> <b><br>
fromBlock</b> <i>blockData</i> <b><br>
validate</b> <i>workData work</i></p>


<p style="margin-left:14%; margin-top: 1em"><b>account::</b></p>

<p style="margin-left:17%;"><b>setFrontier</b> <i>account
frontierHash balance representative</i> <b><br>
getFrontier</b> <i>account</i> <b><br>
getFrontier</b> <i>account</i>
?<b>frontierHash</b>|<b>balance</b>|<b>representative</b>?
<b><br>
addPending</b> <i>account blockHash amount</i> <b><br>
getPending</b> <i>account</i> ?<i>blockHash</i>? <b><br>
clearPending</b> <i>account</i> ?<i>blockHash</i>?</p>

<p style="margin-left:17%; margin-top: 1em"><b>receive</b>
<i>account blockHash privateKey</i> <b><br>
receiveAllPending</b> <i>account privateKey</i> <b><br>
send</b> <i>fromAccount toAccount amount privateKey</i>
<b><br>
setRepresentative</b> <i>account representative
privateKey</i></p>

<h2>INTRODUCTION
<a name="INTRODUCTION"></a>
</h2>


<p style="margin-left:11%; margin-top: 1em"><i>Nano</i> is
a low-latency payment platform that requires minimal
resources, relying on a peer-to-peer network to distribute
&quot;blocks&quot;, which are cryptographically signed
transactions. This package provides bindings for interacting
with the Nano network from <i>Tcl</i>.</p>

<p style="margin-left:11%; margin-top: 1em">Nano uses
Ed25519 with Blake2b as the cryptographic hashing primitive
for digital signatures, rather than the common construction
of Ed25519 with the SHA2-512 cryptographic hashing
function.</p>

<p style="margin-left:11%; margin-top: 1em">Nano implements
a &quot;blockchain&quot;, which is a cryptographic
linked-list, by identifying every &quot;block&quot; by its
crytographic hash and providing a pointer from every block
to its predecessor in the &quot;chain&quot; as part of the
hashed data.</p>

<p style="margin-left:11%; margin-top: 1em">This
predecessors is referred to here as the &quot;previous&quot;
block. In Nano, each account has its own blockchain and they
reference each other using a data structure referred to as
&quot;block lattice&quot;, where the individual chains
contain blocks that reference blocks in other chains to tie
them together. The field within blocks that reference other
blocks on a different blockchain is referred to as either
the &quot;link&quot; field or &quot;source block
hash&quot;.</p>

<p style="margin-left:11%; margin-top: 1em">Each Nano block
also encapsulates the full state of the account, containing,
at a minimum, a tuple of (<i>account</i>, <i>balance</i>,
<i>representative</i>, <i>previous</i>).</p>

<p style="margin-left:11%; margin-top: 1em">Since Nano
blocks are signed by independent actors, who may, for their
own gain, generate multiple valid blocks referring to the
same predecessor (<i>previous</i>) block, an arbitration
mechanism is employed by the Nano network to decide which
blocks are valid within a given chain. This arbitration
mechanism operates on the principles of consensus. Each
account holder has a stake in the network operating
nominally, otherwise the balance represented by an account
is not useful for a transfer of value. In Nano the stake an
account has in the network is equal to the account&rsquo;s
balance. The larger the stake an account has the more
incentivized the account-holder is to ensure the network is
operating nominally and not accepting multiple blocks that
reference the same predecessor.</p>

<p style="margin-left:11%; margin-top: 1em">Nano utilizes a
mechanism called <i>voting</i> to determine which blocks are
valid and which blocks are not valid. Each stakeholder votes
their stake upon seeing a new subordinate block
(<i>i.e.</i>, a block with a unique <i>previous</i> value).
Since voting is an active and on-going process that occurs
on the Nano peer-to-peer network, participants must be
online to vote their stake. As this is often inconvienent or
impossible, stakeholders may select another stakeholder to
vote their share of the network. This delegate is referred
to as a <i>representative</i>.</p>


<p style="margin-left:11%; margin-top: 1em">Representatives
should be chosen carefully by stakeholders since malicious
representatives may attempt to gather voting power and
destablize the Nano network by altering decisions made by
consensus previously.</p>

<p style="margin-left:11%; margin-top: 1em">Nano accounts
are referred to by address. A Nano address starts with the
prefix &quot;<b>nano_</b>&quot; or &quot;<b>xrb_</b>&quot;.
A Nano address is actually the public portion of a
private/public keypair, plus the prefix, and a checksum to
ensure that no digits are mistyped by users when
communicating them. Nano public keys are 256-bit keys in the
Ed25519 algorithm.</p>

<p style="margin-left:11%; margin-top: 1em">A user may have
many accounts. To simplify the process of maintaining the
private/public keypairs for all the accounts, Nano supports
the concept of a <i>wallet</i>. A <i>wallet</i> is a
conceptual entity that is used to refer to a <i>seed</i>,
which is a random 256-bit number that can be used to derive
mulitple private/public keypairs from.</p>

<p style="margin-left:11%; margin-top: 1em">Balances in
Nano are stored in a 128-bit integer value. There are
various units for representing the balance, the smallest and
base unit is called &quot;<i>raw</i>&quot;. The most common
unit for users to use is called &quot;<i>Nano</i>&quot;, one
of which is equal to 1e30 raw.</p>

<h2>PROCEDURES
<a name="PROCEDURES"></a>
</h2>


<p style="margin-left:11%; margin-top: 1em"><b>Addresses
<br>
::nano::address::toPublicKey</b></p>

<p style="margin-left:22%;"><i>address</i>
?<b>-hex</b>|<b>-binary</b>?
?<b>-verify</b>|<b>-no-verify</b>? <b>-&gt;</b>
<i>publicKey</i></p>

<p style="margin-left:22%; margin-top: 1em">Converts a Nano
address to a public key. The <b>-hex</b> option indicates
that the public key should be returned in hexidecimal form.
The option indicates that the public key should be returned
in binary form. The <b>-verify</b> option verifies the
checksum embedded in the Nano address before returning. The
<b>-no-verify</b> option inhibits verifying the checksum
embedded in the Nano address.</p>


<p style="margin-left:11%;"><b>::nano::address::fromPublicKey</b></p>

<p style="margin-left:22%;"><i>pubKey</i>
?<b>-xrb</b>|<b>-nano</b>? <b>-&gt;</b> <i>address</i></p>

<p style="margin-left:22%; margin-top: 1em">Converts a
public key to a Nano address. The option specifies that the
returned address should be prefixed with the old-style
&quot;xrb_&quot; prefix, where the <b>-nano</b> option
specifies that the returned address should be prefixed with
the new-style &quot;nano_&quot; prefix.</p>


<p style="margin-left:11%;"><b>::nano::address::fromPrivateKey</b></p>

<p style="margin-left:22%;"><i>privateKey</i>
?<b>-xrb</b>|<b>-nano</b>? <b>-&gt;</b> <i>address</i></p>

<p style="margin-left:22%; margin-top: 1em">Converts a
private key to a Nano address. It accepts the same arguments
as <b>fromPublicKey</b>.</p>

<p style="margin-left:11%; margin-top: 1em"><b>Key
Management <br>
::nano::key::newSeed</b></p>

<p style="margin-left:22%;">?<b>-hex</b>|<b>-binary</b>?
-&gt; <i>seed</i></p>

<p style="margin-left:22%; margin-top: 1em">Generates a new
seed. A seed is a 256-bit bitfield which, along with a
32-bit index, is used to derive enumerated keys from a
single point of entropy. See the <b>fromSeed</b> procedure.
The <b>-hex</b> and <b>-binary</b> options determine the
formatting of the result.</p>

<p style="margin-left:11%;"><b>::nano::key::newKey</b></p>

<p style="margin-left:22%;">?<b>-hex</b>|<b>-binary</b>?
-&gt; <i>privateKey</i></p>

<p style="margin-left:22%; margin-top: 1em">Generates a new
private key. A private key can be used to sign transactions,
which can then be verified with its cooresponding public key
(see <b>publicKeyFromPrivateKey</b>). This procedure is
normally not used, but rather private keys are derived from
a <i>seed</i> and <i>index</i> pair using the
<b>fromSeed</b> procedure. The <b>-hex</b> and
<b>-binary</b> options determine the formatting of the
result.</p>


<p style="margin-left:11%;"><b>::nano::key::fromSeed</b></p>

<p style="margin-left:22%;"><i>seed</i> ?<i>index</i>?
?<b>-hex</b>|<b>-binary</b>? -&gt; <i>privateKey</i></p>

<p style="margin-left:22%; margin-top: 1em">Derive a
private key from the seed specified as <i>seed</i> and the
<i>index</i> indicated. This procedure is deterministic
(i.e., the same <i>seed</i> and <i>index</i> will always
give you the same private key). This procedure is used to
derive many keypairs from a single user-managed piece of
data, so the user does not have to manage multiple private
keys. If the <i>index</i> is not specified it defaults to
<b>0</b>. The <b>-hex</b> and <b>-binary</b> options
determine the formatting of the result.</p>


<p style="margin-left:11%;"><b>::nano::key::publicKeyFromPrivateKey</b></p>

<p style="margin-left:22%;"><i>privateKey</i>
?<b>-hex</b>|<b>-binary</b>? -&gt; <i>publicKey</i></p>

<p style="margin-left:22%; margin-top: 1em">Converts a
private key into its corresponding public key. Normally
Ed25519 private keys are a concatencation of the private and
public keys, however in this package they are each treated
separately. The <b>-hex</b> and <b>-binary</b> options
determine the formatting of the result.</p>

<p style="margin-left:11%; margin-top: 1em"><b>Low-level
Block <br>

::nano::block::</b><i>representation</i><b>::toBlock</b></p>

<p style="margin-left:22%;"><i>blockRepresentation</i>
-&gt; <i>blockData</i></p>

<p style="margin-left:22%; margin-top: 1em">Converts from
one of the internal representations (either Tcl dictionary
or JSON) to a Nano block. The <i>representation</i> portion
of the command name may be one of <b>dict</b> or
<b>json</b>.</p>


<p style="margin-left:11%;"><b>::nano::block::json::fromDict</b></p>

<p style="margin-left:22%;"><i>blockDict</i> -&gt;
<i>blockJSON</i></p>

<p style="margin-left:22%; margin-top: 1em">Converts from a
Tcl dictionary representation to a JSON representation of a
block.</p>


<p style="margin-left:11%;"><b>::nano::block::dict::fromJSON</b></p>

<p style="margin-left:22%;"><i>blockJSON</i> -&gt;
<i>blockDict</i></p>

<p style="margin-left:22%; margin-top: 1em">Converts from a
JSON object representation to a Tcl dictionary
representation of a block.</p>


<p style="margin-left:11%;"><b>::nano::block::</b><i>representation</i><b>::fromBlock</b></p>

<p style="margin-left:22%;"><i>blockData</i>
?<b>-xrb</b>|<b>-nano</b>? ? <b>-type=</b><i>blockType</i> ?
? <b>-signKey=</b><i>privateKey</i> ? -&gt;
<i>blockRepresentation</i></p>

<p style="margin-left:22%; margin-top: 1em">Parses a Nano
block and returns either a Tcl dictionary or a JSON object.
The <b>-xrb</b> option causes all parsed addresses to be
prefixed with the old-style &quot;xrb_&quot; address prefix,
while the <b>-nano</b> option causes them to be prefixed
with the new-style &quot;nano_prefix&quot;. The
<i>representation</i> portion of the command name may be one
of <b>dict</b> or <b>json</b>.</p>


<p style="margin-left:11%;"><b>::nano::block::</b><i>representation</i><b>::sign</b></p>

<p style="margin-left:22%;"><i>blockRepresentation
privateKey</i> ?<b>-update</b>|<b>-signature</b>
?<b>-hex</b>|<b>binary</b>?? -&gt;
<i>signature</i>|<i>blockJSON</i></p>

<p style="margin-left:22%; margin-top: 1em">Sign a block,
in either Tcl dictionary or JSON representation, with the
specified <i>privateKey</i>. If the <b>-update</b> option is
used, return the object with the updated attribute. If the
<b>-signature</b> option is used, return just the signature.
The <b>-hex</b> and <b>-binary</b> options determine the
formatting of the result. The <i>representation</i> portion
of the command name may be one of <b>dict</b> or
<b>json</b>.</p>


<p style="margin-left:11%;"><b>::nano::block::</b><i>representation</i><b>::verifySignature</b></p>

<p style="margin-left:22%;"><i>blockRepresentation</i>
-&gt; <i>boolean</i></p>

<p style="margin-left:22%; margin-top: 1em">Verify the
signature on a block, in either Tcl dictionary or JSON
representation, matches the public key specified in the
<b>account</b> attribute of that object. This may not work
correctly for old-style blocks unless you manually add the
<b>account</b> attribute. The <i>representation</i> portion
of the command name may be one of <b>dict</b> or
<b>json</b>.</p>


<p style="margin-left:11%;"><b>::nano::block::</b><i>representation</i><b>::work</b></p>

<p style="margin-left:22%;"><i>blockRepresentation</i>
?<b>-update</b>|<b>-work</b> ?<b>-hex</b>|<b>binary</b>??
-&gt; <i>work</i>|<i>blockRepresentation</i></p>

<p style="margin-left:22%; margin-top: 1em">Generate
proof-of-work (PoW) required to submit a given block to the
network. Nano uses PoW to increase the cost of submitting
blocks to the network to cut down on spam. The <i>work</i>
that is computed is based on the hash of the previous block
on this chain, or if there is no previous block on this
chain (i.e., because it is the first block on an account)
the public key of the account. If the <b>-update</b> option
is used, return the object with the updated attribute. If
the <b>-work</b> option is used, just return the work. The
<b>-hex</b> and <b>-binary</b> options determine the
formatting of the result. The <i>representation</i> portion
of the command name may be one of <b>dict</b> or
<b>json</b>.</p>


<p style="margin-left:11%;"><b>::nano::block::</b><i>representation</i><b>::validateWork</b></p>

<p style="margin-left:22%;"><i>blockRepresentation</i>
-&gt; <i>boolean</i></p>

<p style="margin-left:22%; margin-top: 1em">Validate the
proof-of-work (PoW) in the object specified as
<i>blockRepresentation</i> with the attribute <b>work</b> is
valid for the block passed in. The <i>representation</i>
portion of the command name may be one of <b>dict</b> or
<b>json</b>.</p>

<p style="margin-left:11%;"><b>::nano::block::hash</b></p>

<p style="margin-left:22%;"><i>blockData</i>
?<b>-hex</b>|<b>-binary</b>? -&gt; <i>blockHash</i></p>

<p style="margin-left:22%; margin-top: 1em">Compute the
cryptographic hash of a block. The cryptographic hashing
algorithm used for Nano is Blake2b. Blocks are typically
identified by their hash (i.e., content addressable). The
<b>-hex</b> and <b>-binary</b> options determine the
formatting of the result.</p>


<p style="margin-left:11%;"><b>::nano::block::signBlockHash</b></p>

<p style="margin-left:22%;"><i>blockHash privateKey</i>
?<b>-hex</b>|<b>-binary</b>? -&gt; <i>signature</i></p>

<p style="margin-left:22%; margin-top: 1em">Compute an
Ed25519-with-Blake2b signature of a given block hash
specified as <i>blockHash</i> with the private key specified
as <i>privateKey</i>. In Nano, signed blocks are signed by
signing the block&rsquo;s hash thus all that is needed to
sign a block is its hash and the private key that
corresponds to the account. <b>NOTE: Ensure that the</b>
<i>privateKey</i> <b>specified matches the account the block
belongs to.</b> The <b>-hex</b> and <b>-binary</b> options
determine the formatting of the result.</p>

<p style="margin-left:11%;"><b>::nano::block::sign</b></p>

<p style="margin-left:22%;"><i>blockData privateKey</i>
?<b>-hex</b>|<b>-binary</b>? -&gt; <i>signature</i></p>

<p style="margin-left:22%; margin-top: 1em">This is a
convienence procedure which computes the hash of a block
given as <i>blockData</i>, and then calls
<b>signBlockHash</b>. The <b>-hex</b> and <b>-binary</b>
options determine the formatting of the result.</p>


<p style="margin-left:11%;"><b>::nano::block::verifyBlockHash</b></p>

<p style="margin-left:22%;"><i>blockHash signature
publicKey</i> -&gt; <i>boolean</i></p>

<p style="margin-left:22%; margin-top: 1em">Verify that a
block hash (<i>blockHash</i>) was signed (<i>signature</i>)
by an account holding the private key that corresponds to
the public key specified as <i>publicKey</i>.</p>


<p style="margin-left:11%;"><b>::nano::block::verify</b></p>

<p style="margin-left:22%;"><i>blockData signature
publicKey</i> -&gt; <i>boolean</i></p>

<p style="margin-left:22%; margin-top: 1em">This is a
convienence procedure which computes the hash of a block
given as <i>blockData</i>, and then calls
<b>verifyBlockHash</b>.</p>


<p style="margin-left:11%;"><b>::nano::block::create::send</b></p>

<p style="margin-left:22%;"><b>from</b> <i>address</i>
<b>to</b> <i>address</i> <b>previous</b> <i>blockHash</i>
<b>representative</b> <i>address</i> <b>previousBalance</b>
<i>integer</i> <b>amount</b> <i>integer</i> ? <b>-json</b>
<i>boolean</i> ? -&gt; <i>blockJSON</i>|<i>blockDict</i></p>

<p style="margin-left:22%; margin-top: 1em">This is a
low-level interface for creating blocks which correspond to
sending Nano from one account to another. It constructs a
block which sends the <b>amount</b> specified from the
<b>from</b> address to the destination (<b>to</b>). The
previous block&rsquo;s hash must be specified as the
<i>blockHash</i> following <b>previous</b>. Additionally the
balance of the account at the previous block must be
supplied as the integer argument to <b>previousBalance</b>.
All balance amounts are in units of <b>raw</b>. If the
optional <b>-json</b> argument is used and specified as true
the result is a JSON representation, otherwise a Tcl dict
representation is used.</p>


<p style="margin-left:11%;"><b>::nano::block::create::receive</b></p>

<p style="margin-left:22%;"><b>to</b> <i>address</i>
<b>sourceBlock</b> <i>blockHash</i> <b>previous</b>
<i>blockHash</i> <b>representative</b> <i>address</i>
<b>previousBalance</b> <i>integer</i> <b>amount</b>
<i>integer</i> ? <b>-json</b> <i>boolean</i> ? -&gt;
<i>blockJSON</i>|<i>blockDict</i></p>

<p style="margin-left:22%; margin-top: 1em">This is a
low-level interface for creating blocks which correspond to
receiving (pocketing) Nano previously sent from another
account to the account specified as the <i>address</i>
supplied to the <b>to</b> argument. It constructs a block
which receives the amount of Nano specified as the
<b>amount</b> argument. The block hash (<i>blockHash</i>) of
the send block which was used to send the Nano to this
account must be specified as the argument to the
<b>sourceBlock</b> option. The previous block&rsquo;s hash
must be specified as the <i>blockHash</i> following
<b>previous</b>. Additionally the balance of the account at
the previous block must be supplied as the integer argument
to <b>previousBalance</b>. All balance amounts are in units
of <b>raw</b>. If the optional <b>-json</b> argument is used
and specified as true the result is a JSON representation,
otherwise a Tcl dict representation is used.</p>


<p style="margin-left:11%;"><b>::nano::block::create::setRepresentative</b></p>

<p style="margin-left:22%;"><b>account</b> <i>address</i>
<b>previous</b> <i>blockHash</i> <b>representative</b>
<i>address</i> ? <b>-json</b> <i>boolean</i> ? -&gt;
<i>blockJSON</i>|<i>blockDict</i></p>

<p style="margin-left:22%; margin-top: 1em">This is a
low-level interface for creating blocks which correspond to
an explicit change of representative. Representatives in
Nano are used as part of the Delegated Proof-of-Stake (dPoS)
consensus mechanism which is used by the Nano network to
determine which block (if any) out of many possible
subordinate blocks in a chain are valid. So that every
account holder does not have to be online to vote for valid
transactions, an account may delegate another account to
vote its stake on its behalf. That delegate is called a
representative. An account may change its representative at
any time by issuing a block with a new representative, such
as a send or receive block, or by issuing an explicit change
of representative block. This procedure creates an explicit
change of representative block for the <b>account</b>
specified. It changes to the delegate to the
<b>representative</b> specified. Further, the
<i>blockHash</i> of the previous block must be specified as
the argument to <b>previous</b>. If the optional
<b>-json</b> argument is used and specified as true the
result is a JSON representation, otherwise a Tcl dict
representation is used.</p>

<p style="margin-left:11%; margin-top: 1em"><b>Work
Generation <br>
::nano::work::fromWorkData</b></p>

<p style="margin-left:22%;"><i>blockHashOrPublicKey</i>
-&gt; <i>work</i></p>

<p style="margin-left:22%; margin-top: 1em">Create
proof-of-work (PoW) from a block hash or public key. Which
one is used depends on whether or not there are any other
blocks in this account&rsquo;s chain. If this is the first
block in this account&rsquo;s chain then the public key of
the account is used, otherwise the hash of the blocks
predecessor (<i>previous</i>) is used. The specific value
needed should be accessible from the <b>_workData</b> member
of a JSON object or Tcl dictionary. Note that this attribute
(and all attributes that begin with an underscore) should be
discarded when sending the block outside of the Tcl
process.</p>


<p style="margin-left:11%;"><b>::nano::work::fromBlock</b></p>

<p style="margin-left:22%;"><i>blockData</i> -&gt;
<i>work</i></p>

<p style="margin-left:22%; margin-top: 1em">This is a
convienence procedure which computes work data (either a
block hash or a public key) for a given block and then calls
<b>fromWorkData</b>.</p>


<p style="margin-left:11%;"><b>::nano::work::validate</b></p>

<p style="margin-left:22%;"><i>workData work</i> -&gt;
<i>boolean</i></p>

<p style="margin-left:22%; margin-top: 1em">This procedure
validates that the supplied <i>work</i> is valid for the
supplied <i>workData</i>, which is either a block hash or an
account public key. For more information see the description
of <b>fromWorkData</b>.</p>

<p style="margin-left:11%; margin-top: 1em"><b>High-level
Account <br>
:nano::account::setFrontier</b></p>

<p style="margin-left:22%;"><i>account frontierHash balance
representative</i></p>

<p style="margin-left:22%; margin-top: 1em">This procedure
is used as part of the High-level Account interface. It sets
the <i>frontier</i>, which is the block hash
(<i>frontierHash</i>) and data (<i>balance</i>,
<i>representative</i>) associated with that block that
corresponds to the head of an account&rsquo;s chain.</p>


<p style="margin-left:11%;"><b>:nano::account::getFrontier</b></p>

<p style="margin-left:22%;"><i>account</i> -&gt;
<i>frontierInfo</i></p>

<p style="margin-left:22%; margin-top: 1em">This procedure
is used as part of the High-level Account interface. It gets
the Tcl dictionary associated with the frontier most
recently set for the specified <i>account</i>.</p>


<p style="margin-left:11%;"><b>:nano::account::getFrontier</b></p>

<p style="margin-left:22%;"><i>account</i>
?<b>frontierHash</b>|<b>balance</b>|<b>representative</b>?
-&gt;
<i>frontierHash</i>|<i>balance</i>|<i>representative</i></p>

<p style="margin-left:22%; margin-top: 1em">This procedure
is used as part of the High-level Account interface. It gets
a specific item from Tcl dictionary associated with the
frontier most recently set for the specified
<i>account</i>.</p>


<p style="margin-left:11%;"><b>:nano::account::addPending</b></p>

<p style="margin-left:22%;"><i>account blockHash
amount</i></p>

<p style="margin-left:22%; margin-top: 1em">This procedure
is used as part of the High-level Account interface. It is
used to indicate than a given <i>account</i> has a
<b>receive</b> block that they could create. The block hash
of the corresponding <b>send</b> block should be supplied as
the <i>blockHash</i> parameter. The amount of Nano that was
sent in the <b>send</b> block should be specified as the
<i>amount</i> parameter (in units of raw).</p>


<p style="margin-left:11%;"><b>:nano::account::getPending</b></p>

<p style="margin-left:22%;"><i>account</i>
?<i>blockHash</i>? -&gt; <i>dict</i></p>

<p style="margin-left:22%; margin-top: 1em">This procedure
is used as part of the High-level Account interface. It is
used to retrieve information stored by <b>addPending</b> for
a given <i>account</i>. If the <i>blockHash</i> parameter is
supplied then a Tcl dictionary is returned with a key called
<b>amount</b> which contains the amount stored previously.
If the <i>blockHash</i> parameter is not supplied then a Tcl
dictionary is returned with keys corresponding to each block
hash pending for the specified <i>account</i>, and
containing a subordinate Tcl dictionary with a key called
<b>amount</b> as previously described.</p>


<p style="margin-left:11%;"><b>::nano::account::clearPending</b></p>

<p style="margin-left:22%;"><i>account</i>
?<i>blockHash</i>?</p>

<p style="margin-left:22%; margin-top: 1em">This procedure
is used as part of the High-level Account interface. It is
used to clear (that is, remove from the conceptual state of
&quot;pending&quot;) entries created previously with
<b>addPending</b> for a given <i>account</i>. If the
<i>blockHash</i> parameter is supplied then only the entry
corresponding to that blockhash is cleared, otherwise all
entries for the specified <i>account</i> are cleared.</p>


<p style="margin-left:11%;"><b>:nano::account::receive</b></p>

<p style="margin-left:22%;"><i>account blockHash
privateKey</i> -&gt; <i>blockJSON</i>|<i>blockDict</i></p>

<p style="margin-left:22%; margin-top: 1em">This procedure
is used as part of the High-level Account interface. It is
used to generate a receive block. Its interface is subject
to change and not considered stable.</p>


<p style="margin-left:11%;"><b>:nano::account::receiveAllPending</b></p>

<p style="margin-left:22%;"><i>account privateKey</i> -&gt;
<i>listOfBlockJSON</i>|<i>listOfBlockDict</i></p>

<p style="margin-left:22%; margin-top: 1em">This procedure
is used as part of the High-level Account interface. It is
used to generate receive blocks for every pending receive on
a given <i>account</i>. Its interface is subject to change
and not considered stable.</p>


<p style="margin-left:11%;"><b>:nano::account::send</b></p>

<p style="margin-left:22%;"><i>fromAccount toAccount amount
privateKey</i> -&gt; <i>blockJSON</i>|<i>blockDict</i></p>

<p style="margin-left:22%; margin-top: 1em">This procedure
is used as part of the High-level Account interface. It is
used to generate a send block. Its interface is subject to
change and not considered stable.</p>


<p style="margin-left:11%;"><b>::nano::account::setRepresentative</b></p>

<p style="margin-left:22%;"><i>account representative
privateKey</i> -&gt; <i>blockJSON</i>|<i>blockDict</i></p>

<p style="margin-left:22%; margin-top: 1em">This procedure
is used as part of the High-level Account interface. It is
used to generate a block that changes the representative for
the given <i>account</i>. Its interface is subject to change
and not considered stable.</p>

<h2>EXAMPLES
<a name="EXAMPLES"></a>
</h2>


<p style="margin-left:11%; margin-top: 1em"><b>Example
1</b></p>
<pre style="margin-left:11%;">package require nano 1.0

set seed &#91;::nano::key::newSeed -hex&#93;
puts &quot;Generated seed: $seed&quot;


for {set index 0} {$index &lt; 10} {incr index} {
     set accountPrivateKey &#91;::nano::key::fromSeed $seed $index -hex&#93;
     set accountAddress &#91;::nano::address::fromPrivateKey $accountPrivateKey&#93;
     puts &quot;    - $index: $accountAddress&quot;
}</pre>


<p style="margin-left:11%; margin-top: 1em"><b>Example 2
<br>
Example 3</b></p>

<h2>AUTHOR
<a name="AUTHOR"></a>
</h2>


<p style="margin-left:11%;">Roy Keene
&lt;<i>rkeene@nano.org</i>&gt;</p>
<hr>