stringintech retweeted
> Bitcoin Core has spent more than a century of CPU time fuzzing individual functions and critical components (though oss-fuzz, Fuzzor, bitcoinfuzz and individual contributors), and decades of CPU time simulating small networks of full nodes under test (Antithesis, Fuzzamoto). I can’t establish causality from this alone, but my strong suspicion is that the sustained testing effort is an important reason these projects have become so robust.
I wrote a blog post on the recent exploits in the Bitcoin ecosystem, how Bitcoin Core is holding up, and how I think the community can get ahead of the models:
dergoegge.de/blog/somethings…
stringintech retweeted
One man's journey to Bitcoin Core development
Stephan (@stickies_v) on getting in to open source Bitcoin:
Earlier this year we published a special interview with Bitcoin Core developer @stickies_v describing his journey into bitcoin open-source.
Previously this had only been available to participants of the @ChaincodeLabs BOSS Challenge. We are pleased to share it is now publicly available both on our website as well as here.
Happy reading!
stringintech retweeted
Reproducible builds give you a source code -> binary mapping. Without this, any open source project needs to pick a single “trusted” person to produce binaries; where no one else can even double check that person compiled the source code they claimed to have compiled (given no reproducibility). So even if you don’t trust the contents of a binary, reproducible builds still solve the problem of a project deciding which binary to make available to end users, given its source code.
Given the cost and difficulty, I’m not sure this is the way forward, especially with AI.
If you really think about it, all reproducible builds did was move the locus of trust (for most people, except those that verified themselves, which are few and far between).
Developer writes code and makes it reproducible. Another guy creates the reproducible builds and posts that they reproduced it. User trusts the other guy blindly.
What would actually be far better is you point your agent to a codebase and say “scan for vulns and build it for me.” That would be far more practical for everyone.
stringintech retweeted
This should be the absolute default for bitcoin-sensitive deliveries.
Replying to @Trezor
We are currently working on an Anonymous Delivery option, which we aim to have ready by September for the EU and by the end of the year for the US.
This gives you a safer way to order hardware wallets without linking the purchase to your home address or real-world identity.
- Dedicated checkout
- Use a nickname or label ID
- Select an automated parcel locker for pickup
- Unbranded packaging with a generic sender label, while the carrier only uses email or SMS to send a pickup PIN
This project is a top priority at the moment.
stringintech retweeted
Reposting the bitcoin kernel library tracking issue: github.com/bitcoin/bitcoin/i…
There are a bunch of things in flight at the moment and this provides a broad overview of things, a list of available language bindings to the library, and aspirational goals.
stringintech retweeted
I spoke with @brian_trollz about bitcoinkernel progress and other work being done to keep Core in good shape in years to come.
Replying to @BitcoinMagazine
Inside the "Kernel Project" & the Bitcoin Core Development Process w/ Core Dev Stéphan
Core developer Stéphan sits down with Bitcoin Magazine's @brian_trollz to explain how the Kernal and multiprocess projects are reshaping Bitcoin Core for long-term reliability.
stringintech retweeted
Bitcoin Core now has an interface for its consensus code - it only took a decade.
github.com/bitcoin/bitcoin/p…
stringintech retweeted
The Bitcoin Core development process and distribution model actually makes it somewhat harder to fix security issues, compared to other serious software distributors.
Take Google Chrome as an example. The CVE fixing happy path is to develop and review a fix in private, push that fix to a private repository, and then push auto-updates to any affected users (running any currently supported release). At some point in the future, you can disclose the bug, once your (built in, on by default) telemetry tells you a significant portion, if not all, of your users have upgraded.
Bitcoin Core development happens in public. While a small(er) group of developers can receive a report of a security issue, and create a patch in private; at some point, long before any end user could be running a fixed binary, this patch must become public, as part of a Pull Request, opened on github.com/bitcoin/bitcoin/.
At that point, it can be seen and reviewed by any person (attacker, regular contributor, or otherwise). This means CVEs must be fixed carefully, you can't open a Pull Request titled "p2p: fix message parsing bug that causes node to crash" with a patch and functional test attached, demonstrating how to exploit the issue; otherwise someone might decide to take down the network that afternoon, for fun.
Instead, CVE fixes are generally hidden as parts of other fixes, or refactors, however that is also non-trivial to do. While a small group of developers might be aware of the (hidden) fix, it's possible for any other contributor, or random internet person looking at GitHub, to do code review, and point out when a patch might not only be doing what it claims to be doing; undermining your ability to fix covertly. It's obviously possible to tell more (regular) contributors about a fix; depending on the severity, that comes with more tradeoffs.
The fact that CVE fixes may be hidden in refactors, or other innocuous looking changes, is also why it can be harder to backport (i.e take a fix applied to master, and apply it to the 30.x branch) these fixes to already released versions of Core. Release branches only get bug-fixes; someone will ask questions if you open a Pull Request to backport a 15 commit refactor (no-op), to an old stable branch.
The difficulty to backport is exacerbated by the fact that backports are already an obvious place for an attacker to look for covert, or exploitable bug fixes. Depending on the severity, it's quite possible that a (very) bad bug, might get fixed in master, released as part of a new major version (i.e v30.0), but not backported to other stable branches, if it's deemed too risky to try and publicly apply those changes to release branches, without making it obvious that a CVE is being patched, and risking it's exploitation, while a significant portion of the network is still vulnerable.
Note that at any point, between when the patch is merged to master, and the next major release happens (1.5-5 months), any person may publicly point out that your patch was actually doing multiple things, and undermine your covert fix. They may also reverse engineer the patch, to the point where they can exploit the issue, and do so.
All of this work must happen in public, because Bitcoin Cores distribution process, uses reproducible builds. This makes it impossible to ship private code changes in binaries (i.e uploading binaries that contain code that hasn't been made public), because any person can take the publicly available source code, and transform it into the same binaries that are available to download from bitcoincore.org. If at any point, the public source code does not match what is being distributed, alarm bells will ring. The are multiple (non-contributors) that are consistently performing the steps to check that the release source code, exactly matches the release binaries.
Bitcoin Core does not ship software with auto-update functionality, and it never will. This means we cannot "push" updates to anybody. Any user of the software, opts-in to updates, at whenever they consider it convenient. Bitcoin Core does not have any form of telemetry, and it never will. Our usage insights come from the public bitcoin network (i.e the user-agent strings of nodes), and are a rough gauge of which versions of the software are most used.
There are many trade-offs involved here, fixing security vulnerabilities in Bitcoin Core, is non-trivial, and unlike the happy-path of most other software distrobutors. However it's important that we continue to distribute software in this way.
Replying to @adam3us
They can always push security fixes in v29 like any serious software distributor does, not forcing anyone to upgrade to unwanted/unprepared for functional changes… and I should know I work for a software editor for 15+ years
stringintech retweeted
The @obscuravpn signup flow, is how paying on the internet should work (by default):
Identifier -> Options -> Lightning Invoice -> Product
stringintech retweeted
stringintech's first merged PR: github.com/bitcoin/bitcoin/p…
Congratulations! 🎉🍾🎆
Lately been working on a Go wrapper for the libbitcoinkernel C API. Turns out the kernel API is a really good entry point for understanding Bitcoin Core's validation logic.
github.com/stringintech/go-b…
stringintech retweeted
Have you, too, had enough of Core devs abusing their power to release highly reviewed software with sane defaults?
Come to my bitcoinkernel workshop at @BTCPrague's dev/hack/day and take the first step towards becoming your own tyrannical full node dev.
stringintech retweeted
Replying to @sedited_
@the_charlatan_ (+village of people) have been meticulously working on the kernel project for years, with the goal of making it possible to build alternative clients that share Bitcoin Core's consensus engine. @Stphnvlstk is hosting a PR review club this week on PR #32317, "Separate UTXO set access from validation functions", in the public libera IRC channel #bitcoin-core-pr-reviews.
bitcoincore.reviews/32317
I wouldn’t be able to focus; feels like being overwhelmed by all that you don’t know and wouldn’t have the chance to know in your lifetime.
stringintech retweeted
Replying to @davefarley77
Many problems can seem hard due to your lack of knowledge over their intrinsic difficulty. Study can fix lack of knowledge. Often you can study just in time. Don't be intimidated by what you don't know.
احتمال اینکه شما واقعا جای اشتباهی باشید و اگه تلاشهاتون رو به یه سمت دیگه ببرید تغییرات شگرفی رخ بده واقعا وجود داره!
۲
عالی؛
دوست دارم یه موردی که توی رشتو هم بهش اشاره شده بود رو تاکید کنم روش (بیشتر به عنوان تلنگر و یادآوری برای خودم 🙂)؛
اونم اینکه خیلی مهمه حوزهای که واردش میشید «برای شما» باشه.
۱
Replying to @saeed_fard
جواب کوتاه: بله، میشه.
جواب خیلی بلند: من منشنتون و دغدغههاتون رو خوندم. و میفهمم. پس بذارین دونهدونه در ۴ بُعد بریم تو.
۱. کند شدن ذهن
من فکر نمیکنم ذهن کند میشه الزاماً. بلکه حتی قدرت ادراک، جامعبینی، و پذیرش منطقی میتونه بالا هم بره. ما توی کدلیتا (@theCodelita) کاربر بین ۵۰ تا ۷۰ ساله هم داریم که حتی سرتیفیکت درس اول برنامهنویسی رو گرفتهن و بازنشسته هم هستن. از معلم بازنشسته زبان در اصفهان گرفته، تا نوازنده موسیقی جاز در فلوریدا. و خداوکیلی خیلیهاشون رو وقتی من میبینم، خودم اول کف و بعد حال میکنم که عه، جدی جدی تونستن!
رو این حساب، حدس من اینه که مغز مشکلی نداره. بلکه اغلب فشار استرس زندگی باعث میشه که مغز/روان، کارتِ فراموشی رو به عنوان یه مکانیزم دفاعی هی بازی کنه. و تسلیم شدن، و بهنوعی وا دادن، هم بیشتر به این فراموشی و کند شدن شاید دامن میزنه. (پشتوانه علمی اصلاً ندارم، تئوری و نظر تجربی هست. و فکر میکنم یه درصدی از آلزایمر/دیمنشیا هایی که رخ میده، سایکوسوماتیک هست برای مقابله با افسردگی/اضطراب خیلی عمیق.)
خلاصه، بهنظرم این کند شدن شاید بیشتر حاصل شخصیت و محیط و تسلیم شدن باشه تا الزاماً سنی. یقیناً با گذشت سن، حجم خاطرات تلخ، یادآوری ناکامیها، فشار مالی، و ... بالا میره. اما اگه بشه اینا موریانهی مغز نشن، و مدیریت بشن در جعبهی خودشون (compartmentalization)، اونوقت میشه که بخشهای یادگیری مغز سالم بمونن و حمایت کنن.
.
۲. حرفهای
اگه منظور از حرفهای کسب درآمد هست، میشه. مخصوصاً اگه مستقل/indie یا فریلنسر بخواین بشین. چون ملت با محصول شما سر و کار دارن و همین الآنم عمراً نمیدونن سازندهی فلان ویدیو گیم یا اپ چند سالشه.
اما اگه بخواین کارمندی برین، ممکنه مدیر میانی که جوان هست، راحت نباشه زیردستش یه آدم ۵۰ ساله از یکی دو نسل قبل باشه. و مضافاً ممکنه بغلدستی شما دستش گرمتر باشه و کار ۸ ساعت شما رو توی ۶ ساعت بکنه. که خب خوبه جفتتون با این اختلاف راحت باشین.
نتیجه اینکه خوبه تصویر واقعیِ هدف (بعد ۲ سال) چیده بشه و کمی بررسی بشه و اگه یه تصویر توش موانع فرهنگی داره، از اول تصویر جایگزین بهتری چیده بشه که تهش تو ذوق نخوره.
.
۳. قورباغهی انتظار و حسرت درون
یه قورباغه بزرگی این وسط هست که شبیه یه صدای توی سر، هر روز میخواد ور ور بگه «آی، دیدی دیر کردی! آی، خاک تو سرت، عمرتو به گا دادی، دیدی عقبی! وای، الآن باید تاااازه عین بچهها و مث ۳۰ سال پیشت بهزور مشق بنویسی، و تو عمراً نمیرسی!»
این قورباغه، که تلفیقی از ایگو، انتظارات غیرواقعبینانه، و حس عقب افتادن و حسرت هست رو یا میتونی قورتش بدی، یا نه. اگه بدی، که بعدش هر تلاشت یه تشویق داره پشتش (حداقل از سمت خودت) و یه دمت گرم. و یه مسیری میشه که سخت هست، پیچ و خم هم داره، ولی خوش میگذره و حال میده!
منتهی اگه نتونی این قورباغه رو قورت بدی، باید هرررر روز بهش گوش کنی و مغزت رو تیلیت کنه و در درونت بجنگی هی باهاش. و هر تلاشت یه لقمه غذا واسه این باشه که کمی خفه شه تا فردا. همچین سیستمی خلاصه سخته باش ادامه دادن، و واقعاً ممکنه ده برابر خستهترت بکنه تا وا بدی. مضافاً ممکنه این قورباغه نه تنها فقط خودت و ایگوت، بلکه بهصورت عینی یکی از عزیزان نزدیک و حتی پارتنر یا والدین یا فرزندان باشه.
پ.ن. برای خفه کردن اون قورباغه، اگه یهنفره موفق نشدین، خوبه از یه متخصص مثل یه تراپیست یا مشاور مجرب کمک بگیرین.
.
۴. ذهنیت یادگیری
یادگیری جذابه. مخصوصاً اگه نمره (انتظار، ترس شکست روزمره) پشتش نباشه. و چند تا پیشنیاز داره:
الف) مدل یادگیری شخصی پیدا بشه (صوتی، تصویری، مطالعه، عملی، تلفیقی، کاربردی، داستانی، و ...)
ب) بدون وام گنده گرفتن بشه وقت گذاشت. ینی کسی (مث پارتنر) نیاد هی نق بزنه به جونتون که چرا هر شب بعد شام ۲ ساعت تو لپتاپ هستین. و بهجاش درک و حمایت کنه.
ج) علاقه باشه. خود فیلد و منبعی که ازش یاد میگیرین، حس ورود به یک دنیای شگفتانگیز و یه شهربازی مهیج رو به کودک درونتون بده.
د) استمرار باشه. ینی از نظر شخصیتی به این باور رسیده باشین که برای خوب شدن تو هر چیزی ۱۰۰۰ ساعت و برای فوقالعاده شدن، ۱۰هزار ساعت وقت لازمه. و دنبال زود رسیدن و یهشبه و وای دیر شد و امروز حال ندارم و این چیزا نباشین.
اگه این موارد رعایت شه، یقیناً با کفش خوب، و پلههای متناسب، در مسیر جذاب، میشه هزار تا پله رو بالا رفت و لذت برد. و اتفاقاً با همین ذهنیت/مایندست هست که یهو بهخودت میای میبینی «عه، رسیدم که!» و اونقدر عاشق مسیر میشی که حتی بعد از رسیدن هم دست از یادگیری برنمیداری.
فیلدهای بسیار پویا ای مثل برنامهنویسی یا هر فیلدی که هر یه قدم که برمیداری، تهش سه قدم مسیر درازتر میشه، دقیقاً همچین ذهنیتی رو میطلبن! که یه «سیستم یادگیری» (شبیه یه اتومبیل شخصی یا اسلحه شخصی) داشته باشی که بشینی پشتش و باش با کمترین دغدغه، توی زون ذهنی خودت، بری جلو و حسابی بترکونی!
مطمئنم اگه این چیدمانها برقرار بشه، یقیناً میشه حتی تو ۵۰ یا ۶۰ سالگی هم به خیلییییی جاها رسید. و مثل دلبر که میگه «ببین زندگی هنوز خوشگلیاشو داره»، من معتقدم «زندگی هنوز کلی چیزای باحال و زیبا و شگفتانگیز پشت پیچ بعدی جادهت برات داره، و منتظرته که تلاشتو بکنی و بیای و ببینی و حالشو ببری!»
ممنون.



























