dr.orlovsky
Dr Maxim Orlovsky

https://dr.orlovsky.ch

Towards the stars, using aspera as weapons. Cypherpunk, AI, robotics, transhumanism. Creator of #RGB #BiFi #AluVM #Contractum. #Bitcoin dissectionalist

Public Key

npub13mhg7ksq9efna8ullmc5cufa53yuy06k73q4u7v425s8tgpdr5msk5mnym

NIP-05 Address

[email protected]

Profile Code

nprofile1qqsgam50tgqzu5e7n70lau2vwy76gjwz8at0gs270x242gr45qk36dcpz4mhxue69uhk2er9dchxummnw3ezumrpdejqu7qr46

Publishing to

eden.nostr.land

Author Public Key

npub13mhg7ksq9efna8ullmc5cufa53yuy06k73q4u7v425s8tgpdr5msk5mnym

Show more details

Last Notes

2025-07-31 11:44:10 UTC

RGB yellow paper is released: the first formally specified scalable smart contract system for Bitcoin & Lightning, made with client-side validation
https://github.com/RGB-WG/yellowpaper/blob/master/rgb-yellowpaper.pdf

2025-07-29 14:39:55 UTC

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

2024-09-06 22:41:22 UTC

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?
https://stacker.news/items/675088

2023-09-17 13:50:28 UTC

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.

2023-09-16 14:49:17 UTC

- reply

This will be a “Feeraiser: Bitcoin horror legends” series - horrifying stories about how Bitcoin fee management capabilities can be misused. I will publish a story each day.
Feeraiser. Chainbound forever.
Feeraiser II. Child pays for parents.
Feeraiser III. Zero confirmation ground.
Feeraiser 4. You’ve got replaced by fee.
Feeraiser 5. Lost in the memory pool.

2023-09-16 14:45:18 UTC

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.
https://24.media.tumblr.com/1db228d4767adb83c4e331eaaabfac51/tumblr_myjo4hzjw21rp0vkjo1_500.gif

2023-09-09 08:58:15 UTC

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 - https://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230820/bfb41b20/attachment-0001.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 (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021732.html).
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: https://t.me/prime_layer1
LNP/BP Association https://www.lnp-bp.org is the non-profit leading #RGB, #prime, multipeer channels development, which needs grants/patrons for 2024
In https://pandoraprime.ch we are building products for the described #BiFi stack and are looking for VCs

2023-07-20 14:04:50 UTC

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

2023-07-17 22:54:22 UTC

- reply

Thank you! APIs are not yet documented

2023-07-17 21:58:16 UTC

A new tool for those interested in developing for #RGB has arrived: https://rgbex.io
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. https://cdn.nostr.build/i/d4c48680e9e49c5980a81c0e3f27aaaf604b5b6093466a4fa70eee7941d9a12b.png https://cdn.nostr.build/i/e3b63f89b1b0714b1f3f31efbea195fe34a0bfa224e5a3bf980b136878834af1.png

2023-07-13 14:20:07 UTC

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: https://github.com/mycitadel/mycitadel-desktop/releases/tag/v1.4.0
Or use `cargo install mycitadel` from the command line.
https://void.cat/d/FfqgzjCdfj3smZg6TBxNR6.webp
https://void.cat/d/EAthUaEZ8eA1e2jaSggHBq.webp

2023-07-10 22:53:19 UTC

#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.
https://thumbs.gfycat.com/CheeryEnchantedHuia-size_restricted.gif

2023-06-19 00:30:09 UTC

- reply

The call stack overflow which will terminate infinite recursion is the difference.

2023-06-19 00:25:59 UTC

The question of trust is the fundamental question for the future of our civilization - and Universe as a whole.
The economy is made of contracts. They either must be enforced through central authority (thus trusted) - or in a trust-minimized way by some technological means. However trust to central authority means unification, always leading to loss of adaptivity and extinction.
The idea that “blockchain technology” can solve the trust issue is a fallacy: even if consensus protocols can solve some aspects of trust (like in PoW), the solution is unscalable - and all other aspects of trust can’t be solved at all.
Contracts, as well as an economy, can be seen as a computation in a multi-agent system. The way one agent can prove something to the other agent without leaking sensitive information (i.e. preserving privacy) is by providing zk-proofs of its own state (or computation on a contract). Unlike blockchain, this can scale - and doesn’t leak privacy into an informationally-centralized (i.e. transparent) public ledger (aka blockchain).
Economy means computing. Economy can’t exist without heterogenous autonomous self-sovereign agents - thus not only humans, but also AI-based agents - or other species after humanity will fork into multiple species or will face other civilizations. Privacy is fundamental. Zero-knowledge computing - and not blockchain - is the solution. https://nostr.build/i/be6d7aca2ab28d4b0acca06496515e8ed089a1a50a239c292364ee11052048ef.jpg

