Bitcoin Core ფუნქციონირებს, როგორც ფულადი ქსელის ხერხემალი, რომელიც უზრუნველყოფს ორ ტრილიონ დოლარზე მეტი ღირებულების უსაფრთხოებას. ფსონები უზარმაზარია და კოდის ბაზის დიდ ნაწილებს შეუძლიათ მაღალი ზემოქმედების შეცდომების შემცველობა. კონსენსუსის ძრავა, peer-to-peer (p2p) შეტყობინებების დამუშავების კოდი და კრიპტოგრაფიული ბიბლიოთეკები არის ის სფეროები, სადაც მოწყვლადობამ შეიძლება გამოიწვიოს ქურდობა, ქსელის გაჩერება ან ფუნდამენტურად შეარყიოს სისტემისადმი ნდობა. ტრადიციული ფინანსური პროგრამული უზრუნველყოფისგან განსხვავებით, რომელიც დაზღვევითა და სამართლებრივი საშუალებებით არის გამყარებული, Bitcoin-ის უსაფრთხოება მთლიანად დამოკიდებულია მისი კოდის ხარისხზე და იმ პროცესებზე, რომლებიც ამ ხარისხს ინარჩუნებენ. Bitcoin Core-ში უსაფრთხოების მიდგომა ფორმალურად არ არის განსაზღვრული, არამედ წარმოადგენს პრაქტიკის განვითარებად ერთობლიობას, რომელიც დროთა განმავლობაში გაუმჯობესდა. განხილვის პროცესები უფრო საფუძვლიანი გახდა, ტესტირების ინფრასტრუქტურა მნიშვნელოვნად გაფართოვდა და პროექტი მთლიანობაში უფრო კონსერვატიული და გააზრებული გახდა პროგრამული უზრუნველყოფის ცვლილებებთან დაკავშირებით. ეს ნელი ტემპი თავისთავად უსაფრთხოების ზომაა, რაც ამცირებს ახალი შეცდომების შემოტანის რისკს ნაჩქარევი მოდიფიკაციების გზით. ეს ნაწარმოები იკვლევს რამდენიმე ძირითად ასპექტს, თუ როგორ უდგება Bitcoin Core უსაფრთხოებას: ეს პრაქტიკები ერთად მუშაობს, თუმცა არა როგორც ერთიანი დიდი სტრატეგია, არამედ როგორც თავდაცვის დამატებითი ფენები, რომლებიც განვითარდა პროექტის მომწიფებასთან ერთად. Bitcoin Core, როგორც პროგრამული პროექტი, არ უზრუნველყოფს ავტომატური განახლების ფუნქციონალობას მის მიერ გამოშვებული პროგრამული უზრუნველყოფისთვის, როგორც დამცავი ზომა მისი მომხმარებლებისთვის მისი დეველოპერებისგან, და ყველა გამოშვებული ბინარული ფაილი შეიძლება შემოწმდეს, რომ შეესაბამებოდეს გამოქვეყნებულ საწყის კოდს რეპროდუცირებადი აწყობის გზით. კვანძის ოპერატორები პასუხისმგებელნი არიან გადაწყვიტონ, პროგრამული უზრუნველყოფის რომელი ვერსია გაუშვან და როდის განაახლონ. უსაფრთხოების მოწყვლადობის კონტექსტში, ეს სერიოზულ დილემას წარმოადგენს. გამოსწორებები უნდა იყოს ღია წყარო განხილვის პროცესისთვის, სანამ გამოშვება მოხდება, თუმცა სრული გამჟღავნება უნდა გადაიდოს, რათა მომხმარებლებს მიეცეთ განახლებისთვის გონივრული დრო, იმის გათვალისწინებით, რომ მოწყვლადობის დეტალების გამოქვეყნების შემდეგ, თავდამსხმელებს შეუძლიათ მისი ექსპლუატაცია. ისტორიულად, პროექტის მიერ უსაფრთხოების კრიტიკული მოწყვლადობების საჯარო გამჟღავნება, მიუხედავად იმისა, გარედან იყო მოხსენებული თუ კონტრიბუტორების მიერ აღმოჩენილი, არაადეკვატური იყო. ამან გამოიწვია სიტუაცია, როდესაც ბევრი მომხმარებელი Bitcoin Core-ს აღიქვამდა, როგორც არასდროს მქონე შეცდომებს, რაც საშიში და არაზუსტი აღქმაა. დაახლოებით წელიწადნახევრის წინ, ამ საკითხებით მოტივირებულმა, პროექტმა გადახედა და ფორმალურად განსაზღვრა უსაფრთხოების საკითხების დამუშავება ყოვლისმომცველ გამჟღავნების პოლიტიკად და საკონსულტაციო პროცესად. მიზნები იყო მეტი გამჭვირვალობის უზრუნველყოფა, უსაფრთხოების მკვლევრებისთვის მკაფიო მოლოდინების დადგენა (მათთვის სტიმულის მიცემა მოწყვლადობების პოვნისა და პასუხისმგებლობით გამჟღავნებისთვის), მოძველებული ვერსიების გაშვების რისკების უკეთესი კომუნიკაცია და უსაფრთხოების შეცდომების ხელმისაწვდომობა კონტრიბუტორების ფართო ჯგუფისთვის გამჟღავნების შემდეგ, რათა დაეხმაროს მათ სწავლაში და მომავლის პრევენციაში. როდესაც მოწყვლადობა ეცნობება პროექტს, ის ჯერ მოწმდება და ფასდება Bitcoin Core-ის „უსაფრთხოების გუნდის“ მიერ, რომელიც არის მცირე ჯგუფი გრძელვადიანი კონტრიბუტორების, რომლებსაც აქვთ უსაფრთხოების შეცდომების პოვნის ან გამოსწორების გამოცდილება. პროექტი მოწყვლადობებს ყოფს ოთხ სიმძიმის დონედ: კრიტიკული (ქსელის მთლიანობის საფრთხეები, როგორიცაა მონეტის ქურდობა ან ინფლაცია), მაღალი (მნიშვნელოვანი ზემოქმედება, დისტანციურად ექსპლუატირებადი), საშუალო (შესრულების დეგრადაცია ან შეზღუდული ფარგლები) და დაბალი (მცირე ზემოქმედებით ექსპლუატაციის სირთულე). თუ სერიოზულად დადასტურდა, გამოსწორება შემუშავდება და საფუძვლიანად იტესტება პირადად. შემდეგ გამოსწორება წარდგენილია, როგორც pull request, ისევე როგორც ნებისმიერი სხვა კოდის ცვლილება, მაგრამ PR-ის აღწერა და დისკუსია აბუნდოვნებს გამოსწორების ნამდვილ ბუნებას. ის შეიძლება ჩამოყალიბდეს, როგორც რეფაქტორინგი, შესრულების გაუმჯობესება ან პოტენციური პრობლემებისგან გამაგრება. ეს საშუალებას აძლევს გამოსწორებას გაიაროს ნორმალური კოდის განხილვა, ხოლო მოწყვლადობის დეტალები დარჩეს კონფიდენციალური. ეს მიდგომა მოიცავს რეალურ კომპრომისებს და მისი შენარჩუნება ნამდვილად რთული ბალანსირების აქტია. კრიტიკოსებმა შეიძლება იკამათონ, რომ ეს პატერნალისტურია ან რომ ის ზედმეტ ძალაუფლებას აკონცენტრირებს რამდენიმე დეველოპერის ხელში, რომლებმაც იციან მოწყვლადობების შესახებ საზოგადოების წინაშე. ეს შეშფოთებები სერიოზულ განხილვას იმსახურებს, მაგრამ დაუყოვნებელი საჯარო გამჟღავნების ალტერნატივა შეიძლება კატასტროფული იყოს. მოწყვლადობის დეტალების გამოქვეყნება მანამ, სანამ მომხმარებლების უმეტესობა განახლდება, არსებითად აწვდის თავდამსხმელებს როგორც სამიზნე სიას (განუახლებელი კვანძები), ასევე იარაღს (ექსპლოიტის კოდი). Fuzzing არის ტესტირების ტექნიკა, რომელიც პროგრამულ უზრუნველყოფას აწვდის შემთხვევით, არასწორად ფორმატირებულ ან მოულოდნელ შეყვანებს შეცდომების მოსაძებნად. ძირითადად, ის უწყვეტად ავტომატურად წარმოქმნის და ცვლის სატესტო შემთხვევებს, აწვდის მათ პროგრამას და აკვირდება მოულოდნელ ქცევას, როგორიცაა კრაშები, გაყინვები, ლოგიკური შეცდომები და ა.შ. თანამედროვე ფაზერები იყენებენ ევოლუციურ ალგორითმებს იმის გასარკვევად, თუ რომელი შეყვანები იწვევს საინტერესო კოდის გზებს, შემდეგ კი ცვლიან ამ შეყვანებს პროგრამაში უფრო ღრმად შესასწავლად. ეს არის ეფექტური გზა ისეთი კიდური შემთხვევების შეცდომების მოსაძებნად, რომელთა აღმოჩენა თითქმის შეუძლებელი იქნებოდა ხელით ტესტირებით ან კოდის განხილვით იმავე სიჩქარით. რადგან ფაზერი უზრუნველყოფს შეყვანებს ამ ტესტირებისთვის, დეველოპერს არ შეუძლია პირდაპირ დაადასტუროს მოსალოდნელი შედეგები (მაგ., შეყვანა A უნდა იძლეოდეს გამოსავალს B). ამის ნაცვლად, ისინი აკეთებენ განცხადებებს ზოგადი თვისებების შესახებ, რომლებიც პროგრამულმა უზრუნველყოფამ უნდა შეინარჩუნოს. ეს უკიდურესად ღირებულია, რადგან ის საშუალებას გვაძლევს ავაშენოთ უფრო ფართო ნდობა სასურველ ქცევაში ისეთი თვისებების ტესტირებით, როგორიცაა კვანძის კრაშის პრევენცია ან მონეტის მიწოდების არასდროს გაზრდის უზრუნველყოფა მოსალოდნელზე მეტად. სისწორის, სიმტკიცისა და უსაფრთხოების კრიტიკული საჭიროების გამო, Bitcoin Core ფართოდ იყენებს fuzzing-ს სხვადასხვა მიდგომებით. Bitcoin Core-ის ისტორიის განმავლობაში, fuzz ტესტირების ძალისხმევა იზრდებოდა. ძალიან პრიმიტიული fuzzing-ის ყველაზე ადრეული ხსენებები 2012 წლით თარიღდება და მარტივი fuzzing ფრეიმვორკის ინტეგრაცია მოხდა 2016 წელს, რომელიც განვითარდა დღევანდელ ყოვლისმომცველ ფრეიმვორკად 200-ზე მეტი ინდივიდუალური fuzz ტესტით, რომელიც მოიცავს კოდის ბაზის კრიტიკულ ინდივიდუალურ კომპონენტებსა და ფუნქციებს. სტანდარტული ერთეულის ტესტებისგან განსხვავებით, fuzz ტესტებს არ აქვთ განსაზღვრული „გავლის“ წერტილი, ანუ თქვენ არ აწარმოებთ მათ ერთხელ და არ იღებთ „გავლილი“ ან „ჩავარდნილი“ სტატუსს სანაცვლოდ. რადგან fuzzing არის უწყვეტი შემთხვევითი პროცესი, შედეგების შესახებ ნებისმიერი განცხადება (როდესაც ხარვეზები არ არის ნაპოვნი) შეიძლება იყოს მხოლოდ ალბათობითი. fuzz ტესტი შეიძლება გაგრძელდეს 5000 საათის განმავლობაში შეცდომის პოვნის გარეშე, თუმცა მომდევნო 5000 საათმა შეიძლება აღმოაჩინოს ერთი. შესაბამისად, ეფექტურობისთვის, fuzz ტესტები უწყვეტად უნდა შესრულდეს. მიუხედავად იმისა, რომ Bitcoin Core ეყრდნობა Google-ის oss-fuzz ინფრასტრუქტურას თავისი fuzz ტესტების გასაშვებად, ის ასევე დიდ ინვესტიციას ახორციელებს საკუთარის მშენებლობაში, რამდენიმე კონტრიბუტორი უწყვეტად ატარებს fuzzing-ს საკუთარი დაყენებებით. მაგალითად, Brink-ის ინფრასტრუქტურა მარტო უზრუნველყოფს წელიწადში 1 მილიონზე მეტ CPU საათს Bitcoin Core-ის fuzzing-ისთვის. მიუხედავად იმისა, რომ Bitcoin Core-ის რეპოზიტორიუმს აქვს მრავალი fuzz ტესტი კომპონენტის/ფუნქციის დონეზე, რამდენიმე გარე პროექტი იყენებს განსხვავებულ fuzzing სტრატეგიებს. Cryptofuzz, რომელიც ახლა შეწყვეტილია, ფოკუსირებული იყო დიფერენცი