i got the iguana full nodes to provide tx construction services for the basilisk lite nodes. the latter dont need any blockchain and rely on iguana consensus for balance and txconstruction services and the protocol is fully abstracted so any coin that supports a basilisk plugin will work. Currently there are only three low level functions that are needed for bitcoin protocol, "balances", "rawtx" and "value" the last is to verify that the constructed spend is spending the correct value and avoids needing to do "heavy" SPV merkle tree validations as if the constructed rawtx has the wrong input values, basilik rejects it, if the output is wrong, basilisk rejects it, if it has a double spend, the network will reject it and the iguana node wont get its fee. I also threw in an auction mechanism, so the lowest fee rawtx that matches consensus is chosen. For inputs with coinage, all iguana nodes will construct the identcal rawtx as a deteministic method is used for unspent selection. I will add an avoid list so a basilisk node can do multiple rawtx requests per block and still have all nodes generate identical rawtx

This is just one method of earning money by running an iguana node. The more coins you run, the more fees you can earn. For coins that are just bitcoin forks without any protocol changes, the following curl request is all that is needed for iguana to do a parallel sync for it:

genltc:
curl --url "http://127.0.0.1:7778" --data "{\"RELAY\":1,\"VALIDATE\":1,\"prefetchlag\":-1,\"poll\":10,\"active\":1,\"agent\":\"iguana\",\"method\":\"addcoin\",\"startpend\":8,\"endpend\":8,\"services\":129,\"maxpeers\":256,\"newcoin\":\"LTC\",\"name\":\"Litecoin\",\"hasheaders\":1,\"useaddmultisig\":0,\"netmagic\":\"fbc0b6db\",\"p2p\":9333,\"rpc\":9334,\"pubval\":48,\"p2shval\":5,\"wifval\":176,\"txfee_satoshis\":\"100000\",\"txhastimestamp\":0,\"minoutput\":10000,\"minconfirms\":2,\"genesishash\":\"12a765e31ffd4059bada1e25190f6e98c99d9714d334efa41a195a7e7e04bfe2\",\"genesis\":{\"version\":1,\"timestamp\":1317972665,\"nBits\":\"1e0ffff0\",\"nonce\":2084524493,\"merkle_root\":\"97ddfbbae6be97fd6cdf3e7ca13232a3afff2353e29badfab7f73011edd4ced9\"},\"alertpubkey\":\"040184710fa689ad5023690c80f3a49c8f13f8d45b8c857fbcbc8bc4a8e4d3eb4b10f4d4604fa08 dce601aaf0f470216fe1b51850b4acf21b179c45070ac7b03a9\",\"protover\":70002}"

Granted, it is quite a lot of coin specific info, but given just the above, iguana can do a full parallel sync. If you have a coin you want to support, most of the above details can be found from blockexplorer of genesis block, or maybe just post in that coin's thread. I will accept pull requests for genCOIN scripts.

The corresponding basilisk script just changes a few values:
ltc:
\"RELAY\":0,\"VALIDATE\":0,\"prefetchlag\":11,\"poll\":100
\"startpend\":1,\"endpend\":1,\"services\":128,\"maxpeers\":16

It took 20 minutes to fully sync LTC and 5 minutes for SYS. Runtime resource usage isnt fully optimized yet for basilisk, but first step is to get the iguana full nodes in place. Once they are in place, then LP services will provide significantly more revenue potential, but always it is providing decentralized services and market driven fee levels.

BTCD blockchain will be where service provider availability and status will be posted and also for when a fast blocktime is needed.

Now you might be worried that iguana having to support all the coins at the same time will mean it is a large program, but its code size is less than 2MB. And that code handles all the coins, InstantDEX and even has the alpha versions of pangea and PAX built in, so if anything the size will probably get a bit smaller.

It has a single external dependency: pthread
So no boost, no networking lib, nothing external to hassle with. I did incorporate directly the libsecp256k1-zkp and portions of gmp.

