Karbo CLI Suite v.1.7.6

In this release was added SSL support for RPC with new startup flags for the daemon karbowanecd:

• --rpc-bind-ssl-enable to enable SSL for RPC service
• --rpc-bind-ssl-port SSL port for RPC service (default port is 32448)
• --rpc-chain-file (default name "rpc_server.crt", this is the "fullchain.pem" file is you use letsencrypt)
• --rpc-key-file (default name "rpc_server.key", this is the "privkey.pem")
• --rpc-dh-file (default name "rpc_server.pem")

The simplewallet also got new flags

• for its wallet RPC server:
  • --rpc-bind-ssl-enable enable SSL for RPC service
  • --rpc-bind-ssl-port (default 15100)
  • --rpc-chain-file (=rpc_server.crt) SSL chain file
  • --rpc-key-file (=rpc_server.key) SSL key file
  • --rpc-dh-file (=rpc_server.pem) SSL DH file
• for client:
  • --daemon-cert custom certificate file for performing SSL verification
  • --daemon-no-verify disable SSL verification procedure

The walletd also got these flags:

--rpc-ssl-enable
--bind-port-ssl arg (=16100)
--rpc-ssl-enable 
--rpc-chain-file arg (=rpc_server.crt)
--rpc-key-file arg (=rpc_server.key)
--rpc-dh-file arg (=rpc_server.pem)

for wallet server

--daemon-port-ssl arg (=32448)
--daemon-ssl-enable
--daemon-chain-file arg (=rpc_server.crt)
--daemon-key-file arg (=rpc_server.key)
--daemon-dh-file arg (=rpc_server.pem)

for its builtin node.

How to create DH file:

openssl dhparam -out /etc/letsencrypt/live/yourdomain.com/rpc_server.pem 2048

Added new JSON RPC method resolveopenalias which may be used e.g. in wallets.
Example request:

{
  "jsonrpc": "2.0",
  "id": "test",
  "method": "resolveopenalias",
  "params": {
   "url":"aiwe.karbo.me"
  }
}

Response:

{
  "id": "test",
  "jsonrpc": "2.0",
  "result": {
    "address": "KetKFqZu4jH9Gnbbvp5ckbXBzadeDK6EFPNFuPcZcCjMDK31r84weVzcF2BhewZEQGZUjDTB7QgHVbJoYTE89eh2ETuDdLH",
    "status": "OK"
  }
}

We dropped Ubuntu 16.04 because of troubles with automated compiling with OpenSSL support due to some incompatibilities with Boost. You can compile after manually installing the correct (newest) version of Boost.

Download:

Karbo-cli-win64-v.1.7.6.zip
4BA58304BFE9AF09475FB43249D70F9CA438A09F31A74BCA9331E585002B2E52

Karbo-cli-ubuntu18.04-v.1.7.6.tar.gz
A4FF76B2007EF996DE2E917168222F5F60B1E9A32354766C975D16A803E65210

Karbo-cli-ubuntu20.04-v.1.7.6.tar.gz
C62AC8940FE1CB10BA20B2AEA31F4556970E95F5DE4898FA67E223A1CEAADA63

Karbo-cli-macOS-v.1.7.6.zip
6F6EB728377796AA8671BA998C6F833AF0B6988A1730ECF35C37AA790699513C

Karbo CLI Suite v.1.7.5

This release contains improvements in JSON RPC methods and therefore is especially recommended to public nodes whose API is exposed to the world. Namely:

• fixed JSON serialization of float numbers
• an error is returned if some of the reserve proof's transactions couldn't be found
• limit the number of requested blocks in some methods
• improve error handling in some methods

Karbo-cli-win64-v.1.7.5.zip
919F699F2B87C70B64370FBA8C7EB8D60E49A78E12F10E306105C960099B6B05

Karbo-cli-ubuntu16.04-v.1.7.5.tar.gz
0D59F8FA2A1B343175C74938D34EB2673777CB5187B8C255938990C70EF266FD

Karbo-cli-ubuntu18.04-v.1.7.5.tar.gz
8B4508ECF5CDBFB374ABC2A9864CAFAB58AC99B06443BD57BD24004293553C78

Karbo-cli-macOS-v.1.7.5.zip
D001F5F87BD5D0BE30A09B8DC4306B1ED9FC5D4414EC233B4B9E35DD937837AD

Karbo CLI Suite v.1.7.4

This release contains:

• the update of Base58 encoding of signatures of messages
• the implementation of sign/verify messages in greenwallet and walletd
• the alt. blocks RPC method getaltblockslist, which, obviously, returns a list of alt. blocks short info (only those stored by given node)
• checkpoints source files were moved to a separate folder

We also remind you to update your software due to a softfork at height 500000 because of transaction fees per byte for extra data and forbidding the unmixable outputs in a transaction.

Karbo-cli-win64-v.1.7.4.zip
4100B9025E52137352227ADEDFF738A550D3CD3B87426212D8C61720C4C166C2

Karbo-cli-ubuntu18.04-v.1.7.4.tar.gz
2C8A1BD502965A0FDF14D2CD681949E273F7973898EDBF00F676227435B85809

Karbo-cli-ubuntu16.04-v.1.7.4.tar.gz
BBDE4726890437760ADB73C72E09256A7E1E8B7688AA93EB788AED1C094734FA

Karbo-cli-macOS-v.1.7.4.zip
99D705925961B561652BB8BA81565E6B957B4080645472A0683AB7A45DFE671F

Karbo CLI Suite v.1.7.3

This release sets a softfork at height 500000 because of transaction fees per byte for extra data and forbidding unmixable outputs in transaction. Mining pool operators are asked to update their nodes.

• Change storage for various blockchain indexes
  This reduces memory usage by ~ 500Mb, from ~1.5Gb to ~ 1Gb and greatly speedup start/exit by dump key images map and transactions map to disk and restore as a single array, very efficiently, and without requiring any hash computation.

• Transaction fees per byte for extra data
  A CryptoNote transaction has an extra field that can store additional information that is stored forever in the blockchain along with the transaction. There is no any limit of the size of this additional transaction extra, therefore it can potentially be quite large. We believe that permanent blockchain storage of the extra data, unrelated to the main purpose of transactions per se, namely, storing information about the transfer of money, has to be paid for. The problem is that the size of the transaction has no influence on the fee of the transaction. The fee based on transaction size solves this problem but creates another one: if a user sends a transaction with many outputs it will render a larger fee amount because of the larger size of the transaction. This is unfair and hard to understand by non-tech-savvy users: why a user has to pay more fees merely because, e.g. he received his money in many smaller transactions or, for example, he wants to send funds in one transaction to many recipients? Therefore, instead of the whole transaction, calculate the additional fee only for the size of the extra field of the transaction. Let's call this fee as 'fee per byte'. This way, the normal transactions will all have the same obligatory limit of the 'minimal fee' but for the additional data, the sender will have to pay an extra fee based on the size of the extra data.

  The extra field of any normal transaction always contains or may contain some data, like e.g. payment id. The size of the extra field of the typical transaction fits in 100 bytes, therefore this size of the extra field of the transaction is proposed to be free of charge.

  The extra field is the vector of uint8_t, and the uint8_t is exactly the one byte, therefore we can easily get the size of the extra field, being the size of the vector, and calculate the 'fee per byte', excluding first 100 bytes.

  The cost of one byte of the extra is set as 1/100 of the 'minimal transaction fee'.

  The 'fee per byte' is added to the 'minimal transaction fee'. The total transaction fee is calculated as

  F = Fb + Fm

  where Fb is 'fee per byte' and Fm is 'minimal transaction fee'.

  Standard transactions from normal wallets are not affected!

• Exposed these RESTful-like API endpoints for GET requests

  • /api/block/height/[height] - returns block info in JSON by height
  • /api/block/hash/[hash] - returns block info in JSON by hash
  • /api/transaction/[hash] - returns transaction info in JSON by hash
  • /api/payment_id/[hash] - returns the list of transaction hashes by payment id in JSON

  which is convenient to get block or transaction info in browser without the need of making a POST request.
  E.g. complete URL looks like http://127.0.0.1:32348/api/block/height/12345

• Changes in node server

  • Added nice HTML output to / path with basic stats
  • Added plain HTML /supply endpoint that returns a string with total coins in circulation
  • Moved /paimentid endpoint to the plain HTML output of randomly generated payment id instead of JSON

Download

Karbo-cli-win64-v.1.7.3.zip
CBB693DA84B104EDDCDD6CC8B67A8186322C232D1D2C4979635242528B67155E

Karbo-cli-ubuntu18.04-v.1.7.3.tar.gz
6B01C97A1D066069DD6895E9268FD71FF408B8574DEC1443FAD70FFE31939644

Karbo-cli-ubuntu16.04-v.1.7.3.tar.gz
EDA2C787929A5C203506B9E92E72FB06FA90235F061F544933A5E026651FA616

Karbo-cli-macOS-v.1.7.3.zip
3B23E3E6BCC7B2ECBFE46BCBD4D497B2A721E07FD8E680F68AF4D53899C0360A

Karbo CLI Suite v.1.7.2

