Bounty 20 BTC: Wi-Fi Hotspot, enabled by bitcoin

[Sukrim]

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.

[1714127815]

1714127815

[1714127815]

1714127815

[bitspill]

* 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.

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.

[ZeroGee]

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.

[K128kevin2]

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.

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.

[Sukrim]

* 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.

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.

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.

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.

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.

[K128kevin2]

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.

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.

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).

[xdrpx]

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.

[Sukrim]

What if a user doesn't have a mobile phone (e.g. on airports you often don't have a local SIM card) or the SMS service provider takes a few hours to send the message? The login details (why logging in anyways if you can already identify someone by MAC address?) are probably better displayed on the splash page or there is no need to "login" anyways as soon as the payment goes through.

[xdrpx]

What if a user doesn't have a mobile phone (e.g. on airports you often don't have a local SIM card) or the SMS service provider takes a few hours to send the message? The login details (why logging in anyways if you can already identify someone by MAC address?) are probably better displayed on the splash page or there is no need to "login" anyways as soon as the payment goes through.

Actually, that seems more appropriate. I was at an airport at my place and had an SMS sent, so probably thought the idea was applicable. It would be nice to autologin once the payment is completed, and probably have a timer that the user can see. You could have packages like for 1 hour of usage or 2 hours and different prices.

[ZenJB]

I would like have hotspot based on some popular WiFi router, like Linksys or Ubiquiti.
Person pay with BTC and get access to internet.

- Better if hotspot will be self sufficient. Some hardware, like Dlink DIR-320 has USB port. It can be used for USB flashdrive as storage of blocks.

- Better if it will have options, like counting traffic or time, several bandwidth throttling degrees, depending on price.

- Better if hotspot will have 2 SSIDs - one private and one public.

How do you think to start implementing this?

My bounty is small, but I think someone on this forum would need the same and also pay for developer.

