Avatar
Loki
3628e6a5764cacab310474c9f9c588657989c74b5ef0718c7e6e0e53a2a1f773

2,100,000,000,000,000 is the total max supply of sats

18,446,744,073,709,551,615 is the maximum value of an unsigned 64 bit integer.

I forget now. It's been a long time since I looked at the bitcoin code.

Thanks to the ppl who have been giving me support while my brainbox has filled with somersaults.

Stress can be an incredibly toxic thing to the mind.

You all know who you are. Salute!

NSA uses tor, of course, and it's no threat to them that they run a lot of the nodes behind fronts.

NSA would use darkweb businesses as cover, and probably some of them are heavily infiltrated, you surely know the story of SR.

Time sensitive is not so much the big deal, low latency is not that bad really, what sucks about Tor is the time one can be waiting for a ping before it and the app protocol time out. On SSH it's extremely difficult to work with it, even using MOSH.

Other than that, I illustrate it in the Indranet whitepaper here:

https://git.indra-labs.org/dev/ind/src/branch/master/docs/whitepaper.md#user-content-tor-isnt-scaling-but-bitcoin-needs-onion-routing

It's not scaling. Per node bandwidth is moving up but number of nodes is not. It's been static for over a decade. The security and stability of the system cannot be in a positive trajectory in these conditions.

You should try using Tor for SSH. It's simply not designed for long living connections.

The lack of performance, that's because it has no incentives for node operators, and that also means that probably most of them are owned by the NSA anyway.

Replying to Avatar Loki

It's a relay network where you make lightning micropayments for small prepaid balances creating sessions with many relays, then your client uses these sessions to create multi-hop paths to reach services, which are advertised exit protocols that relays advertise.

If your message is just a broadcast, such as a bitcoin transaction, you can watch to confirm it got to the Bitcoin p2p network via other channels, but to enable privacy for clients, while the server is public, you send special types of messages that carry requests to these services, which I call "reply headers" and they contain a secret path to return, and the ciphers to encode the message on its way back to you.

The payload is already known to the exit anyway, and it knows how many hops the path back will be, but it does not know the keys that combine to create the set of symmetric encryption keys, or who will be receiving them and unwrapping their layer of the message beyond the first hop, and because the path is selected by the client, it is unlikely that an evil exit will also be in cahoots with more than one of the intermediary hops.

This creates "client side anonymity", which is to say, the exit is public, but the client is hidden. The relay operator can indeed be running the service themselves, on the same machine, or elsewhere, through the use of a firewall forward or similar.

Then, hidden services can advertise their existence via these client side private routes, and deliver a reply packet and intro to their chosen introducer, clients can request an introduction after receiving the ad for the introduction on the p2p gossip network, and deliver a request containing the client reply headers, to the introducer, and then back to the hidden service, who then can send a new reply header to the client using the client's routing header, and so on and so forth, as the server and the client can now negotiate their reply paths to each other independently of the introducer.

The hidden service will accept reuse of some prior reply headers in case of a transmission failure, when one of the hops in the reply header fails for some reason, but worst case the client uses another introducer to get a new connection established.

This is "bidirectional anonymity" or hidden services.

The last piece of it, is that it requires a connectionless p2p network transport, in order to minimise latency. I already have a protocol that uses libp2p and tcp, but this protocol adds tcp handshake delays every time a client constructs a path that the hops along the way are not "connected" to - whereas with a connectionless transport, it just delivers it and the next point in the path expects random messages from everywhere, and it doesn't maintain any state aside from the sessions that clients paid for.

This all will enable not just privacy, both client, and client AND server anonymity, it also allows relays to put a price on delivering messages to other network locations, such as their own stash of content, which can potentially be monetised to distribute the content, using Prisms or potentially even special redistribution licence fees, or other possible schemes that use cryptography to guarantee the payments are divvied up, and it would enable things like wifi internet access, while getting paid for it, and without becoming a man in the middle for malicious actors who won't profit if they have to pay for the traffic (eg spammers).

In other words, it could help the spam problem on nostr as well, protect bitcoin users from doxxing their location and where the private keys are located, and likewise for LN operators, whose location is a vulnerability for attacks for the same reason.

It's difficult to explain it any shorter than that, and I'm very very welcoming of anyone who can boil that down so it's understandable. I know that LN was completely opaque to me at first, and even after reading the WP, and many further articles, I only started to grasp it a bit.

Feel free to feed it to an AI, make a short version, join in and help bring funding to it.

It should be obvious that I'm not the person to write such marketing, I'm the one engineering it!

I didn't mention the "lightning bolt" decoy propagation patterns or the delay messages or several other things. This is just the VPN use case and a little hint at the paywall use case.

probably potatoes and eggs.

It's a relay network where you make lightning micropayments for small prepaid balances creating sessions with many relays, then your client uses these sessions to create multi-hop paths to reach services, which are advertised exit protocols that relays advertise.

If your message is just a broadcast, such as a bitcoin transaction, you can watch to confirm it got to the Bitcoin p2p network via other channels, but to enable privacy for clients, while the server is public, you send special types of messages that carry requests to these services, which I call "reply headers" and they contain a secret path to return, and the ciphers to encode the message on its way back to you.

The payload is already known to the exit anyway, and it knows how many hops the path back will be, but it does not know the keys that combine to create the set of symmetric encryption keys, or who will be receiving them and unwrapping their layer of the message beyond the first hop, and because the path is selected by the client, it is unlikely that an evil exit will also be in cahoots with more than one of the intermediary hops.

