{
  "trx_id": "127d573628670328ff8d279ca43d2c73f0b333c4",
  "block": 66884373,
  "trx_in_block": 6,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2022-08-17T14:42:03",
  "op": [
    "transfer",
    {
      "from": "ph-support",
      "to": "stealthsend",
      "amount": "0.001 STEEM",
      "memo": ""
    }
  ]
}

{
  "trx_id": "90d1865b3be6534c19a37eeb3ddfc9caa3362bce",
  "block": 34376340,
  "trx_in_block": 43,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-07-04T20:12:12",
  "op": [
    "transfer",
    {
      "from": "jadams2k18",
      "to": "stealthsend",
      "amount": "0.002 STEEM",
      "memo": "Appreciated @stealthsend. Sorry to intrude. I hope I'm not disturbing you with this message. My intention is to help promote the last post of my great friend @crypto.piotr about palnet.io and the HOPE project. I hope this reading is constructive for you. LINK: https://steemit.com/palnet/@crypto.piotr/project-hope-help-us-grow-by-making-a-simple-change"
    }
  ]
}

{
  "trx_id": "d4873eb5959669feca322b8e0bcad63b5c5e72fa",
  "block": 34142764,
  "trx_in_block": 2,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-06-26T17:14:54",
  "op": [
    "comment",
    {
      "parent_author": "stealthsend",
      "parent_permlink": "stealth-development-blog-013-03-08-2019",
      "author": "steemitboard",
      "permlink": "steemitboard-notify-stealthsend-20190626t171453000z",
      "title": "",
      "body": "Congratulations @stealthsend! You received a personal award!\n\n<table><tr><td>https://steemitimages.com/70x70/http://steemitboard.com/@stealthsend/birthday1.png</td><td>Happy Birthday! - You are on the Steem blockchain for 1 year!</td></tr></table>\n\n<sub>_You can view [your badges on your Steem Board](https://steemitboard.com/@stealthsend) and compare to others on the [Steem Ranking](https://steemitboard.com/ranking/index.php?name=stealthsend)_</sub>\n\n\n**Do not miss the last post from @steemitboard:**\n<table><tr><td><a href=\"https://steemit.com/steemitboard/@steemitboard/the-steem-community-has-lost-an-epic-member-farewell-woflhart\"><img src=\"https://steemitimages.com/64x128/https://cdn.steemitimages.com/DQmQWnM36SWCPGn98nY83M1ArgweMz5fnovQEp2E4FiDdug/Wolfhart_header.png\"></a></td><td><a href=\"https://steemit.com/steemitboard/@steemitboard/the-steem-community-has-lost-an-epic-member-farewell-woflhart\">The Steem community has lost an epic member! Farewell @woflhart!</a></td></tr></table>\n\n###### [Vote for @Steemitboard as a witness](https://v2.steemconnect.com/sign/account-witness-vote?witness=steemitboard&approve=1) to get one more award and increased upvotes!",
      "json_metadata": "{\"image\":[\"https://steemitboard.com/img/notify.png\"]}"
    }
  ]
}

