send it to yourself if you want to

KMD doesnt have staking built in and utxo based staking adds a lot of blockchain bloat, NXT based staking adds a lot of extra work and both increase chance of bugs.

my opinion is that spend based accrued interest payments is the lowest footprint method to reward the 5% APR and ultimately I think that is what people care about, ie. getting their 5%

you are earning the 5% automatically, all the time.

1) BTCD isnt mined, it gets 5% APR via staking

2) the mining by notary nodes is designed to pay for the costs of running the notary node.

With KMD, the plan is to payout accrued interest (max weekly) whenever you spend an output. So the 5% from 1) is achieved without any need for staking.

you have it wrong

At 25 cents per KMD the mined amount will cover the costs of the notary nodes, so the subsidy is not expected to last forever.

The BTC txfee costs will be less than the costs for the notary nodes.

I want to have at least a 10 year buffer, so for all that are complaining that we are raising funds or it is some sort of greed, they need to realize that it costs BTC to pay continuous BTC fees and to have many high end servers.

Once it is in place, it becomes a barrier to entry. Granted anybody else could fork the code, but still the entire notary nodes have to be reproduced and the BTC for txfees would be needed. Also, once KMD is live, people can just use KMD and obtain the benefits of being secured by BTC (indirectly) at a fraction of the cost.

Each user of KMD will create demand for KMD, usually on a continuous basis, and that will provide a base of demand. We will be migrating the various NXT assets to assetchains, which will use dPoW so there will be some reference cases available. By using KMD to secure the assetchains, for a minimal cost, each asset will obtain BTC level security for its transactions and not be a derivative crypto at the mercy of some master chain. the txfees for users would be denominated in that asset and the asset issuer would just need to purchase enough KMD to pay for the service.

Beyond assetchains, there will be smart chains which are special purpose blockchains that implement a dapp. think of it like an ASIC that does one thing and only one thing, vs a CPU that is running and OS and doing many things at once. We expect this to be a very popular way to utilize blockchain tech and the isolation it provides combined with efficiency that is further secured by dPoW will hopefully make a good demand for KMD.

I dont know why everybody assumes that the max specified amount is anything other than the maximum.

We had to pick some limit to prevent whales from buying up the entire ICO, 16% does not seem like an unreasonable maximum, especially since the actual amount coming in will likely be a lot less. it cannot be more, it will most likely be a lot less.

there is no rush for 5000btc. angel investors proactively approached us and made a reasonable request to get a slightly bigger bonus. we accomodated and made the identical offer available to everybody else.

if you criticize us for working with investors to secure funds, then maybe the fact that we are conducting an ICO to raise funds has been overlooked? is the criticism that we should have rejected the funds?

If you criticize us for offering the same deal to everyone, instead of keeping it secret and/or closed to public like most other projects, does that mean you prefer that we keep secrets about this or dont offer it globally?

Angel investors appear to have provided enough for the minimum already, so no worries on this

you must be kidding.

why would we choose an obsolete 3 year old libzerocoin implementation that has significant bloat issues?

it would be like choosing an Intel 8080 CPU over Xeon

so no, never considered zcoin

zcash tech is indeed pretty cool
the bitcoin that is sent is in transparent mode, so it can be traced
however, once it is in KMD, then you can protect it by converting it to a zero knowledge proof. And then transact with it in that form

https://github.com/zcash/zcash/wiki/specification

The following was automatically generated by a pair of test notary nodes:

KMD ht 17747 0x4553
014f222c02ae2560aae7e33245701ab7049a9f148386980ffc1569c22fdb4488

BTC: https://blockexplorer.com/tx/d203681d4bf82039b74dabcdbd93add3fc7d931a2a40ad996eba9ac3151155a3
01000000021835e9a5332e4c7e32489d187972b268f8e0b63b6fd8bba5b8664a7f7709727b07000 000484730440220217e5c849004e5e66b3bee2736d093a12f9dc9a85ddba47e47afc661cf97d652 022042f4578df9393ef94aacb03dd0efc69822aa02d9f3bb54cd95e011263af83b3201ffffffffc 5a4bab5145a1eeb52ad86ed43b1ecea0e52b80d81c15f374419a3a1b9e7a8240700000048473044 022038a057d362ac241f8ee73dddfd566eb2ccd3e9603b81e67a74013fb5532c6de8022034333c8 5d1f7f97421fdc093dcb5ca2de812585607a7699d175310924a82ef3b01ffffffff021027000000 0000002321020e46e79a2a8d12b9b5d12c7a91adb4e454edfae43c0a0cb805427d2ac7613fd9ac0 000000000000000266a248844db2fc26915fc0f988683149f9a04b71a704532e3e7aa6025ae022c 224f015345000000000000

