Pages:
Author

Topic: [ANN] [KRB] Karbo (Ҝ) Кapбoвaнeць - Anon / stable transaction costs - page 6. (Read 493160 times)

legendary
Activity: 1750
Merit: 1101
karbo.io
Software updates arrived:

New Karbo CLI Suite v. 1.6.5
New Karbo Classic Wallet v. 1.3.5
New Karbo-GUI v. 2.1.0
New Karbo Lite Wallet v. 1.0.8


All pools and nodes should update to make sure your daemon is not stuck syncing. The same goes for wallets.

Please update!
legendary
Activity: 1750
Merit: 1101
karbo.io
3 years ago was mined the first block of Karbo blockchain. See the first pages of this thread.

In these 3 years, many things happened, we made lots of achievements and progress, we always try to sum up. Let's mention some of our achievements we're proud of and which were also recognized by high awards. In this third year, we finally got the web wallet I always wanted - fully client-side - https://wallet.karbo.org/ and this is our official wallet, ported from Masari. We also implemented a unique and battle-tested defence against 51% attacks, introduced protection against merge mining (as slave coin, total ban pending), introduced Proof of Payment (by secret transaction key or special signature not revealing transaction secret key), introduced Proof of funds, made lots of improvements of our software.

We are working on delivering a new software version with faster synchronization and better scalability, we are researching and working on the implementation of own I/O bond POW and on novel PoW with Stake algorithms which will make Karbo even more secure and stable. And of course, we maintain devotion to our course of becoming low volatile sound money, suitable for trade and store of value, continuing implementation and improvement of adaptive parameters protocol (adaptive emission, fee and so on), outlined in our whitepaper, which we enhanced and supplemented by new articles, published in this year, which you can find in posts above. Slowly but steady we're moving forward.

I am grateful to our developers and Karbo community for support and engagement. I am sure that with your help and participation we will rich our goals. Because Karbo is sound.

newbie
Activity: 63
Merit: 0
Not sure if you are aware but nova exchange are offering free listing for former Cryptopia listed coins
legendary
Activity: 1750
Merit: 1101
karbo.io
New Karbo improvement proposal published https://github.com/Karbovanets/papers/blob/master/KIP-001.md

Reviews and opinions are welcomed. Public testnet will be launched these days, stay tuned.




KIP-001: ArgoNight — Non-Outsourceable Blockchain Based Proof-of-Work Hash

v. 1.1

nuclEar_chaos, Aiwe, Luke

Herein the new POW algorithm proposal for Karbo is explained.

The reason

One of the cornerstones of CryptoNote protocol, and Karbo as well, was "egalitarian proof of work" that was broken by the invention of ASICs for CryptoNight POW algorithm, which is default for the CryptoNote. The Karbo cryptocurrency sill uses CryptoNight in spite ASICs were developed for it and the majority of CryptoNote based coins that were using it migrated to its variants with modifications of different magnitudes under the leadership of Monero (and mostly Monero CryptoNight variants were used).

The reason for this was to retain as much decentralization of mining as possible, because it is commonly believed that accumulating of the majority of the hashrate under the control of few ASIC manufacturers is not safe for coins.

Another reason for the change of the algorithm to the unique one for smaller coins was to escape the possibility of renting the hashrate on rental services of which the most known is Nicehash.

Sharing the algorithm with large coin is dangerous for the smaller one as there is high risk of 51%-attacks using rented hashrate or the risk of incursions of profit switching miners which causes difficulty and block times fluctuations.

At Karbo we came to the conclusion that small tweaks of the hashing algorithm are not sufficient, which was confirmed by the series of hardforks of Monero to escape ASICs and newly developed FPGAs for their variant. We think that as soon as it becomes economically profitable, ASICs are developed for any algorithm. There are but few algorithms that are considered ASIC-resistant.

Therefore we were lingering with such change, and have not switched to any CryptoNight variant developed by Monero or other CryptoNote coins until we develop more sophisticated algorithm of our own that will be not only ASIC resistant but also preferably will favor solo only mining, which is truly decentralized, without pools and will be also botnet-resistant.

Basic overview

In order to achieve our goals we decided to use blockchain data in hashing to create non-outsourceable algorithm which will be able to prevent pooled mining and botnets.

Now hashing is a closed algorithm, that is, we have nonce which is changed and an incoming static data. The idea is to include in the calculation of the final hash a factor which destroys such a closed system.

Specific implementation is to include in algorithm the data from a blocks, the heights of which are defined as an intermediate result of a preparatory hash. That is, for the next hash with another nonce these intermediate blocks will be completely different. Thus, without an access to the blockchain hashing is not possible.

