You are quite mistaken with your entire post. I have my passphrase very safe in a remote offsite location. As this post proves. Anyway, I am locking this thread as Komodo is the new BTCD and the coin for the SuperNET originated ecosystem.

You can consider a billion dollar ecosystem as a failure, but for most people it is actually a pretty decent achievement, especially considering we are just getting to where the initial iteration is completed.

KMD thread is at: https://bitcointalk.org/index.php?topic=1605144

even if this were true, why is HUSH trading well below ZEN?

Of course, the dev roadmap for HUSH is in good hands and at the least, HUSH should be above zclassic and zencash. I believe HUSH will rise significantly higher than the current combined marketcaps of all three, but that's just me

I officially confirm the jl777B account is mine. I just have two different computers now and have a different account on each one.

currently from dPoW notarization fees and PAX fees, but in the future any new monetizations that doesnt already have an asset for it will flow to crypto777

With David (radix42) as the lead dev, HUSH definitely should not be trading below zclassic. HUSH is not just a zcash clone, it has a roadmap to add key new features like Counterparty. Also, David has been the go-to guy to get a zcash fork working with Windows and he did a fantastic job for Komodo.

Recently, some of SuperNET investments like STRAT and IOTA reached full valuations so I have been diversifying into promising new coins.

Similar to buying zcash when it was a fraction of XMR marketcap, buying HUSH when it is a fraction of other zcash forks doesnt take a lot of courage.

ZEN is subject to replay attack and its lead dev bailed out. Yet ZEN is trading at many times the marketcap of HUSH. Is the market right or is this a case of market inertia and mispriced coins? How often do you find a coin on the third page of coinmarketcap, when it belongs on the first page?

You can see that I bought some HUSH:

http://old.supernet.org/nav.php

HUSH is now safely in the long term hodl portfolio of SuperNET and I look forward to working with David as HUSH roadmap is completed. I will be adding HUSH to the Komodo native DEX so that soon you can trade HUSH without ever losing control of your coins.

I dont usually post in threads of other coins, but I wanted to announce the HUSH addition to SuperNET portfolio.

In the past SuperNET had to overcome many obstacles just to survive the bear market. Now the bull market has helped us achieve: http://old.supernet.org/nav.php

If you notice the coin holdings, SuperNET now has over 1% of two top 10 coins and reasonably liquid holdings in excess of $30 million USD equivalent.

We had been operating on a tight budget due to limited funds, but now that our funds have multiplied, it is time to expand the budget. Also, the tech is now reaching the initial release stage for JUMBLR and also DEX, along with migration from NXT assets into their own assetchains.

I would like to announce an active recruitment for a fulltime team dedicated to each of the SuperNET core assets: JUMBLR, DEX, PANGEA, BOTS, CRYPTO. Initially we will focus on the first two or three that are closest to product release.

Approximate budget for each asset is $1 million USD worth of crypto. Which should be enough to pay decent salary and marketing costs for initial launch. After launch, the goal is to get each asset self-sustaining and to generate a steady stream of revenues for its holders.

If you are interested in being the CEO or lead dev or marketing for any of these projects, please contact @pondsea who will be coordinating the recruitment process.

At the end of the initial product release cycles, my hope is that SuperNET will start trading as a high tech growth company that happens to have a large book value in liquid assets, instead of as a closed end investment fund at a discount to NAV.

Also, this is just the halfway point (approx), we are in a marathon and still have a ways to go before there is a fully decentralized automated money making machine.

It is interesting to see a lot of my ideas from years ago being duplicated in different contexts and raising incredible amounts of funds, based on whitepapers and not any working system. This tech is not easy by any means and has taken years to get to where it is and likely a few more before it can be considered in maintenance mode. I am glad that we are finally moving away from the pure bitcoin clones and now there is a very large spectrum of crypto projects and all are able to obtain the required financing.

The landscape has indeed changed and we are on course for a truly decentralized economy that operates in parallel to the fiat economies.

Exciting times ahead.

In the past SuperNET had to overcome many obstacles just to survive the bear market. Now the bull market has helped us achieve: http://old.supernet.org/nav.php

If you notice the coin holdings, SuperNET now has over 1% of two top 10 coins and reasonably liquid holdings in excess of $30 million USD equivalent.

We had been operating on a tight budget due to limited funds, but now that our funds have multiplied, it is time to expand the budget. Also, the tech is now reaching the initial release stage for JUMBLR and also DEX, along with migration from NXT assets into their own assetchains.

I would like to announce an active recruitment for a fulltime team dedicated to each of the SuperNET core assets: JUMBLR, DEX, PANGEA, BOTS, CRYPTO. Initially we will focus on the first two or three that are closest to product release.

Approximate budget for each asset is $1 million USD worth of crypto. Which should be enough to pay decent salary and marketing costs for initial launch. After launch, the goal is to get each asset self-sustaining and to generate a steady stream of revenues for its holders.

If you are interested in being the CEO or lead dev or marketing for any of these projects, please contact @pondsea who will be coordinating the recruitment process.

At the end of the initial product release cycles, my hope is that SuperNET will start trading as a high tech growth company that happens to have a large book value in liquid assets, instead of as a closed end investment fund at a discount to NAV.

I apologize for not being very active in this thread, but I have been quite busy working on the various parts of SuperNET all along. Also, this is just the halfway point (approx), we are in a marathon and still have a ways to go before there is a fully decentralized automated money making machine.

It is interesting to see a lot of my ideas from years ago being duplicated in different contexts and raising incredible amounts of funds, based on whitepapers and not any working system. This tech is not easy by any means and has taken years to get to where it is and likely a few more before it can be considered in maintenance mode. I am glad that we are finally moving away from the pure bitcoin clones and now there is a very large spectrum of crypto projects and all are able to obtain the required financing.

The landscape has indeed changed and we are on course for a truly decentralized economy that operates in parallel to the fiat economies.

Exciting times ahead.

The explorer is not aware of interest, however it calculates the txfee as:

sum of inputs - sum of outputs = txfee

Notice that if the sum of outputs is bigger than sum of inputs, the difference goes negative. For other coins, this is never happening, but with KMD it means your outputs were bigger than the inputs due to interest. The actual interest amount is even a bit more as the real txfee was also covered.

As far as the difference in interest goes, it could be that you still have some utxo with accrued interest. If you do a listunspent command you can see an "interest" field. or a "getinfo" command has an "interest" field for all the utxo.

native mode komodod has the definite answer as to what your balance is for the imported privkeys, just do a getinfo.

It is a very fluid situation, best to join #tradebots

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://bitcointalk.org/index.php?topic=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

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 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?

No, to the contrary there is much less centralization with KMD notaries as all the notaries have equal power.

Look at: https://blockchain.info/pools

Notice the top 16 have well over 90% the hashrate.

So which is more centralized?

http://old.supernet.org/nav.php -> NAV over 700

I have been buying SuperNET at below NAV for years. I like the discount and it also provides liquidity to the person selling.

What almost everyone didnt realize is that the stronger KMD is, the more it helps SuperNET. Having virtually all my major positions kick into high gear didnt hurt either: STRAT, IOTA, KMD, SYS, WAVES, etc. Even the little HEAT is starting to register on the totals page.

As far as the long term prognosis, what do you think it means when the issuer is repurchasing on the open market? Finally, the initial assets are about to generate some revenues. Not much at first, but have to start somewhere. Over time, SuperNET will shift to trading as a high tech growth company with a large book value, instead of as a discounted closed end fund

The blockchain was not under attack, it is similar to a DOS attack at the network level. Still not sure exactly how a killer packet was created, but a fix for the crashing is already updated in github. I estimate about 10% of nodes were affected.

If you are having crashes, just update and it should be fine. We are still testing the hotfix version, but the change was very small so it should be fine.

No funds were at risk, just annoyance of having to restart a node, but if you are in the process of syncing, it would likely make it much more difficult to do so as if it is crashed it wont sync.

We have detected some sort of remote packet that triggered an assert (which stops komodod).

It could just be some sporadic thing, but it is possible it is a deliberate action. The effect is that your node might be stopped and you have to start it again. Annoying, but since it might be part of a two part attack, we took the precaution to alert bittrex.

We are working on a fix and this doesnt affect trading, just deposits and withdraws.

So, if you are hit with this, then just restart komodo. I estimate about 10% of nodes are affected. And 90% of those are able to just resume. If restarting komodo doesnt work, try loading it in gdb with a breakpoint at main, and then continue. This works around the assert. If that doesnt work, then you will have to wait for an update.

A proposed fix is in the beta branch now, but it could well require more changes as we just started testing it.

a much more complex protocol is needed to atomic swap without segwit

18th payout is complete:

ba323d890f61499cd6f0063794d584c42e1aae4fb37a8ff63fdac6a05b02cd67
108998.28313606 <- expected amount RCJHEogA7SW6PxuctPLtaVnXwiu49PyZY8
06dc0290c9f65464dff7df9191b18ec8b0d5f99affd6f7af66e999415bdb7d48
196.34763557 <- expected amount RDdUQ5t6SYYGZUdAxBk5i7QdTWvzAshxNZ
e7c27c1c681e4d7c8264aedebbfd2ff1d72ba7c2291909eff7b7a40bff197a84
14524.72874062 <- expected amount RTdb8aKy9UyhaQhN4XzMxG2AhR6HfZ1ATU
c83b67431f0201c1ac968f82dbc267cd66ba171c31dafe0fe2fe662b86d5a17e
16017.97255691 <- expected amount REVcoi6A4GRfuchCXTwBTszbakhoh9inLs
6de5758956e3838cff795c9d9d0e3e172c9790fcfb74fc6b7be78e51a2bacd72
145928.92215821 <- expected amount RND3dLBRRvqqCGw9Pe2c2VT68ognGA9h22
ebe5f1ed70e1fd2119fc00342dd234c97752ec84587a351d27b5c305ec95cf22
114940.35721379 <- expected amount RUMinvguFQSi3j9viHRpdocppdZ3r1SUj6
d7c1c7f667aa2db61b7d2687d4dcd201dd6ed51df46dcb9d11339e853050de96
28699.34324752 <- expected amount RVYZtHbqWg27o8PDVc8DiwxnuEw2pdfoDU
66a57e792dc943488b3e92492295345cd5427d50d8f1b9a55bda8b5e2f947e3a
101090.11347764 <- expected amount RV25zizocv445ht9My45WaxpGuAC42cxLa
5462603741b92727e5886d616d47755818131540dcfa214343cad0d1db8b96a6
1704.23483890 <- expected amount RQJgyjp5MbTA6QBnDBB4gQgUkDwx39Wv5S
ff22203b60e409224fd91bcb14bd94788ccf48fea34303165871591b7a06b2dc
96831.52493750 <- expected amount RBoQRMAn8txSuC4n49V5sYXofMeYwacvnD
33381c89806157ff2b2e14fa89b9e65d168ea82deb959ae62e28ced3e3208175
11.06362104 <- expected amount RQDJUGS4uAXSMasPLCSfWCYY3CEUQ8C1Ve
db7fd99299d947f652835f070526f6bdf08c9ff9a7425e5b22b2c9443a4dcd13
32009.28059927 <- expected amount RJS6WdJgYh7RZQa1UsR6zN4EM6c1AB9fwv
fef7f866940e790a332b6a9cb5b25da7175bf2d81a7df259d4055b052f363a64
305.48459176 <- expected amount RStHfZ1ZkPmg5aA5ZinoadfGd3n7p2bYuh
09f9e5720c9aef6ceba3b88d0d82e60c5c3c06ab6006e78cd7fa41fd4f226678
162977.74808228 <- expected amount RGDscrxo4txwMjg3DFxD9WQmsoqv54L5A3
46f49312acb1ce8e11389d4bc5806d9ce557f4814aaf12a11dabcdf7c524e43f
9683.15249375 <- expected amount RArc3Gr7t5CfmqC4sYbJp9FHe8VbLiA9Qn
c0c51db261ce3d0b957073ee40c4e763a6be4944b02ee490e5208694ea151f12
1593.10203942 <- expected amount RGcAkUkjGzbYDZVWwM6Y4v8KVWrjqeimw3
2eaa40eae0e1f704c38b7c2c436b4bed1be6972fb9d33a6cb04f38585f74b1c9
4066.11066256 <- expected amount RFzRMuvV81ARPU55NhnkBRD3yi3znXG7tu
7ec37d306496bff1541197d1afad3f6c7c8647e5f283a6d0516d337bfb5468e0
4014.80536992 <- expected amount RDqVPXmcky1tueJ6tzqUDMv1o3NBCB3xvc
e8ac9703858fe135ebb1ed5f5cc7f20563e2560d8e4541bdfbbbfa7acfcdfedc
2904.94574812 <- expected amount RNoaDacQgoYifqagidpsMqTQ74t5QxDWXd
cb21e500825041fd9a666d0231164df81b5d45c244aa444761771a764ecc03d6
38080.08587787 <- expected amount REeJHDzfSqf58Br7SgNJhwYwswNgP9jjrc
114f283a976ccbdc349c531a081ddc3919475c54aa9e9c6b06f36df14e53ff6c
875.08198390 <- expected amount RMAqR1iFUMkojtqaWNf2gThH3NKSey4yZ7
84b2b4c375ae3b22789437041f98a21658465b50a2d569fc00300acb97c20a18
9683.15249375 <- expected amount RULousSwdVGhaP6vusva8u9AQWTs8ugjfp
eaa0c2911be48d5cd1d0415ebec4869b0a42bb11f91b4bd46a296f687073e636
2954.24166783 <- expected amount RXGs9paVUE6cYE7UdEyTBGeQCcyXqJbuRK
745a44099060b7e406c3d3423252b7805ae797bad62e019ff5dc8957d4481077
35716.07599193 <- expected amount RXcy9GwSCmd5RRsZfuMxaa6GpHqetmrPGU
9bb6606a222fc4cc72fb0f30563ba58027fcadb0a9d850616a2da12a621c19a1
1681.36207445 <- expected amount R9R5HirAzqDcWrWGiJEL115dpV3QB3hobH
84b3b246e7704df4a502748c079e500045a5480fc93da5e3040f8bcf633e3546
7119.36644540 <- expected amount RBCjXdMgAVP8NopCBk5bsCUz5ZFev6s8gJ
a21df452b4188e436241160c9ea5022b0c4b5e77a8ad424254a08ee83a7adb05
29049.45748125 <- expected amount RUM2zxUvxwGVErZ8QopcJD3uGaR7tmxxNV
5d31f249fb7e26ccd5e1c1894cfb0094f4e6fffdf92b4021b1e4c123ff00d7ae
216.38341633 <- expected amount RUBFFG9jXRZMrqGsbTcCYmXccF1C8BiDLG
3b8db190bb0b95f11bfef44c2d5408697cc752acd2b6abde72473cb85b90f207
3239.94057692 <- expected amount RWc6GouJggQDsBCeW1DYck629FPrDJCTP9
783bd6226cf64a1a2d81b5315b6162c4a6ca90e31141154fc0ed001529dc2f19
723.21529345 <- expected amount R9TmkWG5UwwgLeg6vvtLA234gAiYeE2fJY
25f3222f22e03a22cbf86038f0357797113aaf3682574a88171b5052a266097a
20415.81928042 <- expected amount RP3ND8ZShCHMnnDeTcLXxdzndTNQzpUSXd
c1d470a8e860f4068026f13ebe288e8c1337b8891cb5aa1679cf070b33f0d4fe
4319.48050817 <- expected amount RMgsHEcKzg5n5NkHs5jz4hVg7avbYsct63
8a51e7287b25d443d6ff720d381f7323babf3751beab6bd61124745ea2468d09
155.08169171 <- expected amount RRFpb6JQn6jrZbPiXq7C3rWfnPLjeyzFE1
1b7b4e019a43cf557155ac34f38d45c106fbe7978f6d004b99f31170588f829a
5177.29144163 <- expected amount RKjRhiPHQJEf65CwXTjBHLQ5r2fKfpeyBC
495d675297b088236e0220ecf01a429d6ccde82d177946ba7b139e131417b472
2034.11335616 <- expected amount RFyRXwf5TyqLM5vJfa5k2dCub614tQKKGS
ef0490222f0a2874a662be193f6d5799fbdebd008f260f7f49bcbf9b89ceec5e
8034.62340879 <- expected amount RWR94SErHZAZXNgKrhYrPAaiU6FWVagZSk
09a7422b39a14edc61059a7b03096d1912fe0455a950632daf5f97753875429b
987.78018920 <- expected amount RC8LVu8PejVfzpRQ8bDXxv9jMhur3K9ErW
e29b46c9bd55f667759cec69094d0cfae4890f281134a2150d2ebfd1ba8305d4
98.35737149 <- expected amount RSxZyyY9ok8ciXJysU9eYhoQsFbozwiZZM
344e9b43399a9577903c86f02eba20322ecbd126b4083f0449472dddc06d5f32
8442.69675032 <- expected amount RLyaf3XgjHruSeJd4oj83E8btck7kYPmVz
639225d80956da321247d9712357580f96cd44c5f626912855281517eea6307f
35.32468867 <- expected amount RTtd8gWY1Yu4fWz89kjdSZCpzaWdnK5sYU
380ca6d111521eca73f2a4fc4afecc4264a4e1ecc7fafc8ec8a25b3de98292a2
2418.19228276 <- expected amount RCAtTmppsyCrsEYoxpLCANGzCVJwJfcfww
793c41cfce9db6db87040b7bc6a9140e180153529a3207183ff8b07dfde85f6c
34.72735411 <- expected amount RHMvt73J6AV2sQP6at6pgQcdpywQFrZABb
e66a51afa982d4935c944895aacfc6063accc03ec91416acc7529851a03b7afb
49.50870613 <- expected amount RTVfykmTFwn6XyuDGSAKp9UK4oBkwfr4JZ
2d87c88e2471874ec7383549e13e3de23e215ccef5ffdd785aa3292e8ce9f002
9683.15249375 <- expected amount RB8pkhY441oNYqJYtbWVmChZsByDsHBiKQ
caa48f7f4eda6d085cece55c7cef9161caeda77be8c40c1d37a61cca2e4dc2eb
56.66050704 <- expected amount RT8Uis8D3jusKUoZVru3DtHSnfSqHHFe2u
54e586e51a3c32f76211947dab6d32efea31e75226cfe0b0f9c4e0497768d9d0
722.28571081 <- expected amount RDJg1f9tuySVCvjZVUbFXhhG2ikM4hft74
d0ed049da92ab135f7285d4765c5cfe4e96a78ffc9c766d89bd6ad50ed2a6186
226.29998024 <- expected amount RKuUZDDjHb3SfbZJJMic5s8mq4f8LKzz68
e0ecfd63e44281ba7cfd21b2a6b4009c80cd3fa79ed604fb9076a6503fed7435
1160.04166875 <- expected amount RG9EcdLkQvWmNBNhLvqgNUNA9XCmvBtg4P
bcde4b36642d8b12d5ebf99c746b5c10e330a8588624769d8ee1293bc2873304
5365.78339027 <- expected amount REuh3kBhL3J4wFqoezgm5sH4CcZAivmwv3
a7a25ee8de533a359daad4675787c037af8e3cbc1f629fbe7aa625b0b2b7712f
9683.15249375 <- expected amount RDx1Py1724JGmq9PZUjxb8117h7Traw8Ab
937b10d1dc1decbcbf7dd144936492e4dc4ae81e87df10fe4c6dc28f7b0626d0
2475.13554655 <- expected amount RXGNx35hp7uZL6g19AWmQv3BuF5xWvrNNv
497e5c65f23cae9db51a591ba0602a020c948177d16b7daa6bb3e9d1241d0671
6778.20674562 <- expected amount RACobrNdsFuWFiB9ZtYcj2RFUUKZ3Y1tGp
a58eb5fb80065f3756e6dcaf870c8a8d2949178e136302159bbc329668537e28
3898.73512521 <- expected amount RLGFJUBLHCiGinRUM2qJ1YRKWNunmYKBoh
b730227ef133bf8327af2c82a45fbf9180574c8084c7fe9aa46c249b1aa8acf9
18775.43011383 <- expected amount R9QFWSLfYM22cTYxxDKUdvdxFN2UDByijJ
b893f3d76a7c3cb7fc4a519ceeb24cccece9a3fa438ff6d60b79be235e51f233
49.27663407 <- expected amount RK3mfPzjv4XmPmNboLagSrV6dUKmkwvSRL
f862ff453423390e0cd394d7d0f10777b504f901fac747a99b4b1464846dfc5c
1177.96870224 <- expected amount RABX76mRux6dbADB2mM6F2gUbG1a5m1TH3
3be22040e7dd7053bcac390d933daaf0650356403658befa0a6a3a031977dac4
3692.18604586 <- expected amount RMi53BdThuz7UA8jbJRLC6y4YSGzjP8yPW
d06a1feeffd7d4779620cb32ca42ae94c1cb14135a9c924f910cbeabe747c752
422.98413624 <- expected amount RY69roX9pRXdH3yeF8WMFUDWFEoEdWDn5S
efe469bb315a7cb53c001e37de663804af54e0e90c38d53c4b8a97153d1736eb
428171.85680159 <- expected amount RSPk4oi4dfq39LtrHucgaQLNfqcRc2vEvk
73b20d7e806bdbecccbb8d9a7745506bffb29cf3e62aeeb7fb9c16cc08854400
27228.79164783 <- expected amount RMb8RPMeah3DF62p16eHALFBZ2KrhUsMuB
51721f48b396f24052d87b4bebc2ab2a4e8ef2f6eb4659d8dbb43d2d32abb16d
6109.56883640 <- expected amount RSEdLeDWTWdnFK4w8NZSNMxx7KTeTsaycU
11c56014452747c7fc9a10471a44ae0fdb7b536728264257000d2c0cb630fb95
316058.09739600 <- expected amount RJZcnvtoZ9waY56kZou9jvHQVjXRv6aWGN
63a45f23a19d85bf49ee464e2c3c5d6180d99103872b10cd3cbf7581828003e2
51229.88531218 <- expected amount RP1h1V7cwz6gkqEm1cNdhzbYdTuRxrj5AH
ff9b52785ee748333201b943f204bd8b2dceb75b006d52281c150089ba8a3022
110083.51536582 <- expected amount RJsu52kYvdGzSZyxY53vJiUx7EkLtYof1s
e21dd8904129f39c216db219028b52c8b62dab2ab739961c6e992f06834e0c56
9295.82639400 <- expected amount RGZUWVDbeNsBknJuqS4oaF9q4k5ndwo9KX
2b8f897016f503c6ad66fb8da9373cca08a5f643ee9aebe1d09622242314c5c7
2611.69343481 <- expected amount RM3onNDjZbjypoN8wqo7Rzz3QEv6EiCfwK
0ca1444b07b0b7adf019f0439c0b21135e79a6fb7a8d99809e7e3d1deea5f2b0
4841.57624687 <- expected amount RXPyGtmWdGeAYLBm4TdfrQW5AUMjCxziVs
a4778ef160047b1b69946df0427691b16c93d576b203b3b053b86ccbed26828c
813.38480947 <- expected amount RRfjHMdC59DDDFWAmcD48USzX6T6QKkfaW
3eb789fa6bc552b76c63876951c0c26b1ee52565825d175d538094d273f14d30
20170.43419449 <- expected amount RLFkkg4L1HxiVdZna1VMQHYhSSmpXqMyZH
af1c11869acfcdff7107b0ffdb30ce36ce0d6bb383ab6d752264a81ef6368214
681.69393556 <- expected amount RM73efhu5ED4T6DYi3PZXJCiwmkHABNafD
d4ac3f76c4675a55b2bae76c50fbf41830a8f6dbad6c62f276a68bd1085a6fcb
1510.02573700 <- expected amount RQQtcWoGzkTfbD3TPfUMNyLeqhge8bJdim
bd70b040505c3a54ee08a3695a06b800ed63d75760cee6260f6830bd54dfd327
693.08132289 <- expected amount RHJ55iWUQNbKcSn8shbv1RbGuip3RSRHFv
44e1aa3df3074e63e72fea827bebde7569a7481a4d92b524e03963675836dc7b
842.93959567 <- expected amount RUKkv5Fz4LuWVVkjLiA5m6TWkvqt8h1kgy
ed9704737e6413443558978962ab4cf5b037091377065406695d165510a2a0c8
1580.29048698 <- expected amount RX2SkGDAB9aANzTQe3DWqtjNv8rszmo8Ue
2a67d5068811e115fb8f931f2f2ef3030a70c1c9d10e7adc458ed34908336515
2904.94574812 <- expected amount RGH1nTajxYK6pYJzJJvj4g9a6QQ8DLCdFN
c6373ca5e9b040dd13ade66ed0f1e0207e51ab1f2690abd2adaabe8809e8e860
594.35547049 <- expected amount RTREfp1yUnazmJi4KWzy7tCN8UPXHNoBwX
8c33daaa606b622984df79717cd82d9190afabb5faa1ef8b1a53bf59c87c1e22
929.58263940 <- expected amount RYLt5Ui2QpCAB7QMJYgHYDEx7T9v7MohKE
f07c11445a84394f349af818d9ae53d379c81848d176059a6592c319046935a1
95491.01211941 <- expected amount RTfaPuVrwm9pvYHWskyyxJtRbhk9GnMRXP
b87c50aef85154f6470e29a1282b36015c81a698d3466ec6b9759665b651de77
2631.59182505 <- expected amount RDkKfXfzCb5kimNFymXbWwbn6hGWtaRoqY
3406d87a690255a7fcfb7d166d001f20ede8c6d4f5ab41f4ff0ec904729a4758
5701.16057828 <- expected amount RJVPgswKQzcWxHB1Woin6QKpPVYRpXVoFn
c9338ac206f44a2e265b118cf22d635d017ef6080bcb80f56caae45ff73779a7
49.10934879 <- expected amount RCpUUnr6d8zei1oBSu4hSeWU9m6eVEig6a
58d0bc32b23acbcd03015939e21f910f8c38714d19f111e6f1cca75ec9f6d3cc
911.94644914 <- expected amount RH1ZmVCNRmnwrVuLiXN5kp2Rw11kkMEhSR
3b7af615d127c96371f24d71feaca678a1f12bd4f68e4c364a4f90fdbd26936f
2169.54630422 <- expected amount RUUH1M8rdBbiiaKHDFwvQgaStgchkJunGH
c02d9679af4b22c78f5709c1ad897f111ae71e800f83f3f2149543a229cad16e
12470.86256471 <- expected amount RJW64iw5NsX74TZUi4Ngx7j8v2AHRPhKEi
ecb226c37a0a708aa2d8df72b1169243e3ff254d67301e182000073b107b9e77
3365.89754092 <- expected amount R9rw4XnwfkQybdrVru9hPmg7n7JdDFkkLj
da30f1b505f3fe4b81c667ee6e1d25d3c7439ecaa67b9c2d2977eb9ebdd3a0ce
511.26690948 <- expected amount RLHrGiqRbVsDttjFqVVSkxCzn2QpH4VXkv


next one is the first friday of July

It was completed long ago with the Coinomat card.