Posted to tcl by stu at Tue Jul 17 14:39:15 GMT 2018view raw
- NANO(N) NANO(N)
- NNAAMMEE
- nano - Tcl bindings for Nano
- SSYYNNOOPPSSIISS
- nnaannoo::::
- aaddddrreessss::::
- ttooPPuubblliiccKKeeyy _a_d_d_r_e_s_s ?--hheexx|--bbiinnaarryy? ?--vveerriiffyy|--nnoo--vveerriiffyy?
- ffrroommPPuubblliiccKKeeyy _p_u_b_K_e_y ?--xxrrbb|--nnaannoo?
- ffrroommPPrriivvaatteeKKeeyy _p_r_i_v_a_t_e_K_e_y ?--xxrrbb|--nnaannoo?
- kkeeyy::::
- nneewwSSeeeedd ?--hheexx|--bbiinnaarryy?
- nneewwKKeeyy ?--hheexx|--bbiinnaarryy?
- ffrroommSSeeeedd _s_e_e_d ?_i_n_d_e_x? ?--hheexx|--bbiinnaarryy?
- ppuubblliiccKKeeyyFFrroommPPrriivvaatteeKKeeyy _p_r_i_v_a_t_e_K_e_y ?--hheexx|--bbiinnaarryy?
- bblloocckk::::
- jjssoonn::::ttooBBlloocckk _b_l_o_c_k_J_S_O_N
- jjssoonn::::ffrroommDDiicctt _b_l_o_c_k_D_i_c_t
- jjssoonn::::ffrroommBBlloocckk _b_l_o_c_k_D_a_t_a ?--xxrrbb|--nnaannoo? ? --ttyyppee==_b_l_o_c_k_T_y_p_e ? ?
- --ssiiggnnKKeeyy==_p_r_i_v_a_t_e_K_e_y ?
- jjssoonn::::ssiiggnn _b_l_o_c_k_J_S_O_N _p_r_i_v_a_t_e_K_e_y ?--uuppddaattee|--ssiiggnnaattuurree ?--hheexx|bbiinnaarryy??
- jjssoonn::::vveerriiffyySSiiggnnaattuurree _b_l_o_c_k_J_S_O_N
- jjssoonn::::wwoorrkk _b_l_o_c_k_J_S_O_N ?--uuppddaattee|--wwoorrkk ?--hheexx|--bbiinnaarryy??
- jjssoonn::::vvaalliiddaatteeWWoorrkk _b_l_o_c_k_J_S_O_N
- jjssoonn::::ffiilltteerr _b_l_o_c_k_J_S_O_N
- ddiicctt::::ttooBBlloocckk _b_l_o_c_k_D_i_c_t
- ddiicctt::::ffrroommJJSSOONN _b_l_o_c_k_J_S_O_N
- ddiicctt::::ffrroommBBlloocckk _b_l_o_c_k_D_a_t_a ?--xxrrbb|--nnaannoo? ? --ttyyppee==_b_l_o_c_k_T_y_p_e ? ?
- --ssiiggnnKKeeyy==_p_r_i_v_a_t_e_K_e_y ?
- ddiicctt::::ssiiggnn _b_l_o_c_k_D_i_c_t _p_r_i_v_a_t_e_K_e_y ?--uuppddaattee|--ssiiggnnaattuurree ?--hheexx|bbiinnaarryy??
- ddiicctt::::vveerriiffyySSiiggnnaattuurree _b_l_o_c_k_D_i_c_t
- ddiicctt::::wwoorrkk _b_l_o_c_k_D_i_c_t ?--uuppddaattee|--wwoorrkk ?--hheexx|--bbiinnaarryy??
- ddiicctt::::vvaalliiddaatteeWWoorrkk _b_l_o_c_k_D_i_c_t
- hhaasshh _b_l_o_c_k_D_a_t_a ?--hheexx|--bbiinnaarryy?
- ssiiggnnBBlloocckkHHaasshh _b_l_o_c_k_H_a_s_h _p_r_i_v_a_t_e_K_e_y ?--hheexx|--bbiinnaarryy?
- ssiiggnn _b_l_o_c_k_D_a_t_a _p_r_i_v_a_t_e_K_e_y ?--hheexx|--bbiinnaarryy?
- vveerriiffyyBBlloocckkHHaasshh _b_l_o_c_k_H_a_s_h _s_i_g_n_a_t_u_r_e _p_u_b_l_i_c_K_e_y
- vveerriiffyy _b_l_o_c_k_D_a_t_a _s_i_g_n_a_t_u_r_e _p_u_b_l_i_c_K_e_y
- ccrreeaattee::::sseenndd _a_r_g_s
- ccrreeaattee::::rreecceeiivvee _a_r_g_s
- ccrreeaattee::::sseettRReepprreesseennttaattiivvee _a_r_g_s
- wwoorrkk::::
- ffrroommWWoorrkkDDaattaa _b_l_o_c_k_H_a_s_h_O_r_P_u_b_l_i_c_K_e_y ?--hheexx|--bbiinnaarryy?
- ffrroommBBlloocckk _b_l_o_c_k_D_a_t_a
- vvaalliiddaattee _w_o_r_k_D_a_t_a _w_o_r_k
- aaccccoouunntt::::
- sseettFFrroonnttiieerr _a_c_c_o_u_n_t _f_r_o_n_t_i_e_r_H_a_s_h _b_a_l_a_n_c_e _r_e_p_r_e_s_e_n_t_a_t_i_v_e
- ggeettFFrroonnttiieerr _a_c_c_o_u_n_t
- ggeettFFrroonnttiieerr _a_c_c_o_u_n_t ?ffrroonnttiieerrHHaasshh|bbaallaannccee|rreepprreesseennttaattiivvee?
- aaddddPPeennddiinngg _a_c_c_o_u_n_t _b_l_o_c_k_H_a_s_h _a_m_o_u_n_t
- ggeettPPeennddiinngg _a_c_c_o_u_n_t ?_b_l_o_c_k_H_a_s_h?
- cclleeaarrPPeennddiinngg _a_c_c_o_u_n_t ?_b_l_o_c_k_H_a_s_h?
- rreecceeiivvee _a_c_c_o_u_n_t _b_l_o_c_k_H_a_s_h _p_r_i_v_a_t_e_K_e_y
- rreecceeiivveeAAllllPPeennddiinngg _a_c_c_o_u_n_t _p_r_i_v_a_t_e_K_e_y
- sseenndd _f_r_o_m_A_c_c_o_u_n_t _t_o_A_c_c_o_u_n_t _a_m_o_u_n_t _p_r_i_v_a_t_e_K_e_y
- sseettRReepprreesseennttaattiivvee _a_c_c_o_u_n_t _r_e_p_r_e_s_e_n_t_a_t_i_v_e _p_r_i_v_a_t_e_K_e_y
- IINNTTRROODDUUCCTTIIOONN
- _N_a_n_o is a low-latency payment platform that requires minimal resources,
- relying on a peer-to-peer network to distribute "blocks", which are
- cryptographically signed transactions. This package provides bindings
- for interacting with the Nano network from _T_c_l.
- 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.
- Nano implements a "blockchain", which is a cryptographic linked-list,
- by identifying every "block" by its cryptographic hash and providing a
- pointer from every block to its predecessor in the "chain" as part of
- the hashed data.
- This predecessors is referred to here as the "previous" block. In
- Nano, each account has its own blockchain and they reference each other
- using a data structure referred to as "block lattice", 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 "link"
- field or "source block hash".
- Each Nano block also encapsulates the full state of the account,
- containing, at a minimum, a tuple of (_a_c_c_o_u_n_t, _b_a_l_a_n_c_e, _r_e_p_r_e_s_e_n_t_a_t_i_v_e,
- _p_r_e_v_i_o_u_s).
- Since Nano blocks are signed by independent actors, who may, for their
- own gain, generate multiple valid blocks referring to the same
- predecessor (_p_r_e_v_i_o_u_s) 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'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.
- Nano utilizes a mechanism called _v_o_t_i_n_g to determine which blocks are
- valid and which blocks are not valid. Each stakeholder votes their
- stake upon seeing a new subordinate block (_i_._e_., a block with a unique
- _p_r_e_v_i_o_u_s 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 inconvenient or impossible,
- stakeholders may select another stakeholder to vote their share of the
- network. This delegate is referred to as a _r_e_p_r_e_s_e_n_t_a_t_i_v_e.
- Representatives should be chosen carefully by stakeholders since
- malicious representatives may attempt to gather voting power and
- destabilize the Nano network by altering decisions made by consensus
- previously.
- Nano accounts are referred to by address. A Nano address starts with
- the prefix "nnaannoo__" or "xxrrbb__". 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.
- 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 _w_a_l_l_e_t. A _w_a_l_l_e_t is a conceptual entity that is used to
- refer to a _s_e_e_d, which is a random 256-bit number that can be used to
- derive multiple private/public keypairs from.
- 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 "_r_a_w". The most common unit for users to use is called
- "_N_a_n_o", one of which is equal to 1e30 raw.
- AAddddrreesssseess
- Nano addresses are composed of a prefix (either "nnaannoo__" or "xxrrbb__") and
- 300 bits of base32 encoded data. The 300-bits of base32 encoded data
- produce a string that is 6 characters long using the base32 alphabet
- 1133445566778899aabbccddeeffgghhiijjkkmmnnooppqqrrssttuuwwxxyyzz. The format of these 300 bits are
- struct {
- uint4_t padding = 0000b;
- uint256_t publicKey;
- uint40_t checksum;
- }
- The checksum is computed as a 5 byte (40 bit) Blake2b hash of the
- 256-bit public key (in binary format), followed by reversing the bytes.
- For example the public key
- DDCC11551122115544EEBB7722111122BB88CCCC223300DD77BB88CC77DDDD446677DDAA7788EE44776633118822DD66CCAAFFAAAADDBB1144885555AA55EE88 which
- has a 5-byte Blake2b hash of {{00xx1188,, 00xx7744,, 00xxAA33,, 00xx4466,, 00xx99CC}} would be
- encoded as
- 00000000..DDCC11551122115544EEBB7722111122BB88CCCC223300DD77BB88CC77DDDD446677DDAA7788EE44776633118822DD66CCAAFFAAAADDBB1144885555AA55EE88..99CC4466AA3377441188
- which when encoded in base32 and the prefix added produces the address
- nnaannoo__33qq11oo44aaccnnxxffss3344ccwweerraarrffhhgg8899uuoo5599uubbwwggaaxxjjjjiiddddeeooyyooffpp776677ddbbhhaammjj55cc88xx11rr.
- NNeettwwoorrkk
- The Nano network consists of two different peer-to-peer networks. One
- for real-time block updates over UDP, and another for bulk ledger
- updates over TCP (_b_o_o_t_s_t_r_a_p_p_i_n_g). The real-time network is a broadcast
- style network where every message sent over it are relayed to all other
- nodes.
- The customary and default port for the real-time/UDP network is
- 7075/udp, while the default port for the bootstrapping/TCP network is
- 7075/tcp.
- The format of the messages on both networks is the same, however not
- every type of message may be used on either network. The kkeeeeppaalliivvee
- message type is invalid on the TCP (bootstrapping) network and the
- bbuullkk__ppuullll message type is invalid on the UDP (real-time) network. The
- format of message are an 8 byte header consisting of:
- struct {
- uint8_t magicProtocol = 0x52;
- uint8_t magicNetwork = 0x41/0x42/0x43;
- uint8_t versionMax;
- uint8_t version;
- uint8_t versionMin;
- uint8_t messageType;
- uint16_t extensions;
- };
- Where the mmaaggiiccPPrroottooccooll field must be the value 00xx5522 (which is ASCII
- 'R') and the mmaaggiiccNNeettwwoorrkk field must be one of 00xx4411, 00xx4422, or 00xx4433
- corresponding to one of the three Nano networks. A value of 00xx4411
- (ASCII 'A') represents the Test network; A value of 00xx4422 (ASCII 'B')
- represents the Beta network; A value of 00xx4433 (ASCII 'C') represents
- the Main network.
- The various version fields control the relaying of the message to nodes
- running various versions of the Nano network protocol (distinct from
- the Nano reference implementation version). The vveerrssiioonnMMaaxx and
- vveerrssiioonnMMiinn fields indicate the inclusive range of acceptable versions
- to relay or broadcast this message to. The vveerrssiioonn field indicates
- what version of the Nano protocol this node is using.
- The messageType field indicates what type of message is being relayed,
- and must conform to the following enumeration
- +------------+------------------+--------------+-------------+
- |mmeessssaaggeeTTyyppee | NNaammee | OOnn BBoooottssttrraapp | OOnn RReeaallttiimmee |
- +------------+------------------+--------------+-------------+
- | 0x00 | Invalid | Yes | Yes |
- +------------+------------------+--------------+-------------+
- | 0x01 | Not_A_Type | ? | ? |
- +------------+------------------+--------------+-------------+
- | 0x02 | Keepalive | No | Yes |
- +------------+------------------+--------------+-------------+
- | 0x03 | Publish | No | Yes |
- +------------+------------------+--------------+-------------+
- | 0x04 | Confirm_Req | No | Yes |
- +------------+------------------+--------------+-------------+
- | 0x05 | Confirm_Ack | No | Yes |
- +------------+------------------+--------------+-------------+
- | 0x06 | Bulk_Pull | Yes | No |
- +------------+------------------+--------------+-------------+
- | 0x07 | Bulk_Push | Yes | No |
- +------------+------------------+--------------+-------------+
- | 0x08 | Frontier_Req | Yes | No |
- +------------+------------------+--------------+-------------+
- | 0x09 | Bulk_Pull_Blocks | Yes | No |
- +------------+------------------+--------------+-------------+
- TTOODDOO:: EExxtteennssiioonnss
- Following the message header comes the payload for the particular
- message type.
- IInnvvaalliidd
- TODOC
- NNoott__AA__TTyyppee
- TODOC
- KKeeeeppaalliivvee
- The Keepalive message requires exactly 8 IPv6 address and port
- number tuples to be sent as its payload. The IPv6 addresses are
- each 128-bits (16-bytes) long and the port numbers are 16-bit
- integers sent in network byte order. The payload for the
- Keepalive message type is 144 bytes in size.
- PPuubblliisshh
- TODOC
- CCoonnffiirrmm__RReeqq
- TODOC
- CCoonnffiirrmm__AAcckk
- TODOC
- BBuullkk__PPuullll
- TODOC
- BBuullkk__PPuusshh
- TODOC
- FFrroonnttiieerr__RReeqq
- TODOC
- BBuullkk__PPuullll__BBlloocckkss
- TODOC
- PPRROOCCEEDDUURREESS
- AAddddrreesssseess
- ::::nnaannoo::::aaddddrreessss::::ttooPPuubblliiccKKeeyy
- _a_d_d_r_e_s_s ?--hheexx|--bbiinnaarryy? ?--vveerriiffyy|--nnoo--vveerriiffyy? -->> _p_u_b_l_i_c_K_e_y
- Converts a Nano address to a public key. The --hheexx option
- indicates that the public key should be returned in hexadecimal
- form. The --bbiinnaarryy option indicates that the public key should
- be returned in binary form. The --vveerriiffyy option verifies the
- checksum embedded in the Nano address before returning. The
- --nnoo--vveerriiffyy option inhibits verifying the checksum embedded in
- the Nano address.
- ::::nnaannoo::::aaddddrreessss::::ffrroommPPuubblliiccKKeeyy
- _p_u_b_K_e_y ?--xxrrbb|--nnaannoo? -->> _a_d_d_r_e_s_s
- Converts a public key to a Nano address. The --xxrrbb option
- specifies that the returned address should be prefixed with the
- old-style "xrb_" prefix, where the --nnaannoo option specifies that
- the returned address should be prefixed with the new-style
- "nano_" prefix.
- ::::nnaannoo::::aaddddrreessss::::ffrroommPPrriivvaatteeKKeeyy
- _p_r_i_v_a_t_e_K_e_y ?--xxrrbb|--nnaannoo? -->> _a_d_d_r_e_s_s
- Converts a private key to a Nano address. It accepts the same
- arguments as ffrroommPPuubblliiccKKeeyy.
- KKeeyy MMaannaaggeemmeenntt
- ::::nnaannoo::::kkeeyy::::nneewwSSeeeedd
- ?--hheexx|--bbiinnaarryy? -> _s_e_e_d
- Generates a new seed. A seed is a 256-bit bit-field which,
- along with a 32-bit index, is used to derive enumerated keys
- from a single point of entropy. See the ffrroommSSeeeedd procedure.
- The --hheexx and --bbiinnaarryy options determine the formatting of the
- result.
- ::::nnaannoo::::kkeeyy::::nneewwKKeeyy
- ?--hheexx|--bbiinnaarryy? -> _p_r_i_v_a_t_e_K_e_y
- Generates a new private key. A private key can be used to sign
- transactions, which can then be verified with its corresponding
- public key (see ppuubblliiccKKeeyyFFrroommPPrriivvaatteeKKeeyy). This procedure is
- normally not used, but rather private keys are derived from a
- _s_e_e_d and _i_n_d_e_x pair using the ffrroommSSeeeedd procedure. The --hheexx and
- --bbiinnaarryy options determine the formatting of the result.
- ::::nnaannoo::::kkeeyy::::ffrroommSSeeeedd
- _s_e_e_d ?_i_n_d_e_x? ?--hheexx|--bbiinnaarryy? -> _p_r_i_v_a_t_e_K_e_y
- Derive a private key from the seed specified as _s_e_e_d and the
- _i_n_d_e_x indicated. This procedure is deterministic (i.e., the
- same _s_e_e_d and _i_n_d_e_x 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_n_d_e_x is not specified it
- defaults to 00. The --hheexx and --bbiinnaarryy options determine the
- formatting of the result.
- ::::nnaannoo::::kkeeyy::::ppuubblliiccKKeeyyFFrroommPPrriivvaatteeKKeeyy
- _p_r_i_v_a_t_e_K_e_y ?--hheexx|--bbiinnaarryy? -> _p_u_b_l_i_c_K_e_y
- Converts a private key into its corresponding public key.
- Normally Ed25519 private keys are a concatenation of the private
- and public keys, however in this package they are each treated
- separately. The --hheexx and --bbiinnaarryy options determine the
- formatting of the result.
- LLooww--lleevveell BBlloocckk
- ::::nnaannoo::::bblloocckk::::_r_e_p_r_e_s_e_n_t_a_t_i_o_n::::ttooBBlloocckk
- _b_l_o_c_k_R_e_p_r_e_s_e_n_t_a_t_i_o_n -> _b_l_o_c_k_D_a_t_a
- Converts from one of the internal representations (either Tcl
- dictionary or JSON) to a Nano block. The _r_e_p_r_e_s_e_n_t_a_t_i_o_n portion
- of the command name may be one of ddiicctt or jjssoonn.
- ::::nnaannoo::::bblloocckk::::jjssoonn::::ffrroommDDiicctt
- _b_l_o_c_k_D_i_c_t -> _b_l_o_c_k_J_S_O_N
- Converts from a Tcl dictionary representation to a JSON
- representation of a block.
- ::::nnaannoo::::bblloocckk::::jjssoonn::::ffiilltteerr
- _b_l_o_c_k_J_S_O_N -> _b_l_o_c_k_J_S_O_N
- Filters out JSON object attributes which are not suitable for
- using with other implementations, such as ___c_o_m_m_e_n_t, ___w_o_r_k_D_a_t_a,
- and ___b_l_o_c_k_H_a_s_h.
- ::::nnaannoo::::bblloocckk::::ddiicctt::::ffrroommJJSSOONN
- _b_l_o_c_k_J_S_O_N -> _b_l_o_c_k_D_i_c_t
- Converts from a JSON object representation to a Tcl dictionary
- representation of a block.
- ::::nnaannoo::::bblloocckk::::_r_e_p_r_e_s_e_n_t_a_t_i_o_n::::ffrroommBBlloocckk
- _b_l_o_c_k_D_a_t_a ?--xxrrbb|--nnaannoo? ? --ttyyppee==_b_l_o_c_k_T_y_p_e ? ?
- --ssiiggnnKKeeyy==_p_r_i_v_a_t_e_K_e_y ? -> _b_l_o_c_k_R_e_p_r_e_s_e_n_t_a_t_i_o_n
- Parses a Nano block and returns either a Tcl dictionary or a
- JSON object. The --xxrrbb option causes all parsed addresses to be
- prefixed with the old-style "xrb_" address prefix, while the
- --nnaannoo option causes them to be prefixed with the new-style
- "nano_prefix". The _r_e_p_r_e_s_e_n_t_a_t_i_o_n portion of the command name
- may be one of ddiicctt or jjssoonn.
- ::::nnaannoo::::bblloocckk::::_r_e_p_r_e_s_e_n_t_a_t_i_o_n::::ssiiggnn
- _b_l_o_c_k_R_e_p_r_e_s_e_n_t_a_t_i_o_n _p_r_i_v_a_t_e_K_e_y ?--uuppddaattee|--ssiiggnnaattuurree
- ?--hheexx|bbiinnaarryy?? -> _s_i_g_n_a_t_u_r_e|_b_l_o_c_k_J_S_O_N
- Sign a block, in either Tcl dictionary or JSON representation,
- with the specified _p_r_i_v_a_t_e_K_e_y. If the --uuppddaattee option is used,
- return the object with the updated attribute. If the --ssiiggnnaattuurree
- option is used, return just the signature. The --hheexx and --bbiinnaarryy
- options determine the formatting of the result. The
- _r_e_p_r_e_s_e_n_t_a_t_i_o_n portion of the command name may be one of ddiicctt or
- jjssoonn.
- ::::nnaannoo::::bblloocckk::::_r_e_p_r_e_s_e_n_t_a_t_i_o_n::::vveerriiffyySSiiggnnaattuurree
- _b_l_o_c_k_R_e_p_r_e_s_e_n_t_a_t_i_o_n -> _b_o_o_l_e_a_n
- Verify the signature on a block, in either Tcl dictionary or
- JSON representation, matches the public key specified in the
- aaccccoouunntt attribute of that object. This may not work correctly
- for old-style blocks unless you manually add the aaccccoouunntt
- attribute. The _r_e_p_r_e_s_e_n_t_a_t_i_o_n portion of the command name may
- be one of ddiicctt or jjssoonn.
- ::::nnaannoo::::bblloocckk::::_r_e_p_r_e_s_e_n_t_a_t_i_o_n::::wwoorrkk
- _b_l_o_c_k_R_e_p_r_e_s_e_n_t_a_t_i_o_n ?--uuppddaattee|--wwoorrkk ?--hheexx|bbiinnaarryy?? ->
- _w_o_r_k|_b_l_o_c_k_R_e_p_r_e_s_e_n_t_a_t_i_o_n
- 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 _w_o_r_k 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 --uuppddaattee option is used, return the object
- with the updated attribute. If the --wwoorrkk option is used, just
- return the work. The --hheexx and --bbiinnaarryy options determine the
- formatting of the result. The _r_e_p_r_e_s_e_n_t_a_t_i_o_n portion of the
- command name may be one of ddiicctt or jjssoonn.
- ::::nnaannoo::::bblloocckk::::_r_e_p_r_e_s_e_n_t_a_t_i_o_n::::vvaalliiddaatteeWWoorrkk
- _b_l_o_c_k_R_e_p_r_e_s_e_n_t_a_t_i_o_n -> _b_o_o_l_e_a_n
- Validate the proof-of-work (PoW) in the object specified as
- _b_l_o_c_k_R_e_p_r_e_s_e_n_t_a_t_i_o_n with the attribute wwoorrkk is valid for the
- block passed in. The _r_e_p_r_e_s_e_n_t_a_t_i_o_n portion of the command name
- may be one of ddiicctt or jjssoonn.
- ::::nnaannoo::::bblloocckk::::hhaasshh
- _b_l_o_c_k_D_a_t_a ?--hheexx|--bbiinnaarryy? -> _b_l_o_c_k_H_a_s_h
- 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 --hheexx and --bbiinnaarryy options determine the formatting of the
- result.
- ::::nnaannoo::::bblloocckk::::ssiiggnnBBlloocckkHHaasshh
- _b_l_o_c_k_H_a_s_h _p_r_i_v_a_t_e_K_e_y ?--hheexx|--bbiinnaarryy? -> _s_i_g_n_a_t_u_r_e
- Compute an Ed25519-with-Blake2b signature of a given block hash
- specified as _b_l_o_c_k_H_a_s_h with the private key specified as
- _p_r_i_v_a_t_e_K_e_y. In Nano, signed blocks are signed by signing the
- block's hash thus all that is needed to sign a block is its hash
- and the private key that corresponds to the account. NNOOTTEE::
- EEnnssuurree tthhaatt tthhee _p_r_i_v_a_t_e_K_e_y ssppeecciiffiieedd mmaattcchheess tthhee aaccccoouunntt tthhee
- bblloocckk bbeelloonnggss ttoo.. The --hheexx and --bbiinnaarryy options determine the
- formatting of the result.
- ::::nnaannoo::::bblloocckk::::ssiiggnn
- _b_l_o_c_k_D_a_t_a _p_r_i_v_a_t_e_K_e_y ?--hheexx|--bbiinnaarryy? -> _s_i_g_n_a_t_u_r_e
- This is a convenience procedure which computes the hash of a
- block given as _b_l_o_c_k_D_a_t_a, and then calls ssiiggnnBBlloocckkHHaasshh. The
- --hheexx and --bbiinnaarryy options determine the formatting of the result.
- ::::nnaannoo::::bblloocckk::::vveerriiffyyBBlloocckkHHaasshh
- _b_l_o_c_k_H_a_s_h _s_i_g_n_a_t_u_r_e _p_u_b_l_i_c_K_e_y -> _b_o_o_l_e_a_n
- Verify that a block hash (_b_l_o_c_k_H_a_s_h) was signed (_s_i_g_n_a_t_u_r_e) by
- an account holding the private key that corresponds to the
- public key specified as _p_u_b_l_i_c_K_e_y.
- ::::nnaannoo::::bblloocckk::::vveerriiffyy
- _b_l_o_c_k_D_a_t_a _s_i_g_n_a_t_u_r_e _p_u_b_l_i_c_K_e_y -> _b_o_o_l_e_a_n
- This is a convenience procedure which computes the hash of a
- block given as _b_l_o_c_k_D_a_t_a, and then calls vveerriiffyyBBlloocckkHHaasshh.
- ::::nnaannoo::::bblloocckk::::ccrreeaattee::::sseenndd
- ffrroomm _a_d_d_r_e_s_s ttoo _a_d_d_r_e_s_s pprreevviioouuss _b_l_o_c_k_H_a_s_h rreepprreesseennttaattiivvee
- _a_d_d_r_e_s_s pprreevviioouussBBaallaannccee _i_n_t_e_g_e_r aammoouunntt _i_n_t_e_g_e_r ? --jjssoonn _b_o_o_l_e_a_n
- ? -> _b_l_o_c_k_J_S_O_N|_b_l_o_c_k_D_i_c_t
- 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 aammoouunntt specified from the
- ffrroomm address to the destination (ttoo). The previous block's hash
- must be specified as the _b_l_o_c_k_H_a_s_h following pprreevviioouuss.
- Additionally the balance of the account at the previous block
- must be supplied as the integer argument to pprreevviioouussBBaallaannccee.
- All balance amounts are in units of rraaww. If the optional --jjssoonn
- argument is used and specified as true the result is a JSON
- representation, otherwise a Tcl dict representation is used.
- ::::nnaannoo::::bblloocckk::::ccrreeaattee::::rreecceeiivvee
- ttoo _a_d_d_r_e_s_s ssoouurrcceeBBlloocckk _b_l_o_c_k_H_a_s_h pprreevviioouuss _b_l_o_c_k_H_a_s_h
- rreepprreesseennttaattiivvee _a_d_d_r_e_s_s pprreevviioouussBBaallaannccee _i_n_t_e_g_e_r aammoouunntt _i_n_t_e_g_e_r ?
- --jjssoonn _b_o_o_l_e_a_n ? -> _b_l_o_c_k_J_S_O_N|_b_l_o_c_k_D_i_c_t
- 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 _a_d_d_r_e_s_s supplied
- to the ttoo argument. It constructs a block which receives the
- amount of Nano specified as the aammoouunntt argument. The block hash
- (_b_l_o_c_k_H_a_s_h) of the send block which was used to send the Nano to
- this account must be specified as the argument to the
- ssoouurrcceeBBlloocckk option. The previous block's hash must be specified
- as the _b_l_o_c_k_H_a_s_h following pprreevviioouuss. Additionally the balance
- of the account at the previous block must be supplied as the
- integer argument to pprreevviioouussBBaallaannccee. All balance amounts are in
- units of rraaww. If the optional --jjssoonn argument is used and
- specified as true the result is a JSON representation, otherwise
- a Tcl dict representation is used.
- ::::nnaannoo::::bblloocckk::::ccrreeaattee::::sseettRReepprreesseennttaattiivvee
- aaccccoouunntt _a_d_d_r_e_s_s pprreevviioouuss _b_l_o_c_k_H_a_s_h rreepprreesseennttaattiivvee _a_d_d_r_e_s_s ?
- --jjssoonn _b_o_o_l_e_a_n ? -> _b_l_o_c_k_J_S_O_N|_b_l_o_c_k_D_i_c_t
- 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 aaccccoouunntt specified. It changes
- to the delegate to the rreepprreesseennttaattiivvee specified. Further, the
- _b_l_o_c_k_H_a_s_h of the previous block must be specified as the
- argument to pprreevviioouuss. If the optional --jjssoonn argument is used
- and specified as true the result is a JSON representation,
- otherwise a Tcl dict representation is used.
- WWoorrkk GGeenneerraattiioonn
- ::::nnaannoo::::wwoorrkk::::ffrroommWWoorrkkDDaattaa
- _b_l_o_c_k_H_a_s_h_O_r_P_u_b_l_i_c_K_e_y ?--hheexx|--bbiinnaarryy? -> _w_o_r_k
- 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's chain. If this is the first block in
- this account's chain then the public key of the account is used,
- otherwise the hash of the blocks predecessor (_p_r_e_v_i_o_u_s) is used.
- The specific value needed should be accessible from the
- __wwoorrkkDDaattaa 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. The --hheexx and --bbiinnaarryy options determine the
- formatting of the result.
- ::::nnaannoo::::wwoorrkk::::ffrroommBBlloocckk
- _b_l_o_c_k_D_a_t_a -> _w_o_r_k
- This is a convenience procedure which computes work data (either
- a block hash or a public key) for a given block and then calls
- ffrroommWWoorrkkDDaattaa.
- ::::nnaannoo::::wwoorrkk::::vvaalliiddaattee
- _w_o_r_k_D_a_t_a _w_o_r_k -> _b_o_o_l_e_a_n
- This procedure validates that the supplied _w_o_r_k is valid for the
- supplied _w_o_r_k_D_a_t_a, which is either a block hash or an account
- public key. For more information see the description of
- ffrroommWWoorrkkDDaattaa.
- HHiigghh--lleevveell AAccccoouunntt
- ::nnaannoo::::aaccccoouunntt::::sseettFFrroonnttiieerr
- _a_c_c_o_u_n_t _f_r_o_n_t_i_e_r_H_a_s_h _b_a_l_a_n_c_e _r_e_p_r_e_s_e_n_t_a_t_i_v_e
- This procedure is used as part of the High-level Account
- interface. It sets the _f_r_o_n_t_i_e_r, which is the block hash
- (_f_r_o_n_t_i_e_r_H_a_s_h) and data (_b_a_l_a_n_c_e, _r_e_p_r_e_s_e_n_t_a_t_i_v_e) associated
- with that block that corresponds to the head of an account's
- chain.
- ::nnaannoo::::aaccccoouunntt::::ggeettFFrroonnttiieerr
- _a_c_c_o_u_n_t -> _f_r_o_n_t_i_e_r_I_n_f_o
- 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 _a_c_c_o_u_n_t.
- ::nnaannoo::::aaccccoouunntt::::ggeettFFrroonnttiieerr
- _a_c_c_o_u_n_t ?ffrroonnttiieerrHHaasshh|bbaallaannccee|rreepprreesseennttaattiivvee? ->
- _f_r_o_n_t_i_e_r_H_a_s_h|_b_a_l_a_n_c_e|_r_e_p_r_e_s_e_n_t_a_t_i_v_e
- 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
- _a_c_c_o_u_n_t.
- ::nnaannoo::::aaccccoouunntt::::aaddddPPeennddiinngg
- _a_c_c_o_u_n_t _b_l_o_c_k_H_a_s_h _a_m_o_u_n_t
- This procedure is used as part of the High-level Account
- interface. It is used to indicate than a given _a_c_c_o_u_n_t has a
- rreecceeiivvee block that they could create. The block hash of the
- corresponding sseenndd block should be supplied as the _b_l_o_c_k_H_a_s_h
- parameter. The amount of Nano that was sent in the sseenndd block
- should be specified as the _a_m_o_u_n_t parameter (in units of raw).
- ::nnaannoo::::aaccccoouunntt::::ggeettPPeennddiinngg
- _a_c_c_o_u_n_t ?_b_l_o_c_k_H_a_s_h? -> _d_i_c_t
- This procedure is used as part of the High-level Account
- interface. It is used to retrieve information stored by
- aaddddPPeennddiinngg for a given _a_c_c_o_u_n_t. If the _b_l_o_c_k_H_a_s_h parameter is
- supplied then a Tcl dictionary is returned with a key called
- aammoouunntt which contains the amount stored previously. If the
- _b_l_o_c_k_H_a_s_h parameter is not supplied then a Tcl dictionary is
- returned with keys corresponding to each block hash pending for
- the specified _a_c_c_o_u_n_t, and containing a subordinate Tcl
- dictionary with a key called aammoouunntt as previously described.
- ::::nnaannoo::::aaccccoouunntt::::cclleeaarrPPeennddiinngg
- _a_c_c_o_u_n_t ?_b_l_o_c_k_H_a_s_h?
- 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 "pending") entries created previously with
- aaddddPPeennddiinngg for a given _a_c_c_o_u_n_t. If the _b_l_o_c_k_H_a_s_h parameter is
- supplied then only the entry corresponding to that blockhash is
- cleared, otherwise all entries for the specified _a_c_c_o_u_n_t are
- cleared.
- ::nnaannoo::::aaccccoouunntt::::rreecceeiivvee
- _a_c_c_o_u_n_t _b_l_o_c_k_H_a_s_h _p_r_i_v_a_t_e_K_e_y -> _b_l_o_c_k_J_S_O_N|_b_l_o_c_k_D_i_c_t
- 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.
- ::nnaannoo::::aaccccoouunntt::::rreecceeiivveeAAllllPPeennddiinngg
- _a_c_c_o_u_n_t _p_r_i_v_a_t_e_K_e_y -> _l_i_s_t_O_f_B_l_o_c_k_J_S_O_N|_l_i_s_t_O_f_B_l_o_c_k_D_i_c_t
- 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 _a_c_c_o_u_n_t. Its interface is subject to
- change and not considered stable.
- ::nnaannoo::::aaccccoouunntt::::sseenndd
- _f_r_o_m_A_c_c_o_u_n_t _t_o_A_c_c_o_u_n_t _a_m_o_u_n_t _p_r_i_v_a_t_e_K_e_y -> _b_l_o_c_k_J_S_O_N|_b_l_o_c_k_D_i_c_t
- 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.
- ::::nnaannoo::::aaccccoouunntt::::sseettRReepprreesseennttaattiivvee
- _a_c_c_o_u_n_t _r_e_p_r_e_s_e_n_t_a_t_i_v_e _p_r_i_v_a_t_e_K_e_y -> _b_l_o_c_k_J_S_O_N|_b_l_o_c_k_D_i_c_t
- 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 _a_c_c_o_u_n_t. Its interface is subject
- to change and not considered stable.
- EEXXAAMMPPLLEESS
- EExxaammppllee 11:: GGeenneerraattee aa nneeww sseeeedd aanndd ddeerriivvee 1100 aaddddrreesssseess ffrroomm iitt
- package require nano @@VERS@@
- set seed [::nano::key::newSeed -hex]
- puts "Generated seed: $seed"
- for {set index 0} {$index < 10} {incr index} {
- set accountPrivateKey [::nano::key::fromSeed $seed $index -hex]
- set accountAddress [::nano::address::fromPrivateKey $accountPrivateKey]
- puts " - $index: $accountAddress"
- }
- AAUUTTHHOORR
- Roy Keene <_r_k_e_e_n_e_@_n_a_n_o_._o_r_g>
- nano @@VERS@@ @@SHORT_DATE@@ NANO(N)