Why does voteproducer require a FIO Address? about fio

[pawmmm]

The first version of vote did not require a FIO Address. We added it, because we wanted voting to be available without a fee (using bundled transaction), so that more users would vote. In that process, we picked an approach that's easiest to code and that was to always require FIO Address. We further felt, it would be a good thing to require a FIO Address to ensure all voters have hands-on experience with the protocol.

[aaroncox]

The justification of using bundled transactions makes sense - since I'm assuming an address is required to utilize those. However, the remaining justifications I respectfully disagree with, and believe using a FIO Address to vote should be an optional parameter or not included at all.

Counterpoints:

• You can have "hands-on experience" with the protocol and still want to vote using an account without an associated address.
• Arguably this requirement is a barrier to voting, and does the opposite of encouraging some token holders to vote. This is because it requires additional steps (address registration/renewal) before allowing a specific token holder to vote.
• Requiring duplicate data that could otherwise be derived as an input parameter of the transaction is potentially wasteful. The transaction already knows who the voter is based on the actor field, and the addition of the address creates no additional value beyond bundling (which could potentially use the actor input?).
• The inclusion of a FIO address as an input parameter also creates a chain-specific implementation headaches for developers. We are experiencing this now, as our ESR signing protocol is designed to be chain-agnostic, and we will not be adding chain-specific templating values for things like FIO addresses. This means that transactions where the input includes a FIO address will not be compatible in a statically generated manner.

If the goal is simply to make bundling available to avoid fees, I'd recommend a different approach to transactions. Forcing it as an input parameter at the base layer causes more of a downside than an upside in many respects.

[lukestokes]

Great points, @aaroncox, thank you. Since bundles come from registered addresses and accounts can have multiple registered addresses, there's no easy way to figure out who would be charged.

How about this approach:

• Keep the address in there as an optional parameter for those who would like to specify exactly which account is using bundled transactions to pay for it
• If not supplied, attempt to find one (and only one) registered address to that account and if found, use it to pay the fee via the bundled transaction
• If not supplied and If multiple FIO Addresses exist or no FIO addresses exist, take the fee directly out of their balance instead of from bundled transactions.

How does that sound to you, @pawmmm ? It seems to accomplish all the goals.

[pawmmm]

I like that approach @lukestokes

[pawmmm]

Although not sure on the second point. It may be odd to deduct bundled transactions without user being aware of it.

[aaroncox]

Since bundles come from registered addresses and accounts can have multiple registered addresses, there's no easy way to figure out who would be charged.

I'm not sure I follow on this - the who shouldn't matter right, since the who is always going to be associated to the actual actor?

If I have an account/public key with 2 different addresses, the "who" is always still me right? In what situation would one account/public key have different addresses with different people behind them?

[pawmmm]

If I have an account/public key with 2 different addresses, the "who" is always still me right? In what situation would one account/public key have different addresses with different people behind them?

True, but you would be making a decision for the user as to which FIO address is "charged" the bundled transaction, since that is currently at FIO Address level. If it was moved to account level, it may make sense.

[aaroncox]

Associating that to the account level would make a lot of sense IMO. It'd be a weird UX to have 100 bundled transactions for a@test and 100 more for b@test - and tell the user they need to pick which address to use in order to utilize those free transactions.

Having all of those free bundled transactions associated on the account level prevents that cognitive load on the user - since they wouldn't need to think about which one of their addresses has remaining free transactions.

[lukestokes]

If bundled transactions are moved to the account actor then if someone buys an address and then sells it, that creates a problem as the remaining bundled transactions wouldn't travel along with the address to the new owner.

[edrotthoff]

just was talking to pawel about this...the main driver for doing addresses with bundled tx was the driver to keep, as much as possible, the notion of the account away from the user...switching this notion of bundled tx to the account level can be done, but (as Luke notes) it involves many use cases and flows and rules which have yet to be fully considered...

[aaroncox]

If bundled transactions are moved to the account actor then if someone buys an address and then sells it, that creates a problem as the remaining bundled transactions wouldn't travel along with the address to the new owner.

Is that actually a problem? I'll relay back to a DNS analogy, where if I buy a domain name and subsequently sell it, I wouldn't expect any "freebies" the registrar provided with my purchase to be transferred along with the domain registration transfer. Those were mine, as the original purchaser, and remain within my account on the registrars site.

the main driver for doing addresses with bundled tx was the driver to keep, as much as possible, the notion of the account away from the user

Considering they're already exposed to the notion of a public key and forced to use it, which essentially is the account itself, it could easily be presented in that fashion to avoid adding a new concept.

Regardless of how it's presented, one entity in the system (public key or account) owns a domain or address at a given moment in time. Users who manage addresses/domains need to know that it exists in some form because all native EOSIO objects are shared to this entity.

[pawmmm]

I think the right solution would be to make FIO Address optional (meaning it can be left blank) and if it is charge a fee. Thoughts?

[pawmmm]

I am recommending we make the following changes to resolve this issue:

• Allow fio_address on voteproducer and voteproxy to be blank and if it is charge the fee instead of decrementing the bundled transaction

@lukestokes @aaroncox @edrotthoff let me know if you agree and I'll write up a FIP

[lukestokes]

@pawmmm works for me.

[pawmmm]

Now a FIP: https://github.com/fioprotocol/fips/blob/master/fip-9.md

Please review and provide feedback.

[aaroncox]

FIP-9 look and the making of the parameter options works for me as well 👍

[pawmmm]

Closing as FIP-9 has been accepted and will be developed.