@ c230edd3:8ad4a712

When beechen buds begin to swell,

And woods the blue-bird’s warble know,

The yellow violet’s modest bell

Peeps from the last year’s leaves below.

Ere russet fields their green resume,

Sweet flower, I love, in forest bare,

To meet thee, when thy faint perfume

Alone is in the virgin air.

Of all her train, the hands of Spring

First plant thee in the watery mould,

And I have seen thee blossoming

Beside the snow-bank’s edges cold.

Thy parent sun, who bade thee view

Pale skies, and chilling moisture sip,

Has bathed thee in his own bright hue,

And streaked with jet thy glowing lip.

Yet slight thy form, and low thy seat,

And earthward bent thy gentle eye,

Unapt the passing view to meet

When loftier flowers are flaunting nigh.

Oft, in the sunless April day,

Thy early smile has stayed my walk;

But midst the gorgeous blooms of May,

I passed thee on thy humble stalk.

So they, who climb to wealth, forget

The friends in darker fortunes tried.

I copied them—but I regret

That I should ape the ways of pride.

And when again the genial hour

Awakes the painted tribes of light,

I’ll not o’erlook the modest flower

That made the woods of April bright.

@ 4c96d763:80c3ee30

Changes

Ken Sedgwick (5):

• drive-by clippy fixes
• add add relay GUI
• add Accounts::add_advertised_relay
• upgrade url string to RelaySpec for [read|write] markers
• publish NIP-65 relay lists

William Casarin (7):

• persistent: dont nuke decks when using cli columns
• envrc: update vrod's npub for testing
• note: introduce RootNoteId
• enostr: introduce PubkeyRef
• mutes: hide logs
• debug: log when adding notes to start
• switch to TimelineCache

greenart7c3 (1):

• Fix side panel color when using light theme

kernelkind (2):

• log nip05 error
• fix persist deck author profile bug

kieran (4):

• note-ref: derive hash
• move Notedeck to notedeck crate
• export enostr / nostrdb
• Always update accounts

pushed to notedeck:refs/heads/master

@ c230edd3:8ad4a712

To him who in the love of Nature holds
Communion with her visible forms, she speaks
A various language; for his gayer hours
She has a voice of gladness, and a smile
And eloquence of beauty, and she glides
Into his darker musings, with a mild
And healing sympathy, that steals away
Their sharpness, ere he is aware. When thoughts
Of the last bitter hour come like a blight
Over thy spirit, and sad images
Of the stern agony, and shroud, and pall,
And breathless darkness, and the narrow house,
Make thee to shudder, and grow sick at heart;—
Go forth, under the open sky, and list
To Nature’s teachings, while from all around— Earth and her waters, and the depths of air— Comes a still voice— Yet a few days, and thee
The all-beholding sun shall see no more
In all his course; nor yet in the cold ground,
Where thy pale form was laid, with many tears,
Nor in the embrace of ocean, shall exist
Thy image. Earth, that nourished thee, shall claim
Thy growth, to be resolved to earth again, And, lost each human trace, surrendering up
Thine individual being, shalt thou go
To mix for ever with the elements,
To be a brother to the insensible rock
And to the sluggish clod, which the rude swain
Turns with his share, and treads upon. The oak
Shall send his roots abroad, and pierce thy mould.