Detailed overview

The hashing in proposed algorithm works as follows:

1)    A block is hashed by fast Keccak hashing function to get the preliminary hash_1.
2)    The resulting hash_1 is used to retrieve 32 blocks at corresponding heights from the blockchain.
3)    A block is then hashed together with 32 retrieved blocks by the Argon2 hashing algorithm using hash_1 as salt.

The block here stands for block hashing blob binary array which consists of block header, which in turn contains, among others, so called nonce.

The mining process in Proof-of-Work uses nonce (a 32 bit arbitrary random number) that is used together with the block data as input for hashing function. Essentially miner is brute forcing all possible nonces in order to find a hash than satisfies the target difficulty.

Because changing the nonce also changes the preparatory hash_1, a different set of 32 blocks is required for every nonce to be retrieved from the blockchain. Thanks to this:

  •     the performance is limited to the speed of I/O operations
  •     every miner needs access to the blockchain (i.e. only full nodes will be mining)
  •     sending from the pool server or requesting block data from open nodes is impractical overhead due to network latency and transfer speed/bandwidth limitations.

As a result, we believe that pooled/hosted mining is problematic with this method and that it provides the botnet resistance.

Notes

We do not specially target CPU-only mining and do intend to prevent GPUs entirely, although with Argon2 we achieve some limiting of GPU's prevalence over CPU.

We assume that I/O limitations will constrain the speed of ASIC and FPGA miners, should such be developed.

There is no SPV nodes for CryptoNote protocol so the full blockchain access requirement for the block verification is not considered as downside.

These benefits come at cost of synchronization speed - the node has to be synchronized block by block in ascending order as previous blocks are required to verify each new block but this is current mode of Karbo synchronization.

There is a concern of 'lightweight' miner possibility that is parsing and storing only block headers required for mining in needed format. However, the advantage of such miner is questionable.
legendary
Activity: 1750
Merit: 1101
karbo.io
An update for Karbo classic wallet  v. 1.3.4 released.

Download: https://github.com/seredat/karbowanecwallet/releases/tag/v.1.3.4

This is an update to keep up to date with the latest core changes.
legendary
Activity: 1750
Merit: 1101
karbo.io
New Karbo CLI v. 1.6.4 released.

This is NOT a mandatory update but recommended.

Download from our Github repository: https://github.com/seredat/karbowanec/releases/tag/v.1.6.4

What's new:

*    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)

legendary
Activity: 1750
Merit: 1101
karbo.io
legendary
Activity: 1750
Merit: 1101
karbo.io
Yes, devs are here and working. For example, just got a sneak peek of new features for the android wallet:




Btw, we updated our explorer, it now shows more transaction details, in particular, money flow in output indexes. Now you can better visualize and understand how mixin works hiding sender.
sr. member
Activity: 672
Merit: 250
DeepOnion
It will be 3 years soon for this project. Glad to know that the dev is still here now.
We need more people to use this coin.
legendary
Activity: 1750
Merit: 1101
karbo.io
With CLI wallet should I use this?

./simplewallet --daemon-address node.karbo.space:32348
Yes, that will work.
full member
Activity: 1274
Merit: 105
With CLI wallet should I use this?

./simplewallet --daemon-address node.karbo.space:32348
legendary
Activity: 1750
Merit: 1101
karbo.io
Is there possibility to use Karbowanec wallet with remote node?
What node should I use?
Or it's better to use 3rd party Light wallet in this case?
You can use any of our wallets with the remote node. The list of nodes can be found here: http://map.karbo.xyz/masternodes or here http://www.karbo.cloud/

In the case of official or so-called classic wallet, you need to set it into remote mode in menu Settings -> Connection.
All of those nodes are safe to use?
Yes, they can not steal your coins, no secret data is sent to them. If you're concerned with anonymity you should use VPN.
full member
Activity: 1274
Merit: 105
Is there possibility to use Karbowanec wallet with remote node?
What node should I use?
Or it's better to use 3rd party Light wallet in this case?
You can use any of our wallets with the remote node. The list of nodes can be found here: http://map.karbo.xyz/masternodes or here http://www.karbo.cloud/

In the case of official or so-called classic wallet, you need to set it into remote mode in menu Settings -> Connection.
All of those nodes are safe to use?
legendary
Activity: 1750
Merit: 1101
karbo.io
Is there possibility to use Karbowanec wallet with remote node?
What node should I use?
Or it's better to use 3rd party Light wallet in this case?
You can use any of our wallets with the remote node. The list of nodes can be found here: http://map.karbo.xyz/masternodes or here http://www.karbo.cloud/

