You are viewing a single comment's thread from:

RE: 2nd update of 2023: Moving to Ubuntu 22, binary storage for hive operations in HAF

in HiveDevslast year

This change lowered the size of a fully populated HAF database by 700GB.

That is a lot and should make running a HAF node more affordable to people.

Work out schedule for creation of various HAF-based applications (most important one here will be a HAF-based smart contract processing engine).

Is this the announcement of the planning of something that might show up in a future announcement?

Tests for massive recurrent transfers to verify it according to relaxed rules to be added at HF28

Speaking of the next hard fork, the fact that it seems the SEC is looking to ban staking on exchanges, it provides an opportunity for Hive to expand the fixed income market. Perhaps having time vaults added in the next HF is a good idea. Get people to lock up their HBD for extended period of times to enable the creation of bond-type systems on layer 2 while also providing more fixed income options on the base layer.

Sort:  
  1. It's basically a task to fill out a roadmap for the work to be done by our team this year (which will be a public roadmap, of course).
  2. The time vault idea is definitely interesting. I'll give it some thought (or maybe @howo will).

also there was a post some weeks ago about the idea of being able to delegate HBD like Hive; the author made some good points:

https://hive.blog/hive-167922/@rubencress/case-study-hbd-savings-delegation

I like the idea of using that for subscriptions. I gave it a little bit of thought and the implementation seems quite easy.

LOL that sounds like the time vault task was just delegated in one sentence.

IMHO time vaults fit another, much wider topic - making "free floating HBD balances". Basically what other coins, especially PoW, have - sending coins to an address rather than account. It is needed for privacy, but at the same time it would enable us to benefit from all the improvements made in the field of different types of signatures, some of which, I believe, enable time locking. Of course there are some downsides - since such balances won't be tied to stake (because it would defeat their purpose), transfers out of them would need to be paying transaction fees (some witness-established RC-to-HBD equivalent) unless signer mixed such transfer with some regular RC paid operation (which would reveal connection to the stake - either fee-less or private, not both). There is a lot of research to be made before we can start doing any coding though.