posted technical updates: https://bitcointalk.org/index.php?topic=1605144.msg16245305#msg16245305

I forgot to mention that I think I have the bitcoin backstop protection hooked in!

Just a stub and wont actually do anything until I get the messaging activated, but given a dataset of notarized blockhashes, any block that tries to replace any notarized block (or earlier), will simply get rejected as being an invalid block.

To my thinking, if it is rejected, then it wont ever be able to trigger a reorg of any depth and when the first non-notarized block along that reorging chain appears, then it would reorg to that point.

For dPoW the bulk of the work is in the voting process to elect the notary nodes and getting this election result properly ratified and onto the blockchain. Without a deterministic list of notaries at every blockheight, well, let's just say that we need to have a list of notary addresses that can be precisely calculated as of any blockheight. Not just in realtime (that's the easy part), but at any time.

Given such a list, then the data needed to verify that the notary seal is valid will be available.

I am fixing iguana bugs as the top priority to make sure we can get a stable release out sooner rather than later and only working on the dPoW coding after I am caught up. Sometimes the two overlap, ie iguana support for TAZ and KMD, as now I can integrate iguana into the notary nodes at the localhost layer. This means they dont need to be compiled or linked together and allows for a lot more flexibility. It also minimizes the chance of any bugs in the iguana codebase from directly affecting komodo. We have been testing iguana for a while, but it is a rather large codebase and it is better to design things to handle the iguana side dropping out.

With komodo relying on the equihash PoW to make blocks the old fashioned way, as long as the presence of notarized blocks can be made seamless, then we get the best of both worlds. Enhanced security when the notary nodes are up to date and current, normal security when they are not.

On the other side of iguana, I added support for syncing to TAZ (zcash testnet) and KMD (komodo testnet)

Due to the protected funds, basilisk mode wont be able to work with them. Also, iguana just cant handle all the zkp code, so while theoretically it would be possible for basilisk support on the transparent output side, it is not a priority for now. That will have to wait for new staff that can work on extending basilisk to the non-bitcoin protocols.

I dont yet interpret the protected transaction data, so the account balances will likely not match for now.

 

you would need to git pull the GUI repo to get an updated html

maybe in the future we will fully automate the process, but for now safer to manually add and test new coins as they are validated.

Of course, if you just go into the GUI html, it is easy enough to add a new coin if you have all the magic parameters for the addcoin API

On the iguana side, I have basilisk mode into testing now. Basilisk nodes rely on iguana full nodes to provide public information data about the blockchain. Currently the following remote calls are supported:

getinfo - returns standard getinfo
balances - returns the balance and listunspent data and spend data for array of addresses
value - returns the value, spend script and unspent status of a specific txid/vout

It might not seem like enough, but from the above, a basilisk node is able to construct a functioning listunspent and from that it constructs the higher level RPC calls, such as sendtoaddress. All the signing is done locally and each vin is verified with multiple peers to have the correct value. Since a spoofed vin will either just not get a valid signatures, the only damage a hostile node can do is provide an unspent with an incorrect value and making a baslisk node overspend. That is why each vin's value is verified as a final step before signing.

I have 10 servers running BTCD (most of the time) as a long term test to make sure they all stay in sync. I also am running a pair of servers with BTC, LTC, DOGE, SYS and GMC. So those coin's should work in basilisk mode.

Current GUI mostly supports basilisk mode as the API is the same for either mode as is the RPC layer, however some things like sync status tend to jump around with the getinfo data coming from different remote iguana nodes.

As soon as a new coin has a few iguana full nodes running and connected to the supernet, then all basilisk nodes will be able to add that coin and have a local wallet without needing the blockchain locally.

I started work on the komodo testnet yesterday evening.

Testnet is live.

https://github.com/jl777/komodo

the end of readme has the instructions to get a komodo TESTNET node running.

The coin supply is changed, and the ICO allocation is done with the first mined block. This minimizes the code changes needed to support ICO purchases stakes as they will be distributed via normal payment transactions.

