@JavierGonzalez 14 October 2020 edited

Verifying an on-chain BMP vote **This** is an example of BMP protocol hashpower voting. https://bmp.virtualpol.com/voting/535947de7669b7e17b6ceb99dc9bae22a8d076c99ae86fa8d920cd51966cb631?blockchain=BCH

Properties Universally verifiable. Decentralized (without a central authority to create the voting or census). Open to the public (anyone with hashpower can participate, on equal terms). Inmutable (indestructible like the blockchain, on-chain, forever). Reproducible (in your own BMP server). Precise, consistent, atomic. Conclusive (with a start and end date). With multiple and extensible parameters. Votes changeable until close of voting. Parallel validity vote. Big `block_window` hashpower avg calculation, but allowing 24h quick votings. Simple and sophisticated. Following the Satoshi whitepaper. Verification Obviously, with 0.0009% of BCH hashpower (24 TH/s) the vote outcome carries no weight. But the technical milestone achieved is a verifiable fact. And you can verify this beyond any doubt. The most fun way is to run your own BMP server, but here we will do it manually. https://bmp.virtualpol.com/README Action: voting BMP link contains the following hash (SHA-256): `535947de7669b7e17b6ceb99dc9bae22a8d076c99ae86fa8d920cd51966cb631` https://bmp.virtualpol.com/voting/535947de7669b7e17b6ceb99dc9bae22a8d076c99ae86fa8d920cd51966cb631?blockchain=BCH Corresponds to this BCH transaction. It contains the following OP_RETURN hex: `9d05000105001f80446f20796f7520737570706f727420746865206e657720636f696e626173652072756c65207468617420726564697265637473203825206f66206d696e696e67207265776172647320746f206120737065636966696320616464726573733f` https://explorer.bitcoinunlimited.info/tx/535947de7669b7e17b6ceb99dc9bae22a8d076c99ae86fa8d920cd51966cb631 The first byte `9d` is the BMP protocol prefix. https://bmp.virtualpol.com/protocol

The second byte `05` is the action: `voting`. To create a new poll. The third byte `00` is the type of voting: `explorative`. It means that the result is not intended to be binding. The purpose of this vote is simply to discover information about the consensus. The fourth byte `01` is the type of vote: `one_option`. It means, each vote will choose one option. In the future there will be preferential, multiple and other more advanced types of votes. The fifth byte `05` in decimal is 5 and is the number of *parameters* of this poll. The next three bytes `001f80` in decimal is 8064 and is the number of blocks of duration. Voting started in block 648919, then it is closed exactly in 656983. We will call this block `close_block`. https://explorer.bitcoinunlimited.info/block/0000000000000000006c1f2092c432bec492bc5163b28a88dd598bfb7db187ff https://explorer.bitcoinunlimited.info/block/000000000000000001fa00ccbdb319a68b11a8d9458d57cd6ef633c431be3fc8 The following bytes are the question of the voting. Decoded with `hex2bin()` is: `Do you support the new coinbase rule that redirects 8% of mining rewards to a specific address?` Parameters: points Now we must find the 5 additional parameters, in order to have the voting complete. This transaction includes the following OP_RETURN hex: `9d06535947de7669b7e17b6ceb99dc9bae22a8d076c99ae86fa8d920cd51966cb631000154686520737065636966696320616464726573732069733a2070716e7176396c74376535766a7970307738387a66326166306c39326c38727864676e6c787777396a39` https://explorer.bitcoinunlimited.info/tx/6fe3938dc79ad8902445450d90b14fc27e0c7fde7e39de73bf064069560a0032 The second byte `06` is the action: `voting_parameter`. Is used for additional metadata associated with the voting. The next 32 bytes are: `535947de7669b7e17b6ceb99dc9bae22a8d076c99ae86fa8d920cd51966cb631` And it is the hash of the initial transaction of this vote. Both transactions have the same address as input. The same voting author. Thus, voting is defined by multiple TX and at the same time is atomic and immutable. The next byte `00` is the type of parameter: `point`. This is a text that is part of the question statement, in the form of numbered points. The next byte `01` is the point order. Specifies the order in which the numbered points should be presented. The following bytes is the text of the point. Decoded with `hex2bin()` is: `The specific address is: pqnqv9lt7e5vjyp0w88zf2af0l92l8rxdgnlxww` There are two more parameters of the same type, which you will find here and here. https://explorer.bitcoinunlimited.info/tx/06e5c99998bdc0603e800c5e8cfba9ddf2925cda31a079c7f6c71c1ab1720cbb https://explorer.bitcoinunlimited.info/tx/ca9142d9289fe03cab0d1644472fbb8f7bdab88710e926b4c71857470d4a02ca Parameters: options The `voting` action says it has 5 parameters. We have verified 3. Two more to go. This transaction includes the following OP_RETURN hex: `9d06535947de7669b7e17b6ceb99dc9bae22a8d076c99ae86fa8d920cd51966cb6310101596573` https://explorer.bitcoinunlimited.info/tx/ecceeb816ddcdcc7e5ea86ebbd60c3988c489049f2a2b29adf41de6c09d0c3a6 The first byte `9d` is the BMP protocol prefix. https://bmp.virtualpol.com/protocol The second byte `06` is the action: `voting_parameter`. The next 32 bytes is the hash of the voting transaction. The next byte `01` is the type of parameter: `option`. This text is one of the voting options to be chosen. The next byte `01` is the option order. Specifies the order in which the point should be presented in the vote selector. The following bytes `596573` is the text of the option. Decoded is: `Yes` This is the last parameter, which is processed in the same way. It is the `No` option. https://explorer.bitcoinunlimited.info/tx/28437559b6e2107955e1ad4f5b71383f2a900211140ceeeeb92d84cb2891dd56 Thus, voting is completely created. It was created with this clean web interface. https://bmp.virtualpol.com/voting/create

