Recently, I've been revisiting IPfs, and it's clear that it has faced significant challenges since my last encounter with it several years ago. Most pinning services are either slow, inactive, or very expensive. This happens because there's not enough real incentive for pinning files, and even Filecoin, its incentive shitcoin layer, seems inactive.

I know there is Nostr, but i also think it is not a true peer-to-peer network. Nostr's relays don't talk directly to each other, and it's quite complex. While Nostr has its place as a general-purpose backend, for all the other web5 applications that don't need a backend (or have their own p2p backend) the Nostr protocol is way overkill.

So, I wondered if Bitcoin could be a solution to these problems. The answer is Maybe.

Could we develop a Bitcoin-incentivized solution similar to BitTorrent? I think the answer is yes.

Considering this, I propose exploring a method for sending static content P2P over any UDP socket (like the holepunch.to stack) and allowing web apps to implement their connection logic independently (whether it's with Nostr, another P2P service, or a backend elsewhere).

(Note: I'll call peers clients and servers when they act as clients or servers, for simplicity, even though there's no strict client or server being it a p2p system.)

General idea

Every file (page, media, etc.) is split into fixed-size blocks, with the hash of each block saved in a header, the client knows the header beforehand from a resolving system (eg. a dns like solution).

When a client wants a file, it connects to a group of servers claiming to have the file (with something like torrent's trackers or hyperswarm).

The client requests a block from a random server, checks it against the hash, and if it's valid, adds it to a sparse file. The client then sends a tip in Bitcoin-denominated ecash (using the cashu protocol) to the server. The server can claim it right away from the client's mint or store it temporarily for a batch claim later.

What if the server cheats?

If the server sends a bad block or ignores the client, the client won't pay, disconnects, moves the server to the bottom of the list, and connects to another one. Ideally it will detect the cheating right after the block is verified, so it can redownload the block from another peer and continue.

What if the client cheats?

If the client doesn't pay or sends invalid ecash, the server kicks it, losing the reward (that will amount to one or few blocks, depending on how often the reward is claimed, so just few sats supposedly) .

So, what will stop the client from cheating again with another (or even the same) server? Proof of Work. Before the blocks can be requested, the server asks the client to solve a PoW challenge. If the client solves it, the server authorizes communication until cheating is detected. If the client cheats, it is kicked and the Proof of Work invalidated. If the client detects too many unjustified PoW challenge requests from the same server it will assume it is either a bad actor or malfunctioning and will treat it as a cheater (see point above). The server can adjust the challenge difficulty with the fee it requests per block.. In this way the client is forced to chose between paying a bit of his stored energy (bitcoin) or waste a larger amount of energy to solve a new PoW challenge.

Why not Lightning?

The files are split in several small blocks and it would cause the streaming of many Lightning invoices that could strain nodes. Ecash transactions are fully offline and can happen on the same P2P UDP socket, they can be used to group the rewards and then request the mint to pay a single larger lightning invoice.

Conclusion

This isn't everything; there's more to consider. How should this be implemented so that you can just open a page in your browser as normal and get all the p2p stuff sorted under the hood? (ie like the ipfs browser extension) What if the client's mint cheat? What about P2P DNS? I have ideas for those, but they're beyond this post's scope. I'd like to hear your thoughts on this idea for now.

And I am well aware that i am not inventing anything new here, but combining known ideas often leads to simple and effective solutions.

If you help me figure out the weaknesses and merits of this approach, if it is worth an attempt, I will put it in the TODO list and build it for everyone (day job permitting).

110 sats \ 0 replies \ @CruncherDefi 8 Jan freebie

I like the client-cheating part and this idea could live on its own.

To summarise: "To get a resource from server client needs to play x amount of bitcoin (reusable POW) or spend energy on 2x amount of POW".

This might be a good bridge between old 'unbitcoinized interned' and new 'bitcoinized internet'. Participants are economically incentivized to switch to bitcoin solution, but non-bitcoinized internet also can access the resource.

It worst it protects the server from DOS attack, at best the server earns some money on its services.

100 sats \ 0 replies \ @justin_shocknet 8 Jan

This idea gets revisited constantly, everyone seems to want to connect the dots with bitcoin (and a lot of shitcoins) and p2p file hosting... and it's been tried countless times as a result. It always ends the same way because everyone seems to overlook the same things.

It's also surprising how often IPFS still comes up despite the pile of bodies of devs who tried to do anything useful with it.

The first major problem is simply the way the physical internet is architected around the limitations of time and space. Datacenters and centralized hosting providers exist for a number of reasons.

In the case of active files, those that do not live in low-latency datacenters in relative geo-proximity to their clients are useless for most purposes. If a video or other file doesn't load in less than a second or so, users bounce, apps break, and the potential cost savings as negligible as it is never gets realized.

These are just some of the reasons DHT based protocols like IPFS, Hypercore etc, are dead in the water. DHT's don't scale and are too slow for anything useful. Torrents which tried going DHT ages ago still fall back to web-based trackers. DHT is a failed experiment in this context.

Keep in mind what problem you're actually trying to solve. Censorship resistance and redundancy? These aren't serious concerns in the status quo because there are so many competing providers. We already have an efficient market. If Alex Jones and the State of Iran have a robust web-presence, then adding p2p overhead isn't really accomplishing anything.

Decentralized archive storage, while doable at the edges due to relative indifference towards latency, doesn't benefit from a cost savings vs. the scale of the existing providers. Torrents are hard to beat here already for long term redundancy, they enforce the original file via a hash and a single torrent can be hosted by countless mirrors.

Multiple file-hosts, paid for with Lightning, wrapped in a single WebTorrent (which uses HTTP for streaming grade performance) can be used without a p2p Rube Goldberg machine. Just pick a few hosts, and pay them directly. This is how Lightning.Video operates, and our seeding service that spits out WebTorrent metadata is opensource on Github.

DNS: I have spent a lot of time thinking about decentralized DNS and drafting systems for it, but the result is always the same, it's not a real problem (see examples above). Additionally, anything built to replace DNS ultimately still needs to bootstrap off DNS at multiple points, just because of the way the internet works.

What people are really seeking are key-based aliases (see the proliferation of NIP-05 and Lightning Addresses). Aliases however are invariably a web-of-trust "pet name" association that can't be truly arbitrated. Enforcing a cost and uniqueness creates friction that mitigates any other advantages since it'll never gain significant traction to create a network-effect.

Where there's no source of truth for names in reality, it's a fools errand to emulate one technically. Who you think of when someone says "Bob" isn't necessarily the same as who my social network thinks "Bob" is. When we type in "Bob" the pubkey we expect to return will differ, yet neither is wrong nor correct. The problem is in who YouTube says Bob is, and that gatekeeping. The only solution to this is a decentralized reputation system that incorporates pet names, that's something I'm looking to draft into a nostr middleware.