> I think my ideal system would be something where a website can offer a bitcoin* address in a header, and at the end of the month my browser randomly picks a set of addresses it's seen, and sends money to them. (In conjunction with current ad-blocking technology.)

This is so ripe for abuse it's not even funny. It would take clickjacking to a whole new level.

This is the whole problem with microtransactions: sites need them to be frictionless or else users will abandon the flow no matter how low the price is, but financial transactions need some sort of user confirmation or else they're wide open to abuse.

> This is the whole problem with microtransactions: sites need them to be frictionless or else users will abandon the flow no matter how low the price is, but financial transactions need some sort of user confirmation or else they're wide open to abuse.

I agree. I solved this problem with a 3-party protocol (user, provider, authenticator) that can't be subverted by either the user or the provider.

No user intervention is required; it works seamlessly. User identity is not revealed and the provider cannot piggyback on the shared tokens to create a persistent identifier. The same scheme can be used to provide effortless passage through paywalls, as well as enabling the same model as Contributor (and before them Kachingle, Contenture, Readability and several others who've failed).

As the authenticator would essentially need to maintain a list of verified providers, you would have to do a lot of work to figure out which providers are legit and which are fraudulent. Even distributed across a whole bunch of transactions, the cost is likely too high when each transaction is a fraction of a cent. That's just a show-stopper for microtransactions.

The technology is the easy part for microtransactions. Simplifying the business rules to the point it can cheap enough to operate financial transactions safely is the hard part.

> As the authenticator would essentially need to maintain a list of verified providers, you would have to do a lot of work to figure out which providers are legit and which are fraudulent.

If payment is proportional to usage, then a linkbait/clickbait scheme won't work. The point is to reward genuine repeat visits to a site you like.

If the profit is too low, fraudsters simply go elsewhere.

>So with this system, the same amount of space is still taken up by ads? I don't think that's really a huge improvement.

It will continue to take up space in most cases (but the system will make an ad block disappear completely if in some circumstances)

But you can go into your settings and set what you want to show up there.

It can be the default (a strange checkerboard mosaic thing), a selection of cat pictures, some abstract colors, a blank space, or you can set it to a custom URL (like a 1px by 1px gif image) which will make them collapse in a similar way to adblockers.

Someone could probably build a browser plugin to at least keep track and divvy up money. The real problem is people say they want to support sites but they really don't want to see ads or support the site.

Yes every site should be sending a bitcoin receiving address in the headers, or embedded in the HTML for when a single page has two areas of content from different providers.

Payout could be based on a number of factors, including existing ads on the page (downvote), number of visits (upvote), seconds of streaming video watched (upvote), etc.

Or, even better, gave a proportional amount based on the amount you've visited. Better yet, give a Humble-Bundle-like distribution slider to allow you to alter it by preferences ("HN already has funding, give all of my BTC to individual bloggers they've linked...").