Since KMD is now on bittrex, I imagine a lot of people will want to deposit there directly via payout.

there is only 10 pending now, but if it gets past 100, I will do another payout tomorrow

As I wrote in https://bitcointalk.org/index.php?topic=1605144.msg17800081#msg17800081
there is no bitcoin built in way to find out if a txid/vout has been spent or not. To do that you need to index the entire blockchain and mark the txids that have been spent, the ones not marked are still unspent. Of course bitcoin does this for addresses in the wallet, but it doesnt do it for addresses that are not in the wallet. Including watchonly addresses.

So over the last couple of days I wrote a full blockchain indexer that can be used to index any blockchain with standard RPC. for now it is only enabled for KMD via dexexplorer API:
curl --url "http://127.0.0.1:7778" --data "{\"agent\":\"dex\",\"method\":\"explorer\",\"symbol\":\"KMD\"}"

it will take a while to scan the blockchain the first time, but after that it will initialize in under a minute when iguana is launched.

The following are the API bindings that are now available:

TWO_STRINGS(dex,listunspent2,symbol,address);
TWO_STRINGS_AND_TWO_DOUBLES(dex,listtransactions2,symbol,address,count,skip);
HASH_AND_STRING_AND_INT(dex,gettxin,txid,symbol,vout);
TWO_STRINGS(dex,listspent,symbol,address);
TWO_STRINGS(dex,getbalance,symbol,address);

I made listunspent2 and listtransactions2 so we can get them validated before using them in the main bitcoinrpc path. The above API bindings simply shows the JSON field names needed in the curl request, there are plenty of examples in SuperNET/iguana/tests

With dex explorer initialized, this means that (theoretically) the current balance of any address, the set of utxo, the list of spends, the spent status of any utxo, can all be queried. And it is all RAM based, so should be quite fast. I added a special handling in dex/getbalance for the address of '*', which will return the coin supply. This it does by bruteforce iterating through all the addresses and doing a getbalance on it. Not very efficient, but still it is completing in about 30 seconds.

To my knowledge this is the smallest code size for any explorer, coming in at 600 lines. And you can see the power of SuperNET as when the notary nodes run this, then all basilisk nodes will be able to access all these explorer functions remotely, without needing any blockchain locally.

The timeline is that this needs to be validated, probably will just do a bruteforce compare against a known good reference. Then it is deployed for the notary nodes. Once there, the GUI can rely on basilisk support of this and so the GUI can use this data for transaction listing. Then it needs to be packaged into the installers.

I am also not handling blockchain reorgs yet, it just has a setback of 3 blocks, which should cover the vast majority of small reorgs. For now, if we detect a larger reorg, it might be that we have to recreate the DB/TRANSACTIONS/KMD file

Quite a bit of work to do in order to get the GUI's transaction history sorted, but we do what we must. A nice side effect of this is now there is a publicly available gettxin and listspent support for the coins the notaries are running this for. Maybe someday, gettxin will become a standard RPC in bitcoin?

I did the 9th batch today. For those that get impatient, please realize I am trying to code some important things and doing these payments takes time away from that.

Certainly if there are 100+ people waiting for a payout then I would, but if it is just 20, then I will likely wait. I do not want to do another 20 payouts during Feb.

After the next payout, I will go to a weekly payout schedule. The next payout will likely be processed early next week. Please do not complain if you miss the 10th payout and have to wait a week.

e706793cdd5ca2502b15067c429e31dd64ac37a9f7503b80685118dd3f0f2b33
11472.96269487 <- expected amount REbMisMicS8W7LUqBPJwkVfYHxNfSeW7d8
c742705c385577030a48fb6e6cae157373f39a5330d2536d91c7b9a5fbd8a51b
914.10663775 <- expected amount RKprtuU6cDvhMGPwJAbycWY8gYtyyWrJBV
86edf4d8240f695f1241d317c5b6a2132927680aa2b5022d540f901b40a501fc
840.13904995 <- expected amount R9ctRNEYWbE5zDmT77Xhz22Fr1LpPVj8CG
5b4c1b73e41f8f15f52d86fb53626b9672c49d44bb73dcc618632c4c35b55996
23492.49573707 <- expected amount RWq87C4y7KBfy95otyvkgyCf18LfXV2vcG
38ae41db2fb95299e8201453f17341021ae25ffa28911bf2e68573f07bcbecec
2584.32223431 <- expected amount RC8jWr1QQsRyo1pDkue8AxGs58Wyz4F3wZ
75fe74a840973f2901f6f8b18f6d4191e70c4edd6a2d0ced5024482d2bd218eb
1278.17612917 <- expected amount RQGJHTEwF7TcpCGHCdRZHZVcmngwucWdXX
4fd4a96c77cfaa80cb88e3cdcde880ea1dd15c478f2dbd3bac9cbafd0470da86
17042.34838900 <- expected amount RAuq7MzV7DgjB2bLJJ9LunEj9P3zUMiNrS
166593bf7c22faa0f7d685e5040373362a99b86c61176a59578aca1f67985866
1198.78675406 <- expected amount RWC11HxcX18hxm38NTZ6U5EMA9uSPzTJ3a
8db1f874f62ea9a74892aee5de46e07904c6a328e1d2fb89944c038587086349
952.88812828 <- expected amount RCownUMXktAgPvzwpALnGimCA1RDJoTvx1
91805b62414de7bf4452a827d34dfb797d531e5bd069cb0229028358d75e3a84
6594.40160977 <- expected amount RSk32hhDqxGpFLNXBaza9e9HsSwEMmJJyM
9619461676f16f6d792c02ee1cf2c3c4895088c1031c767263086b3d7ebd744b
9295.82639400 <- expected amount RJyZ9XSE4b18JQWyxPFxTzNXqfkre6aF3j
8bb6c95663c93d5d91a0b9ebbb1bc01d3c8e776c76e9e6b7ecc449a9c4bf9795
30681.77405788 <- expected amount RFkQHrVHb7xiFgjmhz1tvbrYJ8DcEH33ns
0926ad92015e3d3a4313bcc43ae55382b6e0212aaef4ef2629a67f29e39d00cc
257.45731805 <- expected amount RQKz3VoxhXq3aKqx2YLZnFMEjQGQ9ZU8S8
32097e87a4ae016c886035284962c77d755c86717db9fc23bfdb31ec852a1517
1163.91492974 <- expected amount RLHX9dCaUDnvCa7GEragjBJv9wCAXUqfYM
eef0c4739bc5a43997fed140af0d9ec884b232726cab5ce6bf37bf77466c37bc
188643.68073877 <- expected amount RJCBezf4HwreDsMK6tCm5YtcZtfBfeY3wL
4edbfa109229b18d241820c38c92183f87b3a74f7214d6f2470554e483701ba4
99.43583265 <- expected amount RPyKbtBPVb3FYv5iFULNUB6bq9DdvekZuz
e3a2b2d44d9ddb41f8cfaaf3e077409cdb80c3fe6be29b29801d447f36bd73e0
1394.37395910 <- expected amount RPJDJKyCnHUEcSJCXPCcCVgAyYzTJQY9KU
6ffe858cd590d0237468450794fe5a5d38c7074f3e7ea4afaba36f511136557a
24207.88123437 <- expected amount RLi74YPDmXDf2UAiBoTqEwUayqX76cXb3h
3d33a0b167cdad93222d4d349f65b38aea97307e9fd73f230164eea2e2e3d339
17160.85255783 <- expected amount RH7cfyUkBwrLbxfWBggcbV3UgzaAHyy3J8
c0a1609c53754a8c27f1435458f17a0f6c2ca49245929cc90b29a8120efe50c1
203188.29997688 <- expected amount REopaxhMho1ffQ9fpqC6YLKaAS8D2Q2Twe
8cef57eecc08b69ed854d1ea77e7a3968050edd47973a36519499794ee5e5316
2316.21007650 <- expected amount RPD3kfdgogsPGbXefBdRt4QpiDZXFHwqan
61891b96d6e4fcc42a2509618744e19df94d3949a45118a66e00408a052d1d62
968.31524937 <- expected amount RGXyii2bqVefbqGmXtuaG19WQY5xa7f9qH
a1cb58ed4b02702c86dbb8c3a718d8f58ebc36704129618a3926a2e6c2add782
1663.06468462 <- expected amount RG7jKgxwFPKNPy4MFxXaBr7TRDEzR2sSkV
92f853441f10b27af1f7bfa310c8407cf57b787bde24f9c5718f88dd2b412005
929.58263940 <- expected amount RC63RYx695o7ve2fdjRtcXKqw4QwzTjqDn
4b86fcfbce4df5dc114c7ae8a8b12b6897ca3d3a5ccff395d7c668b1caa40b6e
91422.85735610 <- expected amount RLJ1GkGiu9jmDngdzYGNtwWffWkFYKgbuX
55282c7553eb17fa7d74c67aeb112e19effb4930cd8df184e18223dc3d1a4803
693.08132289 <- expected amount RHJ55iWUQNbKcSn8shbv1RbGuip3RSRHFv
c776090ef42630fa404ab43f36ed53b656c9dd69d19f3c5a380ff2939194f160
138920.34502737 <- expected amount RKmZ2U9SYweYcUCuVugKmyfiawpPzXX8JB
4d75910e5b0db53220ca8ebc1ea5e7ee8bfd5b9934ce2fbe65dbf429fc5320f6
9683.15249375 <- expected amount RTUeFxM12wv69Mf5JcXFZGx9qVbGYtPf99
3a3b068904ee87f157d0b3b7f2c7ab7252d0b9be1fcb0178f2bf2bfff04bc344
1422.54025612 <- expected amount RG2cAef3JbCXiQkzPgrqS52HAQrBzJiAy4
137664f7fecf790ed3c944b91870c11206a5e12774716403cee9b66903d3055c
6041.35757346 <- expected amount RLzSA37kWBnxCz3yTspTLg1Y85ai18LZoN
4f489677f35c8c3844e039330310c1e1c85aa41e368ae6caeff517040ed0f773
3571.37913637 <- expected amount REmYfd1MwrYzxW7swvXMMcuKb7u1LFeNHk
4efa01883041a797c20a1d320d36e3a2cff2b9958b28254ed88306a1448b7752
0.29002598 <- expected amount RMuS51q7GuPd2jF8aYmRuD8vAwY3GpjhEB
fc195c8a97098890334c2291229d518cf03156100184dd9bb26fb548630bc387
25106.60529680 <- expected amount RXdBJ5cWDcS38ykuggEQZh3vSztxwmG3ut
0569eae7e77315a56d78fc110d6130441d4fdac9e5fe27d32739055a959bb1ee
48415.76246875 <- expected amount RPm9bzUBbWbhqPdnydRxFnEk5XXxxcdMPw
744f5222411621ef1a9764beda4bd64795269a18759b83ee0d9a442889403a62
2420.78820090 <- expected amount RUoGAwzyNUF1F22TkPq2Jx7cQVQk8Yn6Gu
8463044c21af1d44490760ac94ad05c279716ac8149e4cbf30b42b2ca987c386
6266.60868209 <- expected amount REsjYn44yH4W9JcGiQND95mfJV98jzip9i

when there are two things traded in markets with a fixed relationship, it creates what is called an arbitrage.

So the BTCD will trade at its conversion value, which means as KMD price changes so will BTCD price.

However it wont be an exact price tracking, what will actually happen is similar to a damped harmonic oscillation, where the mean price will tend to converge to the theoretical conversion price, but it will usually trade at a premium or discount. Kind of like a stopped clock being right twice a day, but a bit more as there is a linkage of BTCD -> KMD.

However there isnt a reverse one, so while there is an arbitrage based floor to BTCD, there is not arbitrage based ceiling. This means that we can expect the oscillations on the high side to be a bit higher than on the low side

mostly correct. I publish the verification of payout AFTER it has been sent not before. the payouts are sent to the confirmed payout addresses

Instead of just making up numbers, I was actually tracking the prices during the ICO. The absolute lowest I saw was 6200 sats and that was when someone decided to sell BTCD at 310,000 sats. It was there for less than a day.

Most of the time BTCD price was in the 400,000 to 500,000+ range which equates to 8000 to 10000 sats.

Now if you had purchased BTCD last year when it hit low price of 200,000 sats, that is the only way to get an effective price of 4000 sats, but that was months before the ICO was even announced, so it is not any reasonable price to use for ICO price.

Please let us not rely on made up numbers when making conclusions

Some probably have noticed that the transaction history is a bit wonky with basilisk mode. This is an artifact on relying on the bitcoind (the bitcoind code within the zcash fork) to generate the listtransactions for watchonly address.

Since the server's wallet doesnt have the privkey for the watchonly address, it seems the code that tracks spends is not invoked, even for an address that was specifically imported. So there is no mechanism in the bitcoin codebase that I can find to answer the simple question for a watchonly address: "has this txid/vout been spent"

Considering the importance of knowing this, I can only conclude it was due to performance reasons it is not enabled.

Anyway, what does this mean? It means to provide a full history, I need to add a full cross index of all txids. Since komodod is essentially frozen, I decided to put it into the iguana notary dapp and will make it a network service. To write something like this totally from scratch would take weeks if not months. However I have done this so many times now, I was able to code it up yesterday and debugging it today.

I have added three new dex remote API: gettxin, listspent, getbalance
in addition to creating alternate form of listunspent and listtransactions

Getting the latter to be 100% compatible with bitcoin syntax, will be a bit of work, so at first I will just put in the important data and let the GUI special case it.

Also, for performance reasons, this service wont be available for BTC, just too much resources would be used, so if you use iguana for BTC in basilisk mode and want a full history, you would need to rely on blockchain.info or any of the other public explorers.

Not sure how long it will be for the GUI to utilize this, but I hope to get it into testing this weekend. Also, once this tests out, since it will provide a full block explorer level dataset for all addresses, there wont be a need to rely on the watchonly functionality of the bitcoin. That also removes a possible issue with notary nodes resetting wallets and losing the list of all the watch only addresses.

look like there will be enough payout requests to do a batch tomorrow

Thanks! This is exactly the type of feedback we need

There are not so many payout requests yet and as some have noticed there could well be a new popular destination for payouts.

If it is ok, I would like to defer the next payout until we get a lot more payout requests.

We are in the process of getting insight explorer up:

http://kmd.explorer.supernet.org/

it is still brand new and might have some issues still, please post any discrepancies you see between this explorer and kpx.io

OK, we can do that as it will be some time more before boogieman gui will reappear

PM me address and amount, but nothing else yet. I will see what i can do to solve this

you can request a payout direct to an exchange deposit address

As some have noticed, zcash now has a windows build, so it is theoretically possible to make a native komodod for windows.

https://forum.z.cash/t/zcash4win-beta-is-out/14155

I like to turn theory into reality, so on the same day the zcash4win beta is announced, I would like to announce that komodo has retained radix42, the same dev that did the zcash4win, to make a komodo4win. I dont know how long it will take him, but retaining radix42 is the best way to get a stable komodo4win sooner rather than later. The agreement includes one year of support and maintenance, so we can be assured to have solid support for the Windows users.

zcash4win has SwingUIWallet wallet in it so I hope we can offer it as an alternate wallet people can use with komodo4win. this will expand the wallets available for komodo and for people that want a simple GUI without all the features of easydex, they can use a simplified GUI.

I never received any PM from you, unless you used a different handle.

Please go to supernet slack and get realtime help there, instead of forum where it is not so easy to get all the info needed to troubleshoot

Sure, give me a good place to donate to and I will as I always do

Using notary nodes and schnorr partial signatures I could do the tech, but it seems that there is a large marketing obstacle and we just dont have any gigantic marketing budget to convince people to switch to the new BTC

So far, it looks good, but until we start seeing a lot of the problem transactions (I think the asset exchange ones caused the most problems) and a few more days of solid running, it is too early to say it is stable.

What everybody can do to help is start using HEAT as much as possible. Do crazy things, make lots of transactions. push it till it breaks, or doesnt

mainnet ALWAYS finds something you cant in a testnet as the real world has real people doing real things that is impossible to predict

So HEAT is certainly good enough to be using and everybody should use it, and I dont think anybody has lost any funds due to HEAT blockchain issues, but of course be careful and dont do anything silly. Crazy is good, silly isnt

I could make a BTC assetchain, it would have 20x the current capacity due to faster blocks and 2MB blocksize.

The problem is there is no provision in bitcoin to unburn, so the bitcoin deposited would need to be held by trusted nodes

MGW is essentially what you talk about from 3 years ago.
If bitcoin would add an unburn code, then sure this can be done securely without any trust needed.

But bitcoin cant even do
#define MAXBLOCKSIZE 1000000 2000000

without taking years...

For the record I would like to state that I stayed up late (past 24hour long day) to help get the HEAT chain back on track yesterday.

If you have been paying attention, HEAT has been forking and looping and at first it is most vulnerable to such things. The safest way to get a new fork solid is to generate enough blocks so other nodes will recognize it as the right chain. To do that an account with enough stake is needed.

A free for all start to forging could well have created another mess and that would hurt HEAT quite a bit in my opinion. At this point stable block generation is the primary thing that needs to be achieved.

Did SuperNET unfairly get a few thousand HEAT due to it having enough stake to be able to forge the new path? Maybe if there werent these technical issues like there needing to be a stable chain, I could agree with that. Even though that is not the case, I will just burn the rewards during the bootstrap period if that will make the trolling stop.