@femmesh My focus has also shifted to how to incent gateway nodes to relay between the low bandwidth radio based mesh network and the global internet, or regional mobile network (ie. SMS).
Even if nodes in the radio based mesh have to spend power to re-transmit, the gateways have a much higher actual cost. Motivating gateways must necessarily happen first because, as your friend pointed out, you need to be able to settle on the main chain for any value to change hands.
Rifting on what @Turnerb says here, I would narrow it down further to say we need to create an incentive to relay messages to/from the global internet and ultimately to/from a blockchain that acts as the ultimate ledger to record value transfers.
Once we have a solution to the gateway problem, it will be possible to think about non-gateway nodes. Gateways could also provide SMS or IM relay capabilities which increase the value of participating in the mesh network in general.
Once you have a mechanism to transfer value, you can decide how to use it.
@Turnerb It’s not blocked for me here in NYC, just FYI. Either way doesn’t look like the whitepaper is available yet until Sept/Oct. Someone forwarded this abstract they got from RightMesh though:
“This document describes a method and technology for connecting users in an ad hoc wireless mesh network, and in so doing, creating new connectivity options and improved outcomes to billions of unconnected users around the world.
Core to the network is an Ethereum ID and digital wallet that provides identity to every mesh node. In a mesh world, when linking multiple hotspots and networks together, traditional identity methods (IP addresses) will not work adequately. The Network’s approach to mesh participation and activation solves this problem. We believe when you combine blockchain-based technologies with wireless mesh networks, you unleash the potential of both technologies and make a lasting difference on the world around you.
We call this RightMesh™.
With RightMesh, the devices people already carry around every day form the infrastructure. This is a software-based solution that will achieve distributed decentralization that will only continue to strengthen with network density. The key principle is that the RightMesh network is self-forming, self-healing, and self-regulating, using whatever it has at its disposal. It runs on devices most of the world already uses and can easily afford. No additional hardware or infrastructure is required, and no longer will people be beholden to ISPs.
As both a platform and a network, RightMesh enables developers to retrofit existing applications or build new, mesh-enabled decentralized applications (DAPPs). RightMesh also intends to introduce a RightMesh token, or MESH, that participants in the ecosystem will use to facilitate the purchase and sale of goods and services.
One example of such a transaction would be an application that empowers a RightMesh user to sell excess Internet capacity, giving those who do not have access the ability to connect to other meshes or consume general Internet traffic. There will soon be more than 6 billion smartphones on the planet and 20 billion IoT devices, a lot of which will have underutilized connectivity, storage, and processing capabilities. This is the sharing economy, and just as companies have shared their homes (Airbnb) and automobiles (Uber and Lyft), RightMesh will empower users to take control of their device and extract its intrinsic, already-invested value.
Another example might be a user who creates a digital good (i.e., music, video, apps, magic swords, or photos) and transmits this to another user for an exchange of MESH tokens. We live in a world that is becoming increasingly digitized, and thus, the concept of work and value creation has changed. A user with a connected smartphone can transact and produce value that is useful to a person or machine on the other side of the planet.
RightMesh believes that this ecosystem will create a new generation of digital entrepreneurs, while helping emerging economies access content and information that improves their life outcomes.”
Doesn’t seem like we’ll know much about how good or bad (or applicable) their suggested implementation is until they release the full paper but it does appear that their proposed token will be limited to their protocol which I think is not that exciting. I go back to my earlier comment that I think we need to build a nonproprietary blockchain layer that can help any/all mesh networks scale.
In any case, my sense is a LOT of other whitepapers around mesh blockchain projects will be coming out sooner or later… only because (finally) mesh networks are so of the zeitgeist. The question is who will do it well — and credibly (as one advisor recently put it to me).
Here’s a simple game theory puzzle way to describe the problem @Turnerb is pondering : every node starts with a counter with ‘m’ counts on it. When a node transmits a message they can decremented the counter by ‘n’ units and tell people how much they decremented it by. Nodes that broadcast a messages may increment their counter by 1 if the message was created by a node that decremented their counter by at least 1 count. Messages have a remaining count of ‘n-1’ if broadcast again.
Problems:
Replace ‘counter’ with ‘account’ and replace ‘count’ with ‘dollar’ and replace ‘broadcast’ with ‘pay for’. Now we have the problem that blockchains solve.
Nodes need to pick a pathway of nodes to pay for rebroadcasting their messages. Or perhaps they always pick a nearby node with the shortest payment pathway. Or maybe the one in the right direction. Maybe the message includes a bonus for delivery to the final destination. We can validate local broadcasts because we also hear it. If we pay and they don’t transmit, they can go on a blacklist. It’s harder to know if our final destination received it unless someone received the bonus payment from the recipient for delivering it.
That all said, maybe people will broadcast messages for free so this is all moot. I’d like to incent gateways first so that this is even possible.
Full nodes on the bitcoin network do not receive any compensation for rebroadcasting transactions or for supporting the network in general. They do however keep a blacklist of misbehaving nodes. If enough mesh network nodes take this attitude, then there’s little reason to be more complicated about it.
Miners, on the other hand, are compensated. But they must prove they’ve done real work to get paid.
The analogy then is that mesh relay nodes are like bitcoin full nodes and mesh gateway nodes are like bitcoin mining nodes.
PS> Anyone that can solve the problems to my toy game theory puzzle without a proof-of-work blockchain should write up their whitepaper and launch their ICO ASAP. 
@rmyers A blockchain developer I recently met seems to think this may be a good area to focus on as well.
Here’s one more paper to add to the reading list: “Flare: An Approach to Routing in Lightning Network” . Here’s the overview article on medium.
@rmyers Tell me if this is what you’re saying, but are you suggesting that we perhaps focus on creating a blockchain protocol that focuses only on stationary and/or back-hauled nodes? In other words, leave the mobile, off-grid nodes out of (or mostly out of) the blockchain topology? If so, this is actually something I was considering last night when I was battling some surprise insomnia.
If you meant something else, would love to hear about it. And if I’m reading your post correctly, I’m keen to hear what you think the advantages of doing this would be. I presume lightweight is one potential consequence, as is focusing on network activity that is much easier to validate. And in terms of the mobile off-grid nodes, what role exactly might they play (or not play), in your view?
Can I ask a (maybe) dumb question? Based on @danielagotenna’s Blockstack talk the point is to create an open source protocol layer that can help all mesh networks scale, not just goTenna’s. But since mesh networks have such different properties - operate on different spectrum, on different hardware, used for different applications (eg IoT or wifi or UHF) - how will one blockchain protocol help all of them scale or manage other problems/questions?
Such a great discussion here 
Finally getting caught up from being out of town for a while.
I think some basic things should be considered when considering any blockchain application as incentive to providing/utilizing a mesh network based on goTennas. Some of these seem to have already been mentioned but I want to highlight each of these specifically for consideration by the group.
Separate blockchain or tied to an existing blockchain (bitcoin, ethereum, etc.)
Consider the answer to this carefully as each option carries further considerations. If tied to an existing blockchain, then the network must have bridges to the Internet in order to function properly (see next item below). If not tied to an existing blockchain, there isn’t an inherent need for Internet connectivity but now mining must occur within the mesh network itself to validate transactions and add blocks to the chain.
Internet gateways as part of the mesh?
This relates to number 1 but also carries some additional things to consider. Namely that if the expectation of this mesh network is that it provides Internet connectivity, then users will expect to access bandwidth intensive services just like any other Internet connection. In the case of goTennas, the resources are quite limited so usage of bandwidth intensive resources on the Internet by users of the mesh network should be disincentivized accordingly to discourage choking off all available bandwidth. It also becomes necessary to incentivize Internet gateway nodes to increase available connectivity and bandwidth to the mesh network. Further, steps should be considered regarding legal liability for those providing gateways to the Internet in the case of fraud or other activities by those on the mesh network.
How to identify endpoints participating in the network?
MAC addresses can be easily spoofed or altered but would they be sufficient as identifiers for this or should some other identifier be provided to prevent spoofing or stealing someone else’s network credit. The answer here may be dependent on what the final solution looks like. My thinking around this may include some kind of embedded signature every X packets or something like that or some signature present in a header field. Signatures imply cryptographic resources though and that may be too much to ask for this solution due to limited resources. It may be too early to ask this question until answers to other fundamental questions are answered.
Ultimately the answers to the first two questions help answer other things like - what behaviors will exist on this network? And which of those behaviors will be detrimental to network performance, stability, etc.? Which behaviors will automatically be disincentivized/incentivized simply due to the nature of the network? And which behaviors should be artificially incentivized to encourage those behaviors?
All of that should help a solution start to take shape IMO.
[ Sorry these thoughts aren’t too well organized, but I wanted to give you my stream of consciousness response anyway since I’ve been too busy this weekend revise it.]
Yes, that’s exactly what I’m thinking now too.
Phase1: Enable mobile off-grid mobile nodes to pay the edge nodes to act as gateways to the internet or mobile network.
Phase 2: Enable off-grid mobile nodes to pay off-grid fixed nodes to support longer distance mesh circuits
Phase 3: Enable off-grid mobile nodes to pay each other to support good mesh behavior generally
All nodes could operate with out incentives, but if the goal is incentives then we should start with the long pole in the tent, which are the gateways. Without gateways you won’t have access to a global value transfer system. Alternative approaches without gateways could be imagined that operate without reference to a global value transfer system, but that’s a different discussion.
Advantages for this approach:
Mobile off-grid mesh nodes are the source of the incentives that encourage gateways and fixed nodes to operate. The value of participating as a mobile off-grid mesh node increases if gateways and fixed nodes exist because now there’s a way to relay data to/from more mesh nodes and with the on-grid world (global communication and value transfer).
Both off-grid and on-grid node are part of the blockchain topology, but I am assuming that gateways can easily form payment pathways between each other. This means that as long as a mobile off-grid node has established a payment pathway with one gateway, these gateways can route through each other and so the mobile off-grid node can also use any gateway they happen to be near.
Creating a payment pathway involving fixed nodes, or between fixed nodes and gateways, will also be easier since they won’t move around and are likely to be more dependably online.
Mobile off-grid node are unlikely to have a payment pathway with any particular other mobile off-grid node they encounter, and the protocol for establishing such a pathway may cost more than it’s worth if all you want to do is encourage them to re-transmit your message. Some sort of simple expiring whitelist / blacklist system might be sufficient in those situations.
I’m afraid my focus is more on the blockchain aspect than the mesh so please let me know if you’d like me to consider any particular mesh situations more deeply.
A scenario might look like like this:
You want to send a message back home while hiking overseas. Roaming is expensive and/or unreliable, but a mesh path can be found. Your phone negotiates paying a fixed off-grid node to connect you to a local gateway which relays using Whatsapp via the internet to your recipient. Payments for the foreign gateway and relay are automatically taken from the balance you keep with your local gateway back home.
The same way you pay the fixed off-grid relay could also be used to pay for lunch from a local off-grid street vendor via their off-grid mobile phone. The vendor could use their blockchain based payments to buy supplies from the city with out needing a bank account.
If you guys were to create a version of goTenna Mesh that had a recessed port that accepted an OpenDime stick AND could access the web via WiFi then that one unit could on ramp a group of people in proximity to validate and transact viw their OpenDimes being read by their own goTenna Mesh.
It would be really interesting to be able to simply validate the amount of an OpenDime via Short Wave Radio “numbers station” on a goTenna Mesh that could tune in to those frequencies.
I agree the choice of blockchain is one of the most important decision, and so the best answer is always going to be that the technology stack can plug into any/several blockchains. I would also like to suggest that the best blockchain is going to be one that uses POS (Proof Of Stake) instead of POW (Proof Of Work). The energy consumption and wasted computing power needed for POW is simply too much for something like goTenna. I dont believe there is a workable POS blockchain out there currently, but Ethereum will most likely get there within 2 years.
@Nunya_Bidness: What is OpenDime exactly and what can it do that nothing else can (currently or in the future)? Is there some IP thing they have?
Also all @here: still open to hearing about my earlier question:
@rmyers I’ve been offline for most of this past week as I’m on vacation, but I just read this. Thank you, this confirms some of my thinking recently and puts more heft around the “gut feeling” around this.
Around this in particular when I’m back in NYC mid-next week our new Chief Scientist will begin and I am sure we will run through several scenarios that integrate coordination considerations and scarcity issues in mesh MANETs (mobile ad-hoc networks) more deeply and will be back with more questions/ideas/scenarios for you and the other blockchain gurus here can help us consider.
@femmesh I think this is an open (and good) question. As you’ve inferred, some mesh systems are completely stationary, others completely mobile. Some are high-bandwidth, others are focused on more bursty data. There’s probably a way to address diametrically opposed mesh systems by focusing on the commonalities between all the disparate ones … I’m very excited to have our new Chief Scientist start officially (today is his first day!) to help us game through so many of these scenarios.
P.S. On that note, would love to hear others’ thoughts. Perhaps @legion @mivyx @rmyers @Jessica @femmesh and others have ideas on this question already?
I have a few generic thoughts on the mesh/blockchain question - these are all just my opinion.
I think the blockchain layer should be embedded in the mesh protocol used and simply be part of standard communications.
I also think the mesh network itself should be designed to operate very efficiently regardless of how the physical network is made up (many mobile nodes vs. many stationary nodes).
What I’m struggling with is the need for connectivity to the Internet. Ideally (in my mind anyway), there could be a mesh network that operates just fine outside of the Internet (perhaps Internet comms are disrupted or not available - then what? I would hope something like this would be around to provide emergency communications). This poses some challenges though… how are payment transactions to purchase network usage handled? In person? That could work actually. Then it doesn’t matter what sorts of payment are negotiated between the parties (cash, bartered services, other goods, etc.). Mining could also be a solution for getting some “fuel” to use the network. What about wallets? Maybe baked into new versions of devices? And it sort of lends itself to keeping a separate, in-network blockchain with all its necessary mining etc. I think it’s all doable but comes with some challenges that will need to be overcome. For instance, how are transactions broadcast across the mesh network such that there is one, heterogenous blockchain on the network in a way that doesn’t choke off available network resources? Or should there even be one heterogenous blockchain? Maybe many smaller ones agreed upon by local nodes in the area?
Maybe some scenario like this would be the result: I need to send some messages over the network so I fire up my mesh device and it finds a node to connect to. The node signals that it has tokens available for purchase along with its location. I go to the location and pay for some tokens and send my messages leaving some tokens available for later use. I leave my laptop running for a while to mine and collect some more tokens to offer to others before shutting down and moving on. I leave my mesh device running to let any others know that I have tokens available should they need them and it periodically broadcasts my location so they can find me.
Is that type of scenario what we’re after? Or something different? Should the network also provide incentives to bridge into the Internet (referencing @rmyers excellent post on this topic)? Should it be a bit of a hybrid solution that can operate on its own but also provide bridges to the Internet?
Lots to consider… Love to hear other’s thoughts on this.
@mivyx brings up an excellent question. What about scenarios where settlement to a global store of value is not required or impractical?
Taking the emergency communications scenario, I can imagine nodes falling into three categories: altruistic, business as usual and opportunistic. Nodes that re-broadcast, relay or provide gateways are altruistic if they perform these services without charging and already exist in the area of the emergency or come to help. These nodes don’t need the internet because even if they once charged, now they won’t because of the emergency.
Some nodes that exist in the emergency area may decide to continue to charge as usual, perhaps as a way to prioritize traffic. Charging also provides an incentive for them to rapidly reestablish their node and keep well known circuits available. If gateways are unavailable, they can continue to accept updates to existing payment channels but they won’t be able to monitor if these channels are closed prematurely or verify anchor transactions for any new channels they create. They would have to accept these transactions on faith until gateways are reestablished. Accepting transactions on faith is no worse than operating altruistically, and once gateways are available it is likely most transactions would be valid.
Opportunistic nodes, perhaps from nearby locations, might enter an emergency zone fast and run purely to profit from the need for emergency communication. With a mobile battery powered satellite uplink/downlink system they could provide limited bandwidth gateways anywhere, but at a much higher cost per byte of traffic than most pre-emergency nodes would pay. Perhaps governments or NGOs (or direct donations) could subsidize traffic on opportunistic nodes until altruistic nodes were established. The permissionless nature of the technology and opportunity to earn real world value can create a situation that harnesses local creativity to rapidly provide communication infrastructure where it’s needed. Even a ‘sneaker net’ that relays traffic by foot could prove invaluable in some situations and yield real world value to the entrepreneur who provides it.
I love the idea of a mesh only currency. It would simplify many problems. But my gut feeling is it’s just not algorithmically possible. @mivyx brings up some good practical problems already. Even if you could come up with a way to do an equivalent of proof-of-work mining on adhoc radio nodes (a big if), then you still have the problem of chain forks. Two disconnected networks of nodes might build two incompatible chains of blocks. Which is the authoritative one? what happens when the disconnected networks reconnect. A node that can see both networks might have an incentive to spend the same mined value on both networks rather than bridge the two networks. I feel like any mesh-only currency would have little value unless it was anchored by a global value blockchain. I tend to favor a simple system of white/black lists as a way to handle mesh only (no gateway) networks situations.
Musings on white/black lists, I can imagine a simple ‘proof of delivery’ based system where you get a delivery-receipt message back cryptographically signed by the node you sent a message to and put nodes involved in the delivery circuit on your white list. You preferentially rebroadcast traffic for nodes on your whitelist.
You know which of your local nodes rebroadcast your message (because you hear it), the receiver of your message can also know and tell you who they received it from. So you can add two nodes to your whitelist with confidence. Any other nodes in between who also put their name on the delivery-receipt and claim credit for participating in the circuit must be taken on faith. Only the nodes who communicated with them directly know if they were part of the circuit or just added by one of the real nodes in the circuit. If you hear a rebroadcast of a delivery-receipt that includes obviously fraudulent additional nodes, that rebroadcasting nodes can go on your black list, but it’s hard to correct the record for the node that receives the delivery-receipt.
Keeping a whitelist of your local nodes who you hear rebroadcasting for you is probably the best we can do trust wise for most situations. I’m still curious to hear how people think a mesh blockchain (used only internally for the mesh-network) can provide an incentive for nodes to rebroadcast for other nodes better than a whitelist.
Hi all, I’ve been on vacation so was trying to disconnect a little bit. Just got back to New York. Tomorrow some members of our team, along with a few advisors, are spending the day brainstorming and discussing blockchain integrations. This will be the first time a lot of us will be in the same room talking about this at once so I’m really excited to report back on how that all goes! Needless to say, a lot of the fodder from this thread will be core to some of what we discuss tomorrow.
In meantime, I asked the 8 people who will be part of this working session to answer the following questions, if any of you are interested in answering them as well I will take them to the group throughout the day tomorrow:
1.Most Important-Incentivization. I think that if this works well, then everything else should be pretty easy. The technology can be chosen/built around how this works.
2.A lot of the mesh networking stuff I don’t get because I’ve never done stuff with it, so like proof of delivery and stuff I have no idea how it would work, but hey learning is cool.
3.Some more fleshed out ideas with the thoughts that were already thrown out in this thread. And candy.
Looking forward to hear how the brainstorming session goes!
What node behavior is most critical to grow and maintain a healthy mesh network?
How do you quantify the costs incurred by mesh nodes to perform different tasks?
For example, what percent of battery life, radio bandwidth and gateway network fees does it cost per hop for different tasks? Some tasks are: rebroadcast a message, establish a communication circuit, establish a payment circuit, send a message to a specific node, send a payment to a specific node, receive proof of delivery, receive proof of payment.
A framework for evaluating blockchain integration proposals for specific high value use cases based on assumptions for the cost and reliability of different tasks.
For example, given a particular blockchain integration proposal and assumptions about battery usage, bandwidth, gateway fees and node reliability, what is the total cost for all nodes involved to find a path to a node {1,2,3} hops away? to send a message along a path {1,2,3} hops away? to send a message via a SMS gateway? to send a payment to a node {1,2,3} hops away? what is the total cost for the nodes involved relative to the cost for the initiating node?
Some factors in creating an evaluation framework: How are cost and reliability assumptions different in different countries? How are assumptions different for fixed nodes vs. mobile nodes? when is the cost to make an incentive payment greater than the costs for the communication required for the payment? how does cost and reliability change when malicious nodes do not follow the protocol?