Tcl Nano
Changes To Manual
Login
HomeTimelineDownloadsBrowse SourceSearchTickets
Next

Initial version of "Manual"




































































































































































































































































































































































































































































































































































































































































































































































































































1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802

+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+


<div class="mandoc">
<table class="head">
<tbody>
<tr>
<td class="head-ltitle">
NANO(N)</td>
<td class="head-vol">
</td>
<td class="head-rtitle">
NANO(N)</td>
</tr>
</tbody>
</table>
<div class="section">
<h1>NAME</h1> nano - Tcl bindings for Nano</div>
<div class="section">
<h1>SYNOPSIS</h1> <b>nano::</b><br/>
<b>address::</b><br/>
<b>toPublicKey</b> <i>address</i> ?<b>-hex</b>|<b>-binary</b>? ?<b>-verify</b>|<b>-no-verify</b>?<div style="height: 0.00em;">
&#160;</div>
<b>fromPublicKey</b> <i>pubKey</i> ?<b>-xrb</b>|<b>-nano</b>?<div style="height: 0.00em;">
&#160;</div>
<b>fromPrivateKey</b> <i>privateKey</i> ?<b>-xrb</b>|<b>-nano</b>?<div style="height: 1.00em;">
&#160;</div>
<br/>
<b>key::</b><br/>
<b>newSeed</b> ?<b>-hex</b>|<b>-binary</b>?<div style="height: 0.00em;">
&#160;</div>
<b>newKey</b> ?<b>-hex</b>|<b>-binary</b>?<div style="height: 0.00em;">
&#160;</div>
<b>fromSeed</b> <i>seed</i> ?<i>index</i>? ?<b>-hex</b>|<b>-binary</b>?<div style="height: 0.00em;">
&#160;</div>
<b>publicKeyFromPrivateKey</b> <i>privateKey</i> ?<b>-hex</b>|<b>-binary</b>?<div style="height: 1.00em;">
&#160;</div>
<br/>
<b>block::</b><br/>
<b>json::toBlock</b> <i>blockJSON</i><div style="height: 0.00em;">
&#160;</div>
<b>json::fromDict</b> <i>blockDict</i><div style="height: 0.00em;">
&#160;</div>
<b>json::fromBlock</b> <i>blockData</i> ?<b>-xrb</b>|<b>-nano</b>? ? <b>-type=</b><i>blockType</i> ? ? <b>-signKey=</b><i>privateKey</i> ?<div style="height: 0.00em;">
&#160;</div>
<b>json::sign</b> <i>blockJSON</i> <i>privateKey</i> ?<b>-update</b>|<b>-signature</b> ?<b>-hex</b>|<b>binary</b>??<div style="height: 0.00em;">
&#160;</div>
<b>json::verifySignature</b> <i>blockJSON</i><div style="height: 0.00em;">
&#160;</div>
<b>json::work</b> <i>blockJSON</i> ?<b>-update</b>|<b>-work</b> ?<b>-hex</b>|<b>-binary</b>??<div style="height: 0.00em;">
&#160;</div>
<b>json::validateWork</b> <i>blockJSON</i><div style="height: 0.00em;">
&#160;</div>
<b>json::filter</b> <i>blockJSON</i><div style="height: 1.00em;">
&#160;</div>
<b>dict::toBlock</b> <i>blockDict</i><div style="height: 0.00em;">
&#160;</div>
<b>dict::fromJSON</b> <i>blockJSON</i><div style="height: 0.00em;">
&#160;</div>
<b>dict::fromBlock</b> <i>blockData</i> ?<b>-xrb</b>|<b>-nano</b>? ? <b>-type=</b><i>blockType</i> ? ? <b>-signKey=</b><i>privateKey</i> ?<div style="height: 0.00em;">
&#160;</div>
<b>dict::sign</b> <i>blockDict</i> <i>privateKey</i> ?<b>-update</b>|<b>-signature</b> ?<b>-hex</b>|<b>binary</b>??<div style="height: 0.00em;">
&#160;</div>
<b>dict::verifySignature</b> <i>blockDict</i><div style="height: 0.00em;">
&#160;</div>
<b>dict::work</b> <i>blockDict</i> ?<b>-update</b>|<b>-work</b> ?<b>-hex</b>|<b>-binary</b>??<div style="height: 0.00em;">
&#160;</div>
<b>dict::validateWork</b> <i>blockDict</i><div style="height: 1.00em;">
&#160;</div>
<b>hash</b> <i>blockData</i> ?<b>-hex</b>|<b>-binary</b>?<div style="height: 0.00em;">
&#160;</div>
<b>signBlockHash</b> <i>blockHash</i> <i>privateKey</i> ?<b>-hex</b>|<b>-binary</b>?<div style="height: 0.00em;">
&#160;</div>
<b>sign</b> <i>blockData</i> <i>privateKey</i> ?<b>-hex</b>|<b>-binary</b>?<div style="height: 0.00em;">
&#160;</div>
<b>verifyBlockHash</b> <i>blockHash</i> <i>signature</i> <i>publicKey</i><div style="height: 0.00em;">
&#160;</div>
<b>verify</b> <i>blockData</i> <i>signature</i> <i>publicKey</i><div style="height: 1.00em;">
&#160;</div>
<b>create::send</b> <i>args</i><div style="height: 0.00em;">
&#160;</div>
<b>create::receive</b> <i>args</i><div style="height: 0.00em;">
&#160;</div>
<b>create::setRepresentative</b> <i>args</i><div style="height: 1.00em;">
&#160;</div>
<br/>
<b>work::</b><br/>
<b>fromWorkData</b> <i>blockHashOrPublicKey</i> ?<b>-hex</b>|<b>-binary</b>?<div style="height: 0.00em;">
&#160;</div>
<b>fromBlock</b> <i>blockData</i><div style="height: 0.00em;">
&#160;</div>
<b>validate</b> <i>workData</i> <i>work</i><div style="height: 1.00em;">
&#160;</div>
<br/>
<b>account::</b><br/>
<b>setFrontier</b> <i>account</i> <i>frontierHash</i> <i>balance</i> <i>representative</i><div style="height: 0.00em;">
&#160;</div>
<b>getFrontier</b> <i>account</i><div style="height: 0.00em;">
&#160;</div>
<b>getFrontier</b> <i>account</i> ?<b>frontierHash</b>|<b>balance</b>|<b>representative</b>?<div style="height: 0.00em;">
&#160;</div>
<b>addPending</b> <i>account</i> <i>blockHash</i> <i>amount</i><div style="height: 0.00em;">
&#160;</div>
<b>getPending</b> <i>account</i> ?<i>blockHash</i>?<div style="height: 0.00em;">
&#160;</div>
<b>clearPending</b> <i>account</i> ?<i>blockHash</i>?<div style="height: 1.00em;">
&#160;</div>
<b>receive</b> <i>account</i> <i>blockHash</i> <i>privateKey</i><div style="height: 0.00em;">
&#160;</div>
<b>receiveAllPending</b> <i>account</i> <i>privateKey</i><div style="height: 0.00em;">
&#160;</div>
<b>send</b> <i>fromAccount</i> <i>toAccount</i> <i>amount</i> <i>privateKey</i><div style="height: 0.00em;">
&#160;</div>
<b>setRepresentative</b> <i>account</i> <i>representative</i> <i>privateKey</i><div style="height: 1.00em;">
&#160;</div>
<br/>
<br/>
<div style="height: 1.00em;">
&#160;</div>
</div>
<div class="section">
<h1>INTRODUCTION</h1> <i>Nano</i> is a low-latency payment platform that requires minimal resources, relying on a peer-to-peer network to distribute &quot;blocks&quot;, which are cryptographically signed transactions.  This package provides bindings for interacting with the Nano network from <i>Tcl</i>.<div style="height: 1.00em;">
&#160;</div>
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.<div style="height: 1.00em;">
&#160;</div>
Nano implements a &quot;blockchain&quot;, which is a cryptographic linked-list, by identifying every &quot;block&quot; by its cryptographic hash and providing a pointer from every block to its predecessor in the &quot;chain&quot; as part of the hashed data.<div style="height: 1.00em;">
&#160;</div>
This predecessors is referred to here as the &quot;previous&quot; block.  In Nano, each account has its own blockchain and they reference each other using a data structure referred to as &quot;block lattice&quot;, where the individual chains contain blocks that reference blocks in other chains to tie them together. The field within blocks that reference other blocks on a different blockchain is referred to as either the &quot;link&quot; field or &quot;source block hash&quot;.<div style="height: 1.00em;">
&#160;</div>
Each Nano block also encapsulates the full state of the account, containing, at a minimum, a tuple of (<i>account</i>, <i>balance</i>, <i>representative</i>, <i>previous</i>).<div style="height: 1.00em;">
&#160;</div>
Since Nano blocks are signed by independent actors, who may, for their own gain, generate multiple valid blocks referring to the same predecessor (<i>previous</i>) block, an arbitration mechanism is employed by the Nano network to decide which blocks are valid within a given chain.  This arbitration mechanism operates on the principles of consensus.  Each account holder has a stake in the network operating nominally, otherwise the balance represented by an account is not useful for a transfer of value.  In Nano the stake an account has in the network is equal to the account'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.<div style="height: 1.00em;">
&#160;</div>
Nano utilizes a mechanism called <i>voting</i> to determine which blocks are valid and which blocks are not valid.  Each stakeholder votes their stake upon seeing a new subordinate block (<i>i.e.</i>, a block with a unique <i>previous</i> value).  Since voting is an active and on-going process that occurs on the Nano peer-to-peer network, participants must be online to vote their stake.  As this is often inconvenient or impossible, stakeholders may select another stakeholder to vote their share of the network.  This delegate is referred to as a <i>representative</i>.<div style="height: 1.00em;">
&#160;</div>
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.<div style="height: 1.00em;">
&#160;</div>
Nano accounts are referred to by address.  A Nano address starts with the prefix &quot;<b>nano_</b>&quot; or &quot;<b>xrb_</b>&quot;. A Nano address is actually the public portion of a private/public keypair, plus the prefix, and a checksum to ensure that no digits are mistyped by users when communicating them.  Nano public keys are 256-bit keys in the Ed25519 algorithm.<div style="height: 1.00em;">
&#160;</div>
A user may have many accounts.  To simplify the process of maintaining the private/public keypairs for all the accounts, Nano supports the concept of a <i>wallet</i>. A <i>wallet</i> is a conceptual entity that is used to refer to a <i>seed</i>, which is a random 256-bit number that can be used to derive multiple private/public keypairs from.<div style="height: 1.00em;">
&#160;</div>
Balances in Nano are stored in a 128-bit integer value.  There are various units for representing the balance, the smallest and base unit is called &quot;<i>raw</i>&quot;. The most common unit for users to use is called &quot;<i>Nano</i>&quot;, one of which is equal to 1e30 raw.<div style="height: 1.00em;">
&#160;</div>
<div class="subsection">
<h2>Addresses</h2> Nano addresses are composed of a prefix (either &quot;<b>nano_</b>&quot; or &quot;<b>xrb_</b>&quot;) 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 <b>13456789abcdefghijkmnopqrstuwxyz</b>. The format of these 300 bits are<div class="spacer">
</div>
<br/>
   struct {<br/>
       uint4_t padding = 0000b;<br/>
       uint256_t publicKey;<br/>
       uint40_t  checksum;<br/>
   }<div class="spacer">
