Diff

Differences From Artifact [528fa84ed3]:

To Artifact [1b94443006]:


236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
.IR Tcl .

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 crytographic 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







|







236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
.IR Tcl .

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
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
to determine which blocks are valid and which blocks are not valid.  Each
stakeholder votes their stake upon seeing a new subordinate block
.RI ( i.e. ,
a block with a unique
.I previous
value).  Since voting is an active and on-going process that occurs on the Nano
peer-to-peer network, participants must be online to vote their stake.  As this
is often inconvienent or impossible, stakeholders may select another
stakeholder to vote their share of the network.  This delegate is referred to
as a
.IR representative .

Representatives should be chosen carefully by stakeholders since malicious
representatives may attempt to gather voting power and destablize the Nano
network by altering decisions made by consensus previously.

Nano accounts are referred to by address.  A Nano address starts with the
prefix
.RB \(dq nano_ "\(dq or \(dq" xrb_ \(dq.
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
.IR wallet .
A
.I wallet
is a conceptual entity that is used to refer to a
.IR seed ,
which is a random 256-bit number that can be used to derive mulitple
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
.RI \(dq raw \(dq.
The most common unit for users to use is called
.RI \(dq Nano \(dq,
one of which is equal to 1e30 raw.

.SS Addresses
Nano addresses are composed of a prefix (either
.RB \(dq nano_ \(dq
or
.RB \(dq xrb_ \(dq)
and 300 bits of base32 encoded data.  The 300-bits of base32 encoded data
produce a string that is 6 charectars long using the base32 alphabet
.BR 13456789abcdefghijkmnopqrstuwxyz .
The format of these 300 bits are
.EX

  [Padding (4 bits: 0)].[Public Key (256 bits)].[Checksum (40 bits)]

.EE







|





|

















|















|







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
to determine which blocks are valid and which blocks are not valid.  Each
stakeholder votes their stake upon seeing a new subordinate block
.RI ( i.e. ,
a block with a unique
.I previous
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
.IR representative .

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
.RB \(dq nano_ "\(dq or \(dq" xrb_ \(dq.
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
.IR wallet .
A
.I wallet
is a conceptual entity that is used to refer to a
.IR seed ,
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
.RI \(dq raw \(dq.
The most common unit for users to use is called
.RI \(dq Nano \(dq,
one of which is equal to 1e30 raw.

.SS Addresses
Nano addresses are composed of a prefix (either
.RB \(dq nano_ \(dq
or
.RB \(dq xrb_ \(dq)
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
.BR 13456789abcdefghijkmnopqrstuwxyz .
The format of these 300 bits are
.EX

  [Padding (4 bits: 0)].[Public Key (256 bits)].[Checksum (40 bits)]

.EE
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
.I address
.RB ? -hex | -binary ?
.RB ? -verify | -no-verify ?
.BI " -> " publicKey

Converts a Nano address to a public key.  The
.B -hex
option indicates that the public key should be returned in hexidecimal form.
The
.-B -binary
option indicates that the public key should be returned in binary form.
The
.B -verify
option verifies the checksum embedded in the Nano address before returning.
The







|







342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
.I address
.RB ? -hex | -binary ?
.RB ? -verify | -no-verify ?
.BI " -> " publicKey

Converts a Nano address to a public key.  The
.B -hex
option indicates that the public key should be returned in hexadecimal form.
The
.-B -binary
option indicates that the public key should be returned in binary form.
The
.B -verify
option verifies the checksum embedded in the Nano address before returning.
The
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

.SS Key Management
.TP
.B ::nano::key::newSeed
.RB ? -hex | -binary ?
.RI "-> " seed

Generates a new seed.  A seed is a 256-bit bitfield which, along with a 32-bit
index, is used to derive enumerated keys from a single point of entropy.  See
the
.B fromSeed
procedure.
.HB

.TP
.B ::nano::key::newKey
.RB ? -hex | -binary ?
.RI " -> " privateKey

Generates a new private key.  A private key can be used to sign transactions,
which can then be verified with its cooresponding public key (see
.BR publicKeyFromPrivateKey ).
This procedure is normally not used, but rather private keys are derived
from a
.I seed
and
.I index
pair using the







|












|







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

.SS Key Management
.TP
.B ::nano::key::newSeed
.RB ? -hex | -binary ?
.RI "-> " seed

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
procedure.
.HB

.TP
.B ::nano::key::newKey
.RB ? -hex | -binary ?
.RI " -> " privateKey

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
.BR publicKeyFromPrivateKey ).
This procedure is normally not used, but rather private keys are derived
from a
.I seed
and
.I index
pair using the
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
.TP
.B ::nano::key::publicKeyFromPrivateKey
.I privateKey
.RB ? -hex | -binary ?
.RI " -> " publicKey

Converts a private key into its corresponding public key.  Normally Ed25519
private keys are a concatencation of the private and public keys, however in
this package they are each treated separately.
.HB

.SS Low-level Block
.TP
.BI ::nano::block:: representation ::toBlock
.I blockRepresentation







|







437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
.TP
.B ::nano::key::publicKeyFromPrivateKey
.I privateKey
.RB ? -hex | -binary ?
.RI " -> " publicKey

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.
.HB

.SS Low-level Block
.TP
.BI ::nano::block:: representation ::toBlock
.I blockRepresentation
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
.TP
.B ::nano::block::sign
.I blockData
.I privateKey
.RB ? -hex | -binary ?
.RI " -> " signature

This is a convienence procedure which computes the hash of a block given as
.IR blockData ,
and then calls
.BR signBlockHash .
.HB

.TP
.B ::nano::block::verifyBlockHash







|







578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
.TP
.B ::nano::block::sign
.I blockData
.I privateKey
.RB ? -hex | -binary ?
.RI " -> " signature

This is a convenience procedure which computes the hash of a block given as
.IR blockData ,
and then calls
.BR signBlockHash .
.HB

.TP
.B ::nano::block::verifyBlockHash
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
.TP
.B ::nano::block::verify
.I blockData
.I signature
.I publicKey
.RI " -> " boolean

This is a convienence procedure which computes the hash of a block given as
.IR blockData ,
and then calls
.BR verifyBlockHash .

.TP
.B ::nano::block::create::send
.BI "from "            address







|







606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
.TP
.B ::nano::block::verify
.I blockData
.I signature
.I publicKey
.RI " -> " boolean

This is a convenience procedure which computes the hash of a block given as
.IR blockData ,
and then calls
.BR verifyBlockHash .

.TP
.B ::nano::block::create::send
.BI "from "            address
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
sending the block outside of the Tcl process.

.TP
.B ::nano::work::fromBlock
.I blockData
.RI " -> " work

This is a convienence procedure which computes work data (either a block hash
or a public key) for a given block and then calls
.BR fromWorkData .

.TP
.B ::nano::work::validate
.I workData
.I work







|







734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
sending the block outside of the Tcl process.

.TP
.B ::nano::work::fromBlock
.I blockData
.RI " -> " work

This is a convenience procedure which computes work data (either a block hash
or a public key) for a given block and then calls
.BR fromWorkData .

.TP
.B ::nano::work::validate
.I workData
.I work