Topic: A Warning Against Using Taint - page 8. (Read 16246 times)

As someone who coded this sort of thing to watch addresses, I can tell you is it definitely technically feasible, but like Stephen says, I would wholeheartedly disagree with using it. You're going to find that huge numbers of coins are "tainted" illegitimately (accidental sends could give a blacklisted address the power to blacklist other addresses) so any blacklist is going to eventually include coins that were sent in error or even completely legitimately.

Specifically I take issue with this:

What user would want to use a client that could ignore that their own wallet has Bitcoin in it? Why would we want the network to essentially *destroy* coin in the first place? It just doesn't make sense.

Also, Bitcoin works very hard to return us back to the "buyer-beware" type system of handling financial transactions, any departure from this system returns us closer to a "lobby-owned" currency, whereby small groups control what is and is not currency, and ensure that others don't ever have enough of it. Long live the Blockchain.

+1

Couldn't have said it better.

A huge +1.

You introducing a system that imposes a form of taint does nothing to prevent theft but does make using Bitcoin a hassle for those who are innocent.

Therefore I do not support this and will vigorously reject any movement towards this initiative and any like it.

The following proposal has been characterized as a horrible idea (see replies), so I thought it would be fair warning to others who explore the idea.

The Personal Blacklist
I propose a new feature called "blacklist".  This feature allows the user to enter BC addresses into his own personal blacklist because they want to know when they receive BC that came from a certain address.  I think the user should also be able to set a threshold so that any transactions from the blacklisted address that are under that threshold would be ignored handled as if they came from a good address. [Added with title change:] The user should also be able to establish a whitelist so that any transactions coming from whitelisted addresses would not be searched back any further.

The Search
Whenever the user receives BC, the feature will search back through the blockchain to find all the transactions that added funds to that address to see if any of them are in the blacklist.  It does this recursively til it finds either an address in the blacklist or all the blocks that created all the BC that ever found its way into the senders address.

The Output
If the generation blocks for all bitcoin are found without finding any blacklisted addresses, the user gets a happy Message.
If an address is found that is in the blacklist then the user gets the following information:
Some of this bitcoin comes from Blacklisted address XXX:

Block#	Date/Time	Amount	Sent By	Received By
#	//::	#BC	XXX	YYY1
#	//::	#BC	YYY1	YYY2
#	//::	#BC	...	...
#	//::	#BC	YYYn	ZZZ

ZZZ is the user's address.

At this point, the user can either request the sender to send non-stolen bitcoins and provide the thief's address to the sender who can add it to his own blacklist, and probably a link to posts on the internet that explain the theft.

This will have the effect of dividing the BC community into those willing to accept stolen bitcoin (either because they don't know, or because they don't care) and those who aren't.

But what if your address holds stolen bitcoin?  That would be detected when you add a thief's address to your blacklist.  At that point, you get several lists just like the one above, one for each sender who has sent stolen BC to your address.  It's up to you to figure out what to do about it.

This proposal only empowers Bitcoin client users to have more information about their counterparties.  I suspect and hope it would grow into a major headache for bitcoin thieves.  It will certainly be a headache for all BC users who have a lot of transactions, but only if people with great goods and services who accept BC decide to refuse service to recipients of stolen funds, and use low thresholds.  So the effectiveness/headache tradeoff is in the hands of the users, where it should be, and the more work we put into it, the more the thief suffers.

Comments?