Bitcoin native internet: BTC-RSK-IPLD based open network layer

General Commons
1

Dear fellow Sovryns,

I hope this letter finds you well. I am writing to initiate a discussion and invite your valuable input regarding the expansion of the Rootstock (RSK) and Bitcoin ecosystems. I would like to present an intriguing concept—a Bitcoin-native InterPlanetary Linked Data (IPLD) based “internet” that integrates hyperexpressive smart contracts, interoperable electronic cash (ecash) protocols, and decentralized cloud computing capabilities. By combining these elements, we have the potential to build a powerful and versatile ecosystem that revolutionizes decentralized computing.

I believe that open collaboration and diverse perspectives are essential in exploring the possibilities of such a groundbreaking endeavor. Therefore, I would greatly appreciate your insights and feedback on the following key elements:

  1. Bitcoin-native IPLD “Internet”: Leveraging the power of IPLD, we can establish a decentralized and secure network that enables seamless data sharing and retrieval across different platforms and protocols. This Bitcoin-native IPLD “internet” could provide a foundation for a wide range of applications, fostering innovation and expanding possibilities within the Rootstock and Bitcoin ecosystems. Notably, IPLD heavily relies on CID (Content Identifier) content identification, empowering users to verify the veracity of any content they interact with or consume, ensuring integrity and trust within the network.
  2. Hyperexpressive Smart Contracts and Decentralized Cloud Computing: Integrating hyperexpressive smart contracts with a proposed decentralized cloud computing module, powered by the IPVM execution layer, opens up new avenues for advanced programmability and automation. The decentralized cloud computing infrastructure utilizes the untapped computational resources of network participants, promoting scalability, privacy, and security. This integration unlocks new possibilities for decentralized application deployment, including decentralized AI and machine learning.
  3. Interoperability and Ecash Protocols: The proposed system supports interoperability between BTC and Rootstock native assets such as DoC and DLLR, facilitating seamless value transfer and financial interactions within the ecosystem. The integration of electronic cash protocols enhances privacy, security, and transaction efficiency on the network.

I firmly believe that the implementation of a Bitcoin-native IPLD “internet” within the Rootstock and Bitcoin ecosystems could reshape decentralized computing and transform the way we interact with the internet. It has the potential to foster an ecosystem of decentralized applications, secure data storage, and efficient financial interactions. The applications are vast, ranging from decentralized document management and secure contract execution to collaborative file systems and decentralized AI.

To further enrich our discussion and provide you with additional insights into the technical aspects and possibilities of this proposal, I have compiled a set of reference materials, which are listed below:

  1. “Overview of WNFS Scope” - Watch from 31:19 to ~39:30: YouTube Link
  2. “UCAN Explanation” - A concise overview of UCAN: YouTube Link
  3. “IPVM Decentralized Cloud Computing Execution Layer” - Information on the IPVM decentralized cloud computing execution layer: YouTube Link
  4. “Filecoin Anchored to BTC” - Paper co-authored by Marko Vukolic about how Filecoin is anchored to BTC: Research Paper Link
  5. “On the Future of Decentralized Computing” - A paper by Marko Vukolic that inspired many of the thoughts and ideas presented in this proposal: Research Paper Link
  6. “Bitcoin Cryptography to counter AI threats” - Interview with Michael Saylor regarding unexplored use cases of the Bitcoin network: YouTube Link

I invite you to share your thoughts, concerns, and ideas regarding this proposal. I value your expertise and believe that an open dialogue can lead us to innovative solutions. Together, we can explore the potential technical implementation, potential collaborations, and the significant benefits this concept can bring to the Rootstock and Bitcoin ecosystems.

Thank you for your time and attention. I eagerly await your response and look forward to engaging in fruitful discussions.

Yours sincerely,

HuluvuBlue

8 Likes
2

This sounds incredible, I will admit that it goes a bit over my head and my mind can’t fully grasp what this would mean or what it would actually look like.
So I hope that more technically minded people can add their expertise and see if and how this can be built, or what would the first steps in doing so be.

Great stuff, I’ll try to dig through the resources you provided in time.

2 Likes
3

This is very cool. I’ll have to dive deeper however to grok it.

3 Likes
4

another great resource providing perhaps the best overall scope of what can be achieved through these methods-
I have linked to a particular part of the video where the lecturer mentions “UCAN channel payments,” a possible solution to transferring digital assets like BTC and DLLR on this new layer:

I have also looked into the new protocol Ark. Kind of an ecash/coinjoin privacy lightning L2; I think you might be able to send and receive VTXOs through these UCAN channel payments (Ark requires you originate a wallet/account with a specific node called an Ark Service Provider)- this could be a custom node that locks up VTXOs and issues UCAN channel assets like DLLR. Perhaps this could be viewed as One-Step-Closer to Bitcoin main chain rather than going through Rootstock PowPeg… it’s probably not, but people might like it more. Burak (founder of Ark) explicitly refers to Ark as a trustless 2 way peg, among other things, in a few interviews I’ve seen.

Basically UCAN Chan is a built in lightning for this layer (still early docs being written) we could lock up Ark vTXOs and issue vDLLR on this layer.

Everything on IPLD is Content-Identified meaning EVERY website or address or connection in this ecosystem is verifiable by the end user. Any “site” native to this system would be easily confirmed to be authentic… i.e. every site on the WNFS or cloud computing execution in the IPVM is essentially a “smart contract” on this layer.

Imagine having a “Sovryn node” that is running BTC core, Rootstock node, Ark service provider (includes lightning), and a BTC native IPLD node that allows users to onboard BTC, take a loan in DLLR and securely interact on the decentralized internet while paying the Node Provide’s d-storage and d-cloud computing fees… Or, if you don’t want to, or don’t have enough BTC to provide liquidity for the Ark/LN node you can just rent out storage or sell your CPU/GPU processing for sats.

It’s be ideal if someone could just download an app on Umbrel or something and start stacking sats running the service…. I’ve spent more than I’d like to admit on AI api key stuff these past 2 months, I bet it would be way more affordable if I could pay the cheapest seller sats to run my dumb queries.

I’m not sure to what degree if at all it really makes a difference if we fork the IPLD or just use the current existing one, we might want a way to confirm or ensure the IPVM executions and things went through an official bitcoin-tethered node but that’s not really the point of open protocols like IPLD; however, it might actually be trivial at this point depending on the node operators willingness to participate (running a node could be a biz opportunity even to little fishes with no massive liquidity stacks.)

If IPLD were to be forked and made Bitcoin-native one would expect a Filecoin analogue to be built on Rootstock; though many of the functions Filecoin performs may be shared with the actual augmented core nodes in the loose framework I have described…

Also Sovryn could build very sophisticated decentralized financial exchange and Financial services interface (on this layer “smart contracts”look and operate more like traditional web ui) with a verified auditable engine being run by these IPLD nodes (the IPVM portion) - i think people might like the sound of a decentralized Bitocin bank and futures exchange that’s run with computational power and data infrastructure provided by essentially Bitcoin nodes.

6 Likes
5

Webnative File System demo (only works with metamask or wallet that supports EIP5630 encryption addition)
https://ipsatoshi.cloud/

Screenshot 2023-08-03 at 7.43.01 PM
Screenshot 2023-08-03 at 7.43.01 PM3304×824 212 KB

this allows you to upload photos to IPFS as well as save ENCRYPTED photos that can only be decrypted by your private keys.

3 Likes
6

This is very cool! Please correct me if I am wrong, but using this one could in theory upload sensitive information that is stored in a decentralized way but other people can’t view its content?

By the way, always love your posts, very informative!

1 Like
7

exactly, the UCAN protocol will be implemented to enable the sharing of the private files. They are also working on Conflict-Free Replicated Data types (CRDTs) that allow for things like file WRITE sharing (think apple icloud “notes” that immediately propagate to all your devices or a collaborative Figma Figjam etc.)

  • the real interesting part though is linked in the github -the new Interplanetary Consensus “Heirarchical Consensus” protocol - IPC “subnets” can allow modular scaling allowing for variable consensus and block frequency i.e. every individual app (or series of specific contracts within it) can have it’s own subnet (think rollup.) We deploy make a secure verifiable “parent” subnet that allows for trivial additions of new “child” subnets. This is equivalent to Drivechain for EVM chains, it keeps all new risk assumptions isolated in the subnet as to not negatively affect the mainchain. We can have essentially pluggable rollups; your new futures exchange needs 1 second blocks? deploy a 1 second block subnet. You need some weird consensus algorithm for some niche use case? make some weird consensus subnet… you need to have some privacy layer obscuring the peg-ups of more ephemeral channel payment tokens? Roll out a specialized subnet.
2 Likes
8

Wow, this is very interesting!
I imagine the application and use cases something like that could have are almost endless. I am by no means a technical person so I have no idea on how easy or difficult would be to deploy. But looking at it from implementations… seems like it would be a great unlock for more use cases!

1 Like
9

I like the sound of that. Any updates on this?

1 Like