Blockchain & goTenna Mesh


#1

We had a pretty fantastic discussion some time ago about various ways to implement blockchain in a way that is friendly to goTenna Mesh. The idea being that with a proper blockchain implementation, it would provide incentive to enrich the network and increase the number of relay nodes as well as provide a built-in throttle to overusage by users of the network. I wanted to kick this discussion back up and discuss any recent news/projects/ideas in this space. I still think this is a great combination of technologies in a way that could deliver some public good.

@rmyers @danielagotenna etc…

-Travis
AG5PE


#2

@mivyx good of you to start a new thread — the older one was so long! (That one is here if anyone wants to find it: goTenna Mesh and Blockchain: Potential Applications and Integrations)

In meantime, I’ll let @rmyers give you a bit of an update on what’s going on with the effort around an incentivized protocol that handles scarcities/coordination issues that mobile mesh networks need to address in order to scale in the long-term.

In addition, along with our friends at Samourai Wallet (hi, @TDevD!), we have an announcement we plan to make about an app integration for btc tx — that’ll happen on May 14 at Consensus NYC.


#3

Hi Travis - thanks for refreshing this thread.

The thinking around incentivization and blockchain is still very much going on. Lack of posting on my part has been due mostly to an intensification of interest and heads down work on the topic.

I will try to give a brief update on the incentive protocol progress, but it’s very much still a work in progress.

Some unique problems need to be overcome by any approach to off-chain incentive transactions on a low-power mesh network:

  1. limited bandwidth - protocol should be as non-interactive and low bandwidth/power as possible
  2. local connectivity - unlike the internet, not every node can freely connect to any other node

Protocols like the Lightning Network make assumptions about connectivity that make them impractical for mesh networks. Connecting to nodes you have previously anchored a channel with is not a free operation in a mesh network unless they happen to be within radio range. We also want the incentive protocol to use a bare minimum of bandwidth and leave as much as possible available for user data.

What I’m interested in right now is a way for each node that relays to be rewarded with what you might call a ‘relay credit’. Any node that wants to send data commits to spending some amount of ‘relay credits’ up-front and if the data is delivered, then the nodes that relayed it get the promised credits from the sender.

This isn’t a solution to the offline double-spend problem, just a way to make sure that only the nodes that usefully relay the data receive relay credits, and no redundant nodes or sibyl nodes are rewarded.

The solution we’re investigating uses signature aggregation to reduce bandwidth to the absolute minimum. Next steps are to solve the ‘fair exchange’ problem for final delivery of the message and integrating with some sort of public ledger to record the credits. Lots of work, but hopefully not intractable.


#4

Isn’t the incentivization problem irrelevant until there is a base level of altruistic users?


#5

On another note will goTenna ever accept crypto payments??


#6

Thanks for the update, @rmyers. This definitely brings back memories of digging into this topic late last year. There are some unique challenges to this low cpu, low bandwidth, mesh scenario that make this quite the challenge. Very glad to hear you’ve been working hard on this! Coming up with a viable (and testable) solution would be a huge accomplishment that could have far-reaching future ramifications even beyond its application here with goTenna.

I remember thinking the public ledger could be a challenge in itself due to the bandwidth limitations of the network. A new node comes online, registers a blockchain address, and now this (potentially giant) ledger needs to be downloaded and verified. Due to the decentralized nature of this application (no central servers available) I figured the whole blockchain (as known to that part of the network) has to be made available. Which brings me to another thought I had that with this specific blockchain application, it’s possible that this may never be one singular blockchain as we have with other protocols, but rather several completely valid but separate blockchains that have periods of being connected to each other and not connected to each other. Due to the fact that this mesh network will likely never be a single global network, but more likely, several enclaves of nodes - some very large and active and others small with perhaps varying amounts of activity. Each enclave would then have its own ledger maintained separately that perhaps gets connected to other enclaves during its existence and hence “mingles” with other ledgers as a result. I suspect that there should be consideration that a specific ledger may exist only on a single node for periods of time. Thinking of an outage in a certain area that outlasts battery life for instance and suddenly the ledger for that region gets splintered amongst the few nodes with enough emergency power to stay online through the outage but may not have connectivity to each other. This turns into a significant challenge when trying to figure out what transactions are valid and which may have been falsified but these are the types of challenges with this sort of application that don’t exist in typical blockchain applications. I suspect these issues aren’t insurmountable though. Perhaps this is the world where things like TCR (Token Curated Registries) will work just fine. I just never dug into these thoughts when we were all discussing this topic.

Has there been thought around the ledger and how it would be handled already or potential solutions? Just curious. Happy to dig into this stuff a bit if not.

Regardless, congrats on the progress made so far! It’s kind of exciting to think about a potential blockchain-based rewards system to drive up mesh adoption and participation in providing mesh connectivity. I’m a big fan of decentralized solutions like this that are hard for the powers that be to control. :slight_smile:

@nelson Regarding a base level of users
I think some of the consideration behind this was to use blockchain-based rewards to actually incentivize both the build-out of new nodes as well as incentivizing participation in the network itself. You do bring up a good point though, this is moot while nodes are so spread out they can’t reach each other. Hopefully the introduction of a rewards system will help drive up adoption and make this type of solution viable.

That’s really exciting about Samourai Wallet, @danielagotenna! Looking forward to that news. Lots of good things happening :slight_smile:

-Travis
AG5PE


#8

Good points @mivyx - the offline issues are some of the least explored territory. Currently I assume nodes will periodically touch bases with some sort of global shared ledger via gateways to the internet.

But going truly off grid and staying off grid would certainly imply some sort of sharding scheme. That might be an area worth researching if your’e interested.

You could also imagine different device manufacturers sharing the protocol but issuing their own tokens. You would then need to have markets for atomic swaps between different tokens. But that’s pretty far down the road at this point.

Speaking of TCRs, you should check out what Altheamesh is doing. They have a whitepaper on their plans floating around.

No, I haven’t dug too deeply into different ledger technologies. My bias is to bitcoin because it is the most established, but it’s unlikely that will be possible given the constraints we’re dealing with would require using some new cryptographic primitives for signature aggregation that are not likely to become part of the Bitcoin protocol. I think both Chia and Grim would be worth learning more about.

I’m really excited too! and looking forward to discussing in more detail what I’ve been working on.


#9

I think there will always be a base of altruistic users willing to relay, but solving the zero start problem can only be helped if people are also incentivized to run relays where and when they are needed and to discourage overuse of the system when there is heavy load.


#10

I don’t know as much about blockchains as many people here probably do, but are you suggesting there is a novel/new blockchain that needs to be created to service the use-case/solution you are mulling here? Meaning it will not run on bitcoin or ethereum or whatnot and will be an altcoin? (Sorry I am getting a lot wrong here, jargon-wise, but this stuff is so esoteric…)


#11

There is a process for existing blockchains like Bitcoin or Ethereum to support new features, so that would be the best route. On the other hand, we don’t really want a new blockchain for various reasons. Best would be to some how piggy back on an existing blockchain and support the new primitives we need at a higher layer (without changes to the core blockchain).

Sorry if that sounds like gobbledygook, short answer is maybe yes, but prefer not to.


#12

@danielagotenna and @rmyers were at the Consensus Conference today, and made a big announcement. In collaboration with the team at Samourai Wallet, we will soon release a new app called TxTenna.

This app will allow users to make bitcoin transactions using a decentralized, off-grid network. You can read more about it in the piece that @rmyers wrote for our magazine here: https://inthemesh.com/archive/txtenna-decentralizing-last-mile-bitcoin/

Congrats guys!


#13

@TDevD is doing pretty much all the work at Samourai Wallet :slight_smile:


#14

High praise :wink: Things are changing. As of recently, we have a small team and are now growing. goTenna “meshes” perfectly with our ethos and we are looking forward to app launch. Looking forward to feedback from everyone post-launch.


#15

Really inspired by what @TDevD et al have done with TxTenna and excited that we’ll have something the Bitcoin community can build on to take advantage of mesh communication. This is just the start!


#16

We do accept bitcoin!


#17

Thanks @eamonabraham for editing the ideas in the article into a cohesive story. Couldn’t have done it without your literary talent.


#18

Now available as a Crypto Quik Read for those on the go:


#19

My little post was isolated. I’ll put it here:


Basically there’s another blockchain project trying to incentivize network routing. I had some questions about txTenna as well.


#20

Thanks for the question @ASSTRIEN. Just to be clear, the TxTenna app is not related directly to any effort to incentive relay nodes. The TxTenna project was only conceived as a way to decentralize the broadcast of bitcoin transactions and to create an alternative path for getting them onto the bitcoin blockchain. TxTenna is just another example of decentralizing communication using a mesh network, in this case messages about value instead of free-form text communication.

That said, doing on-chain payments in bitcoin to incentivize relays is a useful benchmark to compare more elaborate schemes against. It has the advantage of being a straight forward method that doesn’t involve any new cryptography or 2nd layer concepts.

One reason using on-chain transactions, bitcoin or otherwise, for incentives is problematic is that on-chain transaction are large relative to the typical messages we send over the mesh. That means you can’t have a 1 to 1 relationship between the messages we send and incentive payments for those messages if the payments themselves are as large as (or larger) than the original message. Instead, as you said, you’d need to have some sort of ‘points’ that are settled at the end of the month with a single on-chain transaction.

This moves the problem to how to fairly attribute “points” to relays in a decentralized way. Once you had a way to fairly attribute points, you could account for them fairly easily in a centralized way. Just imagine something like how airlines track the miles you fly and have a central database for frequent flyer points. Those systems use a database and don’t need any crypto-currency. But centralized accounting would introduce a central point of failure and control that in my opinion violates the spirit and potential of mesh networking.

So the hard work that needs to be done is to come up with a light-weight and trust-minimized way to track when people use or provide relay capacity to the mesh network, and a decentralized way to settle and track this information. Doing it on a decentralized public ledger means that no company controls balance information and instead it is effectively controlled by the people who use the mesh network.

I’ve got some good ideas for how to do the first part (track usage) in a low-overhead way, but tracking balances in a decentralized way is a non-trivial problem.

Please share any ideas you have about tying off-grid relay accounting to on-grid blockchains.


#21

Ah! finally a SME replied to one of my posts (to include the substratum, bitcoin, MAIDsafe, and New Kind of Network reddits and forums) So excited.

So, to clarify before I said points but I think it would be more comparable to stocks or shares really and it might actually have to be registered as such as a result.

As far as trustlessly distributing these shares, we could create our own blockchain with its own lightening network that way it doesn’t bother with everyone’s transactions, but emphasis that they are points redeemable for the networks earnings in bitcoin and not a currency. They could also time expire to make sure people don’t try to turn them in at a higher earnings rate. The tokens would be swapped for bitcoin via a smart contract hosted on ethereum or cardano trustlessly.

On the topic of scaling have you looked at the lightening network? It’s supposed to solve the scaling issue by having a level of trust in the process using a bit of game theory. I’m not sure what the size of data would be in a lightening transaction though. I would love your inputs as I only know the basis of what these things do and not the code or data sizes of everything.