{
  "trx_id": "618950e31864287006718b3f7f12c1841de62985",
  "block": 32536669,
  "trx_in_block": 2,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-05-01T21:24:45",
  "op": [
    "vote",
    {
      "voter": "stealthpay",
      "author": "stealthsend",
      "permlink": "the-holy-grail-of-crypto-or-part-2-4-feeless",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "c84416bc1e87cf7772681d1f63290b74fcdaeca2",
  "block": 32536666,
  "trx_in_block": 27,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-05-01T21:24:36",
  "op": [
    "vote",
    {
      "voter": "stealthpay",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-002-12-14-2018",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "e7b0d3cbf7f1c4add7a53f18bf7ba86205ceca14",
  "block": 32536666,
  "trx_in_block": 10,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-05-01T21:24:36",
  "op": [
    "vote",
    {
      "voter": "stealthpay",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-003-12-21-2018",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "efa4bd9cfa2a86686a189339bc37975456ad2dcd",
  "block": 32536663,
  "trx_in_block": 25,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-05-01T21:24:27",
  "op": [
    "vote",
    {
      "voter": "stealthpay",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-004-01-04-2019",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "e0f79fd923d8459f486dc025268fc2d3465e2adc",
  "block": 32536663,
  "trx_in_block": 6,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-05-01T21:24:27",
  "op": [
    "vote",
    {
      "voter": "stealthpay",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-005-01-11-2019",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "d1b055c196ebe3bce4bd9417430cedccbf6c3847",
  "block": 32536662,
  "trx_in_block": 22,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-05-01T21:24:24",
  "op": [
    "vote",
    {
      "voter": "stealthpay",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-006-01-18-2019",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "3a7378647f2caa2303b3ed28a19236ddfab45ffd",
  "block": 32536658,
  "trx_in_block": 22,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-05-01T21:24:12",
  "op": [
    "vote",
    {
      "voter": "stealthpay",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-007-01-25-2019",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "92a1aaf0676a5757136f4233319b654db0413cb6",
  "block": 32434068,
  "trx_in_block": 25,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-04-28T07:51:27",
  "op": [
    "transfer",
    {
      "from": "crypto.piotr",
      "to": "stealthsend",
      "amount": "0.003 STEEM",
      "memo": "Dear @stealthsend, I hope you don't mind this little memo. Just yesterday I published new post on Steemit asking all readers to share their opinion on particular topic: \"AIRDROPS - do you LOVE OR HATE them? or simply don't care?\". I would be glad if you would share your view on that issue. I read and upvote all interesting comments. Yours, Piotr // LINK: https://steemit.com/blockchain/@crypto.piotr/airdrops-do-you-love-or-hate-them-or-simply-don-t-care"
    }
  ]
}

{
  "trx_id": "dec982fc30b47b2354e9ffad87dba76e765fda54",
  "block": 32290671,
  "trx_in_block": 36,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-04-23T08:18:18",
  "op": [
    "transfer",
    {
      "from": "crypto.piotr",
      "to": "stealthsend",
      "amount": "0.002 STEEM",
      "memo": "Dear @stealthsend, I hope you don't mind my little memo. Did you ever think about IMPACT OF \"ALIENS\" on our religions? I would like to share with you link to very interesting discussion \"How will the overwhelming discovery of extraterrestrial life affect our lives and beliefs?\" by @jadams2k18. Perhaps you will find it interesting (I read and upvote all interesting comments). Yours, Piotr // LINK: https://steemit.com/life/@jadams2k18/how-will-the-overwhelming-discovery-of-extraterrestrial-life-affect-our-lives-and-beliefs"
    }
  ]
}

{
  "trx_id": "a45438aad4491dd91f2060bbf1b9eabd40702896",
  "block": 31975535,
  "trx_in_block": 44,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-04-12T08:31:54",
  "op": [
    "transfer",
    {
      "from": "crypto.piotr",
      "to": "stealthsend",
      "amount": "0.002 STEEM",
      "memo": "Dear @stealthsend, My good friend from Venezuela published recently very interesting post describing \"Behavior and evolution of cryptocurrencies ten years after its creation\". I found this post very valuable and wanted to share with you (my own attempt to promote quality content). I read and upvote all interesting comments. Yours, Piotr // LINK: https://steemit.com/blockchain/@fucho80/behavior-and-evolution-of-cryptocurrencies-ten-years-after-its-creation-what-to-expect-from-them-in-the-future"
    }
  ]
}

{
  "trx_id": "60613c4abf54de8f6af9ba3ee5ee5dff68b01a2e",
  "block": 31718197,
  "trx_in_block": 8,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-04-03T09:38:36",
  "op": [
    "transfer",
    {
      "from": "crypto.piotr",
      "to": "stealthsend",
      "amount": "0.002 STEEM",
      "memo": "Dear [@username], Today I've tried to check my \"wallet\" only to realize that I need to sign in again in order to have an access to it. It seem that Steemit Inc made another awful change that WILL ONLY COMPLICATE this platform even more. Please check out my latest comment and share your view with me. I read all comments. Yours, Piotr // LINK:   https://steemit.com/steem/@crypto.piotr/re-steemitblog-social-condenser-is-live-20190403t083122138z"
    }
  ]
}

{
  "trx_id": "49cbd31c402dbab9fcaae93bf913877ad55883bb",
  "block": 31613444,
  "trx_in_block": 15,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-03-30T18:16:48",
  "op": [
    "transfer",
    {
      "from": "crypto.piotr",
      "to": "stealthsend",
      "amount": "0.002 STEEM",
      "memo": "Dear @stealthsend, My friend @julianhorack published very interesting post about CENSORSHIP on social media and on blockchain. He does believe that blockchain is our solution and I seem to disagree with his concept. Perhaps you would like to share your own opinion on this particular topic? I would APPRECIATE very much and I will read, upvote and reply to every single comment. Yours, Piotr // LINK: https://steemit.com/informationwar/@crypto.piotr/re-julianhorack-blockchain-as-the-liberator-of-the-masses-from-the-claws-of-the-nwo-20190330t110024985z"
    }
  ]
}

{
  "trx_id": "ee70c901856ebe180a66e253482dbaaf58508645",
  "block": 31430776,
  "trx_in_block": 29,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-03-24T09:59:15",
  "op": [
    "transfer",
    {
      "from": "crypto.piotr",
      "to": "stealthsend",
      "amount": "0.002 STEEM",
      "memo": "Hi again @stealthsend. I hope you don't mind one more memo from me. If you do then please let me know and I will not bother you again. EACH WEEKEND I'm trying to promote 1-2 publications which I consider VALUABLE and related to BLOCKCHAIN technology. Good friend of mine @guysellars posted interesting article about KYC and AML. I would love to know what is your opinon on this particular subject. Yours, Piotr // LINK: https://steemit.com/bitcoin/@crypto.piotr/re-guysellars-kyc-and-aml-are-good-yum-20190324t092617518z"
    }
  ]
}

{
  "trx_id": "d195a7848bc04fd9b31f6550afe10f1ca687e6f4",
  "block": 31430087,
  "trx_in_block": 29,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-03-24T09:24:48",
  "op": [
    "transfer",
    {
      "from": "crypto.piotr",
      "to": "stealthsend",
      "amount": "0.002 STEEM",
      "memo": "Dear @stealthsend. Have you ever been wondering about purchasing your own NANO Ledger? I did several times. Friend of mine described his own valuable experience with this company and I would like to share link to his publication with you. Perhaps you will find it useful or even you could share your own experience with NANO Ledgers? I will gladly read all comments. Yours, Piotr // LINK: https://steemit.com/business/@crypto.piotr/re-roleerob-celebrating-good-business-latest-from-ledger-20190324t090152829z"
    }
  ]
}

{
  "trx_id": "5ffdb73ea2e924824aa1016df8c5a2dcb2f0e8a5",
  "block": 31226270,
  "trx_in_block": 4,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-03-17T07:27:57",
  "op": [
    "transfer",
    {
      "from": "dlease",
      "to": "stealthsend",
      "amount": "0.001 STEEM",
      "memo": "BuildTeam is proud to announce the release of DLease.io - our flagship P2P leasing marketplace app, aimed at assisting Steemians in leasing and delegating STEEM POWER for daily passive returns, with recent yields as high as 20% APR. DLease.io is a professional grade app , designed to replace the current MinnowBooster.net leasing market which has to date facilitated nearly 20 Million STEEM POWER in lease value to happy BuildTeam customers. View the new app at https://dlease.io/ or read the announcement post on https://steemit.com/@dlease."
    }
  ]
}

{
  "trx_id": "b4f2c71acbcb391078d56a593787bc4d4634c68d",
  "block": 31187069,
  "trx_in_block": 20,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-03-15T22:44:21",
  "op": [
    "account_update",
    {
      "account": "stealthsend",
      "owner": {
        "weight_threshold": 1,
        "account_auths": [],
        "key_auths": [
          [
            "STM5mZZ32nKXYe57pesmgJ5FgkJCNFR3bvJ2vnq1e9B569xadvUeh",
            1
          ]
        ]
      },
      "active": {
        "weight_threshold": 1,
        "account_auths": [],
        "key_auths": [
          [
            "STM6bUqULsYGXRKD47oex2xQyofLhoUWLbn9SaN5rUwLhDbJKsEX6",
            1
          ]
        ]
      },
      "posting": {
        "weight_threshold": 1,
        "account_auths": [],
        "key_auths": [
          [
            "STM8YMUQEcJhoV5ScCDJR5q4pUNtbz1BNTigTFrf5NsuNqmaMNnpb",
            1
          ]
        ]
      },
      "memo_key": "STM7KhDn21DcDkb8jaKTpXtkGJcsvvQxbqBHABmCFjioLNHbzc5qp",
      "json_metadata": ""
    }
  ]
}

{
  "trx_id": "bcaea930c12d243782aa0bef635bacd49fb8f346",
  "block": 31186397,
  "trx_in_block": 2,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-03-15T22:10:39",
  "op": [
    "account_update",
    {
      "account": "stealthsend",
      "posting": {
        "weight_threshold": 1,
        "account_auths": [
          [
            "busy.app",
            1
          ]
        ],
        "key_auths": [
          [
            "STM7oGtEVkFB2dbx9SGPjRxogp5AQF316sQYesk7kWGAza6rk7x5k",
            1
          ]
        ]
      },
      "memo_key": "STM7dT7fSHMXzR5MWo3uv7BUTyJ5hs83Er6SFBF5eibYybKEhQLsH",
      "json_metadata": "{\"profile\":{\"website\":\"https://stealth.org\",\"profile_image\":\"https://cdn.steemitimages.com/DQmUhEABcHYU8CftLBy32R1xsG5YRsTm6kBLVjwYc7pqdbw/logo.jpeg\"}}"
    }
  ]
}

{
  "trx_id": "915d39510596c29abd9051bfcf6762c0e5e45279",
  "block": 31001099,
  "trx_in_block": 4,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-03-09T11:39:33",
  "op": [
    "vote",
    {
      "voter": "steemitboard",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-013-03-08-2019",
      "weight": 100
    }
  ]
}

{
  "trx_id": "4e68902cf1a714ad4be1033bf87eb6896552962a",
  "block": 31001098,
  "trx_in_block": 32,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-03-09T11:39:30",
  "op": [
    "comment",
    {
      "parent_author": "stealthsend",
      "parent_permlink": "stealth-development-blog-013-03-08-2019",
      "author": "steemitboard",
      "permlink": "steemitboard-notify-stealthsend-20190309t113932000z",
      "title": "",
      "body": "Congratulations @stealthsend! You have completed the following achievement on the Steem blockchain and have been rewarded with new badge(s) :\n\n<table><tr><td>https://steemitimages.com/60x70/http://steemitboard.com/@stealthsend/payout.png?201903091018</td><td>You received more than 10 as payout for your posts. Your next target is to reach a total payout of 50</td></tr>\n</table>\n\n<sub>_[Click here to view your Board](https://steemitboard.com/@stealthsend)_</sub>\n<sub>_If you no longer want to receive notifications, reply to this comment with the word_ `STOP`</sub>\n\n\nTo support your work, I also upvoted your post!\n\n\n###### [Vote for @Steemitboard as a witness](https://v2.steemconnect.com/sign/account-witness-vote?witness=steemitboard&approve=1) and get one more award and increased upvotes!",
      "json_metadata": "{\"image\":[\"https://steemitboard.com/img/notify.png\"]}"
    }
  ]
}

{
  "trx_id": "eb4cfd16ff9186c3637182582c003bc9a6c785cf",
  "block": 30999452,
  "trx_in_block": 17,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-03-09T10:17:09",
  "op": [
    "vote",
    {
      "voter": "stealthpay",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-013-03-08-2019",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "01e6f23c1f125ad9f6d2ab515214b76b008ed8c3",
  "block": 30998214,
  "trx_in_block": 9,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-03-09T09:15:15",
  "op": [
    "vote",
    {
      "voter": "mrakodrap",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-013-03-08-2019",
      "weight": 1000
    }
  ]
}

{
  "trx_id": "0000000000000000000000000000000000000000",
  "block": 30995181,
  "trx_in_block": 4294967295,
  "op_in_trx": 0,
  "virtual_op": 13,
  "timestamp": "2019-03-09T06:43:36",
  "op": [
    "author_reward",
    {
      "author": "stealthsend",
      "permlink": "stealth-development-blog-012-03-01-2019",
      "sbd_payout": "0.556 SBD",
      "steem_payout": "0.000 STEEM",
      "vesting_payout": "2528.994156 VESTS"
    }
  ]
}

{
  "trx_id": "ff70d9312d7fe08149cdc17e2c9fe2a95790e2b3",
  "block": 30993884,
  "trx_in_block": 6,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-03-09T05:38:36",
  "op": [
    "vote",
    {
      "voter": "dniceguy",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-013-03-08-2019",
      "weight": 5000
    }
  ]
}

{
  "trx_id": "d395d80ca6748029e909754a7c85f883673418e3",
  "block": 30993794,
  "trx_in_block": 36,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-03-09T05:34:06",
  "op": [
    "vote",
    {
      "voter": "kiong3",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-013-03-08-2019",
      "weight": 2000
    }
  ]
}

{
  "trx_id": "1ae5d88297def8bd937c7ea5b5770db9987826cc",
  "block": 30993789,
  "trx_in_block": 18,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-03-09T05:33:51",
  "op": [
    "vote",
    {
      "voter": "steeming-hot",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-013-03-08-2019",
      "weight": 2
    }
  ]
}

{
  "trx_id": "db15b7002f2aa3288497c164c960bc383d9fbb26",
  "block": 30993771,
  "trx_in_block": 5,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-03-09T05:32:57",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "blockchain",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-013-03-08-2019",
      "title": "Stealth Development Blog 013: 03/08/2019",
      "body": "https://i.imgsafe.org/2d/2d1810987c.jpeg\n\n<b><h1>Internal Testnet: Staker Registrations and Client Restarts </h1></b>\nThis week I had two key achievements on testnet. Perhaps the most significant was that I registered a staker. I describe why this achievement is significant herein. Additionally, I debugged client restarts, so that the registry is restored perfectly after a restart. I also was able to transfer ownership of a staker. Before I discuss these landmarks, I need to revisit the topic of last week’s post regarding the structure of the block index.\n\n–––––\n\n<b><h1>Fork Dependent Structure of Block Indices</h1></b>\nLast week I spent a lot of time discussing how full node operators would need to re-index the entire chain before the transition to qPoS. Re-indexing would take one to two days depending on hardware. This week, I am happy to say that re-indexing will not be a requirement. In other words, full node operators will be able to simply stop their client, install the new Stealth software, and start again, enjoying an otherwise uninterrupted transition to qPoS.\n\nPreviously, I mentioned that the reason for re-indexing is that it is not possible to know a block’s version (and therefore its potential content) without reading the actual block from disk, which is a slow process. I happened to be incorrect about this assertion. I overlooked that a block index is required to read a block and the block index can contain information that indicates the potential content of its corresponding block.\n\nTo explain, QPoS blocks store two additional pieces of information in the block headers: (1) the four byte block version, which is moved from the coinbase transaction to a field in the block header, and (2) the four byte staker ID of the block signer. Blocks prior to the qPoS transition don’t have these fields in the block header, making the block structure different before and after the transition to qPoS. This difference in block headers means that the contents of the blocks must be known in order to read their transactions, as I described [last week](https://medium.com/stealthsend/stealth-development-blog-012-03-01-2019-a19d1b4ecc98). Fortunately, block indices can provide this content information.\n\nBelow I discuss changes to the block index structure that will be unique to qPoS. In short, block indices will also store all state changes to the registry so that reconstructing the registry state can be done using only block indices and not require reading any blocks from disk.\n\n\nhttps://i.imgsafe.org/2d/2d1829a31b.jpeg\n–––––\n\n<b><h1>Staker Registration</h1></b>\nThe most significant achievement this week has been to register a staker. The following shows the output of `getqposinfo` for the first ever registered qPoS staker:\n\n ``` \n \"1\" : {\n            \"alias\" : \"StealthRules\",\n            \"id\" : 1,\n            \"version\" : 1,\n            \"qualified\" : true,\n            \"enabled\" : false,\n            \"weight\" : 1,\n            \"keys\" : {\n                \"owner_key\" : \"02b2ea2375...\",\n                \"delegate_key\" : \"02cd85238b...\",\n                \"controller_key\" : \"02cd85238b...\"\n            },\n            \"delegate_payout_pcm\" : 0,\n            \"total_earned\" : 0.00000000,\n            \"blocks_produced\" : 0,\n            \"blocks_missed\" : 0,\n            \"blocks_assigned\" : 0,\n            \"blocks_seen\" : 0,\n            \"previous_blocks_missed\" : 0\n        },\n```\n<br>\nThe fields of this JSON output are described in [SDBS 011](https://medium.com/stealthsend/stealth-development-blog-011-02-22-2019-3b86f10528e9).\n\nHere, I have truncated the public keys from 66 characters to ten for readability. You will notice that the owner key is different from the delegate and controller keys. The reason is because I also transferred ownership from the original owner (02cd8…) to a new owner (02b2e…), representing another achievement on testnet.\n\nUpon creating the above output, the testnet is not yet ready to make the transition from PoS to qPoS, so this staker has has 0 earnings, 0 blocks seen, etc. Notice that stakers start life disabled. This means they need to be enabled through another blockchain transaction before they can sign blocks. Enabling a staker is simple and cheap, costing only the XST transaction fee of 0.01 XST. Stakers start disabled so that the economic event (the purchase) is decoupled from the functional event (signing blocks), allowing an individual to purchase a staker at a suitable time without the requirement to have a full node ready to sign blocks at precisely that moment.\n\nWhile the registration and owner transfer of a staker may seem like a simple achievement, together these abilities represent about 90% of underlying functionality of the qPoS code (consider that I spend most of my time in these SDBS posts talking about the “staker registry”). \n\nTaking staker registration as an example, the following list outlines the key functionalities involved:\n\n1. An RPC command must communicate the purchase to the client.\n2. The client must convert the RPC command into a blockchain transaction, where the instructions are stored in a transaction output as a valid program in the [Script programming language](https://en.bitcoin.it/wiki/Script).\n3. The blockchain transaction must be extracted into a command that specifies a registry state change. This extraction happens as a prerequisite to validation.\n4. The blockchain transaction must be validated, including the signatory, taken from the transaction input. Also in this process, the Script program mentioned above must be compared to a Script template to ensure it is a standard transaction output. This latter comparison required some very low-level changes to the Script parser, which I won’t discuss today.\n5. Upon inclusion in a block, these commands must be stored in the block indices, in a fork-friendly way, meaning that early block indices do not need to have placeholders for a command list.\n6. Upon acceptance of a block into the main chain, these commands must be read from the blockindex and applied to the registry to create the new registry state. Critical here is to synchronize these changes with user events, blockchain events, and with the entire network, requiring careful multithreading. An example of a registry state change is the addition of a staker with all its information, as represented in the above output of `getqposinfo`.\n7. Additionally, in order for the registry state to persist between startups, the registry state must be stored as snapshots and replayed faithfully from that snapshot to the lead block at the time of shutdown.\n\nThe list above represents the bulk of qPoS requirements, with the only real additional requirements being:\n\n* The registry state must be rolled back upon blockchain reorganization, then replayed to the lead block of the new best chain.\n* Stakers must start producing blocks upon the transition to qPoS.\n* Staker owners and delegates must be able to claim earnings from the registry ledger and transfer these earnings to the blockchain (UTXO) ledger so that these earnings can be useful (e.g. sent to other individuals to buy things or sold on an exchange).\n\nIndeed, except for finishing the testing and debugging of a few RPC commands (`setstakerdelegate`, `setstakercontroller`, `enablestaker`, and `disablestaker`) this latter bullet list constitutes the lion’s share of the remaining testing and debugging for the internal testnet. Although it seems more significant than registering a staker, making the transition in consensus mechanism from PoS to qPoS is not as technically challenging as registering a staker. In terms of assembling blocks and signing them, qPoS is very similar to PoS. The only technical differences are that qPoS block signers are scheduled in a queue that is managed by the registry, while PoS block signers participate in an inefficient stake lottery known as [King-Nadal consensus](https://whitepaperdatabase.com/peercoin-ppc-whitepaper/).\n\n\n<b><h2>Restoring the Registry State after Client Restart</h2></b>\nNext to blockchain reorganizations, one of the most technically challenging components of maintaining the registry is to restore its state after restart. At first glance, this may seem as simple as storing the registry state on shutdown then reading it again on startup. In a perfect world, this approach would suffice.\n\nHowever, in reality, running a full node is fraught with the perils of unexpected program terminations. These events can range from power outages, to crashes related to bugs in the code (nobody is perfect), to hardware failures. When a program crashes it cannot be expected to store information in anticipation of a shutdown. Instead, either this information must be periodically stored as a matter of housekeeping (i.e. snapshots), or must be easily reconstructed (a.k.a “replayed”) from information that is stored during normal operations (e.g. storing block indices).\n\nIn qPoS, I apply both of these latter strategies. Every 720 blocks (one hour), the protocol stores a snapshot of the staker registry to disk. Upon restart, the newest snapshot that is older than the lead block is read and the registry is replayed from this snapshot, saving replay time. To make this replay more efficient, qPoS stores information for registry state transitions in the block indices. Note that a new block index is stored to disk upon the processing of any block, including orphans. This state change information is stored as a set of imperatives in an vector (array-like) data structure called “vDeets” (short for “vector of registry state-change details”). These imperatives can be applied to the registry with minimal processing. Adding these imperatives to the block indices was one of my major improvements to qPoS this week.\n\n\n–––––\n\n\nHondo\n\nhttps://www.stealth.org",
      "json_metadata": "{\"tags\":[\"blockchain\",\"bitcoin\",\"cryptocurrency\",\"stealth\",\"privacy\"],\"image\":[\"https://i.imgsafe.org/2d/2d1810987c.jpeg\",\"https://i.imgsafe.org/2d/2d1829a31b.jpeg\"],\"links\":[\"https://medium.com/stealthsend/stealth-development-blog-012-03-01-2019-a19d1b4ecc98\",\"https://medium.com/stealthsend/stealth-development-blog-011-02-22-2019-3b86f10528e9\",\"https://en.bitcoin.it/wiki/Script\",\"https://whitepaperdatabase.com/peercoin-ppc-whitepaper/\",\"https://www.stealth.org\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}"
    }
  ]
}

{
  "trx_id": "2d47f529e9ece3da3eae649501dcc3ad63bd269c",
  "block": 30907880,
  "trx_in_block": 3,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-03-06T05:55:48",
  "op": [
    "comment",
    {
      "parent_author": "stealthsend",
      "parent_permlink": "stealth-development-blog-012-03-01-2019",
      "author": "steemitboard",
      "permlink": "steemitboard-notify-stealthsend-20190306t055547000z",
      "title": "",
      "body": "Congratulations @stealthsend! You received a personal award!\n\n<table><tr><td>https://steemitimages.com/70x70/http://steemitboard.com/@stealthsend/sc_verified.png</td><td>Steemcleaners Verified Profile</td></tr></table>\n\n<sub>_[Click here to view your Board](https://steemitboard.com/@stealthsend)_</sub>\n\n\n**Do not miss the last post from @steemitboard:**\n<table><tr><td><a href=\"https://steemit.com/carnival/@steemitboard/carnival-2019\"><img src=\"https://steemitimages.com/64x128/http://i.cubeupload.com/rltzHT.png\"></a></td><td><a href=\"https://steemit.com/carnival/@steemitboard/carnival-2019\">Carnival Challenge - Collect badge and win 5 STEEM</a></td></tr></table>\n\n###### [Vote for @Steemitboard as a witness](https://v2.steemconnect.com/sign/account-witness-vote?witness=steemitboard&approve=1) and get one more award and increased upvotes!",
      "json_metadata": "{\"image\":[\"https://steemitboard.com/img/notify.png\"]}"
    }
  ]
}

{
  "trx_id": "16f99d29ce07830da651f3cc053b47d0814716bc",
  "block": 30812402,
  "trx_in_block": 19,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-03-02T22:18:48",
  "op": [
    "vote",
    {
      "voter": "stealthpay",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-009-02-08-2019",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "47bcc100581dc1419fe8ecdf60d7884b79cef708",
  "block": 30812397,
  "trx_in_block": 14,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-03-02T22:18:33",
  "op": [
    "vote",
    {
      "voter": "stealthpay",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-010-02-15-2019",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "c0208587e052f6ed9887f5779cc4f02b3d7f7d4d",
  "block": 30812391,
  "trx_in_block": 8,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-03-02T22:18:15",
  "op": [
    "vote",
    {
      "voter": "stealthpay",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-011-02-22-2019",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "41040ce2d6653df3c8ca1f75353f07ac874340c8",
  "block": 30812387,
  "trx_in_block": 15,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-03-02T22:18:03",
  "op": [
    "vote",
    {
      "voter": "stealthpay",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-012-03-01-2019",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "c24a8897ee0a61f0f50ce5fc4626fcf5a230eef3",
  "block": 30794475,
  "trx_in_block": 9,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-03-02T07:21:54",
  "op": [
    "comment",
    {
      "parent_author": "stealthsend",
      "parent_permlink": "stealth-development-blog-012-03-01-2019",
      "author": "tts",
      "permlink": "re-stealth-development-blog-012-03-01-2019-20190302t072154",
      "title": "",
      "body": "To listen to the audio version of this article click on the play image.\n[![](https://s18.postimg.org/51o0kpijd/play200x46.png)](http://ec2-52-72-169-104.compute-1.amazonaws.com/stealthsend__stealth-development-blog-012-03-01-2019.mp3)\nBrought to you by [@tts](https://steemit.com/tts/@tts/introduction). If you find it useful please consider upvoting this reply.",
      "json_metadata": ""
    }
  ]
}

{
  "trx_id": "23a26f50f2b31eb18f65ccf26ab2cf54f4ff9116",
  "block": 30794305,
  "trx_in_block": 11,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-03-02T07:13:24",
  "op": [
    "vote",
    {
      "voter": "glitterfart",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-012-03-01-2019",
      "weight": 1000
    }
  ]
}

{
  "trx_id": "7f83803c085c10661a830ded7ffbf37f48b03c12",
  "block": 30793710,
  "trx_in_block": 6,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-03-02T06:43:36",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "blockchain",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-012-03-01-2019",
      "title": "Stealth Development Blog 012: 03/01/2019",
      "body": "https://i.imgsafe.org/a2/a22c8c369d.jpeg\n\n<b><h1>Stealth qPoS Internal Testnet Week 1</h1></b>\nToday, I describe progress and challenges related to Week 1 of the qPoS Internal Testnet. Most of my time this week was spent tracking down multithreading issues. Each issue took nearly two days to diagnose but about 20 seconds to fix. But most notably (from an end-user perspective), I had to change the block index from the original (genesis) design. The bulk of today’s post is dedicated to describing this change.\n\n–––––\n\n<b><h1>Block Index Change: Block Signer Will Be Stored in the Block Index from Genesis</h1></b>\nThe very first problem I encountered running the Internal Testnet this week was related to reading block headers. This problem was very nuanced and took almost three days to debug and fix. During this process I realized I needed to change how block indices are stored. To describe this change, I first need to explain some key differences between PoW, PoS, and qPoS blocks, and why they differ.\n\nIn PoW blocks, the block signer is identified by the coinbase transaction, which contains the signer’s public key as a destination for the block reward. This public key is used to verify the block signature. In PoS blocks, the block signer is identified by the coinstake transaction, that similarly contains the signer’s public key as both a destination and a source of stake.\n\nTo optimize blockchain storage, qPoS blocks differ from PoW and PoS blocks in that qPoS blocks do not contain the signer’s public key. Instead, the signer’s public key is held in the registry and indexed by a unique staker ID. To verify a qPoS block, clients use the staker ID stored in the block header to look up the staker’s public key in the registry (a very fast operation), then verify the block signature with this public key. For each block, this is a savings of at least 29 bytes (33 byte public key minus the 4 byte staker ID). Compared to PoS blocks, this qPoS optimization saves even more storage, adding to over 463 MB of blockchain storage per year (assuming 5 second block times).\n\nOf course PoW and PoS block headers have no field for storing a staker ID, which means that upon switching to qPoS, the staker ID needs to be added to the block header. This change increases the block header by 4 bytes (while reducing the transaction storage by 77 bytes). The logic of this transition is simple enough, and can be written in pseudocode as “if qPoS has started, write the 4 byte staker ID to the header”. Indeed the actual storage of the staker ID poses no problem whatsoever.\n\nHowever, the problem comes with reading a block index. Block indices, derived from block information, are stored with the following structure:\n\n* Block header\n* Transactions\n\nThe hangup comes when reading a transaction. To access a  transaction, the very low-level database API known as LevelDB starts reading right after the block header. To know where to start reading transactions, LevelDB must know the length of the header.\n\nHere is the catch, if block headers vary according to block height (where blocks coming after the qPoS transition are 4 bytes longer than blocks coming before the transition) then LevelDB won’t know where the transactions start without reading the block to determine its height.\n\nThis problem has a few solutions:\n\n1. Store the header length independently of the rest of the block, keyed by the block hash.\n2. Read the block to determine its version, then calculate where to start reading the transactions.\n3. Keep all headers the same length, storing the staker ID in a special transaction.\n4. Keep all headers the same length, storing the staker ID beginning at block 0.\n\nEach solution has tradeoffs. For example, the first two solutions mean that the disk storage must be accessed twice to determine where to start reading the transactions. The first solution has an additional disadvantage that not only must the 1 byte length information be stored but also the 32 byte block hash must be stored as a key, adding 33 bytes of index storage per block.\n\nFor these two solutions, the big killer, in my opinion, is not additional storage, but additional disk I/O. In the first solution, the additional I/O is to read the header length, and in the second solution the additional I/O is to read the entire block header to read the block version to deduce the header length.\n\nThe third solution requires no additional disk I/O operation and requires no significant effort from users, services, or exchanges. The one downside is that it needs 48 additional bytes per block, or an additional 289 MB of blockchain storage per year.\n\nThe fourth solution is most efficient, requiring no additional disk I/O. It requires a single one-time addition of about 11 MB to the disk index (but not the actual blockchain). This requirement is basically negligible. The huge drawback of the fourth solution is that it requires all nodes to rewrite history (i.e. re-index their chains upon upgrading to the qPoS client). The problem here is that the Stealth chain is over 2.5 million blocks long, and so re-indexing can take between one and three days, depending on one’s hardware. While I feel like this is significant burden for users, block producers, third parties, and especially exchanges, it makes the most sense in the long-run. It does mean that each exchange may be down between 4 and 6 days (because they usually run on VPS and not bare metal servers), but this is a one-time requirement that will greatly improve the storage efficiency of qPoS.\n\nRe-indexing does have another upside in that it will clean up the network significantly. As everyone is well aware, a blockchain is not a single data structure sitting on a single computer. A blockchain exists in numerous copies distributed across the world. And although the best blockchain can be determined by the consensus mechanism (PoW, PoS, qPoS, etc.), each separate copy has storage variation in the form of orphans and ordering. These variations can cause issues, such as when synchronizing a chain from the network. When nodes are required to reindex, they can be encouraged to use a specific bootstrap, which itself can be cleaned of orphans and ordered through a process called linearization.\n\nIn the end, even though re-indexing will pose a significant burden for users, third party service providers, and exchanges, and may cause service disruptions, it will ultimately be good for the Stealth network and enable the optimal approach to indexing block signers in qPoS.\n\nhttps://i.imgsafe.org/a2/a22c73ec0d.jpeg\n–––––\n\n<b><h1>Internal Testnet Week 1 Milestones</h1></b>\nThis week I was able to achieve the following milestones on the internal testnet:\n\n1. Full bootstrap (synchronization) to the mainnet blockchain.\n2. Genesis on the testnet blockchain.\n3. Mining on the testnet blockchain.\n4. Staking on the testnet blockchain.\n5. Sending/receiving on the testnet blockchain.\n\nFuture goals required for successful completion of the Internal Testnet include, but may not be limited to:\n\n* Register stakers.\n* Produce blocks by qPoS, keeping target times.\n* Send and receive under qPoS block production.\n* Use delegation.\n* Claim balances.\n* Test enabling/disabling of stakers.\n* Attempt to fork the network.\n* Attempt [timestamp attacks](https://medium.com/stealthsend/stealth-development-blog-001-12-7-2018-359ecb038de9).\n* Transfer staker ownership.\n* Test other constraints, like disallowed names, re-registering an alias, etc.\n\nOne question that may arise is: why not jump straight to testing qPoS? Why “waste” a week testing what should already work (chain sync, PoW, PoS, sending)? The simple answer is that one must test what should already work to ensure it did not break. An additional, and perhaps less obvious answer is that testnet must recapitulate mainnet. In other words, a testnet must be able to do all those things a mainnet has done or will do, in the order the mainnet did or will do them. Operationally, the most common need for recapitulation is that simply that new clients must replay the blockchain to validate it, and (in the case of qPoS) to know the state of the registry.\n\n\n–––––\n\nHondo\n\nhttps://www.stealth.org",
      "json_metadata": "{\"tags\":[\"blockchain\",\"bitcoin\",\"cryptocurrency\",\"stealth\",\"privacy\"],\"image\":[\"https://i.imgsafe.org/a2/a22c8c369d.jpeg\",\"https://i.imgsafe.org/a2/a22c73ec0d.jpeg\"],\"links\":[\"https://medium.com/stealthsend/stealth-development-blog-001-12-7-2018-359ecb038de9\",\"https://www.stealth.org\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}"
    }
  ]
}

{
  "trx_id": "b4d8f3c9593f9aa962ecf1ff81359427f5787fc6",
  "block": 30583575,
  "trx_in_block": 9,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-22T23:28:57",
  "op": [
    "vote",
    {
      "voter": "ratticus",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-011-02-22-2019",
      "weight": 1000
    }
  ]
}

{
  "trx_id": "420383af3bca7063b5c9d753256143d191e2ed77",
  "block": 30583561,
  "trx_in_block": 4,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-22T23:28:15",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "blockchain",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-011-02-22-2019",
      "title": "Stealth Development Blog 011: 02/22/2019",
      "body": "@@ -2411,18 +2411,62 @@\n archy:%0A%0A\n+%3Cb%3E%3Ch3%3ERegistry Object (Top-Level)%3C/h3%3E%3C/b%3E%0A%0A\n *\n- \n  %3Cb%3Evers\n@@ -2614,18 +2614,18 @@\n future.%0A\n-%0A\n *\n+ \n  %3Cb%3Ebloc\n@@ -2705,18 +2705,18 @@\n pdated.%0A\n-%0A\n *\n+ \n  %3Cb%3Ebloc\n@@ -2801,18 +2801,18 @@\n  block.%0A\n-%0A\n *\n+ \n  %3Cb%3Ein_r\n@@ -2947,17 +2947,16 @@\n  chain.%0A\n-%0A\n *  %3Cb%3Eco\n@@ -3024,17 +3024,16 @@\n staker.%0A\n-%0A\n *  %3Cb%3Ecu\n@@ -3454,23 +3454,16 @@\n false%60.%0A\n-%0A*  %3Cb%3E\n prev_blo\n@@ -3469,36 +3469,32 @@\n ock_was_produced\n-%3C/b%3E\n : %5Bbool%5D Whether\n@@ -3780,17 +3780,16 @@\n ttacks.%0A\n-%0A\n *  %3Cb%3Ecu\n@@ -3982,17 +3982,16 @@\n  below.%0A\n-%0A\n *  %3Cb%3Est\n@@ -4092,17 +4092,16 @@\n  block.%0A\n-%0A\n *  %3Cb%3Equ\n@@ -4294,29 +4294,675 @@\n the \n-following keys:%0A    %E2%80%A2\n+keys id, %3Cb%3Estart_time%3C/b%3E, and %3Cb%3Eend_time%3C/b%3E, described below under the heading %3Cb%3EQueue Object%3C/b%3E.%0A*  %3Cb%3Estakers%3C/b%3E: %5Bobject%5D An object with staker IDs as keys. Although IDs are integers, as JSON keys, they must be represented as strings. Each component object represents a staker and is described below under the heading %3Cb%3EStaker Object%3C/b%3E.%0A*  %3Cb%3Ebalances%3C/b%3E: %5Bobject%5D Represents the balances tracked in the registry ledger, which stores payouts to staker owners and their delegates. JSON keys are pubkeys (hex encoded 66 character strings). Each component object is described below under the heading %3Cb%3EBalances Object%3C/b%3E.%0A%0A%0A%3Cb%3E%3Ch3%3EQueue Object%3C/h3%3E%3C/b%3E%0A*\n  %3Cb%3E\n@@ -5066,21 +5066,17 @@\n gistry.%0A\n-    %E2%80%A2\n+*\n  %3Cb%3Estar\n@@ -5143,21 +5143,17 @@\n e slot.%0A\n-    %E2%80%A2\n+*\n  %3Cb%3Eend_\n@@ -5221,224 +5221,40 @@\n t.%0A%0A\n-*   %3Cb%3Estakers%3C/b%3E: %5Bobject%5D An object with staker IDs as keys. Although IDs are integers, as JSON keys, they must be represented as strings. Each component object represents a staker and has the following keys%0A    %E2%80%A2\n+%0A%3Cb%3E%3Ch3%3EStaker Object%3C/h3%3E%3C/b%3E%0A*\n  %3Cb%3E\n@@ -5363,21 +5363,17 @@\n change.%0A\n-    %E2%80%A2\n+*\n  %3Cb%3Eid%3C/\n@@ -5401,13 +5401,9 @@\n ID.%0A\n-    %E2%80%A2\n+*\n  %3Cb%3E\n@@ -5526,17 +5526,17 @@\n future.%0A\n-%E2%80%A2\n+*\n  %3Cb%3Equal\n@@ -5722,17 +5722,17 @@\n  above.%0A\n-%E2%80%A2\n+*\n  %3Cb%3Eenab\n@@ -5995,17 +5995,17 @@\n ewards.%0A\n-%E2%80%A2\n+*\n  %3Cb%3Eweig\n@@ -6494,18 +6494,17 @@\n  trust.%0A\n-%E2%80%A2 \n+*\n  %3Cb%3Ekeys\n@@ -6605,980 +6605,116 @@\n eys:\n-%0A    %C2%B7  %3Cb%3Eowner_key%3C/b%3E: %5Bstring%5D Hex encoded 66 character (33 byte) hash of the staker%E2%80%99s owner key. The owner \n+ owner_key, delegate_\n key\n+,\n  \n-c\n an\n+d\n  c\n-hange all three authority keys. If the owner key is changed, it transfers ownership. Payout from block rewards is indicated by the %60delegate_payout_pcm%60 value, described below.%0A     %C2%B7  %3Cb%3Edelegate_key%3C/b%3E: %5Bstring%5D Hex encoded 66 character (33 byte) hash of the staker%E2%80%99s delegate key. As described in %5BSDBS 001%5D(https://medium.com/stealthsend/stealth-development-blog-001-12-7-2018-359ecb038de9#0534), a delegate has authority to sign blocks on behalf of the staker%E2%80%99s owner. Payout to the delegate is subject to the delegate_payout_pcm value.%0A     %C2%B7  %3Cb%3Econtroller_key%3C/b%3E: %5Bstring%5D Hex encoded 66 character (33 byte) hash of the staker%E2%80%99s controller key. As described in %5BSDBS 003%5D(https://medium.com/stealthsend/stealth-development-blog-003-12-21-2018-c1af967b108e), a controller can enable and disable a staker for purposes like failover safety.%0A%0A%E2%80%A2 \n+ontroller_key. This object is described below under the heading Keys Object%0A*\n  %3Cb%3E\n@@ -6803,16 +6803,19 @@\n ercent (\n+%3Ci%3E\n per cent\n@@ -6820,16 +6820,20 @@\n nt mille\n+%3C/i%3E\n , pcm). \n@@ -6881,18 +6881,17 @@\n 00,000.%0A\n-%E2%80%A2 \n+*\n  %3Cb%3Etota\n@@ -7000,18 +7000,17 @@\n legate.%0A\n-%E2%80%A2 \n+*\n  %3Cb%3Ebloc\n@@ -7065,34 +7065,33 @@\n  by the staker.%0A\n-%E2%80%A2 \n+*\n  %3Cb%3Eblocks_misse\n@@ -7142,18 +7142,17 @@\n staker.%0A\n-%E2%80%A2 \n+*\n  %3Cb%3Ebloc\n@@ -7235,18 +7235,17 @@\n issed).%0A\n-%E2%80%A2 \n+*\n  %3Cb%3Ebloc\n@@ -7393,18 +7393,17 @@\n blocks.%0A\n-%E2%80%A2 \n+*\n  %3Cb%3Eprev\n@@ -7962,17 +7962,17 @@\n a block.\n-%0A\n+ \n See %5BSDB\n@@ -8065,16 +8065,16 @@\n de9#\n-0534).%0A%E2%80%A2\n+3991).%0A*\n  %3Cb%3E\n@@ -8812,18 +8812,17 @@\n etween.%0A\n-%E2%80%A2 \n+*\n  %3Cb%3Eprev\n@@ -9054,141 +9054,637 @@\n text\n-%0A%0A* %3Cb%3Ebalances%3C/b%3E: %5Bobject%5D Represents the balances tracked in the registry ledger, which stores payouts to\n+.%0A%0A%0A%3Cb%3E%3Ch3%3EKeys Object%3C/h3%3E%3C/b%3E%0A* %3Cb%3Eowner_key%3C/b%3E: %5Bstring%5D Hex encoded 66 character (33 byte) hash of the staker%E2%80%99s owner key. The owner key can change all three authority keys. If the owner key is changed, it transfers ownership. Payout from block rewards is indicated by the %60delegate_payout_pcm%60 value, described below.%0A* %3Cb%3Edelegate_key%3C/b%3E: %5Bstring%5D Hex encoded 66 character (33 byte) hash of the staker%E2%80%99s delegate key. As described in %5BSDBS 001%5D(https://medium.com/stealthsend/stealth-development-blog-001-12-7-2018-359ecb038de9#3991), a delegate has authority to sign blocks on behalf of the\n  staker\n+%E2%80%99s\n  owner\n-s and\n+. Payout to\n  the\n-ir\n  del\n@@ -9692,119 +9692,390 @@\n gate\n-s. JSON keys are pubkeys (hex encoded 66 character strings). Each component object has the following keys:%0A   %E2%80%A2\n+ is subject to the %60delegate_payout_pcm%60 value.%0A* %3Cb%3Econtroller_key%3C/b%3E: %5Bstring%5D Hex encoded 66 character (33 byte) hash of the staker%E2%80%99s controller key. As described in %5BSDBS 003%5D(https://medium.com/stealthsend/stealth-development-blog-003-12-21-2018-c1af967b108e), a controller can enable and disable a staker for purposes like failover safety.%0A%0A%0A%3Cb%3E%3Ch3%3EBalances Object%3C/h3%3E%3C/b%3E%0A*\n  %3Cb%3E\n@@ -10142,20 +10142,17 @@\n pubkey.%0A\n-   %E2%80%A2\n+*\n  %3Cb%3Elast\n@@ -10161,16 +10161,17 @@\n laim%3C/b%3E\n+:\n  %5Bintege\n@@ -10769,12 +10769,9 @@\n ol.%0A\n-   %E2%80%A2\n+*\n  %3Cb%3E\n@@ -10974,17 +10974,16 @@\n e key.%0A%0A\n-%0A\n %E2%80%93%E2%80%93%E2%80%93%E2%80%93%E2%80%93%0A%0AH\n",
      "json_metadata": "{\"tags\":[\"blockchain\",\"bitcoin\",\"cryptocurrency\",\"stealth\",\"privacy\"],\"image\":[\"https://i.imgsafe.org/06/0658503a2e.jpeg\",\"https://i.imgsafe.org/06/06596ce829.jpeg\"],\"links\":[\"https://medium.com/stealthsend/stealth-development-blog-009-02-08-2019-6832e71ba658\",\"https://gist.github.com/StealthSend/8fc665fe06173e23ef85f5b9475e6739\",\"https://medium.com/stealthsend/stealth-development-blog-001-12-7-2018-359ecb038de9\",\"https://github.com/StealthSend/Stealth/wiki/Stealth-Quantum-PoS-(qPoS)\",\"https://medium.com/stealthsend/stealth-development-blog-001-12-7-2018-359ecb038de9#3991\",\"https://medium.com/stealthsend/stealth-development-blog-003-12-21-2018-c1af967b108e\",\"https://en.wikipedia.org/wiki/Unspent_transaction_output\",\"https://github.com/StealthSend/Stealth/wiki/Stealth-Quantum-PoS-(qPoS)#using-a-hybrid-ledger-to-improve-economics-and-throughput\",\"https://www.stealth.org\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}"
    }
  ]
}

{
  "trx_id": "9381dba444b91620bb5a515332a0d487a3c7d709",
  "block": 30583205,
  "trx_in_block": 3,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-22T23:10:27",
  "op": [
    "vote",
    {
      "voter": "hodlcoin",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-011-02-22-2019",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "6bde206aec590313c06ad74c869b92cad69050cc",
  "block": 30582597,
  "trx_in_block": 20,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-22T22:40:03",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "blockchain",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-011-02-22-2019",
      "title": "Stealth Development Blog 011: 02/22/2019",
      "body": "@@ -2760,17 +2760,19 @@\n ock.%0A%0A* \n- \n+%3Cb%3E\n in_repla\n",
      "json_metadata": "{\"tags\":[\"blockchain\",\"bitcoin\",\"cryptocurrency\",\"stealth\",\"privacy\"],\"image\":[\"https://i.imgsafe.org/06/0658503a2e.jpeg\",\"https://i.imgsafe.org/06/06596ce829.jpeg\"],\"links\":[\"https://medium.com/stealthsend/stealth-development-blog-009-02-08-2019-6832e71ba658\",\"https://gist.github.com/StealthSend/8fc665fe06173e23ef85f5b9475e6739\",\"https://medium.com/stealthsend/stealth-development-blog-001-12-7-2018-359ecb038de9\",\"https://github.com/StealthSend/Stealth/wiki/Stealth-Quantum-PoS-(qPoS)\",\"https://medium.com/stealthsend/stealth-development-blog-001-12-7-2018-359ecb038de9#0534\",\"https://medium.com/stealthsend/stealth-development-blog-003-12-21-2018-c1af967b108e\",\"https://en.wikipedia.org/wiki/Unspent_transaction_output\",\"https://github.com/StealthSend/Stealth/wiki/Stealth-Quantum-PoS-(qPoS)#using-a-hybrid-ledger-to-improve-economics-and-throughput\",\"https://www.stealth.org\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}"
    }
  ]
}

{
  "trx_id": "b120d7ba23e7e22f1632a94db05380e80ac44e67",
  "block": 30582579,
  "trx_in_block": 10,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-22T22:39:09",
  "op": [
    "vote",
    {
      "voter": "hamsa.quality",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-011-02-22-2019",
      "weight": 110
    }
  ]
}

{
  "trx_id": "df5333ba16fb2f83d29718c12ae7f5986eda475d",
  "block": 30582578,
  "trx_in_block": 2,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-22T22:39:06",
  "op": [
    "vote",
    {
      "voter": "nanobot",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-011-02-22-2019",
      "weight": 500
    }
  ]
}

{
  "trx_id": "7be893b37bef95b1dd3d325b9a12cb79ddb8a2e3",
  "block": 30582576,
  "trx_in_block": 44,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-22T22:39:00",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "blockchain",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-011-02-22-2019",
      "title": "Stealth Development Blog 011: 02/22/2019",
      "body": "@@ -2667,16 +2667,17 @@\n .%0A%0A* %3Cb%3E\n+b\n lock_has\n",
      "json_metadata": "{\"tags\":[\"blockchain\",\"bitcoin\",\"cryptocurrency\",\"stealth\",\"privacy\"],\"image\":[\"https://i.imgsafe.org/06/0658503a2e.jpeg\",\"https://i.imgsafe.org/06/06596ce829.jpeg\"],\"links\":[\"https://medium.com/stealthsend/stealth-development-blog-009-02-08-2019-6832e71ba658\",\"https://gist.github.com/StealthSend/8fc665fe06173e23ef85f5b9475e6739\",\"https://medium.com/stealthsend/stealth-development-blog-001-12-7-2018-359ecb038de9\",\"https://github.com/StealthSend/Stealth/wiki/Stealth-Quantum-PoS-(qPoS)\",\"https://medium.com/stealthsend/stealth-development-blog-001-12-7-2018-359ecb038de9#0534\",\"https://medium.com/stealthsend/stealth-development-blog-003-12-21-2018-c1af967b108e\",\"https://en.wikipedia.org/wiki/Unspent_transaction_output\",\"https://github.com/StealthSend/Stealth/wiki/Stealth-Quantum-PoS-(qPoS)#using-a-hybrid-ledger-to-improve-economics-and-throughput\",\"https://www.stealth.org\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}"
    }
  ]
}

{
  "trx_id": "5e7d1befde43274aab0e558ab33f16dc2902f1c2",
  "block": 30582559,
  "trx_in_block": 8,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-22T22:38:09",
  "op": [
    "vote",
    {
      "voter": "bukiland",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-011-02-22-2019",
      "weight": 100
    }
  ]
}

{
  "trx_id": "05a110a84a11ae87c48cff5487febc4d71af8574",
  "block": 30582546,
  "trx_in_block": 1,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-22T22:37:30",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "blockchain",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-011-02-22-2019",
      "title": "Stealth Development Blog 011: 02/22/2019",
      "body": "https://i.imgsafe.org/06/0658503a2e.jpeg\n\n<b><h1>Stealth qPoS Enters Testing</h1></b>\nToday, I am excited to say that after a painful week of fixing compiling errors, we have the first functional build of the qPoS client. Not only does it build without error, but as of a few hours ago, it has created a testnet genesis block, meaning that the Internal Testnet is operational.\n\n–––––\n\n<b><h1>Development Wish List</h1></b>\nThe path to mainnet (i.e. my wish list) is outlined in [SDBS 009](https://medium.com/stealthsend/stealth-development-blog-009-02-08-2019-6832e71ba658) and is summarized as follows:\n\n☑ Implement the RPC commands.\n☑ Build the client (debug the compiling process).\n☑ Get it to run and create a testnet genesis block (meaning it can boot!).\n☒ Run the Internal Testnet that tests all functionalities of the client.\n☐ Implement blockwise Byzantine fault tolerance (BFT) .\n☐ Public Testnet Phase 1, with code publication to github\n☐ Public Testnet Phase 2\n☐ Staker bad behavior controls and maybe qPoS GUI\n☐ Public Testnet Phase 3 with participation incentives (KYC applies)\n☐ Main Net Release\n\nKey\n☐ – Not started yet\n☒ – In progress\n☑ – Complete\n\nNote that all disclaimers in [SDBS 009](https://medium.com/stealthsend/stealth-development-blog-009-02-08-2019-6832e71ba658) still apply.\n\nhttps://i.imgsafe.org/06/06596ce829.jpeg\n–––––\n\n\n<b><h1>Pseudo-Schema of `getqposinfo` JSON Output</h1></b>\nEven though debugging a build with so much new code takes a lot of work, it doesn’t catalyze much in the way of design decisions or new functionalities. Also, I want to get to testing my new creation ASAP, so I don’t feel like writing a long-winded post about cryptocurrency concepts today.\n\nInstead, I present a detailed description and pseudo-schema for `getqposinfo`, which will be highly useful for third party service providers. After all, the SDBS is meant to document as much as give updates on progress. The material for this documentation comes from the fact that I needed to document the output of the most useful informational qPoS RPC command, `getqposinfo` for a third party who may (no promises!) be working with Stealth on app development.\n\nPlease note that I published a mock-up of the output of `getqposinfo` as a [github gist](https://gist.github.com/StealthSend/8fc665fe06173e23ef85f5b9475e6739). The entire output of `getqposinfo` is a single JSON object with the following hierarchy:\n\n*  <b>version</b>: [integer] This top-level version is the registry data structure version, and may give an indication of available JSON fields in the future.\n\n* <b>block_height</b>: [integer] Height of latest block to which the registry is updated.\n\n* <b>lock_hash</b>: [string] Hex encoded 64 character (32 byte/256 bit) hash of latest block.\n\n*  in_replay</b>: [bool] This value is `true` if the registry is being replayed, which happens during restart and reorganization of the chain.\n\n*  <b>counter_next</b>: [integer] Next staker ID for a newly created staker.\n\n*  <b>current_block_was_produced</b>: [bool] Each slot corresponds to a block that should be produced, but may not be produced if a staker missed it. This field will be `true` if a staker has produced a block for the current time slot of the queue. The staker registry is updated in real time. When a time slot has expired and a new block has not yet been produced by the assigned staker, this field will have a value of `false`.\n\n*  <b>prev_block_was_produced</b>: [bool] Whether the block for the previous time slot was produced. The concept of previous blocks is discussed below for `prev_blocks_missed` and in [SDBS 001](https://medium.com/stealthsend/stealth-development-blog-001-12-7-2018-359ecb038de9), in the context of discouraging staker timestamp attacks.\n\n*  <b>current_slot</b>: [integer] Each slot of the queue schedule has an index, starting with 0. The value of `current_slot` is the index of the current slot in the queue. The queue is described below.\n\n*  <b>staker_price</b>: [float] Real-time price of a staker in XST. The price fluctuates from block to block.\n\n*  <b>queue</b>: [array of objects] Represents the current round of staking where stakers are pseudo-randomly shuffled, signing blocks in shuffled order. Each component object of this array has the following keys:\n    • <b>id</b>: [integer] Staker ID, which is a unique number from an increment counter tracked by the registry.\n    • <b>start_time</b>: [integer] Timestamp (seconds) of the start of the slot.\n    • <b>end_time</b>: [integer] Timestamp (seconds) of the end of the slot.\n\n*   <b>stakers</b>: [object] An object with staker IDs as keys. Although IDs are integers, as JSON keys, they must be represented as strings. Each component object represents a staker and has the following keys\n    • <b>alias</b>: [string] Unique, case-sensitive staker alias, as assigned by the registrant, and can never change.\n    • <b>id</b>: [integer] Staker ID.\n    • <b>version</b>: Version of the staker data structure, and may give an indication of the available staker fields in the future.\n• <b>qualified</b>: [bool] If `false` (rare), the staker will be terminated and purged from the registry at the end of the current round. Staking rounds are tracked in the queue, described above.\n• <b>enabled</b>: [bool] Stakers can be enabled (`true`) and disabled (`false`). A disabled staker is essentially in hibernation. A disabled staker will not be assigned a position in the queue, will not be penalized for missing blocks, and will not earn any block rewards.\n• <b>weight</b>: [integer] Payout and chain trust multiplier, each staker has a potentially unique multiplier. As described in the [Whitepaper](https://github.com/StealthSend/Stealth/wiki/Stealth-Quantum-PoS-(qPoS)), weight is proportional to the staker’s net blocks produced, where each missed block is subtracted from the total produced. A staker earns rewards proportional to its weight. Additionally, chain trust is additive, where the weight of a staker producing a block is the block’s trust.\n•  <b>keys</b>: [object] Describes the authority keys for a staker. This object has the following JSON keys:\n    ·  <b>owner_key</b>: [string] Hex encoded 66 character (33 byte) hash of the staker’s owner key. The owner key can change all three authority keys. If the owner key is changed, it transfers ownership. Payout from block rewards is indicated by the `delegate_payout_pcm` value, described below.\n     ·  <b>delegate_key</b>: [string] Hex encoded 66 character (33 byte) hash of the staker’s delegate key. As described in [SDBS 001](https://medium.com/stealthsend/stealth-development-blog-001-12-7-2018-359ecb038de9#0534), a delegate has authority to sign blocks on behalf of the staker’s owner. Payout to the delegate is subject to the delegate_payout_pcm value.\n     ·  <b>controller_key</b>: [string] Hex encoded 66 character (33 byte) hash of the staker’s controller key. As described in [SDBS 003](https://medium.com/stealthsend/stealth-development-blog-003-12-21-2018-c1af967b108e), a controller can enable and disable a staker for purposes like failover safety.\n\n•  <b>delegate_payout_pcm</b>: [integer] Fraction of rewards paid to delegate in milli-percent (per cent mille, pcm). E.g. 10,000 pcm = 10%. Maximum value is 100,000.\n•  <b>total_earned</b>: [integer] Total XST earned by the staker. This includes payouts to both the owner and delegate.\n•  <b>blocks_produced</b>: [integer] Total blocks produced by the staker.\n•  <b>blocks_missed</b>: [integer] Total blocks missed by the staker.\n•  <b>blocks_assigned</b>: [integer] Total blocks assigned to the staker (produced + missed).\n•  <b>blocks_seen</b>: [integer] Total blocks that have been added to the chain since the staker was created. This value is “how old the staker is” in blocks.\n•  <b>prev_blocks_missed</b>: [integer] Total blocks missed by the staker in the slot immediately prior in the queue. Every round a new queue is made with stakers in pseudo-random order. A staker is immediately prior (\"previous\") to another if it comes in the queue exactly one slot earlier, meaning the identity of a “previous” staker will vary according to the pseudo-random ordering of the queue. The qPoS protocol tracks misses of \"previous\" stakers because a staker can behave badly to attempt to fool the network into thinking the \"previous\" staker missed a block.\nSee [SDBS 001](https://medium.com/stealthsend/stealth-development-blog-001-12-7-2018-359ecb038de9#0534).\n• <b>recent_blocks</b>: [array of integers] Components of this array are 1 or 0, exclusively. The value 1 means the staker produced its assigned block. The value 0 means the staker missed its assigned block. This array is in reverse-chronological order where more recent blocks have lower indices in the array. These blocks are based on assignments to the specific staker, and are not contiguous. In other words the block represented by element 0 in the `recent_blocks` array does not necessarily immediately follow (in the blockchain) the block corresponding to element 1. For example, if element 0 represents block 1000, element 1 may represent block 970, if both blocks 1000 and 970 were assigned to the staker, with no assignments between.\n•  <b>prev_recent_blocks</b>: [array of integers] Similar to `recent_blocks`, but representing the blocks assigned to the staker’s previous slots. See the `prev_blocks_missed` description above for the meaning of “previous” in this context\n\n* <b>balances</b>: [object] Represents the balances tracked in the registry ledger, which stores payouts to staker owners and their delegates. JSON keys are pubkeys (hex encoded 66 character strings). Each component object has the following keys:\n   • <b>balance</b>: [float] The unclaimed balance belonging to the pubkey.\n   • <b>last_claim</b> [integer] Timestamp (seconds) of the last claim of this pubkey’s balance. Each pubkey can make a claim no more frequently than every 24 hours. The reason for this imposed infrequency is that each claim creates a new [UTXO](https://en.wikipedia.org/wiki/Unspent_transaction_output). So, to allow unlimited claims would defeat the purpose of qPoS’s [hybrid ledger](https://github.com/StealthSend/Stealth/wiki/Stealth-Quantum-PoS-(qPoS)#using-a-hybrid-ledger-to-improve-economics-and-throughput), which has as one component a registry ledger with no UTXOs. This maximizes efficiency of the qPoS protocol.\n   • <b>active_count</b>: [integer] Each pubkey can be associated with any number of owners and delegates. The `active_count` keeps track of how many extant staker owners plus delegates are assigned to the key.\n\n\n–––––\n\nHondo\n\nhttps://www.stealth.org",
      "json_metadata": "{\"tags\":[\"blockchain\",\"bitcoin\",\"cryptocurrency\",\"stealth\",\"privacy\"],\"image\":[\"https://i.imgsafe.org/06/0658503a2e.jpeg\",\"https://i.imgsafe.org/06/06596ce829.jpeg\"],\"links\":[\"https://medium.com/stealthsend/stealth-development-blog-009-02-08-2019-6832e71ba658\",\"https://gist.github.com/StealthSend/8fc665fe06173e23ef85f5b9475e6739\",\"https://medium.com/stealthsend/stealth-development-blog-001-12-7-2018-359ecb038de9\",\"https://github.com/StealthSend/Stealth/wiki/Stealth-Quantum-PoS-(qPoS)\",\"https://medium.com/stealthsend/stealth-development-blog-001-12-7-2018-359ecb038de9#0534\",\"https://medium.com/stealthsend/stealth-development-blog-003-12-21-2018-c1af967b108e\",\"https://en.wikipedia.org/wiki/Unspent_transaction_output\",\"https://github.com/StealthSend/Stealth/wiki/Stealth-Quantum-PoS-(qPoS)#using-a-hybrid-ledger-to-improve-economics-and-throughput\",\"https://www.stealth.org\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}"
    }
  ]
}

{
  "trx_id": "6f6bac9a079f8f7e3b03f133ae82356014c35fde",
  "block": 30582476,
  "trx_in_block": 0,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-22T22:34:00",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "blockchain",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-011-02-22-2019",
      "title": "Stealth Development Blog 011: 02/22/2019",
      "body": "@@ -8349,17 +8349,17 @@\n a block.\n- \n+%0A\n See %5BSDB\n",
      "json_metadata": "{\"tags\":[\"blockchain\",\"bitcoin\",\"cryptocurrency\",\"stealth\",\"privacy\"],\"image\":[\"https://i.imgsafe.org/06/0658503a2e.jpeg\",\"https://i.imgsafe.org/06/06596ce829.jpeg\"],\"links\":[\"https://medium.com/stealthsend/stealth-development-blog-009-02-08-2019-6832e71ba658\",\"https://gist.github.com/StealthSend/8fc665fe06173e23ef85f5b9475e6739\",\"https://medium.com/stealthsend/stealth-development-blog-001-12-7-2018-359ecb038de9\",\"https://github.com/StealthSend/Stealth/wiki/Stealth-Quantum-PoS-(qPoS)\",\"https://medium.com/stealthsend/stealth-development-blog-001-12-7-2018-359ecb038de9#0534\",\"https://medium.com/stealthsend/stealth-development-blog-003-12-21-2018-c1af967b108e\",\"https://en.wikipedia.org/wiki/Unspent_transaction_output\",\"https://github.com/StealthSend/Stealth/wiki/Stealth-Quantum-PoS-(qPoS)#using-a-hybrid-ledger-to-improve-economics-and-throughput\",\"https://www.stealth.org\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}"
    }
  ]
}

{
  "trx_id": "b7b8cfff1d1bec3faa9e619719b2dee6757168c0",
  "block": 30582451,
  "trx_in_block": 2,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-22T22:32:45",
  "op": [
    "vote",
    {
      "voter": "steeming-hot",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-011-02-22-2019",
      "weight": 5
    }
  ]
}

{
  "trx_id": "678ca27de81b8b394879dee36823e9a58c06523b",
  "block": 30582435,
  "trx_in_block": 7,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-22T22:31:57",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "blockchain",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-011-02-22-2019",
      "title": "Stealth Development Blog 011: 02/22/2019",
      "body": "https://i.imgsafe.org/06/0658503a2e.jpeg\n\n<b><h1>Stealth qPoS Enters Testing</h1></b>\nToday, I am excited to say that after a painful week of fixing compiling errors, we have the first functional build of the qPoS client. Not only does it build without error, but as of a few hours ago, it has created a testnet genesis block, meaning that the Internal Testnet is operational.\n\n–––––\n\n<b><h1>Development Wish List</h1></b>\nThe path to mainnet (i.e. my wish list) is outlined in [SDBS 009](https://medium.com/stealthsend/stealth-development-blog-009-02-08-2019-6832e71ba658) and is summarized as follows:\n\n☑ Implement the RPC commands.\n☑ Build the client (debug the compiling process).\n☑ Get it to run and create a testnet genesis block (meaning it can boot!).\n☒ Run the Internal Testnet that tests all functionalities of the client.\n☐ Implement blockwise Byzantine fault tolerance (BFT) .\n☐ Public Testnet Phase 1, with code publication to github\n☐ Public Testnet Phase 2\n☐ Staker bad behavior controls and maybe qPoS GUI\n☐ Public Testnet Phase 3 with participation incentives (KYC applies)\n☐ Main Net Release\n\nKey\n☐ – Not started yet\n☒ – In progress\n☑ – Complete\n\nNote that all disclaimers in [SDBS 009](https://medium.com/stealthsend/stealth-development-blog-009-02-08-2019-6832e71ba658) still apply.\n\nhttps://i.imgsafe.org/06/06596ce829.jpeg\n–––––\n\n\n<b><h1>Pseudo-Schema of `getqposinfo` JSON Output</h1></b>\nEven though debugging a build with so much new code takes a lot of work, it doesn’t catalyze much in the way of design decisions or new functionalities. Also, I want to get to testing my new creation ASAP, so I don’t feel like writing a long-winded post about cryptocurrency concepts today.\n\nInstead, I present a detailed description and pseudo-schema for `getqposinfo`, which will be highly useful for third party service providers. After all, the SDBS is meant to document as much as give updates on progress. The material for this documentation comes from the fact that I needed to document the output of the most useful informational qPoS RPC command, `getqposinfo` for a third party who may (no promises!) be working with Stealth on app development.\n\nPlease note that I published a mock-up of the output of `getqposinfo` as a [github gist](https://gist.github.com/StealthSend/8fc665fe06173e23ef85f5b9475e6739). The entire output of `getqposinfo` is a single JSON object with the following hierarchy:\n\n*  <b>version</b>: [integer] This top-level version is the registry data structure version, and may give an indication of available JSON fields in the future.\n\n* <b>block_height</b>: [integer] Height of latest block to which the registry is updated.\n\n* <b>lock_hash</b>: [string] Hex encoded 64 character (32 byte/256 bit) hash of latest block.\n\n*  in_replay</b>: [bool] This value is `true` if the registry is being replayed, which happens during restart and reorganization of the chain.\n\n*  <b>counter_next</b>: [integer] Next staker ID for a newly created staker.\n\n*  <b>current_block_was_produced</b>: [bool] Each slot corresponds to a block that should be produced, but may not be produced if a staker missed it. This field will be `true` if a staker has produced a block for the current time slot of the queue. The staker registry is updated in real time. When a time slot has expired and a new block has not yet been produced by the assigned staker, this field will have a value of `false`.\n\n*  <b>prev_block_was_produced</b>: [bool] Whether the block for the previous time slot was produced. The concept of previous blocks is discussed below for `prev_blocks_missed` and in [SDBS 001](https://medium.com/stealthsend/stealth-development-blog-001-12-7-2018-359ecb038de9), in the context of discouraging staker timestamp attacks.\n\n*  <b>current_slot</b>: [integer] Each slot of the queue schedule has an index, starting with 0. The value of `current_slot` is the index of the current slot in the queue. The queue is described below.\n\n*  <b>staker_price</b>: [float] Real-time price of a staker in XST. The price fluctuates from block to block.\n\n*  <b>queue</b>: [array of objects] Represents the current round of staking where stakers are pseudo-randomly shuffled, signing blocks in shuffled order. Each component object of this array has the following keys:\n    • <b>id</b>: [integer] Staker ID, which is a unique number from an increment counter tracked by the registry.\n    • <b>start_time</b>: [integer] Timestamp (seconds) of the start of the slot.\n    • <b>end_time</b>: [integer] Timestamp (seconds) of the end of the slot.\n\n*   <b>stakers</b>: [object] An object with staker IDs as keys. Although IDs are integers, as JSON keys, they must be represented as strings. Each component object represents a staker and has the following keys\n    • <b>alias</b>: [string] Unique, case-sensitive staker alias, as assigned by the registrant, and can never change.\n    • <b>id</b>: [integer] Staker ID.\n    • <b>version</b>: Version of the staker data structure, and may give an indication of the available staker fields in the future.\n• <b>qualified</b>: [bool] If `false` (rare), the staker will be terminated and purged from the registry at the end of the current round. Staking rounds are tracked in the queue, described above.\n• <b>enabled</b>: [bool] Stakers can be enabled (`true`) and disabled (`false`). A disabled staker is essentially in hibernation. A disabled staker will not be assigned a position in the queue, will not be penalized for missing blocks, and will not earn any block rewards.\n• <b>weight</b>: [integer] Payout and chain trust multiplier, each staker has a potentially unique multiplier. As described in the [Whitepaper](https://github.com/StealthSend/Stealth/wiki/Stealth-Quantum-PoS-(qPoS)), weight is proportional to the staker’s net blocks produced, where each missed block is subtracted from the total produced. A staker earns rewards proportional to its weight. Additionally, chain trust is additive, where the weight of a staker producing a block is the block’s trust.\n•  <b>keys</b>: [object] Describes the authority keys for a staker. This object has the following JSON keys:\n    ·  <b>owner_key</b>: [string] Hex encoded 66 character (33 byte) hash of the staker’s owner key. The owner key can change all three authority keys. If the owner key is changed, it transfers ownership. Payout from block rewards is indicated by the `delegate_payout_pcm` value, described below.\n     ·  <b>delegate_key</b>: [string] Hex encoded 66 character (33 byte) hash of the staker’s delegate key. As described in [SDBS 001](https://medium.com/stealthsend/stealth-development-blog-001-12-7-2018-359ecb038de9#0534), a delegate has authority to sign blocks on behalf of the staker’s owner. Payout to the delegate is subject to the delegate_payout_pcm value.\n     ·  <b>controller_key</b>: [string] Hex encoded 66 character (33 byte) hash of the staker’s controller key. As described in [SDBS 003](https://medium.com/stealthsend/stealth-development-blog-003-12-21-2018-c1af967b108e), a controller can enable and disable a staker for purposes like failover safety.\n\n•  <b>delegate_payout_pcm</b>: [integer] Fraction of rewards paid to delegate in milli-percent (per cent mille, pcm). E.g. 10,000 pcm = 10%. Maximum value is 100,000.\n•  <b>total_earned</b>: [integer] Total XST earned by the staker. This includes payouts to both the owner and delegate.\n•  <b>blocks_produced</b>: [integer] Total blocks produced by the staker.\n•  <b>blocks_missed</b>: [integer] Total blocks missed by the staker.\n•  <b>blocks_assigned</b>: [integer] Total blocks assigned to the staker (produced + missed).\n•  <b>blocks_seen</b>: [integer] Total blocks that have been added to the chain since the staker was created. This value is “how old the staker is” in blocks.\n•  <b>prev_blocks_missed</b>: [integer] Total blocks missed by the staker in the slot immediately prior in the queue. Every round a new queue is made with stakers in pseudo-random order. A staker is immediately prior (\"previous\") to another if it comes in the queue exactly one slot earlier, meaning the identity of a “previous” staker will vary according to the pseudo-random ordering of the queue. The qPoS protocol tracks misses of \"previous\" stakers because a staker can behave badly to attempt to fool the network into thinking the \"previous\" staker missed a block. See [SDBS 001](https://medium.com/stealthsend/stealth-development-blog-001-12-7-2018-359ecb038de9#0534).\n• <b>recent_blocks</b>: [array of integers] Components of this array are 1 or 0, exclusively. The value 1 means the staker produced its assigned block. The value 0 means the staker missed its assigned block. This array is in reverse-chronological order where more recent blocks have lower indices in the array. These blocks are based on assignments to the specific staker, and are not contiguous. In other words the block represented by element 0 in the `recent_blocks` array does not necessarily immediately follow (in the blockchain) the block corresponding to element 1. For example, if element 0 represents block 1000, element 1 may represent block 970, if both blocks 1000 and 970 were assigned to the staker, with no assignments between.\n•  <b>prev_recent_blocks</b>: [array of integers] Similar to `recent_blocks`, but representing the blocks assigned to the staker’s previous slots. See the `prev_blocks_missed` description above for the meaning of “previous” in this context\n\n* <b>balances</b>: [object] Represents the balances tracked in the registry ledger, which stores payouts to staker owners and their delegates. JSON keys are pubkeys (hex encoded 66 character strings). Each component object has the following keys:\n   • <b>balance</b>: [float] The unclaimed balance belonging to the pubkey.\n   • <b>last_claim</b> [integer] Timestamp (seconds) of the last claim of this pubkey’s balance. Each pubkey can make a claim no more frequently than every 24 hours. The reason for this imposed infrequency is that each claim creates a new [UTXO](https://en.wikipedia.org/wiki/Unspent_transaction_output). So, to allow unlimited claims would defeat the purpose of qPoS’s [hybrid ledger](https://github.com/StealthSend/Stealth/wiki/Stealth-Quantum-PoS-(qPoS)#using-a-hybrid-ledger-to-improve-economics-and-throughput), which has as one component a registry ledger with no UTXOs. This maximizes efficiency of the qPoS protocol.\n   • <b>active_count</b>: [integer] Each pubkey can be associated with any number of owners and delegates. The `active_count` keeps track of how many extant staker owners plus delegates are assigned to the key.\n\n\n–––––\n\nHondo\n\nhttps://www.stealth.org",
      "json_metadata": "{\"tags\":[\"blockchain\",\"bitcoin\",\"cryptocurrency\",\"stealth\",\"privacy\"],\"image\":[\"https://i.imgsafe.org/06/0658503a2e.jpeg\",\"https://i.imgsafe.org/06/06596ce829.jpeg\"],\"links\":[\"https://medium.com/stealthsend/stealth-development-blog-009-02-08-2019-6832e71ba658\",\"https://gist.github.com/StealthSend/8fc665fe06173e23ef85f5b9475e6739\",\"https://medium.com/stealthsend/stealth-development-blog-001-12-7-2018-359ecb038de9\",\"https://github.com/StealthSend/Stealth/wiki/Stealth-Quantum-PoS-(qPoS)\",\"https://medium.com/stealthsend/stealth-development-blog-001-12-7-2018-359ecb038de9#0534\",\"https://medium.com/stealthsend/stealth-development-blog-003-12-21-2018-c1af967b108e\",\"https://en.wikipedia.org/wiki/Unspent_transaction_output\",\"https://github.com/StealthSend/Stealth/wiki/Stealth-Quantum-PoS-(qPoS)#using-a-hybrid-ledger-to-improve-economics-and-throughput\",\"https://www.stealth.org\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}"
    }
  ]
}

{
  "trx_id": "0000000000000000000000000000000000000000",
  "block": 30582020,
  "trx_in_block": 4294967295,
  "op_in_trx": 0,
  "virtual_op": 4,
  "timestamp": "2019-02-22T22:11:12",
  "op": [
    "author_reward",
    {
      "author": "stealthsend",
      "permlink": "stealth-development-blog-010-02-15-2019",
      "sbd_payout": "0.021 SBD",
      "steem_payout": "0.000 STEEM",
      "vesting_payout": "130.261618 VESTS"
    }
  ]
}

{
  "trx_id": "727e994de1b7a7cc6fbbc84e27545b088935954b",
  "block": 30425374,
  "trx_in_block": 2,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-17T11:33:24",
  "op": [
    "comment",
    {
      "parent_author": "stealthsend",
      "parent_permlink": "stealth-development-blog-010-02-15-2019",
      "author": "steemcleaner",
      "permlink": "re-stealthsend-stealth-development-blog-010-02-15-2019-20190217t113322236z",
      "title": "",
      "body": "!cheetah unban\nUser verified authorship.",
      "json_metadata": "{\"app\":\"steemcleaners/0.3\",\"format\":\"markdown+html\",\"community\":\"steemcleaners\"}"
    }
  ]
}

{
  "trx_id": "b60b4d973002cbc4b6672ae0bfdd478839e0ee9a",
  "block": 30411836,
  "trx_in_block": 8,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-17T00:16:00",
  "op": [
    "vote",
    {
      "voter": "jamesstroud",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-010-02-15-2019",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "42e95d0d2cd6c3c7648b1287c8b3b676056a6715",
  "block": 30382510,
  "trx_in_block": 27,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-15T23:48:48",
  "op": [
    "comment",
    {
      "parent_author": "stealthsend",
      "parent_permlink": "stealth-development-blog-010-02-15-2019",
      "author": "steemitboard",
      "permlink": "steemitboard-notify-stealthsend-20190215t234850000z",
      "title": "",
      "body": "Congratulations @stealthsend! You have completed the following achievement on the Steem blockchain and have been rewarded with new badge(s) :\n\n<table><tr><td>https://steemitimages.com/60x70/http://steemitboard.com/@stealthsend/posts.png?201902152312</td><td>You published more than 20 posts. Your next target is to reach 30 posts.</td></tr>\n</table>\n\n<sub>_[Click here to view your Board](https://steemitboard.com/@stealthsend)_</sub>\n<sub>_If you no longer want to receive notifications, reply to this comment with the word_ `STOP`</sub>\n\n\n\n**Do not miss the last post from @steemitboard:**\n<table><tr><td><a href=\"https://steemit.com/valentine/@steemitboard/valentine-challenge-love-is-in-the-air\"><img src=\"https://steemitimages.com/64x128/http://i.cubeupload.com/LvDzr5.png\"></a></td><td><a href=\"https://steemit.com/valentine/@steemitboard/valentine-challenge-love-is-in-the-air\">Valentine challenge - Love is in the air!</a></td></tr></table>\n\n> Support [SteemitBoard's project](https://steemit.com/@steemitboard)! **[Vote for its witness](https://v2.steemconnect.com/sign/account-witness-vote?witness=steemitboard&approve=1)** and **get one more award**!",
      "json_metadata": "{\"image\":[\"https://steemitboard.com/img/notify.png\"]}"
    }
  ]
}

{
  "trx_id": "8b1aa009c9e824a6b17105ead547c8efa628aae7",
  "block": 30382177,
  "trx_in_block": 9,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-15T23:32:06",
  "op": [
    "vote",
    {
      "voter": "filipino",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-010-02-15-2019",
      "weight": 1000
    }
  ]
}

{
  "trx_id": "8f3c965dea4a8d91c80030e1e5771ac748cd92ab",
  "block": 30380764,
  "trx_in_block": 18,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-15T22:21:18",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "blockchain",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-010-02-15-2019",
      "title": "Stealth Development Blog 010: 02/15/2019",
      "body": "@@ -9503,16 +9503,22 @@\n p; \n+ \n %60%3Cpayout\n",
      "json_metadata": "{\"tags\":[\"blockchain\",\"bitcoin\",\"cryptocurrency\",\"stealth\",\"privacy\"],\"image\":[\"https://i.imgsafe.org/6f/6ffc93287d.jpeg\",\"https://i.imgsafe.org/73/731761ba96.jpeg\",\"https://i.imgsafe.org/73/7317627587.jpeg\",\"https://i.imgsafe.org/73/7317a912f1.jpeg\"],\"links\":[\"https://medium.com/stealthsend/stealth-development-blog-007-01-25-2019-ba470c1fedd9\",\"https://medium.com/stealthsend/stealth-development-blog-008-02-01-2019-ffd328354496\",\"https://www.json.org/\",\"https://medium.com/stealthsend/stealth-development-blog-001-12-7-2018-359ecb038de9\",\"https://medium.com/stealthsend/stealth-development-blog-003-12-21-2018-c1af967b108e#3681\",\"https://www.stealth.org\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}"
    }
  ]
}

{
  "trx_id": "b22bb136f12644667dc498ad6cbd4d70a0d04296",
  "block": 30380757,
  "trx_in_block": 16,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-15T22:20:57",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "blockchain",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-010-02-15-2019",
      "title": "Stealth Development Blog 010: 02/15/2019",
      "body": "@@ -9503,28 +9503,16 @@\n p; \n-  \n %60%3Cpayout\n",
      "json_metadata": "{\"tags\":[\"blockchain\",\"bitcoin\",\"cryptocurrency\",\"stealth\",\"privacy\"],\"image\":[\"https://i.imgsafe.org/6f/6ffc93287d.jpeg\",\"https://i.imgsafe.org/73/731761ba96.jpeg\",\"https://i.imgsafe.org/73/7317627587.jpeg\",\"https://i.imgsafe.org/73/7317a912f1.jpeg\"],\"links\":[\"https://medium.com/stealthsend/stealth-development-blog-007-01-25-2019-ba470c1fedd9\",\"https://medium.com/stealthsend/stealth-development-blog-008-02-01-2019-ffd328354496\",\"https://www.json.org/\",\"https://medium.com/stealthsend/stealth-development-blog-001-12-7-2018-359ecb038de9\",\"https://medium.com/stealthsend/stealth-development-blog-003-12-21-2018-c1af967b108e#3681\",\"https://www.stealth.org\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}"
    }
  ]
}

{
  "trx_id": "d9c61d1f548670bd1d2f0bb67e0ae36486e547ec",
  "block": 30380746,
  "trx_in_block": 26,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-15T22:20:24",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "blockchain",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-010-02-15-2019",
      "title": "Stealth Development Blog 010: 02/15/2019",
      "body": "@@ -9227,16 +9227,160 @@\n gate%3E %60%0A\n+                        \n  &n\n",
      "json_metadata": "{\"tags\":[\"blockchain\",\"bitcoin\",\"cryptocurrency\",\"stealth\",\"privacy\"],\"image\":[\"https://i.imgsafe.org/6f/6ffc93287d.jpeg\",\"https://i.imgsafe.org/73/731761ba96.jpeg\",\"https://i.imgsafe.org/73/7317627587.jpeg\",\"https://i.imgsafe.org/73/7317a912f1.jpeg\"],\"links\":[\"https://medium.com/stealthsend/stealth-development-blog-007-01-25-2019-ba470c1fedd9\",\"https://medium.com/stealthsend/stealth-development-blog-008-02-01-2019-ffd328354496\",\"https://www.json.org/\",\"https://medium.com/stealthsend/stealth-development-blog-001-12-7-2018-359ecb038de9\",\"https://medium.com/stealthsend/stealth-development-blog-003-12-21-2018-c1af967b108e#3681\",\"https://www.stealth.org\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}"
    }
  ]
}

{
  "trx_id": "dad2aee1e617c83ecfb499e2e12452f0b4870ea8",
  "block": 30380734,
  "trx_in_block": 2,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-15T22:19:48",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "blockchain",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-010-02-15-2019",
      "title": "Stealth Development Blog 010: 02/15/2019",
      "body": "@@ -9227,16 +9227,112 @@\n gate%3E %60%0A\n+                \n  &n\n",
      "json_metadata": "{\"tags\":[\"blockchain\",\"bitcoin\",\"cryptocurrency\",\"stealth\",\"privacy\"],\"image\":[\"https://i.imgsafe.org/6f/6ffc93287d.jpeg\",\"https://i.imgsafe.org/73/731761ba96.jpeg\",\"https://i.imgsafe.org/73/7317627587.jpeg\",\"https://i.imgsafe.org/73/7317a912f1.jpeg\"],\"links\":[\"https://medium.com/stealthsend/stealth-development-blog-007-01-25-2019-ba470c1fedd9\",\"https://medium.com/stealthsend/stealth-development-blog-008-02-01-2019-ffd328354496\",\"https://www.json.org/\",\"https://medium.com/stealthsend/stealth-development-blog-001-12-7-2018-359ecb038de9\",\"https://medium.com/stealthsend/stealth-development-blog-003-12-21-2018-c1af967b108e#3681\",\"https://www.stealth.org\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}"
    }
  ]
}

{
  "trx_id": "61962d9bef82119e9f28554f2d42ea8304d75f8e",
  "block": 30380716,
  "trx_in_block": 4,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-15T22:18:54",
  "op": [
    "vote",
    {
      "voter": "hamsa.quality",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-010-02-15-2019",
      "weight": 110
    }
  ]
}

{
  "trx_id": "93d16741de2b4b605013f5cae20da7eeb99cc4d2",
  "block": 30380693,
  "trx_in_block": 4,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-15T22:17:45",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "blockchain",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-010-02-15-2019",
      "title": "Stealth Development Blog 010: 02/15/2019",
      "body": "@@ -9225,16 +9225,67 @@\n legate%3E \n+%60%0A        %60\n %3Cpayout%3E\n",
      "json_metadata": "{\"tags\":[\"blockchain\",\"bitcoin\",\"cryptocurrency\",\"stealth\",\"privacy\"],\"image\":[\"https://i.imgsafe.org/6f/6ffc93287d.jpeg\",\"https://i.imgsafe.org/73/731761ba96.jpeg\",\"https://i.imgsafe.org/73/7317627587.jpeg\",\"https://i.imgsafe.org/73/7317a912f1.jpeg\"],\"links\":[\"https://medium.com/stealthsend/stealth-development-blog-007-01-25-2019-ba470c1fedd9\",\"https://medium.com/stealthsend/stealth-development-blog-008-02-01-2019-ffd328354496\",\"https://www.json.org/\",\"https://medium.com/stealthsend/stealth-development-blog-001-12-7-2018-359ecb038de9\",\"https://medium.com/stealthsend/stealth-development-blog-003-12-21-2018-c1af967b108e#3681\",\"https://www.stealth.org\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}"
    }
  ]
}

{
  "trx_id": "f02d73f08e1bcdc0f2384762a6cd45a487909af8",
  "block": 30380607,
  "trx_in_block": 22,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-15T22:13:27",
  "op": [
    "vote",
    {
      "voter": "curation.trail",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-010-02-15-2019",
      "weight": 100
    }
  ]
}

{
  "trx_id": "37410dc643707e214bb8eaa7dfebe0fe2b9d592d",
  "block": 30380587,
  "trx_in_block": 25,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-15T22:12:27",
  "op": [
    "vote",
    {
      "voter": "steeming-hot",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-010-02-15-2019",
      "weight": 25
    }
  ]
}

{
  "trx_id": "788012d0cd8568a77ccbcb43dc44cfd9b97b4597",
  "block": 30380568,
  "trx_in_block": 6,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-15T22:11:30",
  "op": [
    "comment",
    {
      "parent_author": "stealthsend",
      "parent_permlink": "stealth-development-blog-010-02-15-2019",
      "author": "cheetah",
      "permlink": "cheetah-re-stealthsendstealth-development-blog-010-02-15-2019",
      "title": "",
      "body": "Warning! This user is on my black list, likely as a known plagiarist, spammer or ID thief. Please be cautious with this post!\nIf you believe this is an error, please chat with us in the #cheetah-appeals channel in [our discord](https://discord.gg/7FkETjJ).",
      "json_metadata": ""
    }
  ]
}

{
  "trx_id": "fce6d3d4bad9150e710d397806a1dd328d63ccb0",
  "block": 30380566,
  "trx_in_block": 32,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-15T22:11:24",
  "op": [
    "vote",
    {
      "voter": "cheetah",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-010-02-15-2019",
      "weight": -8
    }
  ]
}

{
  "trx_id": "4b8b725a17e1dd1d4879414491386031ba5a6b0d",
  "block": 30380562,
  "trx_in_block": 30,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-15T22:11:12",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "blockchain",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-010-02-15-2019",
      "title": "Stealth Development Blog 010: 02/15/2019",
      "body": "https://i.imgsafe.org/6f/6ffc93287d.jpeg\n\n<b><h1>Essential qPoS RPC Commands and Their Implementation</h1></b>\nIn today’s development update, I document the 12 essential RPC (remote procedure calls) required for users to purchase and modify stakers. These commands comprise the full set of commands necessary to query and interact with qPoS stakers and the qPoS ledger (collectively known as the “registry”).\n\nMy work this week represented my final coding push before building and testing the qPoS client. With these RPC commands, the current state of the qPoS code can be considered a complete, albeit very rough codebase. Of course it still needs plenty of organizing, debugging, and likely some new coding before the qPoS is minimally functional. However, I feel like I have hit a significant milestone on the way to qPoS, and am entering a new, phase of development characterized by improving code I have already written.\n\n–––––\n\n<b><h1>Overview of the qPoS RPC Commands</h1></b>\nI will preface documenting the commands by reviewing the structure of those commands that affect changes in the registry. The simplest of these commands, both in terms of syntax and functionality is called `enablestaker`. This command ensures that a staker is enabled to sign blocks, rather than sit dormantly, neither earning rewards nor getting penalized for missing blocks. They syntax of the “enablestaker” command is\n\n&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;`enablestaker <txid> <vout> <alias>`\n\nThe three arguments (“txid”, “vout”, and “alias”) are common to every RPC command that affects changes to the registry. The easiest argument to understand is “alias”, which specifies a staker by the name given to it upon registration. I have described aliases [<b>in a previous post</b>](https://medium.com/stealthsend/stealth-development-blog-007-01-25-2019-ba470c1fedd9), but basically aliases are 3–16 character names that (1) are composed of only numbers and letters, (2) start with a letter, (3) are case sensitive for representation (as when displaying a staker’s info on a web page), and (4) are not case sensitive for identification (as when using RPC commands).\n\nThe other two arguments, “txid” and “vout” specify what is known as an “unspent transaction output” (UTXOs), which is a single amount of unspent funds. I have described the UTXO model elsewhere, most recently [<b>here</b>](https://medium.com/stealthsend/stealth-development-blog-008-02-01-2019-ffd328354496) in the context of the non-hierarchical nature of the blockchain data structure. The “txid” is the transaction ID, and “vout” is the index of a specific output within this transaction that will be spent in the new transaction.\n\nThe specification of a UTXO serves three purposes: (1) it identifies a source of funds for transaction fees or for a purchase (as when buying a staker) and (2) by signing the UTXO, the user proves that they have the authority to execute the change to the registry. In some cases, as when claiming funds, (3) the specified UTXO also serves to identify the claimant. While the need for funds is clear, how spending a UTXO authorizes a state transition or serves as identification is less obvious.\n\nThe following figure shows a hypothetical bank draft (“cheque”) that is signed by Satoshi Nakamoto. Notice that the cheque itself (1) provides identification on the “Remit To:” line (light green arrow) and also (2) proves authorization on the signature line (dark blue arrow). The cheque has the text <i>“The undersigned hereby transfers the value of this UTXO to the affixed new Outputs”</i>, which means that the signature marks this cheque for 100 XST spent so that it can not be spent again (“double-spent”). Additionally new cheques, affixed to the spent cheque, will total 100 XST minus any transaction fees.\n\nhttps://i.imgsafe.org/73/731761ba96.jpeg\n\nOne important property of spent outputs is that it is possible to use their identification and authorization properties to execute a command on behalf of the spender, as illustrated in the following figure:\n\nhttps://i.imgsafe.org/73/7317627587.jpeg\n\nAnyone who executes the “Enable Staker #1” command on their own client in response to this order can verify that Staker #1 belongs to Satoshi Nakamoto, and that the signature is genuine (using public-private key cryptography). Notice that the command is also an output, but it has no value and cannot be spent (“non-spendable”).\n\nhttps://i.imgsafe.org/73/7317a912f1.jpeg\n\n–––––\n\n<b><h1>Documenting The qPoS RPC Commands</h1></b>\nThe remainder of today’s post explains the usage and function of the qPoS RPC commands, starting first with informational commands, then describing commands that direct changes to the registry. Mandatory literals are bare words (e.g. the command names), mandatory arguments are in angled brackets, and optional arguments are in square brackets. All commands return valid [<b>JSON</b>](https://www.json.org/).\n\n<b><h2>Informational qPoS RPC Commands</h2></b>\n* <b>getstakerprice</b>: Returns the staker price at the moment of the call. Stakers go up in price with every block (albeit ever so slightly). Because of these price increases, this query should be for informational purposes, such as selecting or creating an input (unspent output, or UTXO) with which to purchase a staker. The “purchasestaker” RPC command (described below) will automatically determine the bidding price for a staker, attempting to account for any marginal increases in staker prices between constructing the transaction and its acceptance to the blockchain. Syntax:\n\t&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;`getstakerprice`\n* <b>getstakerid</b>: Returns the staker ID for the alias provided. This command offers simple accessibility to a staker’s ID for services that need to navigate the exhaustive output of “getqposinfo”, described below. Syntax:\n\t&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;` getstakerid <alias>`\n* <b>getstakerinfo</b>: Returns complete information about a staker, including id, version, enabled status, weight, permission keys (owner, delegate, controller), total earned, blocks produced and missed, and recent history of block production, among other information. Syntax:\n\t&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;`getstakerinfo <alias>`\n* <b>getqposbalance</b>: Returns the qPoS ledger balance for a public key. This command is useful to claim balances using the “claimqposbalance” RPC command.\n\t&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;`getqposbalance <pubkey>`\n* <b>getqposinfo</b>: Returns exhaustive info for all stakers, the queue, and ledger balances, and public keys therein. If another RPC doesn’t have the info needed, “getqposinfo” does. This command is useful for websites offering informational or other services that rely on knowing the current state of the qPoS registry at any moment. Syntax:\n\t&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;`getqposinfo`\n\n\n<b><h2>Commands that Affect the Registry</h2></b>\n\nAll commands that affect the registry require the specification of a UTXO using the “txid” and “vout” arguments. With the exception of “purchasestaker”, the signing of this UTXO serves to authorize the state changes. The “purchasestaker” command also requires specifying a UTXO as a source of funds. This requirement is to encourage users to select inputs carefully (to obscure relationships with other funds), and also to retain consistency with other RPC commands. Any change is returned to the owner of the specified UTXO (i.e. the caller of the RPC command).\n\n* <b>purchasestaker</b>: Purchases a staker and assigns the owner, controller, and delegate keys as specified. The bid can either be set manually using the optional “amount” argument, or automatically. Automatic bid selection includes a small addition that accounts for any price increases between submitting the command and its inclusion in the blockchain. This addition is expected to be a small fraction of 1 XST. If the delegate key is specified, a delegate payout, expressed as a percentage of block earnings, must also be specified. Payout is rounded to thousands of a percent. Note that either zero or all three of the “delegate”, “controller”, and “payout” arguments must be provided. In other words, if the caller specifies a delegate, the caller must also specify the controller and payout. Syntax:\n\t&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;`purchasestaker <txid> <vout> <alias> <owner> [amount]`\n\t\t&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;`[delegate controller payout]`\n* <b>setstakerowner</b>: Sets the staker owner key. This command transfers ownership! To help avoid unintended ownership transfers, users of this command must type the literal “iunderstand” at the end of the command. Syntax:\n\t&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;`setstakerowner <txid> <vout> <alias> <owner> iunderstand`\n* <b>setstakerdelegate</b>: Sets the staker delegate key. Note that the payout, expressed in percentage must be provided. Delegation is [<b>described here</b>](https://medium.com/stealthsend/stealth-development-blog-001-12-7-2018-359ecb038de9). Syntax:\n\t&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;`setstakerdelegate <txid> <vout> <alias> <delegate> <payout>`\n* <b>setstakercontroller</b>: Sets the staker controller key. A controller is authorized to enable and disable stakers, [<b>described here</b>](https://medium.com/stealthsend/stealth-development-blog-003-12-21-2018-c1af967b108e#3681). Syntax:\n\t&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;`setstakercontroller <txid> <vout> <alias> <controller>`\n* <b>enablestaker</b>: Ensures that the staker is enabled. This command can be submitted to the blockchain even if a staker is already enabled. In such a case, no change to the staker will occur. Syntax:\n\t&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;`enablestaker <txid> <vout> <alias>`\n* <b>disablestaker</b>: Ensures that the staker is disabled. Similar to “enablestaker”, “disablestaker” can be submitted to the blockchain even if the staker is already disabled. Syntax:\n\t&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;`disablestaker <txid> <vout> <alias>`\n* <b>claimqposbalance</b>: This command claims qPoS block rewards that are tracked in the registry ledger. To make these rewards generally transferable they must be claimed, but no more frequently than once a day for any given claimant (owner of the balance). Claims will be sent to the owner of the balance, as identified by the specified UTXO (by the “txid” and “vout” arguments). Because the UTXO identifies the claimant, the public key of the claimant is not a required (or even possible) argument to “claimqposbalance”. How UTXOs are used for identification and authorization is described above. The amount claimed must also be specified, and of course must not exceed the claimant’s registry balance. Syntax:\n\t&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;`claimqposbalance <txid> <vout> <amount> `\n\n–––––\n\nHondo\n\nhttps://www.stealth.org",
      "json_metadata": "{\"tags\":[\"blockchain\",\"bitcoin\",\"cryptocurrency\",\"stealth\",\"privacy\"],\"image\":[\"https://i.imgsafe.org/6f/6ffc93287d.jpeg\",\"https://i.imgsafe.org/73/731761ba96.jpeg\",\"https://i.imgsafe.org/73/7317627587.jpeg\",\"https://i.imgsafe.org/73/7317a912f1.jpeg\"],\"links\":[\"https://medium.com/stealthsend/stealth-development-blog-007-01-25-2019-ba470c1fedd9\",\"https://medium.com/stealthsend/stealth-development-blog-008-02-01-2019-ffd328354496\",\"https://www.json.org/\",\"https://medium.com/stealthsend/stealth-development-blog-001-12-7-2018-359ecb038de9\",\"https://medium.com/stealthsend/stealth-development-blog-003-12-21-2018-c1af967b108e#3681\",\"https://www.stealth.org\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}"
    }
  ]
}

