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