Wallet proposal: include block transaction hash in generation signature
I posted code up on github here but wanted to open up the chance for discussion.
Full details in the pull request description, but a quick summary:
- Currently the generation signature only builds upon the id of the account that mined the previous block and the contents of the block and hash of the previous block are signed with the generators public key.
- This allows a miner or pool who finds multiple blocks in a row to easily change the contents of the block without having to recompute the work put into finding the block, potentially allowing an avenue for DOS spam attacks and also potential double spend attempts.
The proposal is to mirror what many POW coins do and include the hash of the transactions in the generation signature so changing the contents of the block will invalidate the work done to find it and ensuring that if a block has been included in the chain, even if the same miner finds multiple blocks in a row, it cannot be mutated.
This should hopefully improve the stability and reliability of the network without too large an impact on the design of the system - only wallets need to be upgraded. One minor downside is that after you broadcast a transaction miners will not consider it for inclusion in a block until after the next block is found, but with a 4 minute block time this shouldn't increase transaction latency by a huge amount.
I'd be interested to know what people think, I only got into burstcoin a few weeks ago by starting to mine and it was due to seeing far more forks and unreliability in mining than I was expecting that I dug into the code to try and find places where improvements could be made - as such I can't say I'm totally familiar with the codebase and may have missed something necessary in the change I've proposed.
To expand on this, as this part of burstcoin is inherited from NXT, a comparison is possible.
You see documented here somebody describing something that could be similar to this, but sadly they never revealed the details as they wanted a bounty first and were rather alarmist about things.
However, in practice, you would not see this on NXT as:
- The coin is fairly well distributed compared to the historical and potential size of pools in burstcoin. Pools never really took off in NXT to reach the percentages they have in burstcoin.
- Even though the largest coin balances would allow for something similar, with transparent forging implemented the disruption possible through doing this is eliminated and attempting a double spend appears to become infeasible but I won't claim to know NXT well enough to say for sure. Transparent forging is a PoS concept and not applicable to PoC.
- A 1 minute block time increases the number of blocks an attacker would need to win a row to perform a double spend after the same amount of time, further reducing the ability to take advantage of this.
In many ways this proposal is similar to transparent forging - rather than predicting who will generate a block in advance, allowing this to be distributed and penalising and ignoring forks based upon this, this proposal requires miners to decide upfront what their block will contain and as recomputing the PoC data isn't possible in real time this is just as good as being able to predict and anticipate the chain. Note that NXT's description of transparent forging also includes similar estimations of the difficulty of double spends with a technique such as this in place as in the linked github PR.
Ultimately PoC is closer to PoW in nature than PoS, hence the need to include the block contents to ensure reliability and prevent rewrites of the chain to create forks for double spends.
@daWallet can you let us know if you seen this post and your thoughts.?
@mass.halting i found your post and your suggestion so late, pls contact me via pm thx!
In case anyone is still wondering about this, current wallets include code that puts the 'payload hash' into the block's hash, which then becomes part of the block's generation signature. I believe older wallets also did this, so the issue the OP is proposing already exist in the code. Fancy, eh?