mirror of https://github.com/lukechilds/docs.git
John Mulhausen
5 years ago
committed by
Hank Stoever
Hank Stoever
506 changed files with 303 additions and 14590 deletions
@ -1 +0,0 @@ |
|||||
2.5.1 |
|
||||
@ -1,16 +0,0 @@ |
|||||
# A sample Guardfile |
|
||||
# More info at https://github.com/guard/guard#readme |
|
||||
|
|
||||
## Uncomment and set this to only include directories you want to watch |
|
||||
# directories %w(app lib config test spec features) \ |
|
||||
# .select{|d| Dir.exists?(d) ? d : UI.warning("Directory #{d} does not exist")} |
|
||||
|
|
||||
## Note: if you are using the `directories` clause above and you are not |
|
||||
## watching the project directory ('.'), then you will want to move |
|
||||
## the Guardfile to a watched dir and symlink it back, e.g. |
|
||||
# |
|
||||
# $ mkdir config |
|
||||
# $ mv Guardfile config/ |
|
||||
# $ ln -s config/Guardfile . |
|
||||
# |
|
||||
# and, you'll have to watch "config/Guardfile" instead of "Guardfile" |
|
||||
@ -1,351 +0,0 @@ |
|||||
# Docs is a premium documentation Jekyll theme |
|
||||
|
|
||||
Desk was developed by [Ivan Chromjak](https://ivanchromjak.com) for [jekyll.plus](https://jekyll.plus/), theme [live demo](https://docs.jekyll.plus/) available. |
|
||||
|
|
||||
## Features |
|
||||
|
|
||||
* Contact form |
|
||||
* Live Search |
|
||||
* Responsive videos |
|
||||
* Image lightbox |
|
||||
* Google maps |
|
||||
* Github avatar |
|
||||
* Changelog page |
|
||||
* Contact form (FormSpree) |
|
||||
* Pre-built pages |
|
||||
* Disqus comments for posts |
|
||||
* Configurable home page header images |
|
||||
* Optimised for [GitHub](https://pages.github.com/) pages |
|
||||
* RSS feed |
|
||||
* SEO tags |
|
||||
* Google Analytics |
|
||||
|
|
||||
|
|
||||
## Installation |
|
||||
|
|
||||
Install the dependencies with [Bundler](http://bundler.io/): |
|
||||
|
|
||||
```bash |
|
||||
bundle install |
|
||||
``` |
|
||||
|
|
||||
Run the following to generate your site: |
|
||||
```bash |
|
||||
bundle exec jekyll serve |
|
||||
``` |
|
||||
|
|
||||
You can find more on [Deployment Methods](https://jekyllrb.com/docs/deployment-methods/) page on Jekyll website. |
|
||||
|
|
||||
## Setup |
|
||||
|
|
||||
### Site and author details |
|
||||
Add your site and author details in `_config.yml`: |
|
||||
```yaml |
|
||||
# Site title and description |
|
||||
title: Docs - Documentation Jekyll Theme |
|
||||
description: Documentation Jekyll theme. |
|
||||
|
|
||||
# Site base hostname & protocol, e.g. http://example.com |
|
||||
url: "https://docs.jekyll.plus" |
|
||||
|
|
||||
# Site logo, image or text |
|
||||
brand: |
|
||||
image: touch-icon.svg # e.g. logo.png, upload logo image file to /assets/img/ folder |
|
||||
text: Docs # if the above "logo:" image variable is not set, this text logo is displayed instead |
|
||||
|
|
||||
# Default author settings |
|
||||
author: |
|
||||
name: John Smith |
|
||||
github: PressApps # Github username for avatar |
|
||||
|
|
||||
# Author settings, displayed on post and doc pages if front matter references author name e.g. author: peter |
|
||||
authors: |
|
||||
peter: |
|
||||
name: Peter Brown |
|
||||
github: PressApps # Github username for avatar |
|
||||
|
|
||||
# Social icons displayed in footer |
|
||||
social: |
|
||||
email: |
|
||||
website: |
|
||||
facebook: https://www.facebook.com/blockstack |
|
||||
flickr: |
|
||||
dribbble: |
|
||||
github: https://github.com/blockstack |
|
||||
googleplus: |
|
||||
instagram: |
|
||||
linkedin: https://www.linkedin.com/company/blockstack-labs |
|
||||
pinterest: |
|
||||
twitter: https://twitter.com/blockstack |
|
||||
vimeo: |
|
||||
youtube: https://www.youtube.com/channel/UC3J2iHnyt2JtOvtGVf_jpHQ/featured |
|
||||
|
|
||||
# Twitter share button |
|
||||
twitter_username: |
|
||||
|
|
||||
``` |
|
||||
|
|
||||
### Navigation Bar |
|
||||
Set in the main navigation links in `_data/navigation_header.yml`: |
|
||||
```yaml |
|
||||
- title: About |
|
||||
url: /about/ |
|
||||
``` |
|
||||
|
|
||||
### Footer |
|
||||
|
|
||||
Edit copyright notice in `_config.yml`: |
|
||||
```yaml |
|
||||
footer: |
|
||||
copyright: |
|
||||
``` |
|
||||
|
|
||||
Set in the navigation links in `_data/navigation_footer.yml`: |
|
||||
```yaml |
|
||||
- title: About |
|
||||
url: /about/ |
|
||||
``` |
|
||||
|
|
||||
### Enabling comments (via Disqus) |
|
||||
|
|
||||
Optionally, if you have a Disqus account, you can tell Jekyll to use it to show a comments section below each post. To enable it, add the following lines to your Jekyll site: |
|
||||
|
|
||||
```yaml |
|
||||
disqus: |
|
||||
shortname: my_disqus_shortname |
|
||||
``` |
|
||||
|
|
||||
You can find out more about Disqus' shortnames [here](https://help.disqus.com/customer/portal/articles/466208). |
|
||||
|
|
||||
Comments are enabled by default and will only appear in production, i.e., `JEKYLL_ENV=production`. If you don't want to display comments for a particular post you can disable them by adding `comments: false` to that post's YAML Front Matter. |
|
||||
|
|
||||
### Google Analytics |
|
||||
|
|
||||
To enable Google Anaytics, add the following lines to your Jekyll site: |
|
||||
|
|
||||
```yaml |
|
||||
google_analytics: UA-NNNNNNNN-N |
|
||||
``` |
|
||||
|
|
||||
Google Analytics will only appear in production, i.e., `JEKYLL_ENV=production` |
|
||||
|
|
||||
### Google Map |
|
||||
|
|
||||
To display Google map on contact page, add the following in your page content, replacing latitude, longitude and zoom values: |
|
||||
|
|
||||
```yaml |
|
||||
{% include map.html latitude="40.6700" longitude="-73.9400" zoom="16" %} |
|
||||
``` |
|
||||
|
|
||||
### Contact Form (via FormSpree) |
|
||||
|
|
||||
Submit the form and confirm your email address at [FormSpree](https://formspree.io/). Then add the following lines to contact page YAML Front Matter, replacing the email address: |
|
||||
|
|
||||
```yaml |
|
||||
formspree: |
|
||||
email: my_name@gmail.com |
|
||||
redirect: /thanks/ |
|
||||
``` |
|
||||
|
|
||||
### Update favicon |
|
||||
|
|
||||
You can find the current favicon (favicon.png) inside the theme `/assets/img/` directory, just replace it with your new favicon. |
|
||||
|
|
||||
## Posts |
|
||||
|
|
||||
To create a new post, you can create a new markdown file inside the `_posts` directory by following the recommended file naming format: |
|
||||
``` |
|
||||
YEAR-MONTH-DAY-title.MARKUP |
|
||||
``` |
|
||||
Where `YEAR` is a four-digit number, `MONTH` and `DAY` are both two-digit numbers, and `MARKUP` is the file extension representing the format used in the file. For example, the following are examples of valid post filenames: |
|
||||
|
|
||||
``` |
|
||||
2011-12-31-new-years-eve-is-awesome.md |
|
||||
2012-09-12-how-to-write-a-blog.md |
|
||||
``` |
|
||||
|
|
||||
Post requires front matter, everything in between the first and second --- are part of the YAML Front Matter, and everything after the second --- will be rendered with Markdown and show up as “Content”. |
|
||||
The following is a post file with different configurations you can add as example: |
|
||||
|
|
||||
```yaml |
|
||||
--- |
|
||||
layout: post |
|
||||
title: How To Travel On Low Budget |
|
||||
--- |
|
||||
``` |
|
||||
|
|
||||
You can rebuild the site in many different ways, but the most common way is to run `bundle exec jekyll serve`, which launches a web server and auto-regenerates your site when a file is updated. |
|
||||
|
|
||||
To keep things more organized, add post images to `/assets/posts/` directory, and add theme images to `/assets/img/` directory. |
|
||||
|
|
||||
### Adding images |
|
||||
To add an image to a post or page use the following codes: |
|
||||
Local image from `/assets/posts/` directory: |
|
||||
```yaml |
|
||||
{% include image.html img="girl.jpg" alt="Alt for image" caption="Girl on a rock" %} |
|
||||
``` |
|
||||
External wide image with lightbox: |
|
||||
```yaml |
|
||||
{% include image.html img="https://source.unsplash.com/TT-ROxWj9nA.jpg" lightbox="true" alt="Alt for image" caption="Image in lightbox" %} |
|
||||
``` |
|
||||
|
|
||||
### Adding table of contents |
|
||||
Add the following code at the top of the post: |
|
||||
``` |
|
||||
#### Sections in this article |
|
||||
{:.no_toc} |
|
||||
* TOC |
|
||||
{:toc} |
|
||||
``` |
|
||||
`{:.no_toc}` excludes the `#### Sections in this article` title from indexing in table of contents |
|
||||
|
|
||||
### Responsive Videos |
|
||||
Embed local videos: |
|
||||
```html |
|
||||
<video controls playsinline uk-video="automute: true"> |
|
||||
<source src="http://www.quirksmode.org/html5/videos/big_buck_bunny.mp4" type="video/mp4"> |
|
||||
<source src="http://www.quirksmode.org/html5/videos/big_buck_bunny.ogv" type="video/ogg"> |
|
||||
</video> |
|
||||
``` |
|
||||
Embed YouTube videos: |
|
||||
```html |
|
||||
<iframe src="http://www.youtube.com/embed/YE7VzlLtp-4?autoplay=0&showinfo=0&rel=0&modestbranding=1&playsinline=1" width="600" height="340" frameborder="0" allowfullscreen uk-responsive uk-video="automute: true"></iframe> |
|
||||
``` |
|
||||
|
|
||||
To create a draft post, create the post file under the `_drafts` directory, and you can find more information in [Working with Drafts](https://jekyllrb.com/docs/drafts/). |
|
||||
|
|
||||
## Home Page |
|
||||
|
|
||||
To create a home page, just create a `index.md` file inside the root directory. The following is a YAML Front Matter example for a page: |
|
||||
|
|
||||
```yaml |
|
||||
--- |
|
||||
layout: home |
|
||||
hero: |
|
||||
title: How Can We Help? # hero section settings |
|
||||
subtitle: Search or browse in depth articles and videos on everything Jekyll, from basic theme setup and hosting to customisation and development |
|
||||
image: imac.svg # display small image above title |
|
||||
search: true # enable search |
|
||||
categories: |
|
||||
columns: 3 # number of category columns; 1, 2, 3, 4 |
|
||||
title: Browse Topics |
|
||||
subtitle: Get your answers fast, jump to most popular documentation content |
|
||||
featured: # featured docs section settings |
|
||||
title: Popular Articles |
|
||||
tag: featured # tag used to populate featured section on home page |
|
||||
section: # display page content |
|
||||
title: Need More? |
|
||||
subtitle: This section displays optional page content lorem ipsum |
|
||||
cta: # call to action section |
|
||||
title: Didn't find an answer to your question? |
|
||||
subtitle: Get in touch with us for details on additional services and custom work pricing |
|
||||
button_text: Contact Us |
|
||||
button_url: /contact/ |
|
||||
--- |
|
||||
``` |
|
||||
|
|
||||
Home page category boxes are added in `_data/navigation_home.yml`, e.g.: |
|
||||
```yml |
|
||||
- title: Getting Started |
|
||||
desc: Get your account up and running in just few easy steps |
|
||||
icon: settings |
|
||||
doc: usage |
|
||||
|
|
||||
- title: Account and Billing |
|
||||
desc: Managing your account, creating new users and exporting data |
|
||||
icon: credit-card |
|
||||
doc: drafts |
|
||||
``` |
|
||||
|
|
||||
All available icons can be found [here](https://getuikit.com/docs/icon#library). |
|
||||
|
|
||||
## Docs |
|
||||
|
|
||||
To create a document post, just create a new page inside the root directory and add the following code in content: |
|
||||
``` |
|
||||
{% include faqs.html %} |
|
||||
``` |
|
||||
|
|
||||
Create new doc post entries in `_docs` folder, similar to creating posts, but with following front matter settings: |
|
||||
|
|
||||
```yml |
|
||||
--- |
|
||||
layout: doc |
|
||||
title: Category hosting Setting up new domain and page |
|
||||
subtitle: This is optional doc subtitle |
|
||||
tags: featured development |
|
||||
author: peter |
|
||||
--- |
|
||||
``` |
|
||||
|
|
||||
Sidebar navigation on docs post can edited in `_data/navigation_docs.yml`: |
|
||||
|
|
||||
```yml |
|
||||
- title: Getting Started # Section title |
|
||||
docs: |
|
||||
- home # Doc file name from _docs folder |
|
||||
- quickstart |
|
||||
- installation |
|
||||
- windows |
|
||||
``` |
|
||||
|
|
||||
## Changelog page |
|
||||
|
|
||||
Create new page with the following front matter: |
|
||||
|
|
||||
```yml |
|
||||
--- |
|
||||
layout: changelog |
|
||||
title: Changelog |
|
||||
permalink: /changelog/ |
|
||||
--- |
|
||||
``` |
|
||||
|
|
||||
Changelog enties are added in `_data/changelog.yml`: |
|
||||
|
|
||||
```yml |
|
||||
- title: Version 0.6.0 |
|
||||
label: |
|
||||
date: Aug 15, 2017 |
|
||||
list: |
|
||||
- Added style support for radio and checkbox in Firefox |
|
||||
- Removed class from Section component |
|
||||
``` |
|
||||
|
|
||||
|
|
||||
## Customization |
|
||||
|
|
||||
To modify the primary color, open `/_sass/theme/variables.scss` and replace the color values e.g.: |
|
||||
|
|
||||
```scss |
|
||||
// Main content |
|
||||
$color-main: #0F1214; |
|
||||
``` |
|
||||
|
|
||||
Further style customization can be done in the following files: |
|
||||
``` |
|
||||
/_sass/theme/mixins.scss |
|
||||
/_sass/theme/variables.scss |
|
||||
/assets/css/main.scss |
|
||||
``` |
|
||||
|
|
||||
## Development |
|
||||
|
|
||||
Install [UIkit](https://getuikit.com/) font end framework dependency via Npm: |
|
||||
```bash |
|
||||
npm install |
|
||||
``` |
|
||||
Enable live browser reload with the following: |
|
||||
```bash |
|
||||
bundle exec jekyll s --livereload |
|
||||
``` |
|
||||
|
|
||||
## Credits and Sources |
|
||||
|
|
||||
- Google analytics https://www.google.com/analytics/ |
|
||||
- Google maps https://www.google.com/maps |
|
||||
- UIkit front end framework https://getuikit.com/ |
|
||||
- Jekyll CML https://jekyllrb.com/ |
|
||||
|
|
||||
## Support |
|
||||
Customer support is provided through our Envato profile page [contact form](https://themeforest.net/user/pressapps) for up to six months from the purchase date and is provided Monday to Friday during the business week. We aim to answer all support requests daily, most are handled within 48h. |
|
||||
@ -1 +0,0 @@ |
|||||
12 |
|
||||
@ -1 +0,0 @@ |
|||||
12 |
|
||||
|
Before Width: | Height: | Size: 88 KiB |
|
Before Width: | Height: | Size: 56 KiB |
|
Before Width: | Height: | Size: 124 KiB |
|
Before Width: | Height: | Size: 52 KiB |
|
Before Width: | Height: | Size: 123 KiB |
|
Before Width: | Height: | Size: 139 KiB |
|
Before Width: | Height: | Size: 97 KiB |
|
Before Width: | Height: | Size: 82 KiB |
|
Before Width: | Height: | Size: 10 KiB |
|
Before Width: | Height: | Size: 41 KiB |
@ -1,773 +0,0 @@ |
|||||
--- |
|
||||
layout: learn |
|
||||
permalink: /:collection/:path.html |
|
||||
--- |
|
||||
# Android SDK Tutorial (Pre-release) |
|
||||
{:.no_toc} |
|
||||
|
|
||||
This tutorial is written for readers who are new to either or both Blockstack |
|
||||
and Android to create a decentralized application. It contains the following |
|
||||
content: |
|
||||
|
|
||||
* TOC |
|
||||
{:toc} |
|
||||
|
|
||||
This tutorial was extensively tested using Android Studio 3.1 on a MacBook Air |
|
||||
running High Sierra 10.13.4. If your environment is different, you may encounter |
|
||||
slight or even major discrepancies when performing the procedures in this |
|
||||
tutorial. Please [join the Blockstack community |
|
||||
Slack](https://slofile.com/slack/blockstack) and post questions or comments to |
|
||||
the `#support` channel. |
|
||||
|
|
||||
Finally, this tutorial is written for all levels from the beginner to the most |
|
||||
experienced. For best results, beginners should follow the guide as written. It |
|
||||
is expected that the fast or furiously brilliant will skip ahead and improvise |
|
||||
on this material at will. Fair journey one and all. |
|
||||
|
|
||||
If you prefer, you can skip working through the tutorial all together. Instead, |
|
||||
you can [download the final project code](images/helloandroid.zip) and import it |
|
||||
into Android Studio to review it. |
|
||||
|
|
||||
## Understand the sample application flow |
|
||||
|
|
||||
When complete, the sample application is a simple `hello-world` display. It is |
|
||||
intended for user on an Android phone. |
|
||||
|
|
||||
 |
|
||||
|
|
||||
Only users with an existing `blockstack.id` can run your |
|
||||
final sample application. When complete, users interact with the sample |
|
||||
application by doing the following: |
|
||||
|
|
||||
 |
|
||||
|
|
||||
## Set up your environment |
|
||||
|
|
||||
This sample application has two code bases, a Blockstack `hello-blockstack` |
|
||||
application and a `hello-andriod` Android application. Before you start |
|
||||
developing the sample, there are a few elements you need in your environment. |
|
||||
|
|
||||
### Install Android Studio |
|
||||
|
|
||||
If you are an experienced Android developer and already have an Android |
|
||||
development environment on your workstation, you can use that and skip this |
|
||||
step. However, you will need to adjust the remaining instructions for your |
|
||||
environment. |
|
||||
|
|
||||
Follow the installation instructions to download and [Android Studio |
|
||||
3.1](https://developer.android.com/studio/install) for your operating system. |
|
||||
Depending on your network connection, this can take between 15-30 minutes. |
|
||||
|
|
||||
 |
|
||||
|
|
||||
### Do you have npm? |
|
||||
|
|
||||
The Blockstack code in this tutorial relies on the `npm` dependency manager. |
|
||||
Before you begin, verify you have installed `npm` using the `which` command to |
|
||||
verify. |
|
||||
|
|
||||
```bash |
|
||||
$ which npm |
|
||||
/usr/local/bin/npm |
|
||||
``` |
|
||||
|
|
||||
If you don't find `npm` in your system, [install |
|
||||
it](https://www.npmjs.com/get-npm). |
|
||||
|
|
||||
### Install the Blockstack test rig |
|
||||
|
|
||||
Users interact with Blockstack-enabled applications through a web browser. You |
|
||||
can Blockstack in test mode, on `localhost` or you can interact with completed |
|
||||
apps through the Blockstack webapp which is available at |
|
||||
[https://browser.blockstack.org/]. |
|
||||
|
|
||||
If you have already installed Blockstack for testing locally and have an |
|
||||
existing Blockstack ID, skip this section. Otherwise, continue onto install |
|
||||
Blockstack. |
|
||||
|
|
||||
1. Go to [Blockstack](https://blockstack.org/install) |
|
||||
|
|
||||
 |
|
||||
|
|
||||
2. Install the version appropriate for your operating system. |
|
||||
|
|
||||
|
|
||||
### Use npm to install Yeoman and the Blockstack App Generator |
|
||||
|
|
||||
You use `npm` to install Yeoman. Yeoman is a generic scaffolding system that |
|
||||
helps users rapidly start new projects and streamline the maintenance of |
|
||||
existing projects. |
|
||||
|
|
||||
|
|
||||
1. Install Yeoman. |
|
||||
|
|
||||
```bash |
|
||||
npm install -g yo |
|
||||
``` |
|
||||
2. Install the Blockstack application generator. |
|
||||
|
|
||||
```bash |
|
||||
npm install -g generator-blockstack |
|
||||
``` |
|
||||
|
|
||||
|
|
||||
## Build the Blockstack hello-world |
|
||||
|
|
||||
In this section, you build a Blockstack `hello-world` application. Then, you |
|
||||
modify the `hello-world` to interact with the Android app via a redirect. |
|
||||
|
|
||||
### Generate and launch your hello-blockstack application |
|
||||
|
|
||||
In this section, you build an initial React.js application called |
|
||||
`hello-blockstack`. |
|
||||
|
|
||||
1. Create a `hello-blockstack` directory. |
|
||||
|
|
||||
```bash |
|
||||
mkdir hello-blockstack |
|
||||
``` |
|
||||
|
|
||||
2. Change into your new directory. |
|
||||
|
|
||||
```bash |
|
||||
cd hello-blockstack |
|
||||
``` |
|
||||
|
|
||||
3. Use Yeoman and the Blockstack application generator to create your initial `hello-blockstack` application. |
|
||||
|
|
||||
```bash |
|
||||
yo blockstack:react |
|
||||
``` |
|
||||
|
|
||||
You should see several interactive prompts. |
|
||||
|
|
||||
```bash |
|
||||
$ yo blockstack:react |
|
||||
========================================================================== |
|
||||
We are constantly looking for ways to make yo better! |
|
||||
May we anonymously report usage statistics to improve the tool over time? |
|
||||
More info: https://github.com/yeoman/insight & http://yeoman.io |
|
||||
========================================================================== No |
|
||||
|
|
||||
_-----_ ╭──────────────────────────╮ |
|
||||
| | │ Welcome to the │ |
|
||||
|--(o)--| │ Blockstack app │ |
|
||||
--------- │ generator! │ |
|
||||
( _U_ ) ╰──────────────────────────╯ |
|
||||
/___A___\ / |
|
||||
| ~ | |
|
||||
__'.___.'__ |
|
||||
|° Y |
|
||||
|
|
||||
? Are you ready to build a Blockstack app in React? (Y/n) |
|
||||
``` |
|
||||
|
|
||||
4. Respond to the prompts to populate the initial app. |
|
||||
|
|
||||
After the process completes successfully, you see a prompt similar to the following: |
|
||||
|
|
||||
```bash |
|
||||
[fsevents] Success: |
|
||||
"/Users/theuser/repos/hello-blockstack/node_modules/fsevents/lib/binding/Release/node-v59-darwin-x64/fse.node" |
|
||||
is installed via remote npm notice created a lockfile as package-lock.json. |
|
||||
You should commit this file. added 1060 packages in 26.901s |
|
||||
``` |
|
||||
|
|
||||
5. Run the initial application. |
|
||||
|
|
||||
```bash |
|
||||
$ npm start |
|
||||
|
|
||||
> hello-blockstack@0.0.0 start /Users/moxiegirl/repos/hello-blockstack |
|
||||
> webpack-dev-server |
|
||||
|
|
||||
Project is running at http://localhost:8080/ |
|
||||
webpack output is served from / |
|
||||
404s will fallback to /index.html |
|
||||
Hash: 4d2312ba236a4b95dc3a |
|
||||
Version: webpack 2.7.0 |
|
||||
Time: 2969ms |
|
||||
Asset Size Chunks Chunk Names |
|
||||
.... |
|
||||
Child html-webpack-plugin for "index.html": |
|
||||
chunk {0} index.html 541 kB [entry] [rendered] |
|
||||
[0] ./~/lodash/lodash.js 540 kB {0} [built] |
|
||||
[1] ./~/html-webpack-plugin/lib/loader.js!./src/index.html 533 bytes {0} [built] |
|
||||
[2] (webpack)/buildin/global.js 509 bytes {0} [built] |
|
||||
[3] (webpack)/buildin/module.js 517 bytes {0} [built] |
|
||||
webpack: Compiled successfully. |
|
||||
``` |
|
||||
|
|
||||
The system opens a browser displaying your running application. |
|
||||
|
|
||||
 |
|
||||
|
|
||||
At this point, the browser is running a Blockstack server on your local host. |
|
||||
This is for testing your applications only. |
|
||||
|
|
||||
6. Choose **Sign in with Blockstack** |
|
||||
|
|
||||
The system displays a prompt allowing you to create a new Blockstack ID or restore an existing one. |
|
||||
|
|
||||
 |
|
||||
|
|
||||
7. Follow the prompts appropriate to your situation. |
|
||||
|
|
||||
If you are restoring an existing ID, you may see a prompt about your user |
|
||||
being nameless, ignore it. At this point you have only a single application |
|
||||
on your test server. So, you should see this single application, with your |
|
||||
own `blockstack.id` display name, once you are signed in: |
|
||||
|
|
||||
 |
|
||||
|
|
||||
|
|
||||
### Add a redirect end point to your application |
|
||||
|
|
||||
When a user opens the webapp from the Blockstack browser on an Android phone, |
|
||||
you want the web app to redirect the user to your Android application. The work |
|
||||
you do here will allow it. |
|
||||
|
|
||||
1. From the terminal command line, change directory to the root of your sample |
|
||||
application directory. |
|
||||
|
|
||||
2. Use the `touch` command to add a redirect endpoint to your application. |
|
||||
|
|
||||
This endpoint on the web version of your app will redirect Android users back |
|
||||
to your mobile app. |
|
||||
|
|
||||
```bash |
|
||||
$ touch public/redirect.html |
|
||||
``` |
|
||||
|
|
||||
3. Open `redirect.html` and add code to the endpoint. |
|
||||
|
|
||||
```html |
|
||||
<!DOCTYPE html> |
|
||||
<html> |
|
||||
<head> |
|
||||
<title>Hello, Blockstack!</title> |
|
||||
<script> |
|
||||
function getParameterByName(name) { |
|
||||
var match = RegExp('[?&]' + name + '=([^&]*)').exec(window.location.search); |
|
||||
return match && decodeURIComponent(match[1].replace(/\+/g, ' ')); |
|
||||
} |
|
||||
|
|
||||
var authResponse = getParameterByName('authResponse') |
|
||||
window.location="myblockstackapp:" + authResponse |
|
||||
</script> |
|
||||
<body> |
|
||||
</body> |
|
||||
</html> |
|
||||
``` |
|
||||
|
|
||||
Blockstack apps are identified by their domain names. The endpoint will |
|
||||
receive a get request with the query parameter `authResponse=XXXX` and |
|
||||
should redirect the browser to `myblockstackapp:XXXX`. |
|
||||
|
|
||||
`myblockstackapp:` is custom protocol handler. The handler should be unique |
|
||||
to your application. Your app's web-based authentication uses this handler |
|
||||
to redirect the user back to your Android app. Later, you'll add a reference |
|
||||
to this handler in your Android application. |
|
||||
|
|
||||
5. Close and save the `redirect.html` file. |
|
||||
6. Ensure your Blockstack compiles successfully. |
|
||||
|
|
||||
## Create the hello-android project |
|
||||
|
|
||||
In this section, you'll create an Android application in Android Studio. You'll |
|
||||
run the application in the emulator to test it. |
|
||||
|
|
||||
### Create a simple project |
|
||||
|
|
||||
In this section, you create an inital project. You'll validate the application's |
|
||||
iniatial state by creating an emulator to run it in. Open Android Studio and do the following: |
|
||||
|
|
||||
|
|
||||
1. Open Android Studio and choose **Start a new Andriod Studio project**. |
|
||||
|
|
||||
If studio is already started, choose **File > New > New Project**. |
|
||||
|
|
||||
2. Enter these fields in the **Create Android Project** page. |
|
||||
|
|
||||
<table> |
|
||||
<tr> |
|
||||
<th>Application Name</th> |
|
||||
<td><code>hello-android</code></td> |
|
||||
</tr> |
|
||||
<tr> |
|
||||
<th>Company domain</th> |
|
||||
<td><code><i>USERNAME</i>.example.com</code></td> |
|
||||
</tr> |
|
||||
<tr> |
|
||||
<th>Project location</th> |
|
||||
<td><code>/Users/<i>USERNAME</i>/AndroidStudioProjects/helloandroid</code></td> |
|
||||
</tr> |
|
||||
<tr> |
|
||||
<th>Include Kotlin support</th> |
|
||||
<td>Set (checked)</td> |
|
||||
</tr> |
|
||||
</table> |
|
||||
|
|
||||
3. Press **Next** to display **Target Android Devices**. |
|
||||
4. Check **Phone and Tablet**. |
|
||||
5. Choose API 27: Andriod 8.1 (Oreo) for the target version. |
|
||||
6. Press **Next**. |
|
||||
7. Choose **Empty Activity** and press **Next**. |
|
||||
8. Leave the **Configure Activity** dialog with its defaults. |
|
||||
|
|
||||
 |
|
||||
|
|
||||
9. Press **Finish**. |
|
||||
|
|
||||
Android studio builds your initial project. This can take a bit the first time you do it. |
|
||||
|
|
||||
 |
|
||||
|
|
||||
### Run the app in an emulator |
|
||||
|
|
||||
In this section, you run the appliation and create an emulator when prompted. |
|
||||
|
|
||||
1. Once the project is imported into studio, click the `app` module in the **Project** window. |
|
||||
|
|
||||
2. Then, select **Run > Run** (or click the green arrow in the toolbar). |
|
||||
|
|
||||
Studio prompts you to **Select Deployment Target**. |
|
||||
|
|
||||
3. Choose **Create New Virtual Device** and press **OK**. |
|
||||
|
|
||||
Studio prompts you to **Select Hardware**. |
|
||||
|
|
||||
4. Choose a Phone running Pixel XL. |
|
||||
|
|
||||
 |
|
||||
|
|
||||
Studio prompts you for a system image. |
|
||||
|
|
||||
5. Choose **Oreo** which is API level 27 and press **Next**. |
|
||||
|
|
||||
 |
|
||||
|
|
||||
Studio asks you to verify your new emulator configuration. |
|
||||
|
|
||||
6. Press **Finish**. |
|
||||
|
|
||||
The emulation takes a moment to build. Then, studio launches the emulation and opens your application. |
|
||||
|
|
||||
 |
|
||||
|
|
||||
|
|
||||
### Configure your application with the Blockstack SDK |
|
||||
|
|
||||
Now that you have created your initial project and verified it running in an emulator, you are ready to begin configuring the application for use with Blockstack. |
|
||||
|
|
||||
1. In studio, open the `AndroidManifest.xml` file. |
|
||||
2. Add the a `launchMode` to the `.MainActivity` definition. |
|
||||
|
|
||||
```XML |
|
||||
<activity android:name=".MainActivity" android:launchMode="singleTask"> |
|
||||
``` |
|
||||
|
|
||||
Blockstack requires that the activity that starts the sign-in process also |
|
||||
handles the auth reponse token. This means that the activity needs to run in |
|
||||
`singleTask` launch mode. |
|
||||
|
|
||||
2. Add an `<intent-filter>` with the custom handler for Blockstack. |
|
||||
|
|
||||
```XML |
|
||||
<intent-filter> |
|
||||
<action android:name="android.intent.action.VIEW" /> |
|
||||
<category android:name="android.intent.category.DEFAULT" /> |
|
||||
<category android:name="android.intent.category.BROWSABLE" /> |
|
||||
<data android:scheme="myblockstackapp" /> |
|
||||
</intent-filter> |
|
||||
``` |
|
||||
|
|
||||
2. Open the Project's `build.gradle` file. |
|
||||
3. Add the Jitpack repository `maven { url 'https://jitpack.io' }` to the `repositories` section. |
|
||||
|
|
||||
When you finish, that section looks like this: |
|
||||
|
|
||||
```JS |
|
||||
allprojects { |
|
||||
repositories { |
|
||||
google() |
|
||||
jcenter() |
|
||||
maven { url 'https://jitpack.io' } |
|
||||
} |
|
||||
} |
|
||||
``` |
|
||||
|
|
||||
4. Open the Module `build.gradle` file. |
|
||||
5. Set the `defaultConfig minSdkVersion` to `19`. |
|
||||
|
|
||||
When you are done, you should see (within your own username not `moxiegirl`): |
|
||||
|
|
||||
```JS |
|
||||
android { |
|
||||
compileSdkVersion 27 |
|
||||
defaultConfig { |
|
||||
applicationId "com.example.moxiegirl.hello_android" |
|
||||
minSdkVersion 19 |
|
||||
targetSdkVersion 27 |
|
||||
versionCode 1 |
|
||||
versionName "1.0" |
|
||||
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner" |
|
||||
} |
|
||||
... |
|
||||
} |
|
||||
``` |
|
||||
|
|
||||
7. Below this, add the Blockstack Android SDK dependency to your project's `dependencies` list: |
|
||||
|
|
||||
When you are done you should see: |
|
||||
|
|
||||
```JS |
|
||||
dependencies { |
|
||||
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version" |
|
||||
implementation 'com.android.support:appcompat-v7:27.1.0' |
|
||||
implementation 'com.android.support.constraint:constraint-layout:1.1.2' |
|
||||
testImplementation 'junit:junit:4.12' |
|
||||
androidTestImplementation 'com.android.support.test:runner:1.0.2' |
|
||||
androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2' |
|
||||
implementation 'com.github.blockstack:blockstack-android:0.3.0' |
|
||||
} |
|
||||
|
|
||||
``` |
|
||||
|
|
||||
**NOTE**: Ignore the warning on the appcompat` dependencies. |
|
||||
|
|
||||
8. Sync your project. |
|
||||
|
|
||||
 |
|
||||
|
|
||||
Be sure to check the sync completed successfully. |
|
||||
|
|
||||
 |
|
||||
|
|
||||
10. Run your app in the emulator. |
|
||||
|
|
||||
You've made a lot of changes, make sure the emulator is still running |
|
||||
correctly. |
|
||||
|
|
||||
### Add a simple interface |
|
||||
|
|
||||
1. Open the `app/res/layout/activity_main.xml` file. |
|
||||
|
|
||||
The `activity_main.xml` file defines the graphical elements. Some elements are required before you can functionality to your `MainActivity.kt` code. |
|
||||
|
|
||||
3. Replace the entire content of the file with the following code: |
|
||||
|
|
||||
The new interface includes a `BlockstackSignInButton` which is provided by |
|
||||
the SDK. This SDK includes a themed "Sign in with Blockstack" button |
|
||||
(`BlockstackSignInButton`). You use this button in your here with the |
|
||||
`org.blockstack.android.sdk.ui.BlockstackSignInButton` class. |
|
||||
|
|
||||
```XML |
|
||||
<?xml version="1.0" encoding="utf-8"?> |
|
||||
<android.support.constraint.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android" |
|
||||
xmlns:app="http://schemas.android.com/apk/res-auto" |
|
||||
xmlns:tools="http://schemas.android.com/tools" |
|
||||
android:layout_width="match_parent" |
|
||||
android:layout_height="match_parent" |
|
||||
tools:context=".MainActivity"> |
|
||||
|
|
||||
<org.blockstack.android.sdk.ui.BlockstackSignInButton |
|
||||
android:id="@+id/signInButton" |
|
||||
android:layout_width="307dp" |
|
||||
android:layout_height="45dp" |
|
||||
android:layout_margin="4dp" |
|
||||
android:layout_marginEnd="185dp" |
|
||||
android:layout_marginStart="39dp" |
|
||||
app:layout_constraintEnd_toEndOf="parent" |
|
||||
app:layout_constraintStart_toStartOf="parent" |
|
||||
tools:layout_editor_absoluteY="16dp" /> |
|
||||
|
|
||||
<TextView |
|
||||
android:id="@+id/userDataTextView" |
|
||||
android:layout_width="370dp" |
|
||||
android:layout_height="27dp" |
|
||||
tools:layout_editor_absoluteX="6dp" |
|
||||
tools:layout_editor_absoluteY="70dp" /> |
|
||||
|
|
||||
</android |
|
||||
``` |
|
||||
|
|
||||
This codes adds a button and some text to your application. |
|
||||
|
|
||||
4. Choose **Run > Apply changes**. |
|
||||
|
|
||||
5. Choose **Run > Run app** in the emulator. |
|
||||
|
|
||||
The emulator now contains a new interface with a button: |
|
||||
|
|
||||
 |
|
||||
|
|
||||
### Add session & authentication code |
|
||||
|
|
||||
1. Open the `MainActivity.kt` file. |
|
||||
2. Add some additional imports to the top below the `android.os.Bundle` import. |
|
||||
|
|
||||
When you are done, your imports should appear as follows: |
|
||||
|
|
||||
```kotlin |
|
||||
|
|
||||
import android.support.v7.app.AppCompatActivity |
|
||||
import android.os.Bundle |
|
||||
|
|
||||
import android.support.v7.app.AppCompatActivity |
|
||||
import android.view.View |
|
||||
import kotlinx.android.synthetic.main.activity_main.* |
|
||||
import org.blockstack.android.sdk.BlockstackSession |
|
||||
import org.blockstack.android.sdk.Scope |
|
||||
import org.blockstack.android.sdk.UserData |
|
||||
import java.net.URI |
|
||||
``` |
|
||||
3. Add a variable for the Blockstack session before `onCreate`. |
|
||||
|
|
||||
```kotlin |
|
||||
class MainActivity : AppCompatActivity() { |
|
||||
|
|
||||
private var _blockstackSession: BlockstackSession? = null |
|
||||
|
|
||||
|
|
||||
override fun onCreate(savedInstanceState: Bundle?) { |
|
||||
super.onCreate(savedInstanceState) |
|
||||
setContentView(R.layout.activity_main) |
|
||||
} |
|
||||
} |
|
||||
``` |
|
||||
|
|
||||
4. Replace the existing the `onCreate` function with the following: |
|
||||
|
|
||||
```kotlin |
|
||||
override fun onCreate(savedInstanceState: Bundle?) { |
|
||||
super.onCreate(savedInstanceState) |
|
||||
setContentView(R.layout.activity_main) |
|
||||
|
|
||||
signInButton.isEnabled = false |
|
||||
|
|
||||
val appDomain = URI("https://flamboyant-darwin-d11c17.netlify.com") |
|
||||
val redirectURI = URI("${appDomain}/redirect") |
|
||||
val manifestURI = URI("${appDomain}/manifest.json") |
|
||||
val scopes = arrayOf(Scope.StoreWrite) |
|
||||
|
|
||||
val config = java.net.URI("https://flamboyant-darwin-d11c17.netlify.com").run { |
|
||||
org.blockstack.android.sdk.BlockstackConfig( |
|
||||
this, |
|
||||
redirectURI, |
|
||||
manifestURI, |
|
||||
scopes |
|
||||
} |
|
||||
|
|
||||
_blockstackSession = BlockstackSession(this, config, |
|
||||
onLoadedCallback = { |
|
||||
signInButton.isEnabled = true |
|
||||
}) |
|
||||
|
|
||||
|
|
||||
signInButton.setOnClickListener { view: View -> |
|
||||
blockstackSession().redirectUserToSignIn { userData -> |
|
||||
if (userData.hasValue) { |
|
||||
runOnUiThread { |
|
||||
onSignIn(userData.value!!) |
|
||||
} |
|
||||
} |
|
||||
} |
|
||||
} |
|
||||
if (intent?.action == Intent.ACTION_VIEW) { |
|
||||
// handle the redirect from sign in |
|
||||
handleAuthResponse(intent) |
|
||||
} |
|
||||
} |
|
||||
``` |
|
||||
|
|
||||
This new `onCreate` does several things: |
|
||||
|
|
||||
* Define the initial state for the `signInButton`. |
|
||||
* Supply authentication information for connecting to your Blockstack app: `appDomain`, `redirectURI`, `manifestURI` and `scopes` |
|
||||
* Add a listener for the button click. |
|
||||
|
|
||||
Notice that the application in this example is a URI you have not set up. |
|
||||
Registering and application name takes time, so in time's interest you'll |
|
||||
use an existing app that is identical to the `hello-world` you created |
|
||||
earlier. For a produciton verison, you'll need to replace `appDomain`, |
|
||||
`redirectURI`, `manifestURI` and `scopes` with values appropriate for your |
|
||||
app. |
|
||||
|
|
||||
5. Add a private function to reflect when a user successfully signs in. |
|
||||
|
|
||||
```kotlin |
|
||||
private fun onSignIn(userData: UserData) { |
|
||||
userDataTextView.text = "Signed in as ${userData.decentralizedID}" |
|
||||
|
|
||||
signInButton.isEnabled = false |
|
||||
|
|
||||
} |
|
||||
``` |
|
||||
|
|
||||
6. Handle sign in requests with an `onNewIntent` function if the activity was already opened when signing in |
|
||||
|
|
||||
Retrieve the authentication token from the custom protocol handler call and |
|
||||
send it to the Blockstack session. |
|
||||
|
|
||||
```kotlin |
|
||||
override fun onNewIntent(intent: Intent?) { |
|
||||
super.onNewIntent(intent) |
|
||||
|
|
||||
if (intent?.action == Intent.ACTION_VIEW) { |
|
||||
handleAuthResponse(intent) |
|
||||
} |
|
||||
} |
|
||||
``` |
|
||||
|
|
||||
7. Create a handler for the authentication response. |
|
||||
|
|
||||
```kotlin |
|
||||
private fun handleAuthResponse(intent: Intent) { |
|
||||
val response = intent.dataString |
|
||||
if (response != null) { |
|
||||
val authResponseTokens = response.split(':') |
|
||||
|
|
||||
if (authResponseTokens.size > 1) { |
|
||||
val authResponse = authResponseTokens[1] |
|
||||
|
|
||||
blockstackSession().handlePendingSignIn(authResponse, { userData -> |
|
||||
if (userData.hasValue) { |
|
||||
// The user is now signed in! |
|
||||
runOnUiThread { |
|
||||
onSignIn(userData.value!!) |
|
||||
} |
|
||||
} |
|
||||
}) |
|
||||
} |
|
||||
} |
|
||||
} |
|
||||
``` |
|
||||
|
|
||||
8. Add the convenience method to access the blockstack session. |
|
||||
|
|
||||
```kotlin |
|
||||
fun blockstackSession() : BlockstackSession { |
|
||||
val session = _blockstackSession |
|
||||
if(session != null) { |
|
||||
return session |
|
||||
} else { |
|
||||
throw IllegalStateException("No session.") |
|
||||
} |
|
||||
} |
|
||||
``` |
|
||||
|
|
||||
9. Verify your final `MainActivity.kt` code looks like this: |
|
||||
|
|
||||
```kotlin |
|
||||
class MainActivity : AppCompatActivity() { |
|
||||
|
|
||||
private var _blockstackSession: BlockstackSession? = null |
|
||||
|
|
||||
|
|
||||
override fun onCreate(savedInstanceState: Bundle?) { |
|
||||
super.onCreate(savedInstanceState) |
|
||||
setContentView(R.layout.activity_main) |
|
||||
|
|
||||
signInButton.isEnabled = false |
|
||||
|
|
||||
val appDomain = URI("https://flamboyant-darwin-d11c17.netlify.com") |
|
||||
val redirectURI = URI("${appDomain}/redirect") |
|
||||
val manifestURI = URI("${appDomain}/manifest.json") |
|
||||
val scopes = arrayOf(Scope.StoreWrite) |
|
||||
|
|
||||
_blockstackSession = BlockstackSession(this, appDomain, redirectURI, manifestURI, scopes, |
|
||||
onLoadedCallback = {signInButton.isEnabled = true |
|
||||
}) |
|
||||
|
|
||||
|
|
||||
signInButton.setOnClickListener { view: View -> |
|
||||
blockstackSession().redirectUserToSignIn { userData -> |
|
||||
if (userData.hasValue) { |
|
||||
runOnUiThread { |
|
||||
onSignIn(userData) |
|
||||
} |
|
||||
} |
|
||||
} |
|
||||
} |
|
||||
if (intent?.action == Intent.ACTION_VIEW) { |
|
||||
handleAuthResponse(intent) |
|
||||
} |
|
||||
} |
|
||||
|
|
||||
private fun onSignIn(userData: UserData) { |
|
||||
userDataTextView.text = "Signed in as ${userData.decentralizedID}" |
|
||||
|
|
||||
signInButton.isEnabled = false |
|
||||
|
|
||||
} |
|
||||
|
|
||||
override fun onNewIntent(intent: Intent?) { |
|
||||
super.onNewIntent(intent) |
|
||||
|
|
||||
if (intent?.action == Intent.ACTION_VIEW) { |
|
||||
handleAuthResponse(intent) |
|
||||
} |
|
||||
} |
|
||||
|
|
||||
private fun handleAuthResponse(intent: Intent) { |
|
||||
val response = intent.dataString |
|
||||
if (response != null) { |
|
||||
val authResponseTokens = response.split(':') |
|
||||
|
|
||||
if (authResponseTokens.size > 1) { |
|
||||
val authResponse = authResponseTokens[1] |
|
||||
|
|
||||
blockstackSession().handlePendingSignIn(authResponse, { userData -> |
|
||||
if (userData.hasValue) { |
|
||||
// The user is now signed in! |
|
||||
runOnUiThread { |
|
||||
onSignIn(userData.value!!) |
|
||||
} |
|
||||
} |
|
||||
}) |
|
||||
} |
|
||||
} |
|
||||
} |
|
||||
|
|
||||
fun blockstackSession() : BlockstackSession { |
|
||||
val session = _blockstackSession |
|
||||
if(session != null) { |
|
||||
return session |
|
||||
} else { |
|
||||
throw IllegalStateException("No session.") |
|
||||
} |
|
||||
} |
|
||||
|
|
||||
|
|
||||
} |
|
||||
``` |
|
||||
|
|
||||
### Run the final app in the emulator |
|
||||
|
|
||||
1. Choose **Run > Apply changes**. |
|
||||
2. Choose **Run > Run app** in the emulator. |
|
||||
3. When you see the application open, choose **Sign in with Blockstack**. |
|
||||
|
|
||||
The system prompts you how to open. |
|
||||
|
|
||||
 |
|
||||
|
|
||||
4. Choose **Chrome** and click **ALWAYS**. |
|
||||
5. Move through the rest of the Chrome prompts. |
|
||||
|
|
||||
The system presents you with your final application. |
|
||||
|
|
||||
 |
|
||||
|
|
||||
6. Work through the Blockstack prompts to login. |
|
||||
|
|
||||
|
|
||||
## Where to go next |
|
||||
|
|
||||
Congratulations, you've completed your Android app using the new, pre-release |
|
||||
Blockstack Android SDK. Thank you for trying this pre-release. Please let us |
|
||||
know about your experience by tweeting to |
|
||||
[@blockstack](https://twitter.com/blockstack). |
|
||||
|
|
||||
Learn more about Blockstack by [trying another tutorial](https://blockstack.org/tutorials). |
|
||||
|
Before Width: | Height: | Size: 179 KiB |
|
Before Width: | Height: | Size: 35 KiB |
|
Before Width: | Height: | Size: 60 KiB |
|
Before Width: | Height: | Size: 13 KiB |
|
Before Width: | Height: | Size: 46 KiB |
|
Before Width: | Height: | Size: 111 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 40 KiB |
|
Before Width: | Height: | Size: 100 KiB |
|
Before Width: | Height: | Size: 575 KiB |
@ -1 +0,0 @@ |
|||||
12 |
|
||||
@ -1 +0,0 @@ |
|||||
12 |
|
||||
@ -1,2 +0,0 @@ |
|||||
|
|
||||
The documentation has been moved to [docs.blockstack.org](https://docs.blockstack.org/), please update your bookmarks. |
|
||||
@ -1,126 +0,0 @@ |
|||||
--- |
|
||||
layout: core |
|
||||
permalink: /:collection/:path.html |
|
||||
--- |
|
||||
# BNS Forks |
|
||||
|
|
||||
BNS effectively uses a public blockchain to store a database log. A BNS peer |
|
||||
bootstraps itself by downloading and replaying the database log from the |
|
||||
blockchain, and in doing so, will calculate the same name database state as |
|
||||
every other (honest) BNS peer that has the same view of the blockchain. |
|
||||
|
|
||||
Crucially, BNS is built on top of a public blockchain that is *unaware* of BNS's existence. |
|
||||
This means that the blockchain peers do not validate BNS transactions. Instead, |
|
||||
the BNS peer needs to do so, and must know how to *reject* both invalid transactions |
|
||||
as well as well-formed transactions from dishonest peers (i.e. peers that do not |
|
||||
follow the same consensus rules). |
|
||||
|
|
||||
BNS nodes do not directly communicate with one another---by design, the set of |
|
||||
BNS peers is not enumerable. The only shared communication medium between BNS |
|
||||
peers is the blockchain. |
|
||||
|
|
||||
To identify and reject invalid and malicious transactions without the blockchain's help, |
|
||||
the log of name operations embedded in the blockchain is constructed as a |
|
||||
[fork\*-consistent](http://www.scs.stanford.edu/~jinyuan/bft2f.pdf) database |
|
||||
log. Fork\*-consistency is a [consistency |
|
||||
model](https://en.wikipedia.org/wiki/Consistency_model) whereby the state |
|
||||
replicas in all of the nodes exhibit the following properties: |
|
||||
|
|
||||
* Each correct peer maintains a history of well-formed, valid state operations. In this |
|
||||
case, each correct BNS node maintains a copy of the history blockchain transactions |
|
||||
that encoded well-formed, valid name operations. |
|
||||
|
|
||||
* Each honest peer's history contains the sequence of all operations that it |
|
||||
sent. That is, a user's BNS peer's transaction log will contain the sequence of all valid |
|
||||
transactions that the user's client wrote to the blockchain. |
|
||||
|
|
||||
* If two peers accept operations *op* and *op'* from the same correct client, |
|
||||
then both of their logs will have the both operations in the same order. If |
|
||||
*op'* was accepted before *op*, then both peers' logs are identical up to *op'*. |
|
||||
In BNS, this means that if two peers both accept a given transaction, then it |
|
||||
means that they have accepted the same sequence of prior transactions. |
|
||||
|
|
||||
This means that unlike with blockchains, |
|
||||
there can be *multiple long-lived conflicting forks* of the BNS database log. |
|
||||
However, due to fork\*-consistency, a correct BNS peer will only process *one* |
|
||||
of these forks, and will *ignore* transactions from peers in other forks. In other words, |
|
||||
fork\*-consistency partitions the set of BNS peers into different **fork-sets**, |
|
||||
where all peers in a fork-set process each other's transactions, but the |
|
||||
completely ignore peers in other fork-sets. |
|
||||
|
|
||||
BNS nodes identify which fork set they belong to using a **consensus hash**. The |
|
||||
consensus hash is a cryptographic digest of a node's operation |
|
||||
history. Each BNS peer calculates a new consensus hash each time it processes a |
|
||||
new block, and stores the history of consensus hashes for each block it |
|
||||
processed. |
|
||||
|
|
||||
Two honest BNS peers can quickly determine if they are in the same fork-set by querying |
|
||||
each other's consensus hashes for a given block. If they match, then they are |
|
||||
in the same fork-set (assming no hash collisions). |
|
||||
|
|
||||
A BNS client executes a name operation on a specific fork-set by including a |
|
||||
recent consensus hash from that fork-set in the blockchain transaction. |
|
||||
At the same time, the BNS consensus rules state that a transaction can only be |
|
||||
accepted if it included a recent valid consensus hash. |
|
||||
This means that all BNS nodes in the client's desired fork-set will accept |
|
||||
the transaction, and all other BNS nodes not in the fork-set will ignore it. |
|
||||
You can see where the consensus hash is included in blockchain transactions by reading |
|
||||
the [transaction wire format]({{ site.baseurl }}/core/wire-format.html) document. |
|
||||
|
|
||||
## Fork-set Selection |
|
||||
|
|
||||
The blockchain linearizes the history of transactions, which means that |
|
||||
in general, there exists a fork-set for each distinct set of BNS |
|
||||
consensus rules. For example, the Blockstack Core [2016 hard fork](https://github.com/blockstack/blockstack-core/blob/master/release_notes/changelog-0.14.md) |
|
||||
and [2017 hard fork](https://github.com/blockstack/blockstack-core/blob/master/release_notes/changelog-0.17.md) both introduced new consensus |
|
||||
rules, which means at the time of this writing there are three possible fork-sets: |
|
||||
the pre-2016 fork-set, the 2016-2017 fork-set, and the post-2017 fork-set. |
|
||||
The [public BNS nodes](https://node.blockstack.org:6263) are always running |
|
||||
in the fork-set with the latest consensus rules. |
|
||||
|
|
||||
BNS clients are incentivized to communicate with peers in the fork-set that has |
|
||||
the most use, since this fork-set's name database will encode name/state |
|
||||
bindings that are the most widely-accepted and understood by users. |
|
||||
To identify this fork-set, a BNS client needs to learn one of |
|
||||
its recent consensus hashes. Once it has a recent consensus hash, it can |
|
||||
query an *untrusted* BNS node for a copy of |
|
||||
its name database, and use the consensus hash to verify that the name database |
|
||||
was used to generate it. |
|
||||
|
|
||||
How does a BNS node determine whether or not a consensus hash corresponds to the |
|
||||
most widely-used fork-set? There are two strategies: |
|
||||
|
|
||||
* Determine whether or not a *characteristic transaction* was accepted by the |
|
||||
widely-used fork-set. If a client knows that a specific transaction belongs to |
|
||||
the widely-used fork-set and not others, then they can use the consensus hash to |
|
||||
efficiently determine whether or not a given node belongs to this fork-set. |
|
||||
|
|
||||
* Determine how much "economic activity" exists in a fork-set by inspecting |
|
||||
the blockchain for burned cryptocurrency tokens. Namespace and name |
|
||||
registrations are structured in a way that sends cryptocurrency tokens to either |
|
||||
a well-known burn address, or to an easily-queried pay-to-namespace-creator |
|
||||
address. |
|
||||
|
|
||||
Both strategies rely on the fact that the consensus hash is calculated as a |
|
||||
[Merkle skip-list](https://github.com/blockstack/blockstack-core/issues/146) |
|
||||
over the BNS node's accepted transactions. A client can use a consensus hash to |
|
||||
determine whether or not a transaction *T* was accepted by a node with *O(log |
|
||||
n)* time and space complexity. We call the protocol for resolving a consensus hash to a specific transaction |
|
||||
**Simplified Name Verification** (SNV). See our [paper on the subject](https://blockstack.org/virtualchain_dccl16.pdf) |
|
||||
for details of how SNV works under the hood. |
|
||||
|
|
||||
If the client has a consensus hash and knows of a characteristic transaction in the widely-used fork-set, |
|
||||
it can use SNV to determine whether or not a node belongs to the fork-set that accepted it. |
|
||||
|
|
||||
If the client knows about multiple conflicting consensus hashes, |
|
||||
they can still use SNV to determine which one corresponds |
|
||||
to the most-used fork-set. To do so, the client would use a |
|
||||
[blockchain explorer](https://explorer.blockstack.org) to find the |
|
||||
list of transactions that burned cryptocurrency tokens. Each of these |
|
||||
transactions will be treated as potential characteristic transactions: |
|
||||
the client would first select the subset of transactions that are well-formed |
|
||||
BNS transactions, and then use SNV to determine which of them correspond to which |
|
||||
consensus hashes. The client chooses the consensus hash that corresponds |
|
||||
to the fork-set with the highest cumulative burn. |
|
||||
|
|
||||
Work is currently underway to automate this process. |
|
||||
|
Before Width: | Height: | Size: 61 KiB |
@ -1,187 +0,0 @@ |
|||||
--- |
|
||||
layout: core |
|
||||
permalink: /:collection/:path.html |
|
||||
--- |
|
||||
# How to build a Profile Search Index |
|
||||
|
|
||||
The search subsystem for Blockstack Core creates an index for data associated |
|
||||
with registered names in namespaces and makes that data searchable. |
|
||||
|
|
||||
The search subsystem is currently meant to index the .id namespace but can |
|
||||
be easily expanded to include other namespaces. |
|
||||
|
|
||||
Currently there are two types of indexes to handle search queries: |
|
||||
|
|
||||
* Substring search on usernames, full names, twitter_handle (powered by MongoDB) |
|
||||
* Raw Lucene index which handles searching extended data e.g., bio. |
|
||||
|
|
||||
Search will currently return upto a max of 20 results (can be less depending on the query) |
|
||||
with data that follows structure of [blockstack IDs](https://github.com/blockstack/blockstack): |
|
||||
|
|
||||
In early 2017, the search subsystem was ported over to the new API system, where support for search is provided by the endpoint: |
|
||||
|
|
||||
``` |
|
||||
http://localhost:5000/search?query=<SEARCH_PATTERN> |
|
||||
``` |
|
||||
|
|
||||
This document describes how to setup the search subsystem to respond at that endpoint. |
|
||||
|
|
||||
# Installation |
|
||||
|
|
||||
- **Step 1:** First, make sure you have [virtualenv installed](http://docs.python-guide.org/en/latest/dev/virtualenvs/). |
|
||||
Then, setup the API and search subsystem: |
|
||||
``` |
|
||||
$ sudo apt-get install -y mongodb memcached python-dev libmemcached-dev zlib1g-dev nginx |
|
||||
$ sudo pip install uwsgi |
|
||||
$ git clone https://github.com/blockstack/blockstack-core.git --branch api |
|
||||
$ cd blockstack-core/ |
|
||||
$ sudo pip install . |
|
||||
$ sudo pip install -r api/requirements.txt |
|
||||
$ sudo mkdir /var/blockstack-search && sudo chown $USER:$USER /var/blockstack-search |
|
||||
``` |
|
||||
|
|
||||
- **Step 2:** Make sure you have Blockstack Core running locally (see [instructions](https://github.com/blockstack/blockstack-core/blob/master/README.md#quick-start)). We highly |
|
||||
recommend using a local node because the search subsystem issues thousands of calls to |
|
||||
Blockstack Core for re-indexing and remote nodes can slow down performance. |
|
||||
|
|
||||
- **Step 3:** Fetch the data for the .id namespace and respective profiles. Note, you may want to redirect stderr to a file, as there is a lot of debug output. |
|
||||
|
|
||||
``` |
|
||||
$ cd api/ |
|
||||
|
|
||||
$ python -m search.fetch_data --fetch_namespace |
|
||||
|
|
||||
$ python -m search.fetch_data --fetch_profiles |
|
||||
``` |
|
||||
|
|
||||
- **Step 4:** Create the search index: |
|
||||
|
|
||||
``` |
|
||||
python -m search.basic_index --refresh |
|
||||
``` |
|
||||
|
|
||||
- **Step 5:** Enable search API endpoint: |
|
||||
|
|
||||
``` |
|
||||
$ sed -i 's/SEARCH_API_ENDPOINT_ENABLED \= False/SEARCH_API_ENDPOINT_ENABLED \= True/' config.py |
|
||||
``` |
|
||||
|
|
||||
# Usage |
|
||||
|
|
||||
You can quickly test the search index from the command line: |
|
||||
|
|
||||
``` |
|
||||
python -m search.substring_search --search_name "Fred Wil" |
|
||||
python -m search.substring_search --search_twitter fredwil |
|
||||
``` |
|
||||
|
|
||||
You can also use the search API end-point: |
|
||||
|
|
||||
> curl -G {machine_ip}:port/search/name -d "query=muneeb" |
|
||||
|
|
||||
Sample Response: |
|
||||
|
|
||||
``` |
|
||||
{ |
|
||||
"people": [ |
|
||||
{ |
|
||||
"profile": { |
|
||||
"website": [ |
|
||||
{ |
|
||||
"url": "http://muneebali.com", |
|
||||
"@type": "WebSite" |
|
||||
} |
|
||||
], |
|
||||
"name": "Muneeb Ali", |
|
||||
"address": { |
|
||||
"addressLocality": "New York, NY", |
|
||||
"@type": "PostalAddress" |
|
||||
}, |
|
||||
"image": [ |
|
||||
{ |
|
||||
"contentUrl": "https://s3.amazonaws.com/dx3/muneeb", |
|
||||
"@type": "ImageObject", |
|
||||
"name": "cover" |
|
||||
}, |
|
||||
{ |
|
||||
"contentUrl": "https://s3.amazonaws.com/kd4/muneeb", |
|
||||
"@type": "ImageObject", |
|
||||
"name": "avatar" |
|
||||
} |
|
||||
], |
|
||||
"@type": "Person", |
|
||||
"description": "Co-founder of Blockstack. Interested in distributed systems and blockchains. Previously, PhD at Princeton." |
|
||||
}, |
|
||||
"username": "muneeb" |
|
||||
}, |
|
||||
{ |
|
||||
"profile": { |
|
||||
"message": "This blockchain ID is reserved for Muneeb Ali. If this is you, please email support@onename.com to claim it for free.", |
|
||||
"status": "reserved" |
|
||||
}, |
|
||||
"username": "muneebali" |
|
||||
}, |
|
||||
{ |
|
||||
"profile": { |
|
||||
"cover": { |
|
||||
"url": "https://s3.amazonaws.com/97p/HHE.jpg" |
|
||||
}, |
|
||||
"v": "0.2" |
|
||||
}, |
|
||||
"username": "muneebali1" |
|
||||
} |
|
||||
|
|
||||
] |
|
||||
} |
|
||||
``` |
|
||||
|
|
||||
## Enabling Elastic Search |
|
||||
|
|
||||
### Requirements: |
|
||||
|
|
||||
``` |
|
||||
sudo apt-get install mongodb |
|
||||
sudo apt-get install memcached libmemcached-dev |
|
||||
sudo apt-get install python2.7-dev |
|
||||
pip install -r requirements.txt |
|
||||
``` |
|
||||
|
|
||||
### Elastic Search |
|
||||
|
|
||||
Elastic Search library is not in github and resides at unix/lib/elastic |
|
||||
|
|
||||
the current version we're using is *0.90.2*. Download from: |
|
||||
|
|
||||
> wget https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-0.90.2.zip |
|
||||
|
|
||||
before installing pylimbmc make sure [memcached]({{ site.baseurl }}/core/memcached.html) is installed. |
|
||||
|
|
||||
Ensure that mongodb and elastic search are running |
|
||||
starting elastic search: |
|
||||
|
|
||||
``` |
|
||||
$elasticsearch (on mac) |
|
||||
bin/elasticsearch -d (on linux) |
|
||||
``` |
|
||||
|
|
||||
To test if elastic search is running: |
|
||||
|
|
||||
> curl -X GET http://localhost:9200/ |
|
||||
|
|
||||
returns: |
|
||||
|
|
||||
``` |
|
||||
{ |
|
||||
"ok" : true, |
|
||||
"status" : 200, |
|
||||
"name" : "Angler", |
|
||||
"version" : { |
|
||||
"number" : "0.90.2", |
|
||||
"snapshot_build" : false, |
|
||||
"lucene_version" : "4.3.1" |
|
||||
}, |
|
||||
``` |
|
||||
|
|
||||
Create Index: |
|
||||
|
|
||||
> python create_search_index.py --create_index |
|
||||
|
Before Width: | Height: | Size: 62 KiB |
@ -1,67 +0,0 @@ |
|||||
# About |
|
||||
|
|
||||
This document is for **Linux users who do not want to use Docker** to run the |
|
||||
Blockstack Browser. Instructions are tailored for Ubuntu, but are similar on other distributions. |
|
||||
|
|
||||
# Setting up Blockstack Browser Node Application |
|
||||
|
|
||||
Install NodeJS through NodeSource PPA |
|
||||
|
|
||||
``` |
|
||||
curl -sL https://deb.nodesource.com/setup_7.x | sudo -E bash - |
|
||||
sudo apt install -y nodejs |
|
||||
``` |
|
||||
|
|
||||
Download Blockstack Browser and install its dependencies |
|
||||
|
|
||||
``` |
|
||||
git clone https://github.com/blockstack/blockstack-browser.git |
|
||||
cd blockstack-browser |
|
||||
npm install node-sass |
|
||||
npm install |
|
||||
``` |
|
||||
|
|
||||
Note that `blockstack-browser` depends on `node-sass` which can sometimes install strangely on Linux, running `npm install node-sass` before trying to install the other dependencies solves that problem. |
|
||||
|
|
||||
# Running Blockstack Browser |
|
||||
|
|
||||
Start the CORS proxy. |
|
||||
|
|
||||
``` |
|
||||
npm run dev-proxy & |
|
||||
``` |
|
||||
|
|
||||
Start the Node Application |
|
||||
|
|
||||
``` |
|
||||
npm run dev |
|
||||
``` |
|
||||
|
|
||||
Then you can open `http://localhost:3000/` in your browser to get to the Blockstack Browser. |
|
||||
|
|
||||
|
|
||||
## Setting up a protocol handler |
|
||||
|
|
||||
If you'd like your browser to automatically handle links with the `blockstack:` protocol specifier, you will need to register a protocol handler with your desktop environment. In Ubuntu/Gnome, this can be done by creating a file |
|
||||
|
|
||||
`~/.local/share/applications/blockstack.desktop` |
|
||||
|
|
||||
With the following contents: |
|
||||
|
|
||||
``` |
|
||||
[Desktop Entry] |
|
||||
Type=Application |
|
||||
Terminal=false |
|
||||
Exec=bash -c 'xdg-open http://localhost:3000/auth?authRequest=$(echo "%u" | sed s,blockstack:////*,,)' |
|
||||
Name=Blockstack-Browser |
|
||||
MimeType=x-scheme-handler/blockstack; |
|
||||
``` |
|
||||
|
|
||||
Then you need to make this file executable, and register it as a protocol handler. |
|
||||
|
|
||||
``` |
|
||||
$ chmod +x ~/.local/share/applications/blockstack.desktop |
|
||||
$ xdg-mime default blockstack.desktop x-scheme-handler/blockstack |
|
||||
``` |
|
||||
|
|
||||
Now, `blockstack:` protocol URLs should get handled by your Blockstack Browser. If you're running Browser in your browser's private mode, you may have to copy and paste the link, as this protocol handler will try to open in a regular browser window. |
|
||||
@ -1,71 +0,0 @@ |
|||||
--- |
|
||||
layout: core |
|
||||
permalink: /:collection/:path.html |
|
||||
--- |
|
||||
# How to link your OpenBazaar GUID to your Blockstack ID |
|
||||
{:.no_toc} |
|
||||
* TOC |
|
||||
{:toc} |
|
||||
|
|
||||
If you don't have the Blockstack CLI. Download and install it first. Instructions are [here](https://github.com/blockstack/blockstack-cli/blob/master/README.md). The rest of this tutorial assumes that you've already registered a name using the Blockstack CLI. |
|
||||
|
|
||||
## Step 1: Advanced Mode |
|
||||
|
|
||||
The first step is to activate "advanced mode" in the CLI. The command to do so is: |
|
||||
|
|
||||
``` |
|
||||
$ blockstack set_advanced_mode on |
|
||||
``` |
|
||||
|
|
||||
## Step 2: Add an OpenBazaar Account |
|
||||
|
|
||||
The second step is to create an OpenBazaar account for your profile (the [Onename](https://onename.com) app also enabled to link your OpenBazaar GUID). The command to do so is: |
|
||||
|
|
||||
``` |
|
||||
$ blockstack put_account "<BLOCKSTACK ID>" "openbazaar" "<YOUR OB GUID>" "<URL TO YOUR STORE>" |
|
||||
``` |
|
||||
|
|
||||
The URL can be any valid URL; it won't be used by OpenBazaar. Here's an example, using the name `testregistration001.id` and the GUID `0123456789abcdef`: |
|
||||
|
|
||||
``` |
|
||||
$ blockstack put_account "testregistration001.id" "openbazaar" "0123456789abcdef" "https://bazaarbay.org/@testregistration001" |
|
||||
``` |
|
||||
|
|
||||
The update should be instantaneous. You can verify that your store is present with `list_accounts`: |
|
||||
|
|
||||
``` |
|
||||
$ blockstack list_accounts "testregistration001.id" |
|
||||
{ |
|
||||
"accounts": [ |
|
||||
{ |
|
||||
"contentUrl": "https://bazaarbay.org/@testregistration001.id", |
|
||||
"identifier": "0123456789abcdef", |
|
||||
"service": "openbazaar" |
|
||||
} |
|
||||
] |
|
||||
} |
|
||||
```` |
|
||||
|
|
||||
# Troubleshooting |
|
||||
|
|
||||
Common problems you might encounter. |
|
||||
|
|
||||
## Profile is in legacy format |
|
||||
|
|
||||
If you registered your blockstack ID before spring 2016, there's a chance that your profile is still in a legacy format. It will get migrated to the new format automatically if you update your profile on the [Onename](https://onename.com) app. However, you have to do this manually with the CLI. |
|
||||
|
|
||||
To do so, the command is: |
|
||||
``` |
|
||||
$ blockstack migrate <YOUR BLOCKSTACK ID> |
|
||||
``` |
|
||||
|
|
||||
It will take a little over an hour to complete, but once finished, you'll be able to manage your accounts with the above commands (and do so with no delays). |
|
||||
|
|
||||
## Failed to broadcast update transaction |
|
||||
|
|
||||
This can happen during a `migrate` for one of a few reasons: |
|
||||
* You do not have enough balance to pay the transaction fee (which is calculated dynamically). |
|
||||
* Your payment address has unconfirmed transactions. |
|
||||
* You can't connect to a Bitcoin node. |
|
||||
|
|
||||
To determine what's going on, you should try the command again by typing `BLOCKSTACK_DEBUG=1 blockstack ...` instead of `blockstack...`. |
|
||||
@ -1,461 +0,0 @@ |
|||||
# LEGACY DOCUMENTATION |
|
||||
|
|
||||
Please see the [latest Gaia documentation](https://github.com/blockstack/gaia) |
|
||||
|
|
||||
Gaia: The Blockstack Storage System |
|
||||
==================================== |
|
||||
|
|
||||
The Blockstack storage system, called "Gaia", is used to host each user's data |
|
||||
without requiring users to run their own servers. |
|
||||
|
|
||||
Gaia works by hosting data in one or more existing storage systems of the user's choice. |
|
||||
These storage systems include cloud storage systems like Dropbox and Google |
|
||||
Drive, they include personal servers like an SFTP server or a WebDAV server, and |
|
||||
they include decentralized storage systems like BitTorrent or IPFS. The point |
|
||||
is, the user gets to choose where their data lives, and Gaia enables |
|
||||
applications to access it via a uniform API. |
|
||||
|
|
||||
A high-level analogy is to compare Gaia to the VFS and block layer in a UNIX |
|
||||
operating system kernel, and to compare existing storage systems to block |
|
||||
devices. Gaia has "drivers" for each storage system that allow it to load, |
|
||||
store, and delete chunks of data via a uniform interface, and it gives |
|
||||
applications a familiar API for organizing their data. |
|
||||
|
|
||||
Applications interface with Gaia via the [Blockstack Core |
|
||||
API](https://github.com/blockstack/blockstack-core/tree/master/api). Javascript |
|
||||
applications connect to Gaia using [Blockstack Portal](https://github.com/blockstack/blockstack-portal), |
|
||||
which helps them bootstrap a secure connection to Blockstack Core. |
|
||||
|
|
||||
# Datastores |
|
||||
|
|
||||
Gaia organizes data into datastores. A **datastore** is a filesystem-like |
|
||||
collection of data that is backed by one or more existing storage systems. |
|
||||
|
|
||||
When a user logs into an application, the application will create or connect to |
|
||||
the datastore that holds the user's data. Once connected, it can proceed to |
|
||||
interact with its data via POSIX-like functions: `mkdir`, `listdir`, `rmdir`, |
|
||||
`getFile`, `putFile`, `deleteFile`, and `stat`. |
|
||||
|
|
||||
A datastore has exactly one writer: the user that creates it. However, all data |
|
||||
within a datastore is world-readable by default, so other users can see the |
|
||||
owner's writes even when the owner is offline. Users manage access controls |
|
||||
by encrypting files and directories to make them readable to other specific users. |
|
||||
All data in a datastore is signed by a datastore-specific key on write, in order |
|
||||
to guarantee that readers only consume authentic data. |
|
||||
|
|
||||
The application client handles all of the encryption and signing. The other |
|
||||
participants---Blockstack Portal, Blockstack Core, and the storage |
|
||||
systems---only ferry data back and forth between application clients. |
|
||||
|
|
||||
## Data Organization |
|
||||
|
|
||||
True to its filesystem inspiration, data in a datastore is organized into a |
|
||||
collection of inodes. Each inode has two parts: |
|
||||
|
|
||||
* a **header**, which contains: |
|
||||
|
|
||||
* the inode type (i.e. file or directory) |
|
||||
|
|
||||
* the inode ID (i.e. a UUID4) |
|
||||
|
|
||||
* the hash of the data it stores |
|
||||
|
|
||||
* the size of the data it stores |
|
||||
|
|
||||
* a signature from the user |
|
||||
|
|
||||
* the version number |
|
||||
|
|
||||
* the ID of the device from which it was sent (see Advanced Topics below) |
|
||||
|
|
||||
* a **payload**, which contains the raw bytes to be stored. |
|
||||
|
|
||||
* For files, this is just the raw bytes. |
|
||||
|
|
||||
* For directories, this is a serialized data structure that lists the names |
|
||||
and inode IDs of its children, as well as a copy of the header. |
|
||||
|
|
||||
The header has a fixed length, and is somewhat small--only a few hundred bytes. |
|
||||
The payload can be arbitrarily large. |
|
||||
|
|
||||
## Data Consistency |
|
||||
|
|
||||
The reason for organizing data this way is to make cross-storage system reads |
|
||||
efficient, even when there are stale copies of the data available. In this |
|
||||
organization, reading an inode's data is a matter of: |
|
||||
|
|
||||
1. Fetching all copies of the header |
|
||||
|
|
||||
2. Selecting the header with the highest version number |
|
||||
|
|
||||
3. Fetching the payload from the storage system that served the latest header. |
|
||||
|
|
||||
This way, we can guarantee that: |
|
||||
|
|
||||
* The inode payload is fetched *once* in the common case, even if there are multiple stale copies of the inode available. |
|
||||
|
|
||||
* All clients observe the *strongest* consistency model offerred by the |
|
||||
underlying storage providers. |
|
||||
|
|
||||
* All readers observe a *minimum* consistency of monotonically-increasing reads. |
|
||||
|
|
||||
* Writers observe sequential consistency. |
|
||||
|
|
||||
This allows Gaia to interface with decentralized storage systems that make |
|
||||
no guarantees regarding data consistency. |
|
||||
|
|
||||
*(Aside 1: The Core node keeps track of the highest last-seen inode version number, |
|
||||
so if all inodes are stale, then no data will be returned).* |
|
||||
|
|
||||
*(Aside 2: In step 3, an error path exists whereby all storage systems will be |
|
||||
queried for the payload if the storage system that served the fresh inode does |
|
||||
not have a fresh payload).* |
|
||||
|
|
||||
# Accessing the Datastore |
|
||||
|
|
||||
Blockstack applications get access to the datastore as part of the sign-in |
|
||||
process. Suppose the user wishes to sign into the application `foo.app`. Then, |
|
||||
the following protocol is executed: |
|
||||
|
|
||||
 |
|
||||
|
|
||||
1. Using `blockstack.js`, the application authenticates to Blockstack Portal via |
|
||||
`makeAuthRequest()` and `redirectUserToSignIn()`. |
|
||||
|
|
||||
2. When Portal receives the request, it contacts the user's Core node to get the |
|
||||
list of names owned by the user. |
|
||||
|
|
||||
3. Portal redirects the user to a login screen, and presents the user with the |
|
||||
list of names to use. The user selects which name to sign in as. |
|
||||
|
|
||||
4. Now that Portal knows which name to use, and which application is signing in, |
|
||||
it loads the datastore private key and requests a Blockstack Core session |
|
||||
token. This token will be used by the application to access Gaia. |
|
||||
|
|
||||
5. Portal creates an authentication response with `makeAuthResponse()`, which it |
|
||||
relays back to the application. |
|
||||
|
|
||||
6. The application retrieves the datastore private key and the Core session |
|
||||
token from the authentication response object. |
|
||||
|
|
||||
|
|
||||
## Creating a Datastore |
|
||||
|
|
||||
Once the application has a Core session token and the datastore private key, it |
|
||||
can proceed to connect to it, or create it if it doesn't exist. To do so, the |
|
||||
application calls `datastoreConnectOrCreate()`. |
|
||||
|
|
||||
This method contacts the Core node directly. It first requests the public |
|
||||
datastore record, if it exists. The public datastore record |
|
||||
contains information like who owns the datastore, when it was created, and which |
|
||||
drivers should be used to load and store its data. |
|
||||
|
|
||||
 |
|
||||
|
|
||||
Suppose the user signing into `foo.app` does not yet have a datastore, and wants |
|
||||
to store her data on storage providers `A`, `B`, and `C`. Then, the following |
|
||||
protocol executes: |
|
||||
|
|
||||
1. The `datastoreConnectOrCreate()` method will generate a signed datastore record |
|
||||
stating that `alice.id`'s public key owns the datastore, and that the drivers |
|
||||
for `A`, `B`, and `C` should be loaded to access its data. |
|
||||
|
|
||||
2. The `datastoreConnectOrCreate()` method will call `mkdir()` to create a |
|
||||
signed root directory. |
|
||||
|
|
||||
3. The `datastoreConnectOrCreate()` method will send these signed records to the Core node. |
|
||||
The Core node replicates the root directory header (blue path), the root |
|
||||
direcory payload (green path), and the datastore record (gold path). |
|
||||
|
|
||||
4. The Core node then replicates them with drivers `A`, `B`, and `C`. |
|
||||
|
|
||||
Now, storage systems `A`, `B`, and `C` each hold a copy of the datastore record |
|
||||
and its root directory. |
|
||||
|
|
||||
*(Aside: The datastore record's consistency is preserved the same way as the |
|
||||
inode consistency).* |
|
||||
|
|
||||
## Reading Data |
|
||||
|
|
||||
Once the application has a Core session token, a datastore private key, and a |
|
||||
datastore connection object, it can proceed to read it. The available methods |
|
||||
are: |
|
||||
|
|
||||
* `listDir()`: Get the contents of a directory |
|
||||
|
|
||||
* `getFile()`: Get the contents of a file |
|
||||
|
|
||||
* `stat()`: Get a file or directory's header |
|
||||
|
|
||||
Reading data is done by path, just as it is in UNIX. At a high-level, reading |
|
||||
data involes (1) resolving the path to the inode, and (2) reading the inode's |
|
||||
contents. |
|
||||
|
|
||||
Path resolution works as it does in UNIX: the root directory is fetched, then |
|
||||
the first directory in the path, then the second directory, then the third |
|
||||
directory, etc., until either the file or directory at the end of the path is |
|
||||
fetched, or the name does not exist. |
|
||||
|
|
||||
### Authenticating Data |
|
||||
|
|
||||
Data authentication happens in the Core node,. |
|
||||
This is meant to enable linking files and directories to legacy Web |
|
||||
applications. For example, a user might upload a photo to a datastore, and |
|
||||
create a public URL to it to share with friends who do not yet use Blockstack. |
|
||||
|
|
||||
By default, the Core node serves back the inode payload data |
|
||||
(`application/octet-stream` for files, and `application/json` for directories). |
|
||||
The application client may additionally request the signatures from the Core |
|
||||
node if it wants to authenticate the data itself. |
|
||||
|
|
||||
### Path Resolution |
|
||||
|
|
||||
Applications do not need to do path resolution themselves; they simply ask the |
|
||||
Blockstack Core node to do so on their behalf. Fetching the root directory |
|
||||
works as follows: |
|
||||
|
|
||||
1. Get the root inode ID from the datastore record. |
|
||||
|
|
||||
2. Fetch all root inode headers. |
|
||||
|
|
||||
3. Select the latest inode header, and then fetch its payload. |
|
||||
|
|
||||
4. Authenticate the data. |
|
||||
|
|
||||
For example, if a client wanted to read the root directory, it would call |
|
||||
`listDir()` with `"/"` as the path. |
|
||||
|
|
||||
 |
|
||||
|
|
||||
The blue paths are the Core node fetching the root inode's headers. The green |
|
||||
paths are the Core node selecting the latest header and fetching the root |
|
||||
payload. The Core node would reply the list of inode names within the root |
|
||||
directory. |
|
||||
|
|
||||
Once the root directory is resolved, the client simply walks down the path to |
|
||||
the requested file or directory. This involves iteratively fetching a |
|
||||
directory, searching its children for the next directory in the path, and if it |
|
||||
is found, proceeding to fetch it. |
|
||||
|
|
||||
### Fetching Data |
|
||||
|
|
||||
Once the Core node has resolved the path to the base name, it looks up the inode |
|
||||
ID from the parent directory and fetches it from the backend storage providers |
|
||||
via the relevant drivers. |
|
||||
|
|
||||
For example, fetching the file `/bar` works as follows: |
|
||||
|
|
||||
 |
|
||||
|
|
||||
1. Resolve the root directory (blue paths) |
|
||||
|
|
||||
2. Find `bar` in the root directory |
|
||||
|
|
||||
3. Get `bar`'s headers (green paths) |
|
||||
|
|
||||
4. Find the latest header for `bar`, and fetch its payload (gold paths) |
|
||||
|
|
||||
5. Return the contents of `bar`. |
|
||||
|
|
||||
## Writing Data |
|
||||
|
|
||||
There are three steps to writing data: |
|
||||
|
|
||||
* Resolving the path to the inode's parent directory |
|
||||
|
|
||||
* Creating and replicating the new inode |
|
||||
|
|
||||
* Linking the new inode to the parent directory, and uploading the new parent |
|
||||
directory. |
|
||||
|
|
||||
All of these are done with both `putFile()` and `mkdir()`. |
|
||||
|
|
||||
### Creating a New Inode |
|
||||
|
|
||||
When it calls either `putFile()` or `mkdir()`, the application client will |
|
||||
generate a new inode header and payload and sign them with the datastore private |
|
||||
key. Once it has done so successfully, it will insert the new inode's name and |
|
||||
ID into the parent directory, give the parent directory a new version number, |
|
||||
and sign and replicate it and its header. |
|
||||
|
|
||||
For example, suppose the client attempts to write the data `"hello world"` to `/bar`. |
|
||||
To do so: |
|
||||
|
|
||||
 |
|
||||
|
|
||||
1. The client executes `listDir()` on the parent directory, `/` (blue paths). |
|
||||
|
|
||||
2. If an inode by the name of `bar` exists in `/`, then the method fails. |
|
||||
|
|
||||
3. The client makes a new inode header and payload for `bar` and signs them with |
|
||||
the datastore private key. It replicates them to the datastore's storage |
|
||||
drivers (green paths). |
|
||||
|
|
||||
4. The client adds a record for `bar` in `/`'s data obtained from (1), |
|
||||
increments the version for `/`, and signs and replicates `/`'s header and |
|
||||
payload (gold paths). |
|
||||
|
|
||||
|
|
||||
### Updating a File or Directory |
|
||||
|
|
||||
A client can call `putFile()` multiple times to set the file's contents. In |
|
||||
this case, the client creates, signs, and replicates a new inode header and new |
|
||||
inode payload for the file. It does not touch the parent directory at all. |
|
||||
In this case, `putFile()` will only succeed if the parent directory lists an |
|
||||
inode with the given name. |
|
||||
|
|
||||
A client cannot directly update the contents of a directory. |
|
||||
|
|
||||
## Deleting Data |
|
||||
|
|
||||
Deleting data can be done with either `rmdir()` (to remove an empty directory) |
|
||||
or `deleteFile()` (to remove a file). In either case, the protocol executed is |
|
||||
|
|
||||
1. The client executes `listDir()` on the parent directory |
|
||||
|
|
||||
2. If an inode by the given name does not exist, then the method fails. |
|
||||
|
|
||||
3. The client removes the inode's name and ID from the directory listing, signs |
|
||||
the new directory, and replicates it to the Blockstack Core node. |
|
||||
|
|
||||
4. The client tells the Blockstack Core node to delete the inode's header and |
|
||||
payload from all storage systems. |
|
||||
|
|
||||
|
|
||||
# Advanced Topics |
|
||||
|
|
||||
These features are still being implemented. |
|
||||
|
|
||||
## Data Integrity |
|
||||
|
|
||||
What happens if the client crashes while replicating new inode state? What |
|
||||
happens if the client crashes while deleting inode state? The data hosted in |
|
||||
the underlying data stores can become inconsistent with the directory structure. |
|
||||
|
|
||||
Given the choice between leaking data and rendering data unresolvable, Gaia |
|
||||
chooses to leak data. |
|
||||
|
|
||||
### Partial Inode-creation Failures |
|
||||
|
|
||||
When creating a file or directory, Gaia stores four records in this order: |
|
||||
|
|
||||
* the new inode payload |
|
||||
|
|
||||
* the new inode header |
|
||||
|
|
||||
* the updated parent directory payload |
|
||||
|
|
||||
* the updated parent directory header |
|
||||
|
|
||||
If the new payload replicates successfully but the new header does not, then the |
|
||||
new payload is leaked. |
|
||||
|
|
||||
If the new payload and new header replicate successfully, but neither parent |
|
||||
directory record succeeds, then the new inode header and payload are leaked. |
|
||||
|
|
||||
If the new payload, new header, and updated parent directory payload replicate |
|
||||
successfully, but the updated parent header fails, then not only are the new |
|
||||
inode header and payload leaked, but also *reading the parent directory will |
|
||||
fail due to a hash mismatch between its header and inode*. This can be detected |
|
||||
and resolved by observing that the copy of the header in the parent directory |
|
||||
payload has a later version than the parent directory header indicates. |
|
||||
|
|
||||
### Partial Inode-deletion Failures |
|
||||
|
|
||||
When deleting a file or directory, Gaia alters records in this order: |
|
||||
|
|
||||
* update parent directory payload |
|
||||
|
|
||||
* update parent directory header |
|
||||
|
|
||||
* delete inode header |
|
||||
|
|
||||
* delete inode payload |
|
||||
|
|
||||
Similar to partial failures from updating parent directories when creating |
|
||||
files, if the client replicates the new parent directory inode payload but fails |
|
||||
before it can update the header, then clients will detect on the next read that |
|
||||
the updated payload is valid because it has a signed inode header with a newer |
|
||||
version. |
|
||||
|
|
||||
If the client successfully updates the parent directory but fails to delete |
|
||||
either the inode header or payload, then they are leaked. However, since the |
|
||||
directory was updated, no correct client will access the deleted inode data. |
|
||||
|
|
||||
### Leak Recovery |
|
||||
|
|
||||
Gaia's storage drivers are designed to keep the inode data they store in a |
|
||||
"self-contained" way (i.e. within a single folder or bucket). In the future, |
|
||||
we will implement a `fsck`-like tool that will scan through a datastore and find |
|
||||
the set of inode headers and payloads that are no longer referenced and delete |
|
||||
them. |
|
||||
|
|
||||
## Multi-Device Support |
|
||||
|
|
||||
Contemporary users read and write data across multiple devices. In this |
|
||||
document, we have thus far described datastores with the assumption that there |
|
||||
is a single writer at all times. |
|
||||
|
|
||||
This assumption is still true in a multi-device setting, since a user is |
|
||||
unlikely to be writing data with the same application simultaneously from two |
|
||||
different devices. |
|
||||
|
|
||||
However, an open question is how multiple devices can access the same |
|
||||
application data for a user. Our design goal is to **give each device its own |
|
||||
keyring**, so if it gets lost, the user can revoke its access without having to |
|
||||
re-key her other devices. |
|
||||
|
|
||||
To do so, we'll expand the definition of a datastore to be a **per-user, |
|
||||
per-application, and per-device** collection of data. The view of a user's |
|
||||
application data will be constructed by merging each device-specific |
|
||||
datastore, and resolving conflicts by showing the "last-written" inode (where |
|
||||
"last-written" is determined by a loosely-synchronized clock). |
|
||||
|
|
||||
For example, if a user uploads a profile picture from their phone, and then |
|
||||
uploads a profile picture from their tablet, a subsequent read will query the |
|
||||
phone-originated picture and the tablet-originated picture, and return the |
|
||||
tablet-originated picture. |
|
||||
|
|
||||
The aforementioned protocols will need to be extended to search for inode |
|
||||
headers not only on each storage provider, but also search for inodes on the |
|
||||
same storage provider that may have been written by each of the user's devices. |
|
||||
Without careful optimization, this can lead to a lot of inode header queries, |
|
||||
which we address in the next topic. |
|
||||
|
|
||||
## A `.storage` Namespace |
|
||||
|
|
||||
Blockstack Core nodes can already serve as storage "gateways". That is, one |
|
||||
node can ask another node to store its data and serve it back to any reader. |
|
||||
|
|
||||
For example, Alice can make her Blockstack Core node public and program it to |
|
||||
store data to her Amazon S3 bucket and her Dropbox account. Bob can then post data to Alice's |
|
||||
node, causing her node to replicate data to both providers. Later, Charlie can |
|
||||
read Bob's data from Alice's node, causing Alice's node to fetch and serve back |
|
||||
the data from her cloud storage. Neither Bob nor Charlie have to set up accounts on |
|
||||
Amazon S3 and Dropbox this way. |
|
||||
|
|
||||
Since Alice is on the read/write path between Bob and Charlie and cloud storage, |
|
||||
she has the opportunity to make optimizations. First, she can program her |
|
||||
Core node to synchronously write data to |
|
||||
local disk and asynchronously back it up to S3 and Dropbox. This would speed up |
|
||||
Bob's writes, but at the cost of durability (i.e. Alice's node could crash |
|
||||
before replicating to the cloud). |
|
||||
|
|
||||
In addition, Alice can program her Core node to service all reads from disk. This |
|
||||
would speed up Charlie's reads, since he'll get the latest data without having |
|
||||
to hit back-end cloud storage providers. |
|
||||
|
|
||||
Since Alice is providing a service to Bob and Charlie, she will want |
|
||||
compensation. This can be achieved by having both of them send her money via |
|
||||
the underlying blockchain. |
|
||||
|
|
||||
To do so, she would register her node's IP address in a |
|
||||
`.storage` namespace in Blockstack, and post her rates per GB in her node's |
|
||||
profile and her payment address. Once Bob and Charlie sent her payment, her |
|
||||
node would begin accepting reads and writes from them up to the capacity |
|
||||
purchased. They would continue sending payments as long as Alice provides them |
|
||||
with service. |
|
||||
|
|
||||
Other experienced node operators would register their nodes in `.storage`, and |
|
||||
compete for users by offerring better durability, availability, performance, |
|
||||
extra storage features, and so on. |
|
||||
@ -1,101 +0,0 @@ |
|||||
--- |
|
||||
layout: core |
|
||||
permalink: /:collection/:path.html |
|
||||
--- |
|
||||
# Manage BNS Names |
|
||||
{:.no_toc} |
|
||||
|
|
||||
This section teaches you how to manage your namespace, it contains the |
|
||||
following sections: |
|
||||
|
|
||||
* TOC |
|
||||
{:toc} |
|
||||
|
|
||||
## Overview of management |
|
||||
|
|
||||
Once you register a BNS name, you have the power to change its zone file hash, |
|
||||
change its public key hash, destroy it (i.e. render it unresolvable), |
|
||||
or renew it. The BNS consensus rules ensure that *only* you, as the owner of |
|
||||
the name's private key, have the ability to carry out these operations. |
|
||||
|
|
||||
Each of these operations are executed by sending a specially-formatted |
|
||||
blockchain transaction to the blockchain, which BNS nodes read and process. |
|
||||
The operations are listed below: |
|
||||
|
|
||||
| Transaction Type | Description | |
|
||||
|------------------|-------------| |
|
||||
| `NAME_UPDATE` | This changes the name's zone file hash. Any 20-byte string is allowed. | |
|
||||
| `NAME_TRANSFER` | This changes the name's public key hash. In addition, the current owner has the option to atomically clear the name's zone file hash (so the new owner won't "receive" the zone file). | |
|
||||
| `NAME_REVOKE` | This renders a name unresolvable. You should do this if your private key is compromised. | |
|
||||
| `NAME_RENEWAL` | This pushes back the name's expiration date (if it has one), and optionally both sets a new zone file hash and a new public key hash. | |
|
||||
|
|
||||
The reference BNS clients--- |
|
||||
[blockstack.js](https://github.com/blockstack/blockstack.js) and the [Blockstack |
|
||||
Browser](https://github.com/blockstack/blockstack-browser)---can handle creating |
|
||||
and sending all of these transactions for you. |
|
||||
|
|
||||
## NAME_UPDATE ([live example](https://www.blocktrail.com/BTC/tx/e2029990fa75e9fc642f149dad196ac6b64b9c4a6db254f23a580b7508fc34d7)) |
|
||||
|
|
||||
A `NAME_UPDATE` transaction changes the name's zone file hash. You would send |
|
||||
one of these transactions if you wanted to change the name's zone file contents. |
|
||||
For example, you would do this if you want to deploy your own [Gaia |
|
||||
hub](https://github.com/blockstack/gaia) and want other people to read from it. |
|
||||
|
|
||||
A `NAME_UPDATE` transaction is generated from the name, a recent [consensus |
|
||||
hash](#bns-forks), and the new zone file hash. The reference clients gather |
|
||||
this information automatically. See the [transaction format]({{ site.baseurl }}/core/wire-format.html) |
|
||||
document for details on how to construct this transaction. |
|
||||
|
|
||||
## NAME_TRANSFER ([live example](https://www.blocktrail.com/BTC/tx/7a0a3bb7d39b89c3638abc369c85b5c028d0a55d7804ba1953ff19b0125f3c24)) |
|
||||
|
|
||||
A `NAME_TRANSFER` transaction changes the name's public key hash. You would |
|
||||
send one of these transactions if you wanted to: |
|
||||
|
|
||||
* Change your private key |
|
||||
* Send the name to someone else |
|
||||
|
|
||||
When transferring a name, you have the option to also clear the name's zone |
|
||||
file hash (i.e. set it to `null`). |
|
||||
This is useful for when you send the name to someone else, so the |
|
||||
recipient's name does not resolve to your zone file. |
|
||||
|
|
||||
The `NAME_TRANSFER` transaction is generated from the name, a recent [consensus |
|
||||
hash](#bns-forks), and the new public key hash. The reference clients gather |
|
||||
this information automatically. See the [transaction format]({{ site.baseurl }}/core/wire-format.html) |
|
||||
document for details on how to construct this transaction. |
|
||||
|
|
||||
## NAME_REVOKE ([live example](https://www.blocktrail.com/BTC/tx/eb2e84a45cf411e528185a98cd5fb45ed349843a83d39fd4dff2de47adad8c8f)) |
|
||||
|
|
||||
A `NAME_REVOKE` transaction makes a name unresolvable. The BNS consensus rules |
|
||||
stipulate that once a name is revoked, no one can change its public key hash or |
|
||||
its zone file hash. The name's zone file hash is set to `null` to prevent it |
|
||||
from resolving. |
|
||||
|
|
||||
You should only do this if your private key is compromised, or if you want to |
|
||||
render your name unusable for whatever reason. It is rarely used in practice. |
|
||||
|
|
||||
The `NAME_REVOKE` operation is generated using only the name. See the |
|
||||
[transaction format]({{ site.baseurl }}/core/wire-format.html) document for details on how to construct |
|
||||
it. |
|
||||
|
|
||||
## NAME_RENEWAL ([live example](https://www.blocktrail.com/BTC/tx/e543211b18e5d29fd3de7c0242cb017115f6a22ad5c6d51cf39e2b87447b7e65)) |
|
||||
|
|
||||
Depending in the namespace rules, a name can expire. For example, names in the |
|
||||
`.id` namespace expire after 2 years. You need to send a `NAME_RENEWAL` every |
|
||||
so often to keep your name. |
|
||||
|
|
||||
A `NAME_RENEWAL` costs both transaction fees and registration fees. You will |
|
||||
pay the registration cost of your name to the namespace's designated burn address when you |
|
||||
renew it. You can find this fee using the `/v1/prices/names/{name}` endpoint. |
|
||||
|
|
||||
When a name expires, it enters a month-long "grace period" (5000 blocks). It |
|
||||
will stop resolving in the grace period, and all of the above operations will |
|
||||
cease to be honored by the BNS consensus rules. You may, however, send a |
|
||||
`NAME_RENEWAL` during this grace period to preserve your name. |
|
||||
|
|
||||
If your name is in a namespace where names do not expire, then you never need to |
|
||||
use this transaction. |
|
||||
|
|
||||
When you send a `NAME_RENEWAL`, you have the option of also setting a new public |
|
||||
key hash and a new zone file hash. See the [transaction format]({{ site.baseurl }}/core/wire-format.html) |
|
||||
document for details on how to construct this transaction. |
|
||||
@ -1,57 +0,0 @@ |
|||||
--- |
|
||||
layout: core |
|
||||
permalink: /:collection/:path.html |
|
||||
--- |
|
||||
# Creating a Namespace |
|
||||
|
|
||||
There are four steps to creating a namespace: |
|
||||
|
|
||||
1. **Send a `NAMESPACE_PREORDER` transaction** ([live example](https://www.blocktrail.com/BTC/tx/5f00b8e609821edd6f3369ee4ee86e03ea34b890e242236cdb66ef6c9c6a1b28)). |
|
||||
This is the first step. This registers the *salted hash* of the namespace with BNS nodes, and burns the |
|
||||
requisite amount of cryptocurrency. In addition, it proves to the |
|
||||
BNS nodes that user has honored the BNS consensus rules by including |
|
||||
a recent *consensus hash* in the transaction |
|
||||
(see the section on [BNS forks](#bns-forks) for details). |
|
||||
|
|
||||
2. **Send a `NAMESPACE_REVEAL` transaction** ([live example](https://www.blocktrail.com/BTC/tx/ab54b1c1dd5332dc86b24ca2f88b8ca0068485edf0c322416d104c5b84133a32)). |
|
||||
This is the second step. This reveals the salt and the namespace ID (pairing it with its |
|
||||
`NAMESPACE_PREORDER`), it reveals how long names last in this namespace before |
|
||||
they expire or must be renewed, and it sets a *price function* for the namespace |
|
||||
that determines how cheap or expensive names its will be. The price function takes |
|
||||
a name in this namespace as input, and outputs the amount of cryptocurrency the |
|
||||
name will cost (i.e. by examining how long the name is, and whether or not it |
|
||||
has any vowels or non-alphabet characters). The namespace creator |
|
||||
has the option to collect name registration fees for the first year of the |
|
||||
namespace's existence by setting a *namespace creator address*. |
|
||||
|
|
||||
3. **Seed the namespace with `NAME_IMPORT` transactions** ([live example](https://www.blocktrail.com/BTC/tx/c698ac4b4a61c90b2c93dababde867dea359f971e2efcf415c37c9a4d9c4f312)). |
|
||||
Once the namespace has been revealed, the user has the option to populate it with a set of |
|
||||
names. Each imported name is given both an owner and some off-chain state. |
|
||||
This step is optional---namespace creators are not required to import names. |
|
||||
|
|
||||
4. **Send a `NAMESPACE_READY` transaction** ([live example](https://www.blocktrail.com/BTC/tx/2bf9a97e3081886f96c4def36d99a677059fafdbd6bdb6d626c0608a1e286032)). |
|
||||
This is the final step of the process. It *launches* the namespace, which makes it available to the |
|
||||
public. Once a namespace is ready, anyone can register a name in it if they |
|
||||
pay the appropriate amount of cryptocurrency (according to the price funtion |
|
||||
revealed in step 2). |
|
||||
|
|
||||
The reason for the `NAMESPACE_PREORDER/NAMESPACE_REVEAL` pairing is to prevent |
|
||||
frontrunning. The BNS consensus rules require a `NAMESPACE_REVEAL` to be |
|
||||
paired with a previous `NAMESPACE_PREORDER` sent within the past 24 hours. |
|
||||
If it did not do this, then a malicious actor could watch the blockchain network |
|
||||
and race a victim to claim a namespace. |
|
||||
|
|
||||
Namespaces are created on a first-come first-serve basis. If two people try to |
|
||||
create the same namespace, the one that successfully confirms both the |
|
||||
`NAMESPACE_PREORDER` and `NAMESPACE_REVEAL` wins. The fee burned in the |
|
||||
`NAMESPACE_PREORDER` is spent either way. |
|
||||
|
|
||||
Once the user issues the `NAMESPACE_PREORDER` and `NAMESPACE_REVEAL`, they have |
|
||||
1 year before they must send the `NAMESPACE_READY` transaction. If they do not |
|
||||
do this, then the namespace they created disappears (along with all the names |
|
||||
they imported). |
|
||||
|
|
||||
Developers wanting to create their own namespaces should read the [namespace |
|
||||
creation]({{ site.baseurl }}/core/naming/namepsaces.html) document. It is highly recommended that |
|
||||
developers individula support to create your own namespace, given the large amount of |
|
||||
cryptocurrency at stake. |
|
||||
@ -1,87 +0,0 @@ |
|||||
--- |
|
||||
layout: core |
|
||||
permalink: /:collection/:path.html |
|
||||
--- |
|
||||
# Understand the Architecture |
|
||||
|
|
||||
The BNS node is the heart of the system. It is responsible for building up |
|
||||
and replicating global name state. |
|
||||
|
|
||||
There are three parts to BNS that developers should be aware of. They are: |
|
||||
|
|
||||
* **The BNS indexer**. This module crawls the blockchain and builds |
|
||||
up its name database. BNS indexers do not contain any private or sensitive |
|
||||
state, and can be deployed publicly. We maintain a fleet of them at |
|
||||
`https://node.blockstack.org:6263` for developers to use to get started. |
|
||||
|
|
||||
* **The BNS API**. This module gives |
|
||||
developers a *stable RESTful API* for interacting with the BNS network. |
|
||||
We provide one for developers to experiment with at `https://core.blockstack.org`. |
|
||||
|
|
||||
* **BNS clients**. These communicate with the BNS API module in order to |
|
||||
resolve names. Internally, they generate and send transactions to register |
|
||||
and modify names. |
|
||||
|
|
||||
The BNS indexer and BNS API comprise the **BNS node**. An architectural schematic appears below. |
|
||||
|
|
||||
``` |
|
||||
+-------------------------------------------------------+ |
|
||||
RESTful | +----------------+ +--------------------+ | |
|
||||
+--------+ API | | | private API | | | |
|
||||
| client |<------------>| BNS API module |<----------->| BNS indexer module | | |
|
||||
+--------+ | | | | | | |
|
||||
| | +----------------+ | +----------------+ | | |
|
||||
| | | | name database | | | |
|
||||
| | | +----------------+ | | |
|
||||
| | +--------------------+ | |
|
||||
| | BNS node ^ | |
|
||||
| +------------------------------------------|------------+ |
|
||||
| | |
|
||||
| v |
|
||||
| blockchain transactions +--------------------+ |
|
||||
+------------------------------------------------->| blockchain peer | |
|
||||
+--------------------+ |
|
||||
|
|
||||
Figure 1: BNS architecture overview. Clients talk to the BNS API module to |
|
||||
resolve names, and generate and send blockchain transactions to register and |
|
||||
modify names. The API module talks to the indexer module and gives clients |
|
||||
a stable, Web-accessible interface for resolving names. The indexer module reads |
|
||||
the blochchain via a blockchain peer, over the blockchain's peer network. |
|
||||
|
|
||||
Blockstack Core currently implements the API module and indexer module as separate |
|
||||
daemons (`blockstack api` and `blockstack-core`, respectively). However, this |
|
||||
is an implementation detail, and may change in the future. |
|
||||
``` |
|
||||
|
|
||||
The BNS indexer implements the blockchain consensus rules and network protocols. |
|
||||
Its main responsibility is to build up and replicate all of the name state. It does |
|
||||
not have any public APIs of its own. |
|
||||
|
|
||||
The BNS API modules allows users and developers to resolve names via a RESTful |
|
||||
interface. Resolution can be done with vanilla `curl` or `wget`. |
|
||||
BNS applications should use the BNS API module for name resolution. |
|
||||
They should not attempt to talk to a BNS indexer directly, because its API is not stable and is not meant |
|
||||
for consumption by any other process except for the API module. |
|
||||
|
|
||||
Registering and managing names require generating and sending blockchain |
|
||||
transactions, which requires running a BNS client. We provide two reference |
|
||||
BNS clients: |
|
||||
|
|
||||
* The [Blockstack Browser](https://github.com/blockstack/blockstack-browser) gives users |
|
||||
and developers a graphical UI to resolve, register and manage names. This is the recommended |
|
||||
way to interact with BNS. |
|
||||
* The Blockstack CLI gives developers low-level |
|
||||
control over resolving, registering, and managing names. |
|
||||
A new CLI that uses [blockstack.js](https://github.com/blockstack/blockstack.js) |
|
||||
is under development, and will replace the existing CLI program. |
|
||||
|
|
||||
We recommend that new developers use the [Blockstack |
|
||||
Browser](https://github.com/blockstack/blockstack-browser). |
|
||||
|
|
||||
Developers who want to make their own client programs that do not use |
|
||||
the reference client library code should read the |
|
||||
[BNS transaction wire format]({{ site.baseurl }}/core/wire-format.html) document for generating and |
|
||||
sending their own transactions. |
|
||||
|
|
||||
The examples in this document focus on resolving names using `curl`. We refer |
|
||||
the reader to client-specific documentation for registering and managing names. |
|
||||
@ -1,148 +0,0 @@ |
|||||
## What is the Blockstack ecosystem |
|
||||
|
|
||||
In the Blockstack ecosystem, users control their data and apps run on their devices. There |
|
||||
are no middlemen, no passwords, no massive data silos to breach, and no services |
|
||||
tracking us around the internet. |
|
||||
|
|
||||
The applications on blockstack are server-less and decentralized. Developers |
|
||||
start by building a single-page application in Javascript, Then, instead of |
|
||||
plugging the frontend into a centralized API, they plug into an API run by the |
|
||||
user. Developers install a library called `blockstack.js` and don't have to |
|
||||
worry about running servers, maintaining databases, or building out user |
|
||||
management systems. |
|
||||
|
|
||||
Personal user APIs ship with the Blockstack app and handle everything from |
|
||||
identity and authentication to data storage. Applications can request |
|
||||
permissions from users and then gain read and write access to user resources. |
|
||||
|
|
||||
Data storage is simple and reliable and uses existing cloud infrastructure. |
|
||||
Users connect with their Dropbox, Google Drive, S3, etc... and data is synced |
|
||||
from their local device up to their cloud. |
|
||||
|
|
||||
Identity is user-controlled and utilizes the blockchain for secure management of |
|
||||
keys, devices and usernames. When users login with apps, they are anonymous by |
|
||||
default and use an app-specific key, but their full identity can be revealed and |
|
||||
proven at any time. Keys are for signing and encryption and can be changed as |
|
||||
devices need to be added or removed. |
|
||||
|
|
||||
Under the hood, Blockstack provides a decentralized domain name system (DNS), |
|
||||
decentralized public key distribution system, and registry for apps and user |
|
||||
identities. |
|
||||
|
|
||||
## What problems does Blockstack solve? |
|
||||
|
|
||||
Developers can now build Web applications where: |
|
||||
|
|
||||
- you own your data, not the application |
|
||||
- you control where your data is stored |
|
||||
- you control who can access your data |
|
||||
|
|
||||
Developers can now build Web applications where: |
|
||||
|
|
||||
- you don't have to deal with passwords |
|
||||
- you don't have to host everyone's data |
|
||||
- you don't have to run app-specific servers |
|
||||
|
|
||||
Right now, Web application users are "digital serfs" and applications are the "digital landlords". Users don't own their data; the app owns it. Users don't control where data gets stored; they can only store it on the application. Users don't control access to it; they only advise the application on how to control access (which the application can ignore). |
|
||||
|
|
||||
Blockstack applications solve both sets of problems. Users pick and choose highly-available storage providers like Dropbox or BitTorrent to host their data, and applications read it with the user's consent. Blockstack ensures that all data is signed and verified and (optionally) encrypted end-to-end, so users can treat storage providers like dumb hard drives: if you don't like yours, you can swap it out with a better one. Users can take their data with them if they leave the application, since it was never the application's in the first place. |
|
||||
|
|
||||
At the same time, developers are no longer on the hook for hosting user data. Since users bring their own storage and use public-key cryptography for authentication, applications don't have to store anything--there's nothing to steal when they get hacked. Moreover, many Web applications today can be re-factored so that everything happens client-side, obviating the need for running dedicated application servers. |
|
||||
|
|
||||
|
|
||||
## What is a Blockstack ID? |
|
||||
|
|
||||
Blockstack IDs are usernames. Unlike normal Web app usernames, Blockstack IDs |
|
||||
are usable *across every Blockstack app.* They fill a similar role to |
|
||||
centralized single-signon services like Facebook or Google. However, you and |
|
||||
only you control your Blockstack ID, and no one can track your logins. |
|
||||
|
|
||||
## How do I get a Blockstack ID? |
|
||||
|
|
||||
If you use the [Blockstack Browser]({{ site.baseurl }}/browser/browser-introduction.md) to create a |
|
||||
new ID. |
|
||||
|
|
||||
## Why do I need a Blockstack ID? |
|
||||
|
|
||||
Blockstack IDs are used to discover where you are keeping your |
|
||||
(publicly-readable) application data. For example, if `alice.id` wants to share |
|
||||
a document with `bob.id`, then `bob.id`'s browser uses the Blockstack ID |
|
||||
`alice.id` to look up where `alice.id` stored it. |
|
||||
|
|
||||
The technical descriptions of how and why this works are quite long. |
|
||||
Please see the [Blockstack Naming Service]({{site.baseurl}}/core/naming/introduction.html) |
|
||||
documentation for a full description. |
|
||||
|
|
||||
= |
|
||||
|
|
||||
## What components make ups the Blockstack ecosystem? |
|
||||
|
|
||||
The components that make up Blockstack do not have any central points of |
|
||||
control. |
|
||||
|
|
||||
* The [Blockstack Naming Service]({{ site.baseurl }}/core/naming/introduction.html) runs on top of |
|
||||
the Bitcoin blockchain, which itself is decentralized. It binds Blockstack |
|
||||
IDs to a small amount of on-chain data (usually a hash of off-chain data). |
|
||||
* The [Atlas Peer Network]({{ site.baseurl }}/core/atlas/overview.html) stores chunks of data referenced by |
|
||||
names in BNS. It operates under similar design principles to BitTorrent, and |
|
||||
has no single points of failure. The network is self-healing---if a node |
|
||||
crashes, it quickly recovers all of its state from its peers. |
|
||||
* The [Gaia storage system](https://github.com/blockstack/gaia) lets users |
|
||||
choose where their application data gets hosted. Gaia reduces all storage |
|
||||
systems---from cloud storage to peer-to-peer networks---to dumb, interchangeable |
|
||||
hard drives. Users have maximum flexibility and control over their data in a |
|
||||
way that is transparent to app developers. |
|
||||
|
|
||||
|
|
||||
## Blockstack vs Ethereum |
|
||||
|
|
||||
Blockstack and Ethereum both strive to provide a decentralized application |
|
||||
platform. Blockstack's design philosophy differs from Ethereum's design |
|
||||
philosophy in that Blockstack emphasizes treating the blockchain as a "dumb |
|
||||
ledger" with no special functionality or properties beyond a few bare minimum |
|
||||
requirements. Instead, it strives to do everything off-chain---an application of the [end-to-end principle](https://en.wikipedia.org/wiki/End-to-end_principle). |
|
||||
Most Blockstack applications do *not* |
|
||||
interact with the blockchain, and instead interact with Blockstack |
|
||||
infrastructure through client libraries and RESTful endpoints. |
|
||||
This is evidenced by Blockstack's decision to implement its naming system (BNS), discovery and routing system |
|
||||
(Atlas), and storage system (Gaia) as blockchain-agnostic components that can be |
|
||||
ported from one blockchain to another. |
|
||||
|
|
||||
Ethereum takes the opposite approach. Ethereum dapps are expected to interface |
|
||||
directly with on-chain smart contract logic, and are expected to host a |
|
||||
non-trivial amount of state in the blockchain itself. This is necessary for |
|
||||
them, because many Ethereum dapps' business logic is centered around the |
|
||||
mechanics of an ERC20 token. |
|
||||
|
|
||||
Blockstack does not implement a smart contract system (yet), but it will soon |
|
||||
implement a [native token](https://blockstack.com/distribution.pdf) that will be |
|
||||
accessible to Blockstack applications. |
|
||||
|
|
||||
|
|
||||
## What's the difference between Onename and Blockstack? |
|
||||
|
|
||||
Onename is the free Blockstack ID registrar run by Blockstack. It makes it easy to register your name and setup your profile. Once the name has been registered in Onename you can transfer it to a wallet you control, or leave it there and use it as you like. |
|
||||
|
|
||||
## How is Blockstack different from Namecoin? |
|
||||
|
|
||||
Blockstack DNS differs from Namecoin DNS in a few fundamental ways: blockchain layering, storage models, name pricing models, and incentives for miners. We wrote a post where you can learn more here: https://blockstack.org/docs/blockstack-vs-namecoin |
|
||||
|
|
||||
## I heard you guys were on Namecoin, what blockchain do you use now? |
|
||||
|
|
||||
We use the Bitcoin blockchain for our source of truth. |
|
||||
|
|
||||
## How long has the project been around? |
|
||||
|
|
||||
Work on the project started in late 2013. First public commits on the code are |
|
||||
from Jan 2014. The first registrar for Blockstack was launched in March 2014 and |
|
||||
the project has been growing since then. |
|
||||
|
|
||||
## Who started the project? Who maintains it? |
|
||||
|
|
||||
The project was started by two engineers from Princeton University. Muneeb Ali |
|
||||
and Ryan Shea met at the Computer Science department at Princeton, where Muneeb |
|
||||
was finishing his PhD and Ryan was running the enterprenurship club. In 2014, |
|
||||
frustrated by the walled-gardens and security problems of the current internet |
|
||||
they started working on a decentralized internet secured by blockchains. A full |
|
||||
list of contributors can be found |
|
||||
[here](https://github.com/blockstack/blockstack-core/graphs/contributors). |
|
||||
@ -1,47 +0,0 @@ |
|||||
## Hardware and OS requirements |
|
||||
|
|
||||
* A 64-bit CPU running at at least 1 GHz is *highly* recommended (but not strictly required) |
|
||||
* You will need ~250MB RAM and ~10 GB disk free. Do **not** attempt to use a network-attached disk for this. |
|
||||
* You should have at least 30,000 inodes free in your filesystem. Unless you are using a very small VM image, you almost certainly have enough (you can check with `df -i`). |
|
||||
* TCP port 6264 should be open and support bidirectional traffic. If you want to use SSL, then port 6263 should be open. |
|
||||
* A reliable Internet connection of DSL-like quality or higher |
|
||||
|
|
||||
## Deployment |
|
||||
### The Easy Way |
|
||||
* Install from `pip`, source code, or Docker |
|
||||
* Run `blockstack-core fast_sync` |
|
||||
* Run `blockstack-core start` |
|
||||
|
|
||||
### The Less Easy Way |
|
||||
* Install from `pip`, source code, or Docker |
|
||||
* Run `blockstack-core start` |
|
||||
* Wait a few days |
|
||||
|
|
||||
#### Best Practices for the Less Easy Way |
|
||||
* Take a `blockstack-server.snapshots` database from a known-good node and pass `--expected_snapshots=/path/to/blockstack-server.snapshots`. This will force your bootstrapping node to verify that it reaches the same sequence of consensus hashes as it bootstraps (i.e. your node will detect any divergence from Blockstack's name history and abort early, instead of wasting your time). |
|
||||
* Make sure you're in a position to leave the node online at 100% CPU use for the duration of its bootstrapping period |
|
||||
|
|
||||
### The Hard Way |
|
||||
* Install `bitcoind` (version 0.16.x is recommended for now) |
|
||||
* Start `bitcoind` as `bitcoind -daemon -txindex=1` |
|
||||
* Wait for `bitcoind` to download the entire blockchain. This can take between 1 hour and 1 day. |
|
||||
* Install `blockstack-core` from source, `pip`, or Docker |
|
||||
* Run `blockstack-core configure` and enter your `bitcoind` node's IP address, port, RPC username, and RPC password when prompted |
|
||||
* Run `blockstack-core start` |
|
||||
* Wait a few days |
|
||||
|
|
||||
#### Best Practices for the Hard Way |
|
||||
* You're going to need ~500 GB of space for the Bitcoin blockchain state |
|
||||
* You can safely store its chain state on a network-attached disk, if you're doing this in a cloud-hosted environment |
|
||||
* Your `bitcoind` host will need TCP:8332-8333 open for bidirectional traffic |
|
||||
|
|
||||
## Troubleshooting |
|
||||
### The node stops responding to TCP:6264 |
|
||||
* Check `dmesg` for TCP SYN flooding. The solution here is to kill and restart the node. |
|
||||
* To mitigate, install a rate-limiting proxy HTTP server in front of the node. We have a sample config for `nginx` [here](https://github.com/blockstack/atlas/blob/master/public_fleet/node/default). |
|
||||
|
|
||||
### No other Blockstack nodes contact my node |
|
||||
* Verify that your IP address is publicly-routable, and that peers can communicate on TCP:6264 |
|
||||
|
|
||||
### People are attacking my Bitcoin node |
|
||||
* Stick an `nginx` reverse proxy in front of your `bitcoind` node, and use our [nginx](https://github.com/blockstack/atlas/tree/master/public_fleet/bitcoind) scripts to limit APi access to only the JSON-RPC methods Blockstack actually needs. Better yet, do what we do---build a statically-linked `bitcoind` binary from source that simply omits all of the RPC methods except the ones listed in the linked config file. |
|
||||
|
Before Width: | Height: | Size: 25 KiB |
@ -1,497 +0,0 @@ |
|||||
--- |
|
||||
layout: core |
|
||||
permalink: /:collection/:path.html |
|
||||
--- |
|
||||
# Bitcoin wire format |
|
||||
{:.no_toc} |
|
||||
|
|
||||
This page is for organizations who want to be able to create and send name operation transactions to the blockchain(s) Blockstack supports. |
|
||||
It describes the transaction formats for the Bitcoin blockchain. |
|
||||
|
|
||||
* TOC |
|
||||
{:toc} |
|
||||
|
|
||||
## Transaction format |
|
||||
|
|
||||
Each Bitcoin transaction for Blockstack contains signatures from two sets of keys: the name owner, and the payer. The owner `scriptSig` and `scriptPubKey` fields are generated from the key(s) that own the given name. The payer `scriptSig` and `scriptPubKey` fields are used to *subsidize* the operation. The owner keys do not pay for any operations; the owner keys only control the minimum amount of BTC required to make the transaction standard. The payer keys only pay for the transaction's fees, and (when required) they pay the name fee. |
|
||||
|
|
||||
This construction is meant to allow the payer to be wholly separate from the owner. The principal that owns the name can fund their own transactions, or they can create a signed transaction that carries out the desired operation and request some other principal (e.g. a parent organization) to actually pay for and broadcast the transaction. |
|
||||
|
|
||||
The general transaction layout is as follows: |
|
||||
|
|
||||
| **Inputs** | **Outputs** | |
|
||||
| ------------------------ | ----------------------- | |
|
||||
| Owner scriptSig (1) | `OP_RETURN <payload>` (2) | |
|
||||
| Payment scriptSig | Owner scriptPubKey (3) | |
|
||||
| Payment scriptSig... (4) | |
|
||||
| ... (4) | ... (5) | |
|
||||
|
|
||||
(1) The owner `scriptSig` is *always* the first input. |
|
||||
(2) The `OP_RETURN` script that describes the name operation is *always* the first output. |
|
||||
(3) The owner `scriptPubKey` is *always* the second output. |
|
||||
(4) The payer can use as many payment inputs as (s)he likes. |
|
||||
(5) At most one output will be the "change" `scriptPubKey` for the payer. |
|
||||
Different operations require different outputs. |
|
||||
|
|
||||
## Payload Format |
|
||||
|
|
||||
Each Blockstack transaction in Bitcoin describes the name operation within an `OP_RETURN` output. It encodes name ownership, name fees, and payments as `scriptPubKey` outputs. The specific operations are described below. |
|
||||
|
|
||||
Each `OP_RETURN` payload *always* starts with the two-byte string `id` (called the "magic" bytes in this document), followed by a one-byte `op` that describes the operation. |
|
||||
|
|
||||
### NAME_PREORDER |
|
||||
|
|
||||
Op: `?` |
|
||||
|
|
||||
Description: This transaction commits to the *hash* of a name. It is the first |
|
||||
transaction of two transactions that must be sent to register a name in BNS. |
|
||||
|
|
||||
Example: [6730ae09574d5935ffabe3dd63a9341ea54fafae62fde36c27738e9ee9c4e889](https://www.blocktrail.com/BTC/tx/6730ae09574d5935ffabe3dd63a9341ea54fafae62fde36c27738e9ee9c4e889) |
|
||||
|
|
||||
`OP_RETURN` wire format: |
|
||||
``` |
|
||||
0 2 3 23 39 |
|
||||
|-----|--|--------------------------------------------------|--------------| |
|
||||
magic op hash_name(name.ns_id,script_pubkey,register_addr) consensus hash |
|
||||
``` |
|
||||
|
|
||||
Inputs: |
|
||||
* Payment `scriptSig`'s |
|
||||
|
|
||||
Outputs: |
|
||||
* `OP_RETURN` payload |
|
||||
* Payment `scriptPubkey` script for change |
|
||||
* `p2pkh` `scriptPubkey` to the burn address (0x00000000000000000000000000000000000000) |
|
||||
|
|
||||
Notes: |
|
||||
* `register_addr` is a base58check-encoded `ripemd160(sha256(pubkey))` (i.e. an address). This address **must not** have been used before in the underlying blockchain. |
|
||||
* `script_pubkey` is either a `p2pkh` or `p2sh` compiled Bitcoin script for the payer's address. |
|
||||
|
|
||||
### NAME_REGISTRATION |
|
||||
|
|
||||
Op: `:` |
|
||||
|
|
||||
Description: This transaction reveals the name whose hash was announced by a |
|
||||
previous `NAME_PREORDER`. It is the second of two transactions that must be |
|
||||
sent to register a name in BNS. |
|
||||
|
|
||||
Example: [55b8b42fc3e3d23cbc0f07d38edae6a451dfc512b770fd7903725f9e465b2925](https://www.blocktrail.com/BTC/tx/55b8b42fc3e3d23cbc0f07d38edae6a451dfc512b770fd7903725f9e465b2925) |
|
||||
|
|
||||
`OP_RETURN` wire format (2 variations allowed): |
|
||||
|
|
||||
Variation 1: |
|
||||
``` |
|
||||
0 2 3 39 |
|
||||
|----|--|-----------------------------| |
|
||||
magic op name.ns_id (37 bytes) |
|
||||
``` |
|
||||
|
|
||||
Variation 2: |
|
||||
``` |
|
||||
0 2 3 39 59 |
|
||||
|----|--|----------------------------------|-------------------| |
|
||||
magic op name.ns_id (37 bytes, 0-padded) value |
|
||||
``` |
|
||||
|
|
||||
Inputs: |
|
||||
* Payer `scriptSig`'s |
|
||||
|
|
||||
Outputs: |
|
||||
* `OP_RETURN` payload |
|
||||
* `scriptPubkey` for the owner's address |
|
||||
* `scriptPubkey` for the payer's change |
|
||||
|
|
||||
Notes: |
|
||||
|
|
||||
* Variation 1 simply registers the name. Variation 2 will register the name and |
|
||||
set a name value simultaneously. This is used in practice to set a zone file |
|
||||
hash for a name without the extra `NAME_UPDATE` transaction. |
|
||||
* Both variations are supported. Variation 1 was designed for the time when |
|
||||
Bitcoin only supported 40-byte `OP_RETURN` outputs. |
|
||||
|
|
||||
### NAME_RENEWAL |
|
||||
|
|
||||
Op: `:` |
|
||||
|
|
||||
Description: This transaction renews a name in BNS. The name must still be |
|
||||
registered and not expired, and owned by the transaction sender. |
|
||||
|
|
||||
Example: [e543211b18e5d29fd3de7c0242cb017115f6a22ad5c6d51cf39e2b87447b7e65](https://www.blocktrail.com/BTC/tx/e543211b18e5d29fd3de7c0242cb017115f6a22ad5c6d51cf39e2b87447b7e65) |
|
||||
|
|
||||
`OP_RETURN` wire format (2 variations allowed): |
|
||||
|
|
||||
Variation 1: |
|
||||
``` |
|
||||
0 2 3 39 |
|
||||
|----|--|-----------------------------| |
|
||||
magic op name.ns_id (37 bytes) |
|
||||
``` |
|
||||
|
|
||||
Variation 2: |
|
||||
``` |
|
||||
0 2 3 39 59 |
|
||||
|----|--|----------------------------------|-------------------| |
|
||||
magic op name.ns_id (37 bytes, 0-padded) value |
|
||||
``` |
|
||||
|
|
||||
Inputs: |
|
||||
|
|
||||
* Payer `scriptSig`'s |
|
||||
|
|
||||
Outputs: |
|
||||
|
|
||||
* `OP_RETURN` payload |
|
||||
* `scriptPubkey` for the owner's addess. This can be a different address than |
|
||||
the current name owner (in which case, the name is renewed and transferred). |
|
||||
* `scriptPubkey` for the payer's change |
|
||||
* `scriptPubkey` for the burn address (to pay the name cost) |
|
||||
|
|
||||
Notes: |
|
||||
|
|
||||
* This transaction is identical to a `NAME_REGISTRATION`, except for the presence of the fourth output that pays for the name cost (to the burn address). |
|
||||
* Variation 1 simply renews the name. Variation 2 will both renew the name and |
|
||||
set a new name value (in practice, the hash of a new zone file). |
|
||||
* Both variations are supported. Variation 1 was designed for the time when |
|
||||
Bitcoin only supported 40-byte `OP_RETURN` outputs. |
|
||||
* This operation can be used to transfer a name to a new address by setting the |
|
||||
second output (the first `scriptPubkey`) to be the `scriptPubkey` of the new |
|
||||
owner key. |
|
||||
|
|
||||
### NAME_UPDATE |
|
||||
|
|
||||
Op: `+` |
|
||||
|
|
||||
Description: This transaction sets the name state for a name to the given |
|
||||
`value`. In practice, this is used to announce new DNS zone file hashes to the [Atlas |
|
||||
network]({{ site.baseurl }}/core/atlas/overview.html). |
|
||||
|
|
||||
Example: [e2029990fa75e9fc642f149dad196ac6b64b9c4a6db254f23a580b7508fc34d7](https://www.blocktrail.com/BTC/tx/e2029990fa75e9fc642f149dad196ac6b64b9c4a6db254f23a580b7508fc34d7) |
|
||||
|
|
||||
`OP_RETURN` wire format: |
|
||||
``` |
|
||||
0 2 3 19 39 |
|
||||
|-----|--|-----------------------------------|-----------------------| |
|
||||
magic op hash128(name.ns_id,consensus hash) zone file hash |
|
||||
``` |
|
||||
|
|
||||
Note that `hash128(name.ns_id, consensus hash)` is the first 16 bytes of a SHA256 hash over the name concatenated to the hexadecimal string of the consensus hash (not the bytes corresponding to that hex string). |
|
||||
See the [Method Glossary](#method-glossary) below. |
|
||||
|
|
||||
Example: `hash128("jude.id" + "8d8762c37d82360b84cf4d87f32f7754") == "d1062edb9ec9c85ad1aca6d37f2f5793"`. |
|
||||
|
|
||||
Inputs: |
|
||||
* owner `scriptSig` |
|
||||
* payment `scriptSig`'s |
|
||||
|
|
||||
Outputs: |
|
||||
* `OP_RETURN` payload |
|
||||
* owner's `scriptPubkey` |
|
||||
* payment `scriptPubkey` change |
|
||||
|
|
||||
### NAME_TRANSFER |
|
||||
|
|
||||
Op: `>` |
|
||||
|
|
||||
Description: This transaction changes the public key hash that owns the name in |
|
||||
BNS. |
|
||||
|
|
||||
Example: [7a0a3bb7d39b89c3638abc369c85b5c028d0a55d7804ba1953ff19b0125f3c24](https://www.blocktrail.com/BTC/tx/7a0a3bb7d39b89c3638abc369c85b5c028d0a55d7804ba1953ff19b0125f3c24) |
|
||||
|
|
||||
`OP_RETURN` wire format: |
|
||||
``` |
|
||||
0 2 3 4 20 36 |
|
||||
|-----|--|----|-------------------|---------------| |
|
||||
magic op keep hash128(name.ns_id) consensus hash |
|
||||
data? |
|
||||
``` |
|
||||
|
|
||||
Inputs: |
|
||||
|
|
||||
* Owner `scriptSig` |
|
||||
* Payment `scriptSig`'s |
|
||||
|
|
||||
Outputs: |
|
||||
|
|
||||
* `OP_RETURN` payload |
|
||||
* new name owner's `scriptPubkey` |
|
||||
* old name owner's `scriptPubkey` |
|
||||
* payment `scriptPubkey` change |
|
||||
|
|
||||
Notes: |
|
||||
|
|
||||
* The `keep data?` byte controls whether or not the name's 20-byte value is preserved. This value is either `>` to preserve it, or `~` to delete it. |
|
||||
|
|
||||
### NAME_REVOKE |
|
||||
|
|
||||
Op: `~` |
|
||||
|
|
||||
Description: This transaction destroys a registered name. Its name state value |
|
||||
in BNS will be cleared, and no further transactions will be able to affect the |
|
||||
name until it expires (if its namespace allows it to expire at all). |
|
||||
|
|
||||
Example: [eb2e84a45cf411e528185a98cd5fb45ed349843a83d39fd4dff2de47adad8c8f](https://www.blocktrail.com/BTC/tx/eb2e84a45cf411e528185a98cd5fb45ed349843a83d39fd4dff2de47adad8c8f) |
|
||||
|
|
||||
`OP_RETURN` wire format: |
|
||||
``` |
|
||||
0 2 3 39 |
|
||||
|----|--|-----------------------------| |
|
||||
magic op name.ns_id (37 bytes) |
|
||||
``` |
|
||||
|
|
||||
Inputs: |
|
||||
|
|
||||
* owner `scriptSig` |
|
||||
* payment `scriptSig`'s |
|
||||
|
|
||||
Outputs: |
|
||||
|
|
||||
* `OP_RETURN` payload |
|
||||
* owner `scriptPubkey` |
|
||||
* payment `scriptPubkey` change |
|
||||
|
|
||||
### ANNOUNCE |
|
||||
|
|
||||
Op: `#` |
|
||||
|
|
||||
Description: This transaction does not affect any names in BNS, but it allows a |
|
||||
user to send a message to other BNS nodes. In order for the message to be |
|
||||
received, the following must be true: |
|
||||
|
|
||||
* The sender must have a BNS name |
|
||||
* The BNS nodes must list the sender's BNS name as being a "trusted message |
|
||||
sender" |
|
||||
* The message must have already been propagated through the [Atlas |
|
||||
network]({{ site.baseurl }}/core/atlas/overview.html). This transaction references it by content hash. |
|
||||
|
|
||||
`OP_RETURN` wire format: |
|
||||
|
|
||||
``` |
|
||||
0 2 3 23 |
|
||||
|----|--|-----------------------------| |
|
||||
magic op ripemd160(sha256(message)) |
|
||||
``` |
|
||||
|
|
||||
Inputs: |
|
||||
|
|
||||
* The payer `scriptSig`'s |
|
||||
|
|
||||
Outputs: |
|
||||
|
|
||||
* `OP_RETURN` payload |
|
||||
* change `scriptPubKey` |
|
||||
|
|
||||
Notes: |
|
||||
|
|
||||
* The payer key should be an owner key for an existing name, since Blockstack users can subscribe to announcements from specific name-owners. |
|
||||
|
|
||||
### NAMESPACE_PREORDER |
|
||||
|
|
||||
Op: `*` |
|
||||
|
|
||||
Description: This transaction announces the *hash* of a new namespace. It is the |
|
||||
first of three transactions that must be sent to create a namespace. |
|
||||
|
|
||||
Example: [5f00b8e609821edd6f3369ee4ee86e03ea34b890e242236cdb66ef6c9c6a1b28](https://www.blocktrail.com/BTC/tx/5f00b8e609821edd6f3369ee4ee86e03ea34b890e242236cdb66ef6c9c6a1b28) |
|
||||
|
|
||||
`OP_RETURN` wire format: |
|
||||
``` |
|
||||
0 2 3 23 39 |
|
||||
|-----|---|-----------------------------------------|----------------| |
|
||||
magic op hash_name(ns_id,script_pubkey,reveal_addr) consensus hash |
|
||||
``` |
|
||||
|
|
||||
Inputs: |
|
||||
|
|
||||
* Namespace payer `scriptSig` |
|
||||
|
|
||||
Outputs: |
|
||||
|
|
||||
* `OP_RETURN` payload |
|
||||
* Namespace payer `scriptPubkey` change address |
|
||||
* `p2pkh` script to the burn address `1111111111111111111114oLvT2`, whose public key hash is 0x00000000000000000000000000000000 |
|
||||
|
|
||||
Notes: |
|
||||
|
|
||||
* The `reveal_addr` field is the address of the namespace revealer public key. The revealer private key will be used to generate `NAME_IMPORT` transactions. |
|
||||
|
|
||||
### NAMESPACE_REVEAL |
|
||||
|
|
||||
Op: `&` |
|
||||
|
|
||||
Description: This transaction reveals the namespace ID and namespace rules |
|
||||
for a previously-anounced namespace hash (sent by a previous `NAMESPACE_PREORDER`). |
|
||||
|
|
||||
Example: [ab54b1c1dd5332dc86b24ca2f88b8ca0068485edf0c322416d104c5b84133a32](https://www.blocktrail.com/BTC/tx/ab54b1c1dd5332dc86b24ca2f88b8ca0068485edf0c322416d104c5b84133a32) |
|
||||
|
|
||||
`OP_RETURN` wire format: |
|
||||
``` |
|
||||
0 2 3 7 8 9 10 11 12 13 14 15 16 17 18 20 39 |
|
||||
|-----|---|--------|-----|-----|----|----|----|----|----|-----|-----|-----|--------|----------|-------------------------| |
|
||||
magic op life coeff. base 1-2 3-4 5-6 7-8 9-10 11-12 13-14 15-16 nonalpha version namespace ID |
|
||||
bucket exponents no-vowel |
|
||||
discounts |
|
||||
``` |
|
||||
|
|
||||
Inputs: |
|
||||
|
|
||||
* Namespace payer `scriptSig`s |
|
||||
|
|
||||
Outputs: |
|
||||
|
|
||||
* `OP_RETURN` payload |
|
||||
* namespace revealer `scriptPubkey` |
|
||||
* namespace payer change `scriptPubkey` |
|
||||
|
|
||||
Notes: |
|
||||
|
|
||||
* This transaction must be sent within 1 day of the `NAMESPACE_PREORDER` |
|
||||
* The second output (with the namespace revealer) **must** be a `p2pkh` script |
|
||||
* The address of the second output **must** be the `reveal_addr` in the `NAMESPACE_PREORDER` |
|
||||
|
|
||||
Pricing: |
|
||||
|
|
||||
The rules for a namespace are as follows: |
|
||||
|
|
||||
* a name can fall into one of 16 buckets, measured by length. Bucket 16 incorporates all names at least 16 characters long. |
|
||||
* the pricing structure applies a multiplicative penalty for having numeric characters, or punctuation characters. |
|
||||
* the price of a name in a bucket is ((coeff) * (base) ^ (bucket exponent)) / ((numeric discount multiplier) * (punctuation discount multiplier)) |
|
||||
|
|
||||
Example: |
|
||||
* base = 10 |
|
||||
* coeff = 2 |
|
||||
* nonalpha discount: 10 |
|
||||
* no-vowel discount: 10 |
|
||||
* buckets 1, 2: 9 |
|
||||
* buckets 3, 4, 5, 6: 8 |
|
||||
* buckets 7, 8, 9, 10, 11, 12, 13, 14: 7 |
|
||||
* buckets 15, 16+: |
|
||||
|
|
||||
With the above example configuration, the following are true: |
|
||||
|
|
||||
* The price of "john" would be 2 * 10^8, since "john" falls into bucket 4 and has no punctuation or numerics. |
|
||||
* The price of "john1" would be 2 * 10^6, since "john1" falls into bucket 5 but has a number (and thus receives a 10x discount) |
|
||||
* The price of "john_1" would be 2 * 10^6, since "john_1" falls into bucket 6 but has a number and punctuation (and thus receives a 10x discount) |
|
||||
* The price of "j0hn_1" would be 2 * 10^5, since "j0hn_1" falls into bucket 6 but has a number and punctuation and lacks vowels (and thus receives a 100x discount) |
|
||||
|
|
||||
|
|
||||
### NAME_IMPORT |
|
||||
|
|
||||
Op: `;` |
|
||||
|
|
||||
Description: This transaction registers a name and some name state into a |
|
||||
namespace that has been revealed, but not been launched. Only the namespace |
|
||||
creator can import names. See the [namespace creation section]({{ site.baseurl }}/core/naming/namespace.html) for details. |
|
||||
|
|
||||
Example: [c698ac4b4a61c90b2c93dababde867dea359f971e2efcf415c37c9a4d9c4f312](https://www.blocktrail.com/BTC/tx/c698ac4b4a61c90b2c93dababde867dea359f971e2efcf415c37c9a4d9c4f312) |
|
||||
|
|
||||
`OP_RETURN` wire format: |
|
||||
``` |
|
||||
0 2 3 39 |
|
||||
|----|--|-----------------------------| |
|
||||
magic op name.ns_id (37 bytes) |
|
||||
``` |
|
||||
|
|
||||
Inputs: |
|
||||
|
|
||||
* The namespace reveal `scriptSig` (with the namespace revealer's public key), or one of its first 300 extended public keys |
|
||||
* Any payment inputs |
|
||||
|
|
||||
Outputs: |
|
||||
|
|
||||
* `OP_RETURN` payload |
|
||||
* recipient `scriptPubKey` |
|
||||
* zone file hash (using the 20-byte hash in a standard `p2pkh` script) |
|
||||
* payment change `scriptPubKey` |
|
||||
|
|
||||
Notes: |
|
||||
|
|
||||
* These transactions can only be sent between the `NAMESPACE_REVEAL` and `NAMESPACE_READY`. |
|
||||
* The first `NAME_IMPORT` transaction **must** have a `scriptSig` input that matches the `NAMESPACE_REVEAL`'s second output (i.e. the reveal output). |
|
||||
* Any subsequent `NAME_IMPORT` transactions **may** have a `scriptSig` input whose public key is one of the first 300 extended public keys from the `NAMESPACE_REVEAL`'s `scriptSig` public key. |
|
||||
|
|
||||
### NAMESPACE_READY |
|
||||
|
|
||||
Op: `!` |
|
||||
|
|
||||
Description: This transaction launches a namesapce. Only the namespace creator |
|
||||
can send this transaction. Once sent, anyone can register names in the |
|
||||
namespace. |
|
||||
|
|
||||
Example: [2bf9a97e3081886f96c4def36d99a677059fafdbd6bdb6d626c0608a1e286032](https://www.blocktrail.com/BTC/tx/2bf9a97e3081886f96c4def36d99a677059fafdbd6bdb6d626c0608a1e286032) |
|
||||
|
|
||||
`OP_RETURN` wire format: |
|
||||
``` |
|
||||
|
|
||||
0 2 3 4 23 |
|
||||
|-----|--|--|------------| |
|
||||
magic op . ns_id |
|
||||
``` |
|
||||
|
|
||||
Inputs: |
|
||||
* Namespace revealer's `scriptSig`s |
|
||||
|
|
||||
Outputs: |
|
||||
* `OP_RETURN` payload |
|
||||
* Change output to the namespace revealer's `p2pkh` script |
|
||||
|
|
||||
Notes: |
|
||||
* This transaction must be sent within 1 year of the corresponding `NAMESPACE_REVEAL` to be accepted. |
|
||||
|
|
||||
## Method Glossary |
|
||||
|
|
||||
Some hashing primitives are used to construct the wire-format representation of each name operation. They are enumerated here: |
|
||||
|
|
||||
``` |
|
||||
B40_REGEX = '^[a-z0-9\-_.+]*$' |
|
||||
|
|
||||
def is_b40(s): |
|
||||
return isinstance(s, str) and re.match(B40_REGEX, s) is not None |
|
||||
|
|
||||
def b40_to_bin(s): |
|
||||
if not is_b40(s): |
|
||||
raise ValueError('{} must only contain characters in the b40 char set'.format(s)) |
|
||||
return unhexlify(charset_to_hex(s, B40_CHARS)) |
|
||||
|
|
||||
def hexpad(x): |
|
||||
return ('0' * (len(x) % 2)) + x |
|
||||
|
|
||||
def charset_to_hex(s, original_charset): |
|
||||
return hexpad(change_charset(s, original_charset, B16_CHARS)) |
|
||||
|
|
||||
def bin_hash160(s, hex_format=False): |
|
||||
""" s is in hex or binary format |
|
||||
""" |
|
||||
if hex_format and is_hex(s): |
|
||||
s = unhexlify(s) |
|
||||
return hashlib.new('ripemd160', bin_sha256(s)).digest() |
|
||||
|
|
||||
def hex_hash160(s, hex_format=False): |
|
||||
""" s is in hex or binary format |
|
||||
""" |
|
||||
if hex_format and is_hex(s): |
|
||||
s = unhexlify(s) |
|
||||
return hexlify(bin_hash160(s)) |
|
||||
|
|
||||
def hash_name(name, script_pubkey, register_addr=None): |
|
||||
""" |
|
||||
Generate the hash over a name and hex-string script pubkey. |
|
||||
Returns the hex-encoded string RIPEMD160(SHA256(x)), where |
|
||||
x is the byte string composed of the concatenation of the |
|
||||
binary |
|
||||
""" |
|
||||
bin_name = b40_to_bin(name) |
|
||||
name_and_pubkey = bin_name + unhexlify(script_pubkey) |
|
||||
|
|
||||
if register_addr is not None: |
|
||||
name_and_pubkey += str(register_addr) |
|
||||
|
|
||||
# make hex-encoded hash |
|
||||
return hex_hash160(name_and_pubkey) |
|
||||
|
|
||||
def hash128(data): |
|
||||
""" |
|
||||
Hash a string of data by taking its 256-bit sha256 and truncating it to the |
|
||||
first 16 bytes |
|
||||
""" |
|
||||
return hexlify(bin_sha256(data)[0:16]) |
|
||||
``` |
|
||||
@ -1,5 +0,0 @@ |
|||||
# About this `docs` directory |
|
||||
|
|
||||
The contents of this directory acts as source for material for |
|
||||
[docs.blockstack.org](https://docs.blockstack.org/), a searchabe documentation |
|
||||
site for all things Blockstack. |
|
||||
|
Before Width: | Height: | Size: 56 KiB |
@ -1,45 +0,0 @@ |
|||||
--- |
|
||||
layout: core |
|
||||
permalink: /:collection/:path.html |
|
||||
--- |
|
||||
# Installing Memcached |
|
||||
|
|
||||
The Blockstack API optionally uses memcached and pylibmc for scaling read-only |
|
||||
calls. If you want to enable this functionality then you should have memcached |
|
||||
running locally. |
|
||||
|
|
||||
### Memcached on Debian & Ubuntu: |
|
||||
|
|
||||
``` |
|
||||
$ sudo apt-get install -y python-dev libmemcached-dev zlib1g-dev |
|
||||
$ pip install pylibmc |
|
||||
``` |
|
||||
|
|
||||
### Memcached on macOS: |
|
||||
|
|
||||
Easiest way to install memcached on macOS is by using [Homebrew](https://brew.sh/). |
|
||||
|
|
||||
After installing Homebrew: |
|
||||
|
|
||||
``` |
|
||||
$ brew install memcached |
|
||||
$ brew install libmemcached |
|
||||
$ pip install pylibmc --install-option="--with-libmemcached=/usr/local/Cellar/libmemcached/1.0.18_1/" |
|
||||
``` |
|
||||
|
|
||||
After installing, you can start memcached and check if it's running properly: |
|
||||
|
|
||||
``` |
|
||||
$ memcached -d |
|
||||
$ echo stats | nc localhost 11211 |
|
||||
``` |
|
||||
|
|
||||
### Memcached on Heroku |
|
||||
|
|
||||
To deploy on Heroku: |
|
||||
|
|
||||
```bash |
|
||||
$ heroku create |
|
||||
$ heroku addons:add memcachedcloud |
|
||||
$ git push heroku master |
|
||||
``` |
|
||||
@ -1,357 +0,0 @@ |
|||||
mixin TryMe(action) |
|
||||
//- Give a "try-me" link for the public api endpoint |
|
||||
- var myUri = action.uriTemplate |
|
||||
- action.parameters.forEach( function (x) { myUri = myUri.replace( "{" + x.name + "}", x.example) } ) |
|
||||
.title |
|
||||
strong |
|
||||
h4 |
|
||||
div |
|
||||
div |
|
||||
span.method(class="badge get",style="float:left") |
|
||||
a.method(href=myUri, style="color:rgb(51, 122, 183);font-size:12pt") |
|
||||
= "Try It!" |
|
||||
| |
|
||||
p |
|
||||
div |
|
||||
| |
|
||||
|
|
||||
mixin Badge(method) |
|
||||
//- Draw a badge for a given HTTP method |
|
||||
case method |
|
||||
when 'GET' |
|
||||
span.badge.get: i.fa.fa-arrow-down |
|
||||
when 'HEAD' |
|
||||
span.badge.head: i.fa.fa-info-circle |
|
||||
when 'OPTIONS' |
|
||||
span.badge.options: i.fa.fa-dot-circle-o |
|
||||
when 'POST' |
|
||||
span.badge.post: i.fa.fa-plus |
|
||||
when 'PUT' |
|
||||
span.badge.put: i.fa.fa-pencil |
|
||||
when 'PATCH' |
|
||||
span.badge.patch: i.fa.fa-pencil |
|
||||
when 'DELETE' |
|
||||
span.badge.delete: i.fa.fa-times |
|
||||
default |
|
||||
span.badge: i.fa.fa-dot-circle-o |
|
||||
|
|
||||
mixin Nav(onlyPublic) |
|
||||
//- Draw a navigation bar, which includes links to individual |
|
||||
//- resources and actions. |
|
||||
nav |
|
||||
if self.api.navItems && self.api.navItems.length |
|
||||
.resource-group |
|
||||
.heading |
|
||||
.chevron |
|
||||
i.open.fa.fa-angle-down |
|
||||
a(href='#top') Overview |
|
||||
.collapse-content |
|
||||
ul: each item in self.api.navItems |
|
||||
li |
|
||||
a(href=item[1])!= item[0] |
|
||||
- if (onlyPublic){ |
|
||||
- myGroups = self.api.resourceGroups.filter( filter_public_resourcegroups ) |
|
||||
- }else{ |
|
||||
- myGroups = self.api.resourceGroups.filter( filter_core_resourcegroups ) |
|
||||
- } |
|
||||
each resourceGroup in myGroups || [] |
|
||||
.resource-group |
|
||||
.heading |
|
||||
.chevron |
|
||||
i.open.fa.fa-angle-down |
|
||||
a(href=resourceGroup.elementLink)!= resourceGroup.name || 'Resource Group' |
|
||||
.collapse-content |
|
||||
ul |
|
||||
each item in resourceGroup.navItems || [] |
|
||||
li |
|
||||
a(href=item[1])!= item[0] |
|
||||
- if (onlyPublic){ |
|
||||
- myResources = resourceGroup.resources.filter( filter_public_resources ) |
|
||||
- }else{ |
|
||||
- myResources = resourceGroup.resources.filter( filter_core_resources ) |
|
||||
- } |
|
||||
each resource in myResources || [] |
|
||||
li |
|
||||
- if (onlyPublic){ |
|
||||
- myActions = resource.actions.filter( filter_public_actions ) |
|
||||
- }else{ |
|
||||
- myActions = resource.actions.filter( filter_core_actions ) |
|
||||
- } |
|
||||
if !self.condenseNav || (myActions.length != 1) |
|
||||
a(href=resource.elementLink)!= resource.name || 'Resource' |
|
||||
ul: each action in myActions || [] |
|
||||
li: a(href=resource.elementLink) |
|
||||
+Badge(action.method) |
|
||||
!= action.name || action.method + ' ' + (action.attributes && action.attributes.uriTemplate || resource.uriTemplate) |
|
||||
else |
|
||||
- var action = myActions[0] |
|
||||
a(href=resource.elementLink) |
|
||||
+Badge(action.method) |
|
||||
!= action.name || resource.name || action.method + ' ' + (action.attributes && action.attributes.uriTemplate || resource.uriTemplate) |
|
||||
//- Link to the API hostname, e.g. api.yourcompany.com |
|
||||
each meta in self.api.metadata || {} |
|
||||
if meta.name == 'HOST' |
|
||||
p(style="text-align: center; word-wrap: break-word;") |
|
||||
a(href=meta.value)= meta.value |
|
||||
|
|
||||
mixin Parameters(params) |
|
||||
//- Draw a definition list of parameter names, types, defaults, |
|
||||
//- examples and descriptions. |
|
||||
.title |
|
||||
strong URI Parameters |
|
||||
.collapse-button.show |
|
||||
span.close Hide |
|
||||
span.open Show |
|
||||
.collapse-content |
|
||||
dl.inner: each param in params || [] |
|
||||
dt= self.urldec(param.name) |
|
||||
dd |
|
||||
code= param.type || 'string' |
|
||||
| |
|
||||
if param.required |
|
||||
span.required (required) |
|
||||
else |
|
||||
span (optional) |
|
||||
| |
|
||||
if param.default |
|
||||
span.text-info.default |
|
||||
strong Default: |
|
||||
span= param.default |
|
||||
| |
|
||||
if param.example |
|
||||
span.text-muted.example |
|
||||
strong Example: |
|
||||
span= param.example |
|
||||
!= self.markdown(param.description) |
|
||||
if param.values.length |
|
||||
p.choices |
|
||||
strong Choices: |
|
||||
each value in param.values |
|
||||
code= self.urldec(value.value) |
|
||||
= ' ' |
|
||||
|
|
||||
mixin RequestResponse(title, request, collapse) |
|
||||
.title |
|
||||
strong |
|
||||
= title |
|
||||
if request.name |
|
||||
| |
|
||||
code= request.name |
|
||||
if collapse && request.hasContent |
|
||||
.collapse-button |
|
||||
span.close Hide |
|
||||
span.open Show |
|
||||
+RequestResponseBody(request, collapse) |
|
||||
|
|
||||
mixin RequestResponseBody(request, collapse, showBlank) |
|
||||
if request.hasContent || showBlank |
|
||||
div(class=collapse ? 'collapse-content' : ''): .inner |
|
||||
if request.description |
|
||||
.description!= self.markdown(request.description) |
|
||||
|
|
||||
if Object.keys(request.headers).length |
|
||||
h5 Headers |
|
||||
pre: code |
|
||||
each item, index in request.headers |
|
||||
!= self.highlight(item.name + ': ' + item.value, 'http') |
|
||||
if index < request.headers.length - 1 |
|
||||
br |
|
||||
div(style="height: 1px;") |
|
||||
if request.body |
|
||||
h5 Body |
|
||||
pre: code |
|
||||
!= self.highlight(request.body, null, ['json', 'yaml', 'xml', 'javascript']) |
|
||||
div(style="height: 1px;") |
|
||||
if request.schema |
|
||||
h5 Schema |
|
||||
pre: code |
|
||||
!= self.highlight(request.schema, null, ['json', 'yaml', 'xml']) |
|
||||
div(style="height: 1px;") |
|
||||
if !request.hasContent |
|
||||
.description.text-muted This response has no content. |
|
||||
div(style="height: 1px;") |
|
||||
|
|
||||
mixin Examples(resourceGroup, resource, action) |
|
||||
each example in action.examples |
|
||||
each request in example.requests |
|
||||
+RequestResponse('Request', request, true) |
|
||||
each response in example.responses |
|
||||
+RequestResponse('Response', response, true) |
|
||||
|
|
||||
mixin Content() |
|
||||
//- Page header and API description |
|
||||
header |
|
||||
h1#top!= self.api.name || 'API Documentation' |
|
||||
|
|
||||
if self.api.descriptionHtml |
|
||||
!= self.api.descriptionHtml |
|
||||
|
|
||||
//- Loop through and display information about all the resource |
|
||||
//- groups, resources, and actions. |
|
||||
each resourceGroup in self.api.resourceGroups || [] |
|
||||
section.resource-group(id=resourceGroup.elementId) |
|
||||
h2.group-heading |
|
||||
!= resourceGroup.name || 'Resource Group' |
|
||||
= " " |
|
||||
a.permalink(href=resourceGroup.elementLink) ¶ |
|
||||
if resourceGroup.descriptionHtml |
|
||||
!= resourceGroup.descriptionHtml |
|
||||
|
|
||||
each resource in resourceGroup.resources || [] |
|
||||
.resource(id=resource.elementId) |
|
||||
h3.resource-heading |
|
||||
!= resource.name || ((resource.actions[0] != null) && resource.actions[0].name) || 'Resource' |
|
||||
= " " |
|
||||
a.permalink(href=resource.elementLink) ¶ |
|
||||
if resource.description |
|
||||
!= self.markdown(resource.description) |
|
||||
|
|
||||
each action in resource.actions || [] |
|
||||
.action(class=action.methodLower, id=action.elementId) |
|
||||
h4.action-heading |
|
||||
.name!= action.name |
|
||||
a.method(class=action.methodLower, href=action.elementLink) |
|
||||
= action.method |
|
||||
code.uri= self.urldec(action.uriTemplate) |
|
||||
if action.description |
|
||||
!= self.markdown(action.description) |
|
||||
|
|
||||
h4 Example URI |
|
||||
.definition |
|
||||
span.method(class=action.methodLower)= action.method |
|
||||
| |
|
||||
span.uri |
|
||||
span.hostname= self.api.host |
|
||||
!= action.colorizedUriTemplate |
|
||||
|
|
||||
//- A list of sub-sections for parameters, requests |
|
||||
//- and responses. |
|
||||
if action.parameters.length |
|
||||
+Parameters(action.parameters) |
|
||||
if action.examples |
|
||||
+Examples(resourceGroup, resource, action) |
|
||||
|
|
||||
- function filter_public_actions(x){ |
|
||||
- return (x.description.includes('+ Public Endpoint') || x.description.includes('+ Public Only Endpoint')) |
|
||||
- } |
|
||||
- function filter_public_resources(x){ |
|
||||
- return (x.actions.filter( filter_public_actions ).length > 0) |
|
||||
- } |
|
||||
- function filter_public_resourcegroups(x){ |
|
||||
- return (x.resources.filter( filter_public_resources ).length > 0) |
|
||||
- } |
|
||||
- function filter_core_actions(x){ |
|
||||
- return !(x.description.includes('+ Public Only Endpoint')) |
|
||||
- } |
|
||||
- function filter_core_resources(x){ |
|
||||
- return (x.actions.filter( filter_core_actions ).length > 0) |
|
||||
- } |
|
||||
- function filter_core_resourcegroups(x){ |
|
||||
- return (x.resources.filter( filter_core_resources ).length > 0) |
|
||||
- } |
|
||||
|
|
||||
mixin ContentTriple(onlyPublic, descriptionHtml) |
|
||||
|
|
||||
.right |
|
||||
h5 API Endpoint |
|
||||
a(href=self.api.host)= self.api.host |
|
||||
.middle |
|
||||
if descriptionHtml |
|
||||
!= descriptionHtml |
|
||||
|
|
||||
//- Loop through and display information about all the resource |
|
||||
//- groups, resources, and actions. |
|
||||
- if (onlyPublic){ |
|
||||
- myGroups = self.api.resourceGroups.filter( filter_public_resourcegroups ) |
|
||||
- }else{ |
|
||||
- myGroups = self.api.resourceGroups.filter( filter_core_resourcegroups ) |
|
||||
- } |
|
||||
each resourceGroup in myGroups || [] |
|
||||
.middle |
|
||||
section.resource-group(id=resourceGroup.elementId) |
|
||||
h2.group-heading |
|
||||
!= resourceGroup.name || 'Resource Group' |
|
||||
= " " |
|
||||
a.permalink(href=resourceGroup.elementLink) ¶ |
|
||||
if resourceGroup.descriptionHtml |
|
||||
!= resourceGroup.descriptionHtml |
|
||||
|
|
||||
- if (onlyPublic){ |
|
||||
- myResources = resourceGroup.resources.filter( filter_public_resources ) |
|
||||
- }else{ |
|
||||
- myResources = resourceGroup.resources.filter( filter_core_resources ) |
|
||||
- } |
|
||||
each resource in myResources || [] |
|
||||
if resource.public != null |
|
||||
.middle |
|
||||
.resource(id=resource.elementId) |
|
||||
a.permalink(href=resource.elementLink) |
|
||||
h3.resource-heading |
|
||||
!= resource.name || ((resource.actions[0] != null) && resource.actions[0].name) || 'Resource' |
|
||||
= " " |
|
||||
¶ |
|
||||
if resource.description |
|
||||
!= self.markdown(resource.description) |
|
||||
|
|
||||
- if (onlyPublic){ |
|
||||
- myActions = resource.actions.filter( filter_public_actions ) |
|
||||
- }else{ |
|
||||
- myActions = resource.actions.filter( filter_core_actions ) |
|
||||
- } |
|
||||
each action in myActions || [] |
|
||||
if action.examples |
|
||||
.right |
|
||||
.definition |
|
||||
span.method(class=action.methodLower)= action.method |
|
||||
| |
|
||||
span.uri |
|
||||
span.hostname= self.api.host |
|
||||
!= action.colorizedUriTemplate |
|
||||
.tabs |
|
||||
if action.hasRequest |
|
||||
.example-names |
|
||||
span Requests |
|
||||
- var requestCount = 0 |
|
||||
each example in action.examples |
|
||||
each request in example.requests |
|
||||
- requestCount++ |
|
||||
span.tab-button= request.name || 'example ' + requestCount |
|
||||
each example in action.examples |
|
||||
each request in example.requests |
|
||||
.tab |
|
||||
+RequestResponseBody(request, false, true) |
|
||||
.tabs |
|
||||
.example-names |
|
||||
span Responses |
|
||||
each response in example.responses |
|
||||
span.tab-button= response.name |
|
||||
each response in example.responses |
|
||||
.tab |
|
||||
+RequestResponseBody(response, false, true) |
|
||||
else |
|
||||
each example in action.examples |
|
||||
.tabs |
|
||||
.example-names |
|
||||
span Responses |
|
||||
each response in example.responses |
|
||||
span.tab-button= response.name |
|
||||
each response in example.responses |
|
||||
.tab |
|
||||
+RequestResponseBody(response, false, true) |
|
||||
.middle |
|
||||
.action(class=action.methodLower, id=action.elementId) |
|
||||
h4.action-heading |
|
||||
.name!= action.name |
|
||||
a.method(class=action.methodLower, href=action.elementLink) |
|
||||
= action.method |
|
||||
code.uri= self.urldec(action.uriTemplate) |
|
||||
if action.description |
|
||||
!= self.markdown(action.description) |
|
||||
|
|
||||
//- A list of sub-sections for parameters, requests |
|
||||
//- and responses. |
|
||||
if action.parameters.length |
|
||||
+Parameters(action.parameters) |
|
||||
if onlyPublic |
|
||||
+TryMe(action) |
|
||||
hr.split |
|
||||
@ -1,249 +0,0 @@ |
|||||
--- |
|
||||
layout: core |
|
||||
permalink: /:collection/:path.html |
|
||||
--- |
|
||||
# BNS Subdomains |
|
||||
|
|
||||
{:.no_toc} |
|
||||
|
|
||||
This section explains BNS subdomains and provides instructions for methods |
|
||||
you can use to work with them. The following topics are included: |
|
||||
|
|
||||
* TOC |
|
||||
{:toc} |
|
||||
|
|
||||
# Overview of subdomains |
|
||||
|
|
||||
BNS names are strongly-owned because the owner of its private key can generate |
|
||||
valid transactions that update its zone file hash and owner. However, this comes at the |
|
||||
cost of requiring a name owner to pay for the underlying transaction in the |
|
||||
blockchain. Moreover, this approach limits the rate of BNS name registrations |
|
||||
and operations to the underlying blockchain's transaction bandwidth. |
|
||||
|
|
||||
BNS overcomes this with subdomains. A **BNS subdomain** is a type of BNS name whose state |
|
||||
and owner are stored outside of the blockchain, but whose existence and |
|
||||
operation history are anchored to the |
|
||||
blockchain. In the example table in the [Resolving BNS |
|
||||
Names](#resolving-bns-names) section, the names `cicero.res_publica.id` and |
|
||||
`podsaveamerica.verified.podcast` are subdomains. |
|
||||
|
|
||||
Like their on-chain counterparts, subdomains are globally |
|
||||
unique, strongly-owned, and human-readable. BNS gives them their own name state |
|
||||
and public keys. |
|
||||
|
|
||||
Unlike on-chain names, subdomains can be created and managed |
|
||||
cheaply, because they are broadcast to the |
|
||||
BNS network in batches. A single blockchain transaction can send up to 120 |
|
||||
subdomain operations. |
|
||||
|
|
||||
This is achieved by storing subdomain records in the [Atlas Network]({{ site.baseurl }}/core/atlas/overview.html). |
|
||||
An on-chain name owner broadcasts subdomain operations by encoding them as |
|
||||
`TXT` records within a DNS zone file. To broadcast the zone file, |
|
||||
the name owner sets the new zone file hash with a `NAME_UPDATE` transaction and |
|
||||
replicates the zone file via Atlas. This, in turn, replicates all subdomain |
|
||||
operations it contains, and anchors the set of subdomain operations to |
|
||||
an on-chain transaction. The BNS node's consensus rules ensure that only |
|
||||
valid subdomain operations from *valid* `NAME_UPDATE` transactions will ever be |
|
||||
stored. |
|
||||
|
|
||||
For example, the name `verified.podcast` once wrote the zone file hash `247121450ca0e9af45e85a82e61cd525cd7ba023`, |
|
||||
which is the hash of the following zone file: |
|
||||
|
|
||||
```bash |
|
||||
$ curl -sL https://core.blockstack.org/v1/names/verified.podcast/zonefile/247121450ca0e9af45e85a82e61cd525cd7ba023 | jq -r '.zonefile' |
|
||||
$ORIGIN verified.podcast |
|
||||
$TTL 3600 |
|
||||
1yeardaily TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiAxeWVhcmRhaWx5CiRUVEwgMzYwMApfaHR0cC5fdGNwIFVSSSAxMCAxICJodHRwczovL3BoLmRvdHBvZGNhc3QuY28vMXllYXJkYWlseS9oZWFkLmpzb24iCg==" |
|
||||
2dopequeens TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiAyZG9wZXF1ZWVucwokVFRMIDM2MDAKX2h0dHAuX3RjcCBVUkkgMTAgMSAiaHR0cHM6Ly9waC5kb3Rwb2RjYXN0LmNvLzJkb3BlcXVlZW5zL2hlYWQuanNvbiIK" |
|
||||
10happier TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiAxMGhhcHBpZXIKJFRUTCAzNjAwCl9odHRwLl90Y3AgVVJJIDEwIDEgImh0dHBzOi8vcGguZG90cG9kY2FzdC5jby8xMGhhcHBpZXIvaGVhZC5qc29uIgo=" |
|
||||
31thoughts TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiAzMXRob3VnaHRzCiRUVEwgMzYwMApfaHR0cC5fdGNwIFVSSSAxMCAxICJodHRwczovL3BoLmRvdHBvZGNhc3QuY28vMzF0aG91Z2h0cy9oZWFkLmpzb24iCg==" |
|
||||
359 TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiAzNTkKJFRUTCAzNjAwCl9odHRwLl90Y3AgVVJJIDEwIDEgImh0dHBzOi8vcGguZG90cG9kY2FzdC5jby8zNTkvaGVhZC5qc29uIgo=" |
|
||||
30for30 TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiAzMGZvcjMwCiRUVEwgMzYwMApfaHR0cC5fdGNwIFVSSSAxMCAxICJodHRwczovL3BoLmRvdHBvZGNhc3QuY28vMzBmb3IzMC9oZWFkLmpzb24iCg==" |
|
||||
onea TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiBvbmVhCiRUVEwgMzYwMApfaHR0cC5fdGNwIFVSSSAxMCAxICJodHRwczovL3BoLmRvdHBvZGNhc3QuY28vb25lYS9oZWFkLmpzb24iCg==" |
|
||||
10minuteteacher TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiAxMG1pbnV0ZXRlYWNoZXIKJFRUTCAzNjAwCl9odHRwLl90Y3AgVVJJIDEwIDEgImh0dHBzOi8vcGguZG90cG9kY2FzdC5jby8xMG1pbnV0ZXRlYWNoZXIvaGVhZC5qc29uIgo=" |
|
||||
36questionsthepodcastmusical TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiAzNnF1ZXN0aW9uc3RoZXBvZGNhc3RtdXNpY2FsCiRUVEwgMzYwMApfaHR0cC5fdGNwIFVSSSAxMCAxICJodHRwczovL3BoLmRvdHBvZGNhc3QuY28vMzZxdWVzdGlvbnN0aGVwb2RjYXN0bXVzaWNhbC9oZWFkLmpzb24iCg==" |
|
||||
_http._tcp URI 10 1 "https://dotpodcast.co/" |
|
||||
``` |
|
||||
|
|
||||
Each `TXT` record in this zone file encodes a subdomain-creation. |
|
||||
For example, `1yeardaily.verified.podcast` resolves to: |
|
||||
|
|
||||
```bash |
|
||||
$ curl https://core.blockstack.org/v1/names/1yeardaily.verified.podcast |
|
||||
{ |
|
||||
"address": "1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH", |
|
||||
"blockchain": "bitcoin", |
|
||||
"last_txid": "d87a22ebab3455b7399bfef8a41791935f94bc97aee55967edd5a87f22cce339", |
|
||||
"status": "registered_subdomain", |
|
||||
"zonefile_hash": "e7acc97fd42c48ed94fd4d41f674eddbee5557e3", |
|
||||
"zonefile_txt": "$ORIGIN 1yeardaily\n$TTL 3600\n_http._tcp URI 10 1 \"https://ph.dotpodcast.co/1yeardaily/head.json\"\n" |
|
||||
} |
|
||||
``` |
|
||||
|
|
||||
This information was extracted from the `1yeardaily` `TXT` resource record in the zone |
|
||||
file for `verified.podcast`. |
|
||||
|
|
||||
## Subdomain Lifecycle |
|
||||
|
|
||||
Note that `1yeardaily.verified.podcast` has a different public key |
|
||||
hash (address) than `verified.podcast`. A BNS node will only process a |
|
||||
subsequent subdomain operation on `1yeardaily.verified.podcast` if it includes a |
|
||||
signature from this address's private key. `verified.podcast` cannot generate |
|
||||
updates; only the owner of `1yeardaily.verified.podcast can do so`. |
|
||||
|
|
||||
The lifecycle of a subdomain and its operations is shown in Figure 2. |
|
||||
|
|
||||
``` |
|
||||
subdomain subdomain subdomain |
|
||||
creation update transfer |
|
||||
+----------------+ +----------------+ +----------------+ |
|
||||
| cicero | | cicero | | cicero | |
|
||||
| owner="1Et..." | signed | owner="1Et..." | signed | owner="1cJ..." | |
|
||||
| zf0="7e4..." |<--------| zf0="111..." |<--------| zf0="111..." |<---- ... |
|
||||
| seqn=0 | | seqn=1 | | seqn=2 | |
|
||||
| | | sig="xxxx" | | sig="xxxx" | |
|
||||
+----------------+ +----------------+ +----------------+ |
|
||||
| | | |
|
||||
| off-chain | | |
|
||||
~ ~ ~ ~ | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~|~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | ~ ~ ~ ~ ~ ~ ~ ... |
|
||||
| on-chain | | |
|
||||
V V (zone file hash ) V |
|
||||
+----------------+ +----------------+ +----------------+ |
|
||||
| res_publica.id | | jude.id | | res_publica.id | |
|
||||
| NAME_UPDATE |<--------| NAME_UPDATE |<--------| NAME_UPDATE |<---- ... |
|
||||
+----------------+ +----------------+ +----------------+ |
|
||||
blockchain blockchain blockchain |
|
||||
block block block |
|
||||
|
|
||||
|
|
||||
Figure 2: Subdomain lifetime with respect to on-chain name operations. A new |
|
||||
subdomain operation will only be accepted if it has a later "sequence=" number, |
|
||||
and a valid signature in "sig=" over the transaction body. The "sig=" field |
|
||||
includes both the public key and signature, and the public key must hash to |
|
||||
the previous subdomain operation's "addr=" field. |
|
||||
|
|
||||
Thesubdomain-creation and subdomain-transfer transactions for |
|
||||
"cicero.res_publica.id" are broadcast by the owner of "res_publica.id". |
|
||||
However, any on-chain name ("jude.id" in this case) can broadcast a subdomain |
|
||||
update for "cicero.res_publica.id". |
|
||||
``` |
|
||||
|
|
||||
Subdomain operations are ordered by sequence number, starting at 0. Each new |
|
||||
subdomain operation must include: |
|
||||
|
|
||||
* The next sequence number |
|
||||
* The public key that hashes to the previous subdomain transaction's address |
|
||||
* A signature from the corresponding private key over the entire subdomain |
|
||||
operation. |
|
||||
|
|
||||
If two correctly-signed but conflicting subdomain operations are discovered |
|
||||
(i.e. they have the same sequence number), the one that occurs earlier in the |
|
||||
blockchain's history is accepted. Invalid subdomain operations are ignored. |
|
||||
|
|
||||
Combined, this ensures that a BNS node with all of the zone files with a given |
|
||||
subdomain's operations will be able to determine the valid sequence of |
|
||||
state-transitions it has undergone, and determine the current zone file and public |
|
||||
key hash for the subdomain. |
|
||||
|
|
||||
## Resolving Subdomains |
|
||||
|
|
||||
Developers interact with subdomains the same way they interact with names. |
|
||||
Using the BNS API, a developer can: |
|
||||
|
|
||||
### Look up a subdomain's public key and zone file ([reference](https://core.blockstack.org/#name-querying-get-name-info)) |
|
||||
|
|
||||
```bash |
|
||||
$ curl https://core.blockstack.org/v1/names/aaron.personal.id |
|
||||
{ |
|
||||
"address": "1PwztPFd1s2STMv4Ntq6UPBdYgHSBr5pdF", |
|
||||
"blockchain": "bitcoin", |
|
||||
"last_txid": "85e8273b0a38d3e9f0af7b4b72faf0907de9f4616afc101caac13e7bbc832394", |
|
||||
"status": "registered_subdomain", |
|
||||
"zonefile_hash": "a6dda6b74ffecf85f4a162627d8df59577243813", |
|
||||
"zonefile_txt": "$ORIGIN aaron.personal.id\n$TTL 3600\n_https._tcp URI 10 1 \"https://gaia.blockstack.org/hub/1PwztPFd1s2STMv4Ntq6UPBdYgHSBr5pdF/profile.json\"\n" |
|
||||
} |
|
||||
``` |
|
||||
|
|
||||
### Look up a subdomain's transaction history ([reference](https://core.blockstack.org/#name-querying-name-history)) |
|
||||
|
|
||||
```bash |
|
||||
$ curl https://core.blockstack.org/v1/names/aaron.personal.id/history |
|
||||
{ |
|
||||
"509981": [ |
|
||||
{ |
|
||||
"address": "1PwztPFd1s2STMv4Ntq6UPBdYgHSBr5pdF", |
|
||||
"block_number": 509981, |
|
||||
"domain": "personal.id", |
|
||||
"name": "aaron.personal.id", |
|
||||
"sequence": 0, |
|
||||
"txid": "85e8273b0a38d3e9f0af7b4b72faf0907de9f4616afc101caac13e7bbc832394", |
|
||||
"value_hash": "a6dda6b74ffecf85f4a162627d8df59577243813", |
|
||||
"zonefile": "JE9SSUdJTiBhYXJvbi5wZXJzb25hbC5pZAokVFRMIDM2MDAKX2h0dHBzLl90Y3AgVVJJIDEwIDEgImh0dHBzOi8vZ2FpYS5ibG9ja3N0YWNrLm9yZy9odWIvMVB3enRQRmQxczJTVE12NE50cTZVUEJkWWdIU0JyNXBkRi9wcm9maWxlLmpzb24iCg==" |
|
||||
} |
|
||||
] |
|
||||
} |
|
||||
``` |
|
||||
|
|
||||
### Look up the list of names and subdomains owned by a given public key hash ([reference](https://core.blockstack.org/#name-querying-get-names-owned-by-address)) |
|
||||
|
|
||||
```bash |
|
||||
$ curl https://core.blockstack.org/v1/addresses/bitcoin/1PwztPFd1s2STMv4Ntq6UPBdYgHSBr5pdF |
|
||||
{ |
|
||||
"names": [ |
|
||||
"aaron.personal.id" |
|
||||
] |
|
||||
} |
|
||||
``` |
|
||||
|
|
||||
## Subdomain Creation and Management |
|
||||
|
|
||||
Unlike an on-chain name, a subdomain owner needs an on-chain name owner's help |
|
||||
to broadcast their subdomain operations. In particular: |
|
||||
* A subdomain-creation transaction can only be processed by the owner of the on-chain |
|
||||
name that shares its suffix. For example, only the owner of `res_publica.id` |
|
||||
can broadcast subdomain-creation transactions for subdomain names ending in |
|
||||
`.res_publica.id`. |
|
||||
* A subdomain-transfer transaction can only be broadcast by the owner of the |
|
||||
on-chain name that created it. For example, the owner of |
|
||||
`cicero.res_publica.id` needs the owner of `res_publica.id` to broadcast a |
|
||||
subdomain-transfer transaction to change `cicero.res_publica.id`'s public key. |
|
||||
* In order to send a subdomain-creation or subdomain-transfer, all |
|
||||
of an on-chain name owner's zone files must be present in the Atlas network. |
|
||||
This lets the BNS node prove the *absence* of any conflicting subdomain-creation and |
|
||||
subdomain-transfer operations when processing new zone files. |
|
||||
* A subdomain update transaction can be broadcast by *any* on-chain name owner, |
|
||||
but the subdomain owner needs to find one who will cooperate. For example, |
|
||||
the owner of `verified.podcast` can broadcast a subdomain-update transaction |
|
||||
created by the owner of `cicero.res_publica.id`. |
|
||||
|
|
||||
That said, to create a subdomain, the subdomain owner generates a |
|
||||
subdomain-creation operation for their desired name |
|
||||
and gives it to the on-chain name owner. |
|
||||
The on-chain name owner then uses Atlas to |
|
||||
broadcast it to all other BNS nodes. |
|
||||
|
|
||||
Once created, a subdomain owner can use any on-chain name owner to broadcast a |
|
||||
subdomain-update operation. To do so, they generate and sign the requisite |
|
||||
subdomain operation and give it to an on-chain name owner, who then packages it |
|
||||
with other subdomain operations into a DNS zone file |
|
||||
and sends them all out on the Atlas network. |
|
||||
|
|
||||
If the subdomain owner wants to change the address of their subdomain, they need |
|
||||
to sign a subdomain-transfer operation and give it to the on-chain name owner |
|
||||
who created the subdomain. They then package it into a zone file and broadcast |
|
||||
it. |
|
||||
|
|
||||
## Subdomain Registrars |
|
||||
|
|
||||
Because subdomain names are cheap, developers may be inclined to run |
|
||||
subdomain registrars on behalf of their applications. For example, |
|
||||
the name `personal.id` is used to register Blockstack application users without |
|
||||
requiring them to spend any Bitcoin. |
|
||||
|
|
||||
We supply a reference |
|
||||
implementation of a [BNS Subdomain Registrar](https://github.com/blockstack/subdomain-registrar) |
|
||||
to help developers broadcast subdomain operations. Users would still own their |
|
||||
subdomain names; the registrar simply gives developers a convenient way for them |
|
||||
to register and manage them in the context of a particular application. |
|
||||
Please see the [tutorial on running a subdomain registrar]({{ site.baseurl }}/core/naming/tutorial_subdomains.html) for |
|
||||
details on how to use it. |
|
||||
|
Before Width: | Height: | Size: 33 KiB |
@ -1,33 +0,0 @@ |
|||||
# Blockstack Resolver |
|
||||
|
|
||||
During 2014-2016, Bockstack resolver was a separate service (like DNS resolvers). |
|
||||
It was merged into the Blockstack API in early 2017. |
|
||||
|
|
||||
The following (legacy) API call is still being supported by the Blockstack API: |
|
||||
|
|
||||
``` |
|
||||
http://localhost:5000/v2/users/fredwilson |
|
||||
``` |
|
||||
|
|
||||
And you can see a legacy resolver in action at http://resolver.onename.com/v2/users/fredwilson |
|
||||
|
|
||||
## Cron Job for Namespaces |
|
||||
|
|
||||
**Note: the instructions below need updating.** |
|
||||
|
|
||||
Currently, the resolver indexes all valid names in a local file which can be |
|
||||
populated by running |
|
||||
> $ ./refresh_names.sh |
|
||||
|
|
||||
On a production deployment, you should add a crond job to periodically run this |
|
||||
script. You can edit your crontab file by: |
|
||||
> $ crontab -e |
|
||||
|
|
||||
Here is a sample crontab file that runs the refresh script every two hours: |
|
||||
``` |
|
||||
SHELL=/bin/bash |
|
||||
HOME=/home/ubuntu |
|
||||
|
|
||||
#This is a comment |
|
||||
0 */2 * * * /home/ubuntu/resolver/resolver/refresh_names.sh |
|
||||
``` |
|
||||
@ -1,254 +0,0 @@ |
|||||
--- |
|
||||
layout: core |
|
||||
permalink: /:collection/:path.html |
|
||||
--- |
|
||||
## Resolve a name |
|
||||
{:.no_toc} |
|
||||
|
|
||||
This section explains resolving BNS names and provides instructions for methods |
|
||||
you can use to accomplish namespace resolution. |
|
||||
|
|
||||
* TOC |
|
||||
{:toc} |
|
||||
|
|
||||
## Understand resolution |
|
||||
|
|
||||
BNS names are bound to both public keys and to about 40Kb of off-chain state. |
|
||||
The off-chain state is encoded as a [DNS zone file](https://en.wikipedia.org/wiki/Zone_file), |
|
||||
which contains routing information for discovering the user's Blockstack data |
|
||||
(such as their profile and app data, which are hosted in the [Gaia storage |
|
||||
system](https://github.com/blockstack/gaia)). |
|
||||
|
|
||||
The blockchain is not used to store this information directly. Instead, the |
|
||||
blockchain stores the *public key hash* and the *zone file hash*. When |
|
||||
indexing the blockchain, each BNS node builds a database with |
|
||||
three columns: all the on-chain BNS names that have been registered, each |
|
||||
name's public key hash, and each name's zone file's hash. |
|
||||
In addition, each BNS node maintains the *transaction history* of each name. |
|
||||
A developer can resolve a name to any configuration it was in at any prior |
|
||||
point in time. |
|
||||
|
|
||||
Below is an example name table pulled from a live BNS node: |
|
||||
|
|
||||
| Name | Public key hash | Zone File Hash | |
|
||||
|------|-----------------|--------------| |
|
||||
| `ryan.id` | `15BcxePn59Y6mYD2fRLCLCaaHScefqW2No` | `a455954b3e38685e487efa41480beeb315f4ec65` | |
|
||||
| `muneeb.id` | `1J3PUxY5uDShUnHRrMyU6yKtoHEUPhKULs` | `37aecf837c6ae9bdc9dbd98a268f263dacd00361` | |
|
||||
| `jude.id` | `16EMaNw3pkn3v6f2BgnSSs53zAKH4Q8YJg` | `b6e99200125e70d634b17fe61ce55b09881bfafd` | |
|
||||
| `verified.podcast` | `1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH` | `6701ce856620d4f2f57cd23b166089759ef6eabd` | |
|
||||
| `cicero.res_publica.id` | `1EtE77Aa5AA8etzF2irk56vvkS4v7rZ7PE` | `7e4ac75f9d79ba9d5d284fac19617497433b832d` | |
|
||||
| `podsaveamerica.verified.podcast` | `1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH` | `0d6f090db8945aa0e60759f9c866b17645893a95` | |
|
||||
|
|
||||
In practice, the zone file hash is the `RIPEMD160` hash of the `SHA256` hash of |
|
||||
the zone file, and the public key is the `base58check`-encoded `RIPEMD160` hash |
|
||||
of the double-`SHA256` hash of the ECDSA public key (i.e. a Bitcoin address). |
|
||||
|
|
||||
The BNS consensus rules ensure that |
|
||||
a BNS name can only be registered if it is not already taken, and that only the |
|
||||
user who owns the name's private key can change its public key hash or zone file |
|
||||
hash. This means that a name's public key and zone file can be stored anywhere, |
|
||||
since they can be authenticated using the hashes discovered by indexing the |
|
||||
blockchain under the BNS consensus rules. |
|
||||
|
|
||||
BNS nodes implement a decentralized storage system for zone files called the |
|
||||
[Atlas network]({{ site.baseurl }}/core/atlas/overview.html). In this system, BNS nodes eagerly replicate |
|
||||
all the zone files they know about to one another, so that eventually every BNS |
|
||||
node has a full replica of all zone files. |
|
||||
|
|
||||
The public keys for names are stored off-chain in [Gaia](https://github.com/blockstack/gaia). |
|
||||
The user controls where their public keys are hosted using the zone file |
|
||||
contents (if they are hosted online anywhere at all). |
|
||||
|
|
||||
Developers can query this table via the BNS API. The API offers routes |
|
||||
to do the following: |
|
||||
|
|
||||
## Look up a name's public key and zone file ([reference](https://core.blockstack.org/#name-querying-get-name-info)) |
|
||||
|
|
||||
```bash |
|
||||
$ curl https://core.blockstack.org/v1/names/muneeb.id |
|
||||
{ |
|
||||
"address": "1J3PUxY5uDShUnHRrMyU6yKtoHEUPhKULs", |
|
||||
"blockchain": "bitcoin", |
|
||||
"expire_block": 599266, |
|
||||
"last_txid": "7e16e8688ca0413a398bbaf16ad4b10d3c9439555fc140f58e5ab4e50793c476", |
|
||||
"status": "registered", |
|
||||
"zonefile": "$ORIGIN muneeb.id\n$TTL 3600\n_http._tcp URI 10 1 \"https://gaia.blockstack.org/hub/1J3PUxY5uDShUnHRrMyU6yKtoHEUPhKULs/0/profile.json\"\n", |
|
||||
"zonefile_hash": "37aecf837c6ae9bdc9dbd98a268f263dacd00361" |
|
||||
} |
|
||||
``` |
|
||||
|
|
||||
Note that the `zonefile` field is given with the off-chain data that hashes |
|
||||
to the `zonefile_hash` field. |
|
||||
|
|
||||
## List all names the node knows about ([reference](https://core.blockstack.org/#name-querying-get-all-names)) |
|
||||
|
|
||||
```bash |
|
||||
$ curl https://core.blockstack.org/v1/names?page=0 |
|
||||
[ |
|
||||
"judecn.id", |
|
||||
"3.id", |
|
||||
"4.id", |
|
||||
"8.id", |
|
||||
"e.id", |
|
||||
"h.id", |
|
||||
"5.id", |
|
||||
"9.id", |
|
||||
"i.id", |
|
||||
"l.id", |
|
||||
"p.id", |
|
||||
"w.id", |
|
||||
"ba.id", |
|
||||
"df.id", |
|
||||
... |
|
||||
] |
|
||||
``` |
|
||||
|
|
||||
Each page returns 100 names. While no specific ordering is mandated by the |
|
||||
protocol, the reference implementation orders names by their order of creation |
|
||||
in the blockchain. |
|
||||
|
|
||||
## Look up the history of states a name was in ([reference](https://core.blockstack.org/#name-querying-name-history)) |
|
||||
|
|
||||
```bash |
|
||||
$ curl https://core.blockstack.org/v1/names/patrickstanley.id/history |
|
||||
{ |
|
||||
"445838": [ |
|
||||
{ |
|
||||
"address": "1occgbip7tFDXX9MvzQhcnTUUjcVX2dYK", |
|
||||
"block_number": 445838, |
|
||||
"burn_address": "1111111111111111111114oLvT2", |
|
||||
"consensus_hash": "7b696b6f4060b792d41912068944d73b", |
|
||||
"op": "?", |
|
||||
"op_fee": 25000, |
|
||||
"opcode": "NAME_PREORDER", |
|
||||
"preorder_hash": "26bf7874706ac761afdd403ed6b3b9578fb01a34", |
|
||||
"sender": "76a91408d0dd44c1f0a3a4f0957ae95901929d7d66d55788ac", |
|
||||
"sender_pubkey": "039a8948d339ecbff44cf426cb85d90fce876f1658d385cdc47f007f279be626ea", |
|
||||
"txid": "6730ae09574d5935ffabe3dd63a9341ea54fafae62fde36c27738e9ee9c4e889", |
|
||||
"vtxindex": 40 |
|
||||
} |
|
||||
], |
|
||||
"445851": [ |
|
||||
{ |
|
||||
"address": "17CbHgTgBG3kLedXNneEKBkCTgW2fyrnUD", |
|
||||
"block_number": 445838, |
|
||||
"consensus_hash": null, |
|
||||
"first_registered": 445851, |
|
||||
"importer": null, |
|
||||
"importer_address": null, |
|
||||
"last_creation_op": "?", |
|
||||
"last_renewed": 445851, |
|
||||
"name": "patrickstanley.id", |
|
||||
"name_hash128": "683a3e1ee5f0296833c56e481cf41b77", |
|
||||
"namespace_block_number": 373601, |
|
||||
"namespace_id": "id", |
|
||||
"op": ":", |
|
||||
"op_fee": 25000, |
|
||||
"opcode": "NAME_REGISTRATION", |
|
||||
"preorder_block_number": 445838, |
|
||||
"preorder_hash": "26bf7874706ac761afdd403ed6b3b9578fb01a34", |
|
||||
"revoked": false, |
|
||||
"sender": "76a9144401f3be5311585ea519c1cb471a8dc7b02fd6ee88ac", |
|
||||
"sender_pubkey": "039a8948d339ecbff44cf426cb85d90fce876f1658d385cdc47f007f279be626ea", |
|
||||
"transfer_send_block_id": null, |
|
||||
"txid": "55b8b42fc3e3d23cbc0f07d38edae6a451dfc512b770fd7903725f9e465b2925", |
|
||||
"value_hash": null, |
|
||||
"vtxindex": 54 |
|
||||
} |
|
||||
], |
|
||||
"445873": [ |
|
||||
{ |
|
||||
"address": "17CbHgTgBG3kLedXNneEKBkCTgW2fyrnUD", |
|
||||
"block_number": 445838, |
|
||||
"consensus_hash": "18b8d69f0182b89ccb1aa536f83be18a", |
|
||||
"first_registered": 445851, |
|
||||
"importer": null, |
|
||||
"importer_address": null, |
|
||||
"last_creation_op": "?", |
|
||||
"last_renewed": 445851, |
|
||||
"name": "patrickstanley.id", |
|
||||
"name_hash128": "683a3e1ee5f0296833c56e481cf41b77", |
|
||||
"namespace_block_number": 373601, |
|
||||
"namespace_id": "id", |
|
||||
"op": "+", |
|
||||
"op_fee": 25000, |
|
||||
"opcode": "NAME_UPDATE", |
|
||||
"preorder_block_number": 445838, |
|
||||
"preorder_hash": "26bf7874706ac761afdd403ed6b3b9578fb01a34", |
|
||||
"revoked": false, |
|
||||
"sender": "76a9144401f3be5311585ea519c1cb471a8dc7b02fd6ee88ac", |
|
||||
"sender_pubkey": "039a8948d339ecbff44cf426cb85d90fce876f1658d385cdc47f007f279be626ea", |
|
||||
"transfer_send_block_id": null, |
|
||||
"txid": "dc478659fc684a1a6e1e09901971e82de11f4dfe2b32a656700bf9a3b6030719", |
|
||||
"value_hash": "02af0ef21161ad06b0923106f40b994b9e4c1614", |
|
||||
"vtxindex": 95 |
|
||||
} |
|
||||
], |
|
||||
"445884": [ |
|
||||
{ |
|
||||
"address": "1GZqrVbamkaE6YNveJFWK6cDrCy6bXyS6b", |
|
||||
"block_number": 445838, |
|
||||
"consensus_hash": "18b8d69f0182b89ccb1aa536f83be18a", |
|
||||
"first_registered": 445851, |
|
||||
"importer": null, |
|
||||
"importer_address": null, |
|
||||
"last_creation_op": "?", |
|
||||
"last_renewed": 445851, |
|
||||
"name": "patrickstanley.id", |
|
||||
"name_hash128": "683a3e1ee5f0296833c56e481cf41b77", |
|
||||
"namespace_block_number": 373601, |
|
||||
"namespace_id": "id", |
|
||||
"op": ">>", |
|
||||
"op_fee": 25000, |
|
||||
"opcode": "NAME_TRANSFER", |
|
||||
"preorder_block_number": 445838, |
|
||||
"preorder_hash": "26bf7874706ac761afdd403ed6b3b9578fb01a34", |
|
||||
"revoked": false, |
|
||||
"sender": "76a914aabffa6dd90d731d3a349f009323bb312483c15088ac", |
|
||||
"sender_pubkey": null, |
|
||||
"transfer_send_block_id": 445875, |
|
||||
"txid": "7a0a3bb7d39b89c3638abc369c85b5c028d0a55d7804ba1953ff19b0125f3c24", |
|
||||
"value_hash": "02af0ef21161ad06b0923106f40b994b9e4c1614", |
|
||||
"vtxindex": 16 |
|
||||
} |
|
||||
] |
|
||||
} |
|
||||
``` |
|
||||
|
|
||||
All of the above information is extracted from the blockchain. Each top-level |
|
||||
field encodes the states the name transitioned to at the given block height (e.g. |
|
||||
445838, 445851, 445873, adn 445884). At each block height, the name's zone file |
|
||||
hashes are returned in the order they were discovered in the blockchain. |
|
||||
|
|
||||
Each name state contains a lot of ancillary data that is used internally by |
|
||||
other API calls and client libraries. The relevant fields for this document's |
|
||||
scope are: |
|
||||
|
|
||||
* `address`: This is the base58check-encoded public key hash. |
|
||||
* `name`: This is the name queried. |
|
||||
* `value_hash`: This is the zone file hash. |
|
||||
* `opcode`: This is the type of transaction that was processed. |
|
||||
* `txid`: This is the transaction ID in the underlying blockchain. |
|
||||
|
|
||||
The name's *entire* history is returned. This includes the history of the name |
|
||||
under its previous owner, if the name expired and was reregistered. |
|
||||
|
|
||||
## Look up the list of names owned by a given public key hash ([reference](https://core.blockstack.org/#name-querying-get-names-owned-by-address)) |
|
||||
|
|
||||
```bash |
|
||||
$ curl https://core.blockstack.org/v1/addresses/bitcoin/16EMaNw3pkn3v6f2BgnSSs53zAKH4Q8YJg |
|
||||
{ |
|
||||
"names": [ |
|
||||
"judecn.id", |
|
||||
"patrickstanley1.id", |
|
||||
"abcdefgh123456.id", |
|
||||
"duckduckgo_tor.id", |
|
||||
"jude.id", |
|
||||
"blockstacknewyear2017.id", |
|
||||
"jude.statism.id" |
|
||||
] |
|
||||
} |
|
||||
``` |
|
||||
|
|
||||
Note that this API endpoint includes names and |
|
||||
[subdomains](#bns-subdomains). |
|
||||
@ -1,78 +0,0 @@ |
|||||
--- |
|
||||
layout: core |
|
||||
permalink: /:collection/:path.html |
|
||||
--- |
|
||||
# Understand Namespaces |
|
||||
|
|
||||
Namespaces are the top-level naming objects in BNS. |
|
||||
|
|
||||
They control a few properties about the names within them: |
|
||||
* How expensive they are to register |
|
||||
* How long they last before they have to be renewed |
|
||||
* Who (if anyone) receives the name registration fees |
|
||||
* Who is allowed to seed the namespace with its initial names. |
|
||||
|
|
||||
At the time of this writing, by far the largest BNS namespace is the `.id` |
|
||||
namespace. Names in the `.id` namespace are meant for resolving user |
|
||||
identities. Short names in `.id` are more expensive than long names, and have |
|
||||
to be renewed by their owners every two years. Name registration fees are not |
|
||||
paid to anyone in particular---they are instead sent to a "black hole" where |
|
||||
they are rendered unspendable (the intention is to discourage ID sqautters). |
|
||||
|
|
||||
Unlike DNS, *anyone* can create a namespace and set its properties. Namespaces |
|
||||
are created on a first-come first-serve basis, and once created, they last |
|
||||
forever. |
|
||||
|
|
||||
However, creating a namespace is not free. The namespace creator must *burn* |
|
||||
cryptocurrency to do so. The shorter the namespace, the more cryptocurrency |
|
||||
must be burned (i.e. short namespaces are more valuable than long namespaces). |
|
||||
For example, it cost Blockstack PBC 40 BTC to create the `.id` namespace in 2015 |
|
||||
(in transaction |
|
||||
`5f00b8e609821edd6f3369ee4ee86e03ea34b890e242236cdb66ef6c9c6a1b281`). |
|
||||
|
|
||||
Namespaces can be between 1 and 19 characters long, and are composed of the |
|
||||
characters `a-z`, `0-9`, `-`, and `_`. |
|
||||
|
|
||||
## Namespace Organization |
|
||||
|
|
||||
BNS names are organized into a global name hierarchy. There are three different |
|
||||
layers in this hierarchy related to naming: |
|
||||
|
|
||||
* **Namespaces**. These are the top-level names in the hierarchy. An analogy |
|
||||
to BNS namespaces are DNS top-level domains. Existing BNS namespaces include |
|
||||
`.id`, `.podcast`, and `.helloworld`. All other names belong to exactly one |
|
||||
namespace. Anyone can create a namespace, but in order for the namespace |
|
||||
to be persisted, it must be *launched* so that anyone can register names in it. |
|
||||
Namespaces are not owned by their creators. |
|
||||
|
|
||||
* **BNS names**. These are names whose records are stored directly on the |
|
||||
blockchain. The ownership and state of these names are controlled by sending |
|
||||
blockchain transactions. Example names include `verified.podcast` and |
|
||||
`muneeb.id`. Anyone can create a BNS name, as long as the namespace that |
|
||||
contains it exists already. The state for BNS names is usually stored in the [Atlas |
|
||||
network]({{ site.baseurl }}/core/atlas/overview.html). |
|
||||
|
|
||||
* **BNS subdomains**. These are names whose records are stored off-chain, |
|
||||
but are collectively anchored to the blockchain. The ownership and state for |
|
||||
these names lives within the [Atlas network]({{ site.baseurl }}/core/atlas/overview.html). While BNS |
|
||||
subdomains are owned by separate private keys, a BNS name owner must |
|
||||
broadcast their subdomain state. Example subdomains include `jude.personal.id` |
|
||||
and `podsaveamerica.verified.podcast`. Unlike BNS namespaces and names, the |
|
||||
state of BNS subdomains is *not* part of the blockchain consensus rules. |
|
||||
|
|
||||
A feature comparison matrix summarizing the similarities and differences |
|
||||
between these name objects is presented below: |
|
||||
|
|
||||
| Feature | **Namespaces** | **BNS names** | **BNS Subdomains** | |
|
||||
|---------|----------------|---------------|--------------------| |
|
||||
| Globally unique | X | X | X | |
|
||||
| Human-meaningful | X | X | X | |
|
||||
| Owned by a private key | | X | X | |
|
||||
| Anyone can create | X | X | [1] | |
|
||||
| Owner can update | | X | [1] | |
|
||||
| State hosted on-chain | X | X | | |
|
||||
| State hosted off-chain | | X | X | |
|
||||
| Behavior controlled by consensus rules | X | X | | |
|
||||
| May have an expiration date | | X | | |
|
||||
|
|
||||
[1] Requires the cooperation of a BNS name owner to broadcast its transactions |
|
||||
File diff suppressed because it is too large
@ -1,3 +0,0 @@ |
|||||
Documentation for setting up the regtest mode for Blockstack Browser |
|
||||
using core's integration tests in macOS and Linux has |
|
||||
moved [here](../integration_tests). |
|
||||
@ -1,604 +0,0 @@ |
|||||
--- |
|
||||
layout: core |
|
||||
permalink: /:collection/:path.html |
|
||||
--- |
|
||||
# Create and Launch a Namespace |
|
||||
{:.no_toc} |
|
||||
|
|
||||
This tutorial teaches you how to create your namespace, it contains the |
|
||||
following sections: |
|
||||
|
|
||||
* TOC |
|
||||
{:toc} |
|
||||
|
|
||||
|
|
||||
Creating namespaces is expensive. |
|
||||
Be sure to test your namespace in our [integration test |
|
||||
framework](https://github.com/blockstack/blockstack-core/tree/master/integration_tests) |
|
||||
first! It will let you simulate any valid namespace configuration |
|
||||
you want at no risk to you. |
|
||||
|
|
||||
|
|
||||
>**WARNING**: If you intend to create a namespace, you must read this document |
|
||||
_in its entirety_. You should also _install the test framework_ and experiment |
|
||||
with your namespace's parameters. _FAILURE TO DO SO MAY RESULT IN IRRECOVERABLE |
|
||||
LOSS OF FUNDS._ |
|
||||
|
|
||||
## Before you begin |
|
||||
|
|
||||
Some basic familiarity with how Bitcoin works is required to |
|
||||
understand this tutorial. This includes: |
|
||||
|
|
||||
* knowing the difference between mainnet, testnet, and regtest |
|
||||
* knowing about compressed and uncompressed ECDSA public keys |
|
||||
* knowing about base58-check encoding |
|
||||
* knowing how Bitcoin transactions are structured |
|
||||
* knowing how UTXOs work |
|
||||
|
|
||||
Creating a namespace is a three-step process. The first step is to `preorder` |
|
||||
the namespace, which broadcasts a salted hash of the namespace ID. The second |
|
||||
step is to `reveal` the namespace, which exposes the namespace ID and price |
|
||||
function to the blockchain. The final step is to `ready` the namespace, which |
|
||||
allows anyone to register names within it. |
|
||||
|
|
||||
In between the `reveal` and `ready` steps, the namespace creator will have a |
|
||||
"lock" on the namespace that lasts for about 1 year. During this time period, |
|
||||
the namespace creator can `import` names. The `import` transaction lets the |
|
||||
namespace creator assign the name a zone file and an owner in one step. |
|
||||
|
|
||||
## Before Trying This in Production... |
|
||||
|
|
||||
|
|
||||
|
|
||||
### Setting up the Test Environment |
|
||||
|
|
||||
In this example, we will use the test framework to create a private Bitcoin |
|
||||
blockchain on your computer, and then create a Blockstack namespace on it. |
|
||||
This will let you experiment with different namespace parameters |
|
||||
without spending actual BTC. The test framework uses `bitcoind -regtest`, |
|
||||
so all of the commands you'll run here will work identically on |
|
||||
mainnet. |
|
||||
|
|
||||
To install the test framework, please follow these |
|
||||
[instructions](https://github.com/blockstack/blockstack-core/tree/master/integration_tests). |
|
||||
Once you have the test framework installed, you should run the `namespace_check` test in `--interactive-web` mode. |
|
||||
This will create an empty `.test` namespace and leave the test scenario running |
|
||||
once it finishes. You will be able to fund addresses and create new blocks via |
|
||||
your Web browser or via `curl`, as will be explained below. Also, you'll be able to use the |
|
||||
`blockstack` utility to interact with your private blockchain and namespaces. |
|
||||
|
|
||||
The test setup command is as follows. This will launch the `namespace_check` |
|
||||
test scenario, and open a web server on port 3001. |
|
||||
```bash |
|
||||
$ blockstack-test-scenario --interactive-web 3001 blockstack_integration_tests.scenarios.namespace_check |
|
||||
``` |
|
||||
|
|
||||
When the test is ready for us to experiment, you should see the following: |
|
||||
|
|
||||
```bash |
|
||||
An empty namespace called 'test' has been created |
|
||||
Feel free to experiment with other namespaces |
|
||||
|
|
||||
Available keys with a balance: |
|
||||
* 6e50431b955fe73f079469b24f06480aee44e4519282686433195b3c4b5336ef01 |
|
||||
* c244642ce0b4eb68da8e098facfcad889e3063c36a68b7951fb4c085de49df1b01 |
|
||||
* f4c3907cb5769c28ff603c145db7fc39d7d26f69f726f8a7f995a40d3897bb5201 |
|
||||
* 8f87d1ea26d03259371675ea3bd31231b67c5df0012c205c154764a124f5b8fe01 |
|
||||
* bb68eda988e768132bc6c7ca73a87fb9b0918e9a38d3618b74099be25f7cab7d01 |
|
||||
* 2,3,6f432642c087c2d12749284d841b02421259c4e8178f25b91542c026ae6ced6d01,65268e6267b14eb52dc1ccc500dc2624a6e37d0a98280f3275413eacb1d2915d01,cdabc10f1ff3410082448b708c0f860a948197d55fb612cb328d7a5cc07a6c8a01 |
|
||||
* 2,3,4c3ab2a0704dfd9fdc319cff2c3629b72ebda1580316c7fddf9fad1baa323e9601,75c9f091aa4f0b1544a59e0fce274fb1ac29d7f7e1cd020b66f941e5d260617b01,d62af1329e541871b244c4a3c69459e8666c40b683ffdcb504aa4adc6a559a7701 |
|
||||
* 2,3,4b396393ca030b21bc44a5eba1bb557d04be1bfe974cbebc7a2c82b4bdfba14101,d81d4ef8123852403123d416b0b4fb25bcf9fa80e12aadbc08ffde8c8084a88001,d0482fbe39abd9d9d5c7b21bb5baadb4d50188b684218429f3171da9de206bb201 |
|
||||
* 2,3,836dc3ac46fbe2bcd379d36b977969e5b6ef4127e111f2d3e2e7fb6f0ff1612e01,1528cb864588a6a5d77eda548fe81efc44180982e180ecf4c812c6be9788c76a01,9955cfdac199b8451ccd63ec5377a93df852dc97ea01afc47db7f870a402ff0501 |
|
||||
``` |
|
||||
|
|
||||
You can determine that the test framework is live by going to |
|
||||
`http://localhost:3001` in your Web browser. From there, you can generate |
|
||||
blocks in the test framework's `bitcoind` node and you can fund any address in |
|
||||
the test framework. |
|
||||
|
|
||||
Finally, you can use the `blockstack-test-env` command to set up your shell |
|
||||
environment variables so `blockstack` will interact with this test (instead of |
|
||||
mainnet). To do so, run the following in your shell: |
|
||||
|
|
||||
```bash |
|
||||
$ . $(which blockstack-test-env) namespace_check |
|
||||
|blockstack-test namespace_check| $ |
|
||||
``` |
|
||||
|
|
||||
You can verify that the environment variables by verifying that your `$PS1` |
|
||||
variable includes the name of your test (as shown above), and that some other |
|
||||
`BLOCKSTACK_`-prefixed variables are set: |
|
||||
|
|
||||
```bash |
|
||||
|blockstack-test namespace_check| $ env | grep BLOCKSTACK |
|
||||
BLOCKSTACK_OLD_PS1=\u@\h:\w$ |
|
||||
BLOCKSTACK_TESTNET=1 |
|
||||
BLOCKSTACK_EPOCH_1_END_BLOCK=1 |
|
||||
BLOCKSTACK_EPOCH_2_END_BLOCK=2 |
|
||||
BLOCKSTACK_TEST=1 |
|
||||
BLOCKSTACK_DEBUG=1 |
|
||||
BLOCKSTACK_CLIENT_CONFIG=/tmp/blockstack-run-scenario.blockstack_integration_tests.scenarios.namespace_check/client/client.ini |
|
||||
``` |
|
||||
|
|
||||
## Registering a Namespace |
|
||||
|
|
||||
Suppose we're going to create the `hello` namespace. The key |
|
||||
`6e50431b955fe73f079469b24f06480aee44e4519282686433195b3c4b5336ef01` will be the key that |
|
||||
*pays* for the namespace. The key |
|
||||
`c244642ce0b4eb68da8e098facfcad889e3063c36a68b7951fb4c085de49df1b01` will be the key that |
|
||||
*creates* the namespace. The creator key will be used to `import` names and |
|
||||
declare the namespace `ready`. The payment key will be used to both pay for the |
|
||||
namespace and receive name registration and renewal fees for the first year of |
|
||||
the namespace's lifetime. |
|
||||
|
|
||||
In this example, we will set these keys as environment variables: |
|
||||
|
|
||||
```bash |
|
||||
|blockstack-test namespace_check| $ export PAYMENT_PKEY="6e50431b955fe73f079469b24f06480aee44e4519282686433195b3c4b5336ef01" |
|
||||
|blockstack-test namespace_check| $ export CREATOR_PKEY="c244642ce0b4eb68da8e098facfcad889e3063c36a68b7951fb4c085de49df1b01" |
|
||||
``` |
|
||||
|
|
||||
#### Multisig Namespace Payment |
|
||||
|
|
||||
If you want to use a multisig address to pay for your namespace (and collect |
|
||||
name registration fees), then instead of using |
|
||||
`6e50431b955fe73f079469b24f06480aee44e4519282686433195b3c4b5336ef01`, you should |
|
||||
use a string formatted as `m,n,pk1,pk2,...,pk_n`. `m` is the number of |
|
||||
signatures required, `n` is the number of private keys, and `pk1,pk2,...,pk_n` |
|
||||
are the private keys. |
|
||||
|
|
||||
For example, you can use the following as your `PAYMENT_PKEY` to have a 2-of-3 |
|
||||
multisig script pay for your namespace and collect name registration fees: |
|
||||
|
|
||||
```bash |
|
||||
|blockstack-test namespace_check| $ export PAYMENT_PKEY="2,3,6f432642c087c2d12749284d841b02421259c4e8178f25b91542c026ae6ced6d01,65268e6267b14eb52dc1ccc500dc2624a6e37d0a98280f3275413eacb1d2915d01,cdabc10f1ff3410082448b708c0f860a948197d55fb612cb328d7a5cc07a6c8a01" |
|
||||
``` |
|
||||
|
|
||||
### Namespace preorder |
|
||||
|
|
||||
The command to preorder the namespace would be: |
|
||||
|
|
||||
```bash |
|
||||
|blockstack-test namespace_check| $ blockstack namespace_preorder hello "$PAYMENT_PKEY" "$CREATOR_PKEY" |
|
||||
``` |
|
||||
|
|
||||
You will be given a set of instructions on how to proceed to reveal and |
|
||||
launch the namespace. _READ THEM CAREFULLY_. You will be prompted to |
|
||||
explicitly acknowledge that you understand the main points of the instructions, |
|
||||
and that you understand the risks. |
|
||||
|
|
||||
The command outputs some necessary information at the very end of its execution. |
|
||||
In particular, you will need to remember the transaction ID of the namespace |
|
||||
preorder. The command will help you do so. |
|
||||
|
|
||||
Here is a sample output: |
|
||||
|
|
||||
```bash |
|
||||
|blockstack-test namespace_check| $ blockstack namespace_preorder hello "$PAYMENT_PKEY" "$CREATOR_PKEY" |
|
||||
|
|
||||
<...snip...> |
|
||||
|
|
||||
Remember this transaction ID: b40dd1375ef63e5a40ee60d790ec6dccd06efcbac99d0cd5f3b07502a4ab05ac |
|
||||
You will need it for `blockstack namespace_reveal` |
|
||||
|
|
||||
Wait until b40dd1375ef63e5a40ee60d790ec6dccd06efcbac99d0cd5f3b07502a4ab05ac has six (6) confirmations. Then, you can reveal `hello` with: |
|
||||
|
|
||||
$ blockstack namespace_reveal "hello" "6e50431b955fe73f079469b24f06480aee44e4519282686433195b3c4b5336ef01" "c244642ce0b4eb68da8e098facfcad889e3063c36a68b7951fb4c085de49df1b01" "b40dd1375ef63e5a40ee60d790ec6dccd06efcbac99d0cd5f3b07502a4ab05ac" |
|
||||
|
|
||||
{ |
|
||||
"status": true, |
|
||||
"success": true, |
|
||||
"transaction_hash": "b40dd1375ef63e5a40ee60d790ec6dccd06efcbac99d0cd5f3b07502a4ab05ac" |
|
||||
} |
|
||||
``` |
|
||||
|
|
||||
If all goes well, you will get back a transaction hash (in this case, `b40dd1375ef63e5a40ee60d790ec6dccd06efcbac99d0cd5f3b07502a4ab05ac`). |
|
||||
To get Blockstack to process it, you will need to mine some blocks in the test framework (by default, |
|
||||
Blockstack will only accept a transaction that has 6 confirmations). To do |
|
||||
this, simply go to `http://localhost:3001` and generate at least 6 blocks. If you |
|
||||
observe the test log, you will see the Blockstack node process and accept it. |
|
||||
|
|
||||
Note that when you do this live, you should wait for |
|
||||
at least 10 confirmations before sending the `reveal` transaction, just to be |
|
||||
safe. |
|
||||
|
|
||||
### Namespace reveal |
|
||||
|
|
||||
The command to reveal a preordered namespace is more complicated, since it |
|
||||
describes the price curve. |
|
||||
|
|
||||
This command is **interactive**. The command to invoke it is as follows: |
|
||||
|
|
||||
```bash |
|
||||
|blockstack-test namespace_check| $ blockstack namespace_reveal hello "$PAYMENT_PKEY" "$CREATOR_PKEY" "b40dd1375ef63e5a40ee60d790ec6dccd06efcbac99d0cd5f3b07502a4ab05ac" |
|
||||
``` |
|
||||
|
|
||||
When running the command, you will see the namespace creation wizard prompt you |
|
||||
with the price curve and the current values: |
|
||||
|
|
||||
``` |
|
||||
Name lifetimes (blocks): infinite |
|
||||
Price coefficient: 4 |
|
||||
Price base: 4 |
|
||||
Price bucket exponents: [15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0] |
|
||||
Non-alpha discount: 2 |
|
||||
No-vowel discount: 5 |
|
||||
Burn or receive fees? Receive to mr6nrMvvh44sR5MiX929mMXP5hqgaTr6fx |
|
||||
|
|
||||
Name price formula: |
|
||||
(UNIT_COST = 10.0 satoshi): |
|
||||
buckets[min(len(name)-1, 15)] |
|
||||
UNIT_COST * coeff * base |
|
||||
cost(name) = ----------------------------------------------------- |
|
||||
max(nonalpha_discount, no_vowel_discount) |
|
||||
|
|
||||
|
|
||||
Name price table: |
|
||||
| length | price | price, nonalpha | price, no vowel | price, both | |
|
||||
-------------------------------------------------------------------------- |
|
||||
| 1 | 42949672960 | 8589934592 | 8589934592 | 8589934592 | |
|
||||
| 2 | 10737418240 | 5368709120 | 2147483648 | 2147483648 | |
|
||||
| 3 | 2684354560 | 1342177280 | 536870912 | 536870912 | |
|
||||
| 4 | 671088640 | 335544320 | 134217728 | 134217728 | |
|
||||
| 5 | 167772160 | 83886080 | 33554432 | 33554432 | |
|
||||
| 6 | 41943040 | 20971520 | 8388608 | 8388608 | |
|
||||
| 7 | 10485760 | 5242880 | 2097152 | 2097152 | |
|
||||
| 8 | 2621440 | 1310720 | 524288 | 524288 | |
|
||||
| 9 | 655360 | 327680 | 131072 | 131072 | |
|
||||
| 10 | 163840 | 81920 | 32768 | 32768 | |
|
||||
| 11 | 40960 | 20480 | 8192 | 8192 | |
|
||||
| 12 | 10240 | 5120 | 2048 | 2048 | |
|
||||
| 13 | 2560 | 1280 | 512 | 512 | |
|
||||
| 14 | 640 | 320 | 128 | 128 | |
|
||||
| 15 | 160 | 80 | 32 | 32 | |
|
||||
| 16+ | 40 | 20 | 10 | 10 | |
|
||||
|
|
||||
|
|
||||
What would you like to do? |
|
||||
(0) Set name lifetime in blocks (positive integer between 1 and 4294967295, or "infinite") |
|
||||
(1) Set price coefficient (positive integer between 1 and 255) |
|
||||
(2) Set base price (positive integer between 1 and 255) |
|
||||
(3) Set price bucket exponents (16 comma-separated integers, each between 1 and 15) |
|
||||
(4) Set non-alphanumeric character discount (positive integer between 1 and 15) |
|
||||
(5) Set no-vowel discount (positive integer between 1 and 15) |
|
||||
(6) Toggle collecting name fees (True: receive fees; False: burn fees) |
|
||||
(7) Show name price formula |
|
||||
(8) Show price table |
|
||||
(9) Done |
|
||||
|
|
||||
(1-9) |
|
||||
``` |
|
||||
|
|
||||
All prices are in the "fundamental unit" of the underlying blockchain (i.e. |
|
||||
satoshis). |
|
||||
|
|
||||
As the formula describes, the name's price is a function of: |
|
||||
|
|
||||
* a fixed unit cost (`UNIT_COST`) |
|
||||
* a multiplicative constant coefficient (`coeff`) |
|
||||
* a fixed exponential base (`base`) |
|
||||
* a 16-element list of price buckets, indexed by the length of the name (`buckets`) |
|
||||
* a discount for having non-alphnumeric letters (`nonalpha_discount`) |
|
||||
* a discount for having no vowels in the name (`no_vowel_discount`) |
|
||||
|
|
||||
You can use options 1 through 8 to play with the pricing function and examine |
|
||||
the name costs in the price table. Enter 9 to send the transaction itself. |
|
||||
|
|
||||
Once you're happy, you can issue the namespace-reveal transaction. As with the |
|
||||
namespace-preorder transaction, you will get back a transaction hash, and your transaction will be |
|
||||
unconfirmed. Simply go to `http://localhost:3001` to generate some more blocks |
|
||||
to confirm your namespace-reveal. |
|
||||
|
|
||||
Once you have confirmed your namespace-reveal transaction, you can |
|
||||
begin to populate your namespace with some initial names. |
|
||||
|
|
||||
**Collecting Name Fees** |
|
||||
|
|
||||
Blockstack 0.17 introduced the ability to create a namespace such that for the |
|
||||
first year of its existence (54595 blocks), all name registration and renewal |
|
||||
fees will be sent to the address of the _payment key_. In this example, |
|
||||
this is the address `mr6nrMvvh44sR5MiX929mMXP5hqgaTr6fx`. |
|
||||
|
|
||||
The alternative is to |
|
||||
have all namespace fees sent to an unspendable burn address |
|
||||
(`1111111111111111111114oLvT2`). This is the case for the `.id` namespace, |
|
||||
for example. |
|
||||
|
|
||||
After the year has passed, all future name registrations and renewal fees |
|
||||
will be sent to the unspendable burn address. This is to disincentivize |
|
||||
namespace squatters. |
|
||||
|
|
||||
**Warnings** |
|
||||
|
|
||||
* You must issue this command **within 144 blocks** of the namespace-preorder transaction. Otherwise, the preorder will expire and you will need to start over from scratch. |
|
||||
|
|
||||
### Importing names |
|
||||
|
|
||||
After sending the `reveal` transaction, you can populate your namespace with |
|
||||
some initial names. You can do so with the `name_import` command. |
|
||||
|
|
||||
Suppose we want to import the name `example.hello` and assign it to an owner |
|
||||
whose public key address is `ms6Y32bcL5zhA57e8tf7awgVZuPxV8Xg8N`. Suppose also |
|
||||
that you wanted to give `example.hello` an initial zone file stored at |
|
||||
`/var/blockstack/zone_files/example.hello`. To do so, you would issue the |
|
||||
following command: |
|
||||
|
|
||||
```bash |
|
||||
|blockstack-test namespace_check| $ blockstack name_import example.hello ms6Y32bcL5zhA57e8tf7awgVZuPxV8Xg8N /var/blockstack/zone_files/example.hello "$CREATOR_PKEY" |
|
||||
``` |
|
||||
|
|
||||
By default, you **must** use the private key you used to reveal the namespace |
|
||||
to import names (this is `$CREATOR_PKEY` in this example). |
|
||||
|
|
||||
As with namespace-preorder and namespace-reveal, the transaction this command |
|
||||
generates will be unconfirmed. Simply go to `http://localhost:3001` to generate |
|
||||
some blocks to confirm it. |
|
||||
|
|
||||
You can check the progress of the transaction with `blockstack info`, as follows: |
|
||||
|
|
||||
```bash |
|
||||
|blockstack-test namespace_check| $ blockstack info |
|
||||
{ |
|
||||
"cli_version": "0.17.0.8", |
|
||||
"consensus_hash": "b10fdd38a20a7e46555ce3a7f68cf95c", |
|
||||
"last_block_processed": 694, |
|
||||
"last_block_seen": 694, |
|
||||
"queues": { |
|
||||
"name_import": [ |
|
||||
{ |
|
||||
"confirmations": 1, |
|
||||
"name": "example.hello", |
|
||||
"tx_hash": "10f7dcd9d6963ef5d20d010f731d5d2ddb76163a083b9d7a2b9fd4515c7fe58c" |
|
||||
} |
|
||||
] |
|
||||
}, |
|
||||
"server_alive": true, |
|
||||
"server_host": "localhost", |
|
||||
"server_port": 16264, |
|
||||
"server_version": "0.17.0.8" |
|
||||
} |
|
||||
``` |
|
||||
|
|
||||
The `confirmation` field indicates how deep in the blockchain the transaction is |
|
||||
at the time. Generating more blocks will increase its number of confirmations. |
|
||||
|
|
||||
When you do this live, |
|
||||
**YOU SHOULD LEAVE YOUR COMPUTER RUNNING UNTIL THE `name_import` QUEUE IS EMPTY**. |
|
||||
Blockstack's background API daemon will monitor the transactions and upload the |
|
||||
name's zone file to the Blockstack Atlas network once it is confirmed. |
|
||||
But to do so, your computer must remain online. If you do not do this, then |
|
||||
the name will not have a zone file and will be unusable in the higher layers of |
|
||||
Blockstack-powered software (including Blockstack applications). However, |
|
||||
if your computer does go offline or reboots, you can recover by |
|
||||
restarting the Blockstack API daemon (with |
|
||||
`blockstack api start`). The daemon itself will pick up where it left off, and |
|
||||
replicate all zone files that have confirmed transactions. |
|
||||
|
|
||||
After the zone file is uploaded, the name will be public and resolvable. You can re-import the |
|
||||
same name over and over, and give it a different address and/or zone file. Like |
|
||||
all other names, the Blockstack Atlas network will accept and propagate zone |
|
||||
files for imported names. |
|
||||
|
|
||||
The owner of the address `ms6Y32bcL5zhA57e8tf7awgVZuPxV8Xg8N` will **not** be |
|
||||
able to issue any transactions for the name `example.hello` until the namespace |
|
||||
creator has sent the `ready` transaction. |
|
||||
|
|
||||
#### Using multiple private keys for NAME_IMPORT |
|
||||
|
|
||||
Bitcoin itself imposes limits on how fast you can send transactions from the |
|
||||
same key (limited by a maximum UTXO-chain length). To work around this, |
|
||||
Blockstack lets you import names by using up to 300 private keys. The private |
|
||||
keys you can use are BIP32 unhardened children of the namespace reveal key (i.e. |
|
||||
`$CREATOR_PKEY` in this example). |
|
||||
|
|
||||
The first name you import **must** use the namespace reveal private key |
|
||||
(`$CREATOR_PKEY` in this example). However, all future names you import in this |
|
||||
namespace can use one of the 300 BIP32 keys. |
|
||||
|
|
||||
To get the list of keys you can use, you can use the `make_import_keys` command: |
|
||||
|
|
||||
```bash |
|
||||
|blockstack-test namespace_check| $ blockstack make_import_keys example hello "$CREATOR_PKEY" |
|
||||
aeda50305ada40aaf53f2d8921aa717f1ec71a0a3b9b4c6397b3877f6d45c46501 (n4DVTuLLv5J1Yc17AoRYY1GtxDAuLGAESr) |
|
||||
92ff179901819a1ec7d32997ce3bb0d9a913895d5850cc05146722847128549201 (mib2KNBGR4az8GiUmusBZexVBqb9YB2gm5) |
|
||||
cc5b6a454e2b614bfa18f4deb9a8e179ab985634d63b7fedfaa59573472d209b01 (mxE2iqV4jdpn4K349Gy424TvZp6MPqSXve) |
|
||||
9b0265e0ac8c3c24fe1d79a734b3661ec2b5c0c2619bb6342356572b8235910101 (n4rGz8hkXTscUGWCwZvahrkEh6LHZVQUoa) |
|
||||
e2585af250404b7918cf6c91c6fa67f3401c0d1ae66df2fafa8fa132f4b9350f01 (moGNpEpighqc6FnkqyNVJA9xtfTiStr5YU) |
|
||||
{ |
|
||||
"status": true |
|
||||
} |
|
||||
``` |
|
||||
|
|
||||
(NOTE: in the test environment, you get only 5 keys in order to save time). |
|
||||
|
|
||||
You can use any of these keys to import names. |
|
||||
|
|
||||
#### Trying it out |
|
||||
|
|
||||
Here's an example walkthrough of how to try this out in the test framework: |
|
||||
|
|
||||
1. Import the first name, creating a zone file in the process: |
|
||||
|
|
||||
```bash |
|
||||
|blockstack-test namespace_check| $ cat > /var/blockstack/zone_files/example.hello <<EOF |
|
||||
> $ORIGIN example.hello |
|
||||
> $TTL 3600 |
|
||||
> _file URI 10 1 "file:///home/blockstack-test/example.hello" |
|
||||
> EOF |
|
||||
|blockstack-test namespace_check| $ blockstack name_import example.hello ms6Y32bcL5zhA57e8tf7awgVZuPxV8Xg8N /var/blockstack/zone_files/example.hello "$CREATOR_PKEY" |
|
||||
Import cost breakdown: |
|
||||
{ |
|
||||
"name_import_tx_fee": { |
|
||||
"btc": 0.0003342, |
|
||||
"satoshis": 33420 |
|
||||
}, |
|
||||
"total_estimated_cost": { |
|
||||
"btc": 0.0003342, |
|
||||
"satoshis": 33420 |
|
||||
}, |
|
||||
"total_tx_fees": 33420 |
|
||||
} |
|
||||
Importing name 'example.hello' to be owned by 'ms6Y32bcL5zhA57e8tf7awgVZuPxV8Xg8N' with zone file hash '05c302430f4ed0a24470abf9df7e264d517fd389' |
|
||||
Proceed? (y/N) y |
|
||||
{ |
|
||||
"status": true, |
|
||||
"success": true, |
|
||||
"transaction_hash": "bd875f00f63bcb718bb22782c88c3edcbed79663f2f9152deab328c48746f103", |
|
||||
"value_hash": "05c302430f4ed0a24470abf9df7e264d517fd389" |
|
||||
} |
|
||||
``` |
|
||||
|
|
||||
2. Advance the test framework blockchain, so the indexer knows which import keys to expect: |
|
||||
|
|
||||
```bash |
|
||||
# NOTE: you can also do this by going to http://localhost:3001 in your Web browser |
|
||||
|blockstack-test namespace_check| $ curl -X POST http://localhost:3001/nextblock |
|
||||
``` |
|
||||
|
|
||||
3. Make import keys: |
|
||||
|
|
||||
```bash |
|
||||
|blockstack-test namespace_check| $ blocksatck make_import_keys hello "$CREATOR_PKEY" |
|
||||
aeda50305ada40aaf53f2d8921aa717f1ec71a0a3b9b4c6397b3877f6d45c46501 (n4DVTuLLv5J1Yc17AoRYY1GtxDAuLGAESr) |
|
||||
92ff179901819a1ec7d32997ce3bb0d9a913895d5850cc05146722847128549201 (mib2KNBGR4az8GiUmusBZexVBqb9YB2gm5) |
|
||||
cc5b6a454e2b614bfa18f4deb9a8e179ab985634d63b7fedfaa59573472d209b01 (mxE2iqV4jdpn4K349Gy424TvZp6MPqSXve) |
|
||||
9b0265e0ac8c3c24fe1d79a734b3661ec2b5c0c2619bb6342356572b8235910101 (n4rGz8hkXTscUGWCwZvahrkEh6LHZVQUoa) |
|
||||
e2585af250404b7918cf6c91c6fa67f3401c0d1ae66df2fafa8fa132f4b9350f01 (moGNpEpighqc6FnkqyNVJA9xtfTiStr5YU) |
|
||||
{ |
|
||||
"status": true |
|
||||
} |
|
||||
``` |
|
||||
|
|
||||
4. Fill up one of the addresses in the test framework, so we can fund `NAME_IMPORT` transactions with it: |
|
||||
|
|
||||
```bash |
|
||||
# NOTE: you can also do this by going to http://localhost:3001 in your Web browser |
|
||||
|blockstack-test namespace_check| $ curl -X POST -F 'addr=n4DVTuLLv5J1Yc17AoRYY1GtxDAuLGAESr' -F 'value=100000000' 'http://localhost:3001/sendfunds' |
|
||||
``` |
|
||||
|
|
||||
5. Import another name, with the child private key we just funded: |
|
||||
|
|
||||
```bash |
|
||||
|blockstack-test namespace_check| $ cat > /tmp/example.hello.zonefile <<EOF |
|
||||
> $ORIGIN example2.hello |
|
||||
> $TTL 3600 |
|
||||
> _file URI 10 1 "file:///home/blockstack-test/example2.hello" |
|
||||
> EOF |
|
||||
|blockstack-test namespace_check| $ blockstack name_import example2.hello n3sFkNfBQPWS25G12DqDEqHRPiqHotAkEb /tmp/example.hello.zonefile aeda50305ada40aaf53f2d8921aa717f1ec71a0a3b9b4c6397b3877f6d45c46501 |
|
||||
Import cost breakdown: |
|
||||
{ |
|
||||
"name_import_tx_fee": { |
|
||||
"btc": 0.0003342, |
|
||||
"satoshis": 33420 |
|
||||
}, |
|
||||
"total_estimated_cost": { |
|
||||
"btc": 0.0003342, |
|
||||
"satoshis": 33420 |
|
||||
}, |
|
||||
"total_tx_fees": 33420 |
|
||||
} |
|
||||
Importing name 'example2.hello' to be owned by 'n3sFkNfBQPWS25G12DqDEqHRPiqHotAkEb' with zone file hash '0649bc0b457f54c564d054ce20dc3745a0c4f0c0' |
|
||||
Proceed? (y/N) y |
|
||||
{ |
|
||||
"status": true, |
|
||||
"success": true, |
|
||||
"transaction_hash": "496a6c2aaccedd98a8403c2e61ff3bdeff221a58bf0e9c362fcae981353f459f", |
|
||||
"value_hash": "0649bc0b457f54c564d054ce20dc3745a0c4f0c0" |
|
||||
} |
|
||||
``` |
|
||||
|
|
||||
6. Advance the blockchain again: |
|
||||
|
|
||||
```bash |
|
||||
# NOTE: you can also do this by going to http://localhost:3001 in your Web browser |
|
||||
|blockstack-test namespace_check| $ curl -X POST http://localhost:3001/nextblock |
|
||||
``` |
|
||||
|
|
||||
7. See that the names are processing: |
|
||||
|
|
||||
```bash |
|
||||
|blockstack-test namespace_check| $ blockstack info |
|
||||
{ |
|
||||
"cli_version": "0.17.0.8", |
|
||||
"consensus_hash": "2a055beeaedcaa1365ab2671a0254a03", |
|
||||
"last_block_processed": 711, |
|
||||
"last_block_seen": 711, |
|
||||
"queues": { |
|
||||
"name_import": [ |
|
||||
{ |
|
||||
"confirmations": 2, |
|
||||
"name": "example.hello", |
|
||||
"tx_hash": "bd875f00f63bcb718bb22782c88c3edcbed79663f2f9152deab328c48746f103", |
|
||||
}, |
|
||||
{ |
|
||||
"confirmations": 1, |
|
||||
"name": "example2.hello", |
|
||||
"tx_hash": "496a6c2aaccedd98a8403c2e61ff3bdeff221a58bf0e9c362fcae981353f459f" |
|
||||
} |
|
||||
] |
|
||||
}, |
|
||||
"server_alive": true, |
|
||||
"server_host": "localhost", |
|
||||
"server_port": 16264, |
|
||||
"server_version": "0.17.0.8" |
|
||||
} |
|
||||
``` |
|
||||
|
|
||||
8. Confirm all the transactions: |
|
||||
|
|
||||
```bash |
|
||||
# NOTE: you can also do this by going to http://localhost:3001 in your Web browser |
|
||||
|blockstack-test namespace_check| $ for i in $(seq 1 10); do curl -X POST http://localhost:3001/nextblock |
|
||||
``` |
|
||||
|
|
||||
9. Look up name zone files to confirm they were replicated to the test framework's Atlas network: |
|
||||
|
|
||||
```bash |
|
||||
|blockstack-test namespace_check| $ blockstack info |
|
||||
{ |
|
||||
"cli_version": "0.17.0.8", |
|
||||
"consensus_hash": "ad247c1d5ff239a65db0736951078f17", |
|
||||
"last_block_processed": 721, |
|
||||
"last_block_seen": 721, |
|
||||
"queues": {}, |
|
||||
"server_alive": true, |
|
||||
"server_host": "localhost", |
|
||||
"server_port": 16264, |
|
||||
"server_version": "0.17.0.8" |
|
||||
} |
|
||||
|blockstack-test namespace_check| $ blockstack get_name_zonefile example.hello |
|
||||
$ORIGIN example.hello |
|
||||
$TTL 3600 |
|
||||
_file URI 10 1 "file:///home/blockstack-test/example.hello" |
|
||||
|
|
||||
|blockstack-test namespace_check| $ blockstack get_name_zonefile example2.hello |
|
||||
$ORIGIN example2.hello |
|
||||
$TTL 3600 |
|
||||
_file URI 10 1 "file:///home/blockstack-test/example2.hello" |
|
||||
``` |
|
||||
|
|
||||
Now, these names are imported and once the `NAMESPACE_READY` transaction is |
|
||||
sent, the name owners can proceed to issue name operations. |
|
||||
|
|
||||
**Warnings** |
|
||||
|
|
||||
* The first private key you use must be the same one you used to *create* the namespace (`$CREATOR_KEY`). |
|
||||
* You may only use the 300 private keys described above to import names. |
|
||||
* You must complete all `NAME_IMPORT` transactions within 52595 blocks of the `NAMESPACE_REVEAL` transaction (about 1 year). |
|
||||
|
|
||||
### Launching a Namespace |
|
||||
|
|
||||
Once you have pre-populated your namespace with all of the initial names, you |
|
||||
have to make it `ready` so anyone can register a name. If you do not do this |
|
||||
within 1 year of the `reveal` transaction, then your namespace and all of the |
|
||||
names will disappear, and someone else will be able to register it. |
|
||||
|
|
||||
To make a namespace `ready`, you use the creator private key as follows: |
|
||||
|
|
||||
```bash |
|
||||
|blockstack-test namespace_check| $ blockstack namespace_ready hello "$CREATOR_PKEY" |
|
||||
``` |
|
||||
|
|
||||
**Warnings** |
|
||||
|
|
||||
* You must send the `NAMESPACE_READY` transaction within 52595 blocks (about 1 year) of the `NAMESPACE_REVEAL` transaction. |
|
||||
@ -1,158 +0,0 @@ |
|||||
--- |
|
||||
layout: core |
|
||||
permalink: /:collection/:path.html |
|
||||
--- |
|
||||
# Choose a name |
|
||||
{:.no_toc} |
|
||||
|
|
||||
This section explains how to choose and create a namespace, it contains the |
|
||||
following sections: |
|
||||
|
|
||||
* TOC |
|
||||
{:toc} |
|
||||
|
|
||||
## Intended uses for a namespace |
|
||||
|
|
||||
The intention is that each application can create its own BNS |
|
||||
namespace for its own purposes. Applications can use namespaces for things like: |
|
||||
|
|
||||
* Giving users a SSO system, where each user registers their public key under a |
|
||||
username. Blockstack applications do this with names in the `.id` namespace, |
|
||||
for example. |
|
||||
* Providing a subscription service, where each name is a 3rd party that provides |
|
||||
a service for users to subscribe to. For example, names in |
|
||||
`.podcast` point to podcasts that users of the |
|
||||
[DotPodcast](https://dotpodcast.co) app can subscribe to. |
|
||||
* Implementing software licenses, where each name corresponds to an access key. |
|
||||
Unlike conventional access keys, access keys implemented as names |
|
||||
can be sold and traded independently. The licensing fee (paid as a name |
|
||||
registration) would be set by the developer and sent to a developer-controlled |
|
||||
blockchain address. |
|
||||
|
|
||||
Names within a namespace can serve any purpose the developer wants. The ability |
|
||||
to collect registration fees for 1 year after creating the namespace not only |
|
||||
gives developers the incentive to get users to participate in the app, but also |
|
||||
gives them a way to measure economic activity. |
|
||||
|
|
||||
Developers can query individual namespaces and look up names within them using |
|
||||
the BNS API. |
|
||||
|
|
||||
## List all namespaces in existence ([reference](https://core.blockstack.org/#namespace-operations-get-all-namespaces)). |
|
||||
|
|
||||
```bash |
|
||||
$ curl https://core.blockstack.org/v1/namespaces |
|
||||
[ |
|
||||
"id", |
|
||||
"helloworld", |
|
||||
"podcast" |
|
||||
] |
|
||||
``` |
|
||||
|
|
||||
## List all names within a namespace ([reference](https://core.blockstack.org/#namespace-operations-get-all-namespaces)) |
|
||||
|
|
||||
```bash |
|
||||
$ curl https://core.blockstack.org/v1/namespaces/id/names?page=0 |
|
||||
[ |
|
||||
"0.id", |
|
||||
"0000.id", |
|
||||
"000000.id", |
|
||||
"000001.id", |
|
||||
"00000111111.id", |
|
||||
"000002.id", |
|
||||
"000007.id", |
|
||||
"0011sro.id", |
|
||||
"007_007.id", |
|
||||
"00n3w5.id", |
|
||||
"00r4zr.id", |
|
||||
"00w1k1.id", |
|
||||
"0101010.id", |
|
||||
"01jack.id", |
|
||||
"06nenglish.id", |
|
||||
"08.id", |
|
||||
"0cool_f.id", |
|
||||
"0dadj1an.id", |
|
||||
"0nelove.id", |
|
||||
"0nename.id" |
|
||||
... |
|
||||
] |
|
||||
``` |
|
||||
|
|
||||
Each page returns a batch of 100 names. |
|
||||
|
|
||||
## Get the Cost to Register a Namespace ([reference](https://core.blockstack.org/#price-checks-get-namespace-price)) |
|
||||
|
|
||||
```bash |
|
||||
$ curl https://core.blockstack.org/v1/prices/namespaces/test |
|
||||
{ |
|
||||
"satoshis": 40000000 |
|
||||
} |
|
||||
``` |
|
||||
|
|
||||
If you want to register a namespace, please see the [namespace creation section]({{ site.baseurl }}/core/naming/namespace.html). |
|
||||
|
|
||||
## Getting the Current Consensus Hash ([reference](https://core.blockstack.org/#blockchain-operations-get-consensus-hash)) |
|
||||
|
|
||||
```bash |
|
||||
$ curl -sL https://core.blockstack.org/v1/blockchains/bitcoin/consensus |
|
||||
{ |
|
||||
"consensus_hash": "98adf31989bd937576aa190cc9f5fa3a" |
|
||||
} |
|
||||
``` |
|
||||
|
|
||||
A recent consensus hash is required to create a `NAMESPACE_PREORDER` transaction. The reference |
|
||||
BNS clients do this automatically. See the [transaction format]({{ site.baseurl }}/core/wire-format.html) |
|
||||
document for details on how the consensus hash is used to construct the |
|
||||
transaction. |
|
||||
|
|
||||
## Create a namespace |
|
||||
|
|
||||
There are four steps to creating a namespace: |
|
||||
|
|
||||
1. **Send a `NAMESPACE_PREORDER` transaction** ([live example](https://www.blocktrail.com/BTC/tx/5f00b8e609821edd6f3369ee4ee86e03ea34b890e242236cdb66ef6c9c6a1b28)). |
|
||||
This is the first step. This registers the *salted hash* of the namespace with BNS nodes, and burns the |
|
||||
requisite amount of cryptocurrency. In addition, it proves to the |
|
||||
BNS nodes that user has honored the BNS consensus rules by including |
|
||||
a recent *consensus hash* in the transaction |
|
||||
(see the section on [BNS forks](#bns-forks) for details). |
|
||||
|
|
||||
2. **Send a `NAMESPACE_REVEAL` transaction** ([live example](https://www.blocktrail.com/BTC/tx/ab54b1c1dd5332dc86b24ca2f88b8ca0068485edf0c322416d104c5b84133a32)). |
|
||||
This is the second step. This reveals the salt and the namespace ID (pairing it with its |
|
||||
`NAMESPACE_PREORDER`), it reveals how long names last in this namespace before |
|
||||
they expire or must be renewed, and it sets a *price function* for the namespace |
|
||||
that determines how cheap or expensive names its will be. The price function takes |
|
||||
a name in this namespace as input, and outputs the amount of cryptocurrency the |
|
||||
name will cost (i.e. by examining how long the name is, and whether or not it |
|
||||
has any vowels or non-alphabet characters). The namespace creator |
|
||||
has the option to collect name registration fees for the first year of the |
|
||||
namespace's existence by setting a *namespace creator address*. |
|
||||
|
|
||||
3. **Seed the namespace with `NAME_IMPORT` transactions** ([live example](https://www.blocktrail.com/BTC/tx/c698ac4b4a61c90b2c93dababde867dea359f971e2efcf415c37c9a4d9c4f312)). |
|
||||
Once the namespace has been revealed, the user has the option to populate it with a set of |
|
||||
names. Each imported name is given both an owner and some off-chain state. |
|
||||
This step is optional---namespace creators are not required to import names. |
|
||||
|
|
||||
4. **Send a `NAMESPACE_READY` transaction** ([live example](https://www.blocktrail.com/BTC/tx/2bf9a97e3081886f96c4def36d99a677059fafdbd6bdb6d626c0608a1e286032)). |
|
||||
This is the final step of the process. It *launches* the namespace, which makes it available to the |
|
||||
public. Once a namespace is ready, anyone can register a name in it if they |
|
||||
pay the appropriate amount of cryptocurrency (according to the price funtion |
|
||||
revealed in step 2). |
|
||||
|
|
||||
The reason for the `NAMESPACE_PREORDER/NAMESPACE_REVEAL` pairing is to prevent |
|
||||
frontrunning. The BNS consensus rules require a `NAMESPACE_REVEAL` to be |
|
||||
paired with a previous `NAMESPACE_PREORDER` sent within the past 24 hours. |
|
||||
If it did not do this, then a malicious actor could watch the blockchain network |
|
||||
and race a victim to claim a namespace. |
|
||||
|
|
||||
Namespaces are created on a first-come first-serve basis. If two people try to |
|
||||
create the same namespace, the one that successfully confirms both the |
|
||||
`NAMESPACE_PREORDER` and `NAMESPACE_REVEAL` wins. The fee burned in the |
|
||||
`NAMESPACE_PREORDER` is spent either way. |
|
||||
|
|
||||
Once the user issues the `NAMESPACE_PREORDER` and `NAMESPACE_REVEAL`, they have |
|
||||
1 year before they must send the `NAMESPACE_READY` transaction. If they do not |
|
||||
do this, then the namespace they created disappears (along with all the names |
|
||||
they imported). |
|
||||
|
|
||||
Developers wanting to create their own namespaces should read the [namespace creation section]({{ site.baseurl }}/core/naming/namespace.html) document. It is highly recommended that |
|
||||
developers request individual support before creating their own space, given the large amount of |
|
||||
cryptocurrency at stake. |
|
||||
@ -1,119 +0,0 @@ |
|||||
--- |
|
||||
layout: core |
|
||||
permalink: /:collection/:path.html |
|
||||
--- |
|
||||
# Naming system feature comparison |
|
||||
{:.no_toc} |
|
||||
|
|
||||
BNS is not the only naming system in wide-spread use, nor is it the only |
|
||||
decentralized naming system that implements human-readable, globally-unique, and |
|
||||
strongly-owned names. This page describes some other naming systems in |
|
||||
comparison to Blockstack: |
|
||||
|
|
||||
* TOC |
|
||||
{:toc} |
|
||||
|
|
||||
|
|
||||
## Blockstack vs DNS |
|
||||
|
|
||||
Blockstack and DNS both implement naming systems, but in fundamentally |
|
||||
different ways. Blockstack *can be used* for resolving host names to IP |
|
||||
addresses, but this is not its default use-case. The [Blockstack Naming |
|
||||
Service]({{ site.baseurl }}/core/naming/introduction.html) (BNS) instead behaves |
|
||||
more like a decentralized |
|
||||
[LDAP](https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol) system for |
|
||||
resolving user names to user data. |
|
||||
|
|
||||
While DNS and BNS handle different problems, they share some terminology and |
|
||||
serialization formats. However, it is important to recognize that this is the |
|
||||
*only* thing they have in common---BNS has fundamentally different semantics |
|
||||
than DNS: |
|
||||
|
|
||||
* **Zone files**: Blockstack stores a DNS zone file for each name. However, |
|
||||
the semantics of a BNS zone file are nothing like the semantics of a DNS zone |
|
||||
file---the only thing they have in common is their format. |
|
||||
A "standard" Blockstack zone files only have `URI` and `TXT` resource records |
|
||||
that point to the user's application data. Moreover, a Blockstack ID has a |
|
||||
*history* of zone files, and historic zone files can alter the way in which a |
|
||||
Blockstack ID gets resolved (DNS has no such concept). It is conceivable that an advanced |
|
||||
user could add `A` and `AAAA` records to their Blockstack ID's zone file, |
|
||||
but these are not honored by any Blockstack software at this time. |
|
||||
|
|
||||
* **Subdomains**: Blockstack has the concept of a subdomain, but it is |
|
||||
semantically very different from a DNS subdomain. In Blockstack, a subdomain |
|
||||
is a Blockstack ID whose state and transaction history are anchored to the |
|
||||
blockchain, but stored within an on-chain Blockstack ID's zone file history. |
|
||||
Unlike DNS subdomains, a BNS subdomain has |
|
||||
its own owner and is a first-class BNS name---all subdomains are resolvable, |
|
||||
and only the subdomain's owner can update the subdomain's records. The only thing BNS subdomains and DNS |
|
||||
subdomains have in common is the name format (e.g. `foo.bar.baz` is a subdomain |
|
||||
of `bar.baz` in both DNS and BNS). |
|
||||
|
|
||||
More details can be found in the [Blockstack vs |
|
||||
DNS]({{ site.baseurl }}/core/naming/comparison.html) document. A feature |
|
||||
comparison can be found at the end of the [Blockstack Naming |
|
||||
Service]({{ site.baseurl }}/core/naming/introduction.html) document. |
|
||||
|
|
||||
## Blockstack vs Namecoin |
|
||||
|
|
||||
Namecoin also implements a decentralized naming service on top of a blockchain, |
|
||||
just like BNS. In fact, early versions of Blockstack were built on Namecoin. |
|
||||
However, [it was discovered](https://www.usenix.org/node/196209) that Namecoin's |
|
||||
merged mining with Bitcoin regularly placed it under the *de facto* control of a single |
|
||||
miner. This prompted a re-architecting of the system to be *portable* across |
|
||||
blockchains, so that if Blockstack's underlying blockchain (currently Bitcoin) |
|
||||
ever became insecure, the system could migrate to a more secure blockchain. |
|
||||
|
|
||||
A feature comparison can be found at the end of the [Blockstack Naming |
|
||||
Service]({{ site.baseurl }}/core/naming/introduction.html) document. |
|
||||
|
|
||||
## Blockstack vs ENS |
|
||||
|
|
||||
ENS also implements a decentralized naming system on top of a blockchain, but as |
|
||||
a smart contract on Ethereum. Like BNS, ENS is geared towards resolving names |
|
||||
to off-chain state (ENS names resolve to a hash, for example). Moreover, ENS is |
|
||||
geared towards providing programmatic control over names with Turing-complete |
|
||||
on-chain resolvers. |
|
||||
|
|
||||
BNS has a fundamentally different relationship with blockchains than ENS. |
|
||||
WHereas ENS tries to use on-chain logic as much as possible, BNS |
|
||||
tries to use the blockchain as little as possible. BNS only uses it to store a |
|
||||
database log for name operations (which are interpreted with an off-chain BNS |
|
||||
node like Blockstack Core). BNS name state and BNS subdomains reside entirely |
|
||||
off-chain in the Atlas network. This has allowed BNS to migrate from blockchain |
|
||||
to blockchain in order to survive individual blockchain failures, and this has |
|
||||
allowed BNS developers to upgrade its consensus rules without having to get the |
|
||||
blockchain's permission (see the [virtualchain |
|
||||
paper](https://blockstack.org/virtualchain.pdf) for details). |
|
||||
|
|
||||
## Summary feature comparison |
|
||||
|
|
||||
|
|
||||
The following feature table provides a quick summary how BNS differs from other naming systems |
|
||||
|
|
||||
| Feature | BNS | [ENS](https://ens.domains/) | DNS | [Namecoin](https://namecoin.org/) | |
|
||||
|----------------------------|-----|-----|-----|----------| |
|
||||
| Globally unique names | X | X | X | X | |
|
||||
| Human-readable names | X | X | X | X | |
|
||||
| Strongly-owned names | X | X | | X | |
|
||||
| Names are enumerable | X | | | X | |
|
||||
| Registration times | 1-2 hours | ~1 week | ~1 day | 1-2 hours | |
|
||||
| Subdomain registration times | 1 hour (instant with [#750](https://github.com/blockstack/blockstack-core/issues/750)) | varies | instant | ~1 hour | |
|
||||
| Anyone can make a TLD/namespace | X | [1] | | [1] | |
|
||||
| TLD/Namespace owners get registration fees | X | | X | | |
|
||||
| TLD/Namespace can be seeded with initial names | X | | X | | |
|
||||
| Portable across blockchains | X | | N/A | | |
|
||||
| Off-chain names | X | | N/A | | |
|
||||
| Off-chain name state | X | X | N/A | | |
|
||||
| Name provenance | X | X | | X | |
|
||||
| [DID](http://identity.foundation) support | X | | | | |
|
||||
| Turing-complete namespace rules | | X | X | | |
|
||||
| Miners are rewarded for participating | [1] | | N/A | X | |
|
||||
|
|
||||
[1] Requires support in higher-level applications. These systems are not aware |
|
||||
of the existence of namespaces/TLDs at the protocol level. |
|
||||
|
|
||||
[2] Blockstack Core destroys the underlying blockchain token to pay for |
|
||||
registration fees when there is no pay-to-namespace-creator address set in the |
|
||||
name's namespace. This has the effect of making the blockchain miners' holdings |
|
||||
slightly more valuable. |
|
||||
@ -1,110 +0,0 @@ |
|||||
--- |
|
||||
layout: core |
|
||||
permalink: /:collection/:path.html |
|
||||
--- |
|
||||
# Register a name |
|
||||
{:.no_toc} |
|
||||
|
|
||||
This section explains registering BNS names and provides instructions for methods |
|
||||
you can use to understandt the cost of namespace registration. |
|
||||
|
|
||||
* TOC |
|
||||
{:toc} |
|
||||
|
|
||||
## Understand registration |
|
||||
|
|
||||
Registering a BNS name costs cryptocurrency. This cost comes from two sources: |
|
||||
|
|
||||
* **Transaction fees:** These are the fees imposed by the cost of storing the |
|
||||
transaction data to the blockchain itself. They are independent of BNS, since |
|
||||
all of the blockchain's users are competing to have their transactions included |
|
||||
in the next block. The blockchain's miners receive the transaction fee. |
|
||||
|
|
||||
* **Registration fees:** Each BNS namespace imposes an *additional* fee on how |
|
||||
much a name costs. The registration fee is sent to the namespace creator |
|
||||
during the first year that a namespace exists, and is sent to a burn address |
|
||||
afterwards. The registration fee is different for each name and is |
|
||||
determined by the namespace itself, but can be queried in advance by the user. |
|
||||
|
|
||||
Registering a name takes two transactions. They are: |
|
||||
|
|
||||
* **`NAME_PREORDER` transaction**: This is the first transaction to be sent. |
|
||||
It tells all BNS nodes the *salted hash* of the BNS name, and it pays the |
|
||||
registration fee to the namespace owner's designated address (or the burn |
|
||||
address). In addition, it proves to the BNS nodes that the client knows about |
|
||||
the current state of the system by including a recent *consensus hash* |
|
||||
in the transaction (see the section on [BNS forks](#bns-forks) for details). |
|
||||
|
|
||||
* **`NAME_REGISTRATION` transaction**: This is the second transaction to be |
|
||||
sent. It reveals the salt and the name to all BNS nodes, and assigns the name |
|
||||
an initial public key hash and zone file hash |
|
||||
|
|
||||
The reason this process takes two transactions is to prevent front-running. |
|
||||
The BNS consensus rules stipulate that a name can only be registered if its |
|
||||
matching preorder transaction was sent in the last 24 hours. Because a name |
|
||||
must be preordered before it is registered, someone watching the blockchain's |
|
||||
peer network cannot race a victim to claim the name they were trying to |
|
||||
register (i.e. the attacker would have needed to send a `NAME_PREORDER` |
|
||||
transaction first, and would have had to have sent it no more than 24 hours |
|
||||
ago). |
|
||||
|
|
||||
Registering a name on top of the Bitcoin blockchain takes 1-2 hours. This is |
|
||||
because you need to wait for the `NAME_PREORDER` transaction to be sufficiently |
|
||||
confirmed before sending the `NAME_REGISTRATION` transaction. The BNS nodes |
|
||||
only register the name once both transactions have at least 6 confirmations |
|
||||
(which itself usually takes about an hour). |
|
||||
|
|
||||
Names are registered on a first-come first-serve basis. |
|
||||
If two different people try to register the same name at the same time, the |
|
||||
person who completes the two-step process *earliest* will receive the name. The |
|
||||
other person's `NAME_REGISTRATION` transaction will be ignored, since it will |
|
||||
not be considered valid at this point. The registration fee paid by the |
|
||||
`NAME_PREORDER` will be lost. However, this situation is rare in practice--- |
|
||||
as of early 2018, we only know of one confirmed instance in the system's 3+ years |
|
||||
of operation. |
|
||||
|
|
||||
Fully-qualified names can be between 3 and 37 characters long, and consist of |
|
||||
the characters `a-z`, `0-9`, `+`, `-`, `_`, and `.`. This is to prevent |
|
||||
[homograph attacks](https://en.wikipedia.org/wiki/IDN_homograph_attack). |
|
||||
`NAME_REGISTRATION` transactions that do not conform to this requirement will be |
|
||||
ignored. |
|
||||
|
|
||||
## Getting a Name's Registration Fee ([reference](https://core.blockstack.org/#price-checks-get-name-price)) |
|
||||
|
|
||||
```bash |
|
||||
$ curl -sL https://core.blockstack.org/v1/prices/names/helloworld.id | jq -r ".name_price" |
|
||||
{ |
|
||||
"btc": 2.5e-05, |
|
||||
"satoshis": 2500 |
|
||||
} |
|
||||
``` |
|
||||
|
|
||||
Note the use of `jq -r` to select the `"name_price"` field. This API |
|
||||
endpoint may return other ancilliary data regarding transaction fee estimation, |
|
||||
but this is the only field guaranteed by this specification to be present. |
|
||||
|
|
||||
## Getting the Current Consensus Hash ([reference](https://core.blockstack.org/#blockchain-operations-get-consensus-hash)) |
|
||||
|
|
||||
```bash |
|
||||
$ curl -sL https://core.blockstack.org/v1/blockchains/bitcoin/consensus |
|
||||
{ |
|
||||
"consensus_hash": "98adf31989bd937576aa190cc9f5fa3a" |
|
||||
} |
|
||||
``` |
|
||||
|
|
||||
The consensus hash must be included in the `NAME_PREORDER` transaction. The BNS |
|
||||
clients do this automatically. See the [transaction format |
|
||||
document]({{ site.baseurl }}/core/wire-format.html) for details as to how to include this in the |
|
||||
transaction. |
|
||||
|
|
||||
## Registering a Name |
|
||||
|
|
||||
Registration happens through a BNS client, such as the [Blockstack |
|
||||
Browser](https://github.com/blockstack/blockstack-browser) or |
|
||||
[blockstack.js](https://github.com/blockstack/blockstack.js). |
|
||||
The reference BNS clients manage a local Bitcoin wallet, calculate transaction fees |
|
||||
dynamically and automatically, and broadcast both the `NAME_PREORDER` and |
|
||||
`NAME_REGISTRATION` transactions at the right times. |
|
||||
|
|
||||
If you want to make your own registration client, you should see the |
|
||||
[transaction format]({{ site.baseurl }}/core/wire-format.html) document. |
|
||||
@ -1,184 +0,0 @@ |
|||||
--- |
|
||||
layout: core |
|
||||
permalink: /:collection/:path.html |
|
||||
--- |
|
||||
# How Atlas Works |
|
||||
{:.no_toc} |
|
||||
|
|
||||
Atlas was designed to overcome the structural weaknesses inherent to all |
|
||||
distributed hash tables. In particular, it uses an unstructured peer network to |
|
||||
maximize resilience against network link failure, and it uses the underlying |
|
||||
blockchain (through BNS) to rate-limit chunk announcements. |
|
||||
|
|
||||
This section contains the following sections: |
|
||||
|
|
||||
* TOC |
|
||||
{:toc} |
|
||||
|
|
||||
## Peer Selection |
|
||||
|
|
||||
Atlas peers self-organize into an unstructured peer-to-peer network. |
|
||||
The Atlas peer network is a [random K-regular |
|
||||
graph](https://en.wikipedia.org/wiki/Random_regular_graph). Each node maintains |
|
||||
*K* neighbors chosen at random from the set of Atlas peers. |
|
||||
|
|
||||
Atlas nodes select peers by carrying out an unbiased random walk of the peer |
|
||||
graph. When "visiting" a node *N*, it will ask for *N*'s neighbors and then |
|
||||
"step" to one of them with a probability dependent on *N*'s out-degree and the |
|
||||
neighbor's in-degree. |
|
||||
|
|
||||
The sampling algorithm is based on the Metropolis-Hastings (MH) random graph walk |
|
||||
algorithm, but with a couple key differences. In particular, the algorithm |
|
||||
attempts to calculate an unbiased peer graph sample that accounts for the fact |
|
||||
that most nodes will be short-lived or unreliable, while a few persistent nodes |
|
||||
will remain online for long periods of time. The sampling algorithm accounts |
|
||||
for this with the following tweaks: |
|
||||
|
|
||||
* If the neighbors of the visited node *N* are all unresponsive, the random |
|
||||
walk resets to a randomly-chosen known neighbor. There is no back-tracking on |
|
||||
the peer graph in this case. |
|
||||
|
|
||||
* The transition probability from *N* to a live neighbor is *NOT* `min(1, |
|
||||
degree(neighbor)/degree(N))` like it is in the vanilla MH algorithm. Instead, |
|
||||
the transition probability discourages backtracking to the previous neighbor *N_prev*, |
|
||||
but in a way that still guarantees that the sampling will remain unbiased. |
|
||||
|
|
||||
* A peer does not report its entire neighbor set when queried, |
|
||||
but only reports a random subset of peers that have met a minimium health threshold. |
|
||||
|
|
||||
* A new neighbor is only selected if it belongs to the same [BNS |
|
||||
fork-set]({{site.baseurl}}/core/naming/introduction.html#bns-forks) (i.e. it reports |
|
||||
as having a recent valid consensus hash). |
|
||||
|
|
||||
The algorithm was adapted from the work from [Lee, Xu, and |
|
||||
Eun](https://arxiv.org/pdf/1204.4140.pdf) in the proceedings of |
|
||||
ACM SIGMETRICS 2012. |
|
||||
|
|
||||
## Comparison to DHTs |
|
||||
|
|
||||
The reason Atlas uses an unstructured random peer network |
|
||||
instead of a [distributed hash table](https://en.wikipedia.org/wiki/Distributed_hash_table) |
|
||||
(DHT) is that DHTs are susceptbile to Sybil attacks. An adaptive adversary can |
|
||||
insert malicious nodes into the DHT in order to stop victims from |
|
||||
resolving chunks or finding honest neighbors. |
|
||||
|
|
||||
### Chunk Censorship |
|
||||
|
|
||||
In a DHT, an attacker can censor a chunk by inserting nodes into the peers' routing tables |
|
||||
such that the attacker takes control over all of the chunk's hash buckets. |
|
||||
It can do so at any point in time after the chunk was first stored, |
|
||||
because only the peers who maintain the chunk's hash bucket have to store it. |
|
||||
This is a *fundamental* problem with structured overlay networks |
|
||||
that perform request routing based on content hash---they give the attacker |
|
||||
insight as to the path(s) the queries take through the peer graph, and thus |
|
||||
reduce the number of paths the attacker must disrupt in order to censor the |
|
||||
chunk. |
|
||||
|
|
||||
Atlas uses an unstructured overlay network combined with a 100% chunk |
|
||||
replication strategy in order to maximize |
|
||||
the amount of work an adversary has to do to censor a chunk. |
|
||||
In Atlas, all peers replicate a chunk, and the paths the chunk take through the |
|
||||
network are *independent* of the content and *randomized* by the software |
|
||||
(so the paths cannot be predicted in advance). The attacker's only |
|
||||
recourse is to quickly identify the nodes that can serve the chunk and partition them from |
|
||||
the rest of the network in order to carry out a censorship attack. |
|
||||
This requires them to have visibility into the vast majority of network links in |
|
||||
the Atlas network (which is extremely difficult to do, because in practice Atlas |
|
||||
peers maintain knowledge of up to 65536 neighbors and only report 10 random peers |
|
||||
when asked). |
|
||||
|
|
||||
### Neighbor Censorship |
|
||||
|
|
||||
Another problem with DHTs is that their overlay |
|
||||
network structure is determined by preferential attachment. Not every peer that |
|
||||
contacts a given DHT node has an equal chance of becoming its neighbor. |
|
||||
The node will instead rank a set of peers as being more or less ideal |
|
||||
for being neighbors. In DHTs, the degree of preference a node exhibits to |
|
||||
another node is usually a function of the node's self-given node identifier |
|
||||
(e.g. a node might want to select neighbors based on proximity in the key |
|
||||
space). |
|
||||
|
|
||||
The preferential attachment property means that an adaptive adversary can game the node's |
|
||||
neighbor selection algorithm by inserting malicious nodes that do not |
|
||||
forward routing or lookup requests. The attacker does not even have to eclipse |
|
||||
the victim node---the victim node will simply prefer to talk to the attacker's unhelpful nodes |
|
||||
instead of helpful honest nodes. In doing so, the attacker can prevent honest peers from discovering each |
|
||||
other and each other's chunks. |
|
||||
|
|
||||
Atlas's neighbor selection strategy does not exhibit preferential attachment |
|
||||
based on any self-reported node properties. A |
|
||||
node is selected as a neighbor only if it is reached through an unbiased random graph |
|
||||
walk, and if it responds to queries correctly. |
|
||||
In doing so, an attacker is forced to completely eclipse a set of nodes |
|
||||
in order to cut them off from the rest of the network. |
|
||||
|
|
||||
## Chunk Propagation |
|
||||
|
|
||||
Atlas nodes maintain an *inventory* of chunks that are known to exist. Each |
|
||||
node independently calculates the chunk inventory from its BNS database. |
|
||||
Because the history of name operations in BNS is linearized, each node can |
|
||||
construct a linearized sub-history of name operations that can set chunk |
|
||||
hashes as their name state. This gives them a linearized sequence of chunks, |
|
||||
and every Atlas peer will independently arrive at the same sequence by reading |
|
||||
the same blockchain. |
|
||||
|
|
||||
Atlas peers keep track of which chunks are present and which are absent. They |
|
||||
each construct an *inventory vector* of chunks *V* such that *V[i]* is set to 1 |
|
||||
if the node has the chunk whose hash is in the *i*th position in the chunk |
|
||||
sequence (and set to 0 if it is absent). |
|
||||
|
|
||||
Atlas peers exchange their inventory vectors with their neighbors in order to |
|
||||
find out which chunks they each have. Atlas nodes download chunks from |
|
||||
neighbors in rarest-first order in order to prioritize data replication for the |
|
||||
chunks that are currently most at-risk for disappearing due to node failure. |
|
||||
|
|
||||
``` |
|
||||
Name operation | chunk hashes | chunk data | Inventory |
|
||||
history | as name state | | vector |
|
||||
|
|
||||
+-------------------+ |
|
||||
| NAME_PREORDER | |
|
||||
+-------------------+----------------+ |
|
||||
| NAME_REGISTRATION | chunk hash | "0123abcde..." 1 |
|
||||
+-------------------+----------------+ |
|
||||
| NAME_UPDATE | chunk hash | (null) 0 |
|
||||
+-------------------+----------------+ |
|
||||
| NAME_TRANSFER | |
|
||||
+-------------------+ |
|
||||
| NAME_PREORDER | |
|
||||
+-------------------+----------------+ |
|
||||
| NAME_IMPORT | chunk hash | "4567fabcd..." 1 |
|
||||
+-------------------+----------------+ |
|
||||
| NAME_TRANSFER | |
|
||||
+-------------------| |
|
||||
. . . |
|
||||
|
|
||||
|
|
||||
Figure 2: Relationship between Atlas node chunk inventory and BNS name state. |
|
||||
Some name operations announce name state in the blockchain, which Atlas |
|
||||
interprets as a chunk hash. The Atlas node builds up a vector of which chunks |
|
||||
it has and which ones it does not, and announces it to other Atlas peers so |
|
||||
they can fetch chunks they are missing. In this example, the node's |
|
||||
inventory vector is [1, 0, 1], since the 0th and 2nd chunks are present |
|
||||
but the 1st chunk is missing. |
|
||||
``` |
|
||||
|
|
||||
## Querying Chunk Inventories |
|
||||
|
|
||||
Developers can query a node's inventory vector as follows: |
|
||||
|
|
||||
```python |
|
||||
>>> import blockstack |
|
||||
>>> result = blockstack.lib.client.get_zonefile_inventory("https://node.blockstack.org:6263", 0, 524288) |
|
||||
>>> print len(result['inv']) |
|
||||
11278 |
|
||||
>>> |
|
||||
``` |
|
||||
|
|
||||
The variable `result['inv']` here is a big-endian bit vector, where the *i*th |
|
||||
bit is set to 1 if the *i*th chunk in the chunk sequence is present. The bit at |
|
||||
`i=0` (the earliest chunk) refers to the leftmost bit. |
|
||||
|
|
||||
A sample program that inspects a set of Atlas nodes' inventory vectors and determines |
|
||||
which ones are missing which chunks can be found |
|
||||
[here](https://github.com/blockstack/atlas/blob/master/atlas/atlas-test). |
|
||||
@ -1,126 +0,0 @@ |
|||||
--- |
|
||||
layout: core |
|
||||
permalink: /:collection/:path.html |
|
||||
--- |
|
||||
# Overview of the Atlas network |
|
||||
{:.no_toc} |
|
||||
|
|
||||
This document describes the Atlas network, a peer-to-peer content-addressed |
|
||||
storage system whose chunks' hashes are announced on a public blockchain. Atlas |
|
||||
allows users and developers to **permanently store** chunks of data that are |
|
||||
**replicated across every peer.** As long as at least one Atlas peer is online, |
|
||||
all chunks are available to clients. |
|
||||
|
|
||||
This document is aimed at developers and technical users. The following |
|
||||
concepts are discussed: |
|
||||
|
|
||||
* TOC |
|
||||
{:toc} |
|
||||
|
|
||||
The reader of this document is expected to be familiar with the [Blockstack Naming Service]({{site.baseurl}}/core/naming/introduction.html)(BNS), as well as Blockstack's |
|
||||
storage system [Gaia](https://github.com/blockstack/gaia). We advise the reader |
|
||||
to familiarize themselves with both systems before approaching this document. |
|
||||
|
|
||||
## Architecture |
|
||||
|
|
||||
Atlas is designed to integrate with BNS in order to allow users to |
|
||||
store name state off-chain, encoded as a DNS zone file. |
|
||||
The overwhelmingly-common use-cases in Blockstack are: |
|
||||
|
|
||||
* Storing a name's routing information for its owners' [Gaia](https://github.com/blockstack/gaia) |
|
||||
datastores. |
|
||||
* Storing BNS subdomain transactions and associated state. |
|
||||
|
|
||||
Atlas is a middleware system in Blockstack. Most developers do not |
|
||||
interact with it directly. BNS clients like the |
|
||||
[Blockstack Browser](https://github.com/blockstack/blockstack-browser) |
|
||||
automatically generate zone files for the names they register, and automatically |
|
||||
propagate them to the Atlas network. BNS API endpoints, including our |
|
||||
[public endpoint](https://core.blockstack.org) and the |
|
||||
[blockstack.js](https://github.com/blockstack/blockstack.js) library, |
|
||||
will automatically fetch zone files from Atlas when they need to look |
|
||||
up data in Gaia (such as profiles and app data). |
|
||||
|
|
||||
``` |
|
||||
+--------------+ +---------------+ +----------------+ |
|
||||
clients | Blockstack | | blockstack.js | | BNS API module | |
|
||||
| Browser | | | | | |
|
||||
+--------------+ +---------------+ +----------------+ |
|
||||
^ ^ ^ ^ ^ ^ |
|
||||
| | | | | | |
|
||||
| | | | | | |
|
||||
V | V | V | |
|
||||
+----------+ | +----------+ | +----------+ | |
|
||||
Gaia | Gaia hub | | | Gaia hub | | | Gaia hub | | |
|
||||
+----------+ | +----------+ | +----------+ | |
|
||||
| | | |
|
||||
| | | |
|
||||
V V V |
|
||||
+---------------------------------------------------------------+ |
|
||||
Atlas | Atlas Peer Network | |
|
||||
+----------+------+----------+-----+----------+------+----------+ |
|
||||
BNS | BNS node | | BNS node | | BNS node | | BNS node | |
|
||||
+----------+ +----------+ +----------+ +----------+ |
|
||||
^ ^ ^ ^ |
|
||||
| (indexing | | | |
|
||||
| blockchain) | | | |
|
||||
+---------------------------------------------------------------+ |
|
||||
Blockchain | Blockchain Peer Network | |
|
||||
+---------------------------------------------------------------+ |
|
||||
|
|
||||
|
|
||||
Figure 1: Location of Atlas in the Blockstack architecture. Each BNS node |
|
||||
implements an Atlas peer. An Atlas peer treats a name state value in BNS as |
|
||||
the hash of a DNS zone file. Atlas peers exchange zone files with one another |
|
||||
until they each have a full replica of all known zone files. Clients can look |
|
||||
up zone files for names using the name's stat value as a zone file hash. Clients |
|
||||
can broadcast zone files to the network if they match a previously-announced |
|
||||
hash. In practice, zone files store URLs to a name owner's Gaia hubs, thereby |
|
||||
allowing Blockstack apps to read and write data in Gaia. |
|
||||
``` |
|
||||
|
|
||||
Nevertheless, Atlas is a general-purpose content-addressed storage |
|
||||
system that advanced developers can use to **host data in an immutable |
|
||||
and durable manner.** Beyond its default use-case in Blockstack, |
|
||||
Atlas is ideal for tasks like: |
|
||||
|
|
||||
* Announcing PGP public keys under a human-readable name |
|
||||
* Storing package hashes for a software release |
|
||||
* Securely deploying shell scripts to remote VMs |
|
||||
* Binding human-readable names to Tor .onion addresses |
|
||||
([example](https://github.com/blockstack-packages/blockstack-tor)) |
|
||||
|
|
||||
## Motivation |
|
||||
|
|
||||
Atlas was designed to augment BNS. BNS allows each name to store a small |
|
||||
amount of state---on the order of 20 bytes. The size is so small because the |
|
||||
state must be recorded to a public blockchain, where the cost per byte is |
|
||||
high and the blockchain protocol limits the size of transactions. |
|
||||
|
|
||||
To compensate for this, we developed an off-chain storage system allows BNS |
|
||||
names to bind and store a large amount of state to each name in a way that |
|
||||
*preserves the security properties of having written that state to the |
|
||||
blockchain*. Instead of storing 20 bytes of data on the blockchain, a BNS name |
|
||||
owner would store the *cryptograhpic hash* of its state, and then store the actual state |
|
||||
Atlas. This decouples the name's state size from the blockchain. |
|
||||
|
|
||||
The reference implementation of Atlas currently allows up to 40kb of state to be |
|
||||
bound to a BNS name, instead of a measly 20 bytes. The 40kb of data is |
|
||||
replicated to each BNS node, where it is stored forever. |
|
||||
|
|
||||
## Feature Comparison |
|
||||
|
|
||||
Atlas is not the only peer-to-peer content-addressible chunk store in existance. The following |
|
||||
feature table describes Atlas in relation to other popular chunk stores. |
|
||||
|
|
||||
| **Features** | Atlas | BitTorrent | [DAT](https://datproject.org/) | [IPFS](https://ipfs.io) | [Swarm](https://github.com/ethersphere/swarm) | |
|
||||
|-----------------------------|-------|------------|--------------------------------|-------------------------|-----------------------------------------------| |
|
||||
| Each peer stores all chunks | X | X | | | | |
|
||||
| Replicas are permanent [1] | X | X | X | | | |
|
||||
| Replicas are free | | X | X | X | | |
|
||||
| Sybil-resistant chunk discovery | X | X | | | X | |
|
||||
| Sybil-resistant peer discovery | X | | | | | |
|
||||
| Fixed chunk size | X | | X | X | X | |
|
||||
|
|
||||
[1] Here, "permanent" means that once a peer has data, they will never evict it |
|
||||
as part of the protocol. |
|
||||
@ -1,5 +0,0 @@ |
|||||
# About this `docs` directory |
|
||||
|
|
||||
The contents of this directory acts as source for material for |
|
||||
[docs.blockstack.org](https://docs.blockstack.org/), a searchable documentation |
|
||||
site for all things Blockstack. |
|
||||
@ -1,4 +0,0 @@ |
|||||
# Legacy, Deprecated, or No longer Useful Documentation |
|
||||
|
|
||||
Documents here are out-of-date but preserved for posterity. Do not rely on |
|
||||
them. |
|
||||
@ -1,185 +0,0 @@ |
|||||
--- |
|
||||
layout: core |
|
||||
permalink: /:collection/:path.html |
|
||||
--- |
|
||||
# Blockstack Technical FAQ |
|
||||
{:.no_toc} |
|
||||
* TOC |
|
||||
{:toc} |
|
||||
|
|
||||
|
|
||||
|
|
||||
This document lists frequently-asked questions and answers to technical |
|
||||
questions about Blockstack. |
|
||||
|
|
||||
If you are new to Blockstack, you should read the |
|
||||
[non-technical FAQ](https://blockstack.org/faq) first. |
|
||||
|
|
||||
If you have a technical question that gets frequently asked on the |
|
||||
[forum](https://forum.blockstack.org) or [Slack](https://blockstack.slack.com), |
|
||||
feel free to send a pull-request with the question and answer. |
|
||||
|
|
||||
## Who should build on Blockstack? |
|
||||
|
|
||||
Everyone! But more seriously, if you are building an application in JavaScript |
|
||||
that requires sign-in and storage you should look at using Blockstack. The APIs |
|
||||
we provide are not only decentralized (No dependency on Google, Facebook, or |
|
||||
other OAuth provider) but easier to use than traditional OAuth. Also you no |
|
||||
longer have to maintain and secure databases with all your user information. |
|
||||
That data is stored securely with the people who created it. |
|
||||
|
|
||||
## What is a "serverless" app? |
|
||||
|
|
||||
The application itself should not run application-specific functionality on a server. All of its functionality should run on end-points. However, the application may use non-app-specific servers with the caveat that they must not be part of the trusted computing base. This is the case with storage systems like Amazon S3 and Dropbox, for example, because Blockstack's data is signed and verified end-to-end (so the storage systems are not trusted to serve data). Serverless can also mean applications where some amount of server-side logic is still written by the application developer but unlike traditional architectures is run in stateless compute containers that are event-triggered, ephemeral (may only last for one invocation) |
|
||||
|
|
||||
|
|
||||
## How are Blockstack domains different from normal DNS domains? |
|
||||
|
|
||||
Blockstack domains are not registered on the traditional DNS run by an organized called ICANN. Instead they're registered on a blockchain in a fully decentralized way. This means that Blockstack domains are truly owned by their owners and cannot be taken away. All Blockstack domains have public keys by default (public keys are required to own the domains), unlike the traditional DNS where a small fraction of domains get the (optional) public key certificates. |
|
||||
|
|
||||
## What is a virtual chain? |
|
||||
|
|
||||
Blockstack is designed around a "virtual chain" concept, where nodes only need to reach consensus on the shared "virtual chain" they're interested in. Virtual chains do not interact with one another, and a single blockchain can host many virtual chains. These virtual chains can live in any blockchain for which there exists a driver, and virtual chain clients only need to execute their virtual chain transactions (i.e. Blockstack only processes Blockstack virtual chain transactions). |
|
||||
|
|
||||
## What is Blockstack Core and who is working on it? |
|
||||
|
|
||||
Blockstack Core is the reference implementation of the Blockstack protocol described in our white paper. It consists of a couple of parts: |
|
||||
|
|
||||
- Virtualchain implementation: This is a python library that parses the underlying blockchain (Bitcoin) and builds the state of the Blockstack DNS. |
|
||||
- Blockstack Core: Uses the Virtualchain to build the DNS state and comes to a consensus on that state in a peer network (Atlas). |
|
||||
- Blockstack API: Indexes the data stored by Blockstack Core and makes it available in a performant way to applications. |
|
||||
|
|
||||
The project is open-source and anyone can contribute! The major contributors are mostly employees of Blockstack PBC. You can see the full list of contributors here: https://github.com/blockstack/blockstack-core/graphs/contributors |
|
||||
|
|
||||
|
|
||||
## How is Blockstack different from Ethereum for building decentralized apps? |
|
||||
|
|
||||
You can think of Ethereum as a "heavy" blockchain that does everything for you. All the complexity is handled on-chain, computations are run there, and all scalability and security concerns need to be handled at the blockchain level. It amounts to a "mainframe" that runs all the applications in the ecosystem. |
|
||||
|
|
||||
Blockstack puts minimal logic into a blockchain and handles scalability outside of the blockchain by re-using existing internet infrastructure. Our architectural design mirrors how computing has developed; moving from mainframes to smaller networked entities. |
|
||||
|
|
||||
Read more about the differences between Blockstack and Ethereum dapps in the following forum post: https://forum.blockstack.org/t/what-is-the-difference-between-blockstack-and-ethereum/781/2 |
|
||||
|
|
||||
## Can Blockstack only run on Bitcoin? |
|
||||
|
|
||||
The model we're currently exploring is where Blockstack can process multiple blockchains to construct the global state where each namespace is tied to a single blockchain. Meaning that say the .id namespace is defined to run on Bitcoin and a .eth namespace is defined to run on Ethereum. Blockstack can process transactions from both blockchains and update the state of namespaces, but the consistency of any given namespace depends only on the underlying blockchain it was defined on. |
|
||||
|
|
||||
## Does Blockstack use a DHT (Distributed Hash Table)? |
|
||||
|
|
||||
It does not, as of November 2016. It uses a much more reliable system called the Atlas Network. Details here: https://blog.blockstack.org/blockstack-core-v0-14-0-release-aad748f46d#.30gzlthdw |
|
||||
|
|
||||
## Can the Blockstack network fork? |
|
||||
|
|
||||
Yes, the Blockstack network can fork if the underlying blockchain encounters a deep fork. In this case, blockstack nodes on either side of the fork will diverge from one another. |
|
||||
|
|
||||
We have yet to encounter a deep fork. If this does happen, then Blockstack will use the virtualchain state on the majority fork once the fork resolves. |
|
||||
|
|
||||
We also hard fork the network once a year to make protocol breaking changes and upgrade the network. The last one of these happened on block `488500` on the bitcoin blockchain. There are more details about the fork in this forum post: https://forum.blockstack.org/t/blockstack-annual-hard-fork-2017/1618 |
|
||||
|
|
||||
## How is the Blockstack network upgraded over time? What parties need to agree on an upgrade? |
|
||||
|
|
||||
We're working on an on-chain voting strategy similar to how mining works, where anyone can cast a vote proportional to the amount of Bitcoin burned. Similar to how Bitcoin upgrades, a new feature will activate if a certain threshold (e.g. 80%) of votes consistently request its adoption over a given time interval (e.g. a couple weeks). |
|
||||
|
|
||||
Until then, we will publicly announce the availability of new software, with the promise that each release will bring highly-desired features to make upgrading worth the users' whiles. |
|
||||
|
|
||||
## Who gets the registration fees for name registrations? |
|
||||
|
|
||||
With the current design, names are purchased by paying tribute with Bitcoin mining fees. |
|
||||
|
|
||||
|
|
||||
## Where are the current core developers based? What are the requirements for being a core developer? |
|
||||
|
|
||||
Most of the core developers work in NYC and Hong Kong. Developers who've contributed to the [core open-source software](https://github.com/blockstack/blockstack-core) over a long enough time period, by default, get included in the list of core developers. There is no formal process for being part of this informal list. Core developers, generally, have the ability to write high-quality code, understand distributed systems and applied crypto, and share a vision of building a truly decentralized internet and are dedicated to that cause. |
|
||||
|
|
||||
## I heard some companies working on Blockstack have raised venture capital, how does that impact the project? |
|
||||
|
|
||||
Blockstack, like Linux, is an open-source project with a GPLv3 license for the core technology. Just like different companies build apps and services on top of Linux and have different individual business models, there are companies who're building apps & services for Blockstack on top of the core open-source technology and these companies have various business models and funding sources respectively. Having more venture-backed companies join the ecosystem for a decentralized internet is a good thing for everyone participating in the ecosystem including users and developers. |
|
||||
|
|
||||
## Where is my data stored and how do I control who access it? |
|
||||
|
|
||||
You control where your data is stored (you could run your own server, or use your own cloud storage - Dropbox, Amazon S3, and keep backups across all). You then use those places as locations pointed to by the URLs in your Blockstack ID's zone file. |
|
||||
|
|
||||
## Why should I trust the information, like name ownership or public key mappings, read from Blockstack? |
|
||||
|
|
||||
Blockstack records are extremely hard to tamper with. This is because the bindings for name ownership (names on Blockstack are owned by public keys) are announced in a proof-of-work blockchain (Bitcoin) and to change these binding an attacker will need to come up with a blockchain with more proof-of-work than the current Bitcoin blockchain but with a different history. Bitcoin's [current hash rate](https://blockchain.info/charts/hash-rate) makes this task almost impossible for non-state actors. |
|
||||
|
|
||||
## Can anyone register a TLD? |
|
||||
|
|
||||
Yes, anyone can register a TLD. If a TLD has not been registered already and you're willing to pay the registration fee for it, you can go ahead and register that TLD. There is no centralized party that can stop you from registering a TLD. |
|
||||
|
|
||||
|
|
||||
## What programming language can I use to build these apps? |
|
||||
|
|
||||
To make apps that run in the web browser using Blockstack, you can use JavaScript and any of the same web frameworks or libraries you use today such as React, AngularJs, Vue.js or jQuery. The Blockstack Core is implementated in Python, but you can use any language you like for native apps as long as you are able to consume a JSON REST API. |
|
||||
|
|
||||
|
|
||||
## Do I need to run a full Blockstack node to use Blockstack? |
|
||||
|
|
||||
tl;dr: You don't, but its very easy to. |
|
||||
|
|
||||
To reduce the overhead involved in getting started we maintain a fleet of Blockstack Core nodes that your Blockstack applications connect to by default. If you want to run your own we provide detailed instructions on our [install page](https://blockstack.org/install). It only takes about 5-10 minutes to spin up your full node! |
|
||||
|
|
||||
## What is the capacity per block for registrations using Blockstack? |
|
||||
|
|
||||
Initial registrations can be done at an order of hundreds per block and once an identity is registered you can do “unlimited” updates to the data because that is off-chain. We’re also working on a more scalable solution where a very large number of identities can be registered but that’s not live yet and is in the pipeline as a rough benchmark. in summer 2015, Blockstack did 30,000+ identity registrations in a matter of few days live on the blockchain and Blockstack was actually throttling its servers and not taking up more than 100-200 transactions per block. It could’ve easily taken up more transactions without impacting the network. |
|
||||
|
|
||||
## What language is the Blockstack software written in? |
|
||||
|
|
||||
Python 2 and Node.js |
|
||||
|
|
||||
## What incentives are there to run a Blockstack node? |
|
||||
|
|
||||
Running a Blockstack node keeps you secure by ensuring that your app gets the right names and public keys. It's not expensive; it takes as much resources as a Chrome tab. |
|
||||
|
|
||||
## Can Blockstack apps scale, given that Blockstack uses blockchains which don't scale that well? |
|
||||
|
|
||||
Yes. Blockstack only uses the blockchain for name registration. Everything else happens off-chain, so apps work just as fast as they do on the Web. |
|
||||
|
|
||||
## What if the current companies and developers working on Blockstack disappear, would the network keep running? |
|
||||
|
|
||||
Yes, the Blockstack network will keep running. All of Blockstack's code is open-source and anyone can deploy Blockstack nodes or maintain the code. Further, Blockstack nodes don't need to coordinate with each other to function. Any node that a user deploys can function correctly independently. |
|
||||
|
|
||||
|
|
||||
## Where does Blockstack keep my app data? |
|
||||
|
|
||||
As a Blockstack user, you can choose exactly where your data gets stored. |
|
||||
Blockstack uses a decentralized storage system called |
|
||||
[Gaia](https://github.com/blockstack/gaia) to host your data. Gaia is different |
|
||||
from other storage systems because it lets you securely host your data wherever you want---in cloud |
|
||||
storage providers, on your personal server, or in another decentralized storage |
|
||||
system like BitTorrent or IPFS. |
|
||||
|
|
||||
When you register, you are given a default Gaia hub that replicates your |
|
||||
data to a bucket in Microsoft Azure. However, you can configure and |
|
||||
deploy your own Gaia hub and have Blockstack store your data there instead. |
|
||||
|
|
||||
The [Blockstack Naming Service]({{ site.baseurl }}/core/naming/introduction.html) and the [Atlas network]({{ site.baseurl }}/core/atlas/overview.html) work together to help other users discover your |
|
||||
app-specific public data, given your Blockstack ID. |
|
||||
|
|
||||
## What is a Blockstack Subdomain? |
|
||||
|
|
||||
This is also a Blockstack ID, and can be used for all the things a Blockstack ID |
|
||||
can be used for. The only difference is that they have the format `foo.bar.baz` |
|
||||
instead of `bar.baz`. For example, |
|
||||
[jude.personal.id](https://core.blockstack.org/v1/users/jude.personal.id) is a |
|
||||
Blockstack ID, and is a subdomain of `personal.id`. |
|
||||
|
|
||||
Subdomains are first-class Blockstack IDs---they can be used for all the same |
|
||||
things that an on-chain Blockstack ID can be used for, and they have all of |
|
||||
the same safety properties. They are globally unique, they are strongly owned |
|
||||
by a private key, and they are human-readable. |
|
||||
|
|
||||
Subdomains are considerably cheaper than Blockstack IDs, since hundreds of them |
|
||||
can be registered with a single transaction. The [BNS |
|
||||
documentation]({{ site.baseurl }}/core/naming/introduction.html) describes them in detail. |
|
||||
|
|
||||
Subdomains provide a fast, inexpensive way to onboard many users at once. |
|
||||
|
|
||||
## Can I get a Blockstack ID without spending Bitcoin? |
|
||||
|
|
||||
Blockstack subdomains can be obtained without spending Bitcoin |
|
||||
by asking a subdomain registrar to create one for you. |
|
||||
|
|
||||
## Is there a Blockstack name explorer? |
|
||||
|
|
||||
Yes! It's at https://explorer.blockstack.org |
|
||||
@ -1,499 +0,0 @@ |
|||||
--- |
|
||||
layout: core |
|
||||
permalink: /:collection/:path.html |
|
||||
--- |
|
||||
# Bitcoin wire format |
|
||||
{:.no_toc} |
|
||||
|
|
||||
This page is for organizations who want to be able to create and send name operation transactions to the blockchain(s) Blockstack supports. |
|
||||
It describes the transaction formats for the Bitcoin blockchain. |
|
||||
|
|
||||
* TOC |
|
||||
{:toc} |
|
||||
|
|
||||
## Transaction format |
|
||||
|
|
||||
Each Bitcoin transaction for Blockstack contains signatures from two sets of keys: the name owner, and the payer. The owner `scriptSig` and `scriptPubKey` fields are generated from the key(s) that own the given name. The payer `scriptSig` and `scriptPubKey` fields are used to *subsidize* the operation. The owner keys do not pay for any operations; the owner keys only control the minimum amount of BTC required to make the transaction standard. The payer keys only pay for the transaction's fees, and (when required) they pay the name fee. |
|
||||
|
|
||||
This construction is meant to allow the payer to be wholly separate from the owner. The principal that owns the name can fund their own transactions, or they can create a signed transaction that carries out the desired operation and request some other principal (e.g. a parent organization) to actually pay for and broadcast the transaction. |
|
||||
|
|
||||
The general transaction layout is as follows: |
|
||||
|
|
||||
| **Inputs** | **Outputs** | |
|
||||
| ------------------------ | ----------------------- | |
|
||||
| Owner scriptSig (1) | `OP_RETURN <payload>` (2) | |
|
||||
| Payment scriptSig | Owner scriptPubKey (3) | |
|
||||
| Payment scriptSig... (4) | |
|
||||
| ... (4) | ... (5) | |
|
||||
|
|
||||
(1) The owner `scriptSig` is *always* the first input. |
|
||||
(2) The `OP_RETURN` script that describes the name operation is *always* the first output. |
|
||||
(3) The owner `scriptPubKey` is *always* the second output. |
|
||||
(4) The payer can use as many payment inputs as (s)he likes. |
|
||||
(5) At most one output will be the "change" `scriptPubKey` for the payer. |
|
||||
Different operations require different outputs. |
|
||||
|
|
||||
## Payload Format |
|
||||
|
|
||||
Each Blockstack transaction in Bitcoin describes the name operation within an `OP_RETURN` output. It encodes name ownership, name fees, and payments as `scriptPubKey` outputs. The specific operations are described below. |
|
||||
|
|
||||
Each `OP_RETURN` payload *always* starts with the two-byte string `id` (called the "magic" bytes in this document), followed by a one-byte `op` that describes the operation. |
|
||||
|
|
||||
### NAME_PREORDER |
|
||||
|
|
||||
Op: `?` |
|
||||
|
|
||||
Description: This transaction commits to the *hash* of a name. It is the first |
|
||||
transaction of two transactions that must be sent to register a name in BNS. |
|
||||
|
|
||||
Example: [6730ae09574d5935ffabe3dd63a9341ea54fafae62fde36c27738e9ee9c4e889](https://www.blocktrail.com/BTC/tx/6730ae09574d5935ffabe3dd63a9341ea54fafae62fde36c27738e9ee9c4e889) |
|
||||
|
|
||||
`OP_RETURN` wire format: |
|
||||
``` |
|
||||
0 2 3 23 39 |
|
||||
|-----|--|--------------------------------------------------|--------------| |
|
||||
magic op hash_name(name.ns_id,script_pubkey,register_addr) consensus hash |
|
||||
``` |
|
||||
|
|
||||
Inputs: |
|
||||
* Payment `scriptSig`'s |
|
||||
|
|
||||
Outputs: |
|
||||
* `OP_RETURN` payload |
|
||||
* Payment `scriptPubkey` script for change |
|
||||
* `p2pkh` `scriptPubkey` to the burn address (0x00000000000000000000000000000000000000) |
|
||||
|
|
||||
Notes: |
|
||||
* `register_addr` is a base58check-encoded `ripemd160(sha256(pubkey))` (i.e. an address). This address **must not** have been used before in the underlying blockchain. |
|
||||
* `script_pubkey` is either a `p2pkh` or `p2sh` compiled Bitcoin script for the payer's address. |
|
||||
|
|
||||
### NAME_REGISTRATION |
|
||||
|
|
||||
Op: `:` |
|
||||
|
|
||||
Description: This transaction reveals the name whose hash was announced by a |
|
||||
previous `NAME_PREORDER`. It is the second of two transactions that must be |
|
||||
sent to register a name in BNS. |
|
||||
|
|
||||
Example: [55b8b42fc3e3d23cbc0f07d38edae6a451dfc512b770fd7903725f9e465b2925](https://www.blocktrail.com/BTC/tx/55b8b42fc3e3d23cbc0f07d38edae6a451dfc512b770fd7903725f9e465b2925) |
|
||||
|
|
||||
`OP_RETURN` wire format (2 variations allowed): |
|
||||
|
|
||||
Variation 1: |
|
||||
``` |
|
||||
0 2 3 39 |
|
||||
|----|--|-----------------------------| |
|
||||
magic op name.ns_id (37 bytes) |
|
||||
``` |
|
||||
|
|
||||
Variation 2: |
|
||||
``` |
|
||||
0 2 3 39 59 |
|
||||
|----|--|----------------------------------|-------------------| |
|
||||
magic op name.ns_id (37 bytes, 0-padded) value |
|
||||
``` |
|
||||
|
|
||||
Inputs: |
|
||||
* Payer `scriptSig`'s |
|
||||
|
|
||||
Outputs: |
|
||||
* `OP_RETURN` payload |
|
||||
* `scriptPubkey` for the owner's address |
|
||||
* `scriptPubkey` for the payer's change |
|
||||
|
|
||||
Notes: |
|
||||
|
|
||||
* Variation 1 simply registers the name. Variation 2 will register the name and |
|
||||
set a name value simultaneously. This is used in practice to set a zone file |
|
||||
hash for a name without the extra `NAME_UPDATE` transaction. |
|
||||
* Both variations are supported. Variation 1 was designed for the time when |
|
||||
Bitcoin only supported 40-byte `OP_RETURN` outputs. |
|
||||
|
|
||||
### NAME_RENEWAL |
|
||||
|
|
||||
Op: `:` |
|
||||
|
|
||||
Description: This transaction renews a name in BNS. The name must still be |
|
||||
registered and not expired, and owned by the transaction sender. |
|
||||
|
|
||||
Example: [e543211b18e5d29fd3de7c0242cb017115f6a22ad5c6d51cf39e2b87447b7e65](https://www.blocktrail.com/BTC/tx/e543211b18e5d29fd3de7c0242cb017115f6a22ad5c6d51cf39e2b87447b7e65) |
|
||||
|
|
||||
`OP_RETURN` wire format (2 variations allowed): |
|
||||
|
|
||||
Variation 1: |
|
||||
``` |
|
||||
0 2 3 39 |
|
||||
|----|--|-----------------------------| |
|
||||
magic op name.ns_id (37 bytes) |
|
||||
``` |
|
||||
|
|
||||
Variation 2: |
|
||||
``` |
|
||||
0 2 3 39 59 |
|
||||
|----|--|----------------------------------|-------------------| |
|
||||
magic op name.ns_id (37 bytes, 0-padded) value |
|
||||
``` |
|
||||
|
|
||||
Inputs: |
|
||||
|
|
||||
* Payer `scriptSig`'s |
|
||||
|
|
||||
Outputs: |
|
||||
|
|
||||
* `OP_RETURN` payload |
|
||||
* `scriptPubkey` for the owner's addess. This can be a different address than |
|
||||
the current name owner (in which case, the name is renewed and transferred). |
|
||||
* `scriptPubkey` for the payer's change |
|
||||
* `scriptPubkey` for the burn address (to pay the name cost) |
|
||||
|
|
||||
Notes: |
|
||||
|
|
||||
* This transaction is identical to a `NAME_REGISTRATION`, except for the presence of the fourth output that pays for the name cost (to the burn address). |
|
||||
* Variation 1 simply renews the name. Variation 2 will both renew the name and |
|
||||
set a new name value (in practice, the hash of a new zone file). |
|
||||
* Both variations are supported. Variation 1 was designed for the time when |
|
||||
Bitcoin only supported 40-byte `OP_RETURN` outputs. |
|
||||
* This operation can be used to transfer a name to a new address by setting the |
|
||||
second output (the first `scriptPubkey`) to be the `scriptPubkey` of the new |
|
||||
owner key. |
|
||||
|
|
||||
### NAME_UPDATE |
|
||||
|
|
||||
Op: `+` |
|
||||
|
|
||||
Description: This transaction sets the name state for a name to the given |
|
||||
`value`. In practice, this is used to announce new DNS zone file hashes to the [Atlas |
|
||||
network]({{ site.baseurl }}/core/atlas/overview.html). |
|
||||
|
|
||||
Example: [e2029990fa75e9fc642f149dad196ac6b64b9c4a6db254f23a580b7508fc34d7](https://www.blocktrail.com/BTC/tx/e2029990fa75e9fc642f149dad196ac6b64b9c4a6db254f23a580b7508fc34d7) |
|
||||
|
|
||||
`OP_RETURN` wire format: |
|
||||
``` |
|
||||
0 2 3 19 39 |
|
||||
|-----|--|-----------------------------------|-----------------------| |
|
||||
magic op hash128(name.ns_id,consensus hash) zone file hash |
|
||||
``` |
|
||||
|
|
||||
Note that `hash128(name.ns_id, consensus hash)` is the first 16 bytes of a SHA256 hash over the name concatenated to the hexadecimal string of the consensus hash (not the bytes corresponding to that hex string). |
|
||||
See the [Method Glossary](#method-glossary) below. |
|
||||
|
|
||||
Example: `hash128("jude.id" + "8d8762c37d82360b84cf4d87f32f7754") == "d1062edb9ec9c85ad1aca6d37f2f5793"`. |
|
||||
|
|
||||
The 20 byte zone file hash is computed from zone file data by using `ripemd160(sha56(zone file data))` |
|
||||
|
|
||||
Inputs: |
|
||||
* owner `scriptSig` |
|
||||
* payment `scriptSig`'s |
|
||||
|
|
||||
Outputs: |
|
||||
* `OP_RETURN` payload |
|
||||
* owner's `scriptPubkey` |
|
||||
* payment `scriptPubkey` change |
|
||||
|
|
||||
### NAME_TRANSFER |
|
||||
|
|
||||
Op: `>` |
|
||||
|
|
||||
Description: This transaction changes the public key hash that owns the name in |
|
||||
BNS. |
|
||||
|
|
||||
Example: [7a0a3bb7d39b89c3638abc369c85b5c028d0a55d7804ba1953ff19b0125f3c24](https://www.blocktrail.com/BTC/tx/7a0a3bb7d39b89c3638abc369c85b5c028d0a55d7804ba1953ff19b0125f3c24) |
|
||||
|
|
||||
`OP_RETURN` wire format: |
|
||||
``` |
|
||||
0 2 3 4 20 36 |
|
||||
|-----|--|----|-------------------|---------------| |
|
||||
magic op keep hash128(name.ns_id) consensus hash |
|
||||
data? |
|
||||
``` |
|
||||
|
|
||||
Inputs: |
|
||||
|
|
||||
* Owner `scriptSig` |
|
||||
* Payment `scriptSig`'s |
|
||||
|
|
||||
Outputs: |
|
||||
|
|
||||
* `OP_RETURN` payload |
|
||||
* new name owner's `scriptPubkey` |
|
||||
* old name owner's `scriptPubkey` |
|
||||
* payment `scriptPubkey` change |
|
||||
|
|
||||
Notes: |
|
||||
|
|
||||
* The `keep data?` byte controls whether or not the name's 20-byte value is preserved. This value is either `>` to preserve it, or `~` to delete it. |
|
||||
|
|
||||
### NAME_REVOKE |
|
||||
|
|
||||
Op: `~` |
|
||||
|
|
||||
Description: This transaction destroys a registered name. Its name state value |
|
||||
in BNS will be cleared, and no further transactions will be able to affect the |
|
||||
name until it expires (if its namespace allows it to expire at all). |
|
||||
|
|
||||
Example: [eb2e84a45cf411e528185a98cd5fb45ed349843a83d39fd4dff2de47adad8c8f](https://www.blocktrail.com/BTC/tx/eb2e84a45cf411e528185a98cd5fb45ed349843a83d39fd4dff2de47adad8c8f) |
|
||||
|
|
||||
`OP_RETURN` wire format: |
|
||||
``` |
|
||||
0 2 3 39 |
|
||||
|----|--|-----------------------------| |
|
||||
magic op name.ns_id (37 bytes) |
|
||||
``` |
|
||||
|
|
||||
Inputs: |
|
||||
|
|
||||
* owner `scriptSig` |
|
||||
* payment `scriptSig`'s |
|
||||
|
|
||||
Outputs: |
|
||||
|
|
||||
* `OP_RETURN` payload |
|
||||
* owner `scriptPubkey` |
|
||||
* payment `scriptPubkey` change |
|
||||
|
|
||||
### ANNOUNCE |
|
||||
|
|
||||
Op: `#` |
|
||||
|
|
||||
Description: This transaction does not affect any names in BNS, but it allows a |
|
||||
user to send a message to other BNS nodes. In order for the message to be |
|
||||
received, the following must be true: |
|
||||
|
|
||||
* The sender must have a BNS name |
|
||||
* The BNS nodes must list the sender's BNS name as being a "trusted message |
|
||||
sender" |
|
||||
* The message must have already been propagated through the [Atlas |
|
||||
network]({{ site.baseurl }}/core/atlas/overview.html). This transaction references it by content hash. |
|
||||
|
|
||||
`OP_RETURN` wire format: |
|
||||
|
|
||||
``` |
|
||||
0 2 3 23 |
|
||||
|----|--|-----------------------------| |
|
||||
magic op ripemd160(sha256(message)) |
|
||||
``` |
|
||||
|
|
||||
Inputs: |
|
||||
|
|
||||
* The payer `scriptSig`'s |
|
||||
|
|
||||
Outputs: |
|
||||
|
|
||||
* `OP_RETURN` payload |
|
||||
* change `scriptPubKey` |
|
||||
|
|
||||
Notes: |
|
||||
|
|
||||
* The payer key should be an owner key for an existing name, since Blockstack users can subscribe to announcements from specific name-owners. |
|
||||
|
|
||||
### NAMESPACE_PREORDER |
|
||||
|
|
||||
Op: `*` |
|
||||
|
|
||||
Description: This transaction announces the *hash* of a new namespace. It is the |
|
||||
first of three transactions that must be sent to create a namespace. |
|
||||
|
|
||||
Example: [5f00b8e609821edd6f3369ee4ee86e03ea34b890e242236cdb66ef6c9c6a1b28](https://www.blocktrail.com/BTC/tx/5f00b8e609821edd6f3369ee4ee86e03ea34b890e242236cdb66ef6c9c6a1b28) |
|
||||
|
|
||||
`OP_RETURN` wire format: |
|
||||
``` |
|
||||
0 2 3 23 39 |
|
||||
|-----|---|-----------------------------------------|----------------| |
|
||||
magic op hash_name(ns_id,script_pubkey,reveal_addr) consensus hash |
|
||||
``` |
|
||||
|
|
||||
Inputs: |
|
||||
|
|
||||
* Namespace payer `scriptSig` |
|
||||
|
|
||||
Outputs: |
|
||||
|
|
||||
* `OP_RETURN` payload |
|
||||
* Namespace payer `scriptPubkey` change address |
|
||||
* `p2pkh` script to the burn address `1111111111111111111114oLvT2`, whose public key hash is 0x00000000000000000000000000000000 |
|
||||
|
|
||||
Notes: |
|
||||
|
|
||||
* The `reveal_addr` field is the address of the namespace revealer public key. The revealer private key will be used to generate `NAME_IMPORT` transactions. |
|
||||
|
|
||||
### NAMESPACE_REVEAL |
|
||||
|
|
||||
Op: `&` |
|
||||
|
|
||||
Description: This transaction reveals the namespace ID and namespace rules |
|
||||
for a previously-anounced namespace hash (sent by a previous `NAMESPACE_PREORDER`). |
|
||||
|
|
||||
Example: [ab54b1c1dd5332dc86b24ca2f88b8ca0068485edf0c322416d104c5b84133a32](https://www.blocktrail.com/BTC/tx/ab54b1c1dd5332dc86b24ca2f88b8ca0068485edf0c322416d104c5b84133a32) |
|
||||
|
|
||||
`OP_RETURN` wire format: |
|
||||
``` |
|
||||
0 2 3 7 8 9 10 11 12 13 14 15 16 17 18 20 39 |
|
||||
|-----|---|--------|-----|-----|----|----|----|----|----|-----|-----|-----|--------|----------|-------------------------| |
|
||||
magic op life coeff. base 1-2 3-4 5-6 7-8 9-10 11-12 13-14 15-16 nonalpha version namespace ID |
|
||||
bucket exponents no-vowel |
|
||||
discounts |
|
||||
``` |
|
||||
|
|
||||
Inputs: |
|
||||
|
|
||||
* Namespace payer `scriptSig`s |
|
||||
|
|
||||
Outputs: |
|
||||
|
|
||||
* `OP_RETURN` payload |
|
||||
* namespace revealer `scriptPubkey` |
|
||||
* namespace payer change `scriptPubkey` |
|
||||
|
|
||||
Notes: |
|
||||
|
|
||||
* This transaction must be sent within 1 day of the `NAMESPACE_PREORDER` |
|
||||
* The second output (with the namespace revealer) **must** be a `p2pkh` script |
|
||||
* The address of the second output **must** be the `reveal_addr` in the `NAMESPACE_PREORDER` |
|
||||
|
|
||||
Pricing: |
|
||||
|
|
||||
The rules for a namespace are as follows: |
|
||||
|
|
||||
* a name can fall into one of 16 buckets, measured by length. Bucket 16 incorporates all names at least 16 characters long. |
|
||||
* the pricing structure applies a multiplicative penalty for having numeric characters, or punctuation characters. |
|
||||
* the price of a name in a bucket is ((coeff) * (base) ^ (bucket exponent)) / ((numeric discount multiplier) * (punctuation discount multiplier)) |
|
||||
|
|
||||
Example: |
|
||||
* base = 10 |
|
||||
* coeff = 2 |
|
||||
* nonalpha discount: 10 |
|
||||
* no-vowel discount: 10 |
|
||||
* buckets 1, 2: 9 |
|
||||
* buckets 3, 4, 5, 6: 8 |
|
||||
* buckets 7, 8, 9, 10, 11, 12, 13, 14: 7 |
|
||||
* buckets 15, 16+: |
|
||||
|
|
||||
With the above example configuration, the following are true: |
|
||||
|
|
||||
* The price of "john" would be 2 * 10^8, since "john" falls into bucket 4 and has no punctuation or numerics. |
|
||||
* The price of "john1" would be 2 * 10^6, since "john1" falls into bucket 5 but has a number (and thus receives a 10x discount) |
|
||||
* The price of "john_1" would be 2 * 10^6, since "john_1" falls into bucket 6 but has a number and punctuation (and thus receives a 10x discount) |
|
||||
* The price of "j0hn_1" would be 2 * 10^5, since "j0hn_1" falls into bucket 6 but has a number and punctuation and lacks vowels (and thus receives a 100x discount) |
|
||||
|
|
||||
|
|
||||
### NAME_IMPORT |
|
||||
|
|
||||
Op: `;` |
|
||||
|
|
||||
Description: This transaction registers a name and some name state into a |
|
||||
namespace that has been revealed, but not been launched. Only the namespace |
|
||||
creator can import names. See the [namespace creation section]({{ site.baseurl }}/core/naming/namespace.html) for details. |
|
||||
|
|
||||
Example: [c698ac4b4a61c90b2c93dababde867dea359f971e2efcf415c37c9a4d9c4f312](https://www.blocktrail.com/BTC/tx/c698ac4b4a61c90b2c93dababde867dea359f971e2efcf415c37c9a4d9c4f312) |
|
||||
|
|
||||
`OP_RETURN` wire format: |
|
||||
``` |
|
||||
0 2 3 39 |
|
||||
|----|--|-----------------------------| |
|
||||
magic op name.ns_id (37 bytes) |
|
||||
``` |
|
||||
|
|
||||
Inputs: |
|
||||
|
|
||||
* The namespace reveal `scriptSig` (with the namespace revealer's public key), or one of its first 300 extended public keys |
|
||||
* Any payment inputs |
|
||||
|
|
||||
Outputs: |
|
||||
|
|
||||
* `OP_RETURN` payload |
|
||||
* recipient `scriptPubKey` |
|
||||
* zone file hash (using the 20-byte hash in a standard `p2pkh` script) |
|
||||
* payment change `scriptPubKey` |
|
||||
|
|
||||
Notes: |
|
||||
|
|
||||
* These transactions can only be sent between the `NAMESPACE_REVEAL` and `NAMESPACE_READY`. |
|
||||
* The first `NAME_IMPORT` transaction **must** have a `scriptSig` input that matches the `NAMESPACE_REVEAL`'s second output (i.e. the reveal output). |
|
||||
* Any subsequent `NAME_IMPORT` transactions **may** have a `scriptSig` input whose public key is one of the first 300 extended public keys from the `NAMESPACE_REVEAL`'s `scriptSig` public key. |
|
||||
|
|
||||
### NAMESPACE_READY |
|
||||
|
|
||||
Op: `!` |
|
||||
|
|
||||
Description: This transaction launches a namesapce. Only the namespace creator |
|
||||
can send this transaction. Once sent, anyone can register names in the |
|
||||
namespace. |
|
||||
|
|
||||
Example: [2bf9a97e3081886f96c4def36d99a677059fafdbd6bdb6d626c0608a1e286032](https://www.blocktrail.com/BTC/tx/2bf9a97e3081886f96c4def36d99a677059fafdbd6bdb6d626c0608a1e286032) |
|
||||
|
|
||||
`OP_RETURN` wire format: |
|
||||
``` |
|
||||
|
|
||||
0 2 3 4 23 |
|
||||
|-----|--|--|------------| |
|
||||
magic op . ns_id |
|
||||
``` |
|
||||
|
|
||||
Inputs: |
|
||||
* Namespace revealer's `scriptSig`s |
|
||||
|
|
||||
Outputs: |
|
||||
* `OP_RETURN` payload |
|
||||
* Change output to the namespace revealer's `p2pkh` script |
|
||||
|
|
||||
Notes: |
|
||||
* This transaction must be sent within 1 year of the corresponding `NAMESPACE_REVEAL` to be accepted. |
|
||||
|
|
||||
## Method Glossary |
|
||||
|
|
||||
Some hashing primitives are used to construct the wire-format representation of each name operation. They are enumerated here: |
|
||||
|
|
||||
``` |
|
||||
B40_REGEX = '^[a-z0-9\-_.+]*$' |
|
||||
|
|
||||
def is_b40(s): |
|
||||
return isinstance(s, str) and re.match(B40_REGEX, s) is not None |
|
||||
|
|
||||
def b40_to_bin(s): |
|
||||
if not is_b40(s): |
|
||||
raise ValueError('{} must only contain characters in the b40 char set'.format(s)) |
|
||||
return unhexlify(charset_to_hex(s, B40_CHARS)) |
|
||||
|
|
||||
def hexpad(x): |
|
||||
return ('0' * (len(x) % 2)) + x |
|
||||
|
|
||||
def charset_to_hex(s, original_charset): |
|
||||
return hexpad(change_charset(s, original_charset, B16_CHARS)) |
|
||||
|
|
||||
def bin_hash160(s, hex_format=False): |
|
||||
""" s is in hex or binary format |
|
||||
""" |
|
||||
if hex_format and is_hex(s): |
|
||||
s = unhexlify(s) |
|
||||
return hashlib.new('ripemd160', bin_sha256(s)).digest() |
|
||||
|
|
||||
def hex_hash160(s, hex_format=False): |
|
||||
""" s is in hex or binary format |
|
||||
""" |
|
||||
if hex_format and is_hex(s): |
|
||||
s = unhexlify(s) |
|
||||
return hexlify(bin_hash160(s)) |
|
||||
|
|
||||
def hash_name(name, script_pubkey, register_addr=None): |
|
||||
""" |
|
||||
Generate the hash over a name and hex-string script pubkey. |
|
||||
Returns the hex-encoded string RIPEMD160(SHA256(x)), where |
|
||||
x is the byte string composed of the concatenation of the |
|
||||
binary |
|
||||
""" |
|
||||
bin_name = b40_to_bin(name) |
|
||||
name_and_pubkey = bin_name + unhexlify(script_pubkey) |
|
||||
|
|
||||
if register_addr is not None: |
|
||||
name_and_pubkey += str(register_addr) |
|
||||
|
|
||||
# make hex-encoded hash |
|
||||
return hex_hash160(name_and_pubkey) |
|
||||
|
|
||||
def hash128(data): |
|
||||
""" |
|
||||
Hash a string of data by taking its 256-bit sha256 and truncating it to the |
|
||||
first 16 bytes |
|
||||
""" |
|
||||
return hexlify(bin_sha256(data)[0:16]) |
|
||||
``` |
|
||||
@ -1,145 +0,0 @@ |
|||||
--- |
|
||||
layout: core |
|
||||
permalink: /:collection/:path.html |
|
||||
--- |
|
||||
# Blockstack Naming Service (BNS) |
|
||||
{:.no_toc} |
|
||||
|
|
||||
This document gives an overview of how the Blockstack Naming Service work. This |
|
||||
section introduces you to BNS and explains the following concepts: |
|
||||
|
|
||||
* TOC |
|
||||
{:toc} |
|
||||
|
|
||||
The ([Blockstack Core](https://github.com/blockstack/blockstack-core)) |
|
||||
repository is the reference implementation of the Blockstack Naming Service. |
|
||||
|
|
||||
|
|
||||
## What is BNS |
|
||||
|
|
||||
The Blockstack Naming Service (BNS) is a network system that binds names |
|
||||
to off-chain state without relying on any central points of control. |
|
||||
It does so by embedding a log of its control-plane messages within a public blockchain, like Bitcoin. |
|
||||
|
|
||||
Each BNS peer determines the state of each name by indexing these specially-crafted |
|
||||
transactions. In doing so, each peer independently calculates the same global |
|
||||
name state. |
|
||||
|
|
||||
Names in BNS have three properties: |
|
||||
|
|
||||
* **Names are globally unique.** The protocol does not allow name collisions, and all |
|
||||
well-behaved nodes resolve a given name to the same state. |
|
||||
* **Names are human-meaningful.** Each name is chosen by its creator. |
|
||||
* **Names are strongly-owned.** Only the name's owner can change the state it |
|
||||
resolves to. Specifically, a name is owned by one or more ECDSA private keys. |
|
||||
|
|
||||
Internally, a BNS node implements a replicated name database. Each BNS node keeps itself |
|
||||
synchronized to all of the other ones in the world, so queries on one BNS node |
|
||||
will be the same on other nodes. BNS nodes allow a name's owner to bind |
|
||||
up to 40Kb of off-chain state to their name, which will be replicated to all |
|
||||
BNS nodes via the [Atlas network]({{ site.baseurl }}/core/atlas/overview.html). |
|
||||
|
|
||||
BNS nodes extract the name database log from an underlying blockchain (Blockstack |
|
||||
Core currently uses Bitcoin, and had used Namecoin in the past). |
|
||||
BNS uses the blockchain to establish a shared "ground truth" for the system: as long as |
|
||||
two nodes have the same view of the blockchain, then they will build up the same |
|
||||
database. |
|
||||
|
|
||||
The biggest consequence for developers is that in BNS, reading name state is |
|
||||
fast and cheap but writing name state is slow and expensive. This is because |
|
||||
registering and modifying names requires one or more transactions to be sent to |
|
||||
the underlying blockchain, and BNS nodes will not process them until they are |
|
||||
sufficiently confirmed. Users and developers need to acquire and spend |
|
||||
the requisite cryptocurrency (i.e. Bitcoin) to send BNS transactions. |
|
||||
|
|
||||
## Motivation behind naming services |
|
||||
|
|
||||
We rely on naming systems in everyday life, and they play a critical |
|
||||
role in many different applications. For example, when you look up a |
|
||||
friend on social media, you are using the platform's naming service to resolve |
|
||||
their name to their profile. When you look up a website, you are using the |
|
||||
Domain Name Service to |
|
||||
resolve the hostname to its host's IP address. When you check out a Git branch, you |
|
||||
are using your Git client to resolve the branch name to a commit hash. |
|
||||
When you look up someone's PGP key on a keyserver, you are resolving |
|
||||
their key ID to their public key. |
|
||||
|
|
||||
What kinds of things do we want to be true about names? In BNS, names are |
|
||||
globally unique, names are human-meaningful, and names are strongly-owned. |
|
||||
However, if you look at these examples, you'll see that each of them only |
|
||||
guarantees *two* of these properties. This limits how useful they can be. |
|
||||
|
|
||||
* In DNS and social media, names are globally unique and human-readable, but not |
|
||||
strongly-owned. The system operator has the |
|
||||
final say as to what each names resolves to. |
|
||||
* **Problem**: Clients must trust the system to make the right |
|
||||
choice in what a given name resolves to. This includes trusting that |
|
||||
no one but the system administrators can make these changes. |
|
||||
|
|
||||
* In Git, branch names are human-meaningful |
|
||||
and strongly-owned, but not globally unique. Two different Git nodes may resolve the same |
|
||||
branch name to different unrelated repository states. |
|
||||
* **Problem**: Since names can refer to conflicting state, developers |
|
||||
have to figure out some other mechanism to resolve ambiguities. In Git's |
|
||||
case, the user has to manually intervene. |
|
||||
|
|
||||
* In PGP, names are key IDs. They are |
|
||||
are globally unique and cryptographically owned, but not human-readable. PGP |
|
||||
key IDs are derived from the keys they reference. |
|
||||
* **Problem**: These names are difficult for most users to |
|
||||
remember since they do not carry semantic information relating to their use in the system. |
|
||||
|
|
||||
BNS names have all three properties, and none of these problems. This makes it a |
|
||||
powerful tool for building all kinds of network applications. With BNS, we |
|
||||
can do the following and more: |
|
||||
|
|
||||
* Build domain name services where hostnames can't be hijacked. |
|
||||
* Build social media platforms where user names can't be stolen by phishers. |
|
||||
* Build version control systems where repository branches do not conflict. |
|
||||
* Build public-key infrastructure where it's easy for users to discover and |
|
||||
remember each other's keys. |
|
||||
|
|
||||
|
|
||||
# Organization of BNS |
|
||||
|
|
||||
BNS names are organized into a global name hierarchy. There are three different |
|
||||
layers in this hierarchy related to naming: |
|
||||
|
|
||||
* **Namespaces**. These are the top-level names in the hierarchy. An analogy |
|
||||
to BNS namespaces are DNS top-level domains. Existing BNS namespaces include |
|
||||
`.id`, `.podcast`, and `.helloworld`. All other names belong to exactly one |
|
||||
namespace. Anyone can create a namespace, but in order for the namespace |
|
||||
to be persisted, it must be *launched* so that anyone can register names in it. |
|
||||
Namespaces are not owned by their creators. |
|
||||
|
|
||||
* **BNS names**. These are names whose records are stored directly on the |
|
||||
blockchain. The ownership and state of these names are controlled by sending |
|
||||
blockchain transactions. Example names include `verified.podcast` and |
|
||||
`muneeb.id`. Anyone can create a BNS name, as long as the namespace that |
|
||||
contains it exists already. The state for BNS names is usually stored in the [Atlas |
|
||||
network]({{ site.baseurl }}/core/atlas/overview.html). |
|
||||
|
|
||||
* **BNS subdomains**. These are names whose records are stored off-chain, |
|
||||
but are collectively anchored to the blockchain. The ownership and state for |
|
||||
these names lives within the [Atlas network]({{ site.baseurl }}/core/atlas/overview.html). While BNS |
|
||||
subdomains are owned by separate private keys, a BNS name owner must |
|
||||
broadcast their subdomain state. Example subdomains include `jude.personal.id` |
|
||||
and `podsaveamerica.verified.podcast`. Unlike BNS namespaces and names, the |
|
||||
state of BNS subdomains is *not* part of the blockchain consensus rules. |
|
||||
|
|
||||
A feature comparison matrix summarizing the similarities and differences |
|
||||
between these name objects is presented below: |
|
||||
|
|
||||
| Feature | **Namespaces** | **BNS names** | **BNS Subdomains** | |
|
||||
|---------|----------------|---------------|--------------------| |
|
||||
| Globally unique | X | X | X | |
|
||||
| Human-meaningful | X | X | X | |
|
||||
| Owned by a private key | | X | X | |
|
||||
| Anyone can create | X | X | [1] | |
|
||||
| Owner can update | | X | [1] | |
|
||||
| State hosted on-chain | X | X | | |
|
||||
| State hosted off-chain | | X | X | |
|
||||
| Behavior controlled by consensus rules | X | X | | |
|
||||
| May have an expiration date | | X | | |
|
||||
|
|
||||
[1] Requires the cooperation of a BNS name owner to broadcast its transactions |
|
||||
@ -1,36 +0,0 @@ |
|||||
doctype |
|
||||
|
|
||||
include mixins.jade |
|
||||
|
|
||||
html |
|
||||
head |
|
||||
meta(charset="utf-8") |
|
||||
title= self.api.name || 'API Documentation' |
|
||||
link(rel="stylesheet", href="https://maxcdn.bootstrapcdn.com/font-awesome/4.3.0/css/font-awesome.min.css") |
|
||||
style!= self.css |
|
||||
body.preload |
|
||||
#nav-background |
|
||||
div.container-fluid.triple |
|
||||
.row |
|
||||
block nav |
|
||||
+Nav(false) |
|
||||
|
|
||||
.content |
|
||||
#right-panel-background |
|
||||
|
|
||||
block content |
|
||||
+ContentTriple(false) |
|
||||
|
|
||||
.middle |
|
||||
p.text-muted(style="text-align: center;") |
|
||||
|
|
||||
script: include scripts.js |
|
||||
|
|
||||
if self.livePreview |
|
||||
script(src="/socket.io/socket.io.js") |
|
||||
script. |
|
||||
var socket = io(); |
|
||||
socket.on('refresh', refresh); |
|
||||
socket.on('reconnect', function () { |
|
||||
socket.emit('request-refresh'); |
|
||||
}); |
|
||||
File diff suppressed because it is too large
@ -1,114 +0,0 @@ |
|||||
# Install Script |
|
||||
|
|
||||
We provide a [script](../images/scripts/ubuntu-17.04.sh) which will |
|
||||
perform all the steps outlined in this doc (except for creating a protocol handler -- see the bottom of the doc). The script creates a virtualenv of |
|
||||
Blockstack Core and installs Browser in a subdirectory. It additionally creates some |
|
||||
scripts for starting Core and Browser together. |
|
||||
|
|
||||
However, if you'd like to customize your install, step through it |
|
||||
yourself, or you are on a different distro, continue on with this doc! |
|
||||
|
|
||||
# Setting up Blockstack Core API Service |
|
||||
|
|
||||
Install required binaries in Ubuntu: |
|
||||
|
|
||||
``` |
|
||||
sudo apt update && sudo apt-get install -y python-pip python-dev libssl-dev libffi-dev rng-tools curl build-essential |
|
||||
``` |
|
||||
|
|
||||
|
|
||||
If you'd like to use a virtualenv to install Blockstack, you can do that |
|
||||
|
|
||||
``` |
|
||||
pip install virtualenv |
|
||||
virtualenv --python=python2.7 ~/.blockstack.venv/ && source ~/.blockstack.venv/bin/activate |
|
||||
``` |
|
||||
|
|
||||
Let's install virtualchain 0.14.3 and blockstack 0.14.3 |
|
||||
|
|
||||
``` |
|
||||
sudo apt install git |
|
||||
pip install git+https://github.com/blockstack/virtualchain.git@rc-0.14.3 |
|
||||
pip install git+https://github.com/blockstack/blockstack-core.git@rc-0.14.3 |
|
||||
``` |
|
||||
|
|
||||
Get Blockstack core configured with default settings and choose your Bitcoin wallet password |
|
||||
``` |
|
||||
blockstack setup -y --password BITCOIN_WALLET_PASSWORD --debug |
|
||||
``` |
|
||||
|
|
||||
# Setting up Blockstack Browser Node Application |
|
||||
|
|
||||
Install NodeJS through NodeSource PPA |
|
||||
|
|
||||
``` |
|
||||
curl -sL https://deb.nodesource.com/setup_7.x | sudo -E bash - |
|
||||
sudo apt install -y nodejs |
|
||||
``` |
|
||||
|
|
||||
Download Blockstack Browser and install its dependencies |
|
||||
|
|
||||
``` |
|
||||
git clone https://github.com/blockstack/blockstack-browser.git -bv0.11.1 |
|
||||
cd blockstack-browser |
|
||||
npm install node-sass |
|
||||
npm install |
|
||||
``` |
|
||||
|
|
||||
Note that `blockstack-browser` depends on `node-sass` which can sometimes install strangely on Linux, running `npm install node-sass` before trying to install the other dependencies solves that problem. |
|
||||
|
|
||||
# Running Blockstack Browser |
|
||||
|
|
||||
Now we're ready to run our Core API service and start the Browser node app. |
|
||||
|
|
||||
First, start the Core API service. |
|
||||
|
|
||||
``` |
|
||||
blockstack api start -y --password BITCOIN_WALLET_PASSWORD --debug |
|
||||
``` |
|
||||
|
|
||||
Start the CORS proxy. |
|
||||
|
|
||||
``` |
|
||||
npm run dev-proxy & |
|
||||
``` |
|
||||
|
|
||||
Start the Node Application |
|
||||
|
|
||||
``` |
|
||||
npm run dev |
|
||||
``` |
|
||||
|
|
||||
Then you can open `http://localhost:3000/` in your browser to get to the Blockstack Browser. |
|
||||
|
|
||||
|
|
||||
You can copy your api password to your clipboard with this command: |
|
||||
``` |
|
||||
grep api_password ~/.blockstack/client.ini | sed 's/api_password = //g' | xclip -selection clipboard |
|
||||
``` |
|
||||
|
|
||||
## Setting up a protocol handler |
|
||||
|
|
||||
If you'd like your browser to automatically handle links with the `blockstack:` protocol specifier, you will need to register a protocol handler with your desktop environment. In Ubuntu/Gnome, this can be done by creating a file |
|
||||
|
|
||||
`~/.local/share/applications/blockstack.desktop` |
|
||||
|
|
||||
With the following contents: |
|
||||
|
|
||||
``` |
|
||||
[Desktop Entry] |
|
||||
Type=Application |
|
||||
Terminal=false |
|
||||
Exec=bash -c 'xdg-open http://localhost:3000/auth?authRequest=$(echo "%u" | sed s,blockstack:////*,,)' |
|
||||
Name=Blockstack-Browser |
|
||||
MimeType=x-scheme-handler/blockstack; |
|
||||
``` |
|
||||
|
|
||||
Then you need to make this file executable, and register it as a protocol handler. |
|
||||
|
|
||||
``` |
|
||||
$ chmod +x ~/.local/share/applications/blockstack.desktop |
|
||||
$ xdg-mime default blockstack.desktop x-scheme-handler/blockstack |
|
||||
``` |
|
||||
|
|
||||
Now, `blockstack:` protocol URLs should get handled by your Blockstack Browser. If you're running Browser in your browser's private mode, you may have to copy and paste the link, as this protocol handler will try to open in a regular browser window. |
|
||||
@ -1,223 +0,0 @@ |
|||||
/* eslint-env browser */ |
|
||||
/* eslint quotes: [2, "single"] */ |
|
||||
'use strict'; |
|
||||
|
|
||||
/* |
|
||||
Determine if a string ends with another string. |
|
||||
*/ |
|
||||
function endsWith(str, suffix) { |
|
||||
return str.indexOf(suffix, str.length - suffix.length) !== -1; |
|
||||
} |
|
||||
|
|
||||
/* |
|
||||
Get a list of direct child elements by class name. |
|
||||
*/ |
|
||||
function childrenByClass(element, name) { |
|
||||
var filtered = []; |
|
||||
|
|
||||
for (var i = 0; i < element.children.length; i++) { |
|
||||
var child = element.children[i]; |
|
||||
var classNames = child.className.split(' '); |
|
||||
if (classNames.indexOf(name) !== -1) { |
|
||||
filtered.push(child); |
|
||||
} |
|
||||
} |
|
||||
|
|
||||
return filtered; |
|
||||
} |
|
||||
|
|
||||
/* |
|
||||
Get an array [width, height] of the window. |
|
||||
*/ |
|
||||
function getWindowDimensions() { |
|
||||
var w = window, |
|
||||
d = document, |
|
||||
e = d.documentElement, |
|
||||
g = d.body, |
|
||||
x = w.innerWidth || e.clientWidth || g.clientWidth, |
|
||||
y = w.innerHeight || e.clientHeight || g.clientHeight; |
|
||||
|
|
||||
return [x, y]; |
|
||||
} |
|
||||
|
|
||||
/* |
|
||||
Collapse or show a request/response example. |
|
||||
*/ |
|
||||
function toggleCollapseButton(event) { |
|
||||
var button = event.target.parentNode; |
|
||||
var content = button.parentNode.nextSibling; |
|
||||
var inner = content.children[0]; |
|
||||
|
|
||||
if (button.className.indexOf('collapse-button') === -1) { |
|
||||
// Clicked without hitting the right element? |
|
||||
return; |
|
||||
} |
|
||||
|
|
||||
if (content.style.maxHeight && content.style.maxHeight !== '0px') { |
|
||||
// Currently showing, so let's hide it |
|
||||
button.className = 'collapse-button'; |
|
||||
content.style.maxHeight = '0px'; |
|
||||
} else { |
|
||||
// Currently hidden, so let's show it |
|
||||
button.className = 'collapse-button show'; |
|
||||
content.style.maxHeight = inner.offsetHeight + 12 + 'px'; |
|
||||
} |
|
||||
} |
|
||||
|
|
||||
function toggleTabButton(event) { |
|
||||
var i, index; |
|
||||
var button = event.target; |
|
||||
|
|
||||
// Get index of the current button. |
|
||||
var buttons = childrenByClass(button.parentNode, 'tab-button'); |
|
||||
for (i = 0; i < buttons.length; i++) { |
|
||||
if (buttons[i] === button) { |
|
||||
index = i; |
|
||||
button.className = 'tab-button active'; |
|
||||
} else { |
|
||||
buttons[i].className = 'tab-button'; |
|
||||
} |
|
||||
} |
|
||||
|
|
||||
// Hide other tabs and show this one. |
|
||||
var tabs = childrenByClass(button.parentNode.parentNode, 'tab'); |
|
||||
for (i = 0; i < tabs.length; i++) { |
|
||||
if (i === index) { |
|
||||
tabs[i].style.display = 'block'; |
|
||||
} else { |
|
||||
tabs[i].style.display = 'none'; |
|
||||
} |
|
||||
} |
|
||||
} |
|
||||
|
|
||||
/* |
|
||||
Collapse or show a navigation menu. It will not be hidden unless it |
|
||||
is currently selected or `force` has been passed. |
|
||||
*/ |
|
||||
function toggleCollapseNav(event, force) { |
|
||||
var heading = event.target.parentNode; |
|
||||
var content = heading.nextSibling; |
|
||||
var inner = content.children[0]; |
|
||||
|
|
||||
if (heading.className.indexOf('heading') === -1) { |
|
||||
// Clicked without hitting the right element? |
|
||||
return; |
|
||||
} |
|
||||
|
|
||||
if (content.style.maxHeight && content.style.maxHeight !== '0px') { |
|
||||
// Currently showing, so let's hide it, but only if this nav item |
|
||||
// is already selected. This prevents newly selected items from |
|
||||
// collapsing in an annoying fashion. |
|
||||
if (force || window.location.hash && endsWith(event.target.href, window.location.hash)) { |
|
||||
content.style.maxHeight = '0px'; |
|
||||
} |
|
||||
} else { |
|
||||
// Currently hidden, so let's show it |
|
||||
content.style.maxHeight = inner.offsetHeight + 12 + 'px'; |
|
||||
} |
|
||||
} |
|
||||
|
|
||||
/* |
|
||||
Refresh the page after a live update from the server. This only |
|
||||
works in live preview mode (using the `--server` parameter). |
|
||||
*/ |
|
||||
function refresh(body) { |
|
||||
document.querySelector('body').className = 'preload'; |
|
||||
document.body.innerHTML = body; |
|
||||
|
|
||||
// Re-initialize the page |
|
||||
init(); |
|
||||
autoCollapse(); |
|
||||
|
|
||||
document.querySelector('body').className = ''; |
|
||||
} |
|
||||
|
|
||||
/* |
|
||||
Determine which navigation items should be auto-collapsed to show as many |
|
||||
as possible on the screen, based on the current window height. This also |
|
||||
collapses them. |
|
||||
*/ |
|
||||
function autoCollapse() { |
|
||||
var windowHeight = getWindowDimensions()[1]; |
|
||||
var itemsHeight = 64; /* Account for some padding */ |
|
||||
var itemsArray = Array.prototype.slice.call( |
|
||||
document.querySelectorAll('nav .resource-group .heading')); |
|
||||
|
|
||||
// Get the total height of the navigation items |
|
||||
itemsArray.forEach(function (item) { |
|
||||
itemsHeight += item.parentNode.offsetHeight; |
|
||||
}); |
|
||||
|
|
||||
// Should we auto-collapse any nav items? Try to find the smallest item |
|
||||
// that can be collapsed to show all items on the screen. If not possible, |
|
||||
// then collapse the largest item and do it again. First, sort the items |
|
||||
// by height from smallest to largest. |
|
||||
var sortedItems = itemsArray.sort(function (a, b) { |
|
||||
return a.parentNode.offsetHeight - b.parentNode.offsetHeight; |
|
||||
}); |
|
||||
|
|
||||
while (sortedItems.length && itemsHeight > windowHeight) { |
|
||||
for (var i = 0; i < sortedItems.length; i++) { |
|
||||
// Will collapsing this item help? |
|
||||
var itemHeight = sortedItems[i].nextSibling.offsetHeight; |
|
||||
if ((itemsHeight - itemHeight <= windowHeight) || i === sortedItems.length - 1) { |
|
||||
// It will, so let's collapse it, remove its content height from |
|
||||
// our total and then remove it from our list of candidates |
|
||||
// that can be collapsed. |
|
||||
itemsHeight -= itemHeight; |
|
||||
toggleCollapseNav({target: sortedItems[i].children[0]}, true); |
|
||||
sortedItems.splice(i, 1); |
|
||||
break; |
|
||||
} |
|
||||
} |
|
||||
} |
|
||||
} |
|
||||
|
|
||||
/* |
|
||||
Initialize the interactive functionality of the page. |
|
||||
*/ |
|
||||
function init() { |
|
||||
var i, j; |
|
||||
|
|
||||
// Make collapse buttons clickable |
|
||||
var buttons = document.querySelectorAll('.collapse-button'); |
|
||||
for (i = 0; i < buttons.length; i++) { |
|
||||
buttons[i].onclick = toggleCollapseButton; |
|
||||
|
|
||||
// Show by default? Then toggle now. |
|
||||
if (buttons[i].className.indexOf('show') !== -1) { |
|
||||
toggleCollapseButton({target: buttons[i].children[0]}); |
|
||||
} |
|
||||
} |
|
||||
|
|
||||
var responseCodes = document.querySelectorAll('.example-names'); |
|
||||
for (i = 0; i < responseCodes.length; i++) { |
|
||||
var tabButtons = childrenByClass(responseCodes[i], 'tab-button'); |
|
||||
for (j = 0; j < tabButtons.length; j++) { |
|
||||
tabButtons[j].onclick = toggleTabButton; |
|
||||
|
|
||||
// Show by default? |
|
||||
if (j === 0) { |
|
||||
toggleTabButton({target: tabButtons[j]}); |
|
||||
} |
|
||||
} |
|
||||
} |
|
||||
|
|
||||
// Make nav items clickable to collapse/expand their content. |
|
||||
var navItems = document.querySelectorAll('nav .resource-group .heading'); |
|
||||
for (i = 0; i < navItems.length; i++) { |
|
||||
navItems[i].onclick = toggleCollapseNav; |
|
||||
|
|
||||
// Show all by default |
|
||||
toggleCollapseNav({target: navItems[i].children[0]}); |
|
||||
} |
|
||||
} |
|
||||
|
|
||||
// Initial call to set up buttons |
|
||||
init(); |
|
||||
|
|
||||
window.onload = function () { |
|
||||
autoCollapse(); |
|
||||
// Remove the `preload` class to enable animations |
|
||||
document.querySelector('body').className = ''; |
|
||||
}; |
|
||||
@ -1 +0,0 @@ |
|||||
The documentation has been moved to [docs.blockstack.org](https://docs.blockstack.org/), please update your bookmarks. |
|
||||
|
Before Width: | Height: | Size: 78 KiB |
@ -1,314 +0,0 @@ |
|||||
--- |
|
||||
layout: core |
|
||||
permalink: /:collection/:path.html |
|
||||
--- |
|
||||
# Subdomain Design and Implementation |
|
||||
|
|
||||
{:.no_toc} |
|
||||
|
|
||||
Subdomains allow us to provide names to end users cheaply (and quickly). This |
|
||||
tutorial explains you how to create, register, and run a subdomain register, it |
|
||||
contains the following sections: |
|
||||
|
|
||||
* TOC |
|
||||
{:toc} |
|
||||
|
|
||||
|
|
||||
## Strong subdomain ownership |
|
||||
|
|
||||
For those who are new to this concept, it's a model where domains can |
|
||||
permanently, cryptographically delegate subdomains to particular keys, |
|
||||
relinquishing their ability to revoke the names or change the name |
|
||||
resolution details. |
|
||||
|
|
||||
These names will be indicated with an `.`, e.g., `foo.bar.id` |
|
||||
|
|
||||
## Overall Design |
|
||||
|
|
||||
We can do this today with a special indexer & resolver endpoint and |
|
||||
without any changes to the core protocol. |
|
||||
|
|
||||
We can do this by having a zone file record for each subdomain *i* |
|
||||
containing the following information: |
|
||||
|
|
||||
1. An owner address *addr* |
|
||||
2. A sequence number *N* |
|
||||
3. A zonefile |
|
||||
4. A signature *S* of the above |
|
||||
|
|
||||
The signature *S_i* must be verifiable with the address in the |
|
||||
*(N-1)*th entry for subdomain *i*. |
|
||||
|
|
||||
## Zonefile Format |
|
||||
|
|
||||
For now, the resolver will use an *TXT* record per subdomain to define |
|
||||
this information. The entry name will be `$(subdomain)`. |
|
||||
|
|
||||
|
|
||||
We'll use the format of [RFC 1464](https://tools.ietf.org/html/rfc1464) |
|
||||
for the TXT entry. We'll have the following strings with identifiers: |
|
||||
|
|
||||
1. **parts** : this specifies the number of pieces that the |
|
||||
zonefile has been chopped into. TXT strings can only be 255 bytes, |
|
||||
so we chop up the zonefile. |
|
||||
2. **zf{n}**: part *n* of the zonefile, base64 encoded |
|
||||
3. **owner**: the owner address delegated to operate the subdomain |
|
||||
4. **seqn**: the sequence number |
|
||||
5. **sig**: signature of the above data. |
|
||||
|
|
||||
``` |
|
||||
$ORIGIN bar.id |
|
||||
$TTL 3600 |
|
||||
pubkey TXT "pubkey:data:0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000" |
|
||||
registrar URI 10 1 "bsreg://foo.com:8234" |
|
||||
aaron TXT "owner=33VvhhSQsYQyCVE2VzG3EHa9gfRCpboqHy" "seqn=0" "parts=1" "zf0=JE9SSUdJTiBhYXJvbgokVFRMIDM2MDAKbWFpbiBVUkkgMSAxICJwdWJrZXk6ZGF0YTowMzAyYWRlNTdlNjNiMzc1NDRmOGQ5Nzk4NjJhNDlkMDBkYmNlMDdmMjkzYmJlYjJhZWNmZTI5OTkxYTg3Mzk4YjgiCg==" |
|
||||
``` |
|
||||
|
|
||||
The `registrar` entry indicates how to contact the registrar service |
|
||||
for clients of the domain wishing to register or modify their entry. |
|
||||
|
|
||||
### Operations per Zonefile |
|
||||
|
|
||||
At 4kb zonefile size, we can only fit around 20 updates per zonefile. |
|
||||
|
|
||||
## Domain Operator Endpoint |
|
||||
|
|
||||
The directory `subdomain_registrar/` contains our code for running a |
|
||||
subdomain registrar. It can be executed by running: |
|
||||
|
|
||||
``` |
|
||||
$ blockstack-subdomain-registrar start foo.id |
|
||||
``` |
|
||||
|
|
||||
Here, `foo.id` is the domain for which subdomains will be associated. |
|
||||
|
|
||||
### Configuration and Registration Files |
|
||||
|
|
||||
Configuration of the subdomain registrar is done through `~/.blockstack_subdomains/config.ini` |
|
||||
|
|
||||
The sqlite database which stores the registrations is located alongside the config `~/.blockstack_subdomains/registrar.db`. |
|
||||
|
|
||||
You can change the location of the config file (and the database), by setting the environment variable `BLOCKSTACK_SUBDOMAIN_CONFIG` |
|
||||
|
|
||||
### Register Subdomain |
|
||||
|
|
||||
Subdomain registrations can be submitted to this endpoint using a REST |
|
||||
API. |
|
||||
|
|
||||
``` |
|
||||
POST /register |
|
||||
``` |
|
||||
|
|
||||
The schema for registration is: |
|
||||
|
|
||||
``` |
|
||||
{ |
|
||||
'type' : 'object', |
|
||||
'properties' : { |
|
||||
'name' : { |
|
||||
'type': 'string', |
|
||||
'pattern': '([a-z0-9\-_+]{3,36})$' |
|
||||
}, |
|
||||
'owner_address' : { |
|
||||
'type': 'string', |
|
||||
'pattern': schemas.OP_ADDRESS_PATTERN |
|
||||
}, |
|
||||
'zonefile' : { |
|
||||
'type' : 'string', |
|
||||
'maxLength' : blockstack_constants.RPC_MAX_ZONEFILE_LEN |
|
||||
} |
|
||||
}, |
|
||||
'required':[ |
|
||||
'name', 'owner_address', 'zonefile' |
|
||||
], |
|
||||
'additionalProperties' : True |
|
||||
} |
|
||||
``` |
|
||||
|
|
||||
The registrar will: |
|
||||
|
|
||||
1. Check if the subdomain `foo` exists already on the domain. |
|
||||
2. Add the subdomain to the queue. |
|
||||
|
|
||||
On success, this returns `202` and the message |
|
||||
|
|
||||
``` |
|
||||
{"status": "true", "message": "Subdomain registration queued."} |
|
||||
``` |
|
||||
|
|
||||
When the registrar wakes up to prepare a transaction, it packs the queued |
|
||||
registrations together and issues an `UPDATE`. |
|
||||
|
|
||||
|
|
||||
### Check subdomain registration status |
|
||||
|
|
||||
A user can check on the registration status of their name via querying the |
|
||||
registrar. |
|
||||
|
|
||||
This is an API call: |
|
||||
``` |
|
||||
GET /status/{subdomain} |
|
||||
``` |
|
||||
|
|
||||
The registrar checks if the subdomain has propagated (i.e., the |
|
||||
registration is completed), in which case the following is returned: |
|
||||
|
|
||||
``` |
|
||||
{"status": "Subdomain already propagated"} |
|
||||
``` |
|
||||
|
|
||||
Or, if the subdomain has already been submitted in a transaction: |
|
||||
|
|
||||
``` |
|
||||
{"status": "Your subdomain was registered in transaction 09a40d6ea362608c68da6e1ebeb3210367abf7aa39ece5fd57fd63d269336399 -- it should propagate on the network once it has 6 confirmations."} |
|
||||
``` |
|
||||
|
|
||||
If the subdomain still hasn't been submitted yet: |
|
||||
|
|
||||
``` |
|
||||
{"status": "Subdomain is queued for update and should be announced within the next few blocks."} |
|
||||
``` |
|
||||
|
|
||||
If an error occurred trying to submit the `UPDATE` transaction, this endpoint will return an error |
|
||||
message in the `"error"` key of a JSON object. |
|
||||
|
|
||||
### Updating Entries |
|
||||
|
|
||||
The subdomain registrar does not currently support updating subdomain entries. |
|
||||
|
|
||||
## Resolver Behavior |
|
||||
|
|
||||
When a lookup like `foo.bar.id` hits the resolver, the resolver will need to: |
|
||||
|
|
||||
1. Lookup the zonefile history of `bar.id` |
|
||||
2. Fetch all these zonefiles and filter by operations on `foo` |
|
||||
3. Verify that all `foo` operations are correct |
|
||||
4. Return the latest record for foo |
|
||||
5. Do a profile lookup for `foo.bar.id` by fetching the URLs in the entry. |
|
||||
*Note*, this spec does not define a priority order for fetching those URLs. |
|
||||
|
|
||||
### Supported Core / Resolver Endpoints |
|
||||
|
|
||||
Generally, domain endpoints are not aware of subdomains (only endpoints |
|
||||
aware of subdomains is `/v1/users/<foo.bar.tld>`, |
|
||||
`/v1/names/<foo.bar.tld>`, and `/v1/addresses/bitcoin/<foo.bar.tld>`) |
|
||||
The endpoints which *are* subdomain aware are marked as such in |
|
||||
[api-specs.md]. |
|
||||
|
|
||||
This means that search is *not* yet supported. |
|
||||
|
|
||||
The lookups work just like normal -- it returns the user's |
|
||||
profile object: |
|
||||
|
|
||||
``` |
|
||||
$ curl -H "Authorization: bearer blockstack_integration_test_api_password" -H "Origin: http://localhost:3000" http://localhost:16268/v1/users/bar.foo.id -v -s | python -m json.tool |
|
||||
* Trying 127.0.0.1... |
|
||||
* Connected to localhost (127.0.0.1) port 16268 (#0) |
|
||||
> GET /v1/users/bar.foo.id HTTP/1.1 |
|
||||
> Host: localhost:16268 |
|
||||
> User-Agent: curl/7.50.1 |
|
||||
> Accept: */* |
|
||||
> Authorization: bearer blockstack_integration_test_api_password |
|
||||
> Origin: http://localhost:3000 |
|
||||
> |
|
||||
* HTTP 1.0, assume close after body |
|
||||
< HTTP/1.0 200 OK |
|
||||
< Server: SimpleHTTP/0.6 Python/2.7.12+ |
|
||||
< Date: Thu, 03 Aug 2017 14:39:16 GMT |
|
||||
< content-type: application/json |
|
||||
< Access-Control-Allow-Origin: * |
|
||||
< |
|
||||
{ [66 bytes data] |
|
||||
* Closing connection 0 |
|
||||
{ |
|
||||
"bar": { |
|
||||
"@type": "Person", |
|
||||
"description": "Lorem Ipsum Bazorem" |
|
||||
} |
|
||||
} |
|
||||
``` |
|
||||
|
|
||||
Name info lookups are also supported (this should enable authenticating logins |
|
||||
with `blockstack.js`, but I will need to double check). |
|
||||
|
|
||||
``` |
|
||||
$ curl -H "Authorization: bearer XXXX" -H "Origin: http://localhost:3000" http://localhost:6270/v1/names/created_equal.self_evident_truth.id -s | python -m json.tool |
|
||||
{ |
|
||||
"address": "1AYddAnfHbw6bPNvnsQFFrEuUdhMhf2XG9", |
|
||||
"blockchain": "bitcoin", |
|
||||
"expire_block": -1, |
|
||||
"last_txid": "0bacfd5a3e0ec68723d5948d6c1a04ad0de1378c872d45fa2276ebbd7be230f7", |
|
||||
"satus": "registered_subdomain", |
|
||||
"zonefile_hash": "48fc1b351ce81cf0a9fd9b4eae7a3f80e93c0451", |
|
||||
"zonefile_txt": "$ORIGIN created_equal\n$TTL 3600\n_https._tcp URI 10 1 \"https://www.cs.princeton.edu/~ablankst/created_equal.json\"\n_file URI 10 1 \"file:///tmp/created_equal.json\"\n" |
|
||||
} |
|
||||
``` |
|
||||
|
|
||||
### Subdomain Caching |
|
||||
|
|
||||
A resolver *caches* a subdomain's state by keeping a database of all |
|
||||
the current subdomain records. This database is automatically updated |
|
||||
when a new zonefile for a particularly domain is seen by the resolver |
|
||||
(this is performed lazily). |
|
||||
|
|
||||
### Testing Subdomain Registrar and Resolution |
|
||||
|
|
||||
You can run a subdomain registrar and resolver with blockstack-core in |
|
||||
regtest mode as follows: |
|
||||
|
|
||||
```bash |
|
||||
IMAGE=$(docker run -dt -p 3000:3000 -p 6270:6270 -p 16269:16269 -p 18332:18332 -e BLOCKSTACK_TEST_CLIENT_RPC_PORT=6270 -e BLOCKSTACK_TEST_CLIENT_BIND=0.0.0.0 -e BLOCKSTACK_TEST_BITCOIND_ALLOWIP=172.17.0.0/16 quay.io/blockstack/integrationtests:master blockstack-test-scenario --interactive 2 blockstack_integration_tests.scenarios.browser_env) |
|
||||
``` |
|
||||
|
|
||||
Once you see `Test finished; doing checks` in that container's logs, the |
|
||||
registrar has started and is ready to accept requests. (We recommend |
|
||||
following the docker instructions below for running this test in |
|
||||
Docker, as it will fetch the source code for the registrar and set the |
|
||||
correct environment variables for it to run). |
|
||||
|
|
||||
Once this environment has started, you can issue a registration request from curl: |
|
||||
|
|
||||
``` |
|
||||
curl -X POST -H 'Content-Type: application/json' --data '{"zonefile": "$ORIGIN baz\n$TTL 3600\n_file URI 10 1 \"file:///tmp/baz.profile.json\"\n", "name": "baz", "owner_address": "14x2EMRz1gf16UzGbxZh2c6sJg4A8wcHLD"}' http://localhost:3000/register/ |
|
||||
``` |
|
||||
|
|
||||
This registers `baz.foo.id` -- you can check the registrar's status with |
|
||||
|
|
||||
``` |
|
||||
curl http://localhost:3000/status/baz |
|
||||
``` |
|
||||
|
|
||||
The API endpoints `/v1/users/<foo.bar.tld>`, |
|
||||
`/v1/names/<foo.bar.tld>`, and `/v1/addresses/bitcoin/<foo.bar.tld>` all work, so if you query the core API, you'll get a response. |
|
||||
|
|
||||
For example: |
|
||||
|
|
||||
``` |
|
||||
curl http://localhost:6270/v1/names/baz.foo.id | python -m json.tool |
|
||||
``` |
|
||||
|
|
||||
Will return: |
|
||||
``` |
|
||||
{ |
|
||||
"address": "1Nup2UcbVuVoDZeZCtR4vjSkrvTi8toTqc", |
|
||||
"blockchain": "bitcoin", |
|
||||
"expire_block": -1, |
|
||||
"last_txid": "43bbcbd8793cdc52f1b0bd2713ed136f4f104a683a9fd5c89911a57a8c4b28b6", |
|
||||
"satus": "registered_subdomain", |
|
||||
"zonefile_hash": "e7e3aada18c9ac5189f1c54089e987f58c0fa51e", |
|
||||
"zonefile_txt": "$ORIGIN bar\n$TTL 3600\n_file URI 10 1 \"file:///tmp/baz.profile.json\"\n" |
|
||||
} |
|
||||
``` |
|
||||
|
|
||||
### Running an interactive testing environment with the Subdomain Registrar service |
|
||||
|
|
||||
Follow the [instructions here](https://github.com/blockstack/blockstack-core/blob/master/integration_tests/README.md) to download the regtesting Docker image. |
|
||||
|
|
||||
Since the subdomain registrar service runs on port 3000, we need to do two things to expose this endpoint to interact with it from the browser: |
|
||||
- Open port 3000 with `-p 3000:3000` |
|
||||
|
|
||||
Here's the full command you'd run to start the interactive testing scenario: |
|
||||
|
|
||||
```bash |
|
||||
IMAGE=$(docker run -dt -p 3000:3000 -p 6270:6270 -p 16269:16269 -p 18332:18332 -e BLOCKSTACK_TEST_CLIENT_RPC_PORT=6270 -e BLOCKSTACK_TEST_CLIENT_BIND=0.0.0.0 -e BLOCKSTACK_TEST_BITCOIND_ALLOWIP=172.17.0.0/16 quay.io/blockstack/integrationtests:master blockstack-test-scenario --interactive 2 blockstack_integration_tests.scenarios.browser_env) |
|
||||
``` |
|
||||
@ -1,143 +0,0 @@ |
|||||
--- |
|
||||
layout: learn |
|
||||
permalink: /:collection/:path.html |
|
||||
--- |
|
||||
# Developer FAQs |
|
||||
{:.no_toc} |
|
||||
|
|
||||
These FAQs are intended for developers of Blockstack. |
|
||||
|
|
||||
* TOC |
|
||||
{:toc} |
|
||||
|
|
||||
|
|
||||
## I'm a Web developer. Can I build on Blockstack? |
|
||||
|
|
||||
Yes! Blockstack is geared primarily towards Web developers. All of your |
|
||||
existing knowledge is immediately applicable to Blockstack. Anything you can do |
|
||||
in a Web browser, you can do in a Blockstack app. |
|
||||
|
|
||||
## I'm a non-Web developer. Can I build on Blockstack? |
|
||||
|
|
||||
Yes! Blockstack implements a [RESTful API](https://core.blockstack.org) which |
|
||||
lets you interact with Blockstack from any language and any runtime. In fact, |
|
||||
the reference client |
|
||||
([blockstack.js](https://github.com/blockstack/blockstack.js)) is mainly a |
|
||||
wrapper around these RESTful API calls, so you won't be missing much by using a |
|
||||
language other than Javascript. |
|
||||
|
|
||||
## What's the difference between a Web app and a Blockstack app? |
|
||||
|
|
||||
Blockstack apps are built like [single-page Web |
|
||||
apps](https://en.wikipedia.org/wiki/Single-page_application)---they are, in |
|
||||
fact, a type of Web application. |
|
||||
|
|
||||
Blockstack apps are a subset of Web applications that use Blockstack's |
|
||||
technology to preserve the user's control over their identities and data. |
|
||||
As such, they tend to be simpler |
|
||||
in design and operation, since in many cases they don't have to host anything |
|
||||
besides the application's assets. |
|
||||
|
|
||||
## Do I need to learn any new languages or frameworks? |
|
||||
|
|
||||
No. Blockstack applications are built using existing Web frameworks and programming |
|
||||
The only new thing you need to learn is either [blockstack.js](https://github.com/blockstack/blockstack.js) or |
|
||||
the [Blockstack RESTful API](https://core.blockstack.org). |
|
||||
|
|
||||
## How does my Web app interact with Blockstack? |
|
||||
|
|
||||
The [blockstack.js](https://github.com/blockstack/blockstack.js) library gives |
|
||||
any Web application the ability to interact with Blockstack's authentication and |
|
||||
storage services. In addition, we supply a [public RESTful API](https://core.blockstack.org). |
|
||||
|
|
||||
## What does `blockstack.js` do? |
|
||||
|
|
||||
This is the reference client implementation for Blockstack. You use it in your |
|
||||
Web app to do the following: |
|
||||
|
|
||||
* Authenticate users |
|
||||
* Load and store user data |
|
||||
* Read other users' public data |
|
||||
|
|
||||
## How do I use `blockstack.js`? |
|
||||
|
|
||||
Please see the API documentation [here](https://github.com/blockstack/blockstack.js). |
|
||||
|
|
||||
## How can I look up names and profiles? |
|
||||
|
|
||||
You can use `blockstack.js`, or you can use the [public Blockstack Core |
|
||||
endpoint](https://core.blockstack.org). |
|
||||
|
|
||||
## How can I read my public app data without `blockstack.js`? |
|
||||
|
|
||||
The URLs to a user's public app data are in a canonical location in their |
|
||||
profile. For example, here's how you would get public data from the |
|
||||
[Publik](https://publik.ykliao.com) app, stored under the Blockstack ID `ryan.id`. |
|
||||
|
|
||||
1. Get the bucket URL |
|
||||
```bash |
|
||||
$ BUCKET_URL="$(curl -sL https://core.blockstack.org/v1/users/ryan.id | jq -r '."ryan.id"["profile"]["apps"]["http://publik.ykliao.com"]')" |
|
||||
$ echo "$BUCKET_URL" |
|
||||
https://gaia.blockstack.org/hub/1FrZTGQ8DM9TMPfGXtXMUvt2NNebLiSzad/ |
|
||||
``` |
|
||||
|
|
||||
2. Get the data |
|
||||
```bash |
|
||||
$ curl -sL "${BUCKET_URL%%/}/statuses.json" |
|
||||
[{"id":0,"text":"Hello, Blockstack!","created_at":1515786983492}] |
|
||||
``` |
|
||||
|
|
||||
## How do I register Blockstack IDs? |
|
||||
|
|
||||
You should use the [Blockstack Browser](https://github.com/blockstack/blockstack-browser). |
|
||||
|
|
||||
## How do I register Blockstack Subdomains? |
|
||||
|
|
||||
You can deploy and use a [Blockstack Subdomain Registrar]({{ site.baseurl }}/core/naming/subdomains.html), or |
|
||||
use an existing one. |
|
||||
|
|
||||
## Can I programmatically register Blockstack IDs? |
|
||||
|
|
||||
Blockstack applications do not currently have |
|
||||
have access to the user's wallet. Users are expected to |
|
||||
register Blockstack IDs themselves. |
|
||||
|
|
||||
However, if you feel particularly ambitious, you can do one of the following: |
|
||||
|
|
||||
* Set up a `blockstack api` endpoint (see the project [README](https://github.com/blockstack/blockstack-core/blob/master/README.md)) and write a |
|
||||
program to automatically register names. Also, see the [API |
|
||||
documentation](https://blockstack.github.io/blockstack-core/#managing-names-register-a-name) |
|
||||
for registering names on this endpoint. |
|
||||
|
|
||||
* Write a `node.js` program that uses `blockstack.js` to register |
|
||||
names. This is currently in development. |
|
||||
|
|
||||
## Can I programmatically register Blockstack Subdomains? |
|
||||
|
|
||||
Yes! Once you deploy your own subdomain registrar, you can have your Web app |
|
||||
send it requests to register subdomains on your Blockstack ID. You can also |
|
||||
create a program that drives subdomain registration on your Blockstack ID. |
|
||||
|
|
||||
## Do you have a testnet or sandbox to experiment with Blockstack? |
|
||||
|
|
||||
We have an [integration test framework](https://github.com/blockstack/blockstack-core/tree/master/integration_tests) that provides a |
|
||||
private Blockstack testnet. It uses `bitcoin -regtest` to create a private |
|
||||
blockchain that you can interact with, without having to spend any Bitcoin or |
|
||||
having to wait for blocks to confirm. Please see the |
|
||||
[README](https://github.com/blockstack/blockstack-core/blob/master/integration_tests/README.md) for details. |
|
||||
|
|
||||
## Does Blockstack have a smart contract system? |
|
||||
|
|
||||
No, not yet. This is because |
|
||||
Blockstack's design philosophy focuses on keeping system complexity at the |
|
||||
"edges" of the network (e.g. clients), instead of the "core" of the network (e.g. |
|
||||
the blockchain), in accordance with the [end-to-end |
|
||||
principle](https://en.wikipedia.org/wiki/End-to-end_principle). |
|
||||
Generally speaking, this can be interpreted as "if you can do X without |
|
||||
a smart contract, you should do X without a smart contract." This organizing |
|
||||
principle applies to a lot of useful decentralized applications. |
|
||||
|
|
||||
## Can Blockstack applications interact with Bitcoin? Ethereum? Smart contracts? Other blockchains? |
|
||||
|
|
||||
Yes! Since Blockstack applications are built like Web applications, all you need to do is include the |
|
||||
relevant Javascript library into your application. |
|
||||
@ -1,127 +0,0 @@ |
|||||
--- |
|
||||
layout: core |
|
||||
permalink: /:collection/:path.html |
|
||||
--- |
|
||||
# How to Use the Atlas Network |
|
||||
{:.no_toc} |
|
||||
|
|
||||
This section teaches you how to use the Atlas network, it contains the |
|
||||
following sections: |
|
||||
|
|
||||
* TOC |
|
||||
{:toc} |
|
||||
|
|
||||
## The API |
|
||||
|
|
||||
While the Blockstack software stack expects that Atlas-hosted data is made up of |
|
||||
DNS zone files, Atlas itself does not enforce this (nor does it care about the |
|
||||
format of its chunks). It is designed as a general-purpose chunk store. |
|
||||
Nevertheless, the ubiquitous use of Atlas to store data as DNS zone files has |
|
||||
had an influence on its API design---fields and method names frequently allude |
|
||||
to zone files and zone file hashes. This is intentional. |
|
||||
|
|
||||
The [public BNS API endpoint](https://core.blockstack.org) does not support |
|
||||
resolving Atlas chunks that do not encode Gaia routing information or subdomain |
|
||||
information. To directly interact with Atlas, developers will need to install |
|
||||
[Blockstack Core](https://github.com/blockstack/blockstack-core) and use its |
|
||||
Python client libraries for these examples. |
|
||||
|
|
||||
## Looking up Chunks |
|
||||
|
|
||||
All Atlas chunks are addressed by the RIPEMD160 hash of the SHA256 hash of the |
|
||||
chunk data. A client can query up to 100 chunks in one RPC call. |
|
||||
|
|
||||
A client can look up a chunk with the `get_zonefiles()` method. If successful, |
|
||||
the returned payload will be a `dict` with a `zonefiles` key that maps the chunk |
|
||||
hashes to their respective data. |
|
||||
|
|
||||
```python |
|
||||
>>> import blockstack |
|
||||
>>> data = blockstack.lib.client.get_zonefiles('https://node.blockstack.org:6263', ['1b89a685f4c4ea245ce9433d0b29166c22175ab4']) |
|
||||
>>> print data['zonefiles']['1b89a685f4c4ea245ce9433d0b29166c22175ab4'] |
|
||||
$ORIGIN duckduckgo_tor.id |
|
||||
$TTL 3600 |
|
||||
tor TXT "3g2upl4pq6kufc4m.onion" |
|
||||
|
|
||||
>>> |
|
||||
``` |
|
||||
|
|
||||
(This particular chunk happens to be associated with the BNS name |
|
||||
`duckduckgo_tor.id`). |
|
||||
|
|
||||
## Adding a New Chunk |
|
||||
|
|
||||
The only way to add a chunk to Atlas is to do so through an on-chain name in |
|
||||
BNS. Adding a new chunk is a two-step process: |
|
||||
|
|
||||
* The name owner announces the chunk hash as a name's state |
|
||||
via a `NAME_REGISTRATION`, `NAME_UPDATE`, `NAME_RENEWAL`, or `NAME_IMPORT` transaction. |
|
||||
* Once the transaction is confirmed and processed by BNS, the name owner |
|
||||
broadcasts the matching zone file. |
|
||||
|
|
||||
Setting a name's state to be the hash of a chunk is beyond the scope of this |
|
||||
document, since it needs to be done through a BNS client. |
|
||||
See the relevant documentation for |
|
||||
[blockstack.js](https://github.com/blockstack/blockstack.js) and the [Blockstack |
|
||||
Browser](https://github.com/blockstack/blockstack-browser) for doing this. |
|
||||
|
|
||||
Once the name operation is confirmed, you can announce the data to the |
|
||||
Atlas network. You can do so with the Python client as follows: |
|
||||
|
|
||||
```python |
|
||||
>>> import blockstack |
|
||||
>>> import base64 |
|
||||
>>> data = "..." # this is the chunk data you will announce |
|
||||
>>> data_b64 = base64.b64encode(data) |
|
||||
>>> result = blockstack.lib.client.put_zonefiles('https://node.blockstack.org:6263', [data_b64]) |
|
||||
>>> assert result['saved'][0] == 1 |
|
||||
>>> |
|
||||
``` |
|
||||
|
|
||||
At most five chunks can be announced in one RPC call. |
|
||||
Note that the data must be base64-encoded before it can be announced. |
|
||||
|
|
||||
When the `put_zonefiles()` method succeeds, it returns a `dict` with a list |
|
||||
under the `saved` key. Here, `result['saved'][i]` will be 1 if the `i`th |
|
||||
chunk given to `put_zonefiles()` was saved by the node, and 0 if not. |
|
||||
The node will not save a chunk if it is too big, or if it has not yet processed |
|
||||
the name operation that contained the chunk's hash. |
|
||||
|
|
||||
The `put_zonefiles()` method is idempotent. |
|
||||
|
|
||||
## Propagating Chunks |
|
||||
|
|
||||
Atlas peers will each store a copy of the chunks you announce. In the |
|
||||
background, they will asynchronously announce to one another which chunks they |
|
||||
have available, and replicate them to one another in a rarest-first order (much |
|
||||
like how BitTorrent works). Eventually, every Atlas peer will receive the |
|
||||
chunk. |
|
||||
|
|
||||
However, developers can accelerate this process by eagerly propagating chunks. |
|
||||
To do so, they can ask an Atlas peer for its immediate neighbors in the Atlas |
|
||||
peer graph, and replicate the chunk to each of them as well. |
|
||||
|
|
||||
For example, this code will replicate the chunk to not only |
|
||||
`https://node.blockstack.org:6263`, but also to its immediate neighbors. |
|
||||
|
|
||||
```python |
|
||||
>>> import blockstack |
|
||||
>>> import base64 |
|
||||
>>> data = "..." # this is the chunk you will replicate widely |
|
||||
>>> data_b64 = base64.b64encode(data) |
|
||||
>>> |
|
||||
>>> result = blockstack.lib.client.get_atlas_peers('https://node.blockstack.org:6263') |
|
||||
>>> neighbors = result['peers'] |
|
||||
>>> print ", ".join(neighbors) |
|
||||
13.65.207.163:6264, 52.225.128.191:6264, node.blockstack.org:6264, 23.102.162.7:6264, 52.167.230.235:6264, 23.102.162.124:6264, 52.151.59.26:6264, 13.92.134.106:6264 |
|
||||
>>> |
|
||||
>>> for neighbor in neighbors: |
|
||||
... result = blockstack.lib.client.put_zonefiles(neighbor, [data_b64]) |
|
||||
... assert result['saved'][0] == 1 |
|
||||
... |
|
||||
>>> |
|
||||
``` |
|
||||
|
|
||||
This is not strictly necessary, but it does help accelerate chunk replication |
|
||||
and makes it less likely that a chunk will get lost due to individual node |
|
||||
failures. |
|
||||
@ -1,88 +0,0 @@ |
|||||
--- |
|
||||
layout: core |
|
||||
permalink: /:collection/:path.html |
|
||||
--- |
|
||||
# Blockstack API |
|
||||
{:.no_toc} |
|
||||
* TOC |
|
||||
{:toc} |
|
||||
|
|
||||
|
|
||||
Step-by-step instructions for deploying a Blockstack API node on Debian or |
|
||||
Ubuntu are below. |
|
||||
|
|
||||
- **Step 1:** Make sure you have Blockstack Core running locally (see [instructions](https://github.com/blockstack/blockstack-core/blob/master/README.md#quick-start)). |
|
||||
|
|
||||
- **Step 2:** Make sure you have [virtualenv installed](http://docs.python-guide.org/en/latest/dev/virtualenvs/). |
|
||||
Then, setup the API: |
|
||||
``` |
|
||||
$ sudo apt-get install -y python-pip memcached rng-tools python-dev libmemcached-dev zlib1g-dev libgmp-dev libffi-dev libssl-dev |
|
||||
$ sudo service memcached start |
|
||||
$ sudo pip install virtualenv |
|
||||
$ sudo npm -g install aglio |
|
||||
$ virtualenv api && source api/bin/activate |
|
||||
$ git clone https://github.com/blockstack/blockstack-core.git |
|
||||
$ cd blockstack-core/ |
|
||||
$ pip install . |
|
||||
$ pip install -r api/requirements.txt |
|
||||
$ blockstack setup_wallet |
|
||||
$ blockstack api start |
|
||||
$ deactivate |
|
||||
$ ./build_docs.sh public_api |
|
||||
``` |
|
||||
|
|
||||
### Search Subsystem |
|
||||
|
|
||||
If you want to enable the search subsystem in your installation, you can |
|
||||
follow the instructions [here](search.md). |
|
||||
|
|
||||
### Nginx Deployment |
|
||||
|
|
||||
For a production deployment we recommend using nginx and uwsgi: |
|
||||
|
|
||||
- **Step 1:** Install nginx and uWSGI: |
|
||||
``` |
|
||||
$ sudo apt-get install -y nginx |
|
||||
$ sudo pip install uwsgi |
|
||||
``` |
|
||||
- **Step 2:** Copy [this sample nginx sites file](../api/nginx/config/nginx_sites-available/blockstack_api) to |
|
||||
|
|
||||
> /etc/nginx/sites-available/blockstack_api |
|
||||
|
|
||||
and edit the paths depending on the uwsgi blockstack_api socket directory (defaults to /tmp/blockstack_api.sock) |
|
||||
You can test your nginx settings: |
|
||||
``` |
|
||||
$ sudo nginx -t |
|
||||
``` |
|
||||
- **Step 3:** Copy [this sample systemd service file](../api/nginx/config/systemd_system/blockstack_api.service) to |
|
||||
|
|
||||
> /etc/systemd/system/blockstack_api.service |
|
||||
|
|
||||
and edit the service user and blockstack paths depending on where your blockstack repo is located, and |
|
||||
where your virtualenv is located. |
|
||||
|
|
||||
Note: The following sed commands will work if the virtualenv is currently active and your shell is in the repo's root directory. |
|
||||
|
|
||||
``` |
|
||||
$ sudo sed -i "s/User\=USER/User\=$USER/" /etc/systemd/system/blockstack_api.service |
|
||||
$ sudo sed -i "s#/path/to/blockstack#$PWD#" /etc/systemd/system/blockstack_api.service |
|
||||
$ sudo sed -i "s#/path/to/virtualenv#$VIRTUAL_ENV#" /etc/systemd/system/blockstack_api.service |
|
||||
``` |
|
||||
|
|
||||
- **Step 4:** Get a security certificate from [Let's Encrypt](https://letsencrypt.org/). |
|
||||
``` |
|
||||
$ git clone https://github.com/certbot/certbot.git |
|
||||
$ cd certbot/ |
|
||||
$ ./certbot-auto --nginx -d <your_domain> |
|
||||
``` |
|
||||
|
|
||||
And copy the cert files to the path given in the nginx sites file earlier. |
|
||||
|
|
||||
- **Step 5:** Start nginx and the Blockstack API uwsgi server: |
|
||||
``` |
|
||||
sudo systemctl restart blockstack_api |
|
||||
sudo systemctl restart nginx |
|
||||
``` |
|
||||
|
|
||||
If you run into any issues, please [submit a Github issue](https://github.com/blockstack/blockstack-core/issues) and we'll update these |
|
||||
instructions. |
|
||||
@ -1,53 +0,0 @@ |
|||||
doctype |
|
||||
|
|
||||
|
|
||||
include mixins.jade |
|
||||
|
|
||||
html |
|
||||
head |
|
||||
meta(charset="utf-8") |
|
||||
title= 'Blockstack Core' |
|
||||
link(rel="stylesheet", href="https://maxcdn.bootstrapcdn.com/font-awesome/4.3.0/css/font-awesome.min.css") |
|
||||
style!= self.css |
|
||||
body.preload |
|
||||
#nav-background |
|
||||
div.container-fluid.triple |
|
||||
.row |
|
||||
block nav |
|
||||
+Nav(true) |
|
||||
|
|
||||
.content |
|
||||
#right-panel-background |
|
||||
.middle |
|
||||
header |
|
||||
h1#top!= 'Getting Started' |
|
||||
p!= 'Welcome to this deployment of Blockstack Core v{{server_info.server_version}}. You can read the documentation and make RESTful calls to this node.' |
|
||||
p |
|
||||
table |
|
||||
tr |
|
||||
td!= 'Consensus hash' |
|
||||
td!= '{{server_info.consensus}}' |
|
||||
tr |
|
||||
|
|
||||
td!= 'Last block seen' |
|
||||
td!= '{{server_info.last_block_seen}}' |
|
||||
tr |
|
||||
td!= 'Last block processed' |
|
||||
td!= '{{server_info.last_block_processed}}' |
|
||||
p!= 'Blockstack Core is open-source software released under a GPLv3 license. The code for this API is <a href="https://github.com/blockstack/blockstack-core/tree/master/api">available on Github</a> and you can deploy your own nodes by following <a href="https://github.com/blockstack/blockstack-core/tree/master/api">these instructions</a>.' |
|
||||
block content |
|
||||
+ContentTriple(true) |
|
||||
|
|
||||
.middle |
|
||||
p.text-muted(style="text-align: center;") |
|
||||
|
|
||||
script: include scripts.js |
|
||||
|
|
||||
if self.livePreview |
|
||||
script(src="/socket.io/socket.io.js") |
|
||||
script. |
|
||||
var socket = io(); |
|
||||
socket.on('refresh', refresh); |
|
||||
socket.on('reconnect', function () { |
|
||||
socket.emit('request-refresh'); |
|
||||
}); |
|
||||
@ -1,124 +0,0 @@ |
|||||
# Advanced Usage |
|
||||
|
|
||||
This section details some of the advanced features in the CLI. |
|
||||
|
|
||||
## A Word of Warning |
|
||||
|
|
||||
Advanced features are meant to be used by experienced Blockstack users and developers, They receive less UI/UX testing than basic features, and their interfaces are expected to change to accomodate bugfixes and security fixes. Moreover, improper use of some advanced methods can cost you money, corrupt your profile, or compromise your wallet. Once they receive sufficient testing, an advanced feature may become a basic-mode feature in a subsequent release. |
|
||||
|
|
||||
**Do not use advanced mode unless you know what you are doing!** |
|
||||
|
|
||||
## Activating Advanced Mode |
|
||||
|
|
||||
To activate advanced mode, use the command `blockstack set_advanced_mode on`. |
|
||||
|
|
||||
To deactivate it later (recommended), use the command `blockstack set_advanced_mode off`. |
|
||||
|
|
||||
## Changing or Using Exiting Keys |
|
||||
|
|
||||
If you already have a payment key you want to use, or an owner key you want to migrate over, you can generate a wallet directly with `import_wallet`. We recommend using this command interactively, so you know which keys correspond to which usages. |
|
||||
|
|
||||
## Accounts |
|
||||
|
|
||||
With the accounts methods, you can directly manage your social proofs, link existing services to your profile, and store small bits of information. |
|
||||
|
|
||||
The account management methods are: |
|
||||
* `get_account`: Look up an account in a name's profile. There can be more than one match. |
|
||||
* `list_accounts`: List all accounts in a name's profile. |
|
||||
* `put_account`: Add or update an account in a name's profile. |
|
||||
* `delete_account`: Remove an account from a name's profile. This may need to be done more than once, if there are duplicates of the account. |
|
||||
|
|
||||
## Advanced Blockstack ID Queries |
|
||||
|
|
||||
Beyond `lookup` and `whois`, there are a few other more advanced queries you can run on Blockstack IDs. These include: |
|
||||
|
|
||||
### Listing Blockstack IDs |
|
||||
* `get_all_names`: Get the list of every single Blockstack ID in existance. |
|
||||
* `get_names_owned_by_address`: Get the list of names owned by a particular ownership address. |
|
||||
|
|
||||
### Querying the Blockchain |
|
||||
* `get_name_blockchain_record`: Get the raw database record for a Blockstack ID. It will contain a *compressed* history of all name operations that have affected it. This is meant primarily for debugging purposes; to get an easier-to-parse listing of the information this command returns, use `get_name_blockchain_history`. |
|
||||
* `get_name_blockchain_history`: Get the set of all prior states a Blockstack ID has been in, keyed by the block heights at which the state-change was processed. |
|
||||
* `get_records_at`: Get the list of name operation records processed at a particular block height. |
|
||||
* `list_update_history`: Get the list of all zonefile hashes that a Blockstack ID has ever had. |
|
||||
|
|
||||
### Zonefiles |
|
||||
* `get_name_zonefile`: Get only a Blockstack ID's zonefile. |
|
||||
* `list_zonefile_history`: Get the list of all zonefiles a Blockstack ID has ever had. **NOTE:** There is no guarantee that the server will hold copies of old zonefiles. This command is meant mainly for determining which historic zonefiles a server has processed. |
|
||||
* `set_zonefile_hash`: This is the counterpart to `update`, but instead of setting the zonefile directly and uploading it to storage, you can use this command to directly set the data hash for a Blockstack ID. **NOTE:** You should ensure that the associated zonefile data has been replicated off-chain to a place where other users can get at it. |
|
||||
|
|
||||
### Lightweight Queries |
|
||||
|
|
||||
The lightweight lookup protocol for Blockstack is called *Simplified Name Verification* (SNV). This command returns a prior blockchain-level record given a more recent known-good consensus hash, serial number, or transaction ID of a transaction that contains a consensus hash. The CLI does not need to trust the Blockstack server to use these commands. |
|
||||
|
|
||||
* `lookup_snv`: Use the Merkle skip-list in the name database to look up a historic name operation on a Blockstack ID. |
|
||||
|
|
||||
## Consensus Queries |
|
||||
|
|
||||
You can query consensus hash information from the server with the following commands: |
|
||||
|
|
||||
* `consensus`: Get the consensus hash at a particular block height |
|
||||
|
|
||||
## Namespace Queries |
|
||||
|
|
||||
In addition to querying Blockstack IDs, the CLI has advanced commands for querying namespaces. These include: |
|
||||
|
|
||||
* `get_namespace_blockchain_record`: Get the raw database record for a Blockstack namespace. It will contain a *compressed* history of all namespace operations that have affected it. |
|
||||
* `get_names_in_namespace`: Get the list of every Blockstack ID in a particular namespace. |
|
||||
* `get_namespace_cost`: Get the cost required to preorder a namespace. Does *not* include the cost to reveal and ready it, nor does it include the transaction fees. |
|
||||
|
|
||||
## Namespace Creation |
|
||||
|
|
||||
**WARNING:** We do not recommend that you try to do this by yourself. Creating a namespace is **EXTREMELY EXPENSIVE**. If you are interested in creating your own namespace, please contact the Blockstack developers on the [Blockstack Slack](http://chat.blockstack.org). |
|
||||
|
|
||||
These methods allow you to create a namespace. There are three steps: preordering, revealing, and readying. Preordering a namespace is like preordering a name--you announce the hash of the namespace ID and the address that will control it. Revealing a namespace not only reveals the namespace ID, but also sets the pricing and lifetime rules for names in the namespace. After revealing the namespace, the namespace controller can pre-populate the namespace by importing Blockstack IDs. Once the namespace has been pre-populated, the controller sends a final transaction that readies the namespace for general use. |
|
||||
|
|
||||
* `namespace_preorder`: Preorder a namespace. |
|
||||
* `namespace_reveal`: Reveal a namespace, and set its pricing and lifetime parameters. **NOTE:** This must be done within 144 blocks of sending the namespace preorder transaction. |
|
||||
* `name_import`: Import a name into a revealed (but not readied) namespace. You can set its owner address and zonefile hash directly. |
|
||||
* `namespace_ready`: Open a namespace for general registrations. |
|
||||
|
|
||||
## Data Storage |
|
||||
|
|
||||
Blockstack allows users to store arbitrary data to any set of storage providers for which the CLI has a driver. The data will be signed by the user's data key, so when other users read the data later on, they can verify that it is authentic (i.e. the storage provider is not trusted). Moreover, Blockstack is designed such that users don't have to know or care about which storage providers were used--as far as users can see, storage providers are just shared hard drives. |
|
||||
|
|
||||
There are two types of data supported by Blockstack: *mutable* data, and *immutable* data. Mutable data is linked by the profile, and can be written as fast and as frequently as the storage provider allows. Mutable data is addressed by URL. |
|
||||
|
|
||||
**WARNING:** While mutable data guarantees end-to-end authenticity, there is a chance that a malicious storage provider can serve new readers stale versions of the data. That is, users who have read the latest data already will not get tricked into reading stale data, but users who have *not yet* read the latest data *can* be tricked (i.e. the CLI keeps a version number for mutable data to do so). This must be taken into account if you intend to use this API. |
|
||||
|
|
||||
Immutable data, however, is content-addressed, and its cryptographic hash is stored to the user's zonefile. Writing immutable data will entail updating the zonefile and sending an `update` transaction (handled internally), so it will be slow by comparison. This has the advantage that storage providers cannot perform the aforementioned stale data attack, but has the downside that writes cost money and take a long time to complete. |
|
||||
|
|
||||
That said, we recommend using the mutable data API with several different storage providers whenever possible. |
|
||||
|
|
||||
### Mutable Data |
|
||||
|
|
||||
The following commands affect mutable data: |
|
||||
|
|
||||
* `get_mutable`: Use the profile to look up and fetch a piece of mutable data. |
|
||||
* `put_mutable`: Add a link to mutable data to the profile, and replicate the signed data itself to all storage providers. Other users will need the data's name to read it with `get_mutable`. |
|
||||
* `delete_mutable`: Remove a link to mutable data from the profile, and ask all storage providers to delete the signed data. |
|
||||
|
|
||||
### Immutable Data |
|
||||
|
|
||||
The following commnds affect immutable data: |
|
||||
|
|
||||
* `get_immutable`: Look up and fetch a piece of immutable data. You can supply either the name of the data, or its hash (both are stored in the zonefile, so there is no gain or loss of security in this choice). |
|
||||
* `put_immutable`: Replicate a piece of data to all storage providers, add its name and hash to the zonefile, and issue an `update` to upload the new zonefile to Blockstack servers and write the hash to the blockchain. |
|
||||
* `delete_immutable`: Remove the link to the data from the zonefile, ask all storage providers to delete the data, and issue an `update` to upload the new zonefile to Blockstack servers and write the new hash to the blockchain. |
|
||||
* `list_immutable_data_history`: Given the name of a piece of immutable data, query the zonefile history to find the historic list of hashes it has had. **NOTE:** Like `list_zonefile_history` above, this only returns data hashes for the data if the Blockstack server has the historic zonefile. |
|
||||
|
|
||||
## Fault Recovery |
|
||||
|
|
||||
Sometimes, things beyond our control can happen. Transactions can get stuck, storage providers can go offline or corrupt data, and so on. These commands are meant to assist in recovering from these problems: |
|
||||
|
|
||||
* `set_profile`: Directly set a Blockstack ID's profile. All previous accounts, data links, etc. must be included in the new profile, since the old profile (if still present) will be overwritten by the one given here. |
|
||||
* `convert_legacy_profile`: Given a legacy profile taken from a resolver, directly convert it into a new profile. This can be used with `set_profile` to recover from a failed profile migration. |
|
||||
* `unqueue`: If a transaction gets lost or stuck, you can remove it from the CLI's transaction queue with this command. This will allow you to re-try it. |
|
||||
* `rpcctl`: This lets you directly start or stop the Blockstack CLI's background daemon, which lets you recover from any crashes it experiences (you can find a trace of its behavior in `~/.blockstack/api_endpoint.log`) |
|
||||
|
|
||||
## Programmatic Access |
|
||||
|
|
||||
Other programs may want to make RPC calls the Blockstack CLI daemon. They can do so using either the `blockstack_client` Python package, or they can do so via the CLI as follows: |
|
||||
|
|
||||
* `rpc`: Issue a JSON RPC call. Takes a raw JSON string that encodes a list of arguments. |
|
||||
|
|
||||
@ -1,99 +0,0 @@ |
|||||
--- |
|
||||
layout: core |
|
||||
permalink: /:collection/:path.html |
|
||||
--- |
|
||||
## Decentralized Identifiers (DIDs) |
|
||||
|
|
||||
BNS nodes are compliant with the emerging |
|
||||
[Decentralized Identity Foundation](http://identity.foundation) protocol |
|
||||
specification for decentralized identifiers (DIDs). |
|
||||
|
|
||||
Each name in BNS has an associated DID. The DID format for BNS is: |
|
||||
|
|
||||
``` |
|
||||
did:stack:v0:{address}-{index} |
|
||||
``` |
|
||||
|
|
||||
Where: |
|
||||
* `{address}` is an on-chain public key hash (e.g. a Bitcoin address). |
|
||||
* `{index}` refers to the `nth` name this address created. |
|
||||
|
|
||||
For example, the DID for `personal.id` is |
|
||||
`did:stack:v0:1dARRtzHPAFRNE7Yup2Md9w18XEQAtLiV-0`, because the name |
|
||||
`personal.id` was the first-ever name created by |
|
||||
`1dARRtzHPAFRNE7Yup2Md9w18XEQAtLiV`. |
|
||||
|
|
||||
As another example, the DID for `jude.id` is `did:stack:v0:16EMaNw3pkn3v6f2BgnSSs53zAKH4Q8YJg-1`. |
|
||||
Here, the address `16EMaNw3pkn3v6f2BgnSSs53zAKH4Q8YJg` had created one earlier |
|
||||
name in history prior to this one (which happens to be `abcdefgh123456.id`). |
|
||||
|
|
||||
The purpose of a DID is to provide an eternal identifier for a public key. |
|
||||
The public key may change, but the DID will not. |
|
||||
|
|
||||
Blockstack Core implements a DID method of its own |
|
||||
in order to be compatible with other systems that use DIDs for public key resolution. |
|
||||
In order for a DID to be resolvable, all of the following must be true for a |
|
||||
name: |
|
||||
|
|
||||
* The name must exist |
|
||||
* The name's zone file hash must be the hash of a well-formed DNS zone file |
|
||||
* The DNS zone file must be present in the BNS [Atlas Network]({{ site.baseurl }}/core/atlas/overview.html) |
|
||||
* The DNS zone file must contain a `URI` resource record that points to a signed |
|
||||
JSON Web Token |
|
||||
* The public key that signed the JSON Web Token (and is included with it) must |
|
||||
hash to the address that owns the name |
|
||||
|
|
||||
Not all names will have DIDs that resolve to public keys. However, names created by the [Blockstack |
|
||||
Browser](https://github.com/blockstack/blockstack-browser) will have DIDs that |
|
||||
do. |
|
||||
|
|
||||
Developers can programmatically resolve DIDs via the Python API: |
|
||||
|
|
||||
```Python |
|
||||
>>> import blockstack |
|
||||
>>> blockstack.lib.client.resolve_DID('did:stack:v0:16EMaNw3pkn3v6f2BgnSSs53zAKH4Q8YJg-1', hostport='https://node.blockstack.org:6263') |
|
||||
{'public_key': '020fadbbcea0ff3b05f03195b41cd991d7a0af8bd38559943aec99cbdaf0b22cc8'} |
|
||||
``` |
|
||||
|
|
||||
A RESTful API is under development. |
|
||||
|
|
||||
|
|
||||
# DID Encoding for Subdomains |
|
||||
|
|
||||
Every name and subdomain in BNS has a DID. The encoding is slightly different |
|
||||
for subdomains, so the software can determine which code-path to take. |
|
||||
|
|
||||
* For on-chain BNS names, the `{address}` is the same as the Bitcoin address |
|
||||
that owns the name. Currently, both version byte 0 and version byte 5 |
|
||||
addresses are supported (i.e. addresses starting with `1` or `3`, meaning `p2pkh` and |
|
||||
`p2sh` addresses). |
|
||||
|
|
||||
* For off-chain BNS subdomains, the `{address}` has version byte 63 for |
|
||||
subdomains owned by a single private key, and version byte 50 for subdomains |
|
||||
owned by a m-of-n set of private keys. That is, subdomain DID addresses start |
|
||||
with `S` or `M`, respectively. |
|
||||
|
|
||||
The `{index}` field for a subdomain's DID is distinct from the `{index}` field |
|
||||
for a BNS name's DID, even if the same created both names and subdomains. |
|
||||
For example, the name `abcdefgh123456.id` has the DID `did:stack:v0:16EMaNw3pkn3v6f2BgnSSs53zAKH4Q8YJg-0`, |
|
||||
because it was the first name created by `16EMaNw3pkn3v6f2BgnSSs53zAKH4Q8YJg`. |
|
||||
However, `16EMaNw3pkn3v6f2BgnSSs53zAKH4Q8YJg` *also* created `jude.statism.id` |
|
||||
as its first subdomain name. The DID for `jude.statism.id` is |
|
||||
`did:stack:v0:SSXMcDiCZ7yFSQSUj7mWzmDcdwYhq97p2i-0`. Note that the address |
|
||||
`SSXMcDiCZ7yFSQSUj7mWzmDcdwYhq97p2i` encodes the same public key hash as the address |
|
||||
`16EMaNw3pkn3v6f2BgnSSs53zAKH4Q8YJg` (the only difference between these two |
|
||||
strings is that the first is base58check-encoded with version byte 0, and the |
|
||||
second is encoded with version byte 63). |
|
||||
|
|
||||
You can see this play out in practice with the following code snippit: |
|
||||
|
|
||||
```python |
|
||||
>>> import blockstack |
|
||||
>>> blockstack.lib.client.get_name_record('jude.statism.id', hostport='https://node.blockstack.org:6263')['address'] |
|
||||
u'16EMaNw3pkn3v6f2BgnSSs53zAKH4Q8YJg' |
|
||||
>>> import virtualchain |
|
||||
>>> virtualchain.address_reencode('16EMaNw3pkn3v6f2BgnSSs53zAKH4Q8YJg', version_byte=63) |
|
||||
'SSXMcDiCZ7yFSQSUj7mWzmDcdwYhq97p2i' |
|
||||
>>> blockstack.lib.client.resolve_DID('did:stack:v0:SSXMcDiCZ7yFSQSUj7mWzmDcdwYhq97p2i-0', hostport='https://node.blockstack.org:6263') |
|
||||
{'public_key': '020fadbbcea0ff3b05f03195b41cd991d7a0af8bd38559943aec99cbdaf0b22cc8'} |
|
||||
``` |
|
||||
Binary file not shown.
@ -1,38 +0,0 @@ |
|||||
# Changelog page source |
|
||||
|
|
||||
- title: Version 1.0.0 |
|
||||
label: STABLE |
|
||||
date: Oct 21, 2017 |
|
||||
list: |
|
||||
- Added Slideshow component |
|
||||
- Added style support for radio and minusbox in Firefox |
|
||||
- Removed class from Section component |
|
||||
- Allow fullscreen mode for videos in Lightbox |
|
||||
- Fixed responsive images in modal for IE11 |
|
||||
- Fix Grid and Margin component for cells with no height |
|
||||
- Larger horizontal padding for form input and textarea |
|
||||
|
|
||||
- title: Version 1.0.0 |
|
||||
label: BETA 1 |
|
||||
date: Sep 01, 2017 |
|
||||
list: |
|
||||
- Allow fullscreen mode for YouTube videos in Lightbox |
|
||||
- Fix icons not displaying if connected in rapid succession |
|
||||
- Fix scrollbar jumping in Switcher |
|
||||
|
|
||||
- title: Version 0.6.0 |
|
||||
label: |
|
||||
date: Aug 15, 2017 |
|
||||
list: |
|
||||
- Added style support for radio and checkbox in Firefox |
|
||||
- Removed class from Section component |
|
||||
- Add workaround to mitigate the duplicating icons issue |
|
||||
- Fixed responsive images in modal for IE11 |
|
||||
|
|
||||
- title: Version 0.5.0 |
|
||||
label: |
|
||||
date: Oct 21, 2017 |
|
||||
list: |
|
||||
- Media options now support any valid media query syntax |
|
||||
- Added style support for radio and checkbox in Firefox |
|
||||
- Fix whitespace trimming in dist |
|
||||
@ -1,53 +0,0 @@ |
|||||
{ |
|
||||
"resources" :[ |
|
||||
{ |
|
||||
"title": "KubeSail", |
|
||||
"url": "https://kubesail.com/template/pastudan/gaia-hub", |
|
||||
"type": "website", |
|
||||
"date": "11-10-2019", |
|
||||
"description": "An example of a KubeSail template button" |
|
||||
}, |
|
||||
{ |
|
||||
"title": "Use Blockstack with create-react-app", |
|
||||
"url": "https://github.com/pradel/craco-blockstack", |
|
||||
"type": "repository", |
|
||||
"date": "03-17-2019", |
|
||||
"description": "A craco plugin to use Blockstack with create-react-app." |
|
||||
}, |
|
||||
{ |
|
||||
"title": "Blockstack + React: A TechRally Presentation", |
|
||||
"url": "https://www.youtube.com/watch?v=Arb-dwU5SZI&list=PLDQHh6RjV5oUJNbtnzV11VVghiJTPJ5Wv", |
|
||||
"type": "video", |
|
||||
"date": "01-01-2019", |
|
||||
"description": "A series of short videos that takes users through the process of building a decentralized application (DApp) with Blockstack and React." |
|
||||
}, |
|
||||
{ |
|
||||
"title": "Building decentralized apps with blockstack.js", |
|
||||
"url": "https://docs.google.com/presentation/d/1KUL7NVGeP4EFyodF-ANCF7Bw05QM4KGBMxGvQbKFsx8/edit?usp=sharing", |
|
||||
"type": "presentation", |
|
||||
"date": "07-18-2018", |
|
||||
"description": "Introduction to using blockstack.js" |
|
||||
}, |
|
||||
{ |
|
||||
"title": "Blockstack Academy", |
|
||||
"url": "https://www.youtube.com/playlist?list=PLXS8JJHIn4nEv_LcXIaklH_QAZaDEVD8q", |
|
||||
"date": "09-26-2017", |
|
||||
"type": "video", |
|
||||
"description" : "A series of educational videos featuring members of the Blockstack community and core contributors." |
|
||||
}, |
|
||||
{ |
|
||||
"title": "Blockstack: A New Internet That Brings Privacy & Property Rights to Cyberspace", |
|
||||
"url": "https://youtu.be/Z4bMFKBRg_k", |
|
||||
"type": "video", |
|
||||
"date": "06-22-2017", |
|
||||
"description": "Meet the developers behind Blockstack, who are using blockchain technology to reconfigure the web." |
|
||||
}, |
|
||||
{ |
|
||||
"title": "Walkthrough of the Blockstack Browser, December 2017", |
|
||||
"url": "https://youtu.be/WopvxEM7O84", |
|
||||
"type": "video", |
|
||||
"date": "12-18-2017", |
|
||||
"description": "Walks through downloading and using Blockstack's new decentralized internet, which gives users control over their data and the applications they share it with. Download the browser for the decentralized internet at blockstack.org." |
|
||||
} |
|
||||
] |
|
||||
} |
|
||||
@ -0,0 +1,123 @@ |
|||||
|
- title: Guides |
||||
|
docs: |
||||
|
- develop/overview_auth |
||||
|
- develop/storage |
||||
|
- develop/profiles |
||||
|
|
||||
|
- title: Tutorials |
||||
|
docs: |
||||
|
- browser/hello-blockstack |
||||
|
- browser/todo-list |
||||
|
- browser/blockstack_storage |
||||
|
- develop/deploy-tips |
||||
|
- android/tutorial |
||||
|
- ios/tutorial |
||||
|
|
||||
|
- title: Blockstack Connect |
||||
|
docs: |
||||
|
- develop/connect/overview |
||||
|
- develop/connect/get-started |
||||
|
- develop/connect/use-with-clarity |
||||
|
|
||||
|
- title: Data sharing & collaboration |
||||
|
docs: |
||||
|
- develop/radiks-intro |
||||
|
- develop/radiks-setup |
||||
|
- develop/radiks-models |
||||
|
- develop/radiks-collaborate |
||||
|
- develop/radiks-server-extras |
||||
|
|
||||
|
- title: Data portability (Preview) |
||||
|
docs: |
||||
|
- develop/collections |
||||
|
- develop/collection-type |
||||
|
|
||||
|
- title: Introduction to Gaia storage |
||||
|
docs: |
||||
|
- storage/overview |
||||
|
- storage/authentication |
||||
|
- storage/write-to-read |
||||
|
- storage/hub-choice |
||||
|
|
||||
|
- title: Gaia How to hub |
||||
|
docs: |
||||
|
- storage/hub-operation |
||||
|
- storage/amazon-s3-deploy |
||||
|
- storage/digital-ocean-deploy |
||||
|
- storage/hello-hub-choice |
||||
|
- storage/gaia-admin |
||||
|
|
||||
|
- title: Clarity Getting started |
||||
|
docs: |
||||
|
- core/smart/overview |
||||
|
|
||||
|
- title: Clarity Tutorials |
||||
|
docs: |
||||
|
- core/smart/tutorial |
||||
|
- core/smart/tutorial-counter |
||||
|
- core/smart/tutorial-test |
||||
|
|
||||
|
- title: Clarity Guides |
||||
|
docs: |
||||
|
- core/smart/principals |
||||
|
- core/smart/neon-node |
||||
|
- core/smart/cli-wallet-quickstart |
||||
|
|
||||
|
- title: About Blockstack |
||||
|
docs: |
||||
|
- org/overview |
||||
|
- faqs/allFAQS |
||||
|
- org/token |
||||
|
- org/whitepaper-blockchain |
||||
|
- title: About Blockstack Manage Stacks |
||||
|
docs: |
||||
|
- org/wallet-intro |
||||
|
- org/wallet-install |
||||
|
- org/wallet-use |
||||
|
- org/wallet-troubleshoot |
||||
|
- org/tokenholders |
||||
|
|
||||
|
- title: Naming Services Guides |
||||
|
docs: |
||||
|
- core/naming/introduction |
||||
|
- core/naming/architecture |
||||
|
- core/naming/namespaces |
||||
|
- core/naming/comparison |
||||
|
|
||||
|
- title: Naming Service Tutorials |
||||
|
docs: |
||||
|
- core/naming/tutorial_subdomains |
||||
|
- core/naming/search |
||||
|
- core/faq_technical |
||||
|
|
||||
|
- title: How to use BNS |
||||
|
docs: |
||||
|
- core/naming/pickname |
||||
|
- core/naming/creationhowto |
||||
|
- core/naming/resolving |
||||
|
- core/naming/register |
||||
|
- core/naming/manage |
||||
|
- core/naming/subdomains |
||||
|
- core/naming/forks |
||||
|
|
||||
|
- title: Atlas |
||||
|
docs: |
||||
|
- core/atlas/overview |
||||
|
- core/atlas/howitworks |
||||
|
- core/atlas/howtouse |
||||
|
|
||||
|
- title: References |
||||
|
docs: |
||||
|
- core/cmdLineRef |
||||
|
- core/smart/clarityRef |
||||
|
- core/smart/rpc-api |
||||
|
- common/javascript_ref |
||||
|
- common/android_ref |
||||
|
- common/ios_ref |
||||
|
- develop/cliDocs |
||||
|
- common/core_ref |
||||
|
- core/faq_developer |
||||
|
- core/wire-format |
||||
|
- storage/config-schema |
||||
|
- org/secureref |
||||
|
- org/terms |
||||
@ -1,4 +0,0 @@ |
|||||
- docs: |
|
||||
- core/atlas/overview |
|
||||
- core/atlas/howitworks |
|
||||
- core/atlas/howtouse |
|
||||
@ -1,37 +0,0 @@ |
|||||
- title: Naming Services Guides |
|
||||
docs: |
|
||||
- core/naming/introduction |
|
||||
- core/naming/architecture |
|
||||
- core/naming/namespaces |
|
||||
- core/naming/comparison |
|
||||
|
|
||||
- title: Naming Service Tutorials |
|
||||
docs: |
|
||||
- core/naming/tutorial_subdomains |
|
||||
- core/naming/search |
|
||||
- core/faq_technical |
|
||||
|
|
||||
- title: How to use BNS |
|
||||
docs: |
|
||||
- core/naming/pickname |
|
||||
- core/naming/creationhowto |
|
||||
- core/naming/resolving |
|
||||
- core/naming/register |
|
||||
- core/naming/manage |
|
||||
- core/naming/subdomains |
|
||||
- core/naming/forks |
|
||||
|
|
||||
- title: Atlas |
|
||||
docs: |
|
||||
- core/atlas/overview |
|
||||
- core/atlas/howitworks |
|
||||
- core/atlas/howtouse |
|
||||
|
|
||||
- title: Reference |
|
||||
docs: |
|
||||
- core/cmdLineRef |
|
||||
- common/javascript_ref |
|
||||
- common/android_ref |
|
||||
- common/ios_ref |
|
||||
- common/core_ref |
|
||||
- core/wire-format |
|
||||
@ -1,3 +0,0 @@ |
|||||
- title: Under Construction |
|
||||
docs: |
|
||||
- common/construction |
|
||||
@ -1,46 +0,0 @@ |
|||||
- title: Guides |
|
||||
docs: |
|
||||
- develop/overview_auth |
|
||||
- develop/storage |
|
||||
- develop/profiles |
|
||||
|
|
||||
- title: Tutorials |
|
||||
docs: |
|
||||
- browser/hello-blockstack |
|
||||
- browser/todo-list |
|
||||
- browser/blockstack_storage |
|
||||
- develop/deploy-tips |
|
||||
- android/tutorial |
|
||||
- ios/tutorial |
|
||||
|
|
||||
- title: Blockstack Connect |
|
||||
docs: |
|
||||
- develop/connect/overview |
|
||||
- develop/connect/get-started |
|
||||
- develop/connect/use-with-clarity |
|
||||
|
|
||||
- title: Data sharing & collaboration |
|
||||
docs: |
|
||||
- develop/radiks-intro |
|
||||
- develop/radiks-setup |
|
||||
- develop/radiks-models |
|
||||
- develop/radiks-collaborate |
|
||||
- develop/radiks-server-extras |
|
||||
|
|
||||
- title: Data portability (Preview) |
|
||||
docs: |
|
||||
- develop/collections |
|
||||
- develop/collection-type |
|
||||
|
|
||||
- title: References |
|
||||
docs: |
|
||||
- common/javascript_ref |
|
||||
- common/android_ref |
|
||||
- common/ios_ref |
|
||||
- develop/cliDocs |
|
||||
- common/core_ref |
|
||||
|
|
||||
- title: Misc |
|
||||
docs: |
|
||||
- core/faq_developer |
|
||||
- develop/communityResources |
|
||||
@ -1,17 +0,0 @@ |
|||||
- title: About Blockstack |
|
||||
docs: |
|
||||
- org/overview |
|
||||
- faqs/allFAQS |
|
||||
- org/token |
|
||||
- org/whitepaper-blockchain |
|
||||
- title: Manage Stacks |
|
||||
docs: |
|
||||
- org/wallet-intro |
|
||||
- org/wallet-install |
|
||||
- org/wallet-use |
|
||||
- org/wallet-troubleshoot |
|
||||
- org/tokenholders |
|
||||
- title: Reference |
|
||||
docs: |
|
||||
- org/secureref |
|
||||
- org/terms |
|
||||
@ -1,21 +0,0 @@ |
|||||
- title: Getting started |
|
||||
docs: |
|
||||
- core/smart/overview |
|
||||
|
|
||||
- title: Tutorials |
|
||||
docs: |
|
||||
- core/smart/tutorial |
|
||||
- core/smart/tutorial-counter |
|
||||
- core/smart/tutorial-test |
|
||||
|
|
||||
- title: Guides |
|
||||
docs: |
|
||||
- core/smart/principals |
|
||||
- core/smart/neon-node |
|
||||
- core/smart/cli-wallet-quickstart |
|
||||
- core/smart/testnet-node |
|
||||
|
|
||||
- title: References |
|
||||
docs: |
|
||||
- core/smart/clarityRef |
|
||||
- core/smart/rpc-api |
|
||||
@ -1,23 +0,0 @@ |
|||||
- title: Introduction to Gaia storage |
|
||||
docs: |
|
||||
- storage/overview |
|
||||
- storage/authentication |
|
||||
- storage/write-to-read |
|
||||
- storage/hub-choice |
|
||||
|
|
||||
- title: How to hub |
|
||||
docs: |
|
||||
- storage/hub-operation |
|
||||
- storage/amazon-s3-deploy |
|
||||
- storage/digital-ocean-deploy |
|
||||
- storage/hello-hub-choice |
|
||||
- storage/gaia-admin |
|
||||
|
|
||||
- title: Reference |
|
||||
docs: |
|
||||
- storage/config-schema |
|
||||
- common/javascript_ref |
|
||||
- common/android_ref |
|
||||
- common/ios_ref |
|
||||
- storage/cliDocs |
|
||||
- common/core_ref |
|
||||
@ -1,14 +0,0 @@ |
|||||
- title: Browser |
|
||||
- docs: |
|
||||
- browser/browser-introduction |
|
||||
- browser/local_browser |
|
||||
|
|
||||
- title: Identity and storage |
|
||||
- docs: |
|
||||
- browser/ids-introduction |
|
||||
- browser/storage-provider |
|
||||
|
|
||||
- title: Reference |
|
||||
- docs: |
|
||||
- browser/secureref |
|
||||
- browser/faq_general |
|
||||
@ -1,24 +0,0 @@ |
|||||
--- |
|
||||
layout: learn |
|
||||
permalink: /:collection/:path.html |
|
||||
--- |
|
||||
# Community Learning Resources |
|
||||
|
|
||||
You can use these community resources to learn more. To add your own resources, |
|
||||
please make a pull request or send us an issue on Github. We are happy to add |
|
||||
other resources. |
|
||||
|
|
||||
<table class="uk-table"> |
|
||||
<thead> |
|
||||
<tr> |
|
||||
<th>Resource Links</th> |
|
||||
<th class="uk-width-1-4">Date</th> |
|
||||
</tr> |
|
||||
</thead> |
|
||||
{% for resource in site.data.community.resources %} |
|
||||
<tr> |
|
||||
<td><p><a href="{{ resource.url }}" target="\_blank">{{ resource.title }}</a> {{resource.description}} (<em>{{resource.type}}</em>)</p></td> |
|
||||
<td>{{resource.date}}</td> |
|
||||
</tr> |
|
||||
{% endfor %} |
|
||||
</table> |
|
||||
|
Before Width: | Height: | Size: 30 KiB |
|
Before Width: | Height: | Size: 26 KiB |
|
Before Width: | Height: | Size: 23 KiB |
|
Before Width: | Height: | Size: 3.2 MiB |
Some files were not shown because too many files changed in this diff
Loading…
Reference in new issue