46
General Discussion / Re: mesh networking, last mile problem, and BTSX
« on: October 01, 2014, 01:05:37 am »Yeah I'd love to see distributed internet and maybe some people here can figure out a model that could align the incentives just right to make it feasible. But you'll be up against some big aggressive players.
I was following the OLPC-project very closely and liked their solution, unfortunately, because that project did not run a certain operating system and did not need a certain manufacturers expensive cpu, a lot of time and effort went into diversion tactics in the shape of netbooks and forcing said bloated os on a system it was not suited for. The meshnetworking or any other concepts were not integrated into the netbooks and the bloated os helped kill the project. The diversion was a succes and besides making some ripples in the industry, real disruption had been halted. But who cares, why would anyone want a screen you could use in direct sunlight anyways?
Anyways I'm a big fan of the concept of mesh-networks and I've been trying to think up ways and combinations with cryptocurrencies that would make it feasible. This looked promising but I have not seen an update or sign of life from them for close to a year now. My current line of thought is that there might be a way to get several services to essentially piggy back ride on each other and with their combined utility value be able to foster and sustain a mesh network.
As for blocktimes, I agree with bytemaster that that is not a concern at all. You only need to transmit a valid signed message, the message itself does not to be confirmed several blocks deep. Even with bitcoin that is actually not a requirement. If you can do a quick check if the paying account has the funds and if you can be certain that enough nodes have seen the payment, then why would you need to wait for the transaction to be confirmed several blocks deep?
I didn't say anything about several blocks deep. I said 10 minutes, which in Bitcoin would be one block (on average). Why wait for a confirmation before giving away resources to an anonymous buyer? Simple: you don't want to be cheated. This is a big problem with 10 minute block confirmation. For instance, someone could place a 10 minute phone call through your mesh node, or get 10 minutes of web browsing and then not pay.
Remember also that in a mesh network the node providing the connectivity to the phone/tablet/computer, is paying another node for that bandwidth (and that node is paying another node, etc.). So it's not like someone came by and used some of your unlimited comcast bandwidth. You actually lose money because you have to payout to the upstream nodes.
Even with BTSX's 10 second confirmation times and a bond posting scheme it's still a problem. If you let people start using the internet before their bond is confirmed they can potentially get a few seconds of connectivity without paying for it. Not a big deal if you only get a few seconds, but if they didn't post the bond then they can just keep doing it over and over to leach free bandwidth. People could write cheating apps for smartphones that allowed you to send free text messages, synchronize email for free, etc. in 10 second increments without paying. Ideally to avoid cheating applications like that, you could get the confirmation times down to just a couple of seconds.
For instance, here is one way to get confirmation times down to a few seconds: Even if the transaction is not officially confirmed, if you can monitor the network for double spend attempts, and if after a few seconds there are none, then you know that your transaction has propagated to most of the network before a double spend and is thus at low risk of a double spend attack if delegates include the first spend they receive (and there are other things you can do to make the risk lower by tweaking how delegates choose which transaction to include in the case of double spend transactions). In this scenario, even if you let people connect instantly you would only lose a few seconds of bandwidth. Furthermore, a few seconds is short enough that you could let their upload data (e.g. http request) through instantly and hold on to their download data until after the seconds had elapsed, and it would still feel pretty seamless. (This would eliminate the incentive to cheat because the user couldn't get any return data from their request until after payment clears, while making the latency involved with paying for the connection appear lower because the return data is all queued up at the last hop and sent through as soon as payment clear.)