Topic: [ANN][KMD][dPoW] Komodo - An Open, Composable Smart Chain Platform, Secured by B - page 394. (Read 1192000 times)

it has stuck here for more than 5 days http://prntscr.com/fgxsxo
what should I do to use the wallet properly. I do want to store some komodo for future purposes but it seems that the wallet does not let me do that. Someone please help me please

That is quite impressive! Where can I  learn more about JUMBLR?.Will it be a separate token and can it be tradeable?

How to transferInterest earned?

I am running the agama wallet in Basilisk mode. I see I have some Interest earned, but that interest is not showing up in my balance. So how can I obtain/transfer this Interest earned?

This is a good idea, especially for whales

This coming Swing Wallet release will have a swing import function.


Don't overwrite or lose your wallet.dat. Always take an extra backup if you are unsure.

Unless you need to immediately move your funds I recommend that you wait for the coming Swing Wallet release.

1) wait that we release it here: https://supernet.org/en/products/komodo-swing-wallet
2) once it's released, download and launch the wallet
3) it will have seed import, you just enter the seed you used in Agama Wallet's Basilisk Mode and you will have your coins in the Swing Wallet

The wallet should work without any issues.

it's good to see this notice but I want to know when is the komodo wallet with the seed released ? because I want to transfer my address from Agama app to komodo wallet .

Komodo platform is moving fast . After the blockchain issue here comes a solo wallet for KMD. Good job Komodo devs.

Hello,

I've got some issues with the Komodo wallet. I've tried to install the new komodo-swing-wallet, what worked, but I don't understand how to use it.

1.) Before I used Agama in Basilisk Mode and transfered some of my KMD sucessfully to another adress. Now I cannot enter anymore as it is loading without an end. How can I start the newest Agama automatically in Basilisk Mode? I think it is downloading or trying to download all the blockchains of diferent coins.

2.) If I use now the new komodo-swing-wallet, is there a Basilisk Mode? If not, how or with what app can I still use this mode? I have just my seed, as I never used Komodo in native mode (downloading the full blockchain). The team allways say to backup the wallet.dat. Where is the wallet.dat of the agama.app that I used in Basilisk mode?

3.) When I just installed the komodo-swing-wallet, is it possible that it overrided my existing wallet.dat (without asking) and I lost all my KMD?

4.) How can I use my Seed now do get my KMD? I can not enter the key in komodo-swing-wallet, it says it is wrong, or is the private key the seed?

Thanks to JL777 and SuperNet team for the excellent communication 

Are voters able to split their vote between multiple candidates? I'd really like to support candidates who might be working on cool dev projects for Komodo, but if it was possible to use some proportion to vote for a pool and get some extra kmd for myself that would be great too.

zcash does not work in 32bits
neither does komodo

---

Here are some technical notes on native DEX to give an idea of what needs to be tested:

At first we need to do more clearbox testing as opposed to blackbox testing. by understanding what is supposed to happen internally, it will be easier to make sure it actually is and when that is solid.
there are two totally different (complicated) parts to the native DEX. Ordermatching and the atomic swap itself
In a decentralized exchange, just knowing what the orderbook is becomes complex. Here we have LP nodes (acting as servers to a degree) and client nodes. The latter need the absolute latest orderbook, but not that often, just when they want to do a trade, but of course they want it quickly
A requirement for the LP node is that anybody is able to run one, ie. permissionless. To achieve this, I made a custom p2p network. yes, yet another one, but I wanted the absolute fastest networking so decided to make my own. That means there could (are) bugs in the fundamental networking code as I read/write directly to the network ports. I combined the p2p and rpc aspects and the peers actually use the same requests as the browser makes for http://5.9.253.195:7779/api/stats/orderbook?base=REVS&rel=KMD and the equivalent. This allowed me to use the same code for the p2p networking and the rpc handling. native DEX p2p network has custom messages to propagate new peers quickly and available utxos reasonably quickly
At any given time, most of the LP nodes will have a recent set of available utxo and a very current set of peers. So, the client connects to any of the seed nodes, gets a list of peers and iterates getpeers on them to get a complete map of all the LP nodes. It is quite possible the networking can flood itself, but I did put guards against that in
the native DEX is based on utxo (pairs). the LP node needs the utxo to trade and a 13% bigger utxo to use as a deposit. The client node needs a utxo to trade and a 1/777th size one for the dexfee. A node scans its smartaddress (derived from passphrase) for pairs of utxo using a simple bestfit algorithm and creates utxopairs that can be seen locally using the inventory command
Now I am concerned that at some scale, the current design will bog down, however I have structured things to be pretty efficient. Each LP node creates a pub/sub nanomsg socket along with a push/pull pipeline socket. The former is used for sending out data (and commands) the latter for receiving requests. Both channels are fed through the RPC command processor, so typically a matched pair of "method" fields are used similar to "ping" -> "pong" response
Since the nanomsg pub/sub was designed to broadcast to a very large number of nodes, it should be able to handle thousands of client nodes. However, to maximize data propagation, all the clients are connected to all the LP nodes. with 10 LP nodes now, this is not an issue, but it could become one if we end up with hundreds (or thousands) of LP nodes
any node can request from an LP node about peers and utxos and prices, whenever any node does, the LP node publishes the answer and since all clients (and LP nodes) are subsribers to all LP nodes, the original requestor along with everybody else will get the data. This makes it so that a lot of times all the required data is available client side automatically
To receive requests, all nodes connect to a one stage pipeline with a single provider, a specific LP node. this serializes the request stream from all other nodes into a specific LP node. Most requests are about peers, utxo and prices, but there are a few special ones that start an atomic swap
Since we are swapping specific utxo, it can only be swapped with a single party. This means we need to create an exclusive lock on that utxo for sale. Of course it needs to be time limited to prevent the orderbook from being locked. The "price" command and "request" command are nearly identical, the latter just provides a 60 second lock for the requesting party to "connect". Since the information is broadcast publicly, it is possible for some other node to jump in and establish the connection. However, in some sense the native DEX is a free for all, first come first served, so this is in the spirit of the DEX operation
the "connect" command makes sure a utxo was properly reserved and if it was it creates a nanomsg NN_PAIR socket, which has the nice attribute of being limited to two connections, one immediately being taken by the LP node. This assures exclusivity of the connecting client node during the atomic protocol and further that only one party at a time is trading any specific utxo. At least on the LP node side. It is possible for an evil client to try to trade the same utxo to multiple LP nodes, but the blockchain will prevent such double spends
In my tests, I am seeing the above process of fetching the utxos, getting prices, requesting and connecting happens essentially instantly
Once the atomic swap protocol starts, I set it up like railroad tracks, basically it can only go along a single path, or derail. This dramatically simplifies all the possible errors that can happen during the atomic swap.
https://bitcointalksearch.org/topic/atomic-swaps-using-cut-and-choose-1364951
 discusses the protocol details for the atomic swap itself. It is quite difficult to understand, so I will try to simplify
bitcointalk.org
Atomic swaps using cut and choose
Atomic swaps using cut and choose
In order to prevent spamming, the client node must pay a dexfee (1/777th tradesize) to assure the LP node that he is serious. Putting an actual financial cost has the advantage in that it removes spammers at the first step and also it creates a revenue stream for our patient investors. There is an implicit assumption that LP nodes are more reliable than client nodes. Even before the dexfee is sent, the two nodes use the cut and choose protocol to perform a key exchange and create a trade specific set of addresses that will be used. Once this is done, then the dexfee is sent. Once the fee is verified to have been sent, the atomic swap starts for real. By convention the two parties trading are Alice (client) and Bob. Bob has the burden of providing a deposit in the protocol. To compensate, Bob has no dexfee at all, just the coins txfee.
Bob first broadcasts a deposit. Alice waits for this to be confirmed. By waiting for the coin confirmation, the nature of the protocol avoids malleability issues, other than the generally annoying part about malleability where the txid you expected is not what ends up in the blockchain. Alice then sends a 2of2 multisig to Bob, Bob can verify it is to the right address that he will be able to spend, but he cant spend it yet
Bob then sends his payment to Alice, who is able to spend it immediately and by doing so has to divulge the information Bob needs to spend the 2of2 multisig.
As soon as the three initial transactions are sent to the blockchain(s): bobdeposit, alicepayment, bobpayment, the trade is locked, both parties know they will get at least what they agreed upon, in cases where one side doesnt do what they are supposed to, the other party can get even more
for each of the three payments, there are two outcomes: bob spends it or alice spends it. The mainstream sequence is:
1. bobdeposit 2. alicepayment 3. bobpayment 4. alicespend 5. bobspend 6. bobrefund
however at any point, the sequence can stop due to disconnection or intentionally. You will see that regardless of what point it stops at, the result is acceptable:
1. alice will eventually claim the deposit when it times out in some hours
2. bob can refund his own deposit and in doing so allows alice to reclaim her payment. if enough time elapses, alice can spend the bobdeposit and give bob the information to spend alicepayment
3. after timeouts, bob can reclaim his deposit and payment
4. alice is happy at this point and can collect even more via spending bobdeposit
5. there is no reason for bob to leave the transactions for alice to reclaim
The above is a very high level description and the reality has a lot of subtle details to make it all work. Happy hunting for bugs

keep an eye on this page: https://supernet.org/en/products/komodo-swing-wallet

We will publish a new wallet there. We expect it to work without any issues and people are able to send KMD.

Agama is still in early development phase, and needs time

5 % of JUMBLR token will be distributed to all KMD holders. Snapshot will happen June ~13th and distribution itself one week after that.

Thank you sir. I will download to try

yes, that is how it should be. you wouldnt want people without much at stake to control the voting.

Bittrex is the "PoW" equivalent right now as anybody can buy voting power. However, other than the free money part, a notary node does not have a lot of direct powers to affect things. A notary mined block still has to be validated by all nodes, there is no ability to create arbitrary transactions. But like with any mined currency, the miner has discretion on what goes into the block.

In my opinion, it is harder to centralize stake as that only requires money to purchase stake and anybody with money is able to do this. That seems pretty fair. With PoW mined coins you need both money and expertise in mining, which limits the number of participants. The fewer the participants, the more likely it is to get centralized.

There are thousands of KMD holders now. If any one of them tried to corner the market and buy up all the KMD ...., that doesnt make economic sense as the cost of such market activity is unlikely to be recouped from a notary node.

Also, notary nodes are split into 4 geographic areas, so no single region can have more than 16 (25%) of notary nodes. That alone seems to make centralization a challenge

I may not be stating this correctly but is't it that whoever has larger number of KMDs also has higher voting power/rights?

+1
crypto investors don't leave money on the table, especially not 20K USD a month (1 Bil USD MK for komodo) for basically running a complicated masternode minus the personal capital required for other coins like DASH/NEM, and 1 bil MK by december is definitely possible in this bull market.

Game theory says the only way notaries don't start offering voters a rev share to get elected is if they collude, and I don't see that happening under jl777's watch, so it just takes one notary to offer a voter % and the flood gates open to full blown competition, which is what should happen if the market is working properly.

Good operators should still get elected with a premium %, but super profits from mooning KMD should go to the KMD holders, same as for a Dash/NEM masternodes etc

Most notaries are probably big KMD holders anyway.

I made an alpha release (command line) of native DEX, more details in #tradebots of SuperNET slack

any coin to any coin trading directly from wallet is now possible

I originally did atomic swaps a couple years ago, but it didnt have the required performance until this iteration. Also, there were quite a few higher priority things that I had to deal with.

Nowadays with the much larger organization, I am able to spend the vast majority of my time coding again.

Anyway, we are looking for command line testers. There  is 10000 KMD allocated for bounties and also there will be coins offered at crazy low prices on the native DEX and the ones who can figure out how to trade for them will get them.

I predicted the second elections will be a lot more competitive, it seems I will be right.

Notaries are currently grossing about $100 per day and this is a nice reward for all the work they put in to get to where we are today. They all took a risk that they might just barely cover costs for all their troubles, but the upside is to have the income increasing without any cost increase.

The quick response of the notaries allowed us to detect and thwart attacks and in general keep the blocks generated smoothly. Moving forward, I think the community will be scrutinizing the actual contributions that each notary makes and vote accordingly.

There are many ways to contribute and one of the most important is by being a developer. We are looking for more devs and while I cannot promise that an active and productive dev will win a notary spot, I can say that they have a very good chance of being elected.

The formula is that a notary node makes about 80x the price of KMD per day, so as the price keeps going up, this starts becoming real money. What if KMD had a few dozen devs who never had to worry about money and could just code cool things for KMD?

They have so far two wallets for KOMODO one is agama (https://supernet.org/en/products/agama-wallet) and another is swing wallet (https://github.com/ca333/komodoGUI/releases/tag/v0.7.7-win)