suggested updates to the "cost" command

[shea256]

There are a couple issues I see with the cost command right now...

First, the "transactions_fee" field should be renamed to "transaction_fee".

Second, some people may find the price of the name to be what they are interested in, as opposed to the total cost including the fee. Consider that in the future we'll have dynamic fees and so those will float up and down. Also consider that this function will be most valuable for expensive names (if you know a name is only a few cents then it's not particularly edifying whether it is 2 cents or 1 cent), and with this scenario the name price will dwarf the transaction fee. Further, people may want to be able to set their own fees so that they can speed up or slow down the registration. Thus, the name price itself is likely going to be the most important metric for a lot of people. At the same time, the total estimated cost is important as well. So they should be given equal footing, in my view, within the response. That means no nested dictionary. And as a bonus we get increased simplicity by having no nesting in the response (this isn't always desirable).

With these things considered, I'm proposing we update the response of the command to the following:

{
  "name_price": 0.02, 
  "transaction_fee": 0.005, 
  "total_estimated_cost": 0.025
}

[shea256]

Also, come to think of it, I feel like we should rename the command from "cost" to "price". Seems to be a bit more in line with how someone would think when they go to register from the command line.

[muneeb-ali]

Not sure about having three things there. I want to see just one number i.e., what is this thing going to cost me? Most people don't care about the details of the breakdown and for those who do they can inspect the details field.

[shea256]

OK good point.

Then I'd just focus on the price of the name as that is the key number. This is similar to how one thinks about sending bitcoins to a friend:

A: "How much should I send you?"
B: "$10."
A: "OK putting in $10."
*(A sees that a fee of $0.05 will be added on at the point of registration and then clicks send)*
B. "Great got it!"

To make this change, we could update the response to the following:

$ blockstack price abcd
{
  "name_price": 0.016, 
  "message": "Note that the price shown does not include a nominal transaction fee."
}

$ blockstack price ab
{
  "name_price": 0.064, 
  "message": "Note that the price shown does not include a nominal transaction fee."
}

vs.

{
  "total_cost": 0.01616, 
  "details": {
    "name_price": 0.016, 
    "transaction_fee": 0.00016
  }
}

{
  "total_cost": 0.06416, 
  "details": {
    "name_price": 0.064, 
    "transaction_fee": 0.00016
  }
}

[muneeb-ali]

I have thought about this option:

$ blockstack price ab
{
  "name_price": 0.064, 
  "message": "Note that the price shown does not include a nominal transaction fee."
} 

The issue with that approach is that later on we use the total_cost to give a display prompt like this:

Registering clone_4001.id will cost 0.0002225 BTC. Continue? (y/n):

By making that change, options become:

a) Display a cost in the second prompt that is inconsistent with the cost shown earlier (that's confusing -- why did the cost change? because of tx fees?).

or b) Display only the name_cost and don't show the transaction cost, which has the bad property that you are not telling the user how much money is coming out of their wallet and they might notice that more money was spent in reality. That's the reason for high estimation of tx fees as well. People don't mind if our estimate is higher and when they check the wallet less money was actually spent. However, taking more money out of their wallet without explicitly telling them is probably not the way to go.

If we absolutely must display only a single number for cost then I'd rather display the total cost instead of name cost and keep that number consistent with the second prompt. Users will have a sense of how much total money is coming out of their wallet.

Personally, I like having both the total_cost and the breakdown. Different underlying factors influence the pricing of these two variables e.g., there can be a namespace where the registration cost is zero and you are only paying transaction cost. Also, we don't know how transaction costs on the Bitcoin network are going to evolve over time. They might be nominal right now, but that might not be the case in the near future.

[shea256]

One way to solve the issue you're talking about would be to change the message to the following:

Registering clone.id will cost 0.00416 (including transaction fees). Continue? (y/n):

But if you do want to have both the total cost and the breakdown, then I think the suggestion of having a flat response works great. Some people may want to focus on the total estimated cost and some people may want to focus on the name price. Personally, I'd be looking at the name price. If I focus on the price and register a few names, I'll be able to develop a mental model of the pricing of names and I can focus on a simple number (0.16, 0.32, 0.64 makes it clear there's some doubling involved with names, whereas too many decimal places and I get lost). This is why I think the response format below makes a lot of sense:

{
  "name_price": 0.02, 
  "transaction_fee": 0.005, 
  "total_estimated_cost": 0.025
}

It also reads like a balance, where the price is at the top, the fee is below that, and the total cost is at the bottom (note that json.dumps in python sorts the fields in the order above, as it's based on key length).

[muneeb-ali]

I can rename to this format and use total_estimated_cost for the display in the second prompt.

Also, are we sticking with cost or price or fee? (I saw fee in the current docs). We should pick one and stick with it. Fee is probably my least favorite. Happy with either cost or price.

[shea256]

OK that sounds good. I like price, and agreed, fee is the worst lol. I'll update the docs once this is updated.