Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Impossible to distinct between a send/receive/change using the `blocks` in RPC #809

Closed
Inkeliz opened this issue Apr 16, 2018 · 2 comments

Comments

5 participants
@Inkeliz
Copy link

commented Apr 16, 2018

Using the state-block can be impossible to distinct between send/receive with the blocks or blocks_info.


If someone creates a receive (legacy), then use the state-block (for send), is impossible to know if it is a send or receive, because the previous block (receive, non-state) don't includes the balance.

Usually, it's possible to check the send/receive comparing against the balance from the previous block, but in some cases don't exist a balance.

Also, is impossible to know if it's a change block. If someone uses a legacy block and do a send and change (both operations in one block) is impossible to know the change, the RPC doesn't include that information too, the previous block might not include it.


I think the blocks_info should include the balance and representative of each block. Alternatively, ignoring performance aspect, can include a SubType array, like SubType: ["receive"] or SubType: ["receive", "change"].

But it isn’t my preferred method… If we go futher we can do the opposite. If have a new optional parameter like force_state_block (in complement with "pending", "source" already existent). If this parameter is used it will retrieve the legacy blocks as a state-block, fixing all issues. So, the “send block” (legacy one) will be a “state-block” with all correct information (the Balance, the Representive used up this block, the Account, and so on).

In this case the SubType is dropped, since all types can be identified, and all types are state-block. For signature check we need to know if it’s a really state or a converted one. In my mind, creating a is_legacy as a Boolean response is enough. It should help the usage of the RPC, since all blocks can be treated as a state-block, if someone need to check the signature they can hash the legacy equivalent of the content and compare it.

@Inkeliz Inkeliz changed the title Impossible to distinct between a send and receive using the `blocks` in RPC Impossible to distinct between a send/receive/change using the `blocks` in RPC Apr 16, 2018

@rkeene rkeene self-assigned this Aug 23, 2018

@rkeene rkeene added this to the V18.0 milestone Aug 23, 2018

@renesq

This comment has been minimized.

Copy link

commented Sep 5, 2018

blocks_info actually has an option to display the balance, just not the representative.

Other alternatives to distinguish between sends and receives:

  • try to retrieve the block referenced in the "link" field. If it works, it's a send or send type block.
  • use account_history instead, which shows the emulted subtype for legacy reasons (But it only shows one subtype at a time, i think. The command also has a "raw" option to show the real blocks. )
  • The main reason why e.g. callback doesn't list subtypes but has a "is_send" flag instead is because representative changes are rather irrelevant for most app development. The is_send flag also is rather precise, since there oould be two subtypes at the same time, as you already noticed.
    If the amount of a state block is 0, it's not a receive either so it must be a change type block or an epoch block. The amount is included in blocks_info. So it is possible to determine sole rep-change type state blocks. But it's not possible to determine rep changes when going from legacy to state block. As already commented in another thread, i recommend ditching legacy support in app development.

@zhyatt zhyatt added this to Unscheduled in V18 Dec 27, 2018

@rkeene rkeene moved this from Unscheduled to CP 2 (2018-01-16) in V18 Dec 31, 2018

@zhyatt zhyatt moved this from CP 2 (2018-01-16) to CP 3 (2018-01-23) in V18 Jan 17, 2019

@zhyatt zhyatt moved this from CP 3 (2018-01-23) to Nice to have in V18 Jan 22, 2019

@zhyatt zhyatt modified the milestones: V18.0, V19.0 Feb 6, 2019

@zhyatt zhyatt removed this from Nice to have in V18 Feb 6, 2019

@SergiySW SergiySW added this to CP0 in V19 Feb 15, 2019

@SergiySW

This comment has been minimized.

Copy link
Collaborator

commented Feb 25, 2019

Subtype field addesd in #1774 (v19.0)

@SergiySW SergiySW closed this Feb 25, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.