2018-04-12 Engineering Meeting

Date/Time: 2018-04-12 @ 13:00 UTC / 09:00 EDT / 21:00 HKT
Click here to convert to your time zone
Length: 45 minutes
Meeting link: https://zoom.us/j/416493133


Please reply to this forum post with items you would like included on the agenda.

Each item should include:

Item name
Background information: Links to github issues, forum posts, etc with background information on the item
Desired outcome: what decision or deliverable would you like from the discussion of this topic at the meeting?

We’ll save ~10 minutes or so for community questions or comments at the end of the meeting.

Breaking Change to /v1/prices/* endpoints


When the Stacks token goes live, two things will happen with respect to name prices:

  • names can be priced in either satoshis or microSTACKs
  • the price of a name can exceed 2**53 - 1 microSTACKs, which is larger than the largest possible integer in Javascript

My feature/token-v1 branch of Blockstack Core addresses this by returning { "units": string, "amount": string } instead of the previous { "satoshis" : number }. The units field can be BTC, STACKS, or (in the future) a namespace ID, for when we have namespace-specific tokens. The amount field must be encoded as a string in order to overcome the 2**53 - 1 limitation in Javascript clients.

My feature/stacks-transactions branch of blockstack.js is compatible with the feature/token-v1 price API. It automatically parses the amount field into a BigInteger, which it then uses to encode the price of a name or namespace in the underlying transaction.

However, I do not know which other consumers of the /v1/prices API exist. Having talked with @aaronb, I think the Blockstack Browser directly queries the Core node instead of using blockstack.network.getNamePrice() for name prices. Either way, the code paths in the Browser will need to be updated at some point in order to support buying names with different tokens (BTC, STACKs, or otherwise)

Desired Outcome

  • Increment the version number on the prices endpoints in the next release of Blockstack Core, yielding /v2/prices/names/:name and /v2/prices/namespaces/:namespaceID.
  • Remove /v1/prices/namespaces, since it will cease to work as-is once STACKs go live. I think this is reasonable since namespace creators are technically savvy enough to understand the gravity of the situation.
  • Deprecate /v1/prices/names, since it will not work on namespaces that expect payment in anything but BTC. We can safely leave it for one more release.
  • Identify which API consumers will need to be patched
    • I have already patched blockstack.js internally
    • My node.js CLI already uses the new convention I outlined here for pricing names and namespaces


Background information: We’ve never shipped a 1.0 of anything and our versioning is confusing to developers. Our policy is that we want to use semantic versioning but in reality we keep avoiding shipping a major version that developers can depend on not breaking for a period of time.

I’d like to propose moving everything to 1.0 in an upcoming release and/or dropping the leading zero and following semver going forward.

Desired outcome: A decision to move to semver or to keep the status quote.


Background information: We will be trying out a QA vendor and need do the following to get started:

  • dedicate ~10 person-hours a week for the next month or two to getting the project off the ground.
  • assign a point person
  • ship subdomains

Desired outcome: Determine if this is an amount of time we’d like to spend, decide on a point person, decide when we’re shipping subdomains.

1 Like

2018-04-12 Engineering Meeting



Breaking Change to /v1/prices/* endpoints

  • Breaking change on endpoint regardless
  • Will need to make changes to browser to use blockstack.js for this
  • Jude to make issues for these and handle them
  • UI/UX change to let users know if they’re paying in stacks or bitcoin
  • Stacks transaction generation in blockstack.js
  • /v2 API endpoint which will not break existing API
  • Jude to break up blockstack.js PR to multiple parts

Versioning in Blockstack.js

  • Implement semantic versioning in blockstack.js
  • Go to version v18 for next release
  • Add a change log and checklist for release to blockstack.js
  • Aaron to add to Readme
  • We should add change logs to all of our library repos


  • Need a point person for QA testing with 3rd party vendor, possibly Jack?
  • Either ship subdomains and give testers subdomains or have them use regtest to test name registrations
  • Version with subdomains can be the first version they test
1 Like