Currently it just has the hooks in for dPoW, however the mining reward is set to 3 KMD per block and due to lack of nodes, the blocks take a bit longer than 1 minute, but with more nodes it should end up averaging 1 minute.

It is running in the no-notary nodes fallback, which uses the same PoW as zcash. This ensures that no matter what happens to the notary nodes, the blockchain will keep advancing. When the notary nodes are present, the blocks will be more regular and it will provided the bitcoin enhanced security.

This testnet is subject to being reset at anytime (already did that 4 times), so if you are running a node, please check here to see if a new testnet is live. Also of note is that even though it is a testnet, just use the mainnet settings for the builds. There will be a new genesis, port changes, etc. prior to the real mainnet.

Since komodo will run with a dual method for block creation, when the notary node method is ready, it will be compatible with the prior blocks that just used the PoW method. I probably will have to make some breaking hardfork changes along the way, but it is possible that soon after the official zcash is ready I can make the actual komodo chain live.

For now, I want to get the process of going from the zcash pure fork to komodo solved, so there are no surprises when the time for the real mainnet is here.

I want to make as few changes to the zcash baseline as possible and so far the changes have been just to constants, strings, "komodo" message, and an if statement calling a komodo_blockcheck just before the equihash block validator is called. Of course there will also need to be a change to the reorg consensus code to check for notarized blockhash, but with the message handler and the block check handler in a komodo.h include file, I can code in C all that logic without getting slowed down by C++.

You can already start testing the zero knowledge protected transactions by following the instructions from "Getting Testcoins" section in the middle of https://github.com/zcash/zcash/wiki/Beta-Guide

The komodo addresses use the same prefix as BTCD, so it will start with 'R', but the protected coins use the same prefix as the zcash so it will start with 'tn'

If you need some test coins, just post your address here

If BBR can support a 2of2 multisig using secp256k1 pubkeys, then it will fit into the DEX atomic swap protocol. Not sure the feasibility of this, but that would be the easiest way to add non-bitcoin protocol coins

the odds are theoretically the same regardless of how it is split. however connectivity issues might make it so it is better to have multiple utxo so you dont miss out on a block due to bad connection

however, the notary node staking will have priority, so the single large address balance will have the slight edge as far as compounding

There will be two independent ways of staking. The peercoin utxo based and the chances of winning a block depends on the amount of KMD in each utxo along with its coinage. The older it is, the higher chance it has to win, so eventually even small amounts will be able to win a block. Of course, a 1 satoshi utxo will probably never win a block, regardless of how old it is.

The issue of the utxo based staking is that you need to have many utxo if you have a large balance and this creates bloat and starts taking a fair amount of resources to stake. However, it is the time tested way for a decentralized staking and I prefer to use such time tested methods.

The other method is the NXT style that is based on total effective balance. That is the method the notary nodes will use and it wont matter how many utxo you have, though if you are spending them and it is not old enough, it wont have the staking power. There will be a bundle boundary balance that serves as a maximum possible and it is adjusted by any balance changes. This avoids attacks based on moving funds all around to addresses that would win a block. Also after an address gets a payout, it will need to "recharge". This will allow smaller addresses to win blocks.

With approx 1440 blocks per day, 1/1440'th total supply will on average win 1 block per day. So a balance of approx 2000 KMD should get staked once per month. And however long it takes, all the interest will then be paid out.

Anyway, the exact details are still subject to change, but I am working to allow people to passively earn 5% per year without having to do anything, but if so inclined would be able to proactively stake on their node.

There are transparent funds (normal bitcoin) and protected funds (zero knowledge)

You can of course transact using transparent funds
You can also transact using protected funds
You can convert transparent to protected
You can convert protected to transparent

keep in mind the protected funds (zero knowledge) wont be able to be staked as there is no way to know the balances for those funds.

I am working on a way where people can stake as normal so they can make sure they will earn staking under their control, or they can just let the notary nodes stake for them. Keep in mind, if your total balance is low then it could be that you wont get many blocks at all, regardless if your node is staking directly or you let notaries do it.

The advantage to this dual nature is that even in the unlikely event that something happens to all the notary nodes, the network will still be able to generate blocks. That way we get a fully decentralized node by node staking, with the elected notary nodes staking as an overlay. Not sure I can get both to play nice with each other yet, but so far it is looking promising

There are three types of gains:
3 KMD blockreward
staking 5% APR
txfees

the staking rewards goes to the address with the winning balance. The blockrewards are reserved for the notary nodes. I am leaning toward the node that stakes getting the txfees, so that would be a slight incentive to directly stake.

If you are able to get BTCD at below the implied price, then that would be the most cost effective way. However, BTCD doesnt have a lot of inventory for sale, as there only seems to be ~50BTC available at or below the implied price + bonus

The first day 25% bonus for BTC investors wont have any liquidity issues and will get the best BTC based price without any complications.

Of course, any BTCD you can pick up below .00425 will be better by the ave early bird bonus for the ICO. Likely ~10%. But the lack of liquidity will make it hard to get any very large amounts. In a sense BTCD is an ICO token with a very early bird bonus

The problem is that the NXT AE's liquidity has really dried up due to circumstances beyond my control. So instead of trading at some reasonable price that reflects the true value of its holdings, it doesnt really trade at all. I warned them. I made a lot of noise about this. I predicted this would happen if they went ahead with their splitting the coin plan, but I was ignored. And I could no longer justify spending my time enhancing NXT.

The split with NXT is what convinced me that I had to create my own platform that I can trust to not be changing beneath my feet if it suits the interests of the primary coin holders. Derived crypto has no protection against the hardfork attack where the devs and large stakeholders agree to transfer value from the addons, like assets.

To solve this I am making assetchains, a blockchain secured by itself using PoS of itself. Now before you start accusing me of starting another project, this one was forced onto me by the NXT situation and I designed a solution that fits into the SuperNET roadmap.

Now the problem with a PoS chain with very few nodes is that it will be very weak and I would not feel it secure enough. So what is needed is a way to enhance the security of assetchains.

Hence dPoW

Before any trolls try to say I did the same thing to BTCD, I remind them that NXT assets had literally millions of dollars worth trading on it before they changed the fundamental future value of what assets are denominated in and without any way to get back onto the main value coin. Of course they are nice enough to support a slave chain at the mercy of the mainchain if you pay a 50% tax. This would be similar to the NASDAQ saying that instead of trading in USD, they are changing to the Argentine peso, except for a while it will trade as it if was (half EUR + YEN), except for the time where it is ...

All NXT asset holders had to become like advanced forex traders and instead of highly predictable currencies like the USD, GBP, lira, peso, they would be denominated in an ever changing base value whose price had no history and was totally unpredictable. It didnt take a genius to realized that to properly price assets in such chaos would be beyond the skills of most the existing assetholders. All they would see is crazy overnight 4x revaluations and 80% drops and that is if the prices did the logical thing! If nobody is trading something and it revalues, then it cant help but be mispriced. And globally mispricing all assets in the market and saying that its the assets fault if they stay mispriced. They are causing financial harm to basically everyone that invested in my assets and I couldnt do anything about it. I just couldnt deal with it anymore and left NXT.

There are no assets denominated in BTCD. Also, even if there was, I would have allowed assets to become denominated in KMD. It matters what currency you trade against.

Oh, the true native DEX will allow trading of all the assetchains directly against BTC, and each other.

So that is what is happening with jl777hodl and many other assets.

I can also talk about why InstantDEX is not yet. Originally I designed it based on NXT, then all the blockchain messages became temporary which is not good for financial records that I wanted to use it for. The permanent messages costs went up 5x and what was already on the high side for fees of 5 NXT due to the number of transactions, would have cost 25NXT. That is more than the cost of using bitcoin!

