John Cantrell johncantrell97

Horizontally scalable networking layer with LDK

I am investigating the best way to implement a stateless networking layer daemon for an LDK-based node. It seems at a high-level the two main options are to either do it at the byte level or event/msg level. The byte level has the benefit mentioned in the docs that it does not require the node to trust the networking daemon. The event/msg level solution has the benefit that the decryption and deserialization of the raw bytes can happen on the scalable proxy, further reducing the load on the singleton node.

For the purposes of this doc I am only focused on the event/msg level solution because I am trying to off-load as much work as possible to a daemon that can be scaled horizontally.

LDK Networking Proxy Daemon

Runs a standard PeerManager with lightning-net-tokio.

Hello again.

Today I am announcing a project I have been working on to help those on the Hunt for Satoshi's Treasure. Watching the first few teams of Hunters develop I saw the same discussions happening over and over again.

The first question on everyone's mind was how are we going to fairly distribute the prize money if we win? It seems like one of the most obvious ways would be to just distribute the prize equally between all 400 keys. The main problem with this approach is that many team members will likely contribute to the discovery of a single key. The other potential issue is that some keys are easier to find than others and you might want to weight them differently.

The next question I often heard discussed was what about people who contribute to the teams in ways that are not directly related to finding a specific key? There are so many different ways someone can contribute to a team. What if someone helps recruit an amazing hacker or the person who lives in that missing geographic region?

Hello again.

I was not the first to find the key this time, props to EnigmaZer0 for this one! After seeing that everyone enjoyed understanding how the first clues were solved I thought I'd provide an explanation for The Leporine Key.

The second clue dropped early afternoon EDT on (easter) Sunday April 21 2019. The clue can be viewed on the satoshis treasure website here and looked like this:


 _____       _            _     _ _       _____
/  ___|     | |          | |   (_| )     |_   _|

Today (April 16th 2019 at noon) the first major clues to discover key #1 was set to be released in a few cities. A QR code with the words 'orbital' were found at these locations and looked like this: (https://imgur.com/a/6rNmz7T). If you read the QR code with your phone you will be directed to this url: https://satoshistreasure.xyz/k1

At this URL you are prompted to input a passphrase to decrypt the first shard. An obvious first guess was to try the word 'orbital' from the QR code. Not suprisingly this worked! This reveals a congratulations page and presents the first key shard:

ST-0001-a36e904f9431ff6b18079881a20af2b3403b86b4a6bace5f3a6a47e945b95cce937c415bedaad6c86bb86b59f0b1d137442537a8.

Now, we were supposed to wait until April 17th to get clues from the other cities for keys #2 and #3 but that wouldn't stop me from digging around with all the new information we had. All that time "playing" notpron (http://notpron.org/notpron/) years ago was going to help me here.

The first thing I noticed was

	let copyPrismaSchema = {
	name: "copy-prisma-schema",
	setup(build) {
	build.onEnd((result) => {
	const fs = require("fs");
	const source = `${__dirname}/prisma/schema.prisma`;
	const destination = build.initialOptions.outfile.replace(
	"index.js",
	"schema.prisma"
	);