The issue with cyberspace being so exceedingly huge is that avatars could spawn in and fly around their entire lives without ever encountering another person. This is quite discouraging, and although it does accurately reflect the vastness of our own universe, it does not make for an engaging or useful digital space.
Therefore, I devised a way to make use of bitcoin's proof-of-work in cyberspace.
One of the core tenets of cyberspace is that everything must have a thermodynamic cost. Bitcoin is backed by the most significant output of thermodynamic energy of any computer system. This thermodynamic expenditure has the effect of securing the bitcoin network, which is effectively a payment to the universe for the benefit of bitcoin's users.
My idea is this: the hash of each bitcoin block can be interpreted as a cyberspace coordinate. Each block can be thought of as a hyperspace railway. Since the block hash is random and cannot be known it advance, it is unknown where this railway through cyberspace will eventually travel. But it will travel randomly and fairly across cyberspace, adding a new stop every 10 minutes, and avatars can use it to instantly jump from one block to the next block for a minor POW expenditure of their own, like buying a ticket to ride an already constructed subway train. In this way, the POW expended for bitcoin's sake directly benefits cyberspace users by providing POW-back transportation infrastructure around cyberspace. This is also good because it gives users a highway to build around and a focus to travel around. Without this unifying golden highway through cyberspace, everything would be lost in a near-endless void.
While the primary purpose of cyberspace is to create physical constraints on digital space, the massive thermodynamic expenditure of bitcoin creates a totally fair and unpredictable, immutable pathway through the cyberspace coordinate system. I therefore believe that while traveling across the timechain does provide significant relief from the constraints cyberspace was invented to enforce, it also creates a dynamic and accessible way for users of cyberspace to travel vast distances that might otherwise be barriers between them and the meaningful connections I hope cyberspace can create.
#bitcoin #cyberspace #pow #timechain #hyperspace
Excerpt from:
quoting
naddr1qq…67e8
During the last 90 days I have made significant headway in identifying practical problems in the protocol and devising solutions to them.
Issues Identified (and Some Solved)
Mining Cyberspace Actions with ASICs
Mining cyberspace actions with SHA256 mining hardware will not be possible unless custom mining software can be written. This isn’t currently something within my capabilities, but luckily it isn’t necessary to the completion of the protocol, nor ONOSENDAI.
The reason that ASICs can’t be used as-is to mine cyberspace actions is because of the very bitcoin-specific data that the ASIC expects to receive from Stratum and how it handles that data.
As far as I can tell, nostr events do not fit the format nor size constraints the ASIC expects, and furthermore the ASIC is designed to double-SHA256 a block header. We can only do a single SHA256 on a nostr event or it won’t be valid. So a rewrite or custom ASIC software would be needed.
However, it appears that Stratum and Stratum v2 would be able to send the nostr event data to an ASIC just fine. Once custom mining software is developed, Stratum will be able to coordinate mining.
Cyberspace’s Scale and Computer Systems
The scale of cyberspace is massive, and it may not be possible to load all of cyberspace at once in any modern programming language. The solution to this was to divide cyberspace into sectors such that sectors may be loaded into memory as chunks and displayed within most computer graphics systems.
A sector is 2^30 along each axis. This number was chosen because almost all modern programming languages support int32 number types at a minimum. A sector’s coordinate system of 2^30 fits within int32, allowing any programming language to load at least 1 sector at a time and display it in a graphics system. If a given system supports larger values, it could load and display multiple adjacent sectors at a time.
Although 2^30 is a large number, cyberspace is 2^85 along each axis, meaning there are 2^55 sectors per axis.
A sector id system was developed. Simply, the sector id is a string of
"xid-yid-zid"where each element is the 0-based index of the sector along the given axis.Querying Cyberspace via Nostr Protocol
It was discovered that while partial queries are supported for authors and event ids, nostr does not support partial queries on tags. Since the cyberspace coordinate of a given cyberspace object was stored in the “C” tag, I had to rethink how one would go about querying nearby objects.
Now with sectors as a cyberspace primitive, I created the new “S” tag. Every cyberspace action and object should have an “S” tag where it’s value is the sector id as described above. This allows anyone to query a relay for a specific sector id and receive all actions and objects within that sector.
Note that the cyberspace coordinate tag is still necessary because it can be used to query the genesis of a given avatar’s action chain by querying for a “C” tag matching the user’s hexadecimal pubkey.
Downscaling Does Not Work
It was discovered while testing, and I am embarrassed to say it, that the downscaling method I was using before does not work as I had imagined. To render all of cyberspace, I simply divided every coordinate by a factor of 2^35. This was to make sure that every coordinate fit within JavaScript’s Number type so objects could be rendered via Three.js. This isn’t a protocol-level thing, but rather just a fix for displaying huge coordinates in ONOSENDAI.
Well, I realized that if I divide every coordinate by 2^35, then any objects within 2^35 would be merged to a single point, and I would have to travel 2^35 to travel 1 point in ONOSENDAI. This should have been obvious to me before but I didn’t realize it until I was testing action chains and acceleration and discovered that although I was accelerating, I was not visibly moving. This was because I was moving less than 2^35 along any given axis.
The solution to this is sectors and rendering each point 1:1.
Decay Constant
While testing action chains and how fast I could travel, I discovered that the default velocity decay constant of 0.999 was too restrictive. With this constant, I was severely limited by what maximum velocity I could attain with my CPU’s proof-of-work capacity. However, by increasing this decay constant to 0.999999 I was able to attain much, much higher velocities with the same amount of POW. To date, I am still not sure exactly what decay constant makes sense for cyberspace.
The idea behind having a decay constant is that your POW spent for acceleration should not yield infinite velocity. Although outer space doesn’t really have drag, it seems appropriate that eventually someone’s velocity would decay and come to a stop if left alone. Likewise, it is convenient to have some stopping force to help you attenuate your movement.
However, there are other problems with having a fractional decay constant. When creating an action chain, the decay constant can yield very long fractions which clutter the underlying nostr event and serve no real purpose, but to ensure one’s verification of an action chain is correct these large decimals would have to be taken into account for verification calculations. This is not ideal. I would prefer to limit velocity to a fixed number of decimal places, say 6, and floor all calculations to this. This rule would have to be universally enforced so that everyone comes up with the same result when both creating and verifying action chains.
I considered having no decimals for velocity, but this would create very jittery and uneven movement through cyberspace. I don’t know if this is a viable or reasonable option, even though it makes the math much simpler.
I am still working on a solution to this problem.
D-Space Speed
After trying out action chains in my latest dev version of ONESENADI I discovered that the scale of cyberspace is indeed a problem to contend with. On a gaming laptop, my CPU could only manage a speed that would deliver me from one end of cyberspace to the other side in 3,000 years. However, after doing some calculations, I found that a standard S9 ASIC, if fitted with software to mine cyberspace actions, could get you from one end of cyberspace to the other in only 300 days. And if Marathon Digital Holdings devoted their 23 Exahash to cyberspace actions, they could travel from one end of cyberspace to the other in only ~15 seconds.
Here is a Jupyter notebook with my calculations: https://github.com/arkin0x/cyberspace/blob/master/d-space%20acceleration.ipynb
One of the main questions I was seeking to answer is how quickly can one move in reality (d-space) via the cyberspace protocol?
My estimations show that 1 terahash per second yields roughly 1 kilometer per hour in d-space movement. I find this relationship to be exceedingly elegant, especially since it was discovered and not planned.
Essentially, however many terahash you apply to your cyberspace movement, you can move that many kilometers per hour in d-space.
Timechain Hyperspace
The issue with cyberspace being so exceedingly huge is that avatars could spawn in and fly around their entire lives without ever encountering another person. This is quite discouraging, and although it does accurately reflect the vastness of our own universe, it does not make for an engaging or useful digital space.
Therefore, I devised a way to make use of bitcoin’s proof-of-work in cyberspace.
One of the core tenets of cyberspace is that everything must have a thermodynamic cost. Bitcoin is backed by the most significant output of thermodynamic energy of any computer system. This thermodynamic expenditure has the effect of securing the bitcoin network, which is effectively a payment to the universe for the benefit of bitcoin’s users.
My idea is this: the hash of each bitcoin block can be interpreted as a cyberspace coordinate. Each block can be thought of as a hyperspace railway. Since the block hash is random and cannot be known it advance, it is unknown where this railway through cyberspace will eventually travel. But it will travel randomly and fairly across cyberspace, adding a new stop every 10 minutes, and avatars can use it to instantly jump from one block to the next block for a minor POW expenditure of their own, like buying a ticket to ride an already constructed subway train. In this way, the POW expended for bitcoin’s sake directly benefits cyberspace users by providing POW-back transportation infrastructure around cyberspace. This is also good because it gives users a highway to build around and a focus to travel around. Without this unifying golden highway through cyberspace, everything would be lost in a near-endless void.
While the primary purpose of cyberspace is to create physical constraints on digital space, the massive thermodynamic expenditure of bitcoin creates a totally fair and unpredictable, immutable pathway through the cyberspace coordinate system. I therefore believe that while traveling across the timechain does provide significant relief from the constraints cyberspace was invented to enforce, it also creates a dynamic and accessible way for users of cyberspace to travel vast distances that might otherwise be barriers between them and the meaningful connections I hope cyberspace can create.
ONOSENDAI Progress
I am busy with developing the thermodynamically enabled version of ONOSENDAI. My first goal is to have cyberspace-protocol-compliant thermodynamic movement working ASAP. Currently, one can move but the chains are not fully valid. It is exciting to see that the action chains work though, and the validation problem will be ironed out as these other issues mentioned above are solved. One significant detour is that I need to implement sectors fully before I continue with action chain movement. However, overcoming each of the above issues is only making the cyberspace meta-protocol stronger and more robust while remaining simple and easy to implement, just like nostr.
I still feel that I am on track to complete my grant scope of work over the next 6 months.
Cyberspace Adoption and Interest
Interest and adoption of cyberspace has been increasing. Here is a brief look:
- The ONOSENDAI telegram group now has 110+ members
- I am leading an effort to add web-worker/threaded (highly efficient) proof-of-work to Pablo’s NDK library so doing NIP-13 proof-of-work on any nostr event will be trivially easy for devs to implement: https://github.com/nostr-dev-kit/ndk/pull/196
- 42Pupusas has released an open source version of Minecraft built on the cyberspace meta-protocol: https://github.com/42Pupusas/nostrcraft
- I have begin developing a game that utilizes cyberspace objects as resource layers. WIP.
- Other interest in cyberspace has been seen from the Nostr Game Dev community.
- I have been in collaboration with La Crypta on their Nostr-based NOMAD protocol (podcast link) because of its similarity to Substrates in cyberspace. Ultimately, between substrates and NOMAD Validators, we will have functioning smart contracts without a blockchain over nostr.
- I have been invited to speak about cyberspace at multiple events across the world – too many to possibly attend! I spoke at Culture Shock in Phoenix, USA, and I am speaking next at Bit Block Boom in Dallas, USA.
Summary
It feels like cyberspace is just getting started! I am very optimistic as I see the sound fundamental ideas of cyberspace spreading through our nostr and bitcoin communities. If a metaverse is going to exist at all, it will be cyberspace, built by bitcoiners on sound principles of thermodynamic and permissionless systems.
Resources
Culture Shock talk: The Dawn of Cyberspace https://fountain.fm/episode/gIx0WDvF1jzlnKdtULoz (it’s a banger)
ONOSENDAI Telegram Group: https://t.me/ONOSENDAITECH Yondar Telegram Group: https://t.me/yondarme Cyberspace Meta-Protocol specification: https://github.com/arkin0x/cyberspace ONOSENDAI repo - refactor branch: https://github.com/arkin0x/ONOSENDAI/tree/vite-reactjs-refactor ONOSENDAI Construct Miner repo: https://github.com/arkin0x/construct-miner Yondar repo: https://github.com/innovatario/yondar-mono ONOSENDAI: https://onosendai.tech Yondar: https://go.yondar.me Me: https://njump.me/npub1arkn0xxxll4llgy9qxkrncn3vc4l69s0dz8ef3zadykcwe7ax3dqrrh43w