2023-06-03 16:57:19 UTC

- reply

Since I do not care what do you think - and do what I will to do. Go and stop me, uneducated fool not knowing the difference between Taproot and Taro.

2023-06-03 16:40:44 UTC

- reply

… and layer 1
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021732.html

2023-06-03 16:39:25 UTC

- reply

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021732.html

2023-06-03 16:37:51 UTC

- reply

Seem like you read words on the internet and randomly put them in sentences not understanding the meaning behind them.
Taro enabled ordinals. Lol. And bitcoin enabled covid.

2023-06-03 15:14:51 UTC

- reply

“Thus I do not care how people will transfer their valuable sats (which some of them value more than their life and the lives of their relatives, see the quoted discussion) to Prime - and back. I prefer if they never transfer and would leave me without the need of answering to their fears of loosing their hoards and bags. If somebody is afraid - do not burn/send your sats, that’s simple!!! And nothing will happen to the loved blockchain, sats, bags - even when the death will come. Maybe one day they will find that nobody else than themselves and few hundreds of other scarcity lovers is using blockchain, will freeze UTXO, stop the mining and will free happy - I do not care. “
https://twitter.com/dr_orlovsky/status/1664727595974381569

2023-06-03 15:09:48 UTC

- reply

Here is how you can do them without a blockchain: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021732.html

2023-06-03 14:48:29 UTC

- reply

Just lol.
Fyi: https://twitter.com/giacomozucco/status/1664515543154544645

2023-06-03 14:47:33 UTC

- reply

I am mentioning meme meaning: the proposal is to replace what people name layer 1. They name it, not me :) In order to be understood I have to use common names.

2023-06-03 14:02:04 UTC

- reply

I think all the buzz around layer 1, 2, 3 is just memes and marketing, so do not take that too serious.
If I was doing a classification, bitcoin PoW consensus and block headers is layer 1.
Bitcoin blockchain blocks, merged mining chains is layer 2.
Sidechains is layer 2+i.
Lightning is layer 3.
RGB is layer 2.71828 (Euler number).
But this has zero chances of becoming a meme.

2023-06-03 13:57:17 UTC

- reply

Yes, still WIP

2023-06-03 13:56:08 UTC

- reply

The proposed solution doesn’t tries to solve blockchain problems. It is targeted to replace it.
Miners mining billions of tx per minute will certainly earn more in fees than today with subsidiary and fees from few thousand of transactions per 10 mins

2023-06-02 09:20:00 UTC

- reply

It is on-blockchain L1 - but still Bitcoin and $BTC. Neither Bitcoin nor $BTC equals blockchain - and they never had.

2023-06-01 18:00:41 UTC

“Scaling and anonymizing Bitcoin at layer 1 with client-side validation” - our new proposal, also sent to bitcoin-dev mail list.
https://github.com/LNP-BP/layer1
“We propose a way to upgrade Bitcoin layer 1 (blockchain/timechain) without a required softfork. The upgrade leverages properties of client-side validation, can be gradual, has a permissionless deployment option (i.e. not requiring majority support or miner cooperation) and will have the scalability sufficient to host billions of transactions per second. It also offers higher privacy (absence of publically available ledger, transaction graphs, addresses, keys, signatures) and bounded Turing-complete programmability with a rich state provided by RGB or another client-side-validated smart contract system.”

2023-05-17 11:44:33 UTC