I still have the "last mile" to code up and debug, but now is the time to get the iguana nodes in place. The more nodes, the more coins can be supported, the more basilisk wallet will be used, the more people will trade, the more fees to be earned.

SuperNET will be running a few service providing nodes, along with MGW so end users will always have service available and fees can be directly earned.

iguana fees will flow through the corresponding asset, ie InstantDEX for DEX fees, pangea for pangea fees, etc. but there will be some things without any corresponding asset like wallet txfees and those will flow through crypto777. There will be a 10% royalty for all the fees that go to crypto777, which I believe is small enough to not impede adoption, but big enough to be meaningful when things go mainstream.

Of course, BTCD transaction levels will go up, so staking BTCD will earn more fees from all this.

MGW and SuperNET nodes wont get any special preference and they will compete on open market regarding fees with whoever else is running a service provider node. This assures best prices and smallest spreads for users and the market will automatically adjust prices.

What revenue levels are possible? It all depends on factors that are hard to estimate ahead of time, but considering that iguana is quite a bit ahead of anything else and BTCD is starting to deploy real world dapps, it is a good place to be.

I know all the dapp platforms are getting all the attention, but who exactly will create the mass market useful dapps? Some weekend casual programmer or me? There is nothing the dapp platforms provide that isnt already available with bitcoin + iguana, so in a sense BTCD is a dapp platform and has a dedicated dev creating mass market potential dapps. Ultimately as crypto transitions out of the "dot-com" type of bubble, the surviving projects will be the ones that get mass market usage and thus the mass market revenues.

For those that think 10% is too low a fee for crypto777, I guess my thinking is that economies with 10% tax rates tend to grow a lot more than those with 50% tax rates and even though it is 1/5th the nominal rate, it can often generate a lot more actual gross revenues than the high tax rates.

InstantDEX necessarily has a 1/777 fee 0.14% to prevent attack vectors, without that fee it can be attacked and it works out to be right in the range of typical exchange commission rates. I will have more info on InstantDEX details in the coming weeks (yes weeks, not months) just dont know exact timing as I prioritize fixing bugs in iguanacore and that means I dont know how much time I have available for the other parts. So far there havent been that many bugs.

For those that think that it has taken too long to get here, I ask, how many other bitcoin core implementations are out there that can run many coins at once. And how long those took to create and how large they are and if it can run in a purely lite mode or a revenue generating full node basis. If so, I could have saved a lot of time and cut and pasted it.

For those worried others will just cut and paste it, the code is GPL so whatever improvements they make will come back into iguana and if they make no improvements, then it seems they will have troubles getting adoption. Not to mention they would need to keep up with me improving my codebase.

James

https://www.youtube.com/watch?v=JF-UMgdkph4

walking/running on water is supposed to be impossible
basilisk does the impossible

It is the liteweight version of iguana, more details as the initial test version is deployed

I am finally close to finishing the iguanacore, the RPC layer is going through testing and so far all bugs found have been easy to fix.

So I am back to debugging the atomic swap and now have the state machine going through 80% of the process, but I am doing it in a loopback mode for now so I dont have to wait for new blocks and can just use the same unspents over and over for testing.

One issue with fully decentralized exchange is that people will lose their connections and the need to properly resume a pending trade needs to be solved. Assuming a power loss, then any temporary keypairs would need to be preserved so the funds can be properly claimed. Worst case is if a powerloss causes HDD corruption and you are in the protocol phase where you need the keys to claim it, you are losing funds.

So, this means a robust key storage and recovery mechanism is needed.

Or is it?

What I came up with is a deterministic keypairs system that allows recreating all temporary keys used for a specific swap, using just the accounts main keypair. I am assuming that proper care about backing up the main keypair is done.

Since there is a lot of divulging of the temporary keypairs going on, I wanted to make sure that neither the main keypair is compromised and also that this method doesnt open up an attack vector. I am thinking that since it has algebraic structure, it makes things a bit harder to spoof, but I cant see any direct way of the other party verifying things directly.

