Greetings Steemit community and accept my first post. This and the following posts are going to be extracts, mostly proposals, from [Gridcoin development wiki](https://github.com/gridcoin/Gridcoin-Research/wiki). Delayed DPoR payments raised a lot of concerns and dissatisfaction with the recent introduction of [stake kernel V8](https://github.com/gridcoin/Gridcoin-Research/wiki/Stake-V8). Also the funds raised will be used for 50% power and 50% donation for grcpool, for beginners.

First excuse me going a little off topic: The difficulty _number_ sharply decreased with the transition. This was expected. But let me assure you, that the creation of blocks is also harder. Thus the two cancel each other. Remember that the changes were extensively tested in testnet before releasing. Since the transition, both the average block spacing (94.8s) and average difficulty were within bounds. You can expect more stats and analysis from me in the future, but now get back to topic.

![GridcoinBlocks_Header_Blur.png](https://steemitimages.com/DQmW6z6FYA4YS1843aZq7qpjLVkG31tR6fBmg4TaKu94xDR/GridcoinBlocks_Header_Blur.png)

This document ([original location](https://github.com/gridcoin/Gridcoin-Research/wiki/DPoR-Payments)) is about the Question:
* How and when to pay BOINCers their Rewards.

Once this document is good enough, we can have a poll for which proposal to implement.

## Current situation

When a block is minted the accrued BOINC reward is paid as whole to the minter on top of the PoS interest. Therefore BOINCer has to wait for PoS to receive their rewards.

In an attempt to make this waiting time shorter, and also secure the blockchain not only by investor coins, magnitude is added to miners stake weight for the kernel v3. This was however [found insecure](https://github.com/gridcoin/Gridcoin-Research/wiki/Stake-V8#multiplication-issue), so it was removed in kernel v8.

User Dutch [pointed out](https://steemit.com/gridcoin/@dutch/why-i-am-very-disappointed-by-the-upcoming-v8-removal-of-the-magnitude-component-of-the-gridcoin-staking-weight) the downsides of removal of magnitude from kernel v8. We must work towards both shortening the time miners must wait to get a reward and restoring their share in securing the block chain.

## Beacon Minting

(TomasBrod) I propose that in addition to coins keys, one can mint with the beacon keys with different difficulty and research based weight. The kernel is in the formula below, but we need to talk about weight and difficulty computation more.

```
ProofHash = H( BeaconPubKey + StakeModifier + nTimeTx );
```

Weight for this kind of stake can depend on the owed amount or current magnitude or some combination of both. This is yet to be decided. Single CPID/beacon is allowed to mint only if the last reward for that cpid (either via standard PoS or this beacon mint) to that CPID was more than x1 (30) hours ago.

Difficulty is computed using the standard mechanism. The target block time for beacon mint is set to x2 (12) minutes. But there must be at least x3 (4) standard PoS blocks in between to mitigate an age bunkering 51 attack.

Rewards to a CPID are tracked the same way for both PoS and this mint. What is rewarded in this new block is not in standard PoS blocks. Established miners are expected to have high balance and thus get all reward in PoS.

## Superblock payment

The idea is to pay all BOINC reward in the superblock. Or provide means of claiming the reward promised in the superblock.

> quezacoatl: There is the idea to generate all POR
> payments in superblocks so miners do not need to stake
> to receive POR anymore. POS is then only used for
> network security while the "NN2.0" takes care of the
> research payments.

This option does not deal with giving BOINCers share in securing the blockchain (stake weight). But most importantly, we do not know yet what "NN 2.0" is.

## Refined Kernel v3

The fundamental issue with kernel v3 is that the magnitude boost is applied to all UTXOs. A simple solution to this problem would be to simply spread the RSA_weight (the magnitude dependent boost) over all the UTXOs. This is as easy as applying a weight proportional to magnitude/number_of_UTXOs. 

The problem with this approach is that the validator does not know the number of UTXOs in the wallet that staked the block. 

A way around this might be to allow the magnitude boost only for UTXOS that are linked to the Gridcoin address that sent the beacon. That way the validator could look up the number of UTXOs of the address. Blocks are rejected if the number of UTXOs linked with that address is wrong or the magnitude boost is applied to a UTXO of a different address.

But this workaround is still hard to implement. Wallet on it's own does not track which UTXOs are linked to CPID and scanning the blockchain every time will be too slow.

The magnitude weight would work like an additional balance equally divided amongst all UTXOs of the beacon address.

Giving this magnitude boost only to the address from beacon is still not an option, as users can have many UTXOs to the same address. Also requiring users to move coins to special address to stake will cause a lot of confusion.

## See also

https://github.com/Erkan-Yilmaz/GRC/issues/42


Ability to mint multiple consecutive blocks by the same entity weakens the network resistance to double spend attacks. The main problem of using any kind of age (coinage or reward=magnitude\*days) is that one can create many accounts with small initial weight, then go offline to acquire more weight by age and then come back and stake them all.