goTenna Mesh and Blockchain: Potential Applications and Integrations


#41

I looked into the new filecoin whitepaper a bit more after a conversation with an advisor this morning and I admit it’s not all in “my language” so to speak but here are some main takeaways for me:

  • If you send me file and you say please store it for me, I could say I stored it and take your filecoin even if I’ve not not stored it (or: say I stored 5 copies even if I only stored 1), but…
  • The Protocol Labs team nevertheless figured out a way cryptographically to make sure that can’t happen!

Relatedly, it may also be entirely possible to do a mesh token without knowing GPS locations… I know I’m the one who brought it up here (in part because we’ve been discussing the question internally at goTenna) but I’m starting to think the first question we need to ask on this particular topic is not how do we prevent people from spoofing GPS locations and instead should be something like:

Do we want to incentivize connectivity in specific places or will connectivity organically emerge where it’s needed (which, by the way, may not be where we think it’s needed)?


Anyway, keen to hear what the rest of you think — I’m still a relative n00b to all this and like learning from you all! :slight_smile:


#42

I think that connections will organically emerge as long as there’s an easy way for people to see where the nodes are. People will be like, hey, there’s no nodes in between City A and City B, I should put one there and see what happens.

Maybe there could be some color coding or something on the map that’s shows slow areas and people will gravitate to setting them up there to make more money or for fun.


#43

I agree with @Legion in that connections will most likely emerge organically. Especially at events like Burning Man and large concerts or things that don’t happen in the same place or need to be there year round.

This does lead me to another question I was wondering about…

Lets say you have a node in a remote area that is serving as a mesh connection between two busy nodes (cities). If that node is handling a lot of traffic, does simply adding another node actually make any difference because you are still dealing with limited radio spectrum? Would’nt it just make more sense to increase the limits on stationary nodes that are plugged in to increase their throughput without adding an additional unit (I realize that would affect the amount of money you bring in but you could offset that with a higher price for the special node).


#44

How many msgs will saturate a relay node [messages per second] does the relay refuse msgs until it can process the ones it has? When its memory is full ie waiting to hand off msgs I assume it refuses msgs. In a busy area, the more active relays the more msgs can be handled.


#45

Can someone tell me why https://plasma.io is any different from the https://lightning.network/ except former is for Ethereum and latter is for Bitcoin?


#46

Probably not, but…

The main difference that I see is that the lightning network seems to be all about transaction speed when transferring currency from one wallet to another but plasma.io has some component that deals with data as well…

We propose a method for decentralized autonomous applications to scale to process not only financial activity, but also construct economic incentives for globally persistent data services, which may produce an alternative to centralized server farms.

I am thinking that all the alternative chains that plasma.io enables can be used to store large amounts of persistent data that would clog up the root ethereum chain if they did not exist.


#47

@kb1eea I just checked in with our product team to make sure I got this right — here’s the answer for goTenna Mesh specifically:

The scenario where the number of messages saturate a goTenna Mesh device (whether relay or mobile node) is highly unlikely. Mesh devices have enough memory to store and process 100’s and 100’s of messages.

That being said, 100’s of messages in the same area of influence at once will affect latency. When a lot of Mesh nodes are transmitting at the same time, network features we’ve built into our Aspen Grove mesh protocol prevent collision. Things like delayed send, random back-offs, listen-before-talk, message retry, etc. kick in, adding seconds to latency. In a quiet RF environment, transmission is otherwise pretty instant. Because goTenna Mesh is focused on short-burst, asynchronous data comms, however, even if the worst-case, latency will be as high as 38 seconds per the current protocol design. That’s really not so bad given it’s still gonna get through. :slight_smile:

And of course when our new Chief Scientist (a.k.a. network architect) begins later this month, we’re going to keep improving the protocol with more smarts to address coordination and other scarcities inherent in any mesh network.


#48

Hey guys, Blockstack just posted the talk I gave on July 27th at their Blockstack Summit on YouTube:


#49

I agree with @Legion as well here. I think organically is the most likely.

Based on the conversation so far, the theoretical gotenna token could be used for a couple of purposes:

  1. To incentivize people using Mesh’s wherever they are, which in turn, improves the availability, the density, and the reach of the network.
  2. If using the network requires tokens, then it automatically works to disincentivize certain behaviors that are harmful to the health of the network such as a single user chewing up lots of bandwidth. This could have the effect of discouraging certain types of denial-of-service attacks (though, not all of them).

Keeping the incentive to just making your Mesh available is probably the best way to go. If you have one, might as well turn it on and plug it in. You can collect some tokens for doing nothing but providing power. You won’t collect many tokens if you’re in a remote area - but you also won’t be competing with others for the tokens that are available. So by doing this, there is inherently incentive to go and provide connectivity in an area where there are more users or areas where there aren’t many Mesh’s to compete with. Users looking to get some tokens will automatically troll maps, develop their own formulas for finding the best areas to go and “hunt” tokens.

The drawback, of course, is that now you have a network that requires purchasing some tokens in order to use. Which, while addresses a couple of challenges, introduces one that seems to go against the purpose of the product in some ways. The converse argument is that without some kind of incentive, there may not be much of a network to use. I think blockchain provides a potential solution.

Good talk by the way, @danielagotenna . Hopefully that got you some additional contacts in the Blockchain community. Interesting discussion on this so far. I think an ethereum-based coin based on a smart contract may hold promise for this.

-Travis


#50

One more thought… the cost in tokens can very depending on things like congestion etc. So if it’s a busy time in a congested area, there is a higher cost in tokens for using the network and a higher benefit for adding your Mesh to the network in that area. If there is no congestion… and you are the only client seeking access, then it’s cheap to use the network.

If all of that ^^^^ can be accomplished in a way that makes sense.


#51

Food for thought… I’m sure there are Waze users here, right? Popular app for navigation for both iOS and android. The app is not only a navigation app but what makes the app so popular both in the states and outside the country is that users get to provide real time input. Other waze users driving see real time pop ups on there map to alert of traffic ahead, accident, weather etc. The app allows users to give a “thanks” back to the driver who reported the incident originally. The feedback is then passed back to the individual. In addition users are encouraged to report and drive distances looking for hidden gems etc as they drive to there destination. Users are rewarded by a point system using the app and interacting. It’s like bragging rights in the waze community. The more you use the app and interact, your waze decal changes to show others on a leaderboard that you are king of the road for the week, month, year etc. sorry to simplify this but it’s just an idea to keep it simple.


#52

A distributed micropayment market via the Lightning Network to pay for the relay of packets is the most obvious answer to many of @danielagotenna questions.

In this kind of system, each relay is a Lightning node and receives a micro fee for acting as a relay. Each node can negotiate what fee they’ll take or relay for free based on a whitelist.

Such a mesh would be valuable to relay transactions and block headers which are both in the 256 byte range. Such a mesh would be complimentary to using a satellite for full block data (see blockstream) downloads.

Having connectivity to both a local mesh and sat channels would provide redundancy against failure or censorship of the current centralized infrastructure. It could also enable off grid use of bitcoin.

Some thoughts on Daniela’s questions:

Zero-Start:

People get them initially for weekend hiking, but can earn micro-payments for leaving it on while they walk around the city during the week; they can use the payments they receive to pay for sending their own packets. Or maybe they would do it to earn bitcoins similar to 21’s model.

Coverage:

A marketplace for transmitting packets means you will earn higher micro-payments by running a node in a place with few other competing nodes.

Capacity:

Mesh nodes that were well located and/or gateways to the internet, satellite uplink, etc. would have higher demand and receive larger micropayments. You can also do Uber style “surge pricing.”

Power:

I don’t understand the subtleties of this question, but I suppose some nodes will be left on while charging if micro-payments exceed the power cost.

Spectrum:

Here is a crazy idea: how about using crowd funding to buy spectrum with participants awarded with tokens that can be used to pay for utilization proportional to their funding. Because tokens could later be resold it allows people to speculate on the increased future utility of the spectrum. If the bid fails, the money could be refunded or used to buy spectrum from the winning bidders.

We know ICOs can raise $200M+ so it’s not inconceivable when spectrum is selling in $300M range.

Although the vast majority of ICOs have weak utility ideas for their tokens, I think a spectrum denominated token might be the best way to allocate access to this scarce resource.

I’d love to hear what other people think. Any one else exploring these ideas?


#53

Someone has created an example of sending a bitcoin transaction via SMS. If you are using the Lightning network then transaction signatures are essentially what you are sending around to pay for relaying data (eg. bitcoin transactions). I believe a signature is around 64 bytes. To close out the channel you would only need to dump a final transaction onto the blockchain. Perhaps via an SMS gateway like this. See Micropayment Channels for details. These are approximately 180 bytes.

The other part of the puzzle involves SPV so you can monitor when a transaction has been included in the blockchain.

Apart from the negotiation of a payment channel path, there would need to be some negotiation to set a price per byte to relay packets. The price could be much lower then any traditional payment system could handle. The smallest unit of bitcoin you could transfer in a payment channel is 1 satoshi, or .00004 USD at today’s prices.


#54

I think that some form of an ICO would be great for goTenna. There’s so many startups that are having ICO’s even without a network, but it’s perfect for this type of project.


#55

If I understand your question about “Network Integrity” correctly there are two networks we can talk about.

The integrity of the mesh network itself concerns how we motivate people to run mesh nodes and validate that they are properly relaying data to other nodes.

The other network is the financial blockchain based network where we want to validate peers properly relay transaction state information and broadcast new transactions we create.

I’ll try to address the latter and use bitcoin as an example. I’m not an expert, but this is based on my general understanding of the technologies involved. I’m a bit out of my depth, but I think I know enough to give a rough sketch.

I assume a network where mesh nodes can periodically and indirectly interact with the bitcoin blockchain. The system must work if bitcoin blockchain data does not propagate in real time and updates from nodes connected to the blockchain are infrequent.

There are five basic steps that happen to transfer value and confirm transfers:

  1. Establish anchor transactions to join bi-directional micropayment channels (eg. Lightning network).
  2. Update channel balances by sending signatures to update balances between payment channel nodes (who are also mesh network nodes). This happens between nodes with no blockchain involved.
  3. Sync block headers ( for Simple Payment Verification ). To validate transactions based on block depth.
  4. Subscribe to full nodes to receive updates about blocks involving relevant payment channel anchor transactions.
  5. Broadcast payment channel closing or penalty transactions to the global bitcoin blockchain.

A key consideration for this system to work is how the relative time lock windows are initially setup for micro-payment channel closing transactions. If a participant only receives updates from or can broadcast to the global bitcoin blockchain once a week, then the time locks must be set at perhaps a month so they can detect invalid closing transactions and broadcast a penalty transaction before it confirms on the blockchain.

The downside of a large time-lock window is a longer delay when closing a channel. However with relatively small amounts of value locked up it should be possible to trade-off between channel timeout delays and on-grid connectivity frequency. In many cases bi-directional channels will never need to be closed except in the cases of mischief.

Data we receive about the state of the blockchain can be locally validated, but we can’t know if some information was withheld. We can locally validate proof that one of our transactions was broadcast to the network, but if our block headers and/or transaction updates only come from one source, we could miss an invalid closing transaction.

So if we now pay nodes to transmit generic packets of data, how do we validate that when we pay a peer mesh node it doesn’t just take our micro-payment and ditch the data?

If every data packet travels along a payment channel path and uses hash-lock contracts to pay each peer along the path; no one gets paid unless the final recipient reveals a secret value. This value is encrypted specifically for them in the packet they receive. The upstream node that delivered the packet only receives payment once the recipient reveals the unencrypted secret. This secret flows back until the sender receives it and everyone settles their micro-payment balances off blockchain.

I’m not sure if this is totally clear, but the idea of hash-lock-contracts is a powerful one and I think relevant to the problem of mesh-network delivery validation. Perhaps it can be used without involving bitcoin at all, or in a more simplified way.

Comments and questions welcome. I think it’s exciting to think about how this kind of thing could work.


#56

The hash-lock is a really good idea, but how does the node ensure that the receiver doesn’t refuse to reveal the secret?

On the other hand, maybe it doesn’t matter. Maybe people would report those that steal your transaction money and their node would have a lower ranking. That way the community would police itself.

The hashing also brings up another interesting point, what if data was hashed and people could make blacklists of information they didn’t want to host or pass on? (Ex.things they considered immoral) I think Filecoin does something like this. But this is probably for later.


#57

I’m really interested in seeing if there’s a way in which blockchains might be used to incentivize the creation of mesh networks with GoTenna that doesn’t focus on micropayments, individualist economic incentives, or otherwise result in a situation where participants are more interested in making money off the system than they are with ensuring that data is routed in places where it’s needed. Althea is building a system on Ethereum that takes the micropayment-based packet forwarding route - I think there can be a more egalitarian way, particularly since GoTenna is so simple to set up.


#58

@Jessica, I’m very interested in this. Do you have any specific ideas or suggestions in this regard?


#59

@rmyers Not sure if you saw this question/reply from @Legion to your earlier post? :slight_smile:


#60

I’m spitballing here, but instead of micropayments I might imagine a reputation based system where each time a packet is routed through your device, you get a reputation boost, ideally with some weighting depending on how many other gotennas are in your area, the amount of time your device is on, etc (the more gotennas around you/the less time you keep your gotenna on, the lower that particular reputation boost). These reputation scores might then be a way of deciding how much bandwidth you are allotted when you try to send a message from your gotenna. Ultimately, the more you’ve contributed to the system, the better your service, no money necessary.

I’m imagining larger possibilities of how you might incorporate a universal basic income model like Circles into this, something with individual gotennas trusting each other so that your data can be routed through your trust network and your trust network’s trust network to ensure that it’s never in the hands of someone you don’t trust but I need to digest that more…

By the way - I’m the one who ran after you at your NYCmesh talk, really glad to see that GoTenna isn’t limiting the blockchain possibilities to ones with financial barriers to entry - exciting, awesome stuff :smiley: