Topic: Bounty 20 BTC: Wi-Fi Hotspot, enabled by bitcoin - page 2. (Read 27504 times)

I think a hotspot concept similar to ones used in airports can be done:

1) User connects to a Wireless network where they can access only one page (login page/payment page). Here the user is instructed to pay to a unique Bitcoin address and a unique reference code is generated to associate/track that reference code to the user who has made the payment. Preferably a Bitcoin address can be used instead of a payment gateway like coinbase or bitpay. Collect the users phone number to SMS the login details.

2) On payment the login details are SMS'd to the users phone number.

3) The user inputs the login details on the login page to be able to browse.

Sorry if my comment came off as negative or discouraging, but I work in this field and I'm trying to give you a more realistic picture of how something like this would get developed.

1. The reason that it would be best to run this as a server side application where the router just handles the ui is because you don't want a router handling business logic. Furthermore, it gives you more flexibility. If the logic is handled on a server, you can control which routers can access the application and you make it more accessible. The software running on people's routers would be much more light weight... all it would be is a ui and some simple logic to route requests to the main server. Like I said, it doesn't have to be done this way, but handling all that logic on the ui side is messy and sub optimal.

2. Once again, you'll be setting up your own payment system, which is what I am saying is a bad idea. You're adding unnecessary work. Why not just use an already existing service?

3. I know a lot of people who develop mobile and web applications like this for a living (I don't live in California and neither do they). The absolute cheapest that these things get developed for is still well over $100k. I work in this industry and I know how much these things cost. Software engineers are extremely expensive no matter where they work. Good software engineers are even more expensive. This is not a small project. That being said, obviously people here aren't going to be dishing out 20 btc for something like this. My point is, though, that this task would take a lot of time, and it will be hard to motivate a software engineer to put their hours towards this instead of, for example, doing some consulting work for like $100 per hour (which is very easy to find).

I don't know enough about Electrum (afaik. it requires some kind of custom remote server), but accessing web wallets is out of scope for sure. Proper SPV wallets such as bitcoin-wallet on Android are able to connect to bitcoind instances.

As Bitcoin-core can prune the blocks on disk, I don't see any reason not to use a proper client instead of something that relies on remote trusted third parties. If you want to add extra stuff (such as connectivity to a local Electrum server or similar - or even connecting to web wallets or other external services) be my guest, but it should at least be configurable service by service - these tend to die out from time to time due to security fluctuations (just look at this thread here and check how many links still work)...

At least bitcoind-access-only mode has to be provided and working, if other services are also provided (e.g. you'd likely need to resolve DNS queries to even let users contact circle.com), they need to have an off-switch.


1. I'm not so sure why the server should handle routing, otherwise I don't see how a DD-WRT router shouldn't be capable of most of the legwork (except for handling more complex payments/cryptokeys in case a more modern approach is taken than "pay x amount and once confirmed (or marked non-RBF), you get network access for y minutes or z MB of traffic credits"). In the end it doesn't matter much, since there will have to be a trusted full node somewhere in the local network anyways, so running a small server there won't do much harm I guess.

2. No, read through this thread and on the concept of payment channels. Also the point of Bitcoin is to be able to handle your own infrastructure - bitcoind is more than capable of handling payments securely and it can also submit arbitrary payments to the network. The back-end server would be online anyways of course.

3. Maybe in Silicon Valley it would? I personally don't see a big market behind this, which is why I'm not going to start a company and collect funds to develop this stuff - if however someone wants to: feel free to do so! If you want to receive money from me as a reward/bounty/donation/whateveryoucallit, I think I was quite clear under which circumstances I would be willing to hand over the equivalent of several hundred USD in current value (which is still the SAME amount of BTC by the way that I offered years back when it was about 20 USD!). Joinmarket for example is a project that is getting close to the maturity that I'd expect and I doubt that it cost several 100k of USD... Anyways, thanks for your opinion.

So a couple points to be a little bit realistic here:

1. The best way to implement a solution for this would be to use one remote server-side application, and a client-side application that would run on a router. The client would basically forward all requests to the server, and the server would handle payments, authentication, and re-routing.

2. If you wanted to implement this as just a client side application where anybody can use it, that would be possible too. However, it would require communication with the internet in order to perform bitcoin transactions. Furthermore, it would be unreasonable to not use an external service for handling bitcoin payments. Building a bitcoin payment system from scratch would be a horrible idea... way too much time and effort to try to reinvent the wheel.

3. I seriously doubt you can find good software engineers who are going to want to build this as open source. Or if they did, the reward would have to be way way way more than 20 BTC. An app like this wouldn't be too difficult to make, but it would be VERY time consuming. There are a lot of moving parts involved. In real life, something like this would most likely cost at least several hundred thousand dollars to develop.

I agree with bitspill's point.

I might be able to contribute toward a solution if that was relaxed. My team is currently doing a large dd-wrt project involving bitcoin and ad-hoc mesh networking. I'll talk with them about it if that constraint could be reconsidered.

That part is a little impractical, you'd have to allow users to access the most common spv servers and online wallets since most will not be running around with full nodes. It'd be more likely that a client is running electrum or simply using their circle account than that they'd be going around with bitcoind installed on their laptop or worse cellphone.

Maybe not 20 BTC, but I'd still chip in with 1 or 2 BTC for a solution that:

* is free software under BSD, MIT or ISC license (no GPL)
* does NOT require any external API or service provider on the internet, the only service running that can be assumed is a trusted bitcoin-core server on the local network. No "21 inc. computer" either.
* does NOT spam the block chain with useless transactions (can be achieved e.g. by using payment channels or lightning network). At most one connection to the AP = 1 transaction on the block chain (or less, if traffic/time is bought ahead of time or a balance is kept open).
* has good (unit, performance and integration) test coverage
* is packaged at least for DD-WRT and 2 other major Linux distributions
* allows a user who has not signed in or paid to connect to the local bitcoind (to download blocks etc.) or to view the landing page that contains the payment info. Not more, not less.

Back then BTC was ~$5 each. You're not actually asking for 20BTC at today's price, are you?

Yep, it's not that hard.
I can do it, if the bounty still stands (escrowed   ) in this BTC price

I would have to agree. It seems that those who have the talent, don't have the interest in such a project.

This sounds like a really cool idea. I don't think it would be terribly difficult either. Just have to set up some APIs for making payments and adding some unique identifier for the current device to a list of verified devices. And then of course you'd need all requests to go through your application, and block ones that are not found in the list of verified devices (or have expired or whatever).

... lack of talent is the major holdup, imho.

It really surprises me that this has been an idea for so long by so many different people and has yet to be anything usable. Whats the major holdup?
While I like that there are projects out there for the 21 computer, Id like to see this done on a rpi or even windows/linux desktop on the network.

Wow this is a great idea. Good luck to anyone who attempts this.

correct

MoonShadow was the 7th poster and followed/contributed all along, they likely aren't the original poster but was a fan of the idea and willing to contribute.

This post was made by a different account than the one you just posted. Does this mean that this is an alt of yours?

Just to be clear, this bounty was posted several years ago, and I am definitely no longer willing to give 20 BTC now.

Last commit over a year ago, a big warning in the readme that it is NOT production ready and not licensed...

Wow, it is really a ultra nice contribution, really apreciated, i thinkit could be a fantastic bussines model for a international coop, cheap hardware and thousand of millions of potential customers