Thanks you guys. If I get an opportunity, I might throw a script together that would enable any vendor to easily achieve what was described. Probably as a local webpage (works offline and across all operating systems without needing special software, so it's perfectly secure) so there's a familiar GUI to work with, that would be easy and I could just put the source code here so anybody could save and operate it.[Edit: I see kmf's already posted some code, the more the merrier :)I should address the concept of salting with respecting to hashing, but I'm a bit tired at the moment, I'll come back and have a think about how to use it.]Basically:-> copy paste in buyer's address.-> data sanitation (stripping out whitespace amongst other things).-> choose what hashing function you want to use.-> you receive hash.Then in excel or openoffice, you paste the hash into a cell, and a forumale increments a cell or the hash is added to the column of hashes. I don't know much about spreadsheet coding, but I'm sure there is a way.Note: once you choose a hashing function, you should stick to it. Also, obviously if buyers play games with their addresses e.g. deliberate mis-spellings, then there's not a lot you can do about it. But, if you see something obviously misspelt, that is a 'red flag' for you. Doesn't mean they are scammer, it could be the buyer is trying to ensure more of the so called 'plausible denialability', but still.One nice security feature, but possibly controversial and we should ask for a go-ahead from DPR/SR staff is this related concept because of the sensitivity of it. With SR scaling up in size, things like this could become important.What it is, is that if people used the same hashing function (v. secure one) and they all used my exact script/spreadsheet forumale, then there is an interesting possibility to deter scammer buyers.See, a scammer buyer is one who only pays 50% of the transaction and claims it never arrived. He thinks he's a clever fellow and eventually has to create a new account since sellers get pissed off and stop dealing with him or his account is deleted etc. However, he cannot so easily, without forethought or expense to himself, change his address all the time. The address remains constant. Since it has a unique hash, more than 1 seller is going to be putting him on his personal black-list.This means, if the vendors share their black-lists of hashes publicly, not addresses, then we have some useful info because of the black-list matches.A: The quantity of scamming the person is doing.B: New vendors, who have never been scammed before by this person, see that this address translates to a hash which is of ill-repute in the community. This makes scamming self correcting.Two problems with this idea, are that somebody in that address can't 'appeal' that they're not a scammer e.g. if Mr Scammer moves out, and a legitimate SR buyer moves into the same address. The other problem is that by adapting your address in various ways, you can escape such scammer surveillance.Nevertheless, most scammers are frankly not that smart. If they were, they wouldn't be scrounging for free stuff in the first place.Also, in a worst case scenario in which LE manages to crack the hashing function somehow (v. unlikely) to decode these publicly available black-lists of hashes, they are only getting addresses, not names of people, and besides which who cares, it's an additional scammer deterrent.You just got to make sure the system isn't abused by the vendors themselves, each vendor would get 1 vote each to increment the public hash black-list. You want to prevent LE using legitimate buyer hashes they might have obtained (un-decodable, but potentially useful in this context of perverting the scammer prevention system). So, you need some manner of threshold before a scammer is added to the public hash black-list. e.g. a certain number of votes.There's probably other flaws you can spot (shout them out!), but I think the concept is essentially sound and brings more benefits than losses, it's just a matter of correctly implementing it.