Hello,
I'm really sorry about the lack of video, we had recording problems, and couldn’t record the meeting.
Instead I wrote some notes to give you an idea of what was discussed, I'm sorry this is incomplete and we'll switch to @gtg's video solution next so that those issues won't happen again.
Developers sync:
On my end I mostly spent time updating my hivemind pull requests following the hardfork changes and supporting RC delegation questions (many heart attacks of people telling me it doesn’t work when in fact it’s something they did wrong).
Then I started working on implementing a feature request by @brianoflondon for recurrent transfers: https://gitlab.syncad.com/hive/hive/-/issues/382
On @blocktrades side (this is somewhat of a non-exhaustive list and will probably be in greater details in a post of his own):
There was some cleanup work following hard fork 26/27, doing some performance analysis on nodes, to see how things have changed.
Then they pushed a bunch of small changes:
Fixed a problem with shutdowns that could happen sometimes when you did ctrl + c on a node.
Fixes and improvements to the block statistics
Added more RC statistics in the form of daily report, with a new API about it (this will happen in hf 27.1)
New api calls for updated witness scheduling
CLI wallet side, fixed a longstanding bug to allow controlling it from websockets.
Updated our cryptography lib to increase performance (tests ongoing but so far the initial testing shows a 40% increase !)
New block log utility to help manage compressed block logs:
- Comparing compressed block logs to output a checksum even though they were compressed using different methods
- Truncating a compressed block log (previously you had to uncompress, truncate, then re-compress)
Improved get_block_range by forcing it to use http to improve performance due to a websocket issue. The current suspect is that websockets is doing compression which causes slowdowns
Adding a VOP to record successful RC delegation
We talked a bunch about the potential use cases and potential edge cases and issues.
The main discussion revolved around the fact that it’s hard to track if an RC delegation got executed or not (and what was executed). But after some back and forth, we concluded that since the node rejects incorrect transactions, it made sense to let the custom json denote of the change.
Hive version 1.27.1:
We want to ship version 1.27.1 very soon:tm: (aka in a few weeks) to provide improvements to HAF and hivemind. We’ll try to slot in a change to RC delegations to include an RC minimum to prevent spam and improve dev experience.
We’ll try to include at the bug that @engrave brought up: https://gitlab.syncad.com/hive/hive/-/issues/338
There's then a lot of discussions between @arcange and @blocktrades on his specific HAF setup that I don't think are really worth talking about.
Today I'd like to suggest both HP and RC delegations expire after x amount of time by default.
There are several instances of active accounts benefiting from inactive account delegations from years ago. Not cool.
Same thing will happen with RC. Not cool.
That's only one problem I see.
Your thoughts? Anyone else care to chime in?
Hmmm, while I see the use case, we don't like to add time-based event too much because they cause load on the chain. This would be something could be automated through an L2 (for RC, HP requires an active key which is no go).
As for the HP I'm like, why is it a problem ? People are free to do what they wish with their stake, if they wish to delegate then go MIA well it's their choice. It was bad for governance votes because it directly affects things like witness rankings or proposals but for delegations it has a lower impact (if you want to mention people self voting and such, I'd say abuse can be countered with free downvotes or by various initiatives)
I hear you. People are most certainly free to make choices. Until they die or lose their keys. And sure, one could simply downvote. That always goes well...
I appreciate your thoughts on this matter.
Keep up the good work. It's appreciated.
Well the same was done for witness vote to expire if account is not active for kore than one year... so this will be an extension of it
Yes. That's how I imagined it. Wouldn't be hard to renew delegations before the time expires if needed, especially if the frontend somehow highlights which ones need attention. Just requires user input, like voting for witnesses.
Plugs up all the leaks.
From the technical standpoint something that stays up potentially forever is worse than something with definite lifetime (because the former can build up over time). That supports the idea of expiration.
From usability point of view I can see potential problem. Now you can set two accounts - one as cold storage, second as active. You set your active as proxy for cold storage, you delegate all HP from cold to active and you are good to go, never to have to touch the cold storage (well, until renewal of proxy setting once a year).
Back to technical side. It would require additional index on delegation objects, so it is not only pluses in that field.
I think we'd need to see what is average effective lifetime of delegation (with and without weighting it by its power) - maybe it is not such big of a problem after all?
At this point, I just wanted to throw the idea out there and see what people think. Certainly don't want to burden anyone or suggest bogging performance.
I see your potential problem and would counter it by delegating renewal rights from cold to active. Easier said than done. I know...
And I'm not really looking at it like it's a major issue, I just know it could turn into one. There are little pockets everywhere; seemingly forgotten delegations. And even being small I view as a problem because that just adds to the total of wasted resources. Similar to shrinkage, in a sense. Especially problematic in the long run, and if price goes up.
Handing out RC, set it and forget it. Incentive to powerup; set that and forget that too. Not a fan of the free ride.
Any single one of these little 'projects' springing up asking for delegation could stop paying out whenever they feel like it. Meanwhile inactive account doesn't notice for two years, passes away, or loses keys. That little project becomes a parasite, forever. Ill-gotten gains.
Again, I don't want to convince anyone it's a problem that needs an immediate solution. Just something not worth ignoring completely. Unfortunately I don't know a damn thing about what's under the hood of the blockchain. I just drive the damn thing and want it to be running efficiently.
Second.
Thanks, I believe it's worth fixing this long-standing bug with market history API. We have an API to serve OCHLV data to create candlestick charts for the internal market and we can't use it because it's broken. It would be great to see such data together with market depth chart.
Nice to see an update! RC delgation seems to be working fine for me, however RC cost for account creation token apparently is the same as pre-hardfork. Does it work as intended?
Eh, I kept looking for the source of the rumor about the increase in RC cost of account tokens, but have not found it...
Yes, working as intended. The parameters that govern account token pool are set directly by witnesses. That was enough reason to make sure other RC changes don't affect it. Besides account tokens are already outrageously expensive and they swing in price by 30% on daily basis (due to pool being almost dry all the time). Not much room to make them even more costly IMHO.
Refer to this article for comprehensive description of all RC changes.
I'm not sure if this was changed with the various transaction adjustments, @blocktrades do you know ?
Who is @arcage? Were none of his questions worthy of interest?
I find it unfortunate that you limit the content of your meeting report according to your personal opinion.
Sorry, given that they were highly specific to your use cases (like the conversation on your HAF setup) it was hard to follow and take notes on it so I couldn't include it. But feel free to write something as a reply to this comment, I'll gladly edit the post to include them.
Hi @howo , want to ask you, what is going on with the ExxP project? It seems like it is dead, almost 2 years no update at all???
Do you plan to update and to maintain this project? Or what is happening there?
Because, the plugin is not working almost at all, and there are many errors and conflicts with most other things in WP.
Can you please give us an update on this?
I would like to see this project updated, because, it works great and it has great potential to be one of the best there.
~~~ embed:1589978677567434752 twitter metadata:MTQ1OTQ5NDgxNTk2ODYyMDU0OHx8aHR0cHM6Ly90d2l0dGVyLmNvbS8xNDU5NDk0ODE1OTY4NjIwNTQ4L3N0YXR1cy8xNTg5OTc4Njc3NTY3NDM0NzUyfA== ~~~
The rewards earned on this comment will go directly to the people( @michupa, @steemadi, @wilsonthe ) sharing the post on Twitter as long as they are registered with @poshtoken. Sign up at https://hiveposh.com.
You are forgiven, it is not really your fault.
I'm really sorry about the lack of video, we had recording problems, and couldn’t record the meeting.
This is a good evolve, there will definitely be an extension.
I was asking to add who sold and who bought as a 3rd line below the price and bought/sold on the right, but they said the api didn't provide that data and that it was a core issue.
Can you help with this?
https://beta.hivehub.dev/market/limit
Hola amigo, gracias por tú voto y por visitarnos ❤️
Thank you so much for your support of my @v4vapp proposals in the past, my previous one expired this week.
I'd be really happy if you would continue supporting my work by voting on this proposal for the next 6 months:
Additionally you can also help this work with a vote for Brianoflondon's Witness using KeyChain or HiveSigner
If you have used v4v.app I'd really like to hear your feedback, and if you haven't I'd be happy to hear why or whether there are other things you want it to do.