Dr Maxim Orlovsky

RGB yellow paper is released: the first formally specified scalable smart contract system for Bitcoin & Lightning, made with client-side validation 📄.pdf

Libre software is dead. Long live zk-libre software. The libre software was created to protect the rights of consumers: when they buy software, they must get the whole thing, not a part: (0) ability to run, (1) ability to learn from how it is done, (2) ability to redistribute, (3) ability to modify. Well, this was an excellent strategy against Microsoft and alike. But today it turns its back to individual developers, - those investing years and their own money to do the R&D - and then having large companies just stealing the result. This is fixable - by what I call zk-libre software. Zk-libre software grants the following FIVE core freedoms to the consumer: (I) ability to run, (II) ability to learn - from reverse-engineering, or docs and specs, coming with it, (III) ability to redistribute, (IV) ability to modify a reverse-engineered version or a re-implementation, created by learning the specs and docs, (V) ability to ensure the software has no backdoors and is formally-verifiable to be safe and secure, as well as proven not to misuse the user data. It also protects DEVELOPERS rights, their intellectual work and allows them to receive the reward and funding they deserve. These all are achieved by zk-proofs of the software properties. It would take decade(s) to make it possible, but we should start already today. The software which will be developed by individuals and meritocratic teams, with no spirit of egalitarianism and leftism, poisoning “open source” fake idol of today. #freesoftware #libresoftware #opensource #zklibresoftware #freedomtech #freedom

Our first post on Stacker News. What do you think if we will create a dedicated RGB topic and community there, will you be participating it?

Stacker News

RGB v.11 beta 8 released marking start of pre-release freeze \ stacker news ~bitdevs

RGB is a client-side validation layer on top of Bitcoin and Lightning, first of its kind, providing smart contracts capabilities. It's being in the...

Sometimes decentralized systems are worse than centralized. When? Well, if we talk about individuation, centralized self-sovereignty beats decentralized social fascism. Thus, the need is not to decentralize everything - but to build freedom-preserving tech infrastructure: an infrastructure where society and its golems (state, common good, crowd, democracy) can’t destroy individual freedoms. Privacy is a cornerstone to that.

Feeraiser. Part 1: Chainbound forever. Once upon a time, far away, but not long ago, one Bitcoin hodler had held his sats for many years, throughout bull and bear cycles, never selling - just stacking. He never trusted software keys - thus was using only hardware wallets. He never trusted a single vendor - thus was using only multisigs. He did only air gapped setups, to prevent leaking any information - and he had metal backups of his seed words. One day a new air gapped hardware wallet had appeared on the market - with beautiful golden engravings and bitcoin signs all around. Instead of using chips (which can’t be trusted) it was using elaborate mechanical puzzle construction to compute addresses and signatures - and expose them as golden QR codes on its surface. He decided he needed to set up a new multisig with this device - and move all his funds on it, for them to be held in a much more secure and cold way. He sent some sats to the new multisig first - to test it - and sent them back. It all worked well. Thus he did a new transaction, spending all his existing sats - and paying them as to a thousand new outputs, all under the new multisig. Everything went smoothly, except… The new key, returned by the new device, was unspendable - and our hodler was doing 6-of-6 multisig. He didn’t know that complex device mechanics were a puzzling trap, and once the first successful payment was done the device had changed its inner configuration to generate only unspendable keys. He sent his transaction - but he put a high fee for it since he knew that blockspace was filled with some ordinal and inscription spam. The transaction got mined instantly - a new block had appeared within several seconds. The luck wasn’t without holder today: he didn’t know that the new multisig was unspendable. He kept stacking for many more years, and most of his transactions got buried under years and years of new blocks ... ... until one day, when bitcoin hit 10m and he urgently needed some money to have an emergent surgery for one of his kids he discovered that he was fooled by the box. He tried to increase the fees for at least the last transactions which he did just a few days ago - pitting them higher and higher until most of the output values were going into fees - but that price was still too small to force the miners to re-org. His sats now remain chained to the old blocks forever - buried under so much PoW that it will be unprofitable to do such a deep re-org which can return his original transaction back. The poor bitcoiner got mad and stayed in his room till the end of his days, trying to manually solve the puzzle and find a combination returning a private key for the public keys generated by the box.

