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

Buyback mechanisms could be easily extended #387

Open
xeroc opened this issue Sep 1, 2017 · 4 comments
Open

Buyback mechanisms could be easily extended #387

xeroc opened this issue Sep 1, 2017 · 4 comments

Comments

@xeroc
Copy link
Member

xeroc commented Sep 1, 2017

Currently, a buyback account can be created using an account_create operation with an extension like this:

     "buyback_options": {
         "asset_to_buy": "1.3.330",
         "asset_to_buy_issuer": "1.2.3563",
         "markets": ["1.3.329"]},

Problems are

  • This extension requires the owner and active to be the null-account
  • If you want max usability, you want to be able to buy back X with assets A, B, ... which is possible already, but the operation fails to pay for the fee because BTS/TEST are not part of markets. If it was, the core asset would be used to buy back X.

Proposal: Allow transfers of CORE to a special account to pay for the order creation fee IFF CORE is not listed in markets.

Discuss!

@xeroc xeroc added the hardfork label Sep 1, 2017
@xeroc
Copy link
Member Author

xeroc commented Sep 1, 2017

On the testnet I get

Skipping buyback processing selling 1.3.329 for  {........}
Account 1.2.3564 'special-account' attempted to pay fee by using asset 1.3.0 'TEST', which is unauthorized due to whitelist / blacklist

Interestingly, this error comes from evaluator.cpp

Which makes me believe that it is not necessarily an issue with markets but rather with whitelisting, but the CORE asset doesn't use a whitelist.

Who can shed some light on this?

//edit: found it. It is indeed caused by allowed_assets which is a list curated by markets
See is_authorized_asset.hpp and account_evaluator.cpp.

Not knowing anything about the internal architecture, I would think the easiest way to resolve this is to add CORE to allowed_assets:

obj.allowed_assets->emplace( asset_id_type() );

@abitmore abitmore added this to the Future Consensus-Changing Release milestone Nov 27, 2017
@pmconrad
Copy link
Contributor

@xeroc I'm not clear about the intent of this issue.

Are buyback accounts used anywhere except for STEALTH? Are there real-life use-cases that we don't support? Would a documentation change "fix" the problem with CORE in allowed_assets?

@xeroc
Copy link
Member Author

xeroc commented Apr 30, 2019

Are buyback accounts used anywhere except for STEALTH? Are there real-life use-cases that we don't support? Would a documentation change "fix" the problem with CORE in allowed_assets?

There are real-life use cases we may want to support. A buyback account can be created with the extensions available in account_create_operation. The idea (and implementation) is to have an account where I send profits and the blockchain to use those funds to buy back some defined assets (asset per account creation) from internal markets. That however fails due to the issue described in the OP.

@OpenLedgerApp would be a prime example for this. They want to use profits to buy back OBITS. and instead of doing that manually, they could just send profits to a buyback account for OBITS.

@OpenLedgerApp
Copy link
Contributor

We do it manually for OBITS.
We would like to implement a similar mechanism in our proposal - bitshares/bsips#134

We are welcome for discussion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants