Synchronize OPR JSON fields with spec

[drkatz]

Currently the FAT spec has some differences than the code as to what ends up on chain in an OPR. From the OPR struct in #134:

// OraclePriceRecord is the data used and created by miners
type OraclePriceRecord struct {
	// These fields are not part of the OPR, but track values associated with the OPR.
	Config     *config.Config `json:"-"` //  The config of the miner using the record
	Difficulty uint64         `json:"-"` // The difficulty of the given nonce
	Grade      float64        `json:"-"` // The grade when OPR records are compared
	OPRHash    []byte         `json:"-"` // The hash of the OPR record (used by PegNet Mining)
	Entry      *factom.Entry  `json:"-"` // Entry to record this record

	// These values define the context of the OPR, and they go into the PegNet OPR record, and are mined.
	OPRChainID         string     `json:"oprchainid"`      // [base58]  Chain ID of the chain used by the Oracle Miners
	Dbht               int32      `json:"dbht"`            //           The Directory Block Height of the OPR.
	WinPreviousOPR     [10]string `json:"winners"`         // First 8 bytes of the Entry Hashes of the previous winners
	CoinbasePNTAddress string     `json:"coinbase"`        // [base58]  PNT Address to pay PNT
	FactomDigitalID    string     `json:"FactomDigitalID"` // [unicode] Digital Identity of the miner

	// The Oracle values of the OPR, they are the meat of the OPR record, and are mined.
	Assets OraclePriceRecordAssetList `json:"assets"`
}

The latest version of the OPR in the Pegnet FAT Spec (Factom-Asset-Tokens/FAT#25):

{
  "winners": [
    "ba98d1bc839877a6",
    ...
  ],
  "reward": "FA...",
  "identity": [
    "Minder",
    "Bob",
    "99"
  ],
  "rates": {
    "PNT": 0,
    ...
  }
}

The serialized values of the OPR datastructure vary subtly from the current spec and should be synced up.

There was a short discussion about OPRChainID somewhere, and I believe it was omitted from the OPR as Pegnet's POW and structure effectively de-incentivizes replay onto other chains(networks) by incentivizing players to only use their hashpower on the mainnet (Real PNT rewards). I can't think of why someone would want to replay mainnet OPRs onto the testnet.

Today during our call we briefly discussed dbht being readded to the spec, and that will be reflected soon 👍

If there is anything else that should be either added to the spec that is required by the implementation,or vice versa let's please discuss!

[sambarnes]

Thanks for bringing the issue up here! A few of my thoughts:

• Yeah I agree "oprchainid" should be removed, it's just duplicate information that I don't think buys us anything
• For dbht maybe it should be something more readable for people, directory_block_height or block_height perhaps?
• The "identity" is actually just a string now rather than an array. So we'll be able to support either chain-id notation or a human readable form with delimiters. Currently thinking this field should be "miner_id" or something similar, since it's an identifier that points to an identity, rather than an identity itself

Also had a question about the PNT value, should we be listing it as nil rather than0 since the rate hasn't been set yet? I know @Emyrk had some thoughts about not wanting to put a value, so maybe no number is better than a zero.

[drkatz]

@sambarnes I think height might be nice as it fits with the current naming scheme, and the database context can be implied.

Sorry I'm sort of addicted to short simple names ha. I agree identity may be a bit uninformative. I could go with something like miner

[sambarnes]

I totally agree short and to the point names are best for these kind of things if possible

Also, forgot to include this in my list:

• for the "winners" array, is there a particular benefit in using the short-entry-hashes? If we're not including the full values already, i'd argue that we should just do a single hash of all winners concatenated together. Like sha256( sha256( winner1 + winner2 +... + winner 10) )

[drkatz]

Hey also let's move this discussion over to the FAT spec PR if you don't mind 😉 There was some good talk there from @WhoSoup and @PaulSnow about shorthashes in winners that I want to circle back to. I really like the idea of collapsing the array down to a single hash if it's not expensive to verify

[Emyrk]

I know @Emyrk had some thoughts about not wanting to put a value, so maybe no number is better than a zero.

I am fine with a 0.

[PaulSnow]

@drkatz We need the design discussions to be done in the PegNet channels and using PegNet tracking.

I think that we have addressed all the issues that you have brought up, and we need to concentrate on actually detailing work that needs to be done, and for really good reasons.