Yet not to thine eternal resting-place
Shalt thou retire alone, nor couldst thou wish
Couch more magnificent. Thou shalt lie down
With patriarchs of the infant world—with kings,
The powerful of the earth—the wise, the good,
Fair forms, and hoary seers of ages past,
All in one mighty sepulchre. The hills
Rock-ribbed and ancient as the sun,—the vales
Stretching in pensive quietness between;
The venerable woods—rivers that move
In majesty, and the complaining brooks
That make the meadows green; and, poured round all,
Old Ocean’s gray and melancholy waste,—
Are but the solemn decorations all
Of the great tomb of man. The golden sun,
The planets, all the infinite host of heaven,
Are shining on the sad abodes of death,
Through the still lapse of ages. All that tread
The globe are but a handful to the tribes
That slumber in its bosom.—Take the wings
Of morning, pierce the Barcan wilderness,
Or lose thyself in the continuous woods
Where rolls the Oregon, and hears no sound,
Save his own dashings—yet the dead are there:
And millions in those solitudes, since first
The flight of years began, have laid them down
In their last sleep—the dead reign there alone. So shalt thou rest, and what if thou withdraw
In silence from the living, and no friend
Take note of thy departure? All that breathe
Will share thy destiny. The gay will laugh When thou art gone, the solemn brood of care
Plod on, and each one as before will chase
His favorite phantom; yet all these shall leave
Their mirth and their employments, and shall come And make their bed with thee. As the long train
Of ages glide away, the sons of men,
The youth in life’s green spring, and he who goes
In the full strength of years, matron and maid,
The speechless babe, and the gray-headed man—
Shall one by one be gathered to thy side,
By those, who in their turn shall follow them.
So live, that when thy summons comes to join
The innumerable caravan, which moves
To that mysterious realm, where each shall take
His chamber in the silent halls of death,
Thou go not, like the quarry-slave at night,
Scourged to his dungeon, but, sustained and soothed
By an unfaltering trust, approach thy grave,
Like one who wraps the drapery of his couch
About him, and lies down to pleasant dreams.

@ da18e986:3a0d9851

Since DVMs were introduced to Nostr in July 2023, we've witnessed remarkable growth - over 2.5 million DVM events (Kinds 5000-7000) and counting. Last fall, when Primal added custom feeds (Kind 5300 DVMs), we saw a 10x surge in DVM activity. To handle this growth, I've spent the last few months completely rewriting DVMDash.

The first version of DVMDash, still live at https://dvmdash.live, unfortunately uses full database table scans to compute the metrics. The code was simpler, but the computation ran on the database. This meant the only way to scale the system was to upgrade the database. Using managed databases (like AWS, Azure, Digital Ocean) beyond the lower tiers gets expensive quickly.