above has:
OP_RETURN 8844db2fc26915fc0f988683149f9a04b71a704532e3e7aa6025ae022c224f0153450000

notice the OP_RETURN data has the KMD blockhash and height (byte reversed) and it is in the BTC blockchain

KMD: http://148.251.57.148:3001/tx/5ff868ddb2a5ded1853fa00ca22265031dc9b767f745c38727faa0021a41e198
0100000002387a235d003629f2d85692b73b98a93f4d29c944068637e6ac4cde3375b04b7101000 00049483045022100cabfcd9227b407ffd2f7042b4fb58baa62f61dc46467d78fc670f0eee811dc b10220724f8156c6291a8d0f29aa3b9f0ecada3297e468ac3b199dc9a7ae6bb69a5df501fffffff faf441f814ba95a0f01df2fa235ea8de4be8afb4fff321ad25ba25d109b37be9b02000000484730 440220076ca32fc5445924e4f6369305310a6823d38f2aa1df26911908d206d45016ba02205b82e 57bc3ab5fde2a6e8652d6c9f6ff615a0d6f75edff0fba1e0db3b11be3fd01ffffffff0210270000 000000002321020e46e79a2a8d12b9b5d12c7a91adb4e454edfae43c0a0cb805427d2ac7613fd9a c00000000000000004a6a488844db2fc26915fc0f988683149f9a04b71a704532e3e7aa6025ae02 2c224f0153450000a3551115c39aba6e99ad402a1a937dfcd3ad93bdcdab4db73920f84b1d6803d 24b4d440000000000

OP_RETURN 8844db2fc26915fc0f988683149f9a04b71a704532e3e7aa6025ae022c224f0153450000a355111 5c39aba6e99ad402a1a937dfcd3ad93bdcdab4db73920f84b1d6803d24b4d4400

In the corresponding KMD confirmation of the BTC notarization, the OP_RETURN has the same data as the BTC tx and also has the BTC txid and name of source coin.

Both the notary transactions use inputs originating from the pubkey of the notary node and since it is a SIGHASH_ALL transaction, it means all signers have validated the data, which in this case is the OP_RETURN data.

The next step is to verify that the dPoW notary tx creation works with more than 2 notary nodes at a time. I coded it in a way that uses "numnotaries" and numnotaries/2+1 as the key thresholds. Over the weekend, the testnet notary operators have been busy getting their rigs up to speed and we have over half a dozen ready to go.

Once we can get a steady stream BTC notarized KMD blocks, then it is the home stretch to use this data to modify the consensus algorithm to avoid/prevent overwriting any block at or before the highest notarized height.

tl:dr dPoW notarized data is automatically being written to BTC blockchain
https://blockchain.info/address/1P3rU1Nk1pmc2BiWC8dEy9bZa1ZbMp5jfg can be used to track these notarized tx

 

Multigateway

It is an asset based automated multisig gateway that I pioneered in the NXT Asset Exchange 2 years ago.

MofN (2of3) independently controlled servers accept deposits in native crypto and issue matching amount of assets. Also, assets can be redeemed as native crypto to any native address.

Combined with the built in asset exchange allows for crypto <-> crypto trading. We are now seeing other implementations of this idea. Waves is building this type of functionality into their asset system.

I am technical advisor to waves, especially regarding MGW

technically it is minable, but unless an elected notary node, odds are going to be really skewed against you.

There have been no insider deals and several large investors approached us for getting a bigger discount with a pre-ICO investment. This is not anything we planned, we are just responding to demand.

Now, it is important that everybody get the same opportunity as everybody else. The only requirement is the amount of the BTC. Considering the size and the timing, the extra percentage bonus is appropriate. This is open to everybody, nobody is forced to do this.