Here is the process:

bits256 instantdex_derivekeypair(struct supernet_info *myinfo,bits256 *newprivp,uint8_t pubkey[33],bits256 privkey,bits256 orderhash)
{
    bits256 sharedsecret;
    sharedsecret = curve25519_shared(privkey,orderhash);
    vcalc_sha256cat(newprivp->bytes,orderhash.bytes,sizeof(orderhash),sharedsecret.bytes,sizeof(sharedsecret));
    return(bitcoin_pubkey33(myinfo->ctx,pubkey,*newprivp));
}

A chain of keypairs are generated that starts from the main account keypair and that one needs to be protected. Each iteration of the chain uses the derivekeypair function. The orderhash is SHA256 of the orderbook entry that is being swapped. I am using the nodes orderbook entry, but maybe it is better to use the other party's entry, or a combine value. Probably the combined value is best, that way the keypairs chain is only for the exact swap.

The first step is to make a shared secret using the orderbook hash as the "pubkey" and the main account's privkey as the privkey. The curve25519 is used for speed and it does an SHA256 of the actual shared secret field element, so that protects the main privkey as well as curve25519 + SHA256 does.

This shared secret is put through another round of SHA256 with the orderhash and that is used as the privkey to generate an secp256k1 pubkey. There is a small chance of failure here as not all 256bit value are valid privkeys, but that is taken care of with the outer loop.

The outer loop does the following:
    for (n=0; n<keypairs_needed; n++)
    {
        pubi = instantdex_derivekeypair(myinfo,&swap->privkeys[n],pubkey,privkey,hash);
        privkey = swap->privkeys[n];
        if ( pubkey[0] != firstbyte )
            continue;
        ...
     }

the first iteration, the privkey is the main account privkey, but after each iteration, the privkey is what is calculated in the prior iteration. Since each new privkey requires a shared secret using the main privkey, only the owner of that privkey is able to generate each iteration.

Also, I set all of Bob's privkey's so that the pubkey starts with 0x03 and Alice's starts with 0x02. that allows to use it as an extra consistency check and with the libsecp256k1 library, the time it takes is not really noticeable for generating about double the keypairs. this check also catches the case where the privkey is illegal as the first byte will be 0x00

Now comes the part I think might have some issues the part above that is in the  "..."

            calc_rmd160_sha256(secret160,swap->privkeys[n].bytes,sizeof(swap->privkeys[n]));
            memcpy(&txid,secret160,sizeof(txid));
            len += iguana_rwnum(1,(uint8_t *)&swap->deck[m][0],sizeof(txid),&txid);
            len += iguana_rwnum(1,(uint8_t *)&swap->deck[m][1],sizeof(pubi.txid),&pubi.txid);
            m++;

txid is a unit64_t and it is the lower 64bits of the bits256. I calculate both the rmd160+sha256 of the privkey and also the lower 64bits of the secp256k1 pubkey. These are the cut and choose keypairs that are sent to the other side. and all but the chosen one is sent back in full privkey form so the above uint64's can be verified.

maybe there is no need to send both variants and just one will suffice, but I have a feeling that with this additional constraint, it might be possible to get some proof that the chosen keypair is valid, prior to funds being committed via pederson commitments or something like that.

James

are you sure?
It seems base58 would have a 1/58th chance for a '1'

there are reasons, but you would need to think things through why as I am not allowed to disclose anything yet.

James

P.S. the two txids above are confirmed

Supernet does marketrate swap at rate of 120 SuperNET assets for NXTventure's sharkfund0. This provides indirect ownership of sharkfund0's 120,000 BTCD stake, which when prorated is a bit over 30,000 BTCD, in addition to the other holdings of sharkfund0. NXT txids 14267855016414469572 and 9842386871139077046

