dr.orlovsky
Dr Maxim Orlovsky
Towards the stars, using aspera as weapons. Cypherpunk, AI, robotics, transhumanism. Creator of #RGB #BiFi #AluVM #Contractum. #Bitcoin dissectionalist
Public Key
npub13mhg7ksq9efna8ullmc5cufa53yuy06k73q4u7v425s8tgpdr5msk5mnym Profile Code
nprofile1qqsgam50tgqzu5e7n70lau2vwy76gjwz8at0gs270x242gr45qk36dcpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds4xnxwh
Show more details
Published at
2023-05-06T18:10:05Z Event JSON
{
"id": "8b7120fe45a8376911214641e692cea39629cbc571ebe0869a51d9c1a37dfb42" ,
"pubkey": "8eee8f5a002e533e9f9ffef14c713da449c23f56f4415e7995552075a02d1d37" ,
"created_at": 1683396605 ,
"kind": 0 ,
"tags": [],
"content": "{\"banner\":\"https://pbs.twimg.com/profile_banners/90660251/1653252769/1500x500\",\"website\":\"https://dr.orlovsky.ch\",\"nip05\":\"[email protected] \",\"picture\":\"https://nostr.build/i/nostr.build_8e0117fecac8c630d4482f1c3ed24b3187df54aae2a967ed194d6d88de1247a9.jpeg\",\"lud16\":\"[email protected] \",\"display_name\":\"Dr Maxim Orlovsky\",\"about\":\"Towards the stars, using aspera as weapons. Cypherpunk, AI, robotics, transhumanism. Creator of #RGB #BiFi #AluVM #Contractum. #Bitcoin dissectionalist\",\"name\":\"dr.orlovsky\"}" ,
"sig": "d331e72bddb0def5864811c5e3f4aab2eb2294ae5cfc5c03553955743dd00200fd64489db83569ced2a47e981e18dfd4c10ef6f8446ffdc4e54acbc184a0c036"
}
Last Notes npub13mhg7ksq9efna8ullmc5cufa53yuy06k73q4u7v425s8tgpdr5msk5mnym dr.orlovsky “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.” npub13mhg7ksq9efna8ullmc5cufa53yuy06k73q4u7v425s8tgpdr5msk5mnym dr.orlovsky 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). npub13mhg7ksq9efna8ullmc5cufa53yuy06k73q4u7v425s8tgpdr5msk5mnym dr.orlovsky 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. npub13mhg7ksq9efna8ullmc5cufa53yuy06k73q4u7v425s8tgpdr5msk5mnym dr.orlovsky 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