[spending bitcoins instead of CPU/electricity]

I have an idea and wonder whether it already came up in the past so was thinking of putting it out here and getting some feedback.
The idea is a variant on POW, securing an Alt-Chain by spending bitcoins instead of CPU/electricity.

To mine a new Altcoin Block, the Alt miner assembles alt mempool transactions into a block and computes the Merkle Root of the transaction list, just like in Bitcoin.
Instead of spending cpu (incrementing a nonce and aiming to minimize the block header's hash) the Alt miner makes a "Mining Transaction" on the Bitcoin network sending some amount of bitcoins to himself leaving behind a predefined amount of Satoshis as a miner fee.
The Alt miner waits for the mining transaction to be confirmed (in Bitcoin). When it is confirmed in some block the alt miner signs (with the private key of the address from which the mining transaction originated) the Hash of the concatenation of the previous alt-block header, the current candidate Merkle root of alt transactions and the mining txid, and publishes that signature as the header for the candidate alt-block.

Other altcoin participants can verify that signature, because the public key corresponding was exposed in the mining transaction.
Define the Purchased (or Payed for) Work to be the Hash of the concatenation of the mining txid with the hashed header of the Bitcoin block where that transaction was mined.
A valid alt-block is required to satisfy that this value is smaller than a predefined difficulty parameter.
The correct alt-chain is the one with maximal accumulated payment, namely, the sum of the payment factors for each block (hash of mining txid concatenated with the header of the Bitcoin block where it was mined) weighted by the price payed (assuming that in general the alt protocol has a retargeting algorithm that changes, like the Bitcoin difficulty adjustment).

Comments:

The basic point here is that if a new alt wants to launch and secure itself with POW then there are 3 main benefits to this method:

• Technically easier than dealing with mining hardware
• Environmentally friendly: No need to burn electricity when we can use an existing provably scarce resource (=Bitcoin)
• Supports Bitcoin's security by increasing miners fees

Security Model:
Unless I'm missing something, it seems to me that reversing an alt-block requires either:

• Alt-Miner need to construct a competing chain. But that is the same as in Bitcoin, you need to pay to mine and that’s ok.
• Reversing a Bitcoin block. Here we assume that Bitcoin is much more expensive so this is not rational to do.

Miners DoS:
An obvious difficulty with methods of this type is that Bitcoin miners may find it profitable to DoS such mining transactions so that only their mining transactions get confirmed. However, under what seems to me to be fairly reasonable assumptions one can show that there is a parameter range where this is not profitable for the miner (namely, it is more profitable to collect the mining fees). See my writeup at https://view.publitas.com/foo/proof-of-payment/ for more details.
 
Anyways, I hope I explained this well. It feels pretty basic so I will not be surprised if it has been proposed in the past or just doesn't work at all for one or many reasons I neglected to consider, but I am hoping to start a discussion, at least so that I can learn from it.

Thanks everyone.

p.s. In case you missed it in the text above, here again is a link to a cleaner PDF writeup of the above https://view.publitas.com/foo/proof-of-payment/

[fully]

Recently I started running a Core 15.1 node with the blockchain on an external hard drive, and found it very hard to fully sync the blockchain.
The problem I keep running into is that (in about 90% of my attempts) the sync does not complete. A DB corruption occurs at some point (usually pretty late in the game, maybe 36 hours into it).

I did some digging in forums and saw that I am not the first user to notice this problem. Peter Wuille mentioned that he does a full sync on like a weekly basis and it always works, and he thus suspects that these type of issues are due to sub optimal hardware.

That seemed very reasonable at first because my initial attempt was done using a pretty old 400gig pocket hard drive. So I switched hard drives.
By now, about 2 months later, I have tried to sync the blockchain from scratch about 20 or 30 times and only twice managed to complete the process.
I did that on 4 different types of hard drives, including a brand new 1T Western Digital.

One may say that all 4 hard drives I used are "suboptimal", but I would object to that because
1. After the sync does complete, the node runs just fine.
2. I think it is desirable to be able to run a full node on a raspberry pi with a pocket size hard drive (note that I run the node on a raspberry pi but use my linux desktop to do the initial sync)

Now the issue I have here is not so much the crash during sync, but the fact that when I restart the client after the crash the only option is to basically start from scratch (If I understand correctly, the client is not necessarily downloading everything from scratch but that is not my point) and sync again from Genesis.
Ideally I would like the client to keep synching from the point it successfully got to and not re sync from scratch on such errors.

I am wondering if this resync from scratch on error is necessary. I assume that corruption occurs in one (or more) of the files in the blocks or chainstate directories. If that is so then why sync from Genesis? Is it not possible to, say, delete all files post the corrupted file and sync from there?

If there is no fundamental reason for this behaviour, I would also appreciate a pointer to the relevant code in the client.

Thanks!!