Webpass(webpass.io)
webpass.io
Webpass
https://webpass.io/
78 comments
If a subscriber doesn't visit any of our existing partners, then we don't pocket that money which was intended for websites. Instead, it's set aside as a fund for helping new websites to join, with a particular priority on those sites that our subscribers use the most.
It may not be so bad if all of a subscriber's money goes towards a single publisher. We measure rates in terms of RPM. In such a circumstance, that single publisher is receiving an excellent RPM, and that gives us a good argument for convincing new websites to join.
As you can imagine, there are many things on our to-do list -- but a list of participating sites seems to be frequently requested, so that needs to move up in priority.
It may not be so bad if all of a subscriber's money goes towards a single publisher. We measure rates in terms of RPM. In such a circumstance, that single publisher is receiving an excellent RPM, and that gives us a good argument for convincing new websites to join.
As you can imagine, there are many things on our to-do list -- but a list of participating sites seems to be frequently requested, so that needs to move up in priority.
A list of participating sites should be your absolute number 1 priority. Like, a call away.
It is what I buy on your page.
It is what I buy on your page.
> If they have no partners, they still collect money, but have no one to give it to at the end of the month, so they'll have to keep it.
IANAL, but my suspicion is that the law of trusts will make this ugly, unless they write "we get to keep it" into their TOS.
My own approach is to levy a fixed percentage and only pay out to participating sites. Readability tried to do the whole accumulate-for-not-participants as a way to try and create dangling carrots for publishers.
It didn't work: it just tied up a bunch of cash, because finding out who to contact for a lot of websites is difficult. Add to that the relatively small amounts of cash held for a given website, spread across many sites, and it would've created a helluva mess.
Disclaimer: I'm working on a competing product.
IANAL, but my suspicion is that the law of trusts will make this ugly, unless they write "we get to keep it" into their TOS.
My own approach is to levy a fixed percentage and only pay out to participating sites. Readability tried to do the whole accumulate-for-not-participants as a way to try and create dangling carrots for publishers.
It didn't work: it just tied up a bunch of cash, because finding out who to contact for a lot of websites is difficult. Add to that the relatively small amounts of cash held for a given website, spread across many sites, and it would've created a helluva mess.
Disclaimer: I'm working on a competing product.
Would you mind sharing the basic premise of your product. I'm also trying to create some partnerships for a similar product.
Well it's the same general premise everyone stumbles on when they think about the problem for more than a few minutes. I call it "microsubscription".
Pay a service a fixed monthly amount. That service follows you as you visit participating publishers. At the end of the month, the service divvies up your payment amongst publishers based on some kind of formula, typically proportional to visits, clicks, time-on-site etc.
As I said elsewhere, the major technical problem has typically been that it's very easy to attack such schemes at the browser or at the publisher in order to create "visit multiplication". The scheme I designed relies on each of three parties -- a browser, a publisher and an authentication server -- providing independent verification of a particular network transaction occurring. Lashings of crypto, essentially.
My first protocol design, the subject of an honours dissertation, was hilariously broken. My second design was a ground-up redesign and independently reviewed by a fairly decent cryptographer.
I generalised the design so that any application protocol with some kind of control channel could be fit into the model.
I intended to create a scheme where users could avoid ads, pay for sites they like, get an easy pass through paywalls, without cheating and without user trackability.
None of this solves the fact that there are non-technical considerations that will probably be far more influential on the final outcome, barring a dramatic uptick in fraudulent activity souring the pot for my competitors. Google can get around this with their existing talent and technology for sniffing out fraud. The rest of us must make do with better protocols.
Pay a service a fixed monthly amount. That service follows you as you visit participating publishers. At the end of the month, the service divvies up your payment amongst publishers based on some kind of formula, typically proportional to visits, clicks, time-on-site etc.
As I said elsewhere, the major technical problem has typically been that it's very easy to attack such schemes at the browser or at the publisher in order to create "visit multiplication". The scheme I designed relies on each of three parties -- a browser, a publisher and an authentication server -- providing independent verification of a particular network transaction occurring. Lashings of crypto, essentially.
My first protocol design, the subject of an honours dissertation, was hilariously broken. My second design was a ground-up redesign and independently reviewed by a fairly decent cryptographer.
I generalised the design so that any application protocol with some kind of control channel could be fit into the model.
I intended to create a scheme where users could avoid ads, pay for sites they like, get an easy pass through paywalls, without cheating and without user trackability.
None of this solves the fact that there are non-technical considerations that will probably be far more influential on the final outcome, barring a dramatic uptick in fraudulent activity souring the pot for my competitors. Google can get around this with their existing talent and technology for sniffing out fraud. The rest of us must make do with better protocols.
> Google can get around this with their existing talent and technology for sniffing out fraud. The rest of us must make do with better protocols.
To defraud webpass etc, you need to be able to sign up as a creator, so if they're not interested in signing up the world (as most adtech players are), they can probably get pretty far just by partnering with reputable sites and forcing them to track and reveal which portions of their traffic is sourced vs organic.
At some point they'll probably want to sign up the entire web too, but by that point they should be large enough to warrant buying the tech from a 3rd party fraud verification provider or build their own in house.
I will say that, knowing what kind of fraud goes on in advertising, I am skeptical that a new protocol would do much besides adding an extra (static) hurdle for fraudsters.
To defraud webpass etc, you need to be able to sign up as a creator, so if they're not interested in signing up the world (as most adtech players are), they can probably get pretty far just by partnering with reputable sites and forcing them to track and reveal which portions of their traffic is sourced vs organic.
At some point they'll probably want to sign up the entire web too, but by that point they should be large enough to warrant buying the tech from a 3rd party fraud verification provider or build their own in house.
I will say that, knowing what kind of fraud goes on in advertising, I am skeptical that a new protocol would do much besides adding an extra (static) hurdle for fraudsters.
You might have already considered it, but as a potential user I'd like to have the chance of adjusting the percentages at each billing period (month for example) to avoid rewarding sites that use tricks to increase page count or other metrics.
By default, percentages go to each visited site as determined automatically by your service.
I'd also like to veto certain publishers, to avoid giving them money when landing there from obscured redirections or by accident.
Of course, if I veto a site then I would not get privileged access to it. That's fine.
That might be at odds with your three-party verification scheme; this is just a suggestion in case it might be useful.
By default, percentages go to each visited site as determined automatically by your service.
I'd also like to veto certain publishers, to avoid giving them money when landing there from obscured redirections or by accident.
Of course, if I veto a site then I would not get privileged access to it. That's fine.
That might be at odds with your three-party verification scheme; this is just a suggestion in case it might be useful.
I hadn't considered adjusting percentages, but I had considered allowing people to complain about and/or exclude websites from payment (veto, in your term).
Otherwise my inclination is to stick to a formula, because you have to balance the interests of users and providers for a network effect to form.
Otherwise my inclination is to stick to a formula, because you have to balance the interests of users and providers for a network effect to form.
I'm trying to do this too but I have a way in that doesn't involve too much capital... Maybe we should have a chat?
This is scary - you mean I pay you to track every website I visit and you transparently pay them to not show Ads?
It doesn't say who get's what data, which sites are involved and there is no way I'm installing their browser plugin! Oh dear!
It doesn't say who get's what data, which sites are involved and there is no way I'm installing their browser plugin! Oh dear!
Check out our privacy policy at https://webpass.io/privacy for a detailed explanation of what we do with your data. If there are any scenarios that aren't clearly explained that concern you, please let me know and I can have the policy updated.
Does your service block trackers as well as ads? It's not clear at all what exactly gets blocked.
Mind you, since the service acts as a tracker in its own right, people wanting to avoid being tracked are unlikely to use it in the first place...
Mind you, since the service acts as a tracker in its own right, people wanting to avoid being tracked are unlikely to use it in the first place...
I am the OP. I run a website that uses webpass.io. I am not posting a link to the site to avoid self-promotion but it should be easy enough to find.
With that said, here is MY implementation. Other publishers may do it differently.
Our site is a discussion forum. People can browse at will but only logged in users can post and reply to topics.
We run advertising with Google DFP. A few years back we started offering a subscription where users pay us a recurring fee and they have the option to turn ads on/off in their profile.
I myself thought of using a micro-payment service but I wanted something easy.
The way webpass works is by their add-on sending a unique token on every page request. If there's a token my code checks with their server if it's a valid token. If yes we then have two options:
- if you are not logged in then we completely remove the ad scripts BEFORE sending the page to the browser client.
- if you are logged in we treat your session as a subscriber session and will send or not the ad scripts based on your profile preferences. This means you can go to your profile page and turn ads on/off.
Using webpass made the experience better for our users because even those people who don't want to create another web profile and pay another subscription can still get to our site ad free.
Does it make sense now?
With that said, here is MY implementation. Other publishers may do it differently.
Our site is a discussion forum. People can browse at will but only logged in users can post and reply to topics.
We run advertising with Google DFP. A few years back we started offering a subscription where users pay us a recurring fee and they have the option to turn ads on/off in their profile.
I myself thought of using a micro-payment service but I wanted something easy.
The way webpass works is by their add-on sending a unique token on every page request. If there's a token my code checks with their server if it's a valid token. If yes we then have two options:
- if you are not logged in then we completely remove the ad scripts BEFORE sending the page to the browser client.
- if you are logged in we treat your session as a subscriber session and will send or not the ad scripts based on your profile preferences. This means you can go to your profile page and turn ads on/off.
Using webpass made the experience better for our users because even those people who don't want to create another web profile and pay another subscription can still get to our site ad free.
Does it make sense now?
Uploading the list of installed browser extensions is unnecessary (you say so yourself in your Privacy Policy) and reveals a lot of information about the user.
I'm out.
I'm out.
You are right, this is not necessary, and we stopped recording this information a while ago. Sending this information should be an option that users can turn on or off at their leisure, if it happens at all. Our aim is to provide our users as much privacy, and control over their privacy, as we can, and this old design choice does not fit that aim.
The Firefox addon has never sent that information, and (though not recorded anyway) we'll be removing it from the Chrome extension and updating our privacy policy shortly.
The Firefox addon has never sent that information, and (though not recorded anyway) we'll be removing it from the Chrome extension and updating our privacy policy shortly.
At least here you are aware of what is going on, you're tracked for a reason and you have the possibility to stop it anytime.
The Internet as a whole is scary. Everyone tracks you. You are also tracked and profiled behind your ad-blocker. So no big[ger] deal...
The Internet as a whole is scary. Everyone tracks you. You are also tracked and profiled behind your ad-blocker. So no big[ger] deal...
> there is no way I'm installing their browser plugin
Plugins provide a sandbox which hostile publishers can't attack. It also helps that plugins get a much richer API to work with.
Disclaimer: I'm working on a competing product.
Plugins provide a sandbox which hostile publishers can't attack. It also helps that plugins get a much richer API to work with.
Disclaimer: I'm working on a competing product.
Which one? I've seen a few in this space... I thought I was being original :-D
Robojar. As I said elsewhere, I've been entirely too busy focusing on the core protocol design -- it was the subject of an honours dissertation and then a patent application.
Nobody's heard of it because I am still bad at thinking like a product person instead of an engineer.
Nobody's heard of it because I am still bad at thinking like a product person instead of an engineer.
I like Google Contributor more: you as a visitor participate in the ad bidding and win the ad space if your bid wins. The website gets exactly what he would get from your visit as before.
Too complicated for people to understand and their funds can get depleted very quickly. Also some websites run Google AdSense as an infill, so Google Contributor doesn't really deal with publishers that have a direct sold inventory first, AdSense second policy.
The webpass.io subscription service is a change from the standard consumer - publisher relationship. Instead of having to create and maintain subscriptions with different websites, consumers can subscribe to a single service and affiliated websites can check with the platform to confirm entitlement - thus eliminating friction.
Depending on how websites configure the service customers don't need to create local accounts to get benefits - unless of course sites require accounts for things such as posting comments in topics and articles, or using other non-subscriber's related services.
I am not involved with the service, except as being a publisher using the platform as an alternative to ad-based revenue/subscription model.
Depending on how websites configure the service customers don't need to create local accounts to get benefits - unless of course sites require accounts for things such as posting comments in topics and articles, or using other non-subscriber's related services.
I am not involved with the service, except as being a publisher using the platform as an alternative to ad-based revenue/subscription model.
What is your website? Did you completely remove ads from it in favor of webpass.io?
I posted this reply to another question, but will repost here for your benefit:
I am the OP. I run a website that uses webpass.io. I am not posting a link to the site to avoid self-promotion but it should be easy enough to find.
With that said, here is MY implementation. Other publishers may do it differently.
Our site is a discussion forum. People can browse at will but only logged in users can post and reply to topics.
We run advertising with Google DFP. A few years back we started offering a subscription where users pay us a recurring fee and they have the option to turn ads on/off in their profile.
I myself thought of using a micro-payment service but I wanted something easy.
The way webpass works is by their add-on sending a unique token on every page request. If there's a token my code checks with their server if it's a valid token. If yes we then have two options:
- if you are not logged in then we completely remove the ad scripts BEFORE sending the page to the browser client.
- if you are logged in we treat your session as a subscriber session and will send or not the ad scripts based on your profile preferences. This means you can go to your profile page and turn ads on/off.
Using webpass made the experience better for our users because even those people who don't want to create another web profile and pay another subscription can still get to our site ad free.
I am the OP. I run a website that uses webpass.io. I am not posting a link to the site to avoid self-promotion but it should be easy enough to find.
With that said, here is MY implementation. Other publishers may do it differently.
Our site is a discussion forum. People can browse at will but only logged in users can post and reply to topics.
We run advertising with Google DFP. A few years back we started offering a subscription where users pay us a recurring fee and they have the option to turn ads on/off in their profile.
I myself thought of using a micro-payment service but I wanted something easy.
The way webpass works is by their add-on sending a unique token on every page request. If there's a token my code checks with their server if it's a valid token. If yes we then have two options:
- if you are not logged in then we completely remove the ad scripts BEFORE sending the page to the browser client.
- if you are logged in we treat your session as a subscriber session and will send or not the ad scripts based on your profile preferences. This means you can go to your profile page and turn ads on/off.
Using webpass made the experience better for our users because even those people who don't want to create another web profile and pay another subscription can still get to our site ad free.
Oh drat, another competitor. I am losing track of who I am trying to beat.
Google Contributor, Kachingle, Webpass, Brave, Flattr, Blendle and I have probably overlooked a bunch. There's also a deadpool with Sprinkepenny, Contenture, Readability and -- again -- I've probably overlooked a few.
The core problem is preventing two classes of attack:
1. Visit multiplication by publishers, intended to over-represent them in the monthly scoring.
2. Money-laundering of stolen cards by using bots to sign up and visit an attacker-controlled site.
There is also the matter of preventing a publisher in the middle from tracking users by piggybacking on shared identifiers.
To my very great shame, I've spent too much of my time solving these problems rather than working on the business side of things.
Edit: at least it's another Australian :)
Google Contributor, Kachingle, Webpass, Brave, Flattr, Blendle and I have probably overlooked a bunch. There's also a deadpool with Sprinkepenny, Contenture, Readability and -- again -- I've probably overlooked a few.
The core problem is preventing two classes of attack:
1. Visit multiplication by publishers, intended to over-represent them in the monthly scoring.
2. Money-laundering of stolen cards by using bots to sign up and visit an attacker-controlled site.
There is also the matter of preventing a publisher in the middle from tracking users by piggybacking on shared identifiers.
To my very great shame, I've spent too much of my time solving these problems rather than working on the business side of things.
Edit: at least it's another Australian :)
Australian, too? Would you be able to get in touch? There are contact details on our website.
[deleted]
Hey don't forget Optimal.com - Americans/South Africans!
It's one of those ideas which is about to seize the zeitgeist.
Apple and Google have, for different reasons, dramatically accelerated the timetable for microsubscriptions.
Apple and Google have, for different reasons, dramatically accelerated the timetable for microsubscriptions.
I use an ad blocker because I hate the idea being tracked. Hiding ads is simply a plus. I like the idea behind Webpass but they do nothing to prevent the tracking part of the whole ad blocking discussion.
I'm one of the co-founders of Webpass.io, and a dislike of being tracked is the primary reason why I am inclined towards using an adblocker myself. Before I realised the amount of tracking that went on, I hadn't been motivated enough to use an adblocker.
Webpass.io has been designed with this in mind. Webpass.io involves removing the advertiser from the transaction -- partnering sites remove advertisements, which should eliminate tracking by advertisers. When it comes to trackers from other sources (e.g., analytics), you can continue to use plugins like Ghostery or the EasyPrivacy list.
Webpass.io is a way for you to support websites, that is compatible with whatever means you use to protect your privacy. You don't need to opt into ads/trackers/third party cookies for our service to work. We track little from our users (check our privacy policy), and we have plans for the future to make our privacy features even stronger by offering (near) anonymous use of our system.
As for our own website, we have avoided using any code that could be used to track you by third parties -- no social media buttons that talk back to their original servers, no third-party commenting system, no third-party analytics, and so on.
Webpass.io has been designed with this in mind. Webpass.io involves removing the advertiser from the transaction -- partnering sites remove advertisements, which should eliminate tracking by advertisers. When it comes to trackers from other sources (e.g., analytics), you can continue to use plugins like Ghostery or the EasyPrivacy list.
Webpass.io is a way for you to support websites, that is compatible with whatever means you use to protect your privacy. You don't need to opt into ads/trackers/third party cookies for our service to work. We track little from our users (check our privacy policy), and we have plans for the future to make our privacy features even stronger by offering (near) anonymous use of our system.
As for our own website, we have avoided using any code that could be used to track you by third parties -- no social media buttons that talk back to their original servers, no third-party commenting system, no third-party analytics, and so on.
[deleted]
The pricing page is a good example of what not to do. If you're going to list distinguishing features/limits for various plans, please don't put "unlimited" on the free plan, limits on other plans, and force everyone to dig through your terms of service just to understand the real limits.
Also, a plan that automatically "upgrades" based on criteria tucked away in the ToS should probably just be called a trial, and the conditions that cause that trial to be converted to a paid plan should be explained somewhere on the pricing page.
Also, a plan that automatically "upgrades" based on criteria tucked away in the ToS should probably just be called a trial, and the conditions that cause that trial to be converted to a paid plan should be explained somewhere on the pricing page.
also the .50 in a really small font, making it $5.50 not $5.00.
> Adblockers deny money for websites without replacing it.
I hate the way this frames the debate. Ads invade my privacy, slow down my Internet browsing, and consume my network and device resources—why can't the cost for content writers, servers, etc come from some other business model than invading my privacy?
I hate the way this frames the debate. Ads invade my privacy, slow down my Internet browsing, and consume my network and device resources—why can't the cost for content writers, servers, etc come from some other business model than invading my privacy?
The current model for alternative revenue sources is... "content". Mainly "sponsored content" where publishers post reviews and whitepapers, some times not disclosing their relationship with the advertisers. I think this is worst than ads.
In their code examples they indicate that this works by:
1) plugin sets header key
2) the site servings ads needs to hit an API endpoint to verify
the header keys' value before rendering ads.
The page simply removes the ads before serving
Correct. In our case we check with the endpoint and if the key is correct and approved we just serve the page WITHOUT the ad scripts.
This not only make pages smaller but also reduces the amount of processing on the client browser. Overall it's as fast, if not faster, than an ad blocker.
This not only make pages smaller but also reduces the amount of processing on the client browser. Overall it's as fast, if not faster, than an ad blocker.
So even at the "worst" pricing of 0.15¢ per page ($3/mo for 2000 pages) and assuming a 100% payout, a big, high traffic publisher like Gawker would have made under $2m in 2014 (on 1.3bn pageviews) versus the $45m they actually netted.
The numbers would be even more awful for niche, high quality publishers (no offense to Gawker, but they're mass media).
This has no chance of replacing anyone's income, and barely a chance at significantly supplementing one, until we're talking cents per page.
The numbers would be even more awful for niche, high quality publishers (no offense to Gawker, but they're mass media).
This has no chance of replacing anyone's income, and barely a chance at significantly supplementing one, until we're talking cents per page.
I don't think you're argument is wrong overall, but I think your math is orders of magnitude wrong. 0.15c/page is a $1.50 CPM rate, and that's really is pretty low, for the web and premium publishers in particular, your math puts Gawker at $35 CPM, however I think your math is off by about a factor of by about a factor of 2-3.
Some quick googling will show the Gawker advertising revenue number is actually $30m; $15m being from ecommerce/licensing + native advertising/sponsored content.
I'm not sure where you pulled 1.3bn/yr from, but at $30m in revenue that would assume Gawker is obtaining CPMs of $23 for all of it's advertising. $23 CPMs are real: in video advertising, but they are totally out of whack for display, even premium display is only commanding about half that: http://www.mediafuse.com/resources/a-guide-to-cpm-rates
I don't know what CPMs Gawker is actually getting, but I think that it's likely that your traffic estimate is probably off by quite a bit since 3rd party traffic estimates are notorious for undercounting traffic.
So, Gawker probably wouldn't be excited about this, but very few people are able to monetize display at that rate, so you may find some publishers that are still interested at this rate, though I do agree that it's particularly low and is only interesting as a last ditch effort of monetizing ad blockers. Though maybe that will be useful in certain communities that heavily favor them.
Some quick googling will show the Gawker advertising revenue number is actually $30m; $15m being from ecommerce/licensing + native advertising/sponsored content.
I'm not sure where you pulled 1.3bn/yr from, but at $30m in revenue that would assume Gawker is obtaining CPMs of $23 for all of it's advertising. $23 CPMs are real: in video advertising, but they are totally out of whack for display, even premium display is only commanding about half that: http://www.mediafuse.com/resources/a-guide-to-cpm-rates
I don't know what CPMs Gawker is actually getting, but I think that it's likely that your traffic estimate is probably off by quite a bit since 3rd party traffic estimates are notorious for undercounting traffic.
So, Gawker probably wouldn't be excited about this, but very few people are able to monetize display at that rate, so you may find some publishers that are still interested at this rate, though I do agree that it's particularly low and is only interesting as a last ditch effort of monetizing ad blockers. Though maybe that will be useful in certain communities that heavily favor them.
Quantcasts puts Gawker Media _Network_'s traffic numbers for 2014 at 7.2b for that time period, so that would give a pre-partner (display) RPM of $4.1
3e7 / 7.2e9 x 1000
And a post partner RPM of $6.25
4.5e7 / 7.2e9 x 1000
This seems plausible.
I think it's fair to consider both since ad-blockers will pick up a bunch of the listing/affiliate code implementations for the extant partner related initiatives.
3e7 / 7.2e9 x 1000
And a post partner RPM of $6.25
4.5e7 / 7.2e9 x 1000
This seems plausible.
I think it's fair to consider both since ad-blockers will pick up a bunch of the listing/affiliate code implementations for the extant partner related initiatives.
BTW they're Quantcast's numbers - Gawker specifically refers you to them for their traffic numbers so I guess they're feeding them their traffic stats.
I'd be curious to know how many people would need to use such a service for the ad maker to make the same amount of money. Basically, what I'm wondering is if it would be similar to Wikipedia where a very few percentage of people need to contribute for the system to work out?
Atri (http://www.atri.me) does just this, but bypasses the sites and uses the Twitter Handles on the page as the creator of record.
Interesting concept
But Adblock is free. Wouldn't a simple donate button be just as effective?
Donate buttons are a joke. They don't work for publishers at all.
I would happily pay an extra $5 a month to my ISP to have them allocate it to the pages I visit. More if they let me select a subset.
You actually want the ISPs, some of the most hated companies in the country, to "fairly distribute" that money for you?
I have an account with them. And they're already doing it for my TV channels.
They're also providing a reliable 100Mbps link 4 miles from the nearest sewer pipe. Seems like they could handle 50 lines of code to parse logs and disburse payments.
They're also providing a reliable 100Mbps link 4 miles from the nearest sewer pipe. Seems like they could handle 50 lines of code to parse logs and disburse payments.
I keep waiting for some serious content creator to try a bitcoin micropayment system. From there it's a small stretch to envision a third party like this one to take care of SSO and varying pay rates per provider.
The set of people willing to pay for online content is tiny. Intersect that with the set of Bitcoin users and you're now targeting maybe twenty people, ten of whom are against SSO because it has the potential to track their access to multiple properties, and another five of whom require instant access but won't agree to significant transaction fees.
Maybe there's a hidden market waiting to be tapped, and I'll look like an idiot when BitPass™ reaches a one billion valuation, but it looks to me like you have a good reason to wait instead of doing it yourself: it's real damn risky.
Maybe there's a hidden market waiting to be tapped, and I'll look like an idiot when BitPass™ reaches a one billion valuation, but it looks to me like you have a good reason to wait instead of doing it yourself: it's real damn risky.
Not bitcoin but https://blendle.com is the closest to what you're suggesting.
Why bitcoin?
Why not 'regular money' that more people have?
Why not 'regular money' that more people have?
The general assumption is that real money means subjecting your business to the percentages and per-transaction fees taken by banks and payment processing companies, making micropayments unprofitable.
Bitcoin also has fees. Also delays. Also wildly fluctuating price. Something like flattr seems like a much better idea.
I think to help decentralised it so that there is no "signing up" by any party involved.
It's easy to charge 5 cents to read an article using Bitcoin. With processing fees, this isn't super easy using credit cards.
Look up the current fees for bitcoin transactions; they're more expensive. Also much slower.
Yeah, but I think that largely depends on the degree of security you want to have in your blockchain. For example you could use something of a multi-party signing-scheme for consensus that regularly stamps hashes of it's own table into the bitcoin blockchain - this kind of scheme would be significantly less expensive to implement since you could pack thousands of transactions into a single bitcoin transaction. I'm not really sure micro-payments are the answer to add blocking to begin with though -
Are you kidding me? You have no idea what you are talking about. The bitcoin transaction has to come from the sender. You are dreaming
You can have multiple inputs / outputs per bitcoin transaction, so presumably that's what he's talking about.
> You can have multiple inputs / outputs per bitcoin transaction, so presumably that's what he's talking about.
Actually that's not it. What I'm saying is that you can have any normal multi-party signature scheme, where every N signing-rounds you ensure some measure of canonical ordering by publishing the hash in the bitcoin blockchain. I think sidechains are probably formulated in a similar fashion but it's been a while since I've looked at exactly what they are doing, the trickier parts if I remember correctly are transfers of value on and off the original chain.
Actually that's not it. What I'm saying is that you can have any normal multi-party signature scheme, where every N signing-rounds you ensure some measure of canonical ordering by publishing the hash in the bitcoin blockchain. I think sidechains are probably formulated in a similar fashion but it's been a while since I've looked at exactly what they are doing, the trickier parts if I remember correctly are transfers of value on and off the original chain.
Oh yeah, that'd be great. I can't wait until the day when I find a good article, click the button to pay to read it, and then wait around for an hour or two while the payment is "confirmed" before I can read it.
If they have no partners, they still collect money, but have no one to give it to at the end of the month, so they'll have to keep it.
I also have no desire for the entire subscription to go to a website I visit one time in a month because they're the only one participating. This is not necessarily a deal breaker, but I can't even make an informed decision without a list of participating sites.