There are some routers that lets you flash Custom Firmware and they might have an Open Source Custom Firmware that creates an Captive Portal (Thats what you're searching for).  To get the payments in Bitcoin you can use BlockChain API to receive payments on that captive portal system (it needs some changes to work with the API)

[evilimprint]

Why not just design a computer using pfsense. pfsense you can setup a computer as a router and get more range also with expand ability of adding a application to accept the bitcoin.

[Sukrim]

Pfsense is a FreeBSD distro, not some magic "hotspot enabler". The often mentioned OpenWRT distribution (Linux based) would be another option. Both of them already have basic captive portal software built in, still nobody bothered to create a proper Bitcoin plugin for them over the past few years.

The way how to do this is actually not very difficult or completely out of the box... it is just hard to monetize and unless you have a lot of people around that have BTC and would use them to pay for WLAN access, it would be very hard to profit from this at all (e.g. a hackerspace - but then again you'd likely offer free WLAN instead of charging money for something as basic as internet). This means you'd have to do this for the bounty here and personal interest. Apparently both are still not high enough to motivate people.

[evilimprint]

Pfsense is a FreeBSD distro, not some magic "hotspot enabler". The often mentioned OpenWRT distribution (Linux based) would be another option. Both of them already have basic captive portal software built in, still nobody bothered to create a proper Bitcoin plugin for them over the past few years.

The way how to do this is actually not very difficult or completely out of the box... it is just hard to monetize and unless you have a lot of people around that have BTC and would use them to pay for WLAN access, it would be very hard to profit from this at all (e.g. a hackerspace - but then again you'd likely offer free WLAN instead of charging money for something as basic as internet). This means you'd have to do this for the bounty here and personal interest. Apparently both are still not high enough to motivate people.

pfsense you can build into a hot spot easily all the options are there. I work with pfsense every day with my server farm.

[speaktome]

The peoples on here they are answering to an approach made on May 11, 2011. I wonder if the creator of this thread found the solution.

[aakashsangwan]

The peoples on here they are answering to an approach made on May 11, 2011. I wonder if the creator of this thread found the solution.

I dont think so that first of all he is following this thread which he created long back, if he would have not found the solution he would have been in details about it and would have reported or replied the messages.

[speaktome]

The peoples on here they are answering to an approach made on May 11, 2011. I wonder if the creator of this thread found the solution.

I dont think so that first of all he is following this thread which he created long back, if he would have not found the solution he would have been in details about it and would have reported or replied the messages.

True,

Besides he was providing that amount when the price was different for a solution.

[Evil-Knievel]

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.

So a couple points to be even more realistic here:

1. Why would anyone want a centralized single point of failure? The original idea of running the system on the router itself is more than fine, and gives the operator maximum flexibility.

2. Not sure why you would consider a router a "client side application", but regarding the bitcoin transactions I see absolutely no problem. Using simplified payment verification (via Electrum or obelisk servers) it's fairly easy to verify received payments. I would estimate the time to code this to 30-45 minutes. It's no horrible idea at all, Bitcoin was invented to avoid centralization ... using a centralized service is ironic.

3. If Linus Torvald had thought this way, we all would be still using Windoze  


Still not sure why you call it time consuming. I could do it in one 8 hour work day, I think.
Whats so hard to monitor bitcoin transactions and set individual routes for the connected clients (either a route to the internet or a route to the payment site) using a hand full of easy bash scripts that are triggered from either a countdown timer or a SPV client when certain transactions are seen?

[drewdtom]

Hey all,

My partners and I would like to give this project a go. Over the last few months we have been playing around with some code and looking at other attempts at this project. We currently have a working prototype for a raspberry pi 3.

We have seen the project that 21.co put out but the price point of a 21 computer makes the product a bit to pricey for most. Our software would run on any raspberry pi and would only need a wifi adapter for a pi 1 and 2 to work. (plus SD card, power adapter and network cable)

If anyone in here is still offering a bounty that would be cool, but I'm trying to fully understand what features make this a great product that you all would support. We will likely sell some prototype units to make back our time developing this product.

We also have an opportunity to demonstrate the product at an upcoming even in New Hampshire among bitcoin users. I'll be back to post an update on our prototype sale but please let me know what it is that would make this qualify for any bounty's or your support buying a prototype.

Thanks!

[Evil-Knievel]

Come on, this is pretty easy and does neither require much funding nor does it require much time.
The least it requires are "partners".

1. Set up regular public access point using open source tools (HostAP?)
2. Create a website that shows a BTC address that users have to pay. The address is deterministically generated from the connected MAC address in the same manner as a brain wallet is created, salted of course.
3. Create hook script to set the default gateway for each MAC address to the payment site (on connection)
4. Set up a SPV client monitoring payment addresses and set the default gateway to the REAL ONE for all mac addresses (i.e., the connected bitcoin addresses) that have been paid.
(Consider checking past payments for old payments if a client reconnects but still has some time left)

One day, max.

[drewdtom]

We have started a presale and crowd funding campaign for a new bitcoin product, The BEWP: Bitcoin Enabled WIFI Portal. BEWP is software configured as a router for Raspberry Pi 3 and other Linux based mini-computers to serve Wi-Fi through a bitcoin pay wall. Using popular bitcoin wallets, such as CoPay, consumers can use bitcoin to get past the Wi-Fi captive portal and establish an Internet connection.

The limited edition plug-and-play prototype is available through Purse.io as well as our Bitcoin Starter page where we offer a few price points to help support the project with a preorder of the final product or an early prototype to help us beta test the various features we have planned.

We just wrapped up deploying the BEWP at the 13th annual Porcupine Freedom festival and provide great WIFI coverage in the remote white mountains of New Hampshire.

Learn more at our Bitcoin Starter page or below is a link to an article just published by Bitcoin.com

https://bitcoinstarter.com/projects/bewp-bitcoin-enabled-wifi-portal/

https://news.bitcoin.com/meet-bewp-bitcoin-enabled-wifi/