Would switching from 3 to 1 second block times also scale the network by 3X? Well, if block size remained the same, you could store more data, but the easy option if we want to scale to process more data

I'm glad someone acknowledged my nerd joke :-)

It will be a big performance change for dapps using HAF, and I hope that before long most new dapps will be written using HAF (the performance benefits are substantial for any dapp that wants to scale).

I hope this short comment will motivate you to supervise the addition of what you wrote about the OBI protocol to the whitepaper I'm actually not one of the main maintainers of the whitepaper, although

I like this change and am curious what type of overhead this has for the p2p network. The overhead on the p2p network is very small: it's one small transaction generated by each of the producing witnesses.

With OBI the same witness can potentially change his vote couple of times per block, so if there is any problem that would be exposed during changed vote, OBI will make it that more likely to actually

Double producing. Whether it is intentional or a problem of misconfigured backup node, using the same or different witness signatures, now it can only happen once per schedule. One block producer double

Note that changed signature can still be a pending change (but already in the state)... hmm... I actually wonder if it isn't a problem today (witness changing signature and producing block signed with

We'll know who produced the block, which would be the most important issue if a block producer was actually trying to break the protocol by allowing a double spend. And, yes, if 3/4 of the block producers

It's already implemented and just waiting further testing, so I hope we can include it, unless we find some unexpected problem. But the code changes were actually quite localized, so I don't expect there

I'm actually a little surprised myself by how substantial have been the gains we've been making on the p2p side lately. We made two simple but big improvements just today that certainly increased the potential

It will improve performance and usability, especially for 2nd layer apps. But one sentence is not a good way to explain most technical things, so best to wait for upcoming post for a full explanation :-)

You can make a mute list and mute the accounts, this will prevent them from showing up in your notifications (or anywhere).

Personally I think 5% upwards variation range for the peg is completely fine, so I don't see any need to lower the fee further. Many "healthy" fiat currencies vary with each within this level

Is The HBD Stabilizer Frontrunning Everyone Else For HIVE to HBD Conversions? No, frontrunning is a different phenomenon that you are conflating with the actual process (which for the most part you describe

Hivemind is a 2nd layer app on Hive that keep track of a lot of "social" data for blogging. Most frontend web sites(hive.blog, peakd, ecency, etc) use Hivemind to get most of the blockchain

test

It's not about upvotes, it's about awareness. Most of us had never heard about this survey until he made this post.

About 90%. There's still one important piece I want to add, which is a smart contract processor optimized to run on top of HAF (this is the new framework for creating scalable Hive apps). But there's already

The long term goal of many of the changes is to make Hive the most attractive blockchain for app development. This means making it very fast, very resilient, easy to develop with, and able to scale with