In the case of official or so-called classic wallet, you need to set it into remote mode in menu Settings -> Connection.
full member
Activity: 1274
Merit: 105
Is there possibility to use Karbowanec wallet with remote node?
What node should I use?
Or it's better to use 3rd party Light wallet in this case?
legendary
Activity: 1750
Merit: 1101
karbo.io
дa я тaки нe пpoтив, взял - пoльзyйcя, нa здopoвьe.
нo пиcaть o тoм, чтo ты изoбpёл yникaльнyю тexнoлoгию бopьбы c aтaкoй 51%, дa eщё в видe cтaтeйки нa мeдиyмe - нy ты cилён...
Let's go to russian thread then. I added above the link to the code. Are we talking about the same thing?


Update: no response... of course, because the code for the corresponding article is 100% mine and I invented it. You must be referring to something other which I highly doubt is yours either.

legendary
Activity: 1750
Merit: 1101
karbo.io
It is you who borrow here and there from various coins. Please show me what exactly did we borrow?


Edit: I will add the link to the first version of our 51% protection code commit here https://github.com/seredat/karbowanec/commit/e06ace21195c473cf9109cbc31ffd6e9181a8738

eeX
hero member
Activity: 961
Merit: 500
Soldo.IN [SLD]
TLDR: Karbo made a novel and unique protection against 51%-attacks which disallows cancelling transactions from blockchain during reorganization. Now Karbo network nodes will refuse to reorganize to an alternative chain until any transaction from the current public chain is missing in the alternative chain. Even more, the alternative chain has to win within 10 blocks.

I like your modesty - "novel and unique protection against 51%-attacks" Smiley

In fact, you just borrowed 3 lines of source code from Soldo project - yes, this "novel and unique protection against 51%-attacks" is so silly simple;-)

I know it for sure, it's my code Smiley
legendary
Activity: 1750
Merit: 1101
karbo.io
any possible roadmap

Loose plan

- Cryptopia
- Broken Cyrillic filesystem support under Windows
- Web Wallet
- Payment Gateway
- Mobile wallet
- Some Ukrainian exchange
- Some major exchange
- Minergate

On development we're watching further wallet optimization, POS/POW, tail emission.
The proposal outlined in the previous reply will cover the mentioned in this cite POS/POW. By the way, all other points are fulfilled by now except major exchange and minergate. We have two payment gateways, two web wallets, mobile wallet, tail emission is implemented and will be updated and transformed into adaptive emission according to our whitepaper.
legendary
Activity: 1750
Merit: 1101
karbo.io
PoW with Stake in Karbo

The major concern for small PoW based cryptocurrencies recently has become the availability of sheer amount of hashrate that is not their native but is available for rent. This results in a series of attacks on coins utilizing rented hashrate. There is even the website crypto51.app which collects the theoretical cost of a 51% attack on various networks. The security of PoW is based on the assumption that it is unfeasible to achieve the prevail in a hash rate for a single entity and even if such entity will possess that hashrate it will be economically motivated not to attack network due to its investments in mining infrastructure, which is no longer true.

Scott Roberts (aka Zawy) describes PoW as “one of the weak forms of PoS” [1] stating that “The only thing protecting PoW is the stake of the equipment infrastructure... All the small coins switching to PoW algorithms that can't be easily rented is an attempt to make miners hold an equipment stake." [1] “This shows that work in PoW is not equal to security, and secure part of PoW is PoS. If BTC hashrate were rentable (no mining stakeholders) BTC double spends would be easy enough to make it worthless”. [1] He continues, “In Monero's case, PoW change was not to reduce NiceHash renting (the reason small coins change PoW) but to reduce the effects of ASICs that were in a few hands. So the key idea in both renting and concentrated ASIC problems, is that PoW works by having distributed equipment owners (stakes). It has nothing to do with work (waste). Value is created by work (waste) in BTC, which can be done in PoS. But securing established value is accomplished by risk of value, not waste. When buying equipment, you are locking up a stake just like PoS systems require. In all reasonable ways, PoW is just a weak and inefficient PoS in disguise”. [1]

From the other hand, in the article “Work is Timeless, Stake is Not” Hugo Nguyen describes the key weakness of PoS and comes to the opposite conclusion. He cites Paul Sztorc as “correctly concluded that PoS is an obfuscated form of PoW” [2] and states that “Proof-of-Stake is a misnomer. The correct, fully descriptive name for Proof-of-Stake should be Proof-of-Temporary-Stake (PoTS). This name is more accurate because it captures the time element, or lack thereof, of PoS.” [2] “The ongoing energy expenditure in PoW contributes to network security in 2 ways:” “Units of work expended in the past accumulate in the ledger. Units of work expended in the future accumulate in the current mining hardware.” [2] He calls this “sort of time-based accumulation phenomenon” as stock & flow. “Bitcoin is essentially protected by high stock-to-flow ratios in 2 areas: the ledger, and the mining hardware”. [2] “In contrast, PoS has no equivalent of this. Past stakes … do not accumulate in the ledger, as stake is released after some arbitrary bonding period. Long-range attack is the manifestation of this weakness: it works because of PoS’s inability to secure the past. Long range attack is at the heart of the problems with PoS, because it shows that in the long run PoS fails to guarantee the integrity of the ledger — the most important asset of all this innovation." [2] “Future stakes ... also do not accumulate in the validators in the present time, as again the act of staking only has meaning within the short window that it occurs — what happens in the future does not count today. Current-private-keys-theft is the manifestation of this weakness: it works because of PoS’s inability to secure the future. Keys theft sidesteps altogether the financial cost supposedly required to acquire controlling stake — whereas in PoW there’s no sidestepping the fact that an attacker needs to overcome the mining hardware and ongoing energy costs to pull off and sustain a majority attack.” [2] “In summary: the further one moves away from the present time in PoS, the faster stake loses its meaning, until stake becomes meaningless. Work is robust against the ravages of time. Stake is not. The fact that the cost of PoW mining is irretrievably sunk and accumulates both in the ledger and the mining hardware, is an important feature, not a bug. PoS research is often based on the fundamental misconception that this is a bug and a source of inefficiency”. [2]

Thus we identified a problem in current state of PoW — the lack of security ensured by stake in equipment. The brilliant solution to the equipment stake deprivation in PoW is proposed by Qi Zhou — to combine PoW and PoS in “Proof of Staked Work ” (PoSW) — a simple hybrid PoW/PoS. “The basic idea is that, if a miner wants to contribute its all hash power to the network (suppose p percent of all hash power of the network), the miner must stake the number of tokens that is proportional to p.” [3] So we came to obvious, naive and simple solving: add to PoW, what has become missing — a stake.

We propose similar yet different approach without multiplying work by stake as we have concerns that this might be an attack vector and could cause frequent reorganisations and higher orphan rate. Besides, the algorithm can estimate hash power of the whole network via difficulty whereas it is hard to estimate hashrate of individual miner to adjust his stake requirements. So we set the same minimum required stake for all miners based on difficulty.

In order to mine a block the miner must stake the number of coins that is not less than the current minimum amount which is determined by the difficulty. The preliminary proposal is that the minimum stake in atomic units should be equal to the next difficulty multiplied by factor m. This factor should be defined economically from the current network state and conditions. For start let m = 100000.

A miner forms the coinbase transaction as follows: he sends to himself the amount not less than the required minimum and adds fees and block reward. This is enough to prove and verify his collateral stake in a simple way.

There is mined money unlock window n, a rule which locks all outputs in coinbase transaction for n blocks. This means that coins from coinbase transaction can be spent only after n blocks. Therefore, to be able to mine blocks successively, miner will have to possess much more money than minimum stake amount for one block,— he will need a stake for each block until his stake for a first mined block is unlocked. This will substantially and even exponentially increase the cost of 51% attack, the cost of being large miner or running a mining pool since the miner or the owner of the pool will have to acquire sufficient stake.

Coin transferred in a coinbase transaction proves possession without revealing sender and recipient. This keeps the stake and reward wallets separate. There will be the possibility to lend stake by preparing a template stake transaction in which lender sends coins to himself, reward to miner, and part of the reward to himself as a commission for lending, and issues this raw transaction to the miner. The miner can check if he received sufficient reward and use the transaction in the block template.

Instead of daemon the coinbase transaction with stake should be created in wallet on request from the daemon or mining software. Staking wallet should be running in RPC mode and listen to the special corresponding command.

Check for inputs/outputs should be revised to take into account new coinbase transaction type.

This approach evokes concerns of amplifying the centralization of mining in the hands of those who possess enough stake for large hash rate eliminating small miners and pools.

References:

[1] https://twitter.com/zawy3/status/1082199522812612608

[2] https://medium.com/@hugonguyen/work-is-timeless-stake-is-not-554c4450ce18

[3] https://medium.com/quarkchain-official/proof-of-staked-work-ef36f9499279
Pages:
Jump to: