Posted to tcl by stu at Tue Jul 17 14:39:15 GMT 2018view pretty
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)