Blockchain & goTenna Mesh

[rmyers]

@ASSTRIEN

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.

[ASSTRIEN]

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.

[rmyers]

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.

[rmyers]

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?

[MrTSolar]

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)?

[femmesh]

+1 on all of @MrTSolar’s questions!

[rmyers]

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.

[rmyers]

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.

[goTennaUser_25169]

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?

[rmyers]

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.

[armin]

@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.

[rmyers]

@armin

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)?

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.

[mficiencies]

@rmyers What is next in this project for you?

[rmyers]

@mficiencies

@rmyers What is next in this project for you?

I’m writing up a more detailed plan for how to incentivize relay nodes so I can get more feedback from people on these ideas. I am also running simulations to try to understand the impact of adding incentive data to a mobile mesh network.

The biggest challenge is coming up with a system that doesn’t create too much communication overhead. The other big issue is keeping offline nodes in a local mesh synced with a decentralized global ledger so that incentives are meaningful.

[danielagotenna]

@jmclarty and here — this is the more recent blockchain thread!

[rmyers]

@jmclarty - I read in your intro that you are interested in the economic aspects of blockchain based incentives.

One aspect that is worth some discussion here is about the token economics of such a system.

@nic_carter suggested an interesting way to look at utility tokens is to consider the “impossible trinity” problem and replace ‘central bank’ with ‘blockchain’ and ‘currency’ with ‘token’.

Start with the idea that we have a way to pay nodes with a token if they relay data for other nodes. We would like these tokens to incentivize people to operate nodes when and where they are most needed.

Unlike a traditional centralized mobile carrier, mobile mesh networks can not use top-down planning to place relay nodes. A decentralized alternative is to use micropayments to incentivize activities that support the network. Nodes earn tokens in proportion to how much they help with network coverage and delivery success. Nodes must also spend tokens in proportion to how much they use the network to send data.

Like in the trilema linked above, we have three qualities that can be selected, but it’s impossible to have more than two.

• A - stable value - the value of one token will not vary relative to some global measure of value over time
• B - permission-less / censorship resistant - at any time, anyone can freely exchange tokens with anyone else
• C - control of the rules - flexibility on how tokens are created and transferred

Here are some ways we could optimize for different pairs of properties:

• A & B - Use an existing decentralized blockchain like Bitcoin. A stable coin like Tether also fits here to the degree it can be traded and redeemed freely.
• A & C - Create a credit system where goTenna issues and redeems tokens at a fixed price.
• B & C - Create a new decentralized blockchain with its own issuance and transfer rules.

The downsides for each of these approaches are:

• A & B - An inflexible protocol. We cannot add or modify aspects of an independent blockchain that must be changed for our particular use case of mesh messaging incentives.

• A & C - Centralized control of the tokens. Independent developers that are needed to create a strong ecosystem will be reluctant to build on a centralized system. Centralization decreases the long term resilience and scalability of the system.

• B & C - Price volatility. Large swings in the relative value of a token adversely effect its native utility. Blockchains with untested security and use cases become easy targets for speculative trading.

This is a Chinese restaurant. You took the lunch special and must pick 2 from the menu: A, B or C. Which two do you choose? And why?

Bonus points if you can suggest a deliciously possible combination of all three.

[rmyers]

I just finished the first version of a project I called txtenna-python. This allows you to receive Bitcoin transactions over the mesh directly to a goTenna connected to a fullnode via USB.

remyers/txtenna-python

The README file includes a sample showing how it works.

I also added functionality for sending transactions, not just receiving. Everything works using a local bitcoind via the RPC interface so the bitcoin user can stay completely anonymous when they send (via mesh) and receive (via fullnode) transactions.

There are some more improvements I would like to make, but if anyone would like to give it a try, I’d love some feedback and suggestions for future improvements.

[Leiah]

Excellent work. I’m trying to get it working on my system.

[rmyers]

@Leiah

Excellent work. I’m trying to get it working on my system.

Thanks, feel free to post any questions or problems you have.

One tip is to make sure you have upgraded your goTenna to the 1.1.12 firmware. I updated the README to link to a pdf that describes how to do that. It’s also discussed elsewhere on the forum.

[Leiah]

Thanks. I’ve upgraded the firmware, installed txTenna server, and requested the SDK token. At the moment stuck on how exactly I should edit the content of index.js (could you maybe post an example?). Also can’t see how to install the whl file with pip as per the 4th item on the list of prerequisites. What command would I have to use for that? I’m running Ubuntu if that makes a difference. As for the goTenna, does it matter what state it’s in when I plug it in? Does it have to be in relay mode for example? Does it matter if it’s been paired via bluetooth?