Author Topic: mesh networking, last mile problem, and BTSX  (Read 20805 times)

0 Members and 1 Guest are viewing this topic.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
Why would it be horrible?  Your IP packets already take a bunch of jumps to get to you.  Adding another 5-10 jumps shouldn't be a huge issue, should it?

Maybe someone with more experience in this field can comment, but if you want to replace the last-mile connectivity, I don't think it is going to just be 10 additional hops. I doubt the latency would every be low enough for gaming, voip, and video chat. And the latency might be high enough that browsing the web recreationally would suck so much that you rather not bother. There is still a lot of use cases that would be great: blockchain transactions, text messaging, email, search results, staying up to date with the news (particularly if the device automatically pulls it from subscribed feeds in the background), downloading important software updates, batch downloads of content/media, and perhaps even streaming media if the mesh network can handle the bandwidth. In my view the mesh network technology is good to have to provide basic internet connectivity to people who cannot get it otherwise, so they can keep up to date with news, do business, and communicate with each other. I think the technology applied to WiFi sharing (with regular wired backend) is fantastic to reduce our dependence on the incumbent carriers and their cell networks. But this doesn't replace people's desire for high bandwidth, low latency fiber to the home.

It's not settled that legal liability would attach.  There have been some cases about people not securing their wifi connection in their homes, and outsiders using their wifi for evil purposes, and I don't think anyone has gotten in serious trouble for not securing their wifi.  It won't be target by government unless it is fairly popular, and once it is, there may be little they can do.  Your example of tor for instance is apt.  Tor is still going.

I am just saying this legal uncertainty can kill adoption. My example with Tor illustrates this. Very few people care about using the slow Tor network. If people are too scared to be exit nodes in this network because of the legal liability, the internet access in this mesh network is going to be very slow. It doesn't even matter if they win the court cases. The fact that they need to defend themselves in court already raises their costs which they need to pass on to mesh network users with higher fees. People won't bother with the expensive, slow mesh network when they can get a cheaper, faster cell network (not even mentioning wired connections).

Ideally, there would be either overwhelming court precedence or a group to lobby the government and pass laws that makes it clear to people that they won't get harassed for relaying information in a network. That way it ends people's hesitation in participating in this network. But I doubt the government is going to give up the harassment until they get some other way to get the information they want (someone to point a finger to as being guilty for either unauthorized access to computer systems, aka hacking, or publishing, whatever that means, information they deem inappropriate). The government's whole logic behind all of this is IMO so flawed to begin with (I don't want to get started with that), but it is the reality we live with currently.
« Last Edit: October 01, 2014, 02:01:50 am by arhag »

Offline fussyhands

  • Full Member
  • ***
  • Posts: 109
    • View Profile
Isn't the latency going to be horrible? Perhaps it would only be useful for asynchronous messaging and batch downloads, which I admit is still incredibly useful.

Why would it be horrible?  Your IP packets already take a bunch of jumps to get to you.  Adding another 5-10 jumps shouldn't be a huge issue, should it?

My biggest concern is liability. Are the end-point nodes going to have to deal with harassment by the government because some anonymous person used their internet connection to do illegal things. Take a look at the lack of Tor exit nodes. Sure, you can be financially compensated for your bandwidth, but that's not going to be enough to cover legal fees trying to prove to the government you weren't the one that initiated those "bad" packets.

It's not settled that legal liability would attach.  There have been some cases about people not securing their wifi connection in their homes, and outsiders using their wifi for evil purposes, and I don't think anyone has gotten in serious trouble for not securing their wifi.  It won't be targeted by government unless it is fairly popular, and once it is, there may be little the government can do.  Your example of tor for instance is apt.  Tor is still going.
« Last Edit: October 01, 2014, 12:28:50 pm by fussyhands »

Offline fussyhands

  • Full Member
  • ***
  • Posts: 109
    • View Profile
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.)
« Last Edit: October 01, 2014, 12:27:45 pm by fussyhands »

Offline fussyhands

  • Full Member
  • ***
  • Posts: 109
    • View Profile
Hmmm...  I remember that proposal for bitcoin a while back.  Serious impediment if you have to wait 10 minutes for the bond to confirm, but if it's only 10 seconds that is not as big a deal.

But, imagine that you had to wait 10 seconds every time you wanted to make a phone call from a new location... even to connect your laptop to wifi, a 10 second delay would be pretty annoying.

Anyway, I think it's possible to get the delay down to a few seconds, which is just on the edge of a delay that won't seriously turn people off.
Much like in bitcoin, the network sees unconfirmed transactions, can let you in directly and cut the connection after 30 secs if the transactions does not get included into a block by delegates

huh?  we're talking about side channels...

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
Isn't the latency going to be horrible? Perhaps it would only be useful for asynchronous messaging and batch downloads, which I admit is still incredibly useful. Also, there is no reason the blockchain settlement and micropayment channel functionality cannot be used for regular WiFi sharing (where the backend is still a typical wired connection and not a mesh network). Users could probably get much better data payment rates than those horrible phone carriers.

My biggest concern is liability. Are the end-point nodes going to have to deal with harassment by the government because some anonymous person used their internet connection to do illegal things. Take a look at the lack of Tor exit nodes. Sure, you can be financially compensated for your bandwidth, but that's not going to be enough to cover legal fees trying to prove to the government you weren't the one that initiated those "bad" packets.