Supernet does marketrate swap at rate of 120 SuperNET assets for NXTventure's sharkfund0. This provides indirect ownership of sharkfund0's 120,000 BTCD stake, which when prorated is a bit over 30,000 BTCD, in addition to the other holdings of sharkfund0. NXT txids 14267855016414469572 and 9842386871139077046

I had the same question.

I think the issue is that if there is a metric that gives permanent precedence to one block or another, then it would allow an attacker to create a replacement block for any point in the past beyond whatever checkpoint.

So, clearly any tiebreaker would need to only apply when there are two chains of equal length. Given the same length, both have the same cumulative weight as the nBits is the same for both chains for all blocks, so the PoW sum will be the same. Due to this, a longer chain will have more chain weight than a shorter chain.

It seems that without changing anything in the protocol, if all the miners just adopted any deterministic metric to resolve chains of equal length, then this will have the effect of extending the chain with the highest metric, even though the block is contributing the same amount to the chainweight.

This isnt much of an issue with bitcoin, due to its high difficulty, but for weaker networks having a way to minimize forks would be a good thing, unless there is some horrible attack vector this opens. However, since all miners using the same tiebreaker is within the current protocol, if standardizing a tiebreaker creates an attack vectors, that already exists

not for a while. I dont want the hardfork to delay the pending releases, so will only be able to work on it here and there.

once the tech is done, then we will need to verify it follows the current network on various nodes. then we can schedule a hardfork block far enough into the future to give everyone a chance to switch.

then the hardfork release is deployed, we wait, the mainchain switches from old version to new version.  I will try to make it use the existing wallets, but it seems a good idea to put the data in a separate directory, ie. ~/.BitcoinDark2

So, even if the tech is ready now, it would be approx 1 month for validating that it properly follows the existing chain, then probably another month ahead for the hardfork block.

There will be plenty of notice. Maybe it would be cool to have it switchover on its birthday, but I dont want to commit to any specific date until the tech is done.

James

yes, everyone will have to update, that is why I want to make sure the vast majority are ok to do this

which works out to ~365/6500 -> 5.6%, well within expected range

I guess if dust amounts (< 0.0001) are being staked that would be less than 1 BTCD staking, which would indeed stake dust amounts

5% per year
how much are you staking?

I posted in slack about a 0.12 hardfork to very positive reaction, so I will describe here the plan:

Currently iguanacore is in testing of the RPC layer, this will allow iguanacore to be a dropin replacement for BitcoinDarkd/bitcoind for all except creating new blocks. During the transition phase, we still need the normal BitcoinDarkd nodes to create the blocks.

However, yesterday I studied the exact staking method and also the 0.12 codebase and realized I could relatively quickly get a BTCD0.12 release, once the staking code is put into an isolated module. I did get a 0.12 to start syncing with the existing BTCD network, but the protocol has changed enough that it didnt really get going, other than to find some peers after genesis

In my opinion, the safest path is to update the BitcoinDarkd to the 0.12 codebase and have it take over the block generation. The iguanacore would be able to submit staked blocks to the network, but by having the 0.12 nodes doing the actual new block creation, we will benefit from all the improvments in the bitcoin codebase. especially regarding all the various fork resolutions.

Eventually, iguanacore will handle all this, but by having the 0.12 nodes take this over, it allows a faster deployment. Also, it will allow me to create a (0.12 <-> iguanacore) interop network and enhance the 0.12 codebase with other iguana interop features.

as a bonus, I also figured out an enhanced staking that will add value to the staking process, but I dont want to disclose details until I get at least a proof of concept working.

This would require a hardfork, which means older nodes will eventually go off onto their own fork. So all nodes would need to upgrade. We can make it so that the 0.12 is deployed well ahead of time in a follow the existing chain mode, until the hardfork block. At that time, it takes over block generation.

The following are the release points, without the 0,12:

1. bitcoin RPC compatible
2. instantdex API stable
3. tradebots API stable
4. pangea API stable
5. PAX API stable
6. asset passport API stable

