├── .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 | ![Creative Commons License](https://i.creativecommons.org/l/by/4.0/88x31.png "License CC-BY") 141 | 142 | This work is licensed under a [Creative Commons Attribution 4.0 International 143 | License](http://creativecommons.org/licenses/by/4.0/). 144 | --------------------------------------------------------------------------------