theocs

Even if all PoW energy came from renewable sources, it's extremely wasteful and I'm sure we could have used that energy on something more productive.

That's not to say the allocation mechanism in PoW isn't interesting, but that's not really good enough in itself.

I've been experimenting with energy limited PoW, something called NuPoW [1], that reduces the reward if too much energy is collectively used. But this only works if you outsource the security to an underlying chain.

[1] https://nupow.fi/whitepaper/

They trade a token, sometimes called a stablecoin, that represent BTC as its underlying value.

Primarily two extremes for how this is done: Centralized, like WBTC (https://coinlist.co/help/what-is-wrapped-bitcoin-wbtc), and decentralized, like tBTC (https://defirate.com/tbtc/)

I think the wrapped BTCs, especially the decentralized approaches to it, are clever links that allow for the transfer of BTC value over to the Ethereum ecosystem.

It's a way of selling BTC for other tokens, extracting and removing its value over time, and instead investing it into DeFi and similar.

Or I just right click open it in private mode

Given that these tokens follow the ERC 20 standard, I don't see why other clients can't just integrate support if they want.

Any feedback welcome! And if you have questions happy to answer and it will help guide me towards what blog posts to focus on next :)

If you want to build a REPL in the browser I'd highly recommend checking out replumb

https://github.com/ScalaConsultants/replumb

You're right about the underlying JS API being async, and that's why those functions are as well.

I wouldn't mind adding a blocking variant of these functions, and use async internally to make that happen. But, not there yet.

Glad you like it :)

You can bind to arbitrary data regions using named items. For example:

cljs.user=> (add-binding-named-item "A1:B2" "binding-id" println)

nil

{:rc 2, :cc 2, :type matrix, :id binding-id}

cljs.user=> (get-binding-data "binding-id" println)

nil

{:rc 2, :cc 2, :type matrix, :id binding-id, :data [[1 2] [3 4]]}

cljs.user=> (set-binding-data! "binding-id" [[2 3] [4 5]])

autobot

This is very technical, most likely way past what 99% of developers both need to care about and have to care about.

Given that most developers work at best with embarrassingly parallel problems they wouldn't need to know much of these details.

But if you're up for it: It's a very rewarding feeling when you're both allowed to figure these things out and someone are also paying you while you figure it out.

Maybe I'm mistaken about the code, but it doesn't look like HugeCollections is storing the key off heap?

Example: Looking at the containsKey method on line 420 here: https://github.com/OpenHFT/HugeCollections/blob/master/colle...

A return map.containsKey(key2) is used, with that map being declared as

final Map<K, DirectStore> map = new HashMap<K, DirectStore>();

on line 232. That makes me believe maybe only map values are kept off-heap?