{
  "trx_id": "0000000000000000000000000000000000000000",
  "block": 30379893,
  "trx_in_block": 4294967295,
  "op_in_trx": 0,
  "virtual_op": 5,
  "timestamp": "2019-02-15T21:37:48",
  "op": [
    "author_reward",
    {
      "author": "stealthsend",
      "permlink": "stealth-development-blog-009-02-08-2019",
      "sbd_payout": "0.000 SBD",
      "steem_payout": "0.028 STEEM",
      "vesting_payout": "58.140428 VESTS"
    }
  ]
}

{
  "trx_id": "78c144d2b18342de59f4aaa1549770204dd987dc",
  "block": 30182984,
  "trx_in_block": 28,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-09T01:25:15",
  "op": [
    "vote",
    {
      "voter": "mrakodrap",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-009-02-08-2019",
      "weight": 1000
    }
  ]
}

{
  "trx_id": "3bf0a99e951f7aae280da397d4c6d1609add1073",
  "block": 30179721,
  "trx_in_block": 8,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-08T22:41:57",
  "op": [
    "vote",
    {
      "voter": "ratticus",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-009-02-08-2019",
      "weight": 1000
    }
  ]
}

{
  "trx_id": "da8c8b036754c426b31300f2106bdc77d9045da5",
  "block": 30179698,
  "trx_in_block": 7,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-08T22:40:48",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "blockchain",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-009-02-08-2019",
      "title": "Stealth Development Blog 009: 02/08/2019",
      "body": "@@ -367,16 +367,17 @@\n  in the \n+%5B\n Whitepap\n@@ -378,16 +378,89 @@\n itepaper\n+%5D(https://github.com/StealthSend/Stealth/wiki/Stealth-Quantum-PoS-(qPoS))\n .%0A%0A%E2%80%93%E2%80%93%E2%80%93%E2%80%93%E2%80%93\n@@ -6750,21 +6750,21 @@\n org/\n-df/df397d308a\n+e0/e052a73720\n .jpe\n@@ -7168,21 +7168,21 @@\n org/\n-df/df397e4869\n+e0/e052a74d90\n .jpe\n@@ -8119,21 +8119,21 @@\n org/\n-df/df4b24789e\n+e0/e052eb3d4b\n .jpe\n",
      "json_metadata": "{\"tags\":[\"blockchain\",\"bitcoin\",\"cryptocurrency\",\"stealth\",\"privacy\"],\"image\":[\"https://i.imgsafe.org/df/df400578c2.jpeg\",\"https://i.imgsafe.org/df/df39bd5273.jpeg\",\"https://i.imgsafe.org/e0/e052a73720.jpeg\",\"https://i.imgsafe.org/e0/e052a74d90.jpeg\",\"https://i.imgsafe.org/df/df3986bcc0.jpeg\",\"https://i.imgsafe.org/e0/e052eb3d4b.jpeg\"],\"links\":[\"https://github.com/StealthSend/Stealth/wiki/Stealth-Quantum-PoS-(qPoS)\",\"http://www-inst.eecs.berkeley.edu/~cs162/fa12/hand-outs/Original_Byzantine.pdf\",\"https://www.stealth.org\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}"
    }
  ]
}

