kpx.io needs to be updated to April 5th version. http://kmd.explorer.supernet.org/ is up to date explorers.supernet.org has a list of all the explorers if you are running native komodod and have not updated to April 5th version (released last week), you are likely on a fork due to not having the latest version. The April 5th version should fix the interest rate calculation error in prior version. This was a planned update and most all the nodes have updated, so the network is running fine, though it seems some GPU pools didnt update so there is much less hashrate, ie slower blocks at times. |
|
|
|
You never gave answers to any of my questions. When will my KMD which I converted and sent to bittrex yesterday reach my bittrex account. It's still pending... On the ico
Payouts are processed manually, next one on this Friday and then monthly Wait... So it means, if I am failed to find a 64bit windows or a linux or a mac before friday, then I'll have to wait for 1 month for the coin to arrive at my wallet (assuming you finally release a stable 32bit or an androind wallet by then) ? Wow, waiting for 4 months (or is it 5? I've lost count how many months is it since the ico ends) sure a long time Not sure why you conclude this. For many months you could put in any KMD address to receive the payout to. All it requires is to run a browser, no need for any specific system configuration. Get a Bittrex deposit address put that address into the payout form on Friday I will process it and it will arrive in the bittrex account This has be stated in many different ways on many different occasions You can get a payout directly to a bittrex address. If you have a bittrex address, you can get a payout directly to that address. And I repeat, the next payout is Friday. After that it will be monthly. There are just so few payouts remaining, it will take a month to even get to 20+ payouts. |
|
|
|
If you want me to check your seed I am willing to do so. If you prefer not to trust me with your seed I understand and will not take offense.
Someone like yassin may also be willing to check it for you.
at this point, I really dont mind. Ill send it to you in a PM. Provided seed generates the address : RJSgNSmfy3mP2m5icjqVpWz9jsYfra3xGt (as you quoted previously) Balance = 0 Checked on kpx.io and the address does not exist on the blockchain as there are no transactions. This is what I'm talking about. I followed everything. I'm will to let the dev look at my ico account to see. If you dont have the passphrase that generates the address, I will need to reverse the RMD160, SHA256 and secp256k1 that were used to generate the address. The latter just needs some recent quantum computing gear that isnt quite ready yet. The RMD160 can likely be bruteforced using some of the larger supercomputers. I will have to see about reversing the SHA256, that one seems that even with quantum compters there is no good algo to reverse it, yet. tl:dr If you dont have the passphrase that generates an address, nobody can practically generate the passphrase. |
|
|
|
A friend of me asks whether he can withdraw KMD from the ICO site directly to bittrex. Is that possible?
Of course. Toward the end of the second post: "How to send your KMD to an exchange" even has detailed instructions |
|
|
|
I think I see where you are going with this, most pax coins will just trade for btc so no need to "unwind" (unlock)(recreate) them back to kmd.
Are there any quotes from the pax white paper that describe this in more detail, specifically this extra pool of kmd that will be used in case of a net shortfall, you can share?
Also, and this has got me thinking, what happens to the supply of kmd when the pax conversions start? Ie: How many kmd do you guesstimate will be locked/burned and unavailable once pax 1 starts? Pax2?
And say in a scenario where a small country decides to use pax and all of a sudden issues a few billion pax of the local currency, what does this do to kmd supply?
Thanks jl777
The pax paper will cover most things with more details. For pax1, I set aside a fixed amount of KMD enough to cover even the total meltdown scenarios. With pax2 the goal is a dynamically adaptive supply that manages risk within specified limits. Think of it as an automated self-insuring blockchain enforced supply. For pax 1, the most KMD that is likely to be locked (burned) is several million. For pax2 I would like to be able to handle an order of magnitude more so I dont expect any reduced supply effect to affect price that much until pax2. To handle a small country's usage, I would need to adapt the pax mechanism to create sidechains for this small country's currency. So N blockchains all DEX connected to each other, all using the same token. Of course such large demand would dramatically reduce the freely available KMD, which is designed to have the effect of increasing its price so as to reduce the total that is needed to be locked (burned). |
|
|
|
Hello miners, we are proud to announce http://komodominingpool.com/ ( beta-test) MINING POOL FOR NEW KOMODO COIN (KMD)HOW TO CONNECT
stratum+tcp://komodominigpool.cloud:5555 ( Auto VarDiff - suitable for CPU and GPU ) To mine KMD just use any ZCASH (EquiHash) miner with komodo address ( !! NOT USE ZCASH ADDRESS to T-ADDRESS !! ) example : ZecMiner64.exe -zpool komodominingpool.com:5555 -zwal komodo_address -zpsw x -allpools 1FEATURES
- Personal mining stats - Stratum and auto vardiff for efficient mining - Payouts are done every 30 minutes. However, 101 confirmations for a block are required to receive a payment in your wallet. - 0% fees- Support with Gitter chat NOTE: this pool use komodo daemon 1.0.5 ( https://github.com/jl777/komodo ) and it's in beta .. Any comments, suggestions and integrations are welcome Happy mining! Looks nice so far, just started mining. thank you but again same problem ... here my steps - reset the blockchain, from ~/.komodo rm -rf blocks chainstate debug.log komodostate db.log inside komodo dir - git checkout beta - git pull - ./zcutil/fetch-params.sh - ./zcutil/build.sh -j2 all it's ok ./komodod & after 1hour of resync 2017-03-25 15:23:01 [Pool] [komodo] (Thread 2) getblocktemplate call failed for daemon instance 0 with error {"type":"request error","message":"socket hang up"} ./komodod crash again socket hang up is an error I havent seen. could be some network issue. It seems the resync is indeed 2x as fast. If it will rescan/resync again, I suggest that you sync without mining, exit, make a complete backup. This way you can always resume from a very recent block no matter what happens. Now, try mining with just one thread and see if it is stable. It could be multithreaded mining has a recent issue? I will investigat this socket hang up to see what it could be thank you jl777 i try again with as you suggest. i updated beta branch now, recompiled komodo with -j1 and resync coin ( wait ) now service mining it's not active, i will inform you asap Regards Again.... 2017-03-26 00:22:47 [Payments] [komodo] Error with payment processing daemon {"type":"offline","message":"connect ECONNREFUSED 127.0.0.1:8232"} 2017-03-26 00:22:49 [Payments] [komodo] Unable to get operation ids for clearing. error in this point ( z_getoperationstatus )z-nomp/libs/paymentProcessor.js 377-384 daemon.cmd('z_getoperationstatus', null, function (result) { if (result.error) { logger.warning(logSystem, logComponent, 'Unable to get operation ids for clearing.'); } if (result.response) { checkOpIdSuccessAndGetResult(result.response); } }, true, true); }, opid_interval); this looks like a different error, so some progress. are you sure z-nomp is configured correctly? 127.0.0.1:8232 is not a KMD port also KMD doesnt mine to z-addresses, it mines to transparent addresses, so not sure why it is looking for operation ids. My guess is that the nomp isnt quite matched up. movetocrypto should be able to help you hi jl777 due an initial error in configuration, some rewards were sent to a our z_addr Using z_gettotalbalance we see this reward in private and non in transparent. if i try to use z_sendmay from z_add to t_add i receive this error : Payment operation failed opid-56af3a46-f0ee-4394-92ff-b4240b8036a5 -1, runtime error: anchor is null any workaround? PM me a typical txid that funded the z-output |
|
|
|
@jl777 - thanks for your answer! I'm really curious about this tech, so if you don't mind, I have couple more questions: The above will convert 1 USD worth of KMD into pax USD.
1. How does PAX know current KMD/USD rate? 2. If I convert some KMD to USD now, on PAX1, will that USD be "reachable/valid" after you release PAX2 with dynamic supply? 3. Scenario: User converts 100 KMD at rate 1 USD/KMD, so he gets 100 PAX USD. In the meantime, KMD price falls to 0.5 USD/KMD. Now he converts 100 PAX USD to KMD and gets 200 KMD. From where does that 100 KMD comes from? Also, where does initially converted KMD "go"? Thanks! This is really interesting, very cool. 1. Notary nodes are putting price feed into the blocks they mine. From this data a process similar to what Augur uses calculates a determistic price by all nodes that requires a 51% attack to change the price to a fake price. Each node has a paxprice cli call that you can see what the price is for that block. 2. PAX2 will of course honor all PAX1 positions, it will likely be a gradual transition process as more and more of PAX2 features are added to PAX1, until one day it is PAX2 3. The conversion process burns the KMD by using an OP_RETURN. Assuming a stable price, over time the deposits and withdraws will cancel out any gains/losses. However as a worst case meltdown scenario, we have set aside enough KMD to absorb conversions that use up the KMD. This is why PAX2 is needed before we remove the volume caps on issuable amounts so that the risk is always limited to absorbable levels. To handle a BTC and/or KMD meltdown scenario, there is a floor price of 2500 sats that the conversion wont go below. Since this is approx the BTC reserves I felt it a reasonable floor price. Given a floor price, the max exposure can be calculated. However due to the limited amount issuable with PAX1, I dont think redeems will be an issue and that all the issued PAX currencies will simply circulate around in the ecosystem. Since KMD is burned to issue the PAX, as long as BTC and KMD are long term increasing, PAX usage will actually create more KMD. Regarding point 3. I am understanding that kmd is burned when issueing pax. When converting pax back to kmd, I am a little confused. [I assumed the kmd was locked (not burned) and unusable when converted to pax until unlocked when converted back from pax, and the pax burned. ] Based on your reply, do I understand right that there is a pool of kmd set aside by the developers that gets dipped into when converting pax back to kmd? And because you don't think redeems will be an issue this pool will never go dry? Lock/Unlock Burn/Recreate these are really the same effect. So the reserve is only for net shortfall, ie. if it will need more KMD to recreate the USD value than was burned. But the practical conversion is pax -> BTC, so to convert to KMD and then to BTC will be an extra step and the conversion to KMD is not fast. By directly being able t DEX from pax -> BTC, it will be faster and also avoids the issue. Since the supply is strictly limited, I dont forsee any large demand to redeem. Of course if there is, we will allow such redeems. |
|
|
|
=
If accounts with trade enabled but withdraw disabled were compromised, what you talk about is the way attacker would transfer value out. Buy up low volume coins from different accounts, then buy with the BTC in the compromised account. Now N accounts all have BTC at big multiples, so even the $2000/day limit is bypassed.
It is a theory.
But once a pump starts for whatever reason on polo, anything can happen.
If someone has 2FA enabled, then you need it to log in and also for withdrawals. If someone doesn't have 2fa enabled, then you don't need it for withdrawls. So if you can get in the acct, you can withdraw the funds. And who would have an acct with withdraw disabled? And if it is disabled, you could likely enable it with whatever tools and info you had to login to the acct. So it's still a wild theory, but I suppose not impossible. And I suppose yes you could use your own account and sell to whoever's acct you hacked to buy too high. But would look suspicious and Polo could lock your acct. But yes, agreed that many crazy pumps on Polo and that could just be the reason. You forget about API keys, which are most usually set with withdraw disabled, but obviously trade enabled. so maybe somebody's bot's api key was compromised. As good theory to explain BTCD at double KMD market cap as any |
|
|
|
Well, I'm speaking of an attacker who is draining limited accounts with ridiculously high bids on low volume coins.
BTCD is not the only coin, that shot up magically.
It this a weird fantasy of yours or is there some news about this? More likely a hacker with access to an account would withdraw the funds and not go in there and try to lose them (making other random people profits at the same time). Sure they could do it for the "lulz", but extremely unlikely. That's why I spoke from limited accounts. If accounts with trade enabled but withdraw disabled were compromised, what you talk about is the way attacker would transfer value out. Buy up low volume coins from different accounts, then buy with the BTC in the compromised account. Now N accounts all have BTC at big multiples, so even the $2000/day limit is bypassed. It is a theory. But once a pump starts for whatever reason on polo, anything can happen. |
|
|
|
@jl777 - thanks for your answer! I'm really curious about this tech, so if you don't mind, I have couple more questions: The above will convert 1 USD worth of KMD into pax USD.
1. How does PAX know current KMD/USD rate? 2. If I convert some KMD to USD now, on PAX1, will that USD be "reachable/valid" after you release PAX2 with dynamic supply? 3. Scenario: User converts 100 KMD at rate 1 USD/KMD, so he gets 100 PAX USD. In the meantime, KMD price falls to 0.5 USD/KMD. Now he converts 100 PAX USD to KMD and gets 200 KMD. From where does that 100 KMD comes from? Also, where does initially converted KMD "go"? Thanks! This is really interesting, very cool. 1. Notary nodes are putting price feed into the blocks they mine. From this data a process similar to what Augur uses calculates a determistic price by all nodes that requires a 51% attack to change the price to a fake price. Each node has a paxprice cli call that you can see what the price is for that block. 2. PAX2 will of course honor all PAX1 positions, it will likely be a gradual transition process as more and more of PAX2 features are added to PAX1, until one day it is PAX2 3. The conversion process burns the KMD by using an OP_RETURN. Assuming a stable price, over time the deposits and withdraws will cancel out any gains/losses. However as a worst case meltdown scenario, we have set aside enough KMD to absorb conversions that use up the KMD. This is why PAX2 is needed before we remove the volume caps on issuable amounts so that the risk is always limited to absorbable levels. To handle a BTC and/or KMD meltdown scenario, there is a floor price of 2500 sats that the conversion wont go below. Since this is approx the BTC reserves I felt it a reasonable floor price. Given a floor price, the max exposure can be calculated. However due to the limited amount issuable with PAX1, I dont think redeems will be an issue and that all the issued PAX currencies will simply circulate around in the ecosystem. Since KMD is burned to issue the PAX, as long as BTC and KMD are long term increasing, PAX usage will actually create more KMD. |
|
|
|
Hi! Can someone please explain how we can swap KMD for USD "PAX" currency through CLI? Also, how we can do reverse operation, USD > KMD? Are there any fees?
Thanks!
With PAX1 we are limiting the total amount that can be issued per currency so we can get the foundational aspects validated in the field for PAX2. PAX2 will have a lot more dynamic inventory creation enabled. With current PAX, there is the paxdeposit CLI command ./komodo-cli paxdeposit <KMDaddress> <amount> <currency> eg. .komodo-cli paxdeposit RSXGTHQSqwcMw1vowKfEE7sQ8fAmv1tmso 1 usd The above will convert 1 USD worth of KMD into pax USD. For the reverse, we will be setting up LP nodes to do atomic swaps so you can go directly from pax USD <-> BTC, in addition to USD <-> KMD and if there are LP nodes that want to setup a forex from USD <-> (other fiats). I was just in the process of validating this part when the attacks hit, so will be going back to it this week. Currently the LP nodes are not live, but when the code is ready, anybody will be able to be an LP node. KMD decentralizes liquidity providing. Even a basilisk node will be able to be an LP node. That has taken a bit more work, but I feel it is the more practical approach as this way anybody can be an LP node just by clicking a few fields in the GUI (not ready yet) without needing to download the entire blockchain. We will be looking for testers for LP nodes in April, especially if you can do command line |
|
|
|
When can I withdraw interest?
it automatically accumulates, there is no need to withdraw it. just spend as normal and you can spend more (by the interest) than you originally received. however between now and April 5th, there is a miscalculation of the interest for middle sized amounts where it could give you less, so best to wait until April 6th Agama wallet will show your interest separately. it is on the blockchain and no special action is needed |
|
|
|
|
We are at block 250500 and other than the interest miscalc, things are looking quite smooth.
I decided to not start a new release cycle just for the interest miscalc, so the master branch is ready to go. There will be a planned update April 5th with the interest fix and other things, but without any crazy rush to push it out the door.
tl:dr if you are running komodod and havent update to the 250000 version, pull from the master branch and rebuild. There will be a scheduled update that activates April 5th later in the week.
|
|
|
|
Hey guys I just installed the new wallet release... All went without a hitch...
The new installer was much faster then before...Woot..
The updated GUI much more streamlined and seems much more responsive so far... Good job guys....
Will experiment when I get home hopefully the chain will be downloaded by then.....How Long does it take to synchronize from scratch?
Again good job guys keep up the good work
On nodes with decent bandwidth, full sync from scratch is about an hour. I think 25mbits/sec speed might be required to achieve this, maybe a bit faster. If you have a 9600 baud modem, it will take quite a bit longer. |
|
|
|
|
There is the Swing wallet for people who want a basic wallet
|
|
|
|
Bittrex wallet is still under maintenance. Has anyone from the Komodo community been in contact with them? Missing out on staking rewards while they figure out their wallet issues. (yes, I'm well aware that this isn't Bittrex support - I just figured I'd ask here first)
Of course we are in touch. I advised them to wait until after the 250000 changes kick in to make sure there are no issues. Good thing too, as we found that there is underpayment for interests with the current version for mid sized utxo. exact size depends on when minutes * 5% nValue overflows 64 bits. I had a feeling that during my sleep deprived period I made some errors, so we are continuing to review and I have made a new version that will activate proper interest calculations as of April 5th. Just too many updates recently and this gives a bit more than a week to update. What this means is that if you spend utxo that overflows before April 5th, it will not give you all the interest. Running the 250000 version for now is fine, just another update will be required before April 5th. |
|
|
|
Hello miners, we are proud to announce http://komodominingpool.com/ ( beta-test) MINING POOL FOR NEW KOMODO COIN (KMD)HOW TO CONNECT
stratum+tcp://komodominigpool.cloud:5555 ( Auto VarDiff - suitable for CPU and GPU ) To mine KMD just use any ZCASH (EquiHash) miner with komodo address ( !! NOT USE ZCASH ADDRESS to T-ADDRESS !! ) example : ZecMiner64.exe -zpool komodominingpool.com:5555 -zwal komodo_address -zpsw x -allpools 1FEATURES
- Personal mining stats - Stratum and auto vardiff for efficient mining - Payouts are done every 30 minutes. However, 101 confirmations for a block are required to receive a payment in your wallet. - 0% fees- Support with Gitter chat NOTE: this pool use komodo daemon 1.0.5 ( https://github.com/jl777/komodo ) and it's in beta .. Any comments, suggestions and integrations are welcome Happy mining! Looks nice so far, just started mining. thank you but again same problem ... here my steps - reset the blockchain, from ~/.komodo rm -rf blocks chainstate debug.log komodostate db.log inside komodo dir - git checkout beta - git pull - ./zcutil/fetch-params.sh - ./zcutil/build.sh -j2 all it's ok ./komodod & after 1hour of resync 2017-03-25 15:23:01 [Pool] [komodo] (Thread 2) getblocktemplate call failed for daemon instance 0 with error {"type":"request error","message":"socket hang up"} ./komodod crash again socket hang up is an error I havent seen. could be some network issue. It seems the resync is indeed 2x as fast. If it will rescan/resync again, I suggest that you sync without mining, exit, make a complete backup. This way you can always resume from a very recent block no matter what happens. Now, try mining with just one thread and see if it is stable. It could be multithreaded mining has a recent issue? I will investigat this socket hang up to see what it could be thank you jl777 i try again with as you suggest. i updated beta branch now, recompiled komodo with -j1 and resync coin ( wait ) now service mining it's not active, i will inform you asap Regards Again.... 2017-03-26 00:22:47 [Payments] [komodo] Error with payment processing daemon {"type":"offline","message":"connect ECONNREFUSED 127.0.0.1:8232"} 2017-03-26 00:22:49 [Payments] [komodo] Unable to get operation ids for clearing. error in this point ( z_getoperationstatus )z-nomp/libs/paymentProcessor.js 377-384 daemon.cmd('z_getoperationstatus', null, function (result) { if (result.error) { logger.warning(logSystem, logComponent, 'Unable to get operation ids for clearing.'); } if (result.response) { checkOpIdSuccessAndGetResult(result.response); } }, true, true); }, opid_interval); this looks like a different error, so some progress. are you sure z-nomp is configured correctly? 127.0.0.1:8232 is not a KMD port also KMD doesnt mine to z-addresses, it mines to transparent addresses, so not sure why it is looking for operation ids. My guess is that the nomp isnt quite matched up. movetocrypto should be able to help you |
|
|
|
Nice coin bros, 90% premine, bittrex wallet down, but 9mil$ market cap (LoL).
Sell like your life is depending on it.
Edit: Oh yea and a possible btc split in the future, btc hash rate might be going to shit. Isn't Komodo built around BTC's hash power? hahahahhaaha.
This is why we designed it so we can change which chain we dPoW to. We simply pick the most secure chain, the notary nodes update. KMD is built to be adaptive. Confused how you can consider a 90% premine, only 10% was reserved for the KMD team. The rest was purchased by BTC or swapped from BTCD. BTCD was mined at first and 100,000 coins created via staking. So it is over 90% mined so I think by any reasonable calculation, the majority of KMD can be considered to have been mined. Additionally, you might have missed this in your thorough research, KMD is still being mined and only half the supply is currently existing. |
|
|
|
|
There is an updated release candidate in komodod repo.
At block 250000 consensus changes will activate, so if you are running native komodod, you will need to update before then.
Basilisk users dont have to worry as the notary nodes will be updated
|
|
|
|
|
Show Posts