Rather than release it with an nonviable pricing, I decided to wait to port it on top of iguana. Of course, to get some product release pump, I could have released it, but that is not who I am. If the non-technical aspects of the tech make it non-viable, I wont release it just to be able to say I released it.

claiming MGW is abandoned, jl777hodl is failed when it has accumulated 600+ BTC from just one of its holdings, and other desperate FUD, it does seem that somebody is in a panic mode.

on the one hand "jl777hodl is a failure"
on the other hand it has 200 siafund worth over 600 BTC

on the one hand "MGW is abandoned"
on the other hand MGW has been in service for years as described above

on the one hand "jl777 starts project after project"
on the other hand jl777 has be focussed on iguana for the last 10 months

anyway, iguana was having some windows compatibility issues and so I ported the entire 100,000 line codebase into visual studio, today. I guess I am just too slow and I should have been able to do it in 4 hrs? My only excuse is I dont even have a windows machine and had to do it remotely, power went out for a few hours and I dont use windows. that is why it took all day

So let us stop this nonsense about me not finishing projects. Porting iguana to visual studio would have been a month+ project for most devs. So does it count against me that I started the port iguana to visual studio project today and finished it today?

working capital

max raise (not very easy to achieve) is required, plus community needs to agree on the exact percentage allocation of the bonus.

Thanks for the observation.

The following is the list of projects I have started since last November when the NXT situation threw a monkey wrench into things by drastically changing its fee structure and everything else:

iguana

Now does iguana have more than a single function. Well yes. Maybe that is what confuses some people, they hear about all these different things that iguana does and cant imagine it is all just one thing.

Separately, an update on my "failed" asset jl777hodl which is a holding fund with 200 siafunds, which appears to be worth over 600 BTC in addition to other assets. Some rumors that siafunds will start trading on poloniex soon, and if its price goes above 5BTC each, then jl777hodl would have gone from 0 to 1000+ BTC. Considering it never did an ICO and I just funded it with my personal holdings, it is a good result.

I also invented the MGW, multigateway, which issues a proxy asset to represent native cryptos 1:1. The multigateway automatically accepts deposits into a multisig address and returns the corresponding asset. Redeems are also automatic and a destination address can be any valid coin address. This has been around for over 2 years and to me it seems to invalidate the claim that I never finish anything.

MGW + NXT AE was doing a tokenized DEX, which allows decentralized trading via the AE. Now we are finally seeing alternate implementations of this tech. 2 years later. I also see the trolls proudly posting lists of the dozen+ proxy assets I issued for MGW to support their claim I am doing an ICO every day. The truth is these assets and many others are just issued with a fee and they are kept around until some deposits are made. Not exactly the millions of dollars of free money I supposedly raised from asset sales.

I have also invested in a variety of other projects. Additionally I freely help other projects when they ask. Now maybe my problem is I post about things that are not just about iguana, but if you think about it, if I am posting about things then I am not coding.

yes, but calculate the cost at 33 signers

also for planning purposes I need to account for the possibility of the 1MB blocks filling up and a fee market being created that boosts the txfees significantly

It depends on what level of the project you mean. There are the mission critical parts, like paying for bitcoin fees and notary nodes.

1000 would be enough for a reduced bitcoin notarization frequency and smaller number of notary nodes, but not a lot of development.

5000 would allow to have the fastest bitcoin notarization frequency, all 64 notary nodes and staff up a group of C coders and GUI devs fulltime for some years

10000 would allow having many LP nodes all fully funded for the lowest trading spreads and many liquid trading pairs

Above this would allow a warchest that can make opportunistic trades, arbitrages and other means to generate working capital and set up a very long term organization of the above. Along with some large scale marketing. Of course, even at the lower funds raised we will be doing marketing, but with a limited budget.

I am not aware of any plans to cancel the crypto card. and certainly if he is planning this I would be against that.

I did coordinate this, so in that sense I was involved, but the banking environment changed from bad to horrible during the project and the best could be done was done. As I am not expert in fiat banking, I need to rely on others for such things

thank you for your understanding.