├── .gitignore
├── 404.html
├── Gemfile
├── Gemfile.lock
├── _config.yml
├── _posts
└── .gitkeep
└── index.md
/.gitignore:
--------------------------------------------------------------------------------
1 | _site
2 | .sass-cache
3 | .jekyll-metadata
4 |
--------------------------------------------------------------------------------
/404.html:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | ---
4 |
5 |
18 |
19 |
20 |
404
21 |
22 |
Page not found :(
23 |
The requested page could not be found.
24 |
25 |
--------------------------------------------------------------------------------
/Gemfile:
--------------------------------------------------------------------------------
1 | source "https://rubygems.org"
2 |
3 | # Hello! This is where you manage which Jekyll version is used to run.
4 | # When you want to use a different version, change it below, save the
5 | # file and run `bundle install`. Run Jekyll with `bundle exec`, like so:
6 | #
7 | # bundle exec jekyll serve
8 | #
9 | # This will help ensure the proper Jekyll version is running.
10 | # Happy Jekylling!
11 | # gem "jekyll", "~> 3.8.3"
12 |
13 | # If you want to use GitHub Pages, remove the "gem "jekyll"" above and
14 | # uncomment the line below. To upgrade, run `bundle update github-pages`.
15 | gem "github-pages", group: :jekyll_plugins
16 |
17 | # If you have any plugins, put them here!
18 | group :jekyll_plugins do
19 | # gem "jekyll-feed", "~> 0.6"
20 | end
21 |
22 | # Windows does not include zoneinfo files, so bundle the tzinfo-data gem
23 | gem "tzinfo-data", platforms: [:mingw, :mswin, :x64_mingw, :jruby]
24 |
25 | # Performance-booster for watching directories on Windows
26 | gem "wdm", "~> 0.1.0" if Gem.win_platform?
27 |
--------------------------------------------------------------------------------
/Gemfile.lock:
--------------------------------------------------------------------------------
1 | GEM
2 | remote: https://rubygems.org/
3 | specs:
4 | activesupport (6.0.3.1)
5 | concurrent-ruby (~> 1.0, >= 1.0.2)
6 | i18n (>= 0.7, < 2)
7 | minitest (~> 5.1)
8 | tzinfo (~> 1.1)
9 | zeitwerk (~> 2.2, >= 2.2.2)
10 | addressable (2.7.0)
11 | public_suffix (>= 2.0.2, < 5.0)
12 | coffee-script (2.4.1)
13 | coffee-script-source
14 | execjs
15 | coffee-script-source (1.11.1)
16 | colorator (1.1.0)
17 | commonmarker (0.17.13)
18 | ruby-enum (~> 0.5)
19 | concurrent-ruby (1.1.6)
20 | dnsruby (1.61.3)
21 | addressable (~> 2.5)
22 | em-websocket (0.5.1)
23 | eventmachine (>= 0.12.9)
24 | http_parser.rb (~> 0.6.0)
25 | ethon (0.12.0)
26 | ffi (>= 1.3.0)
27 | eventmachine (1.2.7)
28 | execjs (2.7.0)
29 | faraday (1.0.1)
30 | multipart-post (>= 1.2, < 3)
31 | ffi (1.12.2)
32 | forwardable-extended (2.6.0)
33 | gemoji (3.0.1)
34 | github-pages (204)
35 | github-pages-health-check (= 1.16.1)
36 | jekyll (= 3.8.5)
37 | jekyll-avatar (= 0.7.0)
38 | jekyll-coffeescript (= 1.1.1)
39 | jekyll-commonmark-ghpages (= 0.1.6)
40 | jekyll-default-layout (= 0.1.4)
41 | jekyll-feed (= 0.13.0)
42 | jekyll-gist (= 1.5.0)
43 | jekyll-github-metadata (= 2.13.0)
44 | jekyll-mentions (= 1.5.1)
45 | jekyll-optional-front-matter (= 0.3.2)
46 | jekyll-paginate (= 1.1.0)
47 | jekyll-readme-index (= 0.3.0)
48 | jekyll-redirect-from (= 0.15.0)
49 | jekyll-relative-links (= 0.6.1)
50 | jekyll-remote-theme (= 0.4.1)
51 | jekyll-sass-converter (= 1.5.2)
52 | jekyll-seo-tag (= 2.6.1)
53 | jekyll-sitemap (= 1.4.0)
54 | jekyll-swiss (= 1.0.0)
55 | jekyll-theme-architect (= 0.1.1)
56 | jekyll-theme-cayman (= 0.1.1)
57 | jekyll-theme-dinky (= 0.1.1)
58 | jekyll-theme-hacker (= 0.1.1)
59 | jekyll-theme-leap-day (= 0.1.1)
60 | jekyll-theme-merlot (= 0.1.1)
61 | jekyll-theme-midnight (= 0.1.1)
62 | jekyll-theme-minimal (= 0.1.1)
63 | jekyll-theme-modernist (= 0.1.1)
64 | jekyll-theme-primer (= 0.5.4)
65 | jekyll-theme-slate (= 0.1.1)
66 | jekyll-theme-tactile (= 0.1.1)
67 | jekyll-theme-time-machine (= 0.1.1)
68 | jekyll-titles-from-headings (= 0.5.3)
69 | jemoji (= 0.11.1)
70 | kramdown (= 1.17.0)
71 | liquid (= 4.0.3)
72 | mercenary (~> 0.3)
73 | minima (= 2.5.1)
74 | nokogiri (>= 1.10.4, < 2.0)
75 | rouge (= 3.13.0)
76 | terminal-table (~> 1.4)
77 | github-pages-health-check (1.16.1)
78 | addressable (~> 2.3)
79 | dnsruby (~> 1.60)
80 | octokit (~> 4.0)
81 | public_suffix (~> 3.0)
82 | typhoeus (~> 1.3)
83 | html-pipeline (2.12.3)
84 | activesupport (>= 2)
85 | nokogiri (>= 1.4)
86 | http_parser.rb (0.6.0)
87 | i18n (0.9.5)
88 | concurrent-ruby (~> 1.0)
89 | jekyll (3.8.5)
90 | addressable (~> 2.4)
91 | colorator (~> 1.0)
92 | em-websocket (~> 0.5)
93 | i18n (~> 0.7)
94 | jekyll-sass-converter (~> 1.0)
95 | jekyll-watch (~> 2.0)
96 | kramdown (~> 1.14)
97 | liquid (~> 4.0)
98 | mercenary (~> 0.3.3)
99 | pathutil (~> 0.9)
100 | rouge (>= 1.7, < 4)
101 | safe_yaml (~> 1.0)
102 | jekyll-avatar (0.7.0)
103 | jekyll (>= 3.0, < 5.0)
104 | jekyll-coffeescript (1.1.1)
105 | coffee-script (~> 2.2)
106 | coffee-script-source (~> 1.11.1)
107 | jekyll-commonmark (1.3.1)
108 | commonmarker (~> 0.14)
109 | jekyll (>= 3.7, < 5.0)
110 | jekyll-commonmark-ghpages (0.1.6)
111 | commonmarker (~> 0.17.6)
112 | jekyll-commonmark (~> 1.2)
113 | rouge (>= 2.0, < 4.0)
114 | jekyll-default-layout (0.1.4)
115 | jekyll (~> 3.0)
116 | jekyll-feed (0.13.0)
117 | jekyll (>= 3.7, < 5.0)
118 | jekyll-gist (1.5.0)
119 | octokit (~> 4.2)
120 | jekyll-github-metadata (2.13.0)
121 | jekyll (>= 3.4, < 5.0)
122 | octokit (~> 4.0, != 4.4.0)
123 | jekyll-mentions (1.5.1)
124 | html-pipeline (~> 2.3)
125 | jekyll (>= 3.7, < 5.0)
126 | jekyll-optional-front-matter (0.3.2)
127 | jekyll (>= 3.0, < 5.0)
128 | jekyll-paginate (1.1.0)
129 | jekyll-readme-index (0.3.0)
130 | jekyll (>= 3.0, < 5.0)
131 | jekyll-redirect-from (0.15.0)
132 | jekyll (>= 3.3, < 5.0)
133 | jekyll-relative-links (0.6.1)
134 | jekyll (>= 3.3, < 5.0)
135 | jekyll-remote-theme (0.4.1)
136 | addressable (~> 2.0)
137 | jekyll (>= 3.5, < 5.0)
138 | rubyzip (>= 1.3.0)
139 | jekyll-sass-converter (1.5.2)
140 | sass (~> 3.4)
141 | jekyll-seo-tag (2.6.1)
142 | jekyll (>= 3.3, < 5.0)
143 | jekyll-sitemap (1.4.0)
144 | jekyll (>= 3.7, < 5.0)
145 | jekyll-swiss (1.0.0)
146 | jekyll-theme-architect (0.1.1)
147 | jekyll (~> 3.5)
148 | jekyll-seo-tag (~> 2.0)
149 | jekyll-theme-cayman (0.1.1)
150 | jekyll (~> 3.5)
151 | jekyll-seo-tag (~> 2.0)
152 | jekyll-theme-dinky (0.1.1)
153 | jekyll (~> 3.5)
154 | jekyll-seo-tag (~> 2.0)
155 | jekyll-theme-hacker (0.1.1)
156 | jekyll (~> 3.5)
157 | jekyll-seo-tag (~> 2.0)
158 | jekyll-theme-leap-day (0.1.1)
159 | jekyll (~> 3.5)
160 | jekyll-seo-tag (~> 2.0)
161 | jekyll-theme-merlot (0.1.1)
162 | jekyll (~> 3.5)
163 | jekyll-seo-tag (~> 2.0)
164 | jekyll-theme-midnight (0.1.1)
165 | jekyll (~> 3.5)
166 | jekyll-seo-tag (~> 2.0)
167 | jekyll-theme-minimal (0.1.1)
168 | jekyll (~> 3.5)
169 | jekyll-seo-tag (~> 2.0)
170 | jekyll-theme-modernist (0.1.1)
171 | jekyll (~> 3.5)
172 | jekyll-seo-tag (~> 2.0)
173 | jekyll-theme-primer (0.5.4)
174 | jekyll (> 3.5, < 5.0)
175 | jekyll-github-metadata (~> 2.9)
176 | jekyll-seo-tag (~> 2.0)
177 | jekyll-theme-slate (0.1.1)
178 | jekyll (~> 3.5)
179 | jekyll-seo-tag (~> 2.0)
180 | jekyll-theme-tactile (0.1.1)
181 | jekyll (~> 3.5)
182 | jekyll-seo-tag (~> 2.0)
183 | jekyll-theme-time-machine (0.1.1)
184 | jekyll (~> 3.5)
185 | jekyll-seo-tag (~> 2.0)
186 | jekyll-titles-from-headings (0.5.3)
187 | jekyll (>= 3.3, < 5.0)
188 | jekyll-watch (2.2.1)
189 | listen (~> 3.0)
190 | jemoji (0.11.1)
191 | gemoji (~> 3.0)
192 | html-pipeline (~> 2.2)
193 | jekyll (>= 3.0, < 5.0)
194 | kramdown (1.17.0)
195 | liquid (4.0.3)
196 | listen (3.2.1)
197 | rb-fsevent (~> 0.10, >= 0.10.3)
198 | rb-inotify (~> 0.9, >= 0.9.10)
199 | mercenary (0.3.6)
200 | mini_portile2 (2.5.1)
201 | minima (2.5.1)
202 | jekyll (>= 3.5, < 5.0)
203 | jekyll-feed (~> 0.9)
204 | jekyll-seo-tag (~> 2.1)
205 | minitest (5.14.1)
206 | multipart-post (2.1.1)
207 | nokogiri (1.11.4)
208 | mini_portile2 (~> 2.5.0)
209 | racc (~> 1.4)
210 | octokit (4.18.0)
211 | faraday (>= 0.9)
212 | sawyer (~> 0.8.0, >= 0.5.3)
213 | pathutil (0.16.2)
214 | forwardable-extended (~> 2.6)
215 | public_suffix (3.1.1)
216 | racc (1.5.2)
217 | rb-fsevent (0.10.3)
218 | rb-inotify (0.10.1)
219 | ffi (~> 1.0)
220 | rouge (3.13.0)
221 | ruby-enum (0.8.0)
222 | i18n
223 | rubyzip (2.3.0)
224 | safe_yaml (1.0.5)
225 | sass (3.7.4)
226 | sass-listen (~> 4.0.0)
227 | sass-listen (4.0.0)
228 | rb-fsevent (~> 0.9, >= 0.9.4)
229 | rb-inotify (~> 0.9, >= 0.9.7)
230 | sawyer (0.8.2)
231 | addressable (>= 2.3.5)
232 | faraday (> 0.8, < 2.0)
233 | terminal-table (1.8.0)
234 | unicode-display_width (~> 1.1, >= 1.1.1)
235 | thread_safe (0.3.6)
236 | typhoeus (1.3.1)
237 | ethon (>= 0.9.0)
238 | tzinfo (1.2.7)
239 | thread_safe (~> 0.1)
240 | unicode-display_width (1.7.0)
241 | zeitwerk (2.3.0)
242 |
243 | PLATFORMS
244 | ruby
245 |
246 | DEPENDENCIES
247 | github-pages
248 | tzinfo-data
249 |
250 | BUNDLED WITH
251 | 2.1.4
252 |
--------------------------------------------------------------------------------
/_config.yml:
--------------------------------------------------------------------------------
1 | # Welcome to Jekyll!
2 | #
3 | # This config file is meant for settings that affect your whole blog, values
4 | # which you are expected to set up once and rarely edit after that. If you find
5 | # yourself editing this file very often, consider using Jekyll's data files
6 | # feature for the data you need to update frequently.
7 | #
8 | # For technical reasons, this file is *NOT* reloaded automatically when you use
9 | # 'bundle exec jekyll serve'. If you change this file, please restart the server process.
10 |
11 | # Site settings
12 | # These are used to personalize your new site. If you look in the HTML files,
13 | # you will see them accessed via {{ site.title }}, {{ site.email }}, and so on.
14 | # You can create any custom variable you would like, and they will be accessible
15 | # in the templates via {{ site.myvariable }}.
16 | title: RGB
17 | email: ""
18 | description: "Private & scalable smart contracts for Bitcoin and Lightning Network"
19 | baseurl: "" # the subpath of your site, e.g. /blog
20 | url: "" # the base hostname & protocol for your site, e.g. http://example.com
21 | # twitter_username: ??
22 | github_username: rgb-org
23 |
24 | # Build settings
25 | markdown: kramdown
26 | theme: jekyll-theme-hacker
27 | plugins:
28 |
29 | # Exclude from processing.
30 | # The following items will not be processed, by default. Create a custom list
31 | # to override the default setting.
32 | # exclude:
33 | # - Gemfile
34 | # - Gemfile.lock
35 | # - node_modules
36 | # - vendor/bundle/
37 | # - vendor/cache/
38 | # - vendor/gems/
39 | # - vendor/ruby/
40 |
--------------------------------------------------------------------------------
/_posts/.gitkeep:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/RGB-WG/rgb-org.github.io-archive/a67caee712348cf7ad7c8049ef2ee13c52b1be3c/_posts/.gitkeep
--------------------------------------------------------------------------------
/index.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | description: Scalable & confidential smart contracts for Bitcoin & lightning network
4 | ---
5 |
6 | # RGB Blueprint
7 |
8 | RGB is a suite of protocols for scalable & confidential smart contracts for Bitcoin & lightning network. They embrace concepts of private & mutual ownership, abstraction and separation of concerns and represent "post-blockchain", Turing-complete form of trustless distributed computing which does not require introduction of "tokens".
9 |
10 | As a smart contract system RGB is quite different from previous approaches, both Bitcoin-based \(Colored coins, Counterparty, OMNI\) and non-bitcoin \(Ethereum, EOS and others\):
11 |
12 | * RGB separates concept of smart contract **issuer**, **state owners** and **state evolution**
13 | * RGB keeps the smart contract code and data offchain
14 | * RGB uses blockchain as a state commitment layer and Bitcoin script as an ownership control system; while smart contract evolution is defined by off-chain **schema**
15 |
16 | More about these concepts can be read in [this presentation](https://github.com/LNP-BP/FAQ/blob/master/Presentation%20slides/RGB%20%26%20Spectrum%20explanation%20for%20business.pdf).
17 |
18 | ## Core underlying concepts
19 |
20 | In order to understand technical details behind RGB one have to become familiar with the following concepts, which are hevily used in RGB design:
21 |
22 | * Distributed systems \(replicated state machines\), including
23 | * PRISM \(partially-replicated infinite state machines\) computing
24 | * AluVM instruction set architecture
25 | * Non-imperative computing, including
26 | * Declarative programming
27 | * Cellular automation
28 | * Zero knowledge protocols, including
29 | * Confidential transactions
30 | * Bulletproofs
31 | * Cryptographic commitment schemes, including
32 | * BIP-340 tagged hashes
33 | * Advanced merklization schemes \(LNPBP-\)
34 | * Multi-message commitments
35 | * Deterministic bitcoin commitments
36 | * Client-side-validation, including:
37 | * Strict encoding \(LNPBP-7\)
38 | * Commit-conceal schemes
39 | * Single-use-seals
40 | * Bitcoin transactions, including
41 | * PSBTs v1 and v2
42 | * Bitcoin TxO2 single-use-seals
43 | * Lightning network protocol, including
44 | * Lightning P2P message extensions
45 | * Generalized lightning channels
46 |
47 | ## Design
48 |
49 | Briefly, RGB smart contracts operate with **client-side validation** paradigm, meaning that all the data is kept outside of the bitcoin transactions, i.e. bitcoin blockchain or lightning channel state. This allows the system to operate on top of Lightning Network without any changes to the LN protocols and also gives a foundation for a high level of protocol scalability and privacy.
50 |
51 | As a security mechanism RGB uses **single-use seals** defined over bitcoin transaction outputs, which provides ability for any party having smart contract state history to verify its uniqueness. In other words, RGB leverages Bitcoin script for its security model and definition of the **ownership** and **access rights**.
52 |
53 | Each RGB smart contract is represented by some **genesis state**, created by **smart contract issuer** \(or, put simply, issuer\) and a directed acyclic graph \(DAG\) of **state transitions** kept in form of _client-validated data_ \(i.e. this data is not stored on blockchain or within LN transactions/channel state\). The state is **assigned** to unspent bitcoin transaction outputs, which defines them as _single-use seals_. The party that is able to spend corresponding transaction output is named a party **owning state**: it is a party that has the right to change the corresponding part of the smart contract state by creating a new _state transition_ and committing to it in a transaction spending the output containing previous state. This procedure represents **closing of a seal over state transition**, and a pair of spending transaction and corresponding extra-transaction data on the state transition are named **witness**.
54 |
55 | _State transition_ **assigns** _state_ to a set of defined **single-use seals**. Each smart contract may maintain different forms of state and define different kinds of single-use seals with different validation rules. Additionally to this, state transition may contain different metadata and _scripts_, defining parts of its business logic.
56 |
57 | Which types of state, seals, metadata and which script extensions are allowed within state transitions is defined by **schema**. Thus, schema can be seen as validation rules for _client-side validation_; schema is always defined by the issuer in state genesis. Schema also may contain Turing-complete _scripts_ defining parts of the business logic for _client-side validation_.
58 |
59 | RGB operates in “shards”, where each contract has a separate **state history** and data; different smart contracts never intersect in their histories directly. This allows another level of scalability; and while the term “shard” is incorrect, we use it to demonstrate that RGB actually achieves what was planned to be achieved with “Ethereum shards”.
60 |
61 | While being separately maintained, RGB contracts may interact via **Bifrost** protocol over the Lightning Network, allowing multiparty **coordinated state changes**, which, for instance, enables functionality like DEX over Lightning etc.
62 |
63 | Thus, by their abilities RGB smart contracts go beyond what is possible with Ethereum-like smart contract system, providing more layered, scalable, private and safe approach, where the ownership of the smart contract state is separated from the smart contract creation.
64 |
65 | ## Compatibility and interoperability
66 |
67 | * SegWit v0
68 | * Taproot \(SegWit v1\), Tapscript
69 | * Schnorr signatures
70 | * Ed19255 signatures and Curve19255 keys
71 | * Miniscript
72 | * Eltoo \(SIGHASH\_ANYPREVOUT\)
73 | * OP\_CHECKTEMPLATEVERIFY
74 | * Lightning network
75 | * Atomic swaps
76 | * UTXO-based blockchains with Bitcoin script
77 | * Tor
78 | * Internet2
79 |
80 | ## History & Acknowledgements
81 |
82 | RGB was originally envisioned in 2016 by _Giacomo Zucco_ \(**BHB Network**\) as a "non-blockchain based asset system" basing on earlier ideas of _Peter Todd_ about client-side-validation and single-use-seals and implemented as original MVP around 2017 by BHB Network with support from **Poseidon Group**. Since 2019, _Dr Maxim Orlovsky_, **Pandora Core AG**, acts as the main designer and lead contributor to RGB protocol, designing and implementing more than 95% of its current code and underlying standards. Since 2019 RGB was restructured and re-thought from scratch by him as a generic form of computing and confidential smart contracting system. This refactoring happened as a part of **LNP/BP Standards** effort, created in 2019 and initially funded by **iFinex Inc** and **Fulgur Ventures** \(2019H2-2020H1\), and, later \(from 2020H2\), by **Pandora Core AG**, personal funds of _Dr Maxim Orlovsky_ and community donations. A lot of input into RGB design, re-design and protocol peer-review came from a broader community, which included contributions from more than 50 people and organizations, including:
83 |
84 | * _Christophe Diederichs_,
85 | * _Cláudio de Castro,_
86 | * _Chris Stewart,_
87 | * _Emil Bayes_,
88 | * _Fabrizio Armani_,
89 | * _Federico Tenga_,
90 | * _Juraj Bednar,_
91 | * _Martino Salvetti_,
92 | * _Max Hillebrand_,
93 | * _Marco Amadori_,
94 | * _Martin Habovštiak_,
95 | * _Nadav Kohen,_
96 | * _Nicola Busanello_,
97 | * _Rajar Shimaitra,_
98 | * _Rene Pickhardt_,
99 | * _Reza Bandegi_,
100 | * _[Sosthene](https://github.com/Sosthene00)_,
101 | * _Stefano Pellegrini_,
102 | * _[yojoe](https://github.com/yojoe)_,
103 | * _ZmnSCPxj_,
104 | * _Zoe Faltiba,_
105 | * _[zkao](https://github.com/zkao)_,
106 |
107 | The community and contribution management since 2019 was performed by _Olga Ukolova_, Pandora Core AG.
108 |
109 | Many input into protocol design ideas and suggestions came from personal conversations of Dr Maxim Orlovsky and Giacomo Zucco with notable cryptographers, specialists on distributed systems and game theorists, including:
110 |
111 | * _Adam Back,_
112 | * _Andrew Poelstra,_
113 | * _Christian Decker_,
114 | * _Christopher Allen,_
115 | * _Pieter Wuille,_
116 | * _Peter Todd,_
117 | * _Sabina Sachtachtinskagia,_
118 |
119 | We are thankful to the early adopters of RGB protocols, who invested and continue to invest into RGB integration and independent peer reviews:
120 |
121 | * HodlHodl
122 | * Bitfinex & Tether
123 | * Condensat Technologies
124 | * inbitcoin
125 | * SuredBits
126 | * Blockchain Of Things
127 | * Atomic Loans
128 | * Farcaster project
129 | * Sphinx
130 | * Nym
131 |
132 |
133 | # Contacts
134 |
135 | Basic information about the project can be provided by the developers in the
136 | [Telegram Group](https://t.me/rgbtelegram).
137 |
138 | # License
139 |
140 | 
141 |
142 | This work is licensed under a [Creative Commons Attribution 4.0 International
143 | License](http://creativecommons.org/licenses/by/4.0/).
144 |
--------------------------------------------------------------------------------