(updated)
Hello
recently the infamous 51% Attack has become all too common.
Before, it was just a theoretical possibility. But since it happened to verge and the price did not drop to zero afterwards, since the miners who performed the attack did not get punished.... at least i did not hear about it. ... since then, the flood gates are opened to further attacks. Refer also to the table of the cost of coins to be attacked by nicehash rented hashpower....
Long story short chains with less hashpower need some new form of security. As i see it, the only chain that is really safe from 51% attacks is the one with the most hashpower, which is Bitcoin BTC.
So how about a form of tie from one chain to another?
How about including the hash of maybe every tenth block of any chain into a transaction on the BTC blockchain. This can be done, by just stating it as the transaction comment.
So basically the cost of this tie is the current transaction cost of a BTC transaction.
It is very small compared to the standard miner reward on any blockchain. So maybe we can even ditch the mining altogether for new coins and just use the proof of bitcoin method by itself.
Ok you gonna need some kind of mining to hash it out, to even create the hash to include into the BTC transaction. But why not just CPU Mining. And also not on full power of the CPU either. Just a local difficulty for your own node. So no competition there. No incentive to have more hashpower, just reach a easy hash.
The earning or incentive model is: run a node and miner combination, that can be a quite simple computer with some hdd space. The first transaction included into the BTC block wins the race. That will be the new coin block that continues the chain.
The node owner collects all the fees of the transactions included into the new coin block.
The BTC transaction must be send from the the current block finder to the node owner that found the last block. The BTC sum must be the total collected fees on the new coin block. So in the end, for your effort you will always receive the fees of the next block.
This way the incentive is less, to only include high fee transactions. The block finders, that send their transaction with their found hash too late, but send it anyways, ( information propagation is not fast enough to avoid this) will get their BTC send back by the receiving node owner. This can be easily verified on the BTC blockchain. If not sent back some punishment will be done. Sth like the network does not accept blocks from this node again...
I hope this method does not spam the BTC chain with transactions trying to be the first transaction.
The exchange rate from the POB coin to BTC needs to be recorded on the blockchain also in some clever way.
Of course in order to utilize this method, when running a node for the new tied POB coin, the same node needs to run a BTC node. Good thing they did not opt for big blocks.
So the result is, if you want to 51% attack... Maybe that is not the right name for it.
So lets say you want to alter the chain, or better, just alter one transaction in the chain. --> you need to go back to this block and hash out the complete rest of the chain again, including all the other transactions, including reaching the exact hash that was included into the BTC transaction, with the correct timestamp. Timestamp is not the correct term, but the blocktimes have to somehow match.
I would say that is close enough to impossible.
To even go further, why not tie it both ways. include the current BTC hash into the block of the new coin and then hash out the new coin block and include the hash into a new BTC transaction. and so on and so forth.
This way a kind of pre-hashing of blocks can be avoided. The hash of the last BTC block has to be known first, before the next POB coin block can be hashed.
So finally, as you can see my coding knowledge is limited. I will be more than happy about your input, if this is a good idea, or just nonsense. Thank you.