Assessing zero confirm transactions with a risk formula

[Tuxavant]

Does anyone think it might be useful to discuss a formula that could be used to assess risk of accepting a transaction based on individual green addresses?

The way it would work is a spender would send their bitcoins from their own personal green address. It's nothing special, except that it is just an address they continuously keep funded to make rapid payments.

The idea is that the block chain can see the date of first spend, the number of transactions per day (average), even some kind of frequency analysis like even distributions over time or all bunched up a long time ago, a clean history of no double spends, etc.

On top of that, each receiving client can be programmed with risks associated with different amounts of Bitcoin received... that is, anything under 1 btc, low risk, anything over 50 btc medium risk, etc. Then the client could display some sort of indication of trust for that transaction.

What I would like to discuss, if you guys think this would be useful, is the criteria for the computation of blockchain data, and user configurable datapoints that would make this useful to the community.

Thoughts?

[1714776752]

1714776752

[1714776752]

1714776752

[1714776752]

1714776752

[1714776752]

1714776752

[1714776752]

1714776752

[jim618]

I assume you want to have a formula that uses ONLY the information on the blockchain and not depersonalising information such as "here is a copy of my driving licence and a DNA sample".

Effectively you want to create a 'risk of cheating' measure. (Or a confidence measure which is the same but in reverse).

Let us assume that you do create a formula involving only data on the blockchain, perhaps analysing double spends that have happened in the past.

Imagine I am a Rational Cheat. I will cheat and double spend if the BTC I can gain is more than the effort I expend in setting up the Cheat. If I am patient, I can create a transaction pattern to emulate whatever I need to do to emulate a 'reliable green address'.   I shuffle BTC to and fro for however many weeks I need to emulate a 'High Score' on your algorithm.  This takes time but not very much cost as moving BTC around is cheap.

I do this programmatically a thousand times, each with a separate set of transactions (i.e. the transaction graphs are completely distinct).

Everything looks great, the formula you have created matches peoples' expectation well. All previous High Trust green addresses always pay up, no double spends.

Then I, as a Rational Cheat, have a "Super Cheat Day" and create a thousand double spends, all of which are marked algorithmically as High Trust.

It's a difficult attack to stop.

[Tuxavant]

Agreed on all points.

Some slight mitigations...

The cheat can't control or has any knowledge of the thresholds set in the receiving client. A person may chose to only accept risk for micro payments and/or only account for largish transactions in the blockchain from that address. By distributing some of the actual criteria to all the users, the attack becomes less clear to the attacker and raises the bar (in transaction costs over time).

There will always be risk in accepting zero confirms, but I'm trying to get us to think about a system that would let individual users mitigate those risks with their own values. We should discuss all the points you've made, come up with more threats, and try to work some metrics that will help us measure those risks.