Nano is a digital payment protocol designed to be accessible and lightweight, with a focus on removing inefficiencies present in other cryptocurrencies.


Logo

Live Artifacts Beta Artifacts GitHub release (latest by date) GitHub tag (latest by date) Tests RelWithDebug Tests Discord


What is Nano?

Nano is a digital payment protocol designed to be accessible and lightweight, with a focus on removing inefficiencies present in other cryptocurrencies. With ultrafast transactions and zero fees on a secure, green and decentralized network, this makes Nano ideal for everyday transactions.


Guides & Documentation

Other documentation details can be found at https://docs.nano.org.


Links & Resources


Want to Contribute?

Please see the contributors guide.


Contact us

We want to hear about any trouble, success, delight, or pain you experience when using Nano. Let us know by filing an issue, joining us on Reddit, or joining us on Discord.

Comments
  • Setting up NANO test network?

    Setting up NANO test network?

    Hello,

    I'm new to NANO and am interested in setting up a "test" network with just a couple of docker nodes that I can use the CLI or web interface to connect to and explore to get a feel for how things work. I want to learn how to setup the TEST network, configure it, and then interact with it as some initial steps.

    I am trying to determine how NANO compares to STEEM, BITSHARES, and EOS as far as transactions-per-second and scalability.

    Is there any documentation on this?

    Also, I am seeking a NANO forum or other place to discuss NANO core code development as well.

    Any assistance or input would be greatly appreciated Thanks and have a great day,

  • Can't start the wallet on Ubuntu 17.04

    Can't start the wallet on Ubuntu 17.04

    I was using rai_wallet a few months ago without any problem, but now I get: $ ./rai_wallet Aborted (core dumped)

    I think it's caused by Ubuntu upgrade to 17.04 My current kernel is: Linux 4.10.0-21-generic #23-Ubuntu SMP Fri Apr 28 16:14:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

    Any thoughts how to fix it?

  • Node v.11.2 died after 3h

    Node v.11.2 died after 3h

    Description of bug: Node just died without messages in the log after running for 3 hours. Compiled from git master; commit 84a6b5160e2d81cf86b23a81f5a52d29553e7287

    Additional information you deem important (e.g. issue happens only occasionally): System Load seems significant higher than with 11.1.1, sometimes 90%-180% in top, will attach graph when more useful in some hours.

    Environment: Arch Linux Server, 4gb ram, SSD CPU(s): 2 Single core Intel Xeon E5-2680 v2s (-MT-SMP-) cache: 32768 KB clock speeds: max: 2799 MHz 1: 2799 MHz 2: 2799 MHz

    Raiblocks folder stored in ramdisk. Node Monitor: https://nanode21.cloud/stats.php

    logs https://nanode21.cloud/11.2.log

  • Would Raiblocks applications (malicious or not) be vulnerable to private key leaking?

    Would Raiblocks applications (malicious or not) be vulnerable to private key leaking?

    I was looking about the sign algorithm Ed25519 and found this issue: https://github.com/jedisct1/libsodium/issues/170

    Lets imagine the flow below:

    1. Origin wallet sign a transaction and broadcast it
    2. Some bit(s) could flip during the signing
    3. Destination wallet receives the transaction and invalidates it because of wrong signature
    4. Origin wallet creates the same transaction again and re-broadcasts it
    5. Destination wallet receives the transaction ok. And as a prize, it could extract the origin wallet's private key

    Having some bits changed during the signing happens, a lot. And happens more on mobile devices, mostly on iOS for example.

    It could expose the private key, not just to the destination, but for all network.

  • Change storage technology

    Change storage technology

    Why

    Currently one of the largest costs of running a Raiblocks node is due to the large amount of IO needed just to keep up with the current write rate.

    General Info

    Disks can do ~75 to 100 iops per second, or 120 Megabytes per second (sequential io). Consumer SSD's can do ~10K iops, or 375 Megabytes per second of IO.

    Problem Description

    Bootstrapping currently requires ~1k iops and 3 megabytes/s. So LMDB is generating a lot of very small writes for every block, but it's not actually writing much data. The write rate would be easily done on a single spinning disk if the IO's were structured differently.

    That's not ideal for this usecase where we are more concerned with being able to sustain a large write rate. There's a very large temporal distribution of data; newer data is more likely to be read while old data is less likely to be read. So we should choose a data-storage technology that allows for very cheap writes, has relatively cheap reads on recent data, and can scale to large amounts of data.

    LMDB is a memory mapped B-Tree. It makes for some very very fast random reads; however it's expensive for writes.

    Log Structured Merge Trees however have the exact properties that we're looking for. See: The advantages of an LSM vs a B-Tree

    Log structured merge trees allow writes to come in at a fantastic rate, and only generate a small amount of larger IO's. So we should think about replacing LMDB with a log structured merge tree. The best in breed currently is RocksDB. It also has the added advantage that it can compress blocks.

    Suggested Solution

    1. Add RocksDB
    2. Add ZSTD
    3. Configure RocksDB with universal compaction,
    4. Add a flag to allow using RockDB.
    5. After it's all tested and shown to be working remove the LMDB code.

    Steps to reproduce the issue:

    1. Start a new rai node
    2. Run iostat -dxt 5
    3. Notice the very very small IO's being issued.

    Environment:

    cpu:
                           Intel(R) Core(TM) i5-4250U CPU @ 1.30GHz, 1995 MHz
                           Intel(R) Core(TM) i5-4250U CPU @ 1.30GHz, 1950 MHz
                           Intel(R) Core(TM) i5-4250U CPU @ 1.30GHz, 1733 MHz
                           Intel(R) Core(TM) i5-4250U CPU @ 1.30GHz, 2444 MHz
    storage:
                           Intel 8 Series SATA Controller 1 [AHCI mode]
    network:
      eno1                 Intel Ethernet Connection I218-V
    network interface:
      eno1                 Ethernet network interface
      lo                   Loopback network interface
      docker0              Ethernet network interface
      veth8964baa          Ethernet network interface
    disk:
      /dev/sda             Crucial_CT120M50
    partition:
      /dev/sda1            Partition
      /dev/sda2            Partition
      /dev/sda3            Partition
    

    logs

    01/24/2018 07:39:03 PM
    Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
    sda               0.00     0.40    0.00  777.60     0.00  3742.40     9.63     3.77    4.85    0.00    4.85   0.04   3.04
    
    01/24/2018 07:39:08 PM
    Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
    sda               0.00     0.40    0.00  868.20     0.00  4256.80     9.81     4.18    4.82    0.00    4.82   0.04   3.44
    
    01/24/2018 07:39:13 PM
    Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
    sda               0.00     0.40    0.00  696.60     0.00  3480.00     9.99     3.49    5.00    0.00    5.00   0.04   2.88
    
    01/24/2018 07:39:18 PM
    Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
    sda               0.00     0.40    0.00  586.40     0.00  2907.20     9.92     3.03    5.17    0.00    5.17   0.04   2.48
    
    01/24/2018 07:39:23 PM
    Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
    sda               0.00     0.60    0.00  490.60     0.00  2472.00    10.08     2.54    5.18    0.00    5.18   0.04   2.08
    
  • Add a new message type

    Add a new message type "bulk_pull_blocks"

    This patchset adds a new message type "bulk_pull_blocks" (0x09) which allows one to request from a node a range of blocks (min_hash to max_hash). Alternatively, the checksum for a range of blocks can be requested to determine if it is likely that there are new blocks in that range that need to be pulled.

    Further, a limited number of blocks can be requested by specifying a non-zero "max_count" argument.

  • New Qml GUI implementation

    New Qml GUI implementation

    This is new Qml GUI implementation (see #384 ), rebased to include last changes from main repo.

    I'm opening a pull request to not let it diverge to much from main codebase, and because even if not 100% complete almost all functionality is implemented.

    Missing parts (advanced tools) are available by showing old GUI via a button inside settings panel.

  • Version 11+ makes Windows 10 unusable / memory leak

    Version 11+ makes Windows 10 unusable / memory leak

    Description of bug:

    Wallets starts briefly, then freezes, database size stays the same

    image

    Steps to reproduce the issue:

    1. Nano Milestone 11 on Windows on a fresh start (deleted database files)
    2. Main window hangs and werfault.exe process starts using 100% of CPU (on one core)

    Describe the results you received:

    Windows Error Reporting starts using 100% (on one core), and is unkillable. image image

    the only way to stop this is forcefully restarting the computer (taskkill can't kill it)

    image

    image

    Describe the results you expected:

    It works like previous versions

    Additional information you deem important (e.g. issue happens only occasionally):

    Happened every time, from the 3 times I tried

    Environment:

    • OS information: Windows 10 x64
    • Node version: Milestone 11

    logs

    [2018-03-23 17:37:44.065215]: Bootstrap stopped because there are no peers
    [2018-03-23 17:37:44.065215]: Bootstrap stopped because there are no peers
    [2018-03-23 17:37:44.065215]: Bootstrap stopped because there are no peers
    [2018-03-23 17:37:44.065215]: Bootstrap stopped because there are no peers
    [2018-03-23 17:37:44.065215]: Exiting bootstrap attempt
    [2018-03-23 17:37:44.510075]: Beginning pending block search
    [2018-03-23 17:37:44.510075]: Pending block search phase complete
    [2018-03-23 17:37:45.515069]: UDP Receive error: No connection could be made because the target machine actively refused it
    [2018-03-23 17:37:47.737077]: Beginning pending block search
    [2018-03-23 17:37:47.737077]: Pending block search phase complete
    [2018-03-23 17:37:49.068256]: Starting bootstrap attempt
    [2018-03-23 17:37:49.238260]: Connection established to [::ffff:192.99.176.122]:7075
    [2018-03-23 17:37:49.246260]: Connection established to [::ffff:192.99.176.121]:7075
    [2018-03-23 17:37:49.246260]: Connection established to [::ffff:165.227.201.217]:7075
    [2018-03-23 17:37:49.248260]: Connection established to [::ffff:144.217.167.119]:7075
    [2018-03-23 17:37:49.274260]: Connection established to [::ffff:159.89.143.80]:7075
    [2018-03-23 17:37:49.276261]: Connection established to [::ffff:138.68.2.234]:7075
    [2018-03-23 17:37:49.304261]: Connection established to [::ffff:139.162.199.142]:7075
    [2018-03-23 17:37:49.322262]: Connection established to [::ffff:138.201.94.249]:7075
    [2018-03-23 17:37:49.402263]: Invalid size: expected 64, got 0
    [2018-03-23 17:37:49.404263]: frontier_req failed, reattempting
    [2018-03-23 17:37:59.094699]: Error initiating bootstrap connection to [::ffff:89.64.59.63]:10025: The I/O operation has been aborted because of either a thread exit or an application request
    [2018-03-23 17:37:59.094699]: Error initiating bootstrap connection to [::ffff:192.81.216.141]:7075: The I/O operation has been aborted because of either a thread exit or an application request
    [2018-03-23 17:37:59.094699]: Error initiating bootstrap connection to [::ffff:54.246.128.136]:7075: The I/O operation has been aborted because of either a thread exit or an application request
    [2018-03-23 17:37:59.350706]: Connection established to [::ffff:45.76.92.115]:7075
    [2018-03-23 17:37:59.352705]: Connection established to [::ffff:212.47.237.7]:7075
    [2018-03-23 17:37:59.356701]: Connection established to [::ffff:188.226.155.250]:7075
    [2018-03-23 17:37:59.484704]: Connection established to [::ffff:172.104.32.150]:7075
    [2018-03-23 17:38:01.985391]: Found a representative at [2001:41d0:8:d85f::1]:7075
    [2018-03-23 17:38:02.857584]: Found a representative at [2600:3c03::f03c:91ff:fee5:29e]:7075
    [2018-03-23 17:38:04.403929]: Received 303959 frontiers from [::ffff:192.99.176.121]:7075
    [2018-03-23 17:38:09.642300]: Found a representative at [::ffff:139.59.31.249]:7075
    [2018-03-23 17:38:10.134317]: Found a representative at [::ffff:35.200.122.8]:7075
    [2018-03-23 17:38:10.548320]: Completed frontier request, 468710 out of sync accounts according to [::ffff:192.99.176.121]:7075
    [2018-03-23 17:38:10.931790]: Found a representative at [::ffff:178.22.66.84]:7075
    [2018-03-23 17:38:10.932791]: Found a representative at [::ffff:178.22.66.84]:7075
    [2018-03-23 17:38:11.020796]: Requesting account xrb_33de47sgua1pup78kw4ye8nz7ujdz47oucfgco1zb95n8n7hkbq1x81z3md6 from [::ffff:165.227.201.217]:7075. 468709 accounts in queue
    [2018-03-23 17:38:11.020796]: Error receiving block type End of file
    [2018-03-23 17:38:11.021797]: Error receiving block type End of file
    
  • QTimers dependency requires newer Qt?

    QTimers dependency requires newer Qt?

    Since https://github.com/clemahieu/raiblocks/pull/508 we started failing builds on Trusty.

    We now have compilation errors like the one below.

    @CathalT thanks so much for your contribution. Would you be willing to rework the change with a CMake feature test or some other way to make sure it still builds on older distros?

    
    /usr/include/qt5/QtCore/qtimer.h:82:17: note:   candidate expects 4 arguments, 2 provided
    ../rai/qt/qt.cpp: In lambda function:
    ../rai/qt/qt.cpp:1415:6: error: no matching function for call to 'QTimer::singleShot(std::chrono::duration<long int, std::ratio<1l, 1000l> >::rep, rai_qt::settings::settings(rai_qt::wallet&)::__lambda73::__lambda74)'
         });
          ^
    ../rai/qt/qt.cpp:1415:6: note: candidates are:
    In file included from /usr/include/qt5/QtCore/QtCore:77:0,
                     from /usr/include/qt5/QtGui/QtGuiDepends:2,
                     from /usr/include/qt5/QtGui/QtGui:3,
                     from ../rai/qt/qt.hpp:9,
                     from ../rai/qt/qt.cpp:1:
    /usr/include/qt5/QtCore/qtimer.h:81:17: note: static void QTimer::singleShot(int, const QObject*, const char*)
         static void singleShot(int msec, const QObject *receiver, const char *member);
                     ^
    /usr/include/qt5/QtCore/qtimer.h:81:17: note:   candidate expects 3 arguments, 2 provided
    /usr/include/qt5/QtCore/qtimer.h:82:17: note: static void QTimer::singleShot(int, Qt::TimerType, const QObject*, const char*)
         static void singleShot(int msec, Qt::TimerType timerType, const QObject *receiver, const char *member);
                     ^
    /usr/include/qt5/QtCore/qtimer.h:82:17: note:   candidate expects 4 arguments, 2 provided
    ninja: build stopped: subcommand failed.
    
  • Remove PoW requirement on RECEIVE tx

    Remove PoW requirement on RECEIVE tx

    Discussed in Issue 360

    Requiring PoW on RECEIVE txs puts a large burden on services that accept XRB deposits, and if a user were spammed with penny-sends then it is difficult for them to clean it up.

    Having a min PoW on RECEIVE txs makes it pretty efficient to identify and discard spam quickly, however it does not prevent spammers from broadcasting underworked RECEIVE txs. Because RECEIVE txs must match 1:1 with SEND txs there is no risk of ledger spam on the RECEIVE side. Only SEND can be the source of ledger spam. PoW does not prevent network spam.

    Instead of using PoW as one of the first criteria to validate RECEIVE txs, a bloom filter can be used first to confirm that the SEND being claimed is still pending. The bloom filter will have to match for all pending SEND's. If the bloom filter check returns "this RECEIVE's SEND is definitely not still pending" then this spam RECEIVE is discarded. If the filter says it may still be pending then this spam check is passed.

    There may be slightly better ways to implement this, or maybe it already is implemented, but the gist of it is that PoW on RECEIVE txs is hurting a whole lot more than it is helping so it should be disabled.

  • Unable to receive pending funds

    Unable to receive pending funds

    Hello,

    Installed RAI Desktop Wallet, created password and backed up seed. Got account address and sent some XRB to it. It was very far out of sync and even after days of running non-stop it did not catch up even though it's installed on SSD and fast network. I downloaded latest ldb and replaced. I then imported my wallet using seed. After import my previous account address is no longer shown in the wallet. The accounts page does however show my pending deposit in the Wallet Pending section. The use of the more recent ldb allowed my local wallet to finish syncing with the blocks, still no change in accepting my funds and again I still cannot see the original account address in the GUI wallet.

    As a troubleshooting step I started using RPC commands. Account list shows the original account address, it shows the pending funds but attempting to run a receive command on the transcation returns this: { "block": "0000000000000000000000000000000000000000000000000000000000000000" }

    Any ideas?

  • Remove sudo from buildci.sh and re-test release process

    Remove sudo from buildci.sh and re-test release process

    The script ci/build-ci uses sudo to gain root access. We should not need to do that just to build our software.

    TODO: remove the sudo and test that the release process is not broken

    REF: https://github.com/nanocurrency/nano-node/blob/754ee4abf6fb619257774c757a45205e9ef45391/ci/build-ci.sh#L67

  • Continuous backlog population

    Continuous backlog population

    Backlog population is a process in which a node scans all accounts in the ledger, with or without any confirmed blocks, and forwards (activates) those accounts which do not have all their blocks confirmed to election scheduler for prioritization and eventual queuing in proper bucket. It is necessary to do this periodically, because the amount of space in each bucket is limited (currently ~2000 entries) and number of accounts needing confirmations can be much higher than that, especially during bootstrap or network spam attack.

    The problem with current implementation is that this process runs every 5 minutes and scans the whole ledger at once, leading to situations where we run out of accounts to prioritize before the next run has started. This is especially visible during bootstrapping, a graph showing such situation is included below. We can clearly see the bumps in AEC occupancy where prioritization queue is filled, followed by periods of idleness when priority queue is emptied:

    Screen Shot 2022-11-15 at 21 15 39

    This PR fixes that by modifying the way the ledger scan is done. Instead of 5 minute interval, we run the scan all the time (unless disabled by setting frontiers_confirmation = disabled node config setting), but we throttle the rate at which the scan is done to limit consumption of node resources. The rate and frequency is controlled by two new node-config.toml settings: backlog_scan_rate and backlog_scan_frequency. By default it scans 10000 accounts per second divided into 10 batches, so 1000 accounts per batch. This is rather conservative and should be later adjusted with feedback from beta node operators (before this PR we dit it in batches of 64k).

    The result of this PR is the AEC that stays full almost all the time (except the initial phase of the bootstrap):

    Screen Shot 2022-11-15 at 21 15 53
NanoSwift: A Swift Library for the Nano cryptocurrency

Nano is an instant, feeless and eco-friendly cryptocurrency that is also super easy to use. This library lets you create wallets, accounts and blocks as well as manage Nano amounts, interact with a node and more.

Mar 1, 2022
Bitweb is an experimental digital currency that enables instant payments to anyone, anywhere in the world.

Bitweb is an experimental digital currency that enables instant payments to anyone, anywhere in the world.

Nov 13, 2022
Elecrypt core protocol details
Elecrypt core protocol details

This codes are compatible with esp8266 nodemcu 1.0 on Arduino board.media/esp8266nodemcu.png

Nov 6, 2022
wtf is a distributed, code-coverage guided, customizable, cross-platform snapshot-based fuzzer designed for attacking user and / or kernel-mode targets running on Microsoft Windows.
wtf is a distributed, code-coverage guided, customizable, cross-platform snapshot-based fuzzer designed for attacking user and / or kernel-mode targets running on Microsoft Windows.

wtf is a distributed, code-coverage guided, customizable, cross-platform snapshot-based fuzzer designed for attacking user and / or kernel-mode targets running on Microsoft Windows.

Nov 17, 2022
FCracker is a command line tool designed to brute force encrypted files like zip, 7z, rar, pdf etc.

FCrack is a command-line tool designed to brute force encrypted files like zip, 7z, rar, pdf, gpg etc.

Oct 3, 2022
BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.

Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.

Nov 20, 2022
A lightweight and simpling iOS binary decryptor

FlexDecrypt's source code is pretty FAT, bundling the whole swift runtime to just achieve a simple mremap_encrypted.

Nov 16, 2022
A lightweight, secure, easy-to-use crypto library suitable for constrained environments.
A lightweight, secure, easy-to-use crypto library suitable for constrained environments.

The Hydrogen library is a small, easy-to-use, hard-to-misuse cryptographic library. Features: Consistent high-level API, inspired by libsodium. Instea

Nov 22, 2022
Finalists to the NIST lightweight cryptography competition

LWC Finalists This repository contains implementations of the 10 finalists in the NIST lightweight cryptography competition: ASCON, Elephant, GIFT-COF

Sep 4, 2022
x509cert is a tool and library for generating X.509 certificates and certificate requests.

x509cert is a tool and library for generating X.509 certificates and certificate requests. It is written in C99 and uses BearSSL to decode keys and compute signatures.

Sep 5, 2022
HashLibPlus is a recommended C++11 hashing library that provides a fluent interface for computing hashes and checksums of strings, files, streams, bytearrays and untyped data to mention but a few.

HashLibPlus HashLibPlus is a recommended C++11 hashing library that provides a fluent interface for computing hashes and checksums of strings, files,

Apr 11, 2022
Text-Crypt is a tool which encrypts and decrypts texts using a specific and certain key.
Text-Crypt is a tool which encrypts and decrypts texts using a specific and certain key.

Text-Crypt is a tool which encrypts and decrypts texts using a specific and certain key. This tool uses Caesar Cypher Algorithm to encrypt and decrypt a given text.

Dec 24, 2021
An open source, portable, easy to use, readable and flexible SSL library

README for Mbed TLS Mbed TLS is a C library that implements cryptographic primitives, X.509 certificate manipulation and the SSL/TLS and DTLS protocol

Nov 25, 2022
TLS/SSL and crypto library

Welcome to the OpenSSL Project OpenSSL is a robust, commercial-grade, full-featured Open Source Toolkit for the Transport Layer Security (TLS) protoco

Nov 25, 2022
Library and command line tool to detect SHA-1 collision in a file

sha1collisiondetection Library and command line tool to detect SHA-1 collisions in files Copyright 2017 Marc Stevens [email protected] Distributed

Nov 19, 2022
Tink is a multi-language, cross-platform, open source library that provides cryptographic APIs that are secure, easy to use correctly, and hard(er) to misuse.

Tink A multi-language, cross-platform library that provides cryptographic APIs that are secure, easy to use correctly, and hard(er) to misuse. Ubuntu

Nov 18, 2022
Easy to use cryptographic framework for data protection: secure messaging with forward secrecy and secure data storage. Has unified APIs across 14 platforms.
Easy to use cryptographic framework for data protection: secure messaging with forward secrecy and secure data storage. Has unified APIs across 14 platforms.

Themis provides strong, usable cryptography for busy people General purpose cryptographic library for storage and messaging for iOS (Swift, Obj-C), An

Nov 21, 2022