{
  "trx_id": "e29d651bf5102170122685bbc85cd590649f5882",
  "block": 30179102,
  "trx_in_block": 6,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-08T22:11:00",
  "op": [
    "vote",
    {
      "voter": "hodlcoin",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-009-02-08-2019",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "2f8f4b87ca52b2b847e871910d761d912ebc1dd9",
  "block": 30178584,
  "trx_in_block": 25,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-08T21:45:06",
  "op": [
    "vote",
    {
      "voter": "warofcraft",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-009-02-08-2019",
      "weight": 2000
    }
  ]
}

{
  "trx_id": "b2e56c30b5639e0ea6f97a091905bc9387216b35",
  "block": 30178579,
  "trx_in_block": 2,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-08T21:44:51",
  "op": [
    "transfer",
    {
      "from": "reblogit",
      "to": "stealthsend",
      "amount": "0.001 STEEM",
      "memo": "▶▶ Re-steem service ▶▶ 4200+ followers ▶▶ Send 0.02 SBDs/Steem ▶▶ I don't comment ▶▶"
    }
  ]
}

{
  "trx_id": "2de2bda55a5cd6f16cc05d2dcc93e4bfd767987c",
  "block": 30178530,
  "trx_in_block": 26,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-08T21:42:24",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "blockchain",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-009-02-08-2019",
      "title": "Stealth Development Blog 009: 02/08/2019",
      "body": "@@ -380,16 +380,23 @@\n paper.%0A%0A\n+%E2%80%93%E2%80%93%E2%80%93%E2%80%93%E2%80%93%0A%0A\n %3Cb%3E%3Ch1%3EP\n",
      "json_metadata": "{\"tags\":[\"blockchain\",\"bitcoin\",\"cryptocurrency\",\"stealth\",\"privacy\"],\"image\":[\"https://i.imgsafe.org/df/df400578c2.jpeg\",\"https://i.imgsafe.org/df/df39bd5273.jpeg\",\"https://i.imgsafe.org/df/df397d308a.jpeg\",\"https://i.imgsafe.org/df/df397e4869.jpeg\",\"https://i.imgsafe.org/df/df3986bcc0.jpeg\",\"https://i.imgsafe.org/df/df4b24789e.jpeg\"],\"links\":[\"http://www-inst.eecs.berkeley.edu/~cs162/fa12/hand-outs/Original_Byzantine.pdf\",\"https://www.stealth.org\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}"
    }
  ]
}

{
  "trx_id": "4f0f9fe641be4d1d41adb650e68fa56a92fade56",
  "block": 30178470,
  "trx_in_block": 44,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-08T21:39:24",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "blockchain",
      "author": "stealthsend",
      "permlink": "stealth-development-blog-009-02-08-2019",
      "title": "Stealth Development Blog 009: 02/08/2019",
      "body": "@@ -3196,16 +3196,17 @@\n ined by \n+%5B\n Lamport,\n@@ -3224,16 +3224,97 @@\n nd Pease\n+%5D(http://www-inst.eecs.berkeley.edu/~cs162/fa12/hand-outs/Original_Byzantine.pdf)\n . I can \n",
      "json_metadata": "{\"tags\":[\"blockchain\",\"bitcoin\",\"cryptocurrency\",\"stealth\",\"privacy\"],\"image\":[\"https://i.imgsafe.org/df/df400578c2.jpeg\",\"https://i.imgsafe.org/df/df39bd5273.jpeg\",\"https://i.imgsafe.org/df/df397d308a.jpeg\",\"https://i.imgsafe.org/df/df397e4869.jpeg\",\"https://i.imgsafe.org/df/df3986bcc0.jpeg\",\"https://i.imgsafe.org/df/df4b24789e.jpeg\"],\"links\":[\"http://www-inst.eecs.berkeley.edu/~cs162/fa12/hand-outs/Original_Byzantine.pdf\",\"https://www.stealth.org\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}"
    }
  ]
}

{
  "trx_id": "1422e25ec43253989c60dcb9865d788ac98816e7",
  "block": 30178444,
  "trx_in_block": 27,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-08T21:38:06",
  "op": [
    "comment",
    {
      "parent_author": "stealthsend",
      "parent_permlink": "stealth-development-blog-009-02-08-2019",
      "author": "cheetah",
      "permlink": "cheetah-re-stealthsendstealth-development-blog-009-02-08-2019",
      "title": "",
      "body": "Warning! This user is on my black list, likely as a known plagiarist, spammer or ID thief. Please be cautious with this post!\nIf you believe this is an error, please chat with us in the #cheetah-appeals channel in [our discord](https://discord.gg/7FkETjJ).",
      "json_metadata": ""
    }
  ]
}