Votes This transaction includes the following OP_RETURN hex: `9d04535947de7669b7e17b6ceb99dc9bae22a8d076c99ae86fa8d920cd51966cb631010102` https://explorer.bitcoinunlimited.info/tx/a919abcee0e640e176bf85e1d847f0a921b1544eb5dea887f02c01e915b85956 The second byte `04` is the action: `vote`. These are the votes. Valid when included in a block while the vote is open. The next 32 bytes are the voting hash transaction. The next byte `01` is the type of vote: `one_election`. In the future, other elements and concepts can be voted. For example, chat messages. The next byte `01` is the validity of the voting. `00` means that the voting is not valid, `01` the voting is valid. This allows a parallel and independent vote, on the wording of the voting itself. Independent of the option you have voted. The next byte `02` is the voted option! `00` is always `Neutral`. In this case: `01` is `Yes` and `02` is `No`. This is the second vote. And it is processed in the same way. https://explorer.bitcoinunlimited.info/tx/258110ad0e4a17984af5112b79ceed2a4a1ee5872b32b68dd932357be3f25152 Hashpower When the voting is closed, the voting result is computed by adding up the hashpower of each option. The option with the most hashpower is the winner. In the first vote, the input and output include the same address: `bitcoincash:qpjf08mqnw5g2v4y9yta50s3exek3yp6fcwddtteak` The same address in legacy format: `1AAtD721LQekC6ncHbAp4ScKxSwR7fFeYT` It is the author of the vote. This is a **coinbase transaction**. It is very special. Only a miner can do this. It is the first transaction of the block. This transaction has no inputs. It receives the fees and the block reward. This is how all Bitcoins originated. https://blockchair.com/bitcoin-cash/transaction/4f25297ae651e44e50104c3ad84a3571d7c614b406bb4c1562dfa03970ba7761 The coinbase transaction includes multiple output addresses. Miners. The address of the first vote, ending in `FeYT`, is included. It receives `0.04374541 BCH`. The block total output is `6.25150088 BCH`. Then `FeYT` address has received **0.7%** of the reward of that block. The difficulty of that 653362 block is `359263959306.8658`. Only this number is needed to calculate the hashpower of the block with: `Difficulty * 2^32 / 60 = 2571711593090800000 = 2.57 EH/s` This is 2,570,000,000,000,000,000 hashes per second for that block! https://explorer.bitcoinunlimited.info/block/000000000000000000d7b6912b54525de60e5e404c7de00f5101cebc94dc8b35 Then, if `FeYT` received 0.7% of the block incentive, proportionally the BMP calculates its hashpower at `18 PH/s`. This signaling method, called `power_by_value`, is by default and it is compatible with all blocks. There are two more sophisticated methods of signaling that I will explain on another article. The BMP `block_window` is the last 4032 blocks for hashpower calculation. Then, when the voting was close, it counted the hashpower of each miner, between 652951 `close_block - block_window` and 656983 `close_block`. Between these blocks, `FeYT` participated in the creation of: 653326 and 653435. https://explorer.bitcoinunlimited.info/block-height/653326 https://explorer.bitcoinunlimited.info/block-height/653435 The BMP calculates the proportional hashpower and adds it all up. It does the same with the second participant. And since they have voted the same, it totals it, resulting in the `24 TH/s` for the `No` option. https://bmp.virtualpol.com This new context is processed with this piece of PHP code. On every block. https://github.com/JavierGonzalez/BMP/blob/master/%2Bbmp/bmp.php