• Change spent key images storage (reduce memory usage)
• Deterministic transaction keys
• Fixed missing address file name when import tracking wallet
• Fixed validation on atypical to domains
• Flat-rate fee for public nodes
• Poor man's Dandelion protocol
• Proper Base58 encoding of proofs
• Small optimization in pushBlock: do not recalculate block hash
• Tidyup crypto: make crypto primitives more clear, move scattered and repeated definitions to one place, add some new crypto functions, fix compiler warning
• --enable-blockchain-indexes now has a short alias -i

Deterministic transaction keys

The secret transaction key allows, for example, proving that a transaction was sent to a specified address and how much money this address received in a given transaction when used directly (undesired) or when used to generate a "proof of payment" (preferable). Since it is randomly generated, it needs to be stored in a wallet cache and/or recorded somewhere externally by the sender. In the case of wallet reset these keys are lost along with other transaction data, such as destination addresses. Likewise, upon restoring and importing the wallet from keys or mnemonic seed this secret transaction key is not recovered.

Replacing the randomly generated secret transaction key with deterministic using transaction inputs and sender's secret view key gives the next benefits:

• recovering the secret transaction key in case of wallet reset
• recovering the secret transaction key when restoring from mnemonic phrase or raw keys
• recovering the secret transaction key even in tracking wallet thanks to using secret view key instead of secret spend key
• can be used to alert about spending in tracking wallet (possible further improvement of tracking wallets to enable tracking of outgoing transactions and displaying correct balance)

Flat-rate fee for public nodes

Karbo first of CryptoNote coins introduced a fee for public nodes paid by wallets in form of a percent of the amount sent in a transaction. This has a few disadvantages:

1. leaking the actual amount being sent
2. tiny dust received by node's wallet only clutters the wallet requiring later optimization
3. fee in the form of a percent often creates many outputs increasing the size of a transaction adding to blockchain bloating
4. larger fees when sending large amounts may be perceived as unfair

The flat-rate fee

1. removes these weaknesses
2. creates the fee market for nodes to compete for users
3. creates a more attractive stable revenue flow for nodes
4. node operators will likely set a fee as a rounded number with fewer decimals resulting in fewer outputs in transactions and their smaller size

This adds an additional flag for a daemon --fee-amount so node operator can set the desired fee like this: --fee-amount=0.1.
To the /feeaddress endpoint output is added a field fee_amount in atomic units.
The /feeaddress output now looks like this:

{
"fee_address":"KaqCQAbx3BSKKv7ED98oQP9QSP3igqgo47hPYZ8q6KZyUY6GnDaQkh9WbVR4DxvmCq8mZcKPg3wfWFJQ5CsyrxPqKcXC3rx",
   "fee_amount":100333000000,
   "status":"OK"
}

The /feeaddress endpoint remains unchanged for backward compatibility. Wallets will pay the old percent-based fee for old nodes without flat-rate fee_amount in the /feeaddress endpoint for a transition period. This feature may be deprecated and removed in the future.

From the /getinfo endpoint fee_address field is removed not to duplicate.

Poor man's Dandelion protocol

Makes it more difficult to determine the IP address from which the transaction was originated. Normally new transaction is broadcasted to all node's peers. The origin of a transaction message and its IP address (which is not included in a transaction message) can be mapped by third-party observers if they control enough nodes or use a supernode that is connected to a significant number of nodes. They can effectively map the originating address by observing which nodes see the transaction first. To hamper this these changes were introduced:

• New transactions are now broadcasted to the two randomly preselected stem peers.
• Stem peers are randomly selected periodically from the list of active peers (among outgoing connections).
• A new field, named stem is added to a transaction message, to which is assigned a boolean value denoting whether it is a stem transaction or a fluff transaction (normal). New transaction always have a true value of stem field, i.e. they are sent as a stem transactions.
• When node receives a stem transaction it forwards it to two its stem peers.
• Each node upon relaying a transaction randomly switches to a fluff phase and broadcast transaction(s) to all its peers.
• When node receives a fluff transaction it forwards it to all its peers.
• Stem transactions are stored in a stempool.
• If incoming transaction notification arrives in a fluff mode all transactions that match are deleted from the stempool.
• Periodically transactions from the stempool that didn't made it to return in a fluff mode by that time are broadcast as a fluff and deleted from the stempool.
• If node fails to send transaction to stem peer it broadcasts transaction in a fluff mode.

Proper Base58 encoding of proofs