This creates "client side anonymity", which is to say, the exit is public, but the client is hidden. The relay operator can indeed be running the service themselves, on the same machine, or elsewhere, through the use of a firewall forward or similar.

Then, hidden services can advertise their existence via these client side private routes, and deliver a reply packet and intro to their chosen introducer, clients can request an introduction after receiving the ad for the introduction on the p2p gossip network, and deliver a request containing the client reply headers, to the introducer, and then back to the hidden service, who then can send a new reply header to the client using the client's routing header, and so on and so forth, as the server and the client can now negotiate their reply paths to each other independently of the introducer.

The hidden service will accept reuse of some prior reply headers in case of a transmission failure, when one of the hops in the reply header fails for some reason, but worst case the client uses another introducer to get a new connection established.

This is "bidirectional anonymity" or hidden services.

The last piece of it, is that it requires a connectionless p2p network transport, in order to minimise latency. I already have a protocol that uses libp2p and tcp, but this protocol adds tcp handshake delays every time a client constructs a path that the hops along the way are not "connected" to - whereas with a connectionless transport, it just delivers it and the next point in the path expects random messages from everywhere, and it doesn't maintain any state aside from the sessions that clients paid for.

This all will enable not just privacy, both client, and client AND server anonymity, it also allows relays to put a price on delivering messages to other network locations, such as their own stash of content, which can potentially be monetised to distribute the content, using Prisms or potentially even special redistribution licence fees, or other possible schemes that use cryptography to guarantee the payments are divvied up, and it would enable things like wifi internet access, while getting paid for it, and without becoming a man in the middle for malicious actors who won't profit if they have to pay for the traffic (eg spammers).

In other words, it could help the spam problem on nostr as well, protect bitcoin users from doxxing their location and where the private keys are located, and likewise for LN operators, whose location is a vulnerability for attacks for the same reason.

It's difficult to explain it any shorter than that, and I'm very very welcoming of anyone who can boil that down so it's understandable. I know that LN was completely opaque to me at first, and even after reading the WP, and many further articles, I only started to grasp it a bit.

Feel free to feed it to an AI, make a short version, join in and help bring funding to it.

It should be obvious that I'm not the person to write such marketing, I'm the one engineering it!

I am in the market and immediately available for work involving Golang and I have extensive experience working with the btcd codebase, protocol design, network handlers, concurrent and parallel high performance programming, binary and text based data encoding, code generation.

I was trying to chase fiat mining work in the shitcoin field, but honestly, especially after the way I was treated by the Cosmos crowd over the years, culminating in a rude snub today with no feedback that I deserved considering how they just yanked the job when Terra/Luna blew up last year, and my other option currently in process is a Distributed Validator system for WEFereum honestly, I can't do it, I really can't do it.

I currently cannot continue to work on https://git.indra-labs.org/dev/ind in a full time capacity because my sponsorship to work on it is finished and I need to get income happening as soon as possible after landing in Madeira.

If anyone has any clues or tips about Bitcoin/LN/Nostr work involving Go on the backend/protocol/server level, I have already contacted one option, but I don't know where else to look - bitcoinerjobs has ZERO Go dev roles, and honestly, I'm not interested in anything that puts any other language in the main place of my daily work, most especially not Rust, Javascript or C++.

Until a year ago I have had abnormally sharp vision. This last year a B1 deficiency reached a critical point and I have chronic tinnitis and was getting double vision for about 2 months before I started to get a reasonable amount of relief by taking hella B complex. The cause being that I don't eat grains due to allergy, and that's where you find B1. Not anywhere else. Not energy drinks, none of them have B1 or B2 in them, and it's hard to find it by itself, even though the damage it can cause is severe. Long term memory loss too. It's a big part of the mechanism behind the damage of alcohol abuse.

Quantum computing is fiat nonsense. Do you know how much power it requires to cool the q-bits? Even if it accelerates a password crack by a million times it's still 1 year with the equivalent of a 100k pop city of energy consumption, and that entirely assumes that Schnorr's algorithm is actually going to work, which isn't a given either.

It's the same fantastical nonsense as vat grown meat and vegan collagen.

https://git.indra-labs.org/dev/ind is my work. My work is based on making use of LN to act as a monetary incentive and spam prevention mechanism for a relay routing system, like Tor, but based on the same type of cryptography used in Lightning.

And I'm a terrible marketer, I haven't got a snowflake's chance in hell of having my work funded at this point.

Clapper for the Crapper xD

This morning for a change I wake up and I am already able to focus on normal sized text, with a tiny bit of effort, no double vision, just a bit blurry. I wonder how much longer until the B1 deficiency damage is recovered. Not too long I hope, maybe I get fully functional vision back for christmas xD

All I see is massive systems failure. messy little dwellings, unplanned and scattered about is much more resilient.

When I get my optic nerves back to normal function - honestly, I used to have a 24" UHD, I felt like I was peering off into the distance at the edges of the screen. I'd like something about 20" with relatively flat spectrum QLED or something like this, the most important thing is that it runs at least 144hz, and yes UHD at that resolution, I like to not see pixels, just smooth text.

I can pick AI generated text a mile off. I doubt they will be able to really hide it from me for at least another 20 years.

I remember seeing courses in nanomaterials, stuff with special EM properties and so on, been going on since 20 years. Only people who came up in the last 20 years haven't been actually hearing as much about it, nanomaterials are everywhere now. Quantum dots in LEDs and displays, for example.