Assuming BB price is ~0.001 this represents about 2.2 BTC of value. I think it is good to put this in perspective. Doing any distribution would likely cost more than its value and not be economical.

With 2.2 BTC estimated value, it would be used for normal expenses. However, I like to hodl promising crypto, so likely would not sell at such a price and then maybe over time it becomes worth 10x more.

If as the trolls say, that I am nothing special, then it seems anybody could take over the codebase. Maybe in a day or so.

Of course, if it is true that I have some special talents, then it is a good thing that funds are being raised for to cover such an unlikely scenario. ALL of the source is open source as I develop it. To my mind this is far less of a risk than any project which isnt open source regardless of how many devs they have.

Also, I am sure that competent C coders like tromp could pick up my codebase without much trouble. I am writing code to existing bitcoin protocol specification for the most part.

I have no plans of disappearing and am VERY careful whenever there are any buses. Believe it or not, I actually dont get out much.

oh, ok.

./komodo-cli paxdeposit RNJmgYaFF5DbnrNUX6pMYz9rcnDKC2tuAc 1 usd
usdkmd.6558498870 basevolume.100000000 baseusd.1000000000 paxvol.100000000 usdvol.100000
0255534400e1f505000000003c8ee61a3161993f4f7b7081259bf5f3322d65d3f8 ht.39430 srcaddr.(RNJmgYaFF5DbnrNUX6pMYz9rcnDKC2tuAc) usd fiatoshis.100000000 -> dest.(RSttHqE7YAooCTb3LjNEnhYwCCTsTb95BH) komodoshis.655849000
f0e1878432ce581fa8547b89e46b377181fa8b61719d70a4653e57d2f6790d02


I figured out how to encode a PAX deposit transaction into a normal bitcoin style transaction. it is a cold address as the pubkey 0255534400e1f505000000003c8ee61a3161993f4f7b7081259bf5f3322d65d3f8 is not published until it is redeemed.

Still fiddling with getting this data into the wallet so it can be used for the redeem. Also, still need to figure out how to submit a redeem.

Keep in mind this is the fundamental low level deposit/redeem based on fiat value from the blockchain. A higher level layer will need to be added to manage the overall balances, so really it is only half done.

not sure I should explain what I did today. It isnt a complete solution, just part of the required infrastructure, but it could easily be misunderstood until the rest is in place.

but this way it is speculation on speculation!
more speculative

added "long term" to the poll question

basically not based on any short term blip, but over the long term what is the predicted ratio. Implicit is that both coins continue existing

2016-10-24 17:26:45 proof-of-work found 
  hash: 02a6d17d79ea8ee3f0181c5003f474cf8715529fd14bcac8cf1b758cd365d0ca 
target: 0f0f0f0000000000000000000000000000000000000000000000000000000000
2016-10-24 17:26:45 CBlock(hash=02a6d17d79ea8ee3f0181c5003f474cf8715529fd14bcac8cf1b758cd365d0ca, ver=4, hashPrevBlock=023cb6cb5ac1bc4692533ad1c1db0ad13871cee5556b90dc08596b8991905e87, hashMerkleRoot=89adce444597ea16da2d9f44245d28dfd4e434f476da7d3ec817d39084123d2c, hashReserved=0000000000000000000000000000000000000000000000000000000000000000, nTime=1477329957, nBits=2003fe27, nNonce=0000febdc00fcfbc9889d391127c5b540a89340528b6986de8e2db6178e00000, vtx=1)


http://148.251.57.148/block/02a6d17d79ea8ee3f0181c5003f474cf8715529fd14bcac8cf1b758cd365d0ca

What is special about the above block is that the mining target hash is: 0f0f0f0000000000000000000000000000000000000000000000000000000000
which is the minimum diff, even though the actual diff at the time was around 4, with nBits of 2003fe27

this prevents mining wars between notaries. a lot of infrastructure needed to be in place for this to work, most especially height specific list of notaries. We still need to verify ratification of a new list of notaries, which is one of the last remaining items now that round robin difficulty is verified.

Added a paxprices RPC call. It isnt fancy, just returns numsamples (timestamp, price) pairs starting from the most recent. The notary nodes are now generating pretty consistent pricefeed entries, so there should be plenty of the raw data.

All 1024 price pairs are supported, with an additional 32 against KMD. for now I just hard-coded .0001 BTC as KMD price, but once it starts trading, it will change based on exchange prices.

Another special case is when base and rel are the same, ie usd usd. I use that to denote the currency's abstract value. However, I had to come up with a sane way to combine the prices of different currencies without creating distortions, or at least minimizing distortions.

What I did was use recent M1 data for all currencies: http://www.tradingeconomics.com/japan/money-supply-m1 and multiple the abstract value in the price feed (will be detailed in PAXpaper). this allows combining different currency prices with some semblance of common denominator. Essentially we get a 32 currency total M1 supply using normalized prices.

Make sure everything fits in 64bit calculations and presto!

The base base value becomes the percentage of the 32 currency M1 supply.

./komodo-cli paxprices usd usd numsamples
{
    "base" : "usd",
    "rel" : "usd",
    "array" : [
        {
            "t" : 1477322826,
            "p" : 10.67656160
        },
        {
            "t" : 1477322769,
            "p" : 10.67656960
        },
        {
            "t" : 1477322697,
            "p" : 10.67658080
        }]
}

The above shows usd at 10.67% of the total M1 supply. Similar to coinmarketcap, I guess this is like a fiat marketcap. Guess which currency is #1?

Speculations

You are assuming BTCD price would stay static. While it is true people who want small amounts can likely get a better effective price via BTCD, if any large amount is purchased in the open market, the price would go up a lot.

Still, we have been 100% open about how all this works. it is everybody's choice on how to participate. Also, going the BTCD path would require getting a local wallet running and then also redeeming, so there are more steps involved

I took advantage of my time off to write a bunch of new code.

iguana notary dapp now generates a pricefeed and the miner puts the pricefeed into the mined tx as an opreturn, about 150 bytes per block.

komodod then uses this data to generate consensus prices for any combination of 32 fiats as of any height:
 { "USD", "EUR", "JPY", "GBP", "AUD", "CAD", "CHF", "NZD",
    "CNY", "RUB", "MXN", "BRL", "INR", "HKD", "TRY", "ZAR", "PLN", "NOK", "SEK", "DKK", "CZK", "HUF", "ILS", "KRW", "MYR", "PHP", "RON", "SGD", "THB", "BGN", "IDR", "HRK" };

./komodo-cli paxprice eur gbp 37750
{
    "base" : "eur",
    "rel" : "gbp",
    "height" : 37750,
    "price" : 0.88864077
}

./komodo-cli paxprice eur gbp 38000
{
    "base" : "eur",
    "rel" : "gbp",
    "height" : 38000,
    "price" : 0.88837559
}

There are almost 1000 combinations of 32 currencies, if you count both directions. base is the starting currency, rel is the ending. So with the eur/gbp above, each EUR gets 0.888... GBP

paxprice is the first RPC I added to komodod, but it wont be the last. I will writeup another whitepaper draft about PAX tech as it does get quite involved.

5% APR

This is one of the characteristics of BTCD so part of KMD requirements. BTCD used the peercoin utxo staking method. What that means is it added a required timestamp field to transactions and staking required spending an old utxo and creating a new one (usually two). So this leads to every increasing amount of work that is needed to do and also adds a lot of transactions to the blockchain.

With KMD's underlying block generation being equihash PoW, to add a utxo staking would require essentially recreating the peercoin PoS changes.

Nothing against the peercoin method, but for KMD with the notary nodes generating blocks using a modified zcash round-robin PoW, I wanted a more efficient way to deal with the 5% APR. I saw how siacoin awarded siafund interest when you spent it, which seemed a much more efficient method as it didnt take any blockchain space, nor did it need any continuously increasing amount of calculations.

of course, making such a change to the zcash codebase is easier said than done. All places that need to know how much is being spent needs to be adjusted to account for the accrued interest. Finding all such places wasnt easy and still not sure I found them all, but I got the basics working with the latest version.

To avoid creating a fork, it is just displaying the accrued interest now. Once all the various places are showing the identical values, then I can enable actually creating the coins to match the accrued interest. Since the txfee is calculated as (Sum(inputs) - Sum(outputs)), by increasing the effective amount of the inputs it would increase the txfee. So, in addition to boosting the input sum, all the places that creates transactions needs to be adjusted. That way, the amount paid for txfee will match what the sender wanted to and the value of the interest obtained.

To avoid awarding interest on dustlike outputs, I set the threshold to 1.0 KMD to be eligible for getting interest. Interest is paid by each minute, using the nLockTime of the transaction against the nTime of the previous block. No need to worry about people iterating sends to themselves each block as the txfee will eat up most of the interest if the timeframe is small.

People familar with bitcoin protocol will exclaim "most transactions dont have nLockTime set! and even if they did, there is no assurance it wasnt set arbitrarily in the past"

At least, that is what I thought at first. Then I realized that I could add a constraint that if nLockTime is set to be a timestamp, then it needs to be within some reasonable gap from the current time. current time as defined by the chaintip's nTime so we can get consensus on all interest calculation durations. By using nLockTime, it makes it a field that is somewhat useful and instead of being almost always 0, it will be a useful timestamp for all tx.

If anybody sees any issues with actually using nLockTime as a transaction timestamp, let me know. If it is used as a block height, then it wont earn interest, but that is a special case usage. For transactions that use the nLockTime actively, like the DEX protocol, the locktime is set to a near future value, which will still start the interest accruing from that point in time.

I changed the wallet to add a timestamp that is based on the chaintip's nTime so by sending funds to yourself you can create a transaction that will start earning interest. then using listunspent or other RPC, you can see the accrued interest. its cool how it keeps increasing each minute, even though it is just satoshis.

