Thank you for the comment.
I think the main problem with your suggestion is that it gives Bitcoin miners a way to DoS by ensuring that their own mining transactions are "first" (or whatever the rule is). This is why I tried to be careful so that Bitcoin miners have no way to game it.
Of course it would be great if we could find a way to eliminate option i and automatically have the full Bitcoin network security backing up an arbitrary alt-chain but that sounds like a free lunch.

I agree with your first point. You can only secure your alt with as much security as you are willing to pay for by spending some scarce resource. Noway around that I'm afraid.

I still disagree with the bloat point however. The mining tx that are not on the longest chain are not useless anymore than the electricity spent crunching nonces in POW. If an alt-miner felt paying the fees to secure the alt network was "worth it" then to me, by definition, this is not a waste but an investment in the security of the network.

Compare the two situations:
A] New alt launches with PoW
B] New alt launches with PoP

In terms of the alt-network security, the two are equivalent. However, in PoP no need to burn more electricity than is already being burnt to create the scarce resource (=Bitcoin). In that sense I think PoP is energy conserving + indirectly supports Bitcoin's security.

Thanks for commenting.
Can you please elaborate on these "low cost manipulations" and how they are different from manipulating any low hashrate altcoin?
Clearly when the altcoin is young, the hashrate is presumably low and anyone can cheaply attack it. In the above setup you don't need to buy mining equipment to perform the attack, you spend bitcoins doing it.

Regarding the blockchain bloat argument, I tend to think that this type of questions are best left for the market to decide. "Bloat" is a moral objection saying "useless tx", but I think all tx are equally useful as long as the sender is willing to pay the fee and miner is willing to mine. Plus, "buying altcoin security" sounds like a legitimate use case to me. Also there is a flip side that by paying miners (instead of burning electricity) we are increasing Bitcoin miners' reward thus contributing to Bitcoin security.

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/

Thanks.
Rsyncing from another hard drive is exactly what I did once I realised achieving a full sync from scratch is not likely to happen. Anyway, your remark about the -reindex-chainstate flag is interesting. I'll try that. However, I would still like to understand why the default behaviour is the way it is.

Thank you for your answer.
So say I sync the node and get a db corruption when the node is, say, 90% synced. Now I delete the chainstate directory and restart the node. Will the node have to re-sync from Genesis (and take the usual 36~48 hours) or will it resume from 90%?

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!!