I quit Twitter a couple of days ago, and I want to home in on Bitcoin and especially Lightning Network.

Indra is a project aimed at designing Onion Routing distriibuted Virtual Private Networks with a focus on payment privacy.

The need for this is obvious to anyone who is aware of the state of Bitcoin full nodes and Lightning channels running over Tor, with the ongoing DoS attack on Tor.

I am dedicating this thread to posting updates on progress, to let people know what is going on and where progress is at. I will reply newly to this thread every day or three as I have something to report.

So, just to be brief, today's update is that I have been working on the cryptosystem for peer to peer messages for the last few weeks.

In previous work I developed a binary encoder that used a somewhat unique feature of Go, the slice of interfaces (dynamic array, and a solution for dynamic types that remains static in compilation using type switches), to simplify specification of message formats for network packets.

The advantage of this scheme is that when data arrives over the network, the receiver can selectively decode the wire format into the runtime data format. Because encrypted, integrity protected data can be invalid due to packet corruption, missing packet segments, and attempts to forge packets, a progressive strategy for decoding data makes more sense, as every nanosecond spent decoding data that won't be used is a nanosecond not decoding useful data that matters.

I expect to be finished creating all the data types and the core container implementation in a few days.

A core goal of Indra is to provide location privacy and prevent establishing connections between addresses on the network, while adding the most minimal cost in latency and connection stability.

It could be compared to QUIC, but with countermeasures against surveillance, and it will use a reliable UDP/gossip based network traffic pattern. This is why the logo has a 6 element circuit, Indra traffic always looks like it's going outward, there is no distinctive pattern of return.

To help this project, you can either donate to my user here on SN or use this LNURL

LNURL1DP68GURN8GHJ7AMPD3KX2AR0VEEKZAR0WD5XJTNRDAKJ7TNHV4KXCTTTDEHHWM30D3H82UNVWQHHW6TNV4MXJUN8DUCRXVAXQP2

or

wisevirgo03@walletofsatoshi.com

Awesome project, I'll certainly look into the repo some.

This is something I'd be interested in integrating once it matures.

I'm done creating the message encryption system as previously described, all lives here https://github.com/Indra-Labs/indra/blob/main/pkg/sifr/message.go

The serialisation to put on the wire is not in there yet, that will be done shortly.

The frame format now has two fields, Seen and Expires, and these are used to communicate to peers they can forget previous private keys as they won't be used again. They are in the clear but the truncated hash does not provide any reverse path to identifying it, and this allows the peers to stay lean and purge stale data storage quickly.

The details of the encryption/decryption will be tidied up shortly. The encrypted message encrypt/decrypt is tested and its output is embedded in the frame.

The last little tidbit is I was looking at the go.mod and saw a nasty blake256 hash function imported. I dug around and discovered that the particular Schnorr signature implementation devised by Decred, which I borrowed, as they have the nice secp256k1 (bitcoin elliptic curve group) signature implementation uses blake256 for signature hashes and their specific version of schnorr.

That's not bitcoin!

So I have copied out and modified their code, swapped the blake256es for sha256es. and changed everything that is practical to change easily, there is just some tests that will require regenerating things because the blake hash output will be different to sha256 outputs so all the signatures both the hash of the message and the output signatures will not work so there is two tests currently disabled waiting for me to deal with this later.

It's not critically important because the code otherwise works and I am anyway not a fan of pre-defined test-results, I prefer to make tests that wherever possible use cryptographically random data to test algorithms on as they are far less likely to trip on edge cases and don't need the tedium of regenerating values if a bug in the algorithm changes the outputs.

I promised I would make intermittent updates to this thread, and here I am with a new tidbit.

This post is about cipher modes. There is a number of strategies used with encryption of which AES is a most famous standard.

There is too many to mention but the essence of what I wanted to get at was that conventional AEAD, the most complex version that provides authentication with the encryption.

This, in combination with Galois Counter Mode produces the most common type of cipher used for arbitrary encryption streams.

After a bit of reading I decided that if I am using schnorr signatures to authenticate data, which combines a hash of a message in such a way that by taking that hash and combining it with the signature you get back the public key of the signer, then I don't need to use an authentication method, and for the sake of future acceleration, since Indra is a bulk throughput system, parallelisation of the decryption process would be desirable.

AEAD with GCM achieves this but wastes processing on authentication.

If one assumes that the messages are either small or the chains of messages that link into longer messages, contain error correction redundancy, or that message bursts are deliberately small so as to minimise packet loss errors, one does not need to worry about the "authentication" part of the process, as the complete assembled packet contains this, sooo, long story short, I decided that the best mode for Indra message encryption is CTR, which enables a message to be encrypted such that with the message key and any number of the fragments of the message each segment can be reliably decrypted if it is not corrupted, similar to GCM.

But the advantage is that if the message is already assembled using Reed Solomon forward error correction, a fixed ratio of the packets can be corrupted (and will be erased) and because of the use of a counter mode, only the first packet is critical, and as many of the rest as the error correction mode dictates, which is essentially a series of codes that duplicate segmetns of the data such that N of M segments yields the correct message without retransmission.

I have previously done a little work on, and started to build out a dynamic RS FEC system that has a retransmit request for failed transmits and an adjustment that is based on the failure rate of packets received that automatically increases redundancy as interference increases, and then as it decreases, dials back the redundancy

TCP is a protocol that was invented in the early days of the first DARPAnet and is still the primary transmission protocol. However, it is being steadily replaced by Google's QUIC protocol, which operates over UDP and has a more dynamic tolerance of failures in the routing path.

Because packets in Indra are travelling over potentially worst case transmission failure and transmission corruption, Indra will be using a segmenting Reed Solomon Forward Error Correction redundancy protocol with dynamic feedback adjustment, it will use CTR, which is an unauthenticated encryption mode, with secp256k1 schnorr signatures to authenticate the error correction protected packets.

Initial implementation will not include RS FEC redundancy, this will be added once the basic system is implemented and proven.

The point of all this is in eliminating signal latency. Because Indra inherently increases latency of signals by a base value of 3x due to its erratic 3 step pathways, it is worth consuming a little more bandwidth to eliminate the need for retransmission of failed packets. For optical connections, the packet drop rate is very low. But for radio based connections this can be intermittently high depending on all kinds of issues, including solar flares, jamming, and so on.

Part of the reason why Elon Musk is making a big titter about Starlink and Ukraine is because the transmission protocol used by Starlink uses Reed Solomon redundancy and has a higher failure tolerance than many of the more specialised and special frequency bands used by military radio systems.

Of course, the internet is better than all the things. And so, also, Indra must be better than all the internet.

There is a rule in software development, never optimize early.

So I'm going to just use Gotiny - the fastest binary/wire codec I know of, nearly 10x faster than Protobuf. and if there seems to be a need to minimise preprocessing I'll think of other ways to do this.

One thing that immediately comes to mind is the fact that encoded blobs of data themselves can be layered inside other encoded segments, making a progressive decode possible without wasting time on a custom codec.