</div>
<br/>
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.<div style="height: 1.00em;">
&#160;</div>
For example the public key <b>DC1512154EB72112B8CC230D7B8C7DD467DA78E4763182D6CAFAADB14855A5E8</b> which has a 5-byte Blake2b hash of <b>{0x18, 0x74, 0xA3, 0x46, 0x9C}</b> would be encoded as <b>0000.DC1512154EB72112B8CC230D7B8C7DD467DA78E4763182D6CAFAADB14855A5E8.9C46A37418</b> which when encoded in base32 and the prefix added produces the address <b>nano_3q1o4acnxfs34cwerarfhg89uo59ubwgaxjjiddeoyofp767dbhamj5c8x1r</b>.<div style="height: 1.00em;">
&#160;</div>
</div>
<div class="subsection">
<h2>Network</h2> 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 (<i>bootstrapping</i>). The real-time network is a broadcast style network where every message sent over it are relayed to all other nodes.<div style="height: 1.00em;">
&#160;</div>
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.<div style="height: 1.00em;">
&#160;</div>
The format of the messages on both networks is the same, however not every type of message may be used on either network.  The <b>keepalive</b> message type is invalid on the TCP (bootstrapping) network and the <b>bulk_pull</b> message type is invalid on the UDP (real-time) network.  The format of message are an 8 byte header consisting of:<div class="spacer">
</div>
<br/>
   struct {<br/>
       uint8_t magicProtocol = 0x52;<br/>
       uint8_t magicNetwork  = 0x41/0x42/0x43;<br/>
       uint8_t versionMax;<br/>
       uint8_t version;<br/>
       uint8_t versionMin;<br/>
       uint8_t messageType;<br/>
       uint16_t extensions;<br/>
   };<div class="spacer">
</div>
<br/>
Where the <b>magicProtocol</b> field must be the value <b>0x52</b> (which is ASCII 'R') and the <b>magicNetwork</b> field must be one of <b>0x41</b>, <b>0x42</b>, or <b>0x43</b> corresponding to one of the three Nano networks.  A value of <b>0x41</b> (ASCII 'A') represents the Test network;  A value of <b>0x42</b> (ASCII 'B') represents the Beta network;  A value of <b>0x43</b> (ASCII 'C') represents the Main network.<div style="height: 1.00em;">
&#160;</div>
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 <b>versionMax</b> and <b>versionMin</b> fields indicate the inclusive range of acceptable versions to relay or broadcast this message to.  The <b>version</b> field indicates what version of the Nano protocol this node is using.<div style="height: 1.00em;">
&#160;</div>
The messageType field indicates what type of message is being relayed, and must conform to the following enumeration<table class="tbl">
<col style="width: 11.00ex;"/>
<col style="width: 16.00ex;"/>
<col style="width: 12.00ex;"/>
<col style="width: 11.00ex;"/>
<tbody>
<tr>
<td>
messageType</td>
<td>
Name</td>
<td>
On Bootstrap</td>
<td>
On Realtime</td>
</tr>
<tr>
<td>
0x00</td>
<td>
Invalid</td>
<td>
Yes</td>
<td>
Yes</td>
</tr>
<tr>
<td>
0x01</td>
<td>
Not_A_Type</td>
<td>
?</td>
<td>
?</td>
</tr>
<tr>
<td>
0x02</td>
<td>
Keepalive</td>
<td>
No</td>
<td>
Yes</td>
</tr>
<tr>
<td>
0x03</td>
<td>
Publish</td>
<td>
No</td>
<td>
Yes</td>
</tr>
<tr>
<td>
0x04</td>
<td>
Confirm_Req</td>
<td>
No</td>
<td>
Yes</td>
</tr>
<tr>
<td>
0x05</td>
<td>
Confirm_Ack</td>
<td>
No</td>
<td>
Yes</td>
</tr>
<tr>
<td>
0x06</td>
<td>
Bulk_Pull</td>
<td>
Yes</td>
<td>
No</td>
</tr>
<tr>
<td>
0x07</td>
<td>
Bulk_Push</td>
<td>
Yes</td>
<td>
No</td>
</tr>
<tr>
<td>
0x08</td>
<td>
Frontier_Req</td>
<td>
Yes</td>
<td>
No</td>
</tr>
<tr>
<td>
0x09</td>
<td>
Bulk_Pull_Blocks</td>
<td>
Yes</td>
<td>
No</td>
</tr>
</tbody>
</table>
<div style="height: 1.00em;">
&#160;</div>
<b>TODO: Extensions</b><div style="height: 1.00em;">
&#160;</div>
Following the message header comes the payload for the particular message type.<div style="height: 1.00em;">
&#160;</div>
<dl>
<dt>
<b>Invalid</b></dt>
<dd>
TODOC<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>Not_A_Type</b></dt>
<dd>
TODOC<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>Keepalive</b></dt>
<dd>
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.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>Publish</b></dt>
<dd>
TODOC<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>Confirm_Req</b></dt>
<dd>
TODOC<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>Confirm_Ack</b></dt>
<dd>
TODOC<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>Bulk_Pull</b></dt>
<dd>
TODOC<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>Bulk_Push</b></dt>
<dd>
TODOC<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>Frontier_Req</b></dt>
<dd>
TODOC<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>Bulk_Pull_Blocks</b></dt>
<dd>
TODOC<div style="height: 1.00em;">
&#160;</div>
<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
</div>
</div>
<div class="section">
<h1>PROCEDURES</h1><div class="subsection">
<h2>Addresses</h2><dl>
<dt>
<b>::nano::address::toPublicKey</b></dt>
<dd>
<i>address</i> ?<b>-hex</b>|<b>-binary</b>? ?<b>-verify</b>|<b>-no-verify</b>? <b> -&gt; </b><i>publicKey</i><div style="height: 1.00em;">
&#160;</div>
Converts a Nano address to a public key.  The <b>-hex</b> option indicates that the public key should be returned in hexadecimal form. The <b>-binary</b> option indicates that the public key should be returned in binary form. The <b>-verify</b> option verifies the checksum embedded in the Nano address before returning. The <b>-no-verify</b> option inhibits verifying the checksum embedded in the Nano address.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>::nano::address::fromPublicKey</b></dt>
<dd>
<i>pubKey</i> ?<b>-xrb</b>|<b>-nano</b>? <b> -&gt; </b><i>address</i><div style="height: 1.00em;">
&#160;</div>
Converts a public key to a Nano address. The <b>-xrb</b> option specifies that the returned address should be prefixed with the old-style &quot;xrb_&quot; prefix, where the <b>-nano</b> option specifies that the returned address should be prefixed with the new-style &quot;nano_&quot; prefix.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>::nano::address::fromPrivateKey</b></dt>
<dd>
<i>privateKey</i> ?<b>-xrb</b>|<b>-nano</b>? <b> -&gt; </b><i>address</i><div style="height: 1.00em;">
&#160;</div>
Converts a private key to a Nano address.  It accepts the same arguments as <b>fromPublicKey</b>.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
</div>
<div class="subsection">
<h2>Key Management</h2><dl>
<dt>
<b>::nano::key::newSeed</b></dt>
<dd>
?<b>-hex</b>|<b>-binary</b>? -&gt; <i>seed</i><div style="height: 1.00em;">
&#160;</div>
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 <b>fromSeed</b> procedure. The <b>-hex</b> and <b>-binary</b> options determine the formatting of the result.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>::nano::key::newKey</b></dt>
<dd>
?<b>-hex</b>|<b>-binary</b>?  -&gt; <i>privateKey</i><div style="height: 1.00em;">
&#160;</div>
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 <b>publicKeyFromPrivateKey</b>). This procedure is normally not used, but rather private keys are derived from a <i>seed</i> and <i>index</i> pair using the <b>fromSeed</b> procedure. The <b>-hex</b> and <b>-binary</b> options determine the formatting of the result.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>::nano::key::fromSeed</b></dt>
<dd>
<i>seed</i> ?<i>index</i>? ?<b>-hex</b>|<b>-binary</b>?  -&gt; <i>privateKey</i><div style="height: 1.00em;">
&#160;</div>
Derive a private key from the seed specified as <i>seed</i> and the <i>index</i> indicated.  This procedure is deterministic (i.e., the same <i>seed</i> and <i>index</i> will always give you the same private key).  This procedure is used to derive many keypairs from a single user-managed piece of data, so the user does not have to manage multiple private keys.  If the <i>index</i> is not specified it defaults to <b>0</b>. The <b>-hex</b> and <b>-binary</b> options determine the formatting of the result.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>::nano::key::publicKeyFromPrivateKey</b></dt>
<dd>
<i>privateKey</i> ?<b>-hex</b>|<b>-binary</b>?  -&gt; <i>publicKey</i><div style="height: 1.00em;">
&#160;</div>
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 <b>-hex</b> and <b>-binary</b> options determine the formatting of the result.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
</div>
<div class="subsection">
<h2>Low-level Block</h2><dl>
<dt>
<b>::nano::block::</b><i>representation</i><b>::toBlock</b></dt>
<dd>
<i>blockRepresentation</i>  -&gt; <i>blockData</i><div style="height: 1.00em;">
&#160;</div>
Converts from one of the internal representations (either Tcl dictionary or JSON) to a Nano block. The <i>representation</i> portion of the command name may be one of <b>dict</b> or <b>json</b>.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>::nano::block::json::fromDict</b></dt>
<dd>
<i>blockDict</i>  -&gt; <i>blockJSON</i><div style="height: 1.00em;">
&#160;</div>
Converts from a Tcl dictionary representation to a JSON representation of a block.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>::nano::block::json::filter</b></dt>
<dd>
<i>blockJSON</i>  -&gt; <i>blockJSON</i><div style="height: 1.00em;">
&#160;</div>
Filters out JSON object attributes which are not suitable for using with other implementations, such as <i>_comment</i>, <i>_workData</i>, and <i>_blockHash</i>.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>::nano::block::dict::fromJSON</b></dt>
<dd>
<i>blockJSON</i>  -&gt; <i>blockDict</i><div style="height: 1.00em;">
&#160;</div>
Converts from a JSON object representation to a Tcl dictionary representation of a block.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>::nano::block::</b><i>representation</i><b>::fromBlock</b></dt>
<dd>
<i>blockData</i> ?<b>-xrb</b>|<b>-nano</b>? ? <b>-type=</b><i>blockType</i> ? ? <b>-signKey=</b><i>privateKey</i> ?  -&gt; <i>blockRepresentation</i><div style="height: 1.00em;">
&#160;</div>
Parses a Nano block and returns either a Tcl dictionary or a JSON object. The <b>-xrb</b> option causes all parsed addresses to be prefixed with the old-style &quot;xrb_&quot; address prefix, while the <b>-nano</b> option causes them to be prefixed with the new-style &quot;nano_prefix&quot;. The <i>representation</i> portion of the command name may be one of <b>dict</b> or <b>json</b>.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>::nano::block::</b><i>representation</i><b>::sign</b></dt>
<dd>
<i>blockRepresentation</i> <i>privateKey</i> ?<b>-update</b>|<b>-signature</b> ?<b>-hex</b>|<b>binary</b>??  -&gt; <i>signature</i>|<i>blockJSON</i><div style="height: 1.00em;">
&#160;</div>
Sign a block, in either Tcl dictionary or JSON representation, with the specified <i>privateKey</i>. If the <b>-update</b> option is used, return the object with the updated attribute. If the <b>-signature</b> option is used, return just the signature. The <b>-hex</b> and <b>-binary</b> options determine the formatting of the result. The <i>representation</i> portion of the command name may be one of <b>dict</b> or <b>json</b>.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>::nano::block::</b><i>representation</i><b>::verifySignature</b></dt>
<dd>
<i>blockRepresentation</i>  -&gt; <i>boolean</i><div style="height: 1.00em;">
&#160;</div>
Verify the signature on a block, in either Tcl dictionary or JSON representation, matches the public key specified in the <b>account</b> attribute of that object.  This may not work correctly for old-style blocks unless you manually add the <b>account</b> attribute. The <i>representation</i> portion of the command name may be one of <b>dict</b> or <b>json</b>.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>::nano::block::</b><i>representation</i><b>::work</b></dt>
<dd>
<i>blockRepresentation</i> ?<b>-update</b>|<b>-work</b> ?<b>-hex</b>|<b>binary</b>??  -&gt; <i>work</i>|<i>blockRepresentation</i><div style="height: 1.00em;">
&#160;</div>
Generate proof-of-work (PoW) required to submit a given block to the network. Nano uses PoW to increase the cost of submitting blocks to the network to cut down on spam.  The <i>work</i> that is computed is based on the hash of the previous block on this chain, or if there is no previous block on this chain (i.e., because it is the first block on an account) the public key of the account.  If the <b>-update</b> option is used, return the object with the updated attribute. If the <b>-work</b> option is used, just return the work. The <b>-hex</b> and <b>-binary</b> options determine the formatting of the result. The <i>representation</i> portion of the command name may be one of <b>dict</b> or <b>json</b>.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>::nano::block::</b><i>representation</i><b>::validateWork</b></dt>
<dd>
<i>blockRepresentation</i>  -&gt; <i>boolean</i><div style="height: 1.00em;">
&#160;</div>
Validate the proof-of-work (PoW) in the object specified as <i>blockRepresentation</i> with the attribute <b>work</b> is valid for the block passed in. The <i>representation</i> portion of the command name may be one of <b>dict</b> or <b>json</b>.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>::nano::block::hash</b></dt>
<dd>
<i>blockData</i> ?<b>-hex</b>|<b>-binary</b>?  -&gt; <i>blockHash</i><div style="height: 1.00em;">
&#160;</div>
Compute the cryptographic hash of a block.  The cryptographic hashing algorithm used for Nano is Blake2b.  Blocks are typically identified by their hash (i.e., content addressable). The <b>-hex</b> and <b>-binary</b> options determine the formatting of the result.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>::nano::block::signBlockHash</b></dt>
<dd>
<i>blockHash</i> <i>privateKey</i> ?<b>-hex</b>|<b>-binary</b>?  -&gt; <i>signature</i><div style="height: 1.00em;">
&#160;</div>
Compute an Ed25519-with-Blake2b signature of a given block hash specified as <i>blockHash</i> with the private key specified as <i>privateKey</i>. In Nano, signed blocks are signed by signing the block's hash thus all that is needed to sign a block is its hash and the private key that corresponds to the account. <b>NOTE: Ensure that the</b> <i>privateKey</i> <b>specified matches the account the block belongs to.</b> The <b>-hex</b> and <b>-binary</b> options determine the formatting of the result.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>::nano::block::sign</b></dt>
<dd>
<i>blockData</i> <i>privateKey</i> ?<b>-hex</b>|<b>-binary</b>?  -&gt; <i>signature</i><div style="height: 1.00em;">
&#160;</div>
This is a convenience procedure which computes the hash of a block given as <i>blockData</i>, and then calls <b>signBlockHash</b>. The <b>-hex</b> and <b>-binary</b> options determine the formatting of the result.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>::nano::block::verifyBlockHash</b></dt>
<dd>
<i>blockHash</i> <i>signature</i> <i>publicKey</i>  -&gt; <i>boolean</i><div style="height: 1.00em;">
&#160;</div>
Verify that a block hash (<i>blockHash</i>) was signed (<i>signature</i>) by an account holding the private key that corresponds to the public key specified as <i>publicKey</i>.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>::nano::block::verify</b></dt>
<dd>
<i>blockData</i> <i>signature</i> <i>publicKey</i>  -&gt; <i>boolean</i><div style="height: 1.00em;">
&#160;</div>
This is a convenience procedure which computes the hash of a block given as <i>blockData</i>, and then calls <b>verifyBlockHash</b>.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>::nano::block::create::send</b></dt>
<dd>
<b>from </b><i>address</i> <b>to </b><i>address</i> <b>previous </b><i>blockHash</i> <b>representative </b><i>address</i> <b>previousBalance </b><i>integer</i> <b>amount </b><i>integer</i> ? <b>-json </b><i>boolean</i> ?  -&gt; <i>blockJSON</i>|<i>blockDict</i><div style="height: 1.00em;">
&#160;</div>
This is a low-level interface for creating blocks which correspond to sending Nano from one account to another.  It constructs a block which sends the <b>amount</b> specified from the <b>from</b> address to the destination (<b>to</b>). The previous block's hash must be specified as the <i>blockHash</i> following <b>previous</b>. Additionally the balance of the account at the previous block must be supplied as the integer argument to <b>previousBalance</b>. All balance amounts are in units of <b>raw</b>. If the optional <b>-json</b> argument is used and specified as true the result is a JSON representation, otherwise a Tcl dict representation is used.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>::nano::block::create::receive</b></dt>
<dd>
<b>to </b><i>address</i> <b>sourceBlock </b><i>blockHash</i> <b>previous </b><i>blockHash</i> <b>representative </b><i>address</i> <b>previousBalance </b><i>integer</i> <b>amount </b><i>integer</i> ? <b>-json </b><i>boolean</i> ?  -&gt; <i>blockJSON</i>|<i>blockDict</i><div style="height: 1.00em;">
&#160;</div>
This is a low-level interface for creating blocks which correspond to receiving (pocketing) Nano previously sent from another account to the account specified as the <i>address</i> supplied to the <b>to</b> argument.  It constructs a block which receives the amount of Nano specified as the <b>amount</b> argument. The block hash (<i>blockHash</i>) of the send block which was used to send the Nano to this account must be specified as the argument to the <b>sourceBlock</b> option. The previous block's hash must be specified as the <i>blockHash</i> following <b>previous</b>. Additionally the balance of the account at the previous block must be supplied as the integer argument to <b>previousBalance</b>. All balance amounts are in units of <b>raw</b>. If the optional <b>-json</b> argument is used and specified as true the result is a JSON representation, otherwise a Tcl dict representation is used.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>::nano::block::create::setRepresentative</b></dt>
<dd>
<b>account </b><i>address</i> <b>previous </b><i>blockHash</i> <b>representative </b><i>address</i> ? <b>-json </b><i>boolean</i> ?  -&gt; <i>blockJSON</i>|<i>blockDict</i><div style="height: 1.00em;">
&#160;</div>
This is a low-level interface for creating blocks which correspond to an explicit change of representative.  Representatives in Nano are used as part of the Delegated Proof-of-Stake (dPoS) consensus mechanism which is used by the Nano network to determine which block (if any) out of many possible subordinate blocks in a chain are valid.  So that every account holder does not have to be online to vote for valid transactions, an account may delegate another account to vote its stake on its behalf.  That delegate is called a representative.  An account may change its representative at any time by issuing a block with a new representative, such as a send or receive block, or by issuing an explicit change of representative block.  This procedure creates an explicit change of representative block for the <b>account</b> specified.  It changes to the delegate to the <b>representative</b> specified.  Further, the <i>blockHash</i> of the previous block must be specified as the argument to <b>previous</b>. If the optional <b>-json</b> argument is used and specified as true the result is a JSON representation, otherwise a Tcl dict representation is used.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
</div>
<div class="subsection">
<h2>Work Generation</h2><dl>
<dt>
<b>::nano::work::fromWorkData</b></dt>
<dd>
<i>blockHashOrPublicKey</i> ?<b>-hex</b>|<b>-binary</b>?  -&gt; <i>work</i><div style="height: 1.00em;">
&#160;</div>
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 (<i>previous</i>) is used.  The specific value needed should be accessible from the <b>_workData</b> member of a JSON object or Tcl dictionary.  Note that this attribute (and all attributes that begin with an underscore) should be discarded when sending the block outside of the Tcl process. The <b>-hex</b> and <b>-binary</b> options determine the formatting of the result.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>::nano::work::fromBlock</b></dt>
<dd>
<i>blockData</i>  -&gt; <i>work</i><div style="height: 1.00em;">
&#160;</div>
This is a convenience procedure which computes work data (either a block hash or a public key) for a given block and then calls <b>fromWorkData</b>.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>::nano::work::validate</b></dt>
<dd>
<i>workData</i> <i>work</i>  -&gt; <i>boolean</i><div style="height: 1.00em;">
&#160;</div>
This procedure validates that the supplied <i>work</i> is valid for the supplied <i>workData</i>, which is either a block hash or an account public key.  For more information see the description of <b>fromWorkData</b>.<div style="height: 1.00em;">
&#160;</div>
<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
</div>
<div class="subsection">
<h2>High-level Account</h2><dl>
<dt>
<b>:nano::account::setFrontier</b></dt>
<dd>
<i>account</i> <i>frontierHash</i> <i>balance</i> <i>representative</i><div style="height: 1.00em;">
&#160;</div>
This procedure is used as part of the High-level Account interface.  It sets the <i>frontier</i>, which is the block hash (<i>frontierHash</i>) and data (<i>balance</i>, <i>representative</i>) associated with that block that corresponds to the head of an account's chain.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>:nano::account::getFrontier</b></dt>
<dd>
<i>account</i>  -&gt; <i>frontierInfo</i><div style="height: 1.00em;">
&#160;</div>
This procedure is used as part of the High-level Account interface.  It gets the Tcl dictionary associated with the frontier most recently set for the specified <i>account</i>.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>:nano::account::getFrontier</b></dt>
<dd>
<i>account</i> ?<b>frontierHash</b>|<b>balance</b>|<b>representative</b>?  -&gt; <i>frontierHash</i>|<i>balance</i>|<i>representative</i><div style="height: 1.00em;">
&#160;</div>
This procedure is used as part of the High-level Account interface.  It gets a specific item from Tcl dictionary associated with the frontier most recently set for the specified <i>account</i>.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>:nano::account::addPending</b></dt>
<dd>
<i>account</i> <i>blockHash</i> <i>amount</i><div style="height: 1.00em;">
&#160;</div>
This procedure is used as part of the High-level Account interface.  It is used to indicate than a given <i>account</i> has a <b>receive</b> block that they could create.  The block hash of the corresponding <b>send</b> block should be supplied as the <i>blockHash</i> parameter.  The amount of Nano that was sent in the <b>send</b> block should be specified as the <i>amount</i> parameter (in units of raw).<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>:nano::account::getPending</b></dt>
<dd>
<i>account</i> ?<i>blockHash</i>?  -&gt; <i>dict</i><div style="height: 1.00em;">
&#160;</div>
This procedure is used as part of the High-level Account interface.  It is used to retrieve information stored by <b>addPending</b> for a given <i>account</i>. If the <i>blockHash</i> parameter is supplied then a Tcl dictionary is returned with a key called <b>amount</b> which contains the amount stored previously.  If the <i>blockHash</i> parameter is not supplied then a Tcl dictionary is returned with keys corresponding to each block hash pending for the specified <i>account</i>, and containing a subordinate Tcl dictionary with a key called <b>amount</b> as previously described.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>::nano::account::clearPending</b></dt>
<dd>
<i>account</i> ?<i>blockHash</i>?<div style="height: 1.00em;">
&#160;</div>
This procedure is used as part of the High-level Account interface.  It is used to clear (that is, remove from the conceptual state of &quot;pending&quot;) entries created previously with <b>addPending</b> for a given <i>account</i>. If the <i>blockHash</i> parameter is supplied then only the entry corresponding to that blockhash is cleared, otherwise all entries for the specified <i>account</i> are cleared.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>:nano::account::receive</b></dt>
<dd>
<i>account</i> <i>blockHash</i> <i>privateKey</i>  -&gt; <i>blockJSON</i>|<i>blockDict</i><div style="height: 1.00em;">
&#160;</div>
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.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>:nano::account::receiveAllPending</b></dt>
<dd>
<i>account</i> <i>privateKey</i>  -&gt; <i>listOfBlockJSON</i>|<i>listOfBlockDict</i><div style="height: 1.00em;">
&#160;</div>
This procedure is used as part of the High-level Account interface.  It is used to generate receive blocks for every pending receive on a given <i>account</i>. Its interface is subject to change and not considered stable.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>:nano::account::send</b></dt>
<dd>
<i>fromAccount</i> <i>toAccount</i> <i>amount</i> <i>privateKey</i>  -&gt; <i>blockJSON</i>|<i>blockDict</i><div style="height: 1.00em;">
&#160;</div>
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.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
<dl>
<dt>
<b>::nano::account::setRepresentative</b></dt>
<dd>
<i>account</i> <i>representative</i> <i>privateKey</i>  -&gt; <i>blockJSON</i>|<i>blockDict</i><div style="height: 1.00em;">
&#160;</div>
This procedure is used as part of the High-level Account interface.  It is used to generate a block that changes the representative for the given <i>account</i>. Its interface is subject to change and not considered stable.<div style="height: 1.00em;">
&#160;</div>
</dd>
</dl>
</div>
</div>
<div class="section">
<h1>EXAMPLES</h1><div class="subsection">
<h2>Example 1: Generate a new seed and derive 10 addresses from it</h2><br/>
package require nano 1.1<div class="spacer">
</div>
<br/>
set seed &#91;::nano::key::newSeed -hex&#93;<br/>
puts &quot;Generated seed: $seed&quot;<div class="spacer">
</div>
<br/>
for {set index 0} {$index &lt; 10} {incr index} {<br/>
	set accountPrivateKey &#91;::nano::key::fromSeed $seed $index -hex&#93;<br/>
	set accountAddress &#91;::nano::address::fromPrivateKey $accountPrivateKey&#93;<br/>
	puts &quot;    - $index: $accountAddress&quot;<br/>
}<br/>
<div style="height: 1.00em;">
&#160;</div>
</div>
</div>
<div class="section">
<h1>AUTHOR</h1> Roy Keene &lt;<i>rkeene@nano.org</i>&gt;</div>
<table class="foot">
<tr>
<td class="foot-date">
17-Jul-2018</td>
<td class="foot-os">
nano 1.1</td>
</tr>
</table>
</div>












Powered by Fossil · RSS