Posted to tcl by stu at Tue Jul 17 14:39:15 GMT 2018view raw

  1. NANO(N) NANO(N)
  2.  
  3.  
  4.  
  5. NNAAMMEE
  6. nano - Tcl bindings for Nano
  7.  
  8. SSYYNNOOPPSSIISS
  9. nnaannoo::::
  10. aaddddrreessss::::
  11. ttooPPuubblliiccKKeeyy _a_d_d_r_e_s_s ?--hheexx|--bbiinnaarryy? ?--vveerriiffyy|--nnoo--vveerriiffyy?
  12. ffrroommPPuubblliiccKKeeyy _p_u_b_K_e_y ?--xxrrbb|--nnaannoo?
  13. ffrroommPPrriivvaatteeKKeeyy _p_r_i_v_a_t_e_K_e_y ?--xxrrbb|--nnaannoo?
  14.  
  15. kkeeyy::::
  16. nneewwSSeeeedd ?--hheexx|--bbiinnaarryy?
  17. nneewwKKeeyy ?--hheexx|--bbiinnaarryy?
  18. ffrroommSSeeeedd _s_e_e_d ?_i_n_d_e_x? ?--hheexx|--bbiinnaarryy?
  19. ppuubblliiccKKeeyyFFrroommPPrriivvaatteeKKeeyy _p_r_i_v_a_t_e_K_e_y ?--hheexx|--bbiinnaarryy?
  20.  
  21. bblloocckk::::
  22. jjssoonn::::ttooBBlloocckk _b_l_o_c_k_J_S_O_N
  23. jjssoonn::::ffrroommDDiicctt _b_l_o_c_k_D_i_c_t
  24. jjssoonn::::ffrroommBBlloocckk _b_l_o_c_k_D_a_t_a ?--xxrrbb|--nnaannoo? ? --ttyyppee==_b_l_o_c_k_T_y_p_e ? ?
  25. --ssiiggnnKKeeyy==_p_r_i_v_a_t_e_K_e_y ?
  26. 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??
  27. jjssoonn::::vveerriiffyySSiiggnnaattuurree _b_l_o_c_k_J_S_O_N
  28. jjssoonn::::wwoorrkk _b_l_o_c_k_J_S_O_N ?--uuppddaattee|--wwoorrkk ?--hheexx|--bbiinnaarryy??
  29. jjssoonn::::vvaalliiddaatteeWWoorrkk _b_l_o_c_k_J_S_O_N
  30. jjssoonn::::ffiilltteerr _b_l_o_c_k_J_S_O_N
  31.  
  32. ddiicctt::::ttooBBlloocckk _b_l_o_c_k_D_i_c_t
  33. ddiicctt::::ffrroommJJSSOONN _b_l_o_c_k_J_S_O_N
  34. ddiicctt::::ffrroommBBlloocckk _b_l_o_c_k_D_a_t_a ?--xxrrbb|--nnaannoo? ? --ttyyppee==_b_l_o_c_k_T_y_p_e ? ?
  35. --ssiiggnnKKeeyy==_p_r_i_v_a_t_e_K_e_y ?
  36. 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??
  37. ddiicctt::::vveerriiffyySSiiggnnaattuurree _b_l_o_c_k_D_i_c_t
  38. ddiicctt::::wwoorrkk _b_l_o_c_k_D_i_c_t ?--uuppddaattee|--wwoorrkk ?--hheexx|--bbiinnaarryy??
  39. ddiicctt::::vvaalliiddaatteeWWoorrkk _b_l_o_c_k_D_i_c_t
  40.  
  41. hhaasshh _b_l_o_c_k_D_a_t_a ?--hheexx|--bbiinnaarryy?
  42. ssiiggnnBBlloocckkHHaasshh _b_l_o_c_k_H_a_s_h _p_r_i_v_a_t_e_K_e_y ?--hheexx|--bbiinnaarryy?
  43. ssiiggnn _b_l_o_c_k_D_a_t_a _p_r_i_v_a_t_e_K_e_y ?--hheexx|--bbiinnaarryy?
  44. 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
  45. 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
  46.  
  47. ccrreeaattee::::sseenndd _a_r_g_s
  48. ccrreeaattee::::rreecceeiivvee _a_r_g_s
  49. ccrreeaattee::::sseettRReepprreesseennttaattiivvee _a_r_g_s
  50.  
  51. wwoorrkk::::
  52. ffrroommWWoorrkkDDaattaa _b_l_o_c_k_H_a_s_h_O_r_P_u_b_l_i_c_K_e_y ?--hheexx|--bbiinnaarryy?
  53. ffrroommBBlloocckk _b_l_o_c_k_D_a_t_a
  54. vvaalliiddaattee _w_o_r_k_D_a_t_a _w_o_r_k
  55.  
  56. aaccccoouunntt::::
  57. 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
  58. ggeettFFrroonnttiieerr _a_c_c_o_u_n_t
  59. ggeettFFrroonnttiieerr _a_c_c_o_u_n_t ?ffrroonnttiieerrHHaasshh|bbaallaannccee|rreepprreesseennttaattiivvee?
  60. aaddddPPeennddiinngg _a_c_c_o_u_n_t _b_l_o_c_k_H_a_s_h _a_m_o_u_n_t
  61. ggeettPPeennddiinngg _a_c_c_o_u_n_t ?_b_l_o_c_k_H_a_s_h?
  62. cclleeaarrPPeennddiinngg _a_c_c_o_u_n_t ?_b_l_o_c_k_H_a_s_h?
  63.  
  64. 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
  65. rreecceeiivveeAAllllPPeennddiinngg _a_c_c_o_u_n_t _p_r_i_v_a_t_e_K_e_y
  66. 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
  67. 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
  68.  
  69.  
  70.  
  71. IINNTTRROODDUUCCTTIIOONN
  72. _N_a_n_o is a low-latency payment platform that requires minimal resources,
  73. relying on a peer-to-peer network to distribute "blocks", which are
  74. cryptographically signed transactions. This package provides bindings
  75. for interacting with the Nano network from _T_c_l.
  76.  
  77. Nano uses Ed25519 with Blake2b as the cryptographic hashing primitive
  78. for digital signatures, rather than the common construction of Ed25519
  79. with the SHA2-512 cryptographic hashing function.
  80.  
  81. Nano implements a "blockchain", which is a cryptographic linked-list,
  82. by identifying every "block" by its cryptographic hash and providing a
  83. pointer from every block to its predecessor in the "chain" as part of
  84. the hashed data.
  85.  
  86. This predecessors is referred to here as the "previous" block. In
  87. Nano, each account has its own blockchain and they reference each other
  88. using a data structure referred to as "block lattice", where the
  89. individual chains contain blocks that reference blocks in other chains
  90. to tie them together. The field within blocks that reference other
  91. blocks on a different blockchain is referred to as either the "link"
  92. field or "source block hash".
  93.  
  94. Each Nano block also encapsulates the full state of the account,
  95. 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,
  96. _p_r_e_v_i_o_u_s).
  97.  
  98. Since Nano blocks are signed by independent actors, who may, for their
  99. own gain, generate multiple valid blocks referring to the same
  100. predecessor (_p_r_e_v_i_o_u_s) block, an arbitration mechanism is employed by
  101. the Nano network to decide which blocks are valid within a given chain.
  102. This arbitration mechanism operates on the principles of consensus.
  103. Each account holder has a stake in the network operating nominally,
  104. otherwise the balance represented by an account is not useful for a
  105. transfer of value. In Nano the stake an account has in the network is
  106. equal to the account's balance. The larger the stake an account has
  107. the more incentivized the account-holder is to ensure the network is
  108. operating nominally and not accepting multiple blocks that reference
  109. the same predecessor.
  110.  
  111. Nano utilizes a mechanism called _v_o_t_i_n_g to determine which blocks are
  112. valid and which blocks are not valid. Each stakeholder votes their
  113. stake upon seeing a new subordinate block (_i_._e_., a block with a unique
  114. _p_r_e_v_i_o_u_s value). Since voting is an active and on-going process that
  115. occurs on the Nano peer-to-peer network, participants must be online to
  116. vote their stake. As this is often inconvenient or impossible,
  117. stakeholders may select another stakeholder to vote their share of the
  118. network. This delegate is referred to as a _r_e_p_r_e_s_e_n_t_a_t_i_v_e.
  119.  
  120. Representatives should be chosen carefully by stakeholders since
  121. malicious representatives may attempt to gather voting power and
  122. destabilize the Nano network by altering decisions made by consensus
  123. previously.
  124.  
  125. Nano accounts are referred to by address. A Nano address starts with
  126. the prefix "nnaannoo__" or "xxrrbb__". A Nano address is actually the public
  127. portion of a private/public keypair, plus the prefix, and a checksum to
  128. ensure that no digits are mistyped by users when communicating them.
  129. Nano public keys are 256-bit keys in the Ed25519 algorithm.
  130.  
  131. A user may have many accounts. To simplify the process of maintaining
  132. the private/public keypairs for all the accounts, Nano supports the
  133. concept of a _w_a_l_l_e_t. A _w_a_l_l_e_t is a conceptual entity that is used to
  134. refer to a _s_e_e_d, which is a random 256-bit number that can be used to
  135. derive multiple private/public keypairs from.
  136.  
  137. Balances in Nano are stored in a 128-bit integer value. There are
  138. various units for representing the balance, the smallest and base unit
  139. is called "_r_a_w". The most common unit for users to use is called
  140. "_N_a_n_o", one of which is equal to 1e30 raw.
  141.  
  142.  
  143. AAddddrreesssseess
  144. Nano addresses are composed of a prefix (either "nnaannoo__" or "xxrrbb__") and
  145. 300 bits of base32 encoded data. The 300-bits of base32 encoded data
  146. produce a string that is 6 characters long using the base32 alphabet
  147. 1133445566778899aabbccddeeffgghhiijjkkmmnnooppqqrrssttuuwwxxyyzz. The format of these 300 bits are
  148.  
  149. struct {
  150. uint4_t padding = 0000b;
  151. uint256_t publicKey;
  152. uint40_t checksum;
  153. }
  154.  
  155. The checksum is computed as a 5 byte (40 bit) Blake2b hash of the
  156. 256-bit public key (in binary format), followed by reversing the bytes.
  157.  
  158. For example the public key
  159. DDCC11551122115544EEBB7722111122BB88CCCC223300DD77BB88CC77DDDD446677DDAA7788EE44776633118822DD66CCAAFFAAAADDBB1144885555AA55EE88 which
  160. has a 5-byte Blake2b hash of {{00xx1188,, 00xx7744,, 00xxAA33,, 00xx4466,, 00xx99CC}} would be
  161. encoded as
  162. 00000000..DDCC11551122115544EEBB7722111122BB88CCCC223300DD77BB88CC77DDDD446677DDAA7788EE44776633118822DD66CCAAFFAAAADDBB1144885555AA55EE88..99CC4466AA3377441188
  163. which when encoded in base32 and the prefix added produces the address
  164. nnaannoo__33qq11oo44aaccnnxxffss3344ccwweerraarrffhhgg8899uuoo5599uubbwwggaaxxjjjjiiddddeeooyyooffpp776677ddbbhhaammjj55cc88xx11rr.
  165.  
  166.  
  167. NNeettwwoorrkk
  168. The Nano network consists of two different peer-to-peer networks. One
  169. for real-time block updates over UDP, and another for bulk ledger
  170. updates over TCP (_b_o_o_t_s_t_r_a_p_p_i_n_g). The real-time network is a broadcast
  171. style network where every message sent over it are relayed to all other
  172. nodes.
  173.  
  174. The customary and default port for the real-time/UDP network is
  175. 7075/udp, while the default port for the bootstrapping/TCP network is
  176. 7075/tcp.
  177.  
  178. The format of the messages on both networks is the same, however not
  179. every type of message may be used on either network. The kkeeeeppaalliivvee
  180. message type is invalid on the TCP (bootstrapping) network and the
  181. bbuullkk__ppuullll message type is invalid on the UDP (real-time) network. The
  182. format of message are an 8 byte header consisting of:
  183.  
  184. struct {
  185. uint8_t magicProtocol = 0x52;
  186. uint8_t magicNetwork = 0x41/0x42/0x43;
  187. uint8_t versionMax;
  188. uint8_t version;
  189. uint8_t versionMin;
  190. uint8_t messageType;
  191. uint16_t extensions;
  192. };
  193.  
  194. Where the mmaaggiiccPPrroottooccooll field must be the value 00xx5522 (which is ASCII
  195. 'R') and the mmaaggiiccNNeettwwoorrkk field must be one of 00xx4411, 00xx4422, or 00xx4433
  196. corresponding to one of the three Nano networks. A value of 00xx4411
  197. (ASCII 'A') represents the Test network; A value of 00xx4422 (ASCII 'B')
  198. represents the Beta network; A value of 00xx4433 (ASCII 'C') represents
  199. the Main network.
  200.  
  201. The various version fields control the relaying of the message to nodes
  202. running various versions of the Nano network protocol (distinct from
  203. the Nano reference implementation version). The vveerrssiioonnMMaaxx and
  204. vveerrssiioonnMMiinn fields indicate the inclusive range of acceptable versions
  205. to relay or broadcast this message to. The vveerrssiioonn field indicates
  206. what version of the Nano protocol this node is using.
  207.  
  208. The messageType field indicates what type of message is being relayed,
  209. and must conform to the following enumeration
  210.  
  211. +------------+------------------+--------------+-------------+
  212. |mmeessssaaggeeTTyyppee | NNaammee | OOnn BBoooottssttrraapp | OOnn RReeaallttiimmee |
  213. +------------+------------------+--------------+-------------+
  214. | 0x00 | Invalid | Yes | Yes |
  215. +------------+------------------+--------------+-------------+
  216. | 0x01 | Not_A_Type | ? | ? |
  217. +------------+------------------+--------------+-------------+
  218. | 0x02 | Keepalive | No | Yes |
  219. +------------+------------------+--------------+-------------+
  220. | 0x03 | Publish | No | Yes |
  221. +------------+------------------+--------------+-------------+
  222. | 0x04 | Confirm_Req | No | Yes |
  223. +------------+------------------+--------------+-------------+
  224. | 0x05 | Confirm_Ack | No | Yes |
  225. +------------+------------------+--------------+-------------+
  226. | 0x06 | Bulk_Pull | Yes | No |
  227. +------------+------------------+--------------+-------------+
  228. | 0x07 | Bulk_Push | Yes | No |
  229. +------------+------------------+--------------+-------------+
  230. | 0x08 | Frontier_Req | Yes | No |
  231. +------------+------------------+--------------+-------------+
  232. | 0x09 | Bulk_Pull_Blocks | Yes | No |
  233. +------------+------------------+--------------+-------------+
  234. TTOODDOO:: EExxtteennssiioonnss
  235.  
  236. Following the message header comes the payload for the particular
  237. message type.
  238.  
  239.  
  240. IInnvvaalliidd
  241. TODOC
  242.  
  243.  
  244. NNoott__AA__TTyyppee
  245. TODOC
  246.  
  247.  
  248. KKeeeeppaalliivvee
  249. The Keepalive message requires exactly 8 IPv6 address and port
  250. number tuples to be sent as its payload. The IPv6 addresses are
  251. each 128-bits (16-bytes) long and the port numbers are 16-bit
  252. integers sent in network byte order. The payload for the
  253. Keepalive message type is 144 bytes in size.
  254.  
  255.  
  256. PPuubblliisshh
  257. TODOC
  258.  
  259.  
  260. CCoonnffiirrmm__RReeqq
  261. TODOC
  262.  
  263.  
  264. CCoonnffiirrmm__AAcckk
  265. TODOC
  266.  
  267.  
  268. BBuullkk__PPuullll
  269. TODOC
  270.  
  271.  
  272. BBuullkk__PPuusshh
  273. TODOC
  274.  
  275.  
  276. FFrroonnttiieerr__RReeqq
  277. TODOC
  278.  
  279.  
  280. BBuullkk__PPuullll__BBlloocckkss
  281. TODOC
  282.  
  283.  
  284.  
  285. PPRROOCCEEDDUURREESS
  286. AAddddrreesssseess
  287. ::::nnaannoo::::aaddddrreessss::::ttooPPuubblliiccKKeeyy
  288. _a_d_d_r_e_s_s ?--hheexx|--bbiinnaarryy? ?--vveerriiffyy|--nnoo--vveerriiffyy? -->> _p_u_b_l_i_c_K_e_y
  289.  
  290. Converts a Nano address to a public key. The --hheexx option
  291. indicates that the public key should be returned in hexadecimal
  292. form. The --bbiinnaarryy option indicates that the public key should
  293. be returned in binary form. The --vveerriiffyy option verifies the
  294. checksum embedded in the Nano address before returning. The
  295. --nnoo--vveerriiffyy option inhibits verifying the checksum embedded in
  296. the Nano address.
  297.  
  298.  
  299. ::::nnaannoo::::aaddddrreessss::::ffrroommPPuubblliiccKKeeyy
  300. _p_u_b_K_e_y ?--xxrrbb|--nnaannoo? -->> _a_d_d_r_e_s_s
  301.  
  302. Converts a public key to a Nano address. The --xxrrbb option
  303. specifies that the returned address should be prefixed with the
  304. old-style "xrb_" prefix, where the --nnaannoo option specifies that
  305. the returned address should be prefixed with the new-style
  306. "nano_" prefix.
  307.  
  308.  
  309. ::::nnaannoo::::aaddddrreessss::::ffrroommPPrriivvaatteeKKeeyy
  310. _p_r_i_v_a_t_e_K_e_y ?--xxrrbb|--nnaannoo? -->> _a_d_d_r_e_s_s
  311.  
  312. Converts a private key to a Nano address. It accepts the same
  313. arguments as ffrroommPPuubblliiccKKeeyy.
  314.  
  315.  
  316. KKeeyy MMaannaaggeemmeenntt
  317. ::::nnaannoo::::kkeeyy::::nneewwSSeeeedd
  318. ?--hheexx|--bbiinnaarryy? -> _s_e_e_d
  319.  
  320. Generates a new seed. A seed is a 256-bit bit-field which,
  321. along with a 32-bit index, is used to derive enumerated keys
  322. from a single point of entropy. See the ffrroommSSeeeedd procedure.
  323. The --hheexx and --bbiinnaarryy options determine the formatting of the
  324. result.
  325.  
  326.  
  327. ::::nnaannoo::::kkeeyy::::nneewwKKeeyy
  328. ?--hheexx|--bbiinnaarryy? -> _p_r_i_v_a_t_e_K_e_y
  329.  
  330. Generates a new private key. A private key can be used to sign
  331. transactions, which can then be verified with its corresponding
  332. public key (see ppuubblliiccKKeeyyFFrroommPPrriivvaatteeKKeeyy). This procedure is
  333. normally not used, but rather private keys are derived from a
  334. _s_e_e_d and _i_n_d_e_x pair using the ffrroommSSeeeedd procedure. The --hheexx and
  335. --bbiinnaarryy options determine the formatting of the result.
  336.  
  337.  
  338. ::::nnaannoo::::kkeeyy::::ffrroommSSeeeedd
  339. _s_e_e_d ?_i_n_d_e_x? ?--hheexx|--bbiinnaarryy? -> _p_r_i_v_a_t_e_K_e_y
  340.  
  341. Derive a private key from the seed specified as _s_e_e_d and the
  342. _i_n_d_e_x indicated. This procedure is deterministic (i.e., the
  343. same _s_e_e_d and _i_n_d_e_x will always give you the same private key).
  344. This procedure is used to derive many keypairs from a single
  345. user-managed piece of data, so the user does not have to manage
  346. multiple private keys. If the _i_n_d_e_x is not specified it
  347. defaults to 00. The --hheexx and --bbiinnaarryy options determine the
  348. formatting of the result.
  349.  
  350.  
  351. ::::nnaannoo::::kkeeyy::::ppuubblliiccKKeeyyFFrroommPPrriivvaatteeKKeeyy
  352. _p_r_i_v_a_t_e_K_e_y ?--hheexx|--bbiinnaarryy? -> _p_u_b_l_i_c_K_e_y
  353.  
  354. Converts a private key into its corresponding public key.
  355. Normally Ed25519 private keys are a concatenation of the private
  356. and public keys, however in this package they are each treated
  357. separately. The --hheexx and --bbiinnaarryy options determine the
  358. formatting of the result.
  359.  
  360.  
  361. LLooww--lleevveell BBlloocckk
  362. ::::nnaannoo::::bblloocckk::::_r_e_p_r_e_s_e_n_t_a_t_i_o_n::::ttooBBlloocckk
  363. _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
  364.  
  365. Converts from one of the internal representations (either Tcl
  366. dictionary or JSON) to a Nano block. The _r_e_p_r_e_s_e_n_t_a_t_i_o_n portion
  367. of the command name may be one of ddiicctt or jjssoonn.
  368.  
  369.  
  370. ::::nnaannoo::::bblloocckk::::jjssoonn::::ffrroommDDiicctt
  371. _b_l_o_c_k_D_i_c_t -> _b_l_o_c_k_J_S_O_N
  372.  
  373. Converts from a Tcl dictionary representation to a JSON
  374. representation of a block.
  375.  
  376.  
  377. ::::nnaannoo::::bblloocckk::::jjssoonn::::ffiilltteerr
  378. _b_l_o_c_k_J_S_O_N -> _b_l_o_c_k_J_S_O_N
  379.  
  380. Filters out JSON object attributes which are not suitable for
  381. using with other implementations, such as ___c_o_m_m_e_n_t, ___w_o_r_k_D_a_t_a,
  382. and ___b_l_o_c_k_H_a_s_h.
  383.  
  384.  
  385. ::::nnaannoo::::bblloocckk::::ddiicctt::::ffrroommJJSSOONN
  386. _b_l_o_c_k_J_S_O_N -> _b_l_o_c_k_D_i_c_t
  387.  
  388. Converts from a JSON object representation to a Tcl dictionary
  389. representation of a block.
  390.  
  391.  
  392. ::::nnaannoo::::bblloocckk::::_r_e_p_r_e_s_e_n_t_a_t_i_o_n::::ffrroommBBlloocckk
  393. _b_l_o_c_k_D_a_t_a ?--xxrrbb|--nnaannoo? ? --ttyyppee==_b_l_o_c_k_T_y_p_e ? ?
  394. --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
  395.  
  396. Parses a Nano block and returns either a Tcl dictionary or a
  397. JSON object. The --xxrrbb option causes all parsed addresses to be
  398. prefixed with the old-style "xrb_" address prefix, while the
  399. --nnaannoo option causes them to be prefixed with the new-style
  400. "nano_prefix". The _r_e_p_r_e_s_e_n_t_a_t_i_o_n portion of the command name
  401. may be one of ddiicctt or jjssoonn.
  402.  
  403.  
  404. ::::nnaannoo::::bblloocckk::::_r_e_p_r_e_s_e_n_t_a_t_i_o_n::::ssiiggnn
  405. _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
  406. ?--hheexx|bbiinnaarryy?? -> _s_i_g_n_a_t_u_r_e|_b_l_o_c_k_J_S_O_N
  407.  
  408. Sign a block, in either Tcl dictionary or JSON representation,
  409. with the specified _p_r_i_v_a_t_e_K_e_y. If the --uuppddaattee option is used,
  410. return the object with the updated attribute. If the --ssiiggnnaattuurree
  411. option is used, return just the signature. The --hheexx and --bbiinnaarryy
  412. options determine the formatting of the result. The
  413. _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
  414. jjssoonn.
  415.  
  416.  
  417. ::::nnaannoo::::bblloocckk::::_r_e_p_r_e_s_e_n_t_a_t_i_o_n::::vveerriiffyySSiiggnnaattuurree
  418. _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
  419.  
  420. Verify the signature on a block, in either Tcl dictionary or
  421. JSON representation, matches the public key specified in the
  422. aaccccoouunntt attribute of that object. This may not work correctly
  423. for old-style blocks unless you manually add the aaccccoouunntt
  424. attribute. The _r_e_p_r_e_s_e_n_t_a_t_i_o_n portion of the command name may
  425. be one of ddiicctt or jjssoonn.
  426.  
  427.  
  428. ::::nnaannoo::::bblloocckk::::_r_e_p_r_e_s_e_n_t_a_t_i_o_n::::wwoorrkk
  429. _b_l_o_c_k_R_e_p_r_e_s_e_n_t_a_t_i_o_n ?--uuppddaattee|--wwoorrkk ?--hheexx|bbiinnaarryy?? ->
  430. _w_o_r_k|_b_l_o_c_k_R_e_p_r_e_s_e_n_t_a_t_i_o_n
  431.  
  432. Generate proof-of-work (PoW) required to submit a given block to
  433. the network. Nano uses PoW to increase the cost of submitting
  434. blocks to the network to cut down on spam. The _w_o_r_k that is
  435. computed is based on the hash of the previous block on this
  436. chain, or if there is no previous block on this chain (i.e.,
  437. because it is the first block on an account) the public key of
  438. the account. If the --uuppddaattee option is used, return the object
  439. with the updated attribute. If the --wwoorrkk option is used, just
  440. return the work. The --hheexx and --bbiinnaarryy options determine the
  441. formatting of the result. The _r_e_p_r_e_s_e_n_t_a_t_i_o_n portion of the
  442. command name may be one of ddiicctt or jjssoonn.
  443.  
  444.  
  445. ::::nnaannoo::::bblloocckk::::_r_e_p_r_e_s_e_n_t_a_t_i_o_n::::vvaalliiddaatteeWWoorrkk
  446. _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
  447.  
  448. Validate the proof-of-work (PoW) in the object specified as
  449. _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
  450. block passed in. The _r_e_p_r_e_s_e_n_t_a_t_i_o_n portion of the command name
  451. may be one of ddiicctt or jjssoonn.
  452.  
  453.  
  454. ::::nnaannoo::::bblloocckk::::hhaasshh
  455. _b_l_o_c_k_D_a_t_a ?--hheexx|--bbiinnaarryy? -> _b_l_o_c_k_H_a_s_h
  456.  
  457. Compute the cryptographic hash of a block. The cryptographic
  458. hashing algorithm used for Nano is Blake2b. Blocks are
  459. typically identified by their hash (i.e., content addressable).
  460. The --hheexx and --bbiinnaarryy options determine the formatting of the
  461. result.
  462.  
  463.  
  464. ::::nnaannoo::::bblloocckk::::ssiiggnnBBlloocckkHHaasshh
  465. _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
  466.  
  467. Compute an Ed25519-with-Blake2b signature of a given block hash
  468. specified as _b_l_o_c_k_H_a_s_h with the private key specified as
  469. _p_r_i_v_a_t_e_K_e_y. In Nano, signed blocks are signed by signing the
  470. block's hash thus all that is needed to sign a block is its hash
  471. and the private key that corresponds to the account. NNOOTTEE::
  472. EEnnssuurree tthhaatt tthhee _p_r_i_v_a_t_e_K_e_y ssppeecciiffiieedd mmaattcchheess tthhee aaccccoouunntt tthhee
  473. bblloocckk bbeelloonnggss ttoo.. The --hheexx and --bbiinnaarryy options determine the
  474. formatting of the result.
  475.  
  476.  
  477. ::::nnaannoo::::bblloocckk::::ssiiggnn
  478. _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
  479.  
  480. This is a convenience procedure which computes the hash of a
  481. block given as _b_l_o_c_k_D_a_t_a, and then calls ssiiggnnBBlloocckkHHaasshh. The
  482. --hheexx and --bbiinnaarryy options determine the formatting of the result.
  483.  
  484.  
  485. ::::nnaannoo::::bblloocckk::::vveerriiffyyBBlloocckkHHaasshh
  486. _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
  487.  
  488. 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
  489. an account holding the private key that corresponds to the
  490. public key specified as _p_u_b_l_i_c_K_e_y.
  491.  
  492.  
  493. ::::nnaannoo::::bblloocckk::::vveerriiffyy
  494. _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
  495.  
  496. This is a convenience procedure which computes the hash of a
  497. block given as _b_l_o_c_k_D_a_t_a, and then calls vveerriiffyyBBlloocckkHHaasshh.
  498.  
  499.  
  500. ::::nnaannoo::::bblloocckk::::ccrreeaattee::::sseenndd
  501. 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
  502. _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
  503. ? -> _b_l_o_c_k_J_S_O_N|_b_l_o_c_k_D_i_c_t
  504.  
  505. This is a low-level interface for creating blocks which
  506. correspond to sending Nano from one account to another. It
  507. constructs a block which sends the aammoouunntt specified from the
  508. ffrroomm address to the destination (ttoo). The previous block's hash
  509. must be specified as the _b_l_o_c_k_H_a_s_h following pprreevviioouuss.
  510. Additionally the balance of the account at the previous block
  511. must be supplied as the integer argument to pprreevviioouussBBaallaannccee.
  512. All balance amounts are in units of rraaww. If the optional --jjssoonn
  513. argument is used and specified as true the result is a JSON
  514. representation, otherwise a Tcl dict representation is used.
  515.  
  516.  
  517. ::::nnaannoo::::bblloocckk::::ccrreeaattee::::rreecceeiivvee
  518. 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
  519. rreepprreesseennttaattiivvee _a_d_d_r_e_s_s pprreevviioouussBBaallaannccee _i_n_t_e_g_e_r aammoouunntt _i_n_t_e_g_e_r ?
  520. --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
  521.  
  522. This is a low-level interface for creating blocks which
  523. correspond to receiving (pocketing) Nano previously sent from
  524. another account to the account specified as the _a_d_d_r_e_s_s supplied
  525. to the ttoo argument. It constructs a block which receives the
  526. amount of Nano specified as the aammoouunntt argument. The block hash
  527. (_b_l_o_c_k_H_a_s_h) of the send block which was used to send the Nano to
  528. this account must be specified as the argument to the
  529. ssoouurrcceeBBlloocckk option. The previous block's hash must be specified
  530. as the _b_l_o_c_k_H_a_s_h following pprreevviioouuss. Additionally the balance
  531. of the account at the previous block must be supplied as the
  532. integer argument to pprreevviioouussBBaallaannccee. All balance amounts are in
  533. units of rraaww. If the optional --jjssoonn argument is used and
  534. specified as true the result is a JSON representation, otherwise
  535. a Tcl dict representation is used.
  536.  
  537.  
  538. ::::nnaannoo::::bblloocckk::::ccrreeaattee::::sseettRReepprreesseennttaattiivvee
  539. 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 ?
  540. --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
  541.  
  542. This is a low-level interface for creating blocks which
  543. correspond to an explicit change of representative.
  544. Representatives in Nano are used as part of the Delegated Proof-
  545. of-Stake (dPoS) consensus mechanism which is used by the Nano
  546. network to determine which block (if any) out of many possible
  547. subordinate blocks in a chain are valid. So that every account
  548. holder does not have to be online to vote for valid
  549. transactions, an account may delegate another account to vote
  550. its stake on its behalf. That delegate is called a
  551. representative. An account may change its representative at any
  552. time by issuing a block with a new representative, such as a
  553. send or receive block, or by issuing an explicit change of
  554. representative block. This procedure creates an explicit change
  555. of representative block for the aaccccoouunntt specified. It changes
  556. to the delegate to the rreepprreesseennttaattiivvee specified. Further, the
  557. _b_l_o_c_k_H_a_s_h of the previous block must be specified as the
  558. argument to pprreevviioouuss. If the optional --jjssoonn argument is used
  559. and specified as true the result is a JSON representation,
  560. otherwise a Tcl dict representation is used.
  561.  
  562.  
  563. WWoorrkk GGeenneerraattiioonn
  564. ::::nnaannoo::::wwoorrkk::::ffrroommWWoorrkkDDaattaa
  565. _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
  566.  
  567. Create proof-of-work (PoW) from a block hash or public key.
  568. Which one is used depends on whether or not there are any other
  569. blocks in this account's chain. If this is the first block in
  570. this account's chain then the public key of the account is used,
  571. otherwise the hash of the blocks predecessor (_p_r_e_v_i_o_u_s) is used.
  572. The specific value needed should be accessible from the
  573. __wwoorrkkDDaattaa member of a JSON object or Tcl dictionary. Note that
  574. this attribute (and all attributes that begin with an
  575. underscore) should be discarded when sending the block outside
  576. of the Tcl process. The --hheexx and --bbiinnaarryy options determine the
  577. formatting of the result.
  578.  
  579.  
  580. ::::nnaannoo::::wwoorrkk::::ffrroommBBlloocckk
  581. _b_l_o_c_k_D_a_t_a -> _w_o_r_k
  582.  
  583. This is a convenience procedure which computes work data (either
  584. a block hash or a public key) for a given block and then calls
  585. ffrroommWWoorrkkDDaattaa.
  586.  
  587.  
  588. ::::nnaannoo::::wwoorrkk::::vvaalliiddaattee
  589. _w_o_r_k_D_a_t_a _w_o_r_k -> _b_o_o_l_e_a_n
  590.  
  591. This procedure validates that the supplied _w_o_r_k is valid for the
  592. supplied _w_o_r_k_D_a_t_a, which is either a block hash or an account
  593. public key. For more information see the description of
  594. ffrroommWWoorrkkDDaattaa.
  595.  
  596.  
  597.  
  598. HHiigghh--lleevveell AAccccoouunntt
  599. ::nnaannoo::::aaccccoouunntt::::sseettFFrroonnttiieerr
  600. _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
  601.  
  602. This procedure is used as part of the High-level Account
  603. interface. It sets the _f_r_o_n_t_i_e_r, which is the block hash
  604. (_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
  605. with that block that corresponds to the head of an account's
  606. chain.
  607.  
  608.  
  609. ::nnaannoo::::aaccccoouunntt::::ggeettFFrroonnttiieerr
  610. _a_c_c_o_u_n_t -> _f_r_o_n_t_i_e_r_I_n_f_o
  611.  
  612. This procedure is used as part of the High-level Account
  613. interface. It gets the Tcl dictionary associated with the
  614. frontier most recently set for the specified _a_c_c_o_u_n_t.
  615.  
  616.  
  617. ::nnaannoo::::aaccccoouunntt::::ggeettFFrroonnttiieerr
  618. _a_c_c_o_u_n_t ?ffrroonnttiieerrHHaasshh|bbaallaannccee|rreepprreesseennttaattiivvee? ->
  619. _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
  620.  
  621. This procedure is used as part of the High-level Account
  622. interface. It gets a specific item from Tcl dictionary
  623. associated with the frontier most recently set for the specified
  624. _a_c_c_o_u_n_t.
  625.  
  626.  
  627. ::nnaannoo::::aaccccoouunntt::::aaddddPPeennddiinngg
  628. _a_c_c_o_u_n_t _b_l_o_c_k_H_a_s_h _a_m_o_u_n_t
  629.  
  630. This procedure is used as part of the High-level Account
  631. interface. It is used to indicate than a given _a_c_c_o_u_n_t has a
  632. rreecceeiivvee block that they could create. The block hash of the
  633. corresponding sseenndd block should be supplied as the _b_l_o_c_k_H_a_s_h
  634. parameter. The amount of Nano that was sent in the sseenndd block
  635. should be specified as the _a_m_o_u_n_t parameter (in units of raw).
  636.  
  637.  
  638. ::nnaannoo::::aaccccoouunntt::::ggeettPPeennddiinngg
  639. _a_c_c_o_u_n_t ?_b_l_o_c_k_H_a_s_h? -> _d_i_c_t
  640.  
  641. This procedure is used as part of the High-level Account
  642. interface. It is used to retrieve information stored by
  643. aaddddPPeennddiinngg for a given _a_c_c_o_u_n_t. If the _b_l_o_c_k_H_a_s_h parameter is
  644. supplied then a Tcl dictionary is returned with a key called
  645. aammoouunntt which contains the amount stored previously. If the
  646. _b_l_o_c_k_H_a_s_h parameter is not supplied then a Tcl dictionary is
  647. returned with keys corresponding to each block hash pending for
  648. the specified _a_c_c_o_u_n_t, and containing a subordinate Tcl
  649. dictionary with a key called aammoouunntt as previously described.
  650.  
  651.  
  652. ::::nnaannoo::::aaccccoouunntt::::cclleeaarrPPeennddiinngg
  653. _a_c_c_o_u_n_t ?_b_l_o_c_k_H_a_s_h?
  654.  
  655. This procedure is used as part of the High-level Account
  656. interface. It is used to clear (that is, remove from the
  657. conceptual state of "pending") entries created previously with
  658. aaddddPPeennddiinngg for a given _a_c_c_o_u_n_t. If the _b_l_o_c_k_H_a_s_h parameter is
  659. supplied then only the entry corresponding to that blockhash is
  660. cleared, otherwise all entries for the specified _a_c_c_o_u_n_t are
  661. cleared.
  662.  
  663.  
  664. ::nnaannoo::::aaccccoouunntt::::rreecceeiivvee
  665. _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
  666.  
  667. This procedure is used as part of the High-level Account
  668. interface. It is used to generate a receive block. Its
  669. interface is subject to change and not considered stable.
  670.  
  671.  
  672. ::nnaannoo::::aaccccoouunntt::::rreecceeiivveeAAllllPPeennddiinngg
  673. _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
  674.  
  675. This procedure is used as part of the High-level Account
  676. interface. It is used to generate receive blocks for every
  677. pending receive on a given _a_c_c_o_u_n_t. Its interface is subject to
  678. change and not considered stable.
  679.  
  680.  
  681. ::nnaannoo::::aaccccoouunntt::::sseenndd
  682. _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
  683.  
  684. This procedure is used as part of the High-level Account
  685. interface. It is used to generate a send block. Its interface
  686. is subject to change and not considered stable.
  687.  
  688.  
  689. ::::nnaannoo::::aaccccoouunntt::::sseettRReepprreesseennttaattiivvee
  690. _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
  691.  
  692. This procedure is used as part of the High-level Account
  693. interface. It is used to generate a block that changes the
  694. representative for the given _a_c_c_o_u_n_t. Its interface is subject
  695. to change and not considered stable.
  696.  
  697.  
  698. EEXXAAMMPPLLEESS
  699. EExxaammppllee 11:: GGeenneerraattee aa nneeww sseeeedd aanndd ddeerriivvee 1100 aaddddrreesssseess ffrroomm iitt
  700. package require nano @@VERS@@
  701.  
  702. set seed [::nano::key::newSeed -hex]
  703. puts "Generated seed: $seed"
  704.  
  705. for {set index 0} {$index < 10} {incr index} {
  706. set accountPrivateKey [::nano::key::fromSeed $seed $index -hex]
  707. set accountAddress [::nano::address::fromPrivateKey $accountPrivateKey]
  708. puts " - $index: $accountAddress"
  709. }
  710.  
  711.  
  712. AAUUTTHHOORR
  713. Roy Keene <_r_k_e_e_n_e_@_n_a_n_o_._o_r_g>
  714.  
  715.  
  716.  
  717. nano @@VERS@@ @@SHORT_DATE@@ NANO(N)
  718.