from listunspent:
    {
        "txid" : "bf0876b211c1abc3b1f9f5c1a129d81e2b6b070c112ddffe7971ab82d3b309fe",
        "vout" : 0,
        "address" : "RNJmgYaFF5DbnrNUX6pMYz9rcnDKC2tuAc",
        "account" : "",
        "scriptPubKey" : "76a9148ee61a3161993f4f7b7081259bf5f3322d65d3f888ac",
        "amount" : 1.00000000,
        "interest" : 0.00011876,
        "confirmations" : 1225,
        "spendable" : true
    },

from getrawtransaction:
    "vout" : [
        {
            "value" : 1.00000000,
            "interest" : 0.00011904,
            "n" : 0,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 8ee61a3161993f4f7b7081259bf5f3322d65d3f8 OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a9148ee61a3161993f4f7b7081259bf5f3322d65d3f888ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "RNJmgYaFF5DbnrNUX6pMYz9rcnDKC2tuAc"
                ]
            }
        },
    "confirmations" : 1228,

from gettxout:
{
    "bestblock" : "012d0a5510ac52d8bd0eacf81cd6dd2d6907233e0b0fb0c983d90cebf475cf8c",
    "confirmations" : 1293,
    "value" : 1.00000000,
    "interest" : 0.00012224,
    "scriptPubKey" : {
        "asm" : "OP_DUP OP_HASH160 8ee61a3161993f4f7b7081259bf5f3322d65d3f8 OP_EQUALVERIFY OP_CHECKSIG",
        "hex" : "76a9148ee61a3161993f4f7b7081259bf5f3322d65d3f888ac",
        "reqSigs" : 1,
        "type" : "pubkeyhash",
        "addresses" : [
            "RNJmgYaFF5DbnrNUX6pMYz9rcnDKC2tuAc"
        ]
    },
    "version" : 1,
    "coinbase" : false
}

I could have gotten this implemented in iguana in just a few hours, but I am still in the process of getting familiarized with the bitcoind C++ code, so that explains why it took me so long to add accrued interest and still it isnt in all places that are needed. When we can verify that the interest is being displayed properly in all places, we can deploy a hardfork that actually awards it. Not sure when that will be, the last hardfork created a fair amount of confusion, so I want to minimize the number of these we do, even if it is just for "testnet"

So, it seems I am ahead of schedule and I hope people wont mind if I take the rest of the weekend off.

the parameters have nothing to do with the genesis block.
there is no "master key", it only exists if all the parameter creators collude.
to avoid any such issues, we will just use the same parameters as zcash
the notaries have nothing to do with the zcash parameters

max of 4 by same person, one per region

from what I can tell, most whales wont bother with running notary nodes, but rather would just vote for the established testnet notaries who have proven they know what they are doing.

So I cant guarantee that you will be elected, but if you dont run a test node i dont think you would get many votes. What a lot of notaries that want to run multiple notaries is to get one of them working during the testnet and then they can run as candidate for multiple slots

All blockchains have a genesis block, it is just the first block that all nodes start from.
If we reset the chain, we will likely change the genesis block, but that is independent as you can reset the chain (start over from genesis) without changing the genesis.

We are past the block 34000 hardfork and also it looks like all the crashes and mining issues are solved.

I found a little complication I need to solve in addition to the 5% APR, but since the 5% APR will be another hardfork best to leave that till next week. I think I see how to do it, but prefer to have a more general approach that will apply to PAX.

So, dont worry if there arent many updates over the weekend. We have dPoW aware komodod and iguana notary dapp both running. The 5% APR is totally independent of dPoW, but it is part of the BTCD coin parameters.

The genesis block is unrelated to the zcash parameters. the trusted setup argument requires assuming that ALL participants in creating the zcash parameters are colluding.

And if there is such a collusion and it is used to inflate the currency supply, it will be discovered and ALL the participants would be found out that they colluded. Also, market value of zcash will plummet, so it seems that smart people wouldnt collude together to be exposed as a colluding group, even if they were unethical and open to stealing.

Does anybody really believe that Matt Green, et. all will all be colluding to steal zcash? ALL of them? knowing that if they utilize the ability to steal the coins that they will be caught and that there is no doubt as to who did the stealing?

Because of this I do not worry about the trusted setup argument

there is a small chance that this testnet can become the actual mainnet

it was a very remote chance before, but now there are just the bugfixes and the 5% APR left to add

if we can get that and also verify that election ratification works, then there is no need to reset the chain

still a lot of if's, just wanted to post about the increasing chances. what I like about it is that it rewards the people who have been helping the test process. it also makes the mainnet a bit more secure as it starts with an established history.

It would also make KMD the longest running zero knowledge blockchain

there are currently more nodes in europe than everywhere else combined. So that means the election process will be very competitive. You are certainly free to become a candidate in Europe, but better to run unopposed anywhere else.

we get more geodiversity and you would have a much higher chance of being elected