The RPC compatible iguanacore is doing quite well in testing and once that is released, theoretically all existing bitcoin RPC apps would be able to work with it.  We will test it with MGW and a few other standard bitcoin RPC based apps.

Now, I am speaking about the iguanacore and not the GUI, which is quite independent of the core by using the bitcoin RPC as the interface layer.

Assuming the community wants the 0.12 hardfork, we need someone to coordinate it. I will disclose to the hardfork coordinator the new enhanced staking, so proper marketing plans for that can be made. I just dont have time to deal with all the non-technical aspects for the hardfork

James

P.S. There is also the chrome app release that will require existing nodes to be deployed first, so that is not a specific release point.

I have a question about the consensus rules.

https://peercoin.net/assets/paper/peercoin-paper.pdf
Main Chain Protocol
The protocol for determining which competing block chain wins as main chain has been
switched over to use consumed coin age. Here every transaction in a block contributes its
consumed coin age to the score of the block. The block chain with highest total consumed
coin age is chosen as main chain.

From the above it indicates that the coinage for the entire block is used to determine which block wins (contingent on its passing all the other requirements).

However in the code, it looks like it is using the longest chain wins. While that would eventually reach consensus, I was wondering if there was a specific reason the blocks' coinage isnt used as a tiebreaker for two competing blocks found at the same time. maybe it opens an attack where a large coinage can be spent?

James

iguanacore works with BTC, which is a well known high liquidity coin

1. you can look at is as a way for VRC to tap into the other parts of supernet. it is up to VRC to create features that are in demand by other supernet users. VRC has fiat gateway, SMS and other thing which appeal to segments of the market different than other coins.

2. via atomic cross chain trading and liquidity providing tradebots, iguana integration

3. it will be the mass market users

4. again you are asking a coin-centric question, if someone has VRC then they would have easy access to the other parts of supernet.

The power of a network is based on the network effect, so even an aggregation of many smaller coins will create a larger base, but of course the larger the coins are, the larger they are.

Also, you need to remember that before SuperNET the concept that a coin should do more than just be a bitcoin clone, this was relatively rare. I am glad to see that now this has changed quite a bit and people are expecting more from all the coins. I dont know if SuperNET had any direct impact on that or if it was just a natural progression that SuperNET anticipated.

James

We will certainly be working closely together, as coinomat has been a long time SuperNET partner

There is a chrome app that is a BTCD node in testing now, doing parallel sync in a few hours. Since chrome apps are limited to 10GB, BTC wont be able to be a full relaying node, while BTCD can be. not sure why there are people that are saying that iguana wont help BTCD. seems they are not really understanding the consequences of having a node encapsulated in a webpage. If the mass market cannot install a node, then the mass market wont be able to adopt it. The mass market is able to run chrome apps. There are also native versions of iguana that run on unix, osx and I think even windows is getting close by the build team.

I still need to add the RPC layer on top of the parallel sync dataset, but at that point we can validate against the bitcoin RPC unit tests and brute force compares against the existing full daemons.

one click install wallet, which also serves as the platform for all the SuperNET services.

James

SuperNET will be getting a modest stake in Waves. Considering the amount that it will raise, I doubt the share will be in the "large" percentage range.

James

BBR has been diluted since coins have been mined by others but SuperNET is not mining it.
NXT has been diluted due to expenses
VPN is a bit less due to some market making inventory

other coins are very close to the same, you can just compare the totals now against the totals in the past. the coin addresses have always been public

So for the most part the coins inventory is the same, with the small exceptions. Of note is that 18 million IOTA has been acquired, which was not originally there. So, whatever usage of the coins is more than compensated by the IOTA value

James

did you read: http://www.digitalcatallaxy.com/report2015.html

you are incorrect in assuming that SuperNET started with 10% for all the coins. It did not. usually 5% to 10% range and if there is mining for a coin, the percentage would shrink as the coin supply increases. Also, the NXT has been used as working capital so it is gradually reducing