On money, liquidity and eurodollar - or why stablecoins more often used as money comparing to bitcoin - against Austrian economics expectations - and in the future this doesn’t seem to change.
Imaging you run a factory producing metal chunks. Your supplier is an iron mine. A client who bought last consignment from you is late with the payment - but you still need to buy from the supplier to produce the next consignment.
Normally what you do is you go to the bank and take a loan - a credit against collateral of your factory assets (equity shares, goods and other forms of capital). However, during crisis fiat banks avoid high risk and do not provide credit - or ask interest rate which destroys your business model. That is why central bank system has emerged as a credit of last resort - but as we know it doesn’t work as expected.
In hyperbitcoinized world if you go to bitcoin hodlers (new form of bankers) - they would put even higher interest rate to match the bitcoin volatility risks. Thus, you can’t operate under such conditions.
Where are we left? A good factory with no real problems has cease to operate/stop ovens (which kills them) - why? Because there is no liquid money in form of credit available - and #Bitcoin doesn’t seem to be fixing that in any way (instead it will make the problem to be worse than in the gold standard age, since the gold can be mined - while bitcoin, after some period, is not).
So what market participants will do? First they will switch to barter (like in post-USSR in early 90-th), but because of its inefficiency soon they will invent their own credit liquid money - and, if it would happen today, it will be probably on form of crypto. This will be an IOU money. Eventually a new private banks will emerge which will be producing those money in return for collateral, doing risk scoring.
This is why I am after private banking school of economics - and not Austrian nonsense about economics being able to run with hard money made of scarcity. Money must be liquid.
This is the use case for crypto or digital finance - and the reason why stable coins gain such tracktion (before them it was eurodollar, which is in fact a private banking money not managed by central banks - a dominant form of money in the world as of today).

2023-05-16 09:18:13 UTC

- reply

Not yet, will have a look. Thank you!

2023-04-15 13:46:55 UTC

- reply

TL;DR:
1. Choice of crypto: nostr picked “bitcoin crypto starter pack”. But what is good for blockchain may be bad for network: it is ultra-slow and non-standard in digital identity world (incompatible with PGP/SSH)
2. Choice of javascript-style (no data typing): vectors for DoS attacks, slow speed, low extensibility
3. No end-to-end encryption
Overall: very vulnerable to DoS, incompatible with other decentralized identity schemata, will have scalability problems.

2023-04-15 13:16:15 UTC

Thoughts on #nostr.
Nostr is a websockets-based text protocol for logs of authenticated (but unauthorized) tagged (and otherwise unstructured) messages stored at public relay servers. The rest is a specific nostr application (like social networking or payments) on top of it.
Nostr takes several decisions on possible tradeoffs, which I try to analyze here:
1. Websockets. Good: pub/sub data access, web-integratable. Bad: high load on relay servers limiting scalability. Verdict: ⚠️
2. Elliptic curve (secp256k1) for identities. Good: bitcoin-based. Bad: very low performance, not GPG/SSH compatible, sidechannels. Overall: ❌.
3. Signature scheme: BIP-340 Schnorr. Good: batch verification, standard. Bad: optimized for onchain, discarding y coord, making verification ~50% more expensive than non-BIP Schnorr. Verdict: ⚠️
4. Hashing function: SHA256. Good: standard, bitcoin. Bad: slower than BLACKE3. Verdict: ⚠️
5. Text JSON encoding. Good: easy to implement. Bad: hard to pass & slow to encode/decode non-text/binary data; no limits on data sizing opening a door for DoSing relays and clients. Verdict: ❌
6. No authorization scheme. Good: easy to implement. Bad: limits use cases, limits scalability. Verdict: ⚠️
7. No encryption on the transport level, relying on TLS. Good: easy to implement. Bad: centralized, not end-to-end. Verdict: ⚠️
So I see most of selected tradeoffs by Nostr as a bad or poor decision. This us arguable of course.
Can Nostr survive and success? For sure, if even much worse systems had done that in the past (Ethereum, JavaScript, PHP).
What is the greatest Nostr weakness? Limited scalability and possible DoS (not even DDoS) attacks.
If I were the one who did nostr, what I would had made differently? I would had used Ed25519 signatures on Ristretto25519 (speed), binary encoding with strict limits on data sizes, use Noise_XK encryption - and provide bridges to Websockets only when they are needed for the web. But we have what we have.
https://nostr.build/i/nostr.build_11196a0ce77932638fc00edde9487a49f50697c768eb16f91ed1fc1a3b60726c.jpeg