As much as I hate it to conform to the government's nonsense that information can be evil, it may be necessary to build that into the protocol in order to grow adoption. I imagine it would be similar in principle to the cryptostock KYC design that BitShares is planning. You have a pseudonymous account which is flagged on the blockchain by a trusted identity verifier to meet KYC requirements. A (layer 5?) networking protocol would be necessary for the packets to include a signature by the pseudonymous account authorizing the (end-to-end encrypted) content sent via the packets. The nodes relaying these packets would need to inspect them to make sure they meet that protocol and of course that the pseudonymous account signing them is the one on the blockchain that meets the KYC requirements from a whitelisted identity verifier. If the authorities have a legitimate (warrant please) request to determine the identity of the person behind those packets (because they determined that session was used to connect to some server and do illegal things), they can leave the nodes alone and go straight to the identity verifier with their warrant. The good news is that the nodes participating in the network get to determine the whitelist. The riskier ones include identity verifiers who have a reputation of standing up to governments and defending privacy (imagine an EFF or ACLU identity verifier). If enough nodes do this, a user could use a pseudonymous account that was verified only with the privacy-respecting identity verifier and still hopefully get a decent internet connection.

Actually, better yet, maybe just the end-point servers would have the responsibility of checking the pseudonymous signature. That way the signature can be hidden inside the end-to-end encryption and everyone inspecting the network wouldn't be able to over time link together a particular user's server connection habits. Also, the computational demand for each of the relay nodes is reduced. That would be the more sensible way to handle it. But it means that the authorities need to not hold relay/exit nodes liable; instead they would require the end-point servers to be responsible for checking that the pseudonymous signature meets KYC requirements before accepting their connection, otherwise the company/individual running the server would be liable for what the user does via that server. Servers can then publicly publish their identity verifier whitelist, and users can know which identity verifier they need to trust with their privacy in order to access that server (and whether it is even worth it).






Offline JoeyD

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?

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Hmmm...  I remember that proposal for bitcoin a while back.  Serious impediment if you have to wait 10 minutes for the bond to confirm, but if it's only 10 seconds that is not as big a deal.

But, imagine that you had to wait 10 seconds every time you wanted to make a phone call from a new location... even to connect your laptop to wifi, a 10 second delay would be pretty annoying.

Anyway, I think it's possible to get the delay down to a few seconds, which is just on the edge of a delay that won't seriously turn people off.
Much like in bitcoin, the network sees unconfirmed transactions, can let you in directly and cut the connection after 30 secs if the transactions does not get included into a block by delegates

Offline fussyhands

  • Full Member
  • ***
  • Posts: 109
    • View Profile
Isnt another big problem with incentivizing mesh networks and internet sharing is that users at the end of the mesh chain dont have any BitUSD/crypto to send to the other nodes?

Why is that an issue?  Can't they just buy some?

Offline fussyhands

  • Full Member
  • ***
  • Posts: 109
    • View Profile
Even if it is necessary to pay per byte, a payment channel will be the most efficient way to handle microtransactions between meshnet nodes. So it could even be implemented with BTC's slow transaction times.

I don't think it will ever be possible to have "true" microtransactions (i.e. arbitrarily small stand alone payments) in a decentralized fashion in any cryptocurrency, because there will always be a flat price for distributing information to a network.

I disagree.  On BTC it takes 10 minutes to establish a payment channel (which I think is the same thing as a bond that Bytemaster suggested).  Imagine having to wait 10 minutes to connect your laptop to wifi, or to make a phone call.

Offline fussyhands

  • Full Member
  • ***
  • Posts: 109
    • View Profile
Identity is easily managed by having a bond posted in the blockchain that is forfeit if the node doesn't make good.  The two parties can then exchange receipts as quickly as they like and then claim it at the end of the day. 

There is a point where it is cheaper to extend a free sample than attempt to collect payment for it.

Hmmm...  I remember that proposal for bitcoin a while back.  Serious impediment if you have to wait 10 minutes for the bond to confirm, but if it's only 10 seconds that is not as big a deal.

But, imagine that you had to wait 10 seconds every time you wanted to make a phone call from a new location... even to connect your laptop to wifi, a 10 second delay would be pretty annoying.

Anyway, I think it's possible to get the delay down to a few seconds, which is just on the edge of a delay that won't seriously turn people off.

Offline speedy

  • Hero Member
  • *****
  • Posts: 1160
    • View Profile
  • BitShares: speedy
Isnt another big problem with incentivizing mesh networks and internet sharing is that users at the end of the mesh chain dont have any BitUSD/crypto to send to the other nodes?


Offline amencon

  • Sr. Member
  • ****
  • Posts: 227
    • View Profile
This wouldn't be a DAC... it would be a standardized protocol that utilizes BTSX.  The routers would be "vending machines" not part of a DAC.
Hmm I went back and re-read the OP more closely and see what you mean.  So each node utilizing the yet to be built protocol would use it to communicate with the BitsharesX DAC and register on the chain to move value between other nodes which do the same?

I suppose it would be an even better situation since BTSX has value outside of micro-payments to mesh networking nodes and wouldn't rely on mesh networks to thrive before being a viable way to exchange value for connection services.

Offline Rune

  • Hero Member
  • *****
  • Posts: 1120
    • View Profile
Even if it is necessary to pay per byte, a payment channel will be the most efficient way to handle microtransactions between meshnet nodes. So it could even be implemented with BTC's slow transaction times.

I don't think it will ever be possible to have "true" microtransactions (i.e. arbitrarily small stand alone payments) in a decentralized fashion in any cryptocurrency, because there will always be a flat price for distributing information to a network.

Offline mbaeichapareiko

  • Full Member
  • ***
  • Posts: 59
    • View Profile
wow,  the possibilities seem endless.  Great application and proposed real world problem/ solution demonstrated here.  digital currencies, and hopefully BTSX is able help make it happen.