Here is my line of thoughts on #BiFi. Of course, >10 min for confirming tx with just dozen tx-per-sec throughput will not run financial system - as it can’t run money or payment system (not to mention lack of privacy/publicity, which is worse than in VISA/MC). Thus, #Bitcoin blockchain is a non-go. There are just two approaches to solve the issue: - build layers on top, providing scalability; - replace layer one (get rid of blockchain). 1. Layers on top. First, one can’t solve problems of blockchain by doing more blockchains. Thus, side/drive/crazy/*/chain-approach changes nothing in this regard. Yes, you can experiment with them or do some interesting stuff - but that is not our topic here. Next, we have Lightning, Enigma and Ark. The last two require softfork to be trustless, so this is years - but I think they can be a solution. Current Lightning (I call it Lightning BOLT, by the name of the current standards) fails with liquidity scaling - the infamous inbound liquidity problem. It also can’t route non-fungible state (not just NFT, but for instance bonds, which are usually non-fungible), thus for financial industry (but also for global payments) it will not work as it is. The only way for making Lightning working is to build multi-peer channels, where no inbound liquidity problem is present, and where you can operate non-fungible state. This is the future #1 for #BiFi. I just discovered that there is a proposal on this matter, which may enable such future: multipeer Nucleus Lightning channels - 📄.pdf Channel factories and other approaches are a bit worse: they either require softforks (like eltoo), require all peers to be online (thus poor sybil resistance and scalability) or less efficient in liquidity management. Other ways - like fedimints - are trusted, thus it is not what we are interested in here (no benefit over trusted crypto DeFi like on Arbitrum or zk rollups). 2. Replacing blockchain. The only proposal for that is #prime, but I expect more to come (

[bitcoin-dev] Scaling and anonymizing Bitcoin at layer 1 with client-side validation - Dr Maxim Orlovsky

). With prime, you do not need soft/hardforks, Lightning or anything else: it is quite simple to be built within a ~year (prime is simpler than bitcoin blockchain, all the business/verification is moved to RGB, which is already working). The only problem with prime is that for $BTC one can move in - but not come back to Bitcoin blockchain in a trustless way. I do not see that as a problem at all (there will be those taking the risk, and the adoption will gradually build, with most of bitcoins eventually moving to the prime), but some hodlers are afraid. Well, I will leave them alone so they can push for their favorite soft-forks for enabling trustless pegouts: zk-opcodes, simplicity, some advanced schemata with CTV/APO etc - or drivechains, if they think that economically-incentivized miners can be trusted due to some Nash equilibriums. Anyway, I do not care on that part and the future of #BiFi on prime/RGB doesn’t depend on them: if bitcoiners will be slow to move to prime, those who were brave enough with moving BTC one way will have their BTC priced higher, leading more BTC to move there - and so on. TL;DR: Without softfork one can build #BiFi either with Nucleus multipeer Lightning channels (hard way) or on #prime (easy way). With a softfork some Ark/Enigma/channel factories can also become an option - but a softfork will take >2 years and by that time we may either have prime or Nucleus. PS: What’s Next Those interested in designing & building #prime can join tech group by LNP/BP Association here:

Telegram

Prime - scalable Bitcoin layer 1

You can view and join @prime_layer1 right away.

LNP/BP Association

LNP/BP Association

Non-profit supervising development of layers for Bitcoin

is the non-profit leading #RGB, #prime, multipeer channels development, which needs grants/patrons for 2024 In

PandoraPrime

PandoraPrime

Pioneering Bitcoin Finance

we are building products for the described #BiFi stack and are looking for VCs

This year we are excited to bring more #RGB #Bitcoin  and #Lightning products - read about them and our business strategy on our updated website:

PandoraPrime

PandoraPrime

Pioneering Bitcoin Finance

A new tool for those interested in developing for #RGB has arrived:

RGB protocol

RGB smart contracts explorer

Find RGB assets, issuers, interfaces, schemata, developers

It is an explorer for the world of Bitcoin Finance #BiFi and smart contracts on #Bitcoin & Lightning ⚡️- and it is supports all the new #RGB 🚥 features from the latest v0.10 release. The interesting thing about it is that it is made without a single line of JavaScript on both client and server side. Client-side it is just pure HTML and CSS, no trackers or google analytics etc; server-side - it is made with rust (rocket.rs), not ysing any cookies or authorization.

MyCitadel 1.4 "Ivana Kupaly" has arrived! It ships with a number of usability improvements, bugfixes and new distributive formats. UI improvements * Improved fonts and colors for the transaction list * Context menus for transaction, address and coin lists * Copy txid, address, amounts, heights to clipboard via context menu * Ability to pay full wallet balance to an address Bugfixes * Fixed date & time precision for the list of transactions * Fixed display of transactions in mempool * Fixed signer renaming persistence in wallet settings * Fixed scrolling for the list of beneficiaries in the transaction composer Distributive * New distributive format: AppImage (!) * Included Python packaging in Windows, simplifying the installation process 📦 Grab it here:

GitHub

Release Version 1.4 (Ivana Kupaly) · mycitadel/mycitadel-desktop

MyCitadel 1.4 ships with a number of usability improvements, bugfixes and new distributive formats. UI improvements Improved fonts and colours for...

Or use `cargo install mycitadel` from the command line.

#RGB scalability is mind blowing: A single #Bitcoin  UTXO may contain assets from 100k different contracts - and all of them may be transferred in one tx. For 200 outputs - 2m contracts (!) Ethereum has ~2m contracts; all their state evolution can fit in a dozen of RGB bitcoin transactions.