We are not talking about a 3x or 5x advantage to the large investors. It is 5% to 10%. If anybody really thinks this is unfair, well, we have to agree to disagree. Whales always get a better deal than the rest, I hope people will analyze this objectively and not with emotions.

Recent peers need to be used (and website updated with them)

I got half the iguana dPoW notary code debugged. It is already coded to monitor the KMD chain and BTC chain and make the appropriate transactions to both chains.

For all running a testnet notary node, the following are prep instructions to get ready for activating dPoW notarized transactions, which I expect to be enabled next week.

testnet is chugging along fine, though i guess according to the former poster, none of this is anything special.

testnet stats:
    "blocks" : 14770,
    "timeoffset" : -53,
    "connections" : 40,
    "proxy" : "",
    "difficulty" : 2.12729565,
  
dPoW notary config:
0. Install and start ../agents/iguana add any coin via coins/genbtcd or coins/basilisk

1. Create an iguana wallet with encryptwallet if you dont already have one:
curl --url "http://127.0.0.1:7778" --data "{\"agent\":\"bitcoinrpc\",\"method\":\"encryptwallet\",\"passphrase\":\"use high entropy passphrase that generates the pubkey\"}"

2. Create an executable (chmod +x) file "SuperNET/iguana/wp" with the following in it:
curl --url "http://127.0.0.1:7778" --data "{\"method\":\"walletpassphrase\",\"params\":[\"same passphrase as above\", 9999999]}"

Now from SuperNET/iguana if you run ./wp it will show the various addresses including "btcpubkey" which is your notary pubkey. Post this in #notarynode if you havent already.

3. create a text file SuperNET/iguana/myip.txt with just your ip address in it:
12.34.56.78

The ipaddress is only used for registering notary node and not directly correlated with your pubkey.

4. copy SuperNET/iguana/coins/btc btc_7776 kmd and kmd_7776 up one directory to SuperNET/iguana and edit "path" to match your home directory. if your home directory is /home/username then \"path\":\"home/username\"

5. make a copy of SuperNET/iguana/wp -> SuperNET/iguana/wp_7776 and change port 7778 to port 7776

6. make a copy of SuperNET/iguana/tests/dpow_7776 to SuperNET/iguana/dpow_7776 and edit the pubkey to match your btcpubkey from above

**********
The assetchains I released yesterday will be upgraded to plug into the dPoW

The DEX I released last week will then be able to atomically swap across the different chains directly, without any third currency involved.

After the iguana dPoW tx generation is completed, what is left to do is:
a) updating latest notarized height based on the notarized tx data
b) prevent overwriting blocks below notarized height
c) detection of special transactions to update list of current notaries
d) award 5% APR for utxo older than a week when they are spent
e) round robin mining difficulty

Those are the only required komodo side changes that I have identified so far. I work steadily to achieve completion and will continue to post the details.

All of this is already open source and available in my various repos:
http://github.com/jl777/komodo - fork of zcash + dPoW host
http://github.com/jl777/iguana - C codebase from scratch, include bitcoin protocol, DEX, etc.
http://github.com/jl777/assetchains - fork of BitcoinUnlimited + dPoW client + spawn new coin from commandline

Whether any of this is anything special, I leave that for the reader to decide. It is unarguable that it is being completed and delivered.

The start of ICO is the 15th of October.

Due to demand, we might offer a whale discount to purchase the week before, but it would require a large amount of BTC, for a slightly higher bonus.

Technically, it isnt just dPoW, it is all the other SuperNET services that will be coming online over the next year. Starting with easyDEX, assetchains.

Also, while the block generation of KMD uses PoW, that is just an artifact from it starting from zcash fork. The vast vast majority of KMD will be owned by ICO investors and I believe it will be the most open, most widely available zcash coin, with no mining based limits on available inventory.

My analogy is that if zcash is like Intel that makes the CPU

then Komodo is like the Apple computer, that has the CPU, but also has all the rest of what is required for a complete system. Clearly we feel zcash will become the standard for privacy in crypto, but privacy alone is not enough. There needs to be a lot of active usage to provide the most ambient transactions.

Having an easy to use GUI and DEX and other services will ensure having the most transaction flow.

I cant guarantee the exact timing of the REVS mainchain, but as I complete the dPoW debugging one of the test points is a third party chain using dPoW.

REVS will be the reference dPoW client chain and so it will allow others to easily create dPoW secured chains just by forking the assetchains repo and creating a new coin via command line. Of course the changes made to the assetchains code to support dPoW can also be implemented into any other blockchain.

The way REVS will be distributed is to an end of bundle BTCD snapshot right after the end of ICO. All BTCD addresses with a balance will receive a corresponding amount of REVS. You just need to importprivkey and you will have access to the REVS.

After REVS is distributed, then one of the first things will be getting easyDEX support for it, so you will be able to directly trade it for all the iguana supported currencies.

However, please keep in mind that KMD dPoW is always the highest priority, so getting that deployed will happen first. In parallel, there are GUI developments happening and I am not speaking about any of those as I am deep in the core. There could well be some GUI releases also, but you would have to ask others about the timing of installers, GUI, etc.

I am recovering from  a cold, so not up to the usual 16hrs per day of deep coding. But no sense to waste time, so I figured I might as well close the loop on assetchains.

https://bitcointalk.org/index.php?topic=1372879.0
The above talks about the asset passport system, which in some sense was the mother of dPoW! The necessity of being able to secure many weak chains is what got me on the path to dPoW.

I have selected the Bitcoin Unlimited implementation to base the assetchains on. A couple reasons are that the MVF (minimum viable fork) btcfork project that I helped out is basing itself on that. Also instead of being insulted, I get invited to the BU slack so I can get support in making a dPoW compatible chain.

Now before you all start thinking that this will take a long amount of time, I already finished the coding for the dPoW independent portion: https://github.com/jl777/assetchains

As I debug the dPoW, I will have a test third party chain to verify that dPoW is able to be used by other chains easily. And since we need to make a BTCD revshare assetchain, this solves multiple issues all at the same time. I call the reference assetchain: REVS (short for revshare)

The changes I made:
1 minute block time, 1.5 day retarget
block 1 issuing of all coins (assets)
disable block reward, txfees goes to crypto777 account
on-demand blocks (no need to generate PoW depth when dPoW provides security)
command line spawning of new coins

The dPoW integration is not yet, but I believe this is the first implementation of a bitcoind fork that allows for command line spawning of new coins. iguana was the first to do this earlier this year and it is quite a handy feature.

    ASSETCHAINS_PORT = GetArg("-ac_port",ASSETCHAINS_PORT);
    ASSETCHAINS_MAGIC = GetArg("-ac_magic",ASSETCHAINS_MAGIC);
    ASSETCHAINS_TIMESTAMP = GetArg("-ac_timestamp",ASSETCHAINS_TIMESTAMP);
    ASSETCHAINS_SUPPLY = GetArg("-ac_supply",ASSETCHAINS_SUPPLY);
    name = GetArg("-ac_name","name");

When the assetchaind is launched by adding the various -ac parameters, it will deterministically generate the nonce for a valid genesis block, and the genesis block and go into an idle mode waiting for transaction to arrive in the mempool. This eliminates all the blockchain space that has empty blocks.

I will have to add a special case to ignore the dPoW notarization special tx, otherwise it will keep generating blocks for each confirming notarization tx. Clearly some dPoW specific issues left to do, but then again since dPoW is not finished yet, that kind of makes sense.

Some might say it is dangerous to release something that allows anybody to create a new coin just with new command line parameters. I say that we will end up with thousands upon thousands of blockchains, this is unstoppable, so they might as well be dPoW blockchains.

To run an assetchain, just clone https://github.com/jl777/assetchains
cd assetchains
./autogen.sh
./configure
make

from src:
./assetchaind -gen

the above launches the default assetchain, which is for REVS. To launch a different chain:

./assetchaind -gen -ac_port=pppp -ac_magic=mmmmmmmm -ac_timestamp=<unixtime> -ac_supply=<supply> -ac_name="name"

pppp is the p2p port, the rpc port will default to one above
mmmmmmmm is netmagic, just some large random number
<unixtime> is standard unix timestamp
<supply> is the total coins/assets issued
"name" is case sensitive and ~/.name will be where the coin files will end up

I tested most functions other than the on-demand blocks. let me know if you have any issues