I'm interested in the security of unconfirmed Bitcoin (BSV)…

If it is not considered a solved problem, I'm interested in contributing code to a solution. But I have some limitations, limited time due to a 9-6 job, and I can't currently receive any kind of compensation due to visa limitations.

Specifically I'm interested in implementing a system to detect attempted double spends on unconfirmed transactions. By sending conflicting tx in parallel to map the network hashrate, and then querying the mempool of nodes with significant hashrate for ds

I'm interested in doing this for fun as an open source project, maybe BSD license. Assuming that it would be a useful contribution to the community. Previously I discussed this on twitter with CSW but lost touch with him about a year ago.

It is solved by the economics. The idea of confirmations are a relic from Core. As soon as the transaction is broadcast with a fee that pays them, it is as good as in a block.

What @145 said, but private solutions like GAP600 are trying to do what you are doing here and providing insurance for 0-conf transactions.

I encourage you to develop a solution and license it to businesses.

Thank you for your reply Connor, love your work! To be clear my current visa does not allow me to do side work, I can only do open source dev. I was unaware of GAP6000. They do seem to have the same goal as I do, and I see they have a bsv page. Interesting

As Ari mentioned in his branch the amount of hashpower that declares support for the transaction is important. e.g. a bad guy can send low fee txs to known miners, so they accept but don't relay. Then a moment later a double spending tx to the merchant.

I'm proposing a solution to this, but are requesting peer review, and the reply by @343 indicates others, specifically GAP6000 have already implemented an acceptable solution to this or are actively working on it. I don't want to duplicate work.

I should probably point out doing this to a real merchant is illegal, it's fraud, hence why I say 'bad guy'. I'm interested in the technical computer science aspect of problem.

The merchant will connect to a service provider (miner) and they will verify a sufficient % of miners support that tx fee rate.

if (txFee < majorityHashAcceptedFeeRate) {
return false;
}

Yes that's basically the solution I'm proposing. But I don't think it's trivial to map the hashrate, which is continually varying. e.g. it requires something like repeatedly sending conflicting transactions to all nodes on the network. Some dev work needed

Also I would like to consider the case of malicious (dishonest) hash rate, that doesn't report accurately on which transactions have been accepted. How to detect such nodes and deal with them?

With Miner ID, a merchant will be able to trustlessly verify (ex: SPV) the past blocks mined (ie: hashrate estimate) by that Miner ID.

Is that what you had in mind to mitigate "dishonest hash rate"?

Finally found & watched the 'Steve Shadders: Double spending on many blockchains can be controlled' CoinGeek Video from 11 Dec 2018 on yt. Great video, exactly what I was looking for. Waiting for an update video, have the Q1 2020 goals have been reached?