The other problem with the first version: it computes metrics globally (well... as global as you can get; there's no true global with Nostr). Global or all-time metrics aren't sustainable with a system that plans to analyze billions of events in the future (a long term goal for DVMDash). Especially metrics like the number of unique DVMs, Kinds, and Users. I spent more time than I care to admit on possible designs, and have settled on these design principles for now:

1. Precise accurate metrics will only be computed for the last 30 days of DVM activity.
2. At the turn of a new month, we will compute a snapshot of the last month's activity, and a snapshot per DVM and per Kind, and store them in a historical table. This way we can see what any given month in the past looked like from a bird's eye view with metrics like number of job requests, job results, a count of unique DVMs, kinds and users, which DVMs ran jobs on which kinds, etc. The monthly data will all be aggregate.

The goal of the new redesign is to support processing millions of DVM events an hour. Therefore we need to ensure we can horizontally scale the processing as the traffic increases. Horizontal scaling was the primary goal of this new redesign, and early results indicate it's working.

The new architecture for DVMDash uses a redis queue to hold events collected from relays. Then batches of events are pulled off of the queue by dvm event analyzers to compute metrics. Duplicating these analyzers is one way DVMDash can horizontally scale.

To see if increasing the number of dvm event analyzers improves speed, I ran a performance test on Digital Ocean using real DVM events collected from Jan. 1st 2024 to Jan 9th 2025, which includes more than 2.4 million events. The only difference between each run is the number of DVM event analyzers ranging from 1 to 6.

The first graph shows that adding more event analyzers has a significant speed improvement. With only one analyzer it took nearly an hour to process the 2.4 million events. With every added analyzer, there was a noticeable speedup, as can be seen in the graph. With n=6 analyzers, we were able to process all 2.4 million events in about 10 minutes.

When we look at the rate of processing shown in the second graph, we can see that we get up to 300k dvm events processed per minute when n=6, compared to just ~50k events processed when n=1.

While I did test beyond 6 analyzers, I found the sweet spot for the current infrastructure setup to be around 6 analyzers. This provides plenty of headroom above our current processing needs, which typically see less than a million events per month. Even at a million DVM events per day, DVMDash should be able to handle it with n=2 analyzers running. The most important takeaway is that DVMDash can now horizontally scale by adding more analyzers as DVM activity grows in the future.

The code to run these performance tests, either locally or on Digital Ocean (you'd need an API key), is in the dvmdash repo, so anyone can replicate these tests. There's a lot of nuance to scaling that I'm leaving out of this short article, and you can't get away from having to adjust database capacity (especially number of connections). The code for this test can be found in experiments/test_batch_processing_scaling.py and the code to produce the graphs is in experiments/graph_batch_processing_scaling_data.py. For now this is still in the full-redesign branch, soon it will be merged into main.

The live version of dvmdash doesn't have these performance updates yet, a complete redesign is coming soon, including a new UI.

I've had my head down working on this rewrite, and couldn't move on to add new features until this was done. Thank you to the folks who made github issues, I'll be getting to those soon.

DVMDash is open source, please drop by and give us a feature request, bug report, pull request or star. Thanks to OpenSats for funding this work.

Github: https://github.com/dtdannen/dvmdash

Shoutout to nostr:npub12xeqxplp5ut4h92s3vxthrdv30j0czxz9a8tef8cfg2cs59r85gqnzrk5w for helping me think through database design choices.

@ 3b70689a:c1e351eb

来自西班牙的公司 Liberux 最近推出了他们的新手机 Liberux NEXX 众筹计划. 根据目前主页上的介绍, 这款设备将会搭载基于 Debian 13 ARM 构建的 LiberuxOS 操作系统, 并且还提供一个受限的(jailed)的 Android 子系统.

• Liberux (@Liberux@mastodon.social) - Mastodon

Liberux 的 Fediverse 主页

• TX4RLY (@BUF0@mastodon.social) - Mastodon

Liberux 硬件开发工程师 Carlos Rodríguez 的 Fediverse 主页

Carlos Rodríguez 说, 目前网站上的 NEXX 是最初版本, 目前仍然在努力制造第一台原型机, 并且所有的硬件和软件设计都将免费(公开).

WOW, I think our little secret has been revealed, we hope that in a short time you will be able to see the first functional prototypes. We are working very hard on it, by the way, all our designs, both hardware and software, will be free. At the moment the web is a first version, some things will be modified.

—— TX4RLY: "@linmob @awai WOW, I think ou…" - Mastodon

硬件参数

• CPU: 瑞芯微 RK3588s (八核心, 8nm, 2.4Ghz, 2022Q1)

• GPU: ARM Mali-G610 (4 核心, 2021Q2)

• 存储: 32GB LPDDR4x RAM, 256GB eMMC ROM
• 电池: 5300mAh (可拆卸)
• 接口: 3.5mm 耳机 * 1, USB-C 3.1 * 2
• 扩展: microSD 插槽 (2TB Max)
• 屏幕: 6.34 吋, OLED, 2400*1080
• 相机: 后置 32MP, 前置 13MP
• 通讯: 高通骁龙 X62 基带 (2021Q1), 海华 AW-CM256SM 无线网卡 (Wi-Fi 5, 蓝牙 5.0)
• 传感器: 昇佳 STK3311-X 环境光传感器, 美新 MMC3630KJ 三轴磁传感器, 应美盛 ICM-42670-P 加速度计/陀螺仪
• 其他: 内置 DAC 和功放芯片 (瑞昱 ALC5640-VB-CG, 艾为 AW8737SCSR)

其他特点

设备目前公布的外观设计均是渲染效果, 最终交付的设备很可能会与这些渲染图片有很大出入. 但仍然可以通过这些效果图理解 Liberux 的最初意图.

• 摄像头 & 麦克风, 蓝牙 & WLAN, 数据网络功能模块的物理开关(位于顶部).

• 后置指纹解锁, 无摄像模组凸起.

• 左上角挖孔前置摄像头.

• 电源键位于侧边右下角.

其他报道

• Liberux Nexx: New Linux smartphone with 32GB RAM, 2TB storage, 5G and more - NotebookCheck.net News
• Смартфон Liberux Nexx получил ОС Linux и поддержку 2 ТБ памяти - 4PDA (讨论)
• Smartfon z Linuksem? Oto Liberux NEXX. Ekran OLED, 32 GB RAM i system oparty na Debianie. Ciekawy model, choć nie bez wad | PurePC.pl (讨论)
• LINux on MOBile: "The Liberux Nexx (https://libe…" - Fosstodon (Fediverse, 讨论, 工程师回复)

@ e034d654:ca919814

I stumbled into nostr end of March 2023. At that point already fully thrown into the hows, whys and whats of Bitcoin, never really interested in social apps, just recently playing around with Lightning, the only experience of which at the time was Muun (😬) and stacker.news custodial wallet.

Fairly inexperienced with technicals other than rough understandings of concepts. A crappy laptop node with a dangling SSD via USB, constantly having to resync to current blockheights whenever I was ready to make an on chain transaction to cold storage. My great success after over two years of delay, and a couple failed attempts.

Something about the breadth of information for nitty gritty specifics, the clash with all the things that I found interesting about Bitcoin, with others equally as focused, kept me interested in Nostr. Plus the lighthearted shit posting to break up plumbing the depths of knowledge appealed to me.

Cut to now. Through the jurisdictional removals and even deaths of LN wallet projects, using mobile LSPs, finding use cases with the numerous cashu implementations, moderate comfortability with NWC strings of various permissions, budgets for seemingly endless apps of Nostr clients, swapping relays, isolated wallets with Alby go for my wife and cousin (I told them both not to put much on there as I'm sure failure is imminent) Alby Hub and Zeus, now fully backended by my own persistently online lightning node. All of it adding to the fluidity of my movement around the protocol.

Nimble.

Gradual progress. Reading through notes and guides posted on Nostr learning little bits, circling back eventually, if even at a time it wasn't clicking for me. Either way. Glad i've stuck to it even if I still barely know what it is I'm doing.

@ d57360cb:4fe7d935

Time sinks and energy wastage.

The topic I'd like to talk on is being worse at something you do when you think about it doing it. Not even overthinking about it, but just in general thinking about an action. Becoming aware and self-conscious seems to divide you. Almost like splitting your brain and body in two when they should be working as a unit. Why am I worse when I want to do better?

The issue of multitasking

Why does my game at any sport or activity take a fall when I begin to think endlessly about it? We can’t multitask; our brain thrives on focus, pure focus. Laser-like unwavering — that’s when the mind is at its best. The kind of focus you have when you are thoughtless, when there is no self present. When you and the activity are merged as one, you reach a state where there is no longer activity, and there is no longer the human participating in the activity. This has been known to be zen, the Tao, the way, Wu Wei, and the flow state. It seems to me when one thinks about an action and simultaneously performs the action, they are experiencing a split in attention.

Trust your natural creativity

An action done without thought is smooth, unfiltered, and untainted by mental precepts for how it should’ve been carried out. Our bodies are natural and know better than our brains. Even as I write this, my best sentences and writing come from when I’m simply not thinking about them. But why? Simply because you allow the genius of creativity to flow through unobstructed. When you analyze and overthink, you get in your own way; you misdirect your energy, you split your brain and body, and you get them out of alignment.

We are at our best when we do one thing at a time, fully attentive, yet should not be mistaken for thinking about being attentive one must be fully there, where there is no thought. There is no mental chatter or storytelling; all flows like a vicious, violent river. These are inherent gifts, spontaneous like nature. The birds don’t think to fly, the plants don’t think to sprout, yet they create the most jaw-dropping beauty. Why do you think you are above that?

Trust your nature; trust your gift. Allow patience to carry you through.

@ c54f9c60:7c34249a

In October 2018, Arjun Balaji asked the innocuous question, What have you learned from Bitcoin? After trying to answer this question in a short tweet, and failing miserably, I realized that the things I've learned are far too numerous to answer quickly, if at all.

The things I've learned are, obviously, about Bitcoin - or at least related to it. However, while some of the inner workings of Bitcoin are explained, the following lessons are not an explanation of how Bitcoin works or what it is, they might, however, help to explore some of the things Bitcoin touches: philosophical questions, economic realities, and technological innovations.

The 21 lessons are structured in bundles of seven, resulting in three chapters. Each chapter looks at Bitcoin through a different lens, extracting what lessons can be learned by inspecting this strange network from a different angle.

Chapter 1 explores the philosophical teachings of Bitcoin. The interplay of immutability and change, the concept of true scarcity, Bitcoin's immaculate conception, the problem of identity, the contradiction of replication and locality, the power of free speech, and the limits of knowledge.

Chapter 2 explores the economic teachings of Bitcoin. Lessons about financial ignorance, inflation, value, money and the history of money, fractional reserve banking, and how Bitcoin is re-introducing sound money in a sly, roundabout way.

Chapter 3 explores some of the lessons learned by examining the technology of Bitcoin. Why there is strength in numbers, reflections on trust, why telling time takes work, how moving slowly and not breaking things is a feature and not a bug, what Bitcoin's creation can tell us about privacy, why cypherpunks write code (and not laws), and what metaphors might be useful to explore Bitcoin's future.

Each lesson contains several quotes and links throughout the text. If I have explored an idea in more detail, you can find links to my related works in the "Through the Looking-Glass" section. If you like to go deeper, links to the most relevant material are listed in the "Down the Rabbit Hole" section. Both can be found at the end of each lesson.

Even though some prior knowledge about Bitcoin is beneficial, I hope that these lessons can be digested by any curious reader. While some relate to each other, each lesson should be able to stand on its own and can be read independently. I did my best to shy away from technical jargon, even though some domain-specific vocabulary is unavoidable.

I hope that my writing serves as inspiration for others to dig beneath the surface and examine some of the deeper questions Bitcoin raises. My own inspiration came from a multitude of authors and content creators to all of whom I am eternally grateful.

Last but not least: my goal in writing this is not to convince you of anything. My goal is to make you think, and show you that there is way more to Bitcoin than meets the eye. I can’t even tell you what Bitcoin is or what Bitcoin will teach you. You will have to find that out for yourself.

"After this, there is no turning back. You take the blue pill —the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill— you stay in Wonderland, and I show you how deep the rabbit hole goes."

—Morpheus

@ ae6ce958:d0f02c7d

In a world increasingly reliant on software, ensuring its reliability, fairness, and ethical operation has never been more critical. Enter DamageBDD, a visionary platform combining Behavior-Driven Development (BDD) principles with the Bitcoin Lightning Network to create an inclusive, sustainable ecosystem that rewards contributors for enhancing global software quality. DamageBDD offers a groundbreaking solution: a decentralized, incentivized network where contributors can earn continuous rewards for their efforts, fostering collaboration, innovation, and resilience on a planetary scale.

---

A Global Network of Inclusion

One of DamageBDD's core strengths lies in its accessibility. The platform lowers barriers to participation, enabling individuals from all walks of life to contribute to software quality assurance. Whether you're a seasoned developer, a student exploring programming, or an enthusiast with logical reasoning skills, DamageBDD offers a place for you to thrive.

• Inclusivity Across Borders: No matter where contributors are located, they can participate, write tests, and verify implementations, earning Bitcoin payouts directly via the Lightning Network. This opens doors for individuals in underserved regions, empowering them to earn a sustainable income by contributing to a global digital infrastructure.
• Democratizing Software Development: By simplifying the process of writing and validating BDD test cases, DamageBDD ensures that anyone, regardless of technical background, can play a vital role in the ecosystem.

---

Sustainability Through Continuous Rewards

DamageBDD introduces a revolutionary incentive model where contributors earn not just for initial efforts but for the enduring utility of their work. Once a contributor writes and validates a test case or implements a feature, they can continue to earn payouts every time that test is executed successfully in the future. This model creates a self-sustaining loop of collaboration, innovation, and maintenance:

• Long-Term Incentives: Contributors remain financially motivated to keep their tests updated and ensure the associated feature works as expected. This continuous engagement ensures the software remains resilient, evolving to meet changing requirements.
• Encouraging Best Practices: By linking payouts to ongoing test executions, DamageBDD promotes robust test writing and feature development, reducing technical debt and encouraging sustainable software practices.

This approach not only aligns incentives with quality but also creates a virtuous cycle where contributors benefit from the long-term success of their work, ensuring a healthier, more collaborative software ecosystem.

---

Empowering Contributors for a Sustainable Future

Participating in the DamageBDD network provides contributors with opportunities that extend beyond monetary rewards. It empowers individuals and communities by fostering education, skill development, and global collaboration.

• Economic Empowerment: By earning Bitcoin payouts for their contributions, participants gain access to a global, borderless financial system. This is particularly impactful for those in regions with limited economic opportunities or unstable fiat currencies.
• Skill Development: Contributors learn and refine valuable skills, from writing precise BDD test cases to collaborating on complex software projects. These skills are transferable, increasing contributors' employability and confidence.
• Community Collaboration: The DamageBDD network brings together a diverse group of individuals and teams, creating a vibrant global community focused on innovation and quality.

---

A Self-Sustaining Software Ecosystem

At the heart of DamageBDD is a vision of a self-sustaining software ecosystem, where contributors, users, and developers are interconnected through mutual benefits:

• Decentralized Verification: Billions of test cases are verified daily on a distributed infrastructure, ensuring scalability and resilience.
• Dynamic Liquidity: The Bitcoin Lightning Network provides seamless micropayments, ensuring that contributors are rewarded in real time without delays or intermediaries.
• Adaptive Testing: DamageBDD's network detects gaps in coverage and autonomously generates new tests, keeping the ecosystem robust and up-to-date.
• Environmental Sustainability: By leveraging existing decentralized infrastructure and incentivizing efficient software development practices, DamageBDD minimizes waste and maximizes resource utilization.

---

The Ripple Effect: Continuous Benefits for All

As the DamageBDD ecosystem grows, its benefits extend far beyond individual contributors. Organizations, communities, and even nations stand to gain:

• For Organizations: High-quality software reduces downtime, builds user trust, and accelerates innovation. Companies that integrate with DamageBDD can leverage its robust test coverage to deliver better products faster.
• For Communities: DamageBDD creates local economic opportunities by enabling individuals to participate in the global digital economy. Communities can build localized solutions while tapping into a global network of expertise.
• For the Planet: A robust, well-tested software ecosystem reduces inefficiencies and ensures that digital infrastructure remains resilient in the face of global challenges.

---

A Vision for the Future

Imagine a world where billions of users collaborate daily to ensure the quality of the software we all rely on. In this vision, DamageBDD is the backbone of a planetary-scale ecosystem, verifying billions of tests and creating an ever-evolving foundation for innovation. Every test case is a building block, every contributor is a stakeholder, and every payout is a step toward a more equitable, sustainable, and inclusive digital future.

By aligning incentives with quality and participation, DamageBDD transforms software development into a collective endeavor that benefits everyone. It is more than a platform; it is a movement—one that empowers individuals, fosters collaboration, and builds a sustainable digital world for generations to come.

@ c54f9c60:7c34249a

Falling down the Bitcoin rabbit hole is a strange experience. Like many others, I feel like I have learned more in the last couple of years studying Bitcoin than I have during two decades of formal education.

The following lessons are a distillation of what I’ve learned. First published as an article series titled “What I’ve Learned From Bitcoin,” what follows can be seen as a second edition of the original series.

Like Bitcoin, these lessons aren't a static thing. I plan to work on them periodically, releasing updated versions and additional material in the future.

Unlike Bitcoin, future versions of this project do not have to be backward compatible. Some lessons might be extended, others might be reworked or replaced. I hope that a future version will be something you can hold in your hands, but I don’t want to promise anything just yet.

Bitcoin is an inexhaustible teacher, which is why I do not claim that these lessons are all-encompassing or complete. They are a reflection of my personal journey down the rabbit hole. There are many more lessons to be learned, and every person will learn something different from entering the world of Bitcoin.

I hope that you will find these lessons useful and that the process of learning them by reading won’t be as arduous and painful as learning them firsthand.

nostr:npub1dergggklka99wwrs92yz8wdjs952h2ux2ha2ed598ngwu9w7a6fsh9xzpc

@ a311301f:4663f8f2

```perl

!/usr/bin/perl

use strict; use warnings; use Term::ReadKey;

STDOUT->autoflush(1);

this version run on Windows and use a pwd.txt file created by

the perl program ; otherwise encoding issue may follow

following sub needs to be used first by uncommenting the main call

sub write_password { print ("Enter Password: ") ; my $password = ; my $file_path = 'pwd.txt'; open(my $fh, '>', $file_path) or die "Cannot open file '$file_path' for writing: $!"; print $fh $password; close($fh); print ("\n"); print "Password written to '$file_path'\n"; }

sub printhex { my $str = shift ; foreach my $char (split //, $str) { printf "%02x ", ord($char); } print "\n"; }

Function to read password from file

sub read_password_from_file { #unecessary #binmode(STDIN, ':crlf'); my $file_path = shift; #unecessary #local $/ = "\r\n" ; # CR, use "\r\n" for CRLF or "\n" for LF open(my $fh, '<', $file_path) or die "Cannot open file '$file_path' for reading: $!"; my $password = <$fh>; close($fh); #printhex ($password) ;
chomp($password); print "'$password'\n" ; #$password =~ s/\r?\n$//; # Remove newline character #$password = substr($password, 2) ; # BOM File starts with FF FE printhex($password ) ; # "\'$password\'\n" ; #$password = "abcde" ;
return $password; }

Main program

sub main { #write_password(); # to uncomment for first use my $correct_password = read_password_from_file("pwd.txt") ; print "Enter password: "; ReadMode('noecho'); # Turn off echo my $entered_password = ReadLine(0); ReadMode('restore'); # Restore echo chomp($entered_password); print "\n";

# Compare entered password with the correct password
if ($entered_password eq $correct_password) {
    print "Access granted!\n";
} else {
    print "Access denied!\n";
    print "'$entered_password' not eq '$correct_password' \n"; 
    printhex ($entered_password); 
    printhex ($correct_password) ; 
    print "The end! \n" ; 
}

}

Call main function

main();

```

@ 35f3a26c:92ddf231

Background

Most people non familiar with Bitcoin thinks that there its has not smart contracts capabilities, and that is incorrect, there are smart contract capabilities, and despite limited in comparison with other blockchain networks, those capabilities are evolving slowly but surely.

The support for smart contracts is done through its scripting language, Script, which allows developers to create complex conditions for transactions.

What can you do with Script? 1. time locks 2. multi-signature requirements 3. other custom logic

opcodes like OP_CHECKLOCKTIMEVERIFY (CLTV) and OP_CHECKSEQUENCEVERIFY (CSV) are used to build more sophisticated smart contracts, these opcodes enable features such as the Lightning Network, a key scaling solution for Bitcoin

back in 2021, the Taproot upgrade introduced Pay-to-Taproot (P2TR), in summary allows for more private and efficient smart contracts, in that soft fork more was added, in addition to Taproot, we got as well Schnorr signatures, which enables multiple signatures to be aggregated into a single signature, improving scalability and privacy and MAST (Merklized Abstract Syntax Trees) which reduces the size of complex smart contracts, making them more efficient, as an added value, this efficiency reduces the cost of transactions.

The Taproot upgrade has laid the foundation for the development of more sophisticated smart contracts on the Bitcoin network, and the use of covenants is an important part of this development.

What is Bitcoin Covenants?

It is a BIP (Bitcoin Improvement Proposal), BIP-347, assigned on April 24, 2024, which marks the first step towards reintroducing functionality removed from Bitcoin by its creator Satoshi Nakamoto in 2010. This proposal aims to bring smart contract functionality to Bitcoin as we see in other EVM networks.

The proposal’s developers authors names are Ethan Heilman and Armin Sabouri, now the community will debate its merits.

Here the link, in case you are curious:

https://github.com/bitcoin/bips/blob/master/bip-0347.mediawiki

It is worth to read the motivation section of the BIP, which reads:

“Bitcoin Tapscript lacks a general purpose way of combining objects on the stack, restricting the expressiveness and power of Tapscript. This prevents, among many other things, the ability to construct and evaluate merkle trees and other hashed data structures in Tapscript. OP_CAT, by adding a general purpose way to concatenate stack values, would overcome this limitation and greatly increase the functionality of Tapscript.

OP_CAT aims to expand the toolbox of the tapscript developer with a simple, modular, and useful opcode in the spirit of Unix. To demonstrate the usefulness of OP_CAT below we provide a non-exhaustive list of some use cases that OP_CAT would enable:

Bitstream, a protocol for the atomic swap (fair exchange) of bitcoins for decryption keys, that enables decentralized file hosting systems paid in Bitcoin. While such swaps are currently possible on Bitcoin without OP_CAT, they require the use of complex and computationally expensive Verifiable Computation cryptographic techniques. OP_CAT would remove this requirement on Verifiable Computation, making such protocols far more practical to build in Bitcoin.

Tree signatures provide a multisignature script whose size can be logarithmic in the number of public keys and can encode spend conditions beyond n-of-m. For instance a transaction less than 1KB in size could support tree signatures with up to 4,294,967,296 public keys. This also enables generalized logical spend conditions.

Post-Quantum Lamport signatures in Bitcoin transactions. Lamport signatures merely require the ability to hash and concatenate values on the stack. [4] It has been proposed that if ECDSA is broken or a powerful computer was on the horizon, there might be an effort to protect ownership of bitcoins by allowing people to mark their taproot outputs as "script-path only" and then move their coins into such outputs with a leaf in the script tree requiring a Lamport signature. It is an open question if a tapscript commitment would preserve the quantum resistance of Lamport signatures. Beyond this question, the use of Lamport Signatures in taproot outputs is unlikely to be quantum resistant even if the script spend-path is made quantum resistant. This is because taproot outputs can also be spent with a key. An attacker with a sufficiently powerful quantum computer could bypass the taproot script spend-path by finding the discrete log of the taproot output and thus spending the output using the key spend-path. The use of "Nothing Up My Sleeve" (NUMS) points as described in BIP-341 to disable the key spend-path does not disable the key spend-path against a quantum attacker as NUMS relies on the hardness of finding discrete logs. We are not aware of any mechanism which could disable the key spend-path in a taproot output without a soft-fork change to taproot.

Non-equivocation contracts in tapscript provide a mechanism to punish equivocation/double spending in Bitcoin payment channels. OP_CAT enables this by enforcing rules on the spending transaction's nonce. The capability is a useful building block for payment channels and other Bitcoin protocols.

Vaults [6] which are a specialized covenant that allows a user to block a malicious party who has compromised the user's secret key from stealing the funds in that output. As shown in OP_CAT is sufficient to build vaults in Bitcoin.

Replicating CheckSigFromStack which would allow the creation of simple covenants and other advanced contracts without having to pre-sign spending transactions, possibly reducing complexity and the amount of data that needs to be stored. Originally shown to work with Schnorr signatures, this result has been extended to ECDSA signatures.

OP_CAT was available in early versions of Bitcoin. In 2010, a single commit disabled OP_CAT, along with another 15 opcodes. Folklore states that OP_CAT was removed in this commit because it enabled the construction of a script whose evaluation could have memory usage exponential in the size of the script. For example, a script that pushed a 1-byte value on the stack and then repeated the opcodes OP_DUP, OP_CAT 40 times would result in a stack element whose size was greater than 1 terabyte assuming no maximum stack element size. As Bitcoin at that time had a maximum stack element size of 5000 bytes, the effect of this expansion was limited to 5000 bytes. This is no longer an issue because tapscript enforces a maximum stack element size of 520 bytes.”

The last update of the BIP was done on Sep. 8 2024 by Ethan Heilman

Controversy

The controversy revolves around two main camps:

1. Those who want to preserve Bitcoin’s network for monetary transactions only, arguing that adding smart contract capabilities could introduce risks and complexity.
2. Others who advocate for expanding Bitcoin’s capabilities to support a wider range of applications, seeing OP_CAT as a step towards enhancing the network’s utility.

Final Thoughts

Bitcoin have done what no other asset have done in history, neither gold, its success is clear, and now, that BlackRock is involved, “miraculously”, corporations and governments are getting on board and Bitcoin is not anymore only for criminals or “rat poison” or “is going to zero”.

But as all tech, improvements are important, if those improvements are done to secure more the network and to make it more robust, there will be little to none controversy, however, when those changes are aiming at adding new shinning features that would change Bitcoin into a network with similar features as Ethereum in terms of contracts that requires attention and debate, few questions come to mind:

1. How will that change affect the security of the network?
2. How that change will affect the blockchain usage?
3. What is the projected impact over the fees per transaction if this change is approved?
4. Will the impact create pressure for the block size increase discussion to come back to the table and with it a second war?

Looking into Ethan Heilman work and contribution to the Bitcoin ecosystem, I am inclined to believe that he has considered most of those questions.

Looking forward to observe the evolution of this proposal.

You liked the article? Make my day brighter!

Like and share!

Last but not least, the following link is an unstoppable domain, it will open a page in which you can perform an anonymous contribution to support my work:

https://rodswallet.unstoppable/

The link didn’t open?

To open the link you need to use a best in class browser that supports web3, two are recommended: Brave Browser and Opera Browser

@ f33c8a96:5ec6f741

@ 2b24a1fa:17750f64

Ein Gedicht unserer Zeit von Lionne Douce.

Sprecherin: Sabrina Khalil

https://soundcloud.com/radiomuenchen/der-gutmenschzug-ist-da-von?