hive issueshttps://gitlab.syncad.com/hive/hive/-/issues2023-12-16T10:48:50Zhttps://gitlab.syncad.com/hive/hive/-/issues/627BLS signatures on Hive? (feature request + research)2023-12-16T10:48:50ZGandalfBLS signatures on Hive? (feature request + research)Lets take a closer look on that. This issue is to gather relevant information.
See: https://hive.blog/vsc/@vsc.network/the-future-of-multisigs-and-cryptography-on-hiveLets take a closer look on that. This issue is to gather relevant information.
See: https://hive.blog/vsc/@vsc.network/the-future-of-multisigs-and-cryptography-on-hivehttps://gitlab.syncad.com/hive/hive/-/issues/609Use full voting power instead of current mana for voting in order to stabiliz...2023-12-08T11:39:09ZAndrzej LisakUse full voting power instead of current mana for voting in order to stabilize use of upvote mana.Full description of the issue in [this Hive post](https://hive.blog/hive-139531/@miosha/request-quality-of-life-change).
Long story short: the problem stems from the fact that upvotes use `current_mana` when determining amount of mana t...Full description of the issue in [this Hive post](https://hive.blog/hive-139531/@miosha/request-quality-of-life-change).
Long story short: the problem stems from the fact that upvotes use `current_mana` when determining amount of mana to use (and therefore power of the vote). Current mana changes with each vote, which makes consecutive votes of the same weight weaker. That in effect makes "deep portion" of the mana unusable and skews power of votes away from curator's intention. The trivial fix is to use full power (determined only by stake) as base for mana used for vote, of course starting with HF28. Other than fixing problems of current code, the most noteworthy consequence of the change is that users will be able to use all their voting mana (down to zero), and that "50 full power votes in 5 day recharge window" will finally be true.HF-28Andrzej LisakAndrzej Lisakhttps://gitlab.syncad.com/hive/hive/-/issues/544refacxctor database_api to reduce redundancy2023-07-10T11:32:07ZKrzysztof Mochockikmochocki@syncad.comrefacxctor database_api to reduce redundancysearching for phrase ` && args.limit <= ` reveals that limit check is compeletly redundant and i think it should be moved to separate funtion.
Here i paste whole line that is redundant:
`FC_ASSERT( 0 < args.limit && args.limit <= DATAB...searching for phrase ` && args.limit <= ` reveals that limit check is compeletly redundant and i think it should be moved to separate funtion.
Here i paste whole line that is redundant:
`FC_ASSERT( 0 < args.limit && args.limit <= DATABASE_API_SINGLE_QUERY_LIMIT, "limit not set or too big" );`https://gitlab.syncad.com/hive/hive/-/issues/207Allow account broadcasting transactions with authority to pay RC cost2021-12-03T20:05:13ZSergioAllow account broadcasting transactions with authority to pay RC costEvaluate if it would be possible to allow an account broadcasting a transaction using the posting/active authority on behalf of another account to OPTIONALLY pay for the RC cost of the transaction?
Maybe using the `extensions` field to s...Evaluate if it would be possible to allow an account broadcasting a transaction using the posting/active authority on behalf of another account to OPTIONALLY pay for the RC cost of the transaction?
Maybe using the `extensions` field to specify that the account signing the transaction is also willing to pay the RC cost? Default behavior will be the current one but with this additional option.
And this should only work when the signature is from the account with the posting/active authority.
Part of the discussion on the chat after sharing this idea:
![image](/uploads/1eccff28a2da4dcea7f9277aa47a0c7d/image.png)
![image](/uploads/8bea5098773dee349200c9566e63a5ed/image.png)https://gitlab.syncad.com/hive/hive/-/issues/205Advanced benchmark for RC evaluation2022-07-28T18:08:18ZGandalfAdvanced benchmark for RC evaluationWe need to gather through analysis of resource usage to be able to evaluate current Resource Credit system and for the sake of its future improvements.
I'm using `2c31840a22ff52d430f648a42ba9aa2dd89b6b5a` as to run it per @ABW request
...We need to gather through analysis of resource usage to be able to evaluate current Resource Credit system and for the sake of its future improvements.
I'm using `2c31840a22ff52d430f648a42ba9aa2dd89b6b5a` as to run it per @ABW request
`config.ini` file used:
```
log-appender = {"appender":"stderr","stream":"std_error"} {"appender":"p2p","file":"logs/p2p/p2p.log"}
log-logger = {"name":"default","level":"info","appender":"stderr"} {"name":"p2p","level":"warn","appender":"p2p"}
plugin = block_api
shared-file-dir = "/run/hive"
shared-file-size = 24G
flush-state-interval = 0
```
command line:
`/home/hive/bin/hived-2c31840a22ff52d430f648a42ba9aa2dd89b6b5a --force-replay --validate-during-replay --advanced-benchmark --dump-memory-details --set-benchmark-interval 100000`
Hardware used:<br>
`Intel(R) Xeon(R) CPU E3-1245 V2 @ 3.40GHz`<br>
32GB RAM, DDR3, ECC 4x 8GB Kingston<br>
2x480GB Intel SSD DC S3510 (software raid0)<br>
OS: Ubuntu 18.04 LTS<br>GandalfGandalfhttps://gitlab.syncad.com/hive/hive/-/issues/198We need more intel about what's going on with blocks / transactions / operati...2021-11-16T13:36:42ZGandalfWe need more intel about what's going on with blocks / transactions / operations / mempoolThat would help with getting a better view on situations like this:
```
2021-11-15T14:45:20.680239 block_producer.cpp:178 apply_pending_transa ] Postponed 206 transactions due to block size limit
2021-11-15T14:45:20.735940 p2p_plu...That would help with getting a better view on situations like this:
```
2021-11-15T14:45:20.680239 block_producer.cpp:178 apply_pending_transa ] Postponed 206 transactions due to block size limit
2021-11-15T14:45:20.735940 p2p_plugin.cpp:704 broadcast_block ] Broadcasting block #59199619
2021-11-15T14:45:20.737028 witness_plugin.cpp:344 block_production_loo ] Generated block #59199619 with timestamp 2021-11-15T14:45:21 at time 2021-11-15T14:45:21
```
Currently in "live sync" we see informations like this:
```
2021-11-16T12:56:06.013 p2p_plugin.cpp:187 handle_block ] Got 200 transactions on block 59226170 by gtg -- Block Time Offset: 13 ms
```
Would be great to have a better info on:
- number of transactions
- number of operations
- size of block in bytes
- with some extra switch even more data on mempool
also `--set-benchmark-interval` could be extended to provide statistical information on data processed within given interval:
- avg block size
- max block size
- number of transactions
- number of operations
Some of that info we have because of periodic RocksDB reports (if `account_history_rocksdb` plugin is enabled), some are logged during `hive sync`, still having that available at seed nodes could help with ad-hoc State-of-Hive analysis.https://gitlab.syncad.com/hive/hive/-/issues/170[cli_wallet] allow to send transactions nonblocking way2021-09-12T13:07:34ZMarcin Sobczyk[cli_wallet] allow to send transactions nonblocking wayCurrently when sending transaction using cli_wallet we usually need to wait for next block available on connected node. This means wallet is blocked for circa 3 seconds. There are few exceptions, like:
- transfer_nonblocking
- d...Currently when sending transaction using cli_wallet we usually need to wait for next block available on connected node. This means wallet is blocked for circa 3 seconds. There are few exceptions, like:
- transfer_nonblocking
- delegate_vesting_shares_nonblocking
- claim_account_creation_nonblocking
This proposal is about adding nonblocking mode/version to all kind of transactions. Event if there are any obstacles why this is hard task - then it would be nice to have it documented as an issue on gitlab.https://gitlab.syncad.com/hive/hive/-/issues/168[cli_wallet] Add support for http/https connections2022-08-18T16:15:54ZGandalf[cli_wallet] Add support for http/https connectionsCurrently `cli_wallet` supports only websocket connections which is fine for local wallet<->node, but it requires cli_wallet user to have their own working node which is not trivial when it comes to requirements and setup time.
Of course...Currently `cli_wallet` supports only websocket connections which is fine for local wallet<->node, but it requires cli_wallet user to have their own working node which is not trivial when it comes to requirements and setup time.
Of course, there are public nodes such as `api.hive.blog` or `api.openhive.network`, etc. but those rarely support direct websocket connection to `hived`. Workaround is to use websocket->http(s) bridge locally or on server-side (such as `lineman`)
<br><br><br>It should work like this:
`cli-wallet -shttps://api.hive.blog`<br>
(Currently it only accepts `-sws://` and `-swss://`)Mateusz TyszczakMateusz Tyszczakhttps://gitlab.syncad.com/hive/hive/-/issues/167[cli_wallet] Support, Maintenance and Development Meta-issue2022-11-24T11:30:39ZGandalf[cli_wallet] Support, Maintenance and Development Meta-issueThis is a meta-issue for cli_wallet that's meant to coordinate work on this useful tool.
<sup>I'm having some deja-vu here, because I already posted similar issue, before The Metadata Oblivion Incident.</sup>
> This piece of software n...This is a meta-issue for cli_wallet that's meant to coordinate work on this useful tool.
<sup>I'm having some deja-vu here, because I already posted similar issue, before The Metadata Oblivion Incident.</sup>
> This piece of software needs more love. For many users, it’s the only software that will ever have access to their privileged keys (Active, Owner). It’s what exchanges, whales, and smart people rely on to sign their transactions.
- [x] #92 Eliminate legacy operations and old condenser_api-like interface from cli_wallet <-> hived communication
- [x] #150 Signing with account authority
- [ ] retain command history (I think issue is gone and has to be revived)
- [ ] #168 Add support for http/https connections
- [x] #169 Add support for offline use
- [ ] #170 non-blocking transactions
- [x] #175 Merge imported wallet file on load instead of replacing it
- [x] #177 `server-rpc-endpoint` option behaves as optional with no `default_value` specified
- [x] #178 Add exit function to the wallet API
- [x] #180 python based regression tests covering offline mode of cli_wallet
- [x] #182 Add ^C signal handler for non-deamon mode
- [x] #183 Add regression tests for exit command
- [x] #185 Extend regression tests to cover help functionality
Minor maintenance work related to internal docs (`gethelp`) - fixes, improvements, enhancements is WIP and usually done within my periodic `g-maintenance` branch, you are welcome to join the effortsGandalfGandalfhttps://gitlab.syncad.com/hive/hive/-/issues/151Standardization of block retrieval2022-10-20T11:13:34ZarcangeStandardization of block retrievalCurrently we have 6 different functions to retrieve information from blocks:
1. block_api.get_block
2. block_api.get_block_range
3. condenser_api.get_block
4. condenser_api.get_ops_in_block
5. account_history_api.get_ops_in_block
6. ac...Currently we have 6 different functions to retrieve information from blocks:
1. block_api.get_block
2. block_api.get_block_range
3. condenser_api.get_block
4. condenser_api.get_ops_in_block
5. account_history_api.get_ops_in_block
6. account_history_api.enum_virtual_ops
With few exceptions, they each have a different parameters' format and provide different results (structure, format, ...).
[1,2,3] do not return vops
[4,5] return ops and/or vops but not block data
[6] returns vops but not ops nor block data
[1,2] return tx ids as a global array
[3] returns tx ids as a global array and inside transactions objects (the later is easier to manage)
[6] returns tx ids in each operation object
[4] returns result as an array
[5] returns result is an object containing an array
[6] is the only one to effectively return `operation_id`
Properties like block_num, timestamp are sometimes duplicated in each transaction/operation which increases the volume of data returned and transferred.
Some APIs return operation type with the `_operation` suffix, some do not.
... and so on
Couldn't we optimize all this by providing one API call and above all standardizing how data are returned?
`get_block_range` looks like the favorite candidate to me.
It is quite new, less used up to now, and therefore less prone to break things if we change it.
My wish is it could return vops and has `transactions_ids` in each transaction object instead of being grouped in an array at the end.https://gitlab.syncad.com/hive/hive/-/issues/130fc maintenance2022-12-12T16:17:06ZGandalffc maintenanceWhat is a current status of "our" fc?
How it compares to:
https://github.com/EOSIO/fc (see `master` and `eosio` branches)
and
https://github.com/bitshares/bitshares-fc
( Also maybe @abit can help here )
Any bug fixes / improvements we c...What is a current status of "our" fc?
How it compares to:
https://github.com/EOSIO/fc (see `master` and `eosio` branches)
and
https://github.com/bitshares/bitshares-fc
( Also maybe @abit can help here )
Any bug fixes / improvements we could benefit from?
Potential reduction of maintenance efforts by reducing gaps between Hive / BitShares / EOS versions?https://gitlab.syncad.com/hive/hive/-/issues/112Reduce the chain block time from 3s to 2s2021-04-12T23:25:09ZSergioReduce the chain block time from 3s to 2s*The following consideration are the result of a chat with @dan and @gandalf*
### Why
This change will not solve a specific problem, but everything happening on Hive will be snappier and feel faster to the user.
Faster actions on social...*The following consideration are the result of a chat with @dan and @gandalf*
### Why
This change will not solve a specific problem, but everything happening on Hive will be snappier and feel faster to the user.
Faster actions on social frontends, faster battles on splinterlands, faster feedback, ...faster everything. Probably also Hivemind will be faster to receive updates.
### Things to consider
- There are almost certainly some things that assume a 3s block time, so it wouldn't be safe to simply change a constant, recompile and launch with new nodes. The other issue is that a decreased block time increases the chance for missed blocks and forks due to transmission latency.
- Higher traffic and block size (block size is a witness parameter, we can have much larger blocks 1M and much more filled...). It's easy to meet latency requirements while dealing with blocks which max_size is set to a minimum (65535)
- One downside of more blocks is increased overhead associated with meta data for the blocks. So if you have a lot of blocks without much transaction data, your chain can be inefficient with respect to storage.
- Increasing the frequency will probably lower the amount of transactions is each block, so processing a single block will be faster (assumed the same amount of tx/day)
### Next steps
Before evaluating the change is important to setup a testnet that can be used to perform some tests in a real world scenario. This means having multiple nodes with real world latency and with a good amount of transactions to process (real traffic).
This testnet can be set up with 1s block time first, then start backing off the time, to see how things change, if too many blocks are being missed.
### Other points to consider at a later stage
Hivemind will probably need some work to see if we are referring to block time to compute stuff, and a lot of troubles with much more frequent forks (but fork handling in hivemind is yet another subject to look at)GandalfGandalfhttps://gitlab.syncad.com/hive/hive/-/issues/52Downvote mana delegation2020-06-04T00:39:00ZHowoDownvote mana delegationFree downvotes were a great step in the right direction, but even with tools that allow you to easily trail people (aka layer 2 solutions), people are still afraid to downvote people, or maybe they would do so for a bit and then stop whe...Free downvotes were a great step in the right direction, but even with tools that allow you to easily trail people (aka layer 2 solutions), people are still afraid to downvote people, or maybe they would do so for a bit and then stop when they start to get backlash, to quote some people "it's not worth the drama".
I thought for the longest time that downvote delegation wasn't necessary for solving the "I don't downvote because I fear backlash" because abusers can just look up who delegated to who. But perhaps it is necessary after all.
the change is a bit complex as it adds yet another layer in delegation/voting calculation etc.https://gitlab.syncad.com/hive/hive/-/issues/49Should we add support for "custom keys"?2022-02-01T00:25:23ZDan NotesteinShould we add support for "custom keys"?IIRC, Bitshares was looking into adding "custom keys": keys which allowed for a given subset of operations to be signed. If it's not too intensive, this could be a useful feature for Hive as well. For example, a user could create a key t...IIRC, Bitshares was looking into adding "custom keys": keys which allowed for a given subset of operations to be signed. If it's not too intensive, this could be a useful feature for Hive as well. For example, a user could create a key that could only be used for voting, but not for posting, preventing potential identity theft when providing a voting key to another user or service.
Maybe someone from BitShares can chime in on if this was implemented, and if so, how easily/usefully it might be implemented for Hive.https://gitlab.syncad.com/hive/hive/-/issues/46CLI wallet should check against blacklist on sends?2020-06-06T02:24:40ZDan NotesteinCLI wallet should check against blacklist on sends?CLI wallet should probably check against blacklist of phishing accounts on transfers and prompt for verification when the transfer is to a known phishing account, but it needs to be done in such a way that it only does it when the comman...CLI wallet should probably check against blacklist of phishing accounts on transfers and prompt for verification when the transfer is to a known phishing account, but it needs to be done in such a way that it only does it when the commands are being sent interactively by users, or else there needs to be an option to "force" the command to happen without a prompt when the cli wallet is being driven programmatically.https://gitlab.syncad.com/hive/hive/-/issues/13Feature: Add app/meta tag to operations2020-06-27T15:29:46ZtherealwolfFeature: Add app/meta tag to operationsWe've already got the meta tag for posts & comments, which is being used to determine which dapp was used to broadcast it. The data is then being used to be display statistics at hivedapps.com & stateofthedapps.com as well as give an est...We've already got the meta tag for posts & comments, which is being used to determine which dapp was used to broadcast it. The data is then being used to be display statistics at hivedapps.com & stateofthedapps.com as well as give an estimation of how many on-chain user Hive has. This is obviously quite important to determine how active the chain is.
It would be good if we had the same tag for other operations. For example: vote, transfer, transfer_to_vesting, etc.
The tag could either be meta (json as string) or simply app (hiveblog/0.1).