I am doing AI since 1998. Those days, when I wrote my first “AI” app in C for my Neuroscience PhD at Medical University - the app which was doing recognition of cells in microscopic images (it was also a “dApp” running on a computer cluster of the University network :) - those days the “AI” was still called “neural networks” and perceptrons. So I have some knowledge of the industry. It is so much fun seeing people being scared of digital parrots of ChatGTP kind - and governments addressing those “issues” in their usual “COVID dovecot” style (“fly in, shit over everything around and fly out”), that I can’t stop laughing. Yes, digital parrots will cause many people to lose their jobs - but this fact says much more about people lacking real intelligence than AI possessing any intelligence. Jobs were taken from people many times before - agriculture took the jobs of hunters, engineering took the jobs of slaves, automation took the job of factory workers etc, etc. None of them was a form of “intelligence” - neither ChatGPT is. Do you know who was fighting these technologies for the “good of people”? Luddites. So congrats to the EU, which is now run by Luddites - and those “advanced opinion leaders and innovators” from the “crypto industry” like Vitalik Buterin welcoming regulations. “Have fun staying stupid” - probably this should be the new meme for those who’d like to address neo-Luddites. But what about real GAI? Is it possible? Would it happen one day? So far, even most humans, possessing the same brain, is still not able to develop a proper generic natural intelligence (GNI), so what we can say about GAI? Of course, it is possible, but not with training on human-generated data sets of some large statistical models using differential equations and calling that “neural networks”. These neural networks are like guinea pig: not a pig - and not from Guinea: they are neither “neural” nor “networks”.

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).

I think #Bitcoin and #Crypto worlds do diverge. I see the foundation of #Bitcoin to be censorship resistance, and, as a result, unconfiscatability and freedom of monetary transactions. Others see the core of it as digital scarcity building hard and sound money - a long-term store of value (the second requires the first; however the first can also exist even without the second). I see #Crypto as a democratization of speculatory financial activities and gambling. Don’t get me wrong: I say that without a negative connotation, since I do believe both are important as a form of games. Children play games to develop their intelligence, adults play economic games and gamble with a skin in the game because of a similar reason: it is a way of competition and evolution of economical intelligent agents. If one day there would be an AI, it should start with a similar simulations. Another related goal of crypto is to make money which are not hard, but liquid money (becoming easy money as a result). Crypto talks a lot about decentralization, but in reality there is no real decentralization; they use an illusion of it as a way to distract regulators from attacking. This difference explains why crypto people do not understand bitcoin - and why bitcoin is not interested in crypto. In fact, they do not have any intersection at all! There is more to the equation: #cypherpunk, where Bitcoin has emerged, goes beyond what Bitocoin can do today, since it is more concerned about privacy than existence of hard and sound money (thus I do not consider projects like Monero or Grin to be crypto projects). However, Bitcoin still shares a lot with it, since real censorship-resistance and freedom of transactions is impossible w/o privacy - however the tradeoffs bitcoiners and cypherpunk are willing to pay are different (that’s why there is still no confidential transactions in Bitcoin, since absence of hidden inflation is more important for bitcoiners than privacy). BTW, #RGB is bridging this gap, but that’s another story. Finally, there is a crypto-anarchism, which, for the first look is similar to cypherpunk - but in reality it is much closer to the crypto world than bitcoin. Crypto anarchists are not worried about the nature of money; their focus is privacy as means of breaking attribution and having _any_ form of financial activity to be non-attributable. However, my own position touches all of these spheres (and to none of them in full): what I am looking for (and contribute in building) is private, uncensorable, unregulatable agoric finance still allowing voluntary disclosure. Decentralization here is not a fetish: it may still contain naturally-centralized parts (like asset issuers for shares or bonds), but in other cases decentralization may be necessary for maintaining censorship-resistance (like DEXes for the secondary markets of the shares). This is the vision we have in our Pandora Prime company building Pandora Network project, leveraging our developments in Bitcoin, Lightning and #RGB smart contracts made during past years as a part of LNP/BP Standards Association.

How #Storm ⛈️ differs from #Nost 🦩? Several years ago LNP/BP Standards Association presented Storm protocol suite for decentralized storage and messaging. It operates on top of #LightningNetwork ⚡️ and provides a way of setting up long-term trustless storage channels, as well as an API for structured data propagation, storage and - last but not least - querying. The first applications demonstrated in summer 2021 to work with Storm were file sharing 📂, chat 💬 and data transfer for client-side-validation #RGB smart contracting system 🔴🟢🔵 Storm provides functionality similar to #Torrent, #IPFS, more recent #Hyperdrive and other distributed data networks - but right next to Lightning channels, with linked Lightning payments and without use of DHTs. In other words, #Storm may be seen as #Nostr “on steroids” where: - relays are Lightning Nodes; - not all data has to be signed, opening use case beyond social networks; - embedded indexing and query capabilities allowing to build decentralized search engines (“decentralized Google”); - support for trustless data storage based on zero knowledge with specially-designed form of Lightning Storm channels; - data can be organized in application-based silos, and construct a DAG-based hierarchies; - data are binary, may provide a custom application-specific schema for their internal structure. Our recent #reNostr initiative uses the experience we have acquired while working on #Storm. It targets making #Nostr more scalable and robust, and will also provide an interoperability layer between #Storm and Nostr, such that Nostr data may be hosted by Lightning nodes via Storm protocol ☔️

The moment when you realize that #Rust 🦀 crates you made were downloaded more than 2 000 000 times

Introducing #reNostr: the effort to built faster, more secure & scalable #nostr upgrade. reNostr for Nostr is like SegWit for #Bitcoin  Join the work, which will be managed by Cyphernet - Swiss non-profit we are establishing with partners. reNostr will provide a reliable binary protocol - new transport for #RGB client-side-validated offchain data - as well as medium for new contracts distribution and some of DEX operations. It will be also used in other wallet-related workflows by MyCitadel wallet. Join the effort:

GitHub

GitHub - renostr/nrps: Nostr Reimplementation Possibilities

Nostr Reimplementation Possibilities. Contribute to renostr/nrps development by creating an account on GitHub.

I read comments from different devs on my recent #nostr PR (the link at the end of the post) and I think I start to understand why underdesigned protocols get higher adoption than thoughtfully-designed. Thise is not accidental; devs adopt protocols because they are able to understand them and play with them - and most of the devs (grown on stackexchange) have limited capacity to understand and contemplate about something (or just do not want to bother) - that is why “AI” is already able to make a work better than they do. That is why it is not the robustness or security which matters, but simplicity and as few components as possible. It is the reason why crazy-weird combinations like “Web technology” - an agglomerate of highly-inefficient and insecure HTTP, JavaScript etc - boosted internet adoption, while it took decades to solve this protocol issues with additions like SSL/TLS, HTTP/2, ECMAScript 6, TypeScript etc “ugly sticked as siding”. IT differs in these terms from other forms of engineering in a way that if in a physical world you would build something with this approach, it will kill people (like cars and electrical equipment can do that) - while in IT the risks are much lower (usually financial) and more tolerable, thus less advanced and secure systems emerge. So, there are two different strategies in protocol creation and adoption, similar r- and K-strategy in biology (

r/K selection theory - Wikipedia

): * r-strategy: very few devs, careful thoughtful design, high quality * K-strategy: no design, “evolution as it goes”, development by a crowd of low-quality devs, until eventually something will start working due to a pure “mining of chances” r-strategy always struggles with adoption, since “very few can understand it”. The only way r-protocols can be adopted is via products, which must be robust and good in UI/UX; i.e. not via dev community/crowd, but via people community/crowd. But usually r-products are not loud in marketing (the only exception is probably apple products - with NeXSTEP-based tech and product/language design teams being very r-like) On the opposite, with K-strategy, things like JSON happen because they allow not to design a protocol - they are sufficiently agile and malleable to any protocol changes and things will contrinue to “sort of working” - thus devs can start with a “no design” and stick random elements into the network until something would start working. 99% of these protocols will die, but out of 1000 attempts one nostr will appear. So any carefully-thought solution to nostr design issues (which will cause its painful growth/scaling in the future) is doomed: nostr devs see these not as a design issues but as features that allow them to build products without designing the protocol per se, leveraging JSON agility. So they agree to migrate to binary formats _only_ if they are same flexible as JSON - while the main problem is not a text/binary format but that flexibility, which will cause network decoherence - or centralization around oligopoly of “standard” relays. The funny part is that this r-strategy still can be the strategy which wins. Details:

GitHub

NIP-88: binary event encoding by dr-orlovsky · Pull Request #512 · nostr-protocol/nips

At the present moment nostr (NIP-1) uses text serialization of the event data, represented in a form of a JSON object. While being simple-to-implem...

Have found a definition for #nostr I am comfortable with: Nostr is self- and shared-hosted trustless event logs. (Nostr relay is a self- or shared-hosting thing) It had started as a platform for social networking, but can be used for groupware and corp applications, cross-device app synchronization, attestation logs and many other things.

Lightning was supposed to solve on-chain congestion problem, not join it! Routing nodes now have to reserve up to thousands of $ for fees: this is the way LN is designed today (example of how this might happen can be found in

X (formerly Twitter)

Mion (@MionGroup) on X

11: However, in a channel jamming scenario, 483 pending HTLCs might need to be included, meaning we’ll end up with a transaction of about 15,113...

It doesn’t mean this money are lost, but they have to be subtracted from the channel balance, increasing existing LN liquidity problems. One of the strategies the nodes may follow will be to stop routing until good fees are back - and keep commitment transactions originating from the times when fees were low. Current software doesn’t support this, but the future versions may do. This will mean that with high onchain fees LN will degrade in performance and liquidity too.

NIP-88 proposal adding support for the binary encoding of #nostr events: all file services, munsters and devs suffering from slow JSON serialization - I know you was looking for a such thing :)

GitHub

NIP-88: binary event encoding by dr-orlovsky · Pull Request #512 · nostr-protocol/nips

At the present moment nostr (NIP-1) uses text serialization of the event data, represented in a form of a JSON object. While being simple-to-implem...

This is the first proposal in the series I will do to address the points of my recent #nostr critique

Damus

dr.orlovsky on nostr

Thoughts on #nostr. Nostr is a websockets-based text protocol f

MyCitadel v1.3 is around the corner with some great updates: ability to compose complex time-locked conditions (like 2-of-4 multisig which in 1 year becomes 1-of-2). A tx created with MyCitadel spending from such complex miniscript descriptor:

The Mempool Open Source Project®

Explore the full Bitcoin ecosystem with The Mempool Open Source Project®. See the real-time status of your transactions, get network info, and more.

Miniscript descriptors with timelocks were available since the first release of our desktop wallet, but due to miniscript inability to work with the same keys in different pre-taproot script branches it was impossible to create non-trivial setups. The new version will introduce account-based spending conditions such that different branches now may use different accounts coming from the same hardware signer.

Descriptor wallet got updated to v0.9.2 with better command-line explorer functions: miniscript support, tx fee & minimg info, P2W* witness parsing, RBF info and colors! `cargo install descriptor-wallet --all-features`

GitHub

Release Descriptor Wallet v0.9.2 · BP-WG/descriptor-wallet

What's Changed Improved command-line explorer: Transaction weight and fee information Parsing witness data for P2WPKH and P2WSH outputs Miniscript...

I was thinking of what nostr is. The initial concept I had was that nostr is a specific client-server (relayed) protocol for social network defined as NIP-1, plus extensions on top. Now tend to see nostr is some other way. Nostr is the way of producing public authentificated data feeds by pseudonymous web-of-trust identities. NIP-1, existing relays etc are just current implementation details, which may change. What would always remain are the data feeds linked to decentralized identities.