Change the way the "proof of payment" and the "reserve (balance) proof" are encoded: instead of adding ProofV1 to the beginning of the string of the Base58 encoded proof, use proper Base58 encoding with varint prefix tag and a checksum which allows checking decoded data, just as CryptoNote address is encoded. The same applies to the "reserve proof": instead of prepending ReserveProofV1 to Base58 encoded string of the reserve proof use proper encoding. For this puprose two prefix tags are introduced:

• const uint64_t CRYPTONOTE_TX_PROOF_BASE58_PREFIX = 3576968; // (0x369488), starts with "Proof..."

• const uint64_t CRYPTONOTE_RESERVE_PROOF_BASE58_PREFIX = 44907175188; // (0xa74ad1d14), starts with "RsrvPrf..."

Therefore now the "payment proof" starts from Proof, the "reserve proof" starts from RsrvPrf.

Download

Karbo-cli-ubuntu18.04-v.1.7.2.tar.gz
51594E7C443CAB3C6F7811F2659A65A417A423A3E87628099742C1B166432F62

Karbo-cli-win64-v.1.7.2.zip
9751056D4FEC00BE512B7EC16ADE805A263E822AE7F4D239BE17EEDE092F4BDF

Karbo-cli-ubuntu16.04-v.1.7.2.tar.gz
F30A5DB221741B85628DD05B72BBACF593B0B2034B509A5B5B1716B02CEB783E

Karbo-cli-macOS-v.1.7.2.zip
962A09C9E4FB3847F5BD783F9FA68624934D1605A1DE6C1D4A7403FCC8BDEA97

Enlight

• Lite blocks propagation, this should reduce traffic between nodes
• Attempt to restore corrupted blockindexes.dat
• Platform independent randomness
• Improvements in simplewallet
• Node update with new endpoints, including info about connections for display in GUI Wallet
• Fix of fee check in Core, fixes syncing from zero with the flag --without-checkpoints
• Ban nodes that stuck too deep behind on fork to spare useless traffic
• Changes in P2P:
  • Moved P2P protocol version to common config
  • Added warning about outdated software
  • Added dropping the connection to outdated too much nodes
  • Added anchor connections, based on https://eprint.iacr.org/2015/263.pdf §4
• Change how we deal with unmixable outputs in wallet:
  • if transaction is zero mixin, first take all unmixable outputs to send, then normal outputs
  • for transactions with mixin first, take normal outputs, only if not enough take dust, unmixable outputs, obviously, not used for sending
  • sweep_dust command is removed from simplewallet
  • the warning is displayed when the user has unmixable outputs that he can get rid of them by sending tx with zero mixin
  • in the edge case of so many unmixable outputs that it will make tx invalid due to exceeding tx size limit user will have to send them in chunks (at cost of an extra fee, but old behaviour is the same)
• Add tools to get some useful statistics via RPC e.g. for building historical charts

The above changes are partially based on TurtleCoin and Monero solutions.

Speedup

• Boost synchronization speed. (It nows syncs in 15-20 minutes to the latest checkpoint. If you want to sync even faster, take the most recent block's height and hash and feed it to daemon as a checkpoint with --load-checkpoints flag)
• Code cleanup: removed various unused files and functions, fixed some bugs
• Changes in RPC: removed some deprecated methods, renamed some fields (many that should've been changed too were left intact for backward compatibility with wallets), allowed some methods while node is syncing
• Check locked amounts in reserve proof RPC method
• Start scan height option for restoring wallets
• Functions used in GUI to lock wallet and to confirm sensitive operations by password
• Daemon save command to store blockchain cache to disk
• RPC method for walletd to show addresses count

Optimize

• Optimizer tool for walletd
• Optimize transaction fee check
• Optimize crypto, RPC, CMake scripts, fix various minor bugs and compiler warnings
• Spend Key Images now stored with blockchain height allowing to check proof of balance against given height

Graceful fee

• Fixed fee validation bug
• Fixed various compiler warnings, typos and minor errors

Also staged not activated changes for the next hardfork:

• Increase mined money unlock window to 1 day
• Proper tail emission - 2% inflation of coins in circulation
• Ban merged mining tag in Karbo's coinbase transaction

GreenWallet

• New GreenWallet for CLI Suite backed by WalletGreen (port of zedwallet from TurtleCoin)
• Patch for timestamp locked invalid inputs in transactions
• Patch for an arbitrary number of (dummy) signatures in the transaction (potential blockchain bloat)
• Option of deterministic keys and mnemonic phrase for walletd
• Export wallet and Create addresses from a list in walletd
• RPC methods to get transaction secret key, transaction proof and balance proof in walletd
• Reworked Blockchain Explorer Data
• Update of NodeRpcProxy and InProcessNode
• Various fixes and code cleanup (to be continued)