Blockchain & goTenna Mesh

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.

4 Likes

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!

1 Like

We do accept bitcoin!

1 Like

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

1 Like

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

2 Likes

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.

2 Likes

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.

1 Like

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.

I very much favor settlement via a 2nd layer protocol, and lightning in particular. But after looking at Lightning, and similar protocols, they make two assumptions that must somehow be overcome :

  • exchanging messages with any node is essentially a free operation, because all nodes are equally connected on the internet
  • communication costs are negligible and an interactive protocol is ok

Neither assumption is true for a long range, but low bandwidth, mobile mesh network like goTenna.

Nodes you can communicate with via a local broadcast cost less, from a network standpoint, than nodes 5 hops away. Communicating with nodes that are not otherwise involved in delivering our message introduces unacceptable overhead.

For example, in Lightning you first connect to and anchor payment channels with a small number of (ideally) random nodes. You can pay anyone else if a multi-hop payment channel path can be found that starts with one of the nodes you are connected to.

This doesn’t work too well in a mesh network if the subset you’ve anchored payment channels with are not within your local radio range and you need to invoke (and potentially pay) relays to communicate with them. Especially if the protocol has multiple communication steps, as does Lightning.

These problems may not be insurmountable, but it does require a rethink of how you design your 2nd layer protocol.

1 Like

Blockchain systems require consensus to work. Without consensus, someone could modify their device and receive more shares or what have you than the what he actually routed, effectively stealing from the other people who are trying to route honestly. You could shard the process though. Only local groups in the mesh need communicate with each other to gain a small group of consensus. These small groups would report after a length of time to a masternode which also routes traffic long range to other masternodes. Masternodes could be given larger shares because of their function. In cryptocurrencies that use masternodes, the masternodes tend to be very expensive pieces of equipment with a collateral of $55,000 for crypto which is only worth $5 a coin (PIVX in this case) Not that its necessary to have collateral but I am saying that people actually do this. Masternodes could be that of project MOAN or a point to point laser set up. (We know that GoTenna can be modified fairly well so it isn’t outside of the realm of possibility)

Even in this system though, there does need to be some kind of ledger. Even if its sharded. Let me know if sharding is enough to make this system work.

Sharding for centralized services

Sharding used in crypto

There’s some crypto videos on masternodes as well let me know if you want to see that.

2 Likes

You make a good point @ASSTRIEN about the fact that only nodes local to each other in the real world need to share consensus about each others balances. Mesh nodes in Singapore should agree on the ledger balances of other nodes in Singapore, but a mesh node in London does not need to be part of this consensus until it moves from London to Singapore.

I’m not sure if the concept of master-nodes with staked value is required here and it’s worth observing that most projects don’t have the same concept of physical locality that a mesh network does. We just need a protocol that allows the internet connected gateways for off-grid nodes in a particular physical location to come to consensus about the balances of the nodes in that location at a a given point in time.

Gateway nodes are likely to initially be out of consensus because there is no way to guarantee they will all get updates from the same off-grid nodes in a given area. This problem isn’t too different from bitcoin miners receiving different sets of transactions. The key goal is that the gateway nodes converge on a canonical ordering of transactions, and thus balances, for the nodes in a given area.

Ideally there’s an efficient way to transmit back the current state of the ledger, or at least the local balances, from the gateway nodes to the off-grid nodes.

I’m curious if there are any other systems that use a sense of physical location to partition the blockchain? I’ve seen a few projects that try to replace GPS with some sort of blockchain concept (eg. FOAM), but that’s not really what we want to do. In our case we just want nodes that self-report in a particular physical location to stay in sync.

1 Like

I’ve been thinking through the last step of message delivery, in particular the last relay node before a message is delivered to the recipient. I’m curious what people think about my proposal for handling it and the impact on the overall incentive economy.

There’s really no way for that penultimate node to know if their next broadcast is to another relay or if the message recipient will hear it. There are two protocol general options to how to handle the situation: always broadcast everything, including the message, or some sort of a multi-phase challenge and response system.

I’m going to rule out any multi-phase system as too slow and inefficient for a low bandwidth mesh network. Especially because every relay node would have to do the multi-phase protocol at every hop. No node knows if they are the penultimate node or not.

So assume relay nodes always broadcast the whole message, along with any incentive protocol overhead. How do we confirm that incentives are only paid to relays when the message is delivered? The system degenerates fast if relays are paid whether or not a message is finally delivered.

If the message receiver hears the message, then they have no incentive to do anything to confirm receipt. If they also receive some of the incentive payment, then they would be encourage to acknowledge receipt, but not if the sender and receiver are collaborating to save money on mesh relay fees.

The only way I see to prevent this is if the value a message sender commits upfront to send a message is lost whether or not the message is signed for as received. The only difference between the receiver acknowledging receipt or not is whether or not the relays and receiver get some of that committed value from the sender. Otherwise the value should just be destroyed (ie. burned).

It actually seems logical to me that whether or not a message is delivered, the sender should have to pay something. The only difference is whether or not that spent value should go to specific nodes, or generally to the network as a whole.

Keep in mind we’re likely talking about incentive payments in the micro-cents. The cost to send messages only becomes meaningful over a large number of messages. Also, whether or not a message is actually delivered, network bandwidth and the battery power of relays is likely still used.

If pre-committed incentives are burned when a message is not received, then it increases the value of the remaining tokens generally. This should encourage relay nodes to participate in relaying messages for others and raise the success of message delivery. I am also assuming incentive token minters (eg. miners) receive a constant block reward so that token inflation counteracts the deflation caused by burned tokens.

The amount of block reward (ie. inflation) could even be tied to the number of burned tokens to preserve some predictable equilibrium.

One implication of this is that messages have some sort of “time-to-live”. That’s a generally good thing so that messages don’t rattle around forever. But for incentives it also means that if a message is not delivered within some period of time, the value is considered burned.

Am I missing something here?

2 Likes

So, how does one acquire relay credits outside of relaying someone else’s message or mining? Would there be a way to get a message through without having any credits?

Also, since blockchains by nature are excellent record-keepers, are copies of all messages stored in the blockchain (encrypted or not)?

3 Likes

+1 on all of @MrTSolar’s questions!

2 Likes

Hi @MrTSolar. I would expect devices to come pre-loaded with credits, and also that a secondary market would exist where people could sell their excess credits.

I see an incentive system as a way to augment the existing free relay system, not as a replacement.

i don’t think people would want their messages recorded, and it would be more efficient to record them in a normal database if they did. Some sort of cryptographic signature would likely be recorded in the blockchain though, as proof that a message was delivered.

1 Like

I’ve been mulling over the question of how to setup the token economy for an incentivized mesh network.

While thinking about it, I keep coming back to the funny and informative lemoncoin video.

It seems the consensus is that the best utility token would not be a new token, but just using some preexisting widely used money.

Using normal fiat currency is not possible because you can’t digitally exchange dollars or yen without relying on centralized online banking infrastructure. That would defeat the purpose of having a decentralized off-grid communication system. Also, which would you choose? Dollars? Yen? The ideal unit of value should be some sort of international currency.

Fortunately, there exists an international and decentralized unit of value: bitcoin. However, using bitcoin as tokens is not technically possible at this point because of bandwidth constraints when using long range low power radios like the goTenna Mesh.

Making a bitcoin transaction requires at minimum transmitting a 64-byte ECDSA signature, and often more than one. Sending a message over three relay hops would require 3 x 64 or 192 bytes just for the signature information - minimum. More hops or more complex smart contracts require transmitting more signatures. Using a second layer system like the Lightning network would help, but you can’t avoid the need to eventually transmit a lot of signature information over the network. The Lightning network is also not optimized for reduced bandwidth communication and assumes relatively high bandwidth connections between all nodes.

Signature aggregation can reduce the need to transmit a large amount of signature data, but would require creating a different blockchain because the Bitcoin network only supports ECDSA signatures which can not be non-interactively aggregated. A new blockchain that supports signature aggregation seems to me to be the best approach, even if it introduces the friction points mentioned in the lemoncoin video. But creating a new blockchain means making important economic and security trade-offs. What technology secures the value of the chain? How are new tokens issued or destroyed? Can you prevent people acquiring tokens to speculate on their future value instead of their utility for decentralized communication?

Only the top proof-of-work (PoW) blockchain has any substantial guarantee of security. Attacks on low value chains show what can happen. The next most popular alternative solution is a proof-of-stake (PoS) system, but this mechanism is as yet unproven to work for high-value networks. There are also questions about the fairness of a system that indefinitely rewards the original owners of a currency.

So how how can a new blockchain use PoW security if only the most economically valuable chain (currently Bitcoin) can be truly secured by PoW?

I propose using something like the Liquid Sidechain with a nominal peg to bitcoin. If the value of an incentive token increases too high, people will increase token supply by converting bitcoin to incentive tokens. If the utility tokens fall in value, people can redeem them for bitcoin. If bitcoin increases in value faster than the incentive tokens increase in value, tokens will be redeemed for bitcoin and the remaining tokens will increase in value. This solves the problem of issuance and makes transparent the security trade-offs inherent to a minority chain. There would be no advantage to speculatively acquiring tokens over just acquiring the underlying bitcoin that the tokens are pegged to. There is also no new decentralized consensus system to attack, except the Bitcoin network itself.

A federated sidechain can be managed like the Liquid network, but instead of a federation of exchanges, it could be a federation of mesh device makers. Device makers would inject liquidity by pegging bitcoin to jump start the process and issue tokens to their customers. Users need to trust the manufacturers to honor valid transfers between the bitcoin and token networks, but as long as the majority (or super majority) are honest the system works. This is an improvement over something like mPesa air time tokens which are 100% controlled by a single company. With a federation of competing companies there is an incentive to follow the rules and not act unilaterally. Unlike a non-dominate PoW or any untested alternative consensus system, the trust trade-offs and incentives are transparent to everyone involved.

I’m really curious to hear what other people think about this problem and my proposed solution. It’s not really just a problem with mesh network incentive tokens, but this is a concrete example for thinking about the problems of utility tokens generally.

2 Likes

Sounds like an interesting strategy. It does seem like we’re designing a mini algorithmic stable coin inside the project though. Any way to use something either already stable to BTC or better yet stable to the dollar?

My suggestion is inspired by the idea off of LBTC (Liquid BTC) which is an existing stable tracking token for BTC. The difference between a crypto-crypto stablecoin and a crypto-fiat version is that with the fiat version (like Tether) someone needs to have a bank account that holds the fiat. In the crypto-crypto tracking token the bitcoin would be locked on the blockchain and require multi-signature authority to unlock. This helps not just with decentralization but with trustless auditing.

Whatever entity controls the fiat is the de-facto centralized owner of the stable coin. That would be a non-starter if we want this protocol to be open to different vendors.

2 Likes

@rmyers, I hate to be THAT GUY but wouldn’t this make each Gotenna user legally a commercial provider, and place all of us under the jurisdiction of various ridiculously heavy-handed regulations (originally calibrated for multi-billion telecom giants)?
I think the network’s only chance of survival is to steer well clear of regulatory friction, and money is a well-known source of such friction.

2 Likes

Haha - you make a really good point. I think the first step is to design as decentralized a protocol as possible. This is new territory at the intersection of the “sharing economy”, consumer friendly unlicensed radio spectrum and things the SEC has opinions about. There’s also potentially a global set of agencies from every country where this protocol could operate - some of them totalitarian regimes.

My personal preference would be to throw all of the interested agencies into an octogon to battle it out for jurisdiction. In reality, I expect lawyers will be involved.

4 Likes