Kto kontroluje Bitcoin Core?

[akos]

Postanowiłem spełnić swoją własną sugestię i przetłumaczyć tekst, który Jameson Lopp umieścił na swoim blogu. Jego zrozumienie moim zdaniem rozjaśnia znacznie mroki hipotez snutych w wątkach "sensacyjnych" (viewtopic.php?f=8&t=33168, viewtopic.php?f=21&t=33348), w których namiętnie praktykuje się wypełnianie luk w wiedzy domysłami oraz jak ognia unika się podawania kryterium falsyfikacji dla stawianych tez ogólnych. Żadnego z tych zarzutów nie można jak sądzę postawić poniższej pracy. Drugi powód ze względu na który zdecydowałem się przetłumaczyć akurat ten tekst uznając go za jeden z ważniejszych jakie czytałem w ostatnich miesiącach na temat Bitcoina i kryptowalut w ogóle, to, że jak wspomniałem wcześniej, stanowi on

kompendium zawierające mnóstwo podlinkowanej w uporządkowany sposób wiedzy dotyczącej developmentu btc

Osoby zainteresowane śledzeniem rozwoju Bitcoin Core, mogą go nawet traktować jako przewodnik zawierający szereg odnośników do dalszej wiedzy.

-----------------------------------------------

Kto kontroluje Bitcoin Core?



Pytanie o to kto kontroluje możliwość merge'owania¹ zmian kodu w repozytorium GitHub Bitcoin Core pojawia się regularnie. Było ono wymieniane jako "centralny punkt kontroli" protokołu Bitcoina przez różne strony na przestrzeni lat, ale ja uważam, że samo to pytanie jest zasłoną dymną, ponieważ jest postawione z perspektywy autorytarnej - a ten model nie dotyczy Bitcoina. Z pewnością dla laika nie jest oczywiste, dlaczego tak jest, dlatego celem tego artykułu jest wyjaśnienie, w jaki sposób funkcjonuje Bitcoin Core i, na wyższym poziomie, jak ewoluuje sam protokół Bitcoin.

Historia Bitcoin Core

Bitcoin core w procesie developmentu protokołu Bitcoina jest raczej punktem skupienia² niż punktem dowodzenia i kontroli. Jeśli z jakiegoś powodu przestałby istnieć, pojawiłby się nowy punkt skupienia - platforma komunikacji technicznej, na której jest oparty (aktualnie repozytorium GitHub) jest raczej kwestią umowy niż jednej z definicji / integralności projektu. W rzeczywistości, widzieliśmy już zmienianie platform developmentu a nawet nazw przez bitcoinowy punkt skupienia.

• Na początku 2009 kod źródłowy projektu Bitcoin był po prostu plikiem .rar hostowanym na SourceForge'u. Wcześni developerzy właściwie wymieniali patche kodu z Satoshim drogą mailową.
• 30 października 2009, Sirius (Martti Malmi) stworzył repozytorium SVN dla projektu Bitcoin na SourceForge'u.
• W 2011 projekt Bitcoin został zmigrowany z SourceForge'a do repozytorium GitHub.
• W 2014 nazwa projektu Bitcoin została zmieniona na Bitcoin Core.

Nie ufaj nikomu

Choć na poziomie organizacyjnym istnieje kilka kont "opiekunów"³ GitHub mających możliwość merge'u kodu do gałęzi master, pełnią one raczej funkcję porządkową niż działają z pozycji władzy. Gdyby każdy mógł wykonać merge do mastera szybko doszłoby do scenariusza "zbyt wielu kucharzy w jednej kuchni". Bitcoin Core kieruje się zasadami najmniejszych uprawnień, tak, że dowolna władza oddana jednostkom może być z łatwością odebrana jeśli zostanie nadużyta.



Core jest transparentny względem listy mającej znaczenie: kluczy PGP, którymi można podpisać commit merge'ujący.
Lekcja do nauczenia to: nie ufać GitHub! Nawet Bitcoin Core nie zna całej listy ludzi mogących modyfikować repozytorium, ze względu na to, że dotyczy to prawdopodobnie kilkudziesięciu pracowników GitHub.

Z kontradyktoryjnego punktu widzenia, GitHubowi nie można ufać. Dowolna liczba pracowników GitHub mogłaby użyć swoich uprawnień administratorskich by wprowadzić kod do repozytorium bez zgody opiekunów. Jednak jest mało prawdopodobne by GitHubowy atakujący był również w stanie przejąć klucz PGP opiekuna Bitcoin Core.
Zamiast opierać integralność kodu na kontach GitHub, BitcoinCore posiada system ciągłej integracji wykonujący weryfikacje zaufanych kluczy PGP wymaganych do podpisania każdego commita merge'ującego.
Choć te klucze są przypisane do znanych tożsamości, nadal nie jest bezpiecznie zakładać, że zawsze tak będzie - klucz mógłby zostać przejęty i nie wiedzielibyśmy o tym dopóki oryginalny właściciel klucza nie powiadomiłby pozostałych opiekunów. W związku z tym klucze commitów również nie zapewniają perfekcyjnego bezpieczeństwa, po prostu utrudniają atakującemu wprowadzenie uznaniowego kodu.

Klucze do królestwa

W momencie pisania tych słów, poniższe są zaufanymi odciskami PGP:

71A3B16735405025D447E8F274810B012346C9A6
133EAC179436F14A5CF1B794860FEB804E669320
32EE5C4C3FA15CCADB46ABE529D4BCB6416F53EC
B8B3F1C0E58C15DB6A81D30C3648A882F4316B9B
CA03882CB1FC067B5D3ACFE4D300116E1C875A3D

Te klucze są zarejestrowane na:

Wladimir J. van der Laan <laanwj@protonmail.com>
Pieter Wuille <pieter.wuille@gmail.com>
Jonas Schnelli <dev@jonasschnelli.ch>
Marco Falke <marco.falke@tum.de>
Samuel Dobson <dobsonsa68@gmail.com>

Czy to oznacza, że ufamy tym pięciu osobom? Niezupełnie. Klucze nie są potwierdzeniem tożsamości - klucze mogłyby potencjalnie wpaść w ręce innych ludzi. Jakie gwarancje faktycznie otrzymujemy uruchamiając pythonowy skrypt verify-commits?

python3 contrib/verify-commits/verify-commits.py 
Using verify-commits data from bitcoin/contrib/verify-commits
All Tree-SHA512s matched up to 309bf16257b2395ce502017be627186b749ee749
There is a valid path from “HEAD” to 82bcf405f6db1d55b684a1f63a4aabad376cdad7 where all commits are signed!

Skrypt verify-commits jest weryfikatorem integralności, który każdy developer może wykonać na swojej maszynie. Po uruchomieniu, sprawdza sygnatury PGP każdego commita merge'ującego od commita 82bcf405… z grudnia 2015 - ponad 3400 merge'ów w momencie pisania tego artykułu.
Gdy skrypt wykona się z powodzeniem, mówi to nam, że każda linia kodu zmodyfikowana od tamtego punktu [od commita o ID 82bcf405f6db1d55b684a1f63a4aabad376cdad7 - przyp. akos] przeszła przez proces developmentu Bitcoin Core i została podpisana przez kogoś kluczem opiekuna. Choć nie stanowi to niezachwianej gwarancji, że nikt nie wstrzyknął⁴ złośliwego kodu (opiekun mógł się zbuntować lub jego klucz mógł zostać skradziony), to ogromnie ogranicza płaszczyznę ataku. Kim są opiekunowie i jak otrzymali swoją rolę? Zajmiemy się tym nieco później.

edit: zastąpienie '.' przez '?' w przedostatnim zdaniu
edit2: poprawka odnośników do maili opiekunów

[akos]

Warstwowe bezpieczeństwo

Spójność kodu Bitcoin Core nie może opierać się jedynie na garstce kluczy kryptograficznych, dlatego istnieje mnogość innych kontroli. Jest wiele warstw bezpieczeństwa zapewniających głęboką obronę:

Ochrona Pull Request⁵

1. Każdy ma prawo zaproponować zmiany w kodzie usprawniające program otwierając pull request do gałęzi master bitcoin/bitcoin.
2. Developerzy przeprowadzają rewizję requestów aby upewnić się, że nie są one szkodliwe. Każdy może wykonać taką rewizję i przekazać opinię - nie ma żadnego strażnika ani egzaminu wejściowego w przypadku wnoszenia wkładu do Bitcoin Core. Jeśli pull request osiąga punkt, w którym nie ma żadnych uzasadnionych zastrzeżeń do jego zmerge'owania, opiekun wykonuje merge.
3. Opiekunowie Core ustawiają ten pre-push hook by upewnić się, że nie wypchną niepodpisanych commitów do repozytorium. [kod uruchamiany przed wykonaniem komendy push sprawdzający podpis commita za pomocą wspomnianego wcześniej skryptu verify-commits o ile push dotyczy gałęzi master - przyp. akos]
4. Commity merge'ujące są opcjonalnie bezpiecznie ostemplowane znacznikami czasu przez OpenTimestamps.
5. System ciągłej integracji Travis regularnie uruchamia ten skrypt [poprawiona ścieżka względem oryginalnego tekstu artykułu - przyp. akos] by sprawdzić spójność drzewa git (historię) i by zweryfikować czy wszystkie commity w gałęzi master zostały podpisane jednym z zaufanych kluczy PGP.
6. Każdy kto zechce, może uruchomić ten skrypt weryfikujący sygnatury PGP wszystkich commitów merge'ujących począwszy od grudnia 2015. Uruchomiłem go w trakcie pisania tego artykułu i jego wykonanie zajęło 25 minut na moim laptopie.

Ochrona Wydań

1. Systemy deterministycznego procesu budowy Gitian są uruchamiane niezależnie przez wielu developerów w celu zbudowania (skompilowania) identycznych binariów. Jeśli ktoś zdoła utworzyć build nie pasujący do zbudowanych przez innych developerów, jest to znakiem, że został wprowadzony indeterminizm a zatem ostatecznie wydanie [release - przyp. akos] nie nastąpi. Jeśli wystąpi indeterminizm, developerzy śledzą co poszło nie tak, naprawiają to i budują kolejnego kandydata do wydania. Gdy deterministyczny build się powiedzie, developerzy podpisują wynikowe binaria, gwarantując, że binaria oraz łańcuch narzędzi nie były naruszone i że użyto tego samego źródła. Ta metoda wyklucza build i proces dystrybucji z bycia pojedynczym punktem awarii [single point of failure (SPOF) - przyp. akos]. Każdy z umiejętnościami technicznymi może uruchomić własny system budowy; instrukcje są tu.
2. Gdy kompilacje Gitian zakończą się sukcesem i zostaną podpisane przez twórców, opiekun Bitcoin Core podpisze za pomocą PGP wiadomość hashami SHA256 każdej kompilacji. Jeśli zdecydujesz się uruchomić zbudowane binaria, możesz sprawdzić ich hash po ściągnięciu i zweryfikować autentyczność podpisanej wiadomości wydania. Instrukcje jak to zrobić można znaleźć tu.
3. Wszystko powyżej jest open source i do skontrolowania przez każdego kto ma odpowiednie umiejętności i potrzebę by to zrobić.
4. Wreszcie, nawet po przejściu przez wszystkie powyższe weryfikatory spójności i jakości, kod, który jest zatwierdzony w Bitcoin Core i ostatecznie "przetoczony" w wydanie, nie jest wdrażany na węzłach sieci przez jakąkolwiek scentralizowaną organizację. Raczej każdy operator węzła musi podjąć świadomą decyzję by wykonać update kodu, który uruchamia. Bitcoin Core celowo nie zawiera funkcji auto-update, gdyż potencjalnie mogłoby to zostać wykorzystane aby zmusić użytkowników do uruchomienia kodu, którego nie wybrali wprost.

Pomimo wszystkich technicznych środków bezpieczeństwa, które są zaimplementowane w projekcie Bitcoin Core, żadne z nich nie są perfekcyjne i każdy z nich może być teoretycznie naruszony. Ostatnia linia obrony integralności kodu Bitcoin Core jest taka sama jak w każdym innym projekcie open source - stała czujność. Im więcej oczu dokonuje rewizji kodu Bitcoin Core, tym mniejsze prawdopodobieństwo, że wadliwy lub złośliwy kod przedostanie się do wydania.

Pokrycie kodu⁶

Bitcoin Core posiada dużo kodu testującego. Istnieje pakiet testów integracyjnych uruchamianych na każdym PR [pull request - przyp. akos] i rozszerzony pakiet testowy uruchamiany każdej nocy na gałęzi master.

Możesz sprawdzić pokrycie kodu samodzielnie:

1. Wykonując clone repozytorium GitHub projektu Bitcoin Core.
2. Instalując zależności potrzebne do zbudowania projektu z kodu źródłowego.
3. Uruchamiając te komendy
4. Przeglądając raport w: ./total_coverage/index.html

Alternatywnie, możesz obejrzeć raport pokrycia kodu, który Marco Falke hostuje tu.



Posiadanie tak dużego poziomu pokrycia testami oznacza większy poziom pewności, że kod funkcjonuje tak jak zamierzono.

Testowanie jest poważną sprawą w przypadku oprogramowania krytycznego dla problemu konsensusu systemu rozproszonego⁷. Dla szczególnie skomplikowanych zmian, developerzy niekiedy przeprowadzają żmudne testy mutacyjne - to znaczy testują testy przez celowo wprowadzone błędy w kodzie i obserwowanie czy testy kończą się błędem zgodnie z oczekiwaniem. Greg Maxwell nieco przybliżył ten proces gdy omawiał wydanie wersji 0.15:



Konkurencja wolnorynkowa

BitMEX napisał świetny artykuł na temat ekosystemu implementacji Bitcoina. Istnieje ponad tuzin różnych kompatybilnych implementacji Bitcoina oraz jeszcze więcej implementacji "konkurencyjnych sieci". To wolnościowy kod open source - każdy kto jest niezadowolony z wysiłków projektu Bitcoin Core może rozpocząć własny projekt. Można zacząć od zera albo można wykonać fork oprogramowania Core.

[akos]

W momencie pisania tego tekstu, 96% osiągalnych węzłów Bitcoin jest uruchomionych na którejś wersji Bitcoin Core. Dlaczego tak jest? Jak Bitcoin Core może mieć status bliski monopolu wśród węzłów sieci skoro wysiłek potrzebny do przesiadki na inną implementację jest minimalny? Ostatecznie, wiele innych implementacji udostępnia API RPC kompatybilne z, a przynajmniej zbliżone do, Bitcoin Core.



Uważam, że wynika to z faktu, że Bitcoin Core jest punktem skupienia developmentu. Stoi za nim i wspiera go o rzędy wielkości więcej czasu developerskiego oraz talentu, co oznacza, że kod wyprodukowany przez projekt Bitcoin Core wydaje się być najbardziej wydajny, niezawodny i bezpieczny. Operatorzy węzłów nie chcą uruchamiać drugiego w kolejności najlepszego oprogramowania gdy w grę wchodzi zarządzanie pieniędzmi. Ponadto, biorąc pod uwagę, że jest to system rozproszony oraz, że protokół Bitcoin nie posiada - oraz prawdopodobnie nie może posiadać - formalnej specyfikacji, ponieważ nikt nie ma odpowiedniej władzy aby ją napisać, jest nieco bezpieczniej używać implementacji punktu skupienia, gdyż jest bardziej prawdopodobne, że będzie kompatybilna z dokładnością do błędów z większością pozostałej sieci. W tym sensie, kod punktu skupienia developmentu jest rzeczą najbliższą specyfikacji, jaka istnieje.

Kim są developerzy Bitcoin Core?

Ludzie nie obznajomieni z procesem developmentu Bitcoin Core mogą spojrzeć na projekt z zewnątrz i rozpatrywać Core jako byt monolityczny. To jest dalekie od rzeczywistości! Mają miejsce częste spory pomiędzy osobami wnoszącymi wkład⁸ w projekt Core i nawet najbardziej żywotni współpracownicy napisali mnóstwo kodu, który nigdy nie został zmerge'owany do projektu. Gdy czytasz wytyczne do procesu wnoszenia wkładu możesz zauważyć, że są one dość luźne - proces mógłby być opisany jako "szorstki konsensus"⁹.

Opiekunowie wezmą daną poprawkę pod uwagę jeśli pozostaje w zgodzie z ogólnymi zasadami projektu; spełnia minimalne standardy do zawarcia w projekcie; oraz zostanie oceniona przez ogólny konsensus współpracowników.

Kim są opiekunowe Bitcoin Core? Są osobami, które wniosły wartościowy wkład budując wystarczający kapitał społeczny w ramach projektu przez pewien czas. Gdy istniejąca grupa opiekunów uzna, że byłoby rozważnym rozszerzenie roli współpracownika, który pokazał kompetencje, niezawodność i motywację w określonym obszarze, mogą przyznać uprawnienia do wykonywania commitów dla konta GitHub tej osoby. Rola głównego opiekuna jest przeznaczona dla kogoś kto sprawuje nadzór nad wszystkimi aspektami projektu i jest odpowiedzialny za koordynowanie wydań. Przez lata była ona dobrowolnie przekazywana:

• Satoshi Nakamoto: 03.01.2009 - 23.02.2011
• Gavin Andresen: 23.02.2011 - 07.04.2014¹⁰
• Wladimir van der Laan: 07.04.2014  - obecnie

Działanie jako opiekun Bitcoin Core jest często odnoszone do pracy porządkującej, ponieważ opiekunowie właściwie nie mają władzy podejmowania decyzji sprzecznych z konsensusem developerów lub użytkowników. Jednakże, rola ta może być dość obciążająca z uwagi na dodatkową uwagę całego ekosystemu. Dla przykładu, Gregory Maxwell, zrezygnował ze swojej roli opiekuna w 2017 z powodów osobistych, prawdopodobnie ze względu na doświadczenie publicznej presji w trakcie debaty dotyczącej problemu skalowania. Wladimir napisał refleksyjnego posta na temat stresu związanego z byciem opiekunem Core oraz wyjaśniającego dlaczego było właściwym by odebrać Gavinowi prawa do commitowania, co zdenerwowało wielu ludzi.

Podobnie, gdy Jeff Garzik został usunięty z systemu GitHub, on i inni byli zaniepokojeni, ale nie wniósł żadnego wkładu do Core w ciągu dwóch lat. Pozostawienie jego konta GitHub z prawami do zapisu do repozytorium nie dawało żadnych korzyści projektowi - tworzyło jedynie ryzyko związane z bezpieczeństwem oraz naruszało zasadę najmniejszych uprawnień, do której Wladimir odnosił się w swoim tekście.

Inni mogą spojrzeć na Core i wierzyć, że jest to technokracja lub wieża z kości słoniowej co sprawia, że trudno jest dołączyć do niej nowym uczestnikom. Jednak, jeśli porozmawiasz z developerami, odkryjesz, że to tak nie wygląda. Choć na przestrzeni lat tylko grupka ludzi posiadała uprawnienia do wykonywania commitów, setki developerów wniosło swój wkład. Ja osobiście wniosłem kilka niewielkich prac; choć nie uznaję się za "developera Core", technicznie jestem jednym z nich. Nikt nie może powstrzymać Cię od dokonania wkładu do Bitcoin Core!



Mainstreamowe media lubią skupiać się na "toksyczności" Bitcoina. Podzielmy się jakimiś pozytywnymi, podnoszącymi na duchu historiami aby temu przeciwdziałać.
W 2011, gdy byłem uczniem szkoły średniej, który nie rozumiał czym jest wskaźnik, społeczność developerów @bitcoincoreorg (zwłaszcza ludzie tacy jak Greg Maxwell, @pwuille itd.) pracowali ze mną by sprawić aby moje gówniane patche były warte zmerge'owania i tworząc wspaniałe środowisko do nauki.



W 2016, @TheBlueMatt zorganizował pobyt w ChaincodeLabs. Czytałem wówczas wszystko o Bitcoinie co wpadło mi w ręce, ale nie miałem odwagi zgłosić Pull Request. Matt, Alex i Suhas niezwykle hojnie poświęcili swój czas ucząc nas o Bitcoinie i wnoszeniu wkładu.



Zacząłem robić niewielkie commity do @bitcoincoreorg i byłem zachwycony zaangażowaniem nad moimi Pull Requestami ze strony MarioFalke, pwuille, orionwl, LukeDashjr i jfnewbery. Cóż za przyjemny projekt!

Jedną z najtrudniejszych rzeczy i wyzwaniem dla zrozumienia przez ludzi wydaje się być to, że punkt skupienia developmentu Bitcoin nie jest po prostu strukturą zdefiniowaną przez konto Bitcoin Core na platformie GitHub. Choć Bitcoin Core posiada pewną strukturę (korzysta ze scentralizowanych kanałów komunikacji w celu koordynacji), sam projekt nie podlega kontroli żadnego z jego uczestników - nawet tych mających podwyższone uprawnienia w repozytorium GitHub. Chociaż jest technicznie możliwe dla zorganizowanej grupy opiekunów dokonać przejęcia repozytorium GitHub, ocenzurowania developerów - dysydentów, i być może nawet utrzymania nazwy markowej "Bitcoin Core", rezultatem tego byłoby, że Bitcoin Core przestałby być punktem skupienia developmentu. Developerzy, którzy nie zgodziliby się z akcjami opiekunów, po prostu wykonaliby fork kodu i przenieśli swoją pracę do innego repozytorium, w którym opiekunowie Bitcoin Core nie mieliby uprawnień administracyjnych.

Nawet przy braku "puczu" jako takiego, jeśli kontrowersyjna zmiana jakimś sposobem znalazłaby się w Core, niektórzy developerzy wykonaliby fork oprogramowania, usunęli kontrowersyjną zmianę i uczynili go dostępnym dla użytkowników. Można argumentować, że dokładnie tak się stało gdy Amaury Sechet wykonał fork Bitcoin Core i usunął funkcjonalność Segregated Witness aby stworzyć Bitcoin ABC. Alternatywnie, gdy Core odrzuca proponowane zmiany, których domagają się niektórzy ludzie, developerzy mogą wykonać fork i dodać te zmiany. To zdarzało się wielokrotnie, np. gdy:

• Mike Hearn zrobił fork Core tworząc Bitcoin XT
• Andrew Stone zrobił fork Core tworząc Bitcoin Unlimited
• Jeff Garzik zrobił fork Core tworząc BTC1

edit: "ją napisać" zamiast "go napisać"

[akos]

Wykonanie forka kodu jest łatwe. Przesunięcie punktu skupienia developmentu Bitcoina jest trudne - musisz przekonać developerów, że ich czas będzie lepiej spożytkowany przy wnoszeniu wkładu do innego projektu.



Nie utrzymuję wierności żadnemu człowiekowi, żadnemu zespołowi developerskiemu Bitcoin. Moją intencją jest uruchamiać kod, który oceniam jako najlepiej zabezpieczający moja finansową suwerenność.

Trudno jest również przekonać wielu ludzi, że użytkownicy nie podążają ślepo za zmianami robionymi przez Bitcoin Core - to może być samo wzmacniające się przekonanie, ponieważ jeśli użytkownicy nie uczestniczą w procesie konsensusu pozostając świadomymi tego jakie posiadają opcje, tym samym cedują część swojej władzy na developerów. Jednakże, władza użytkowników była przećwiczona podczas ruchu UASF (User Activated Soft Fork) w 2017. Anonimowy developer używający pseudonimu shaolinfry zaproponował BIP 148, który zmuszałby górników do aktywacji funkcjonalności Segregated Witness od bloku, który pojawiłby się około pierwszego sierpnia. Wykazano jednak, że BIP 148 jest zbyt kontrowersyjny aby zostać przyjętym przez Bitcoin Core, więc shaolinfry zrobił fork Core i uczynił dostępnym oprogramowanie "Bitcoin UASF. Ta implementacja zyskała nietrywialną ilość uwagi i zdawała się tworzyć wystarczającą presję w celu przekonania górników do przyjęcia BIP 91 by aktywować fork przed ostatecznym terminem BIP 148.

W mojej opinii, najlepsi developerzy Bitcoin Core to ci, którzy praktykują ekstremalną odpowiedzialność¹¹. Przykładowo - choć John Newbery nie napisał kodu zawierającego pewien konkretny błąd związany z problemem konsensusu, czuje się odpowiedzialny za niezapobieżenie jego zmerge'owaniu poprzez uważną rewizję i za nieodkrycie go później podczas pisania przypadków testowych.



Jestem odpowiedzialny za błąd CVE-2018-17144
Stało się źle, że błędny kod został zmerge'owany. Tak, schrzaniliśmy to, ale "my", którzy schrzaniliśmy ma bardzo szeroki zakres. Cała społeczność schrzaniła nie robiąc wystarczająco dokładnej rewizji zmian konsensusu, więcej developerów musi zachować uwagę! To wasza cała odpowiedzialność.

Wszyscy jesteśmy Satoshim



Wnoszenie wkładu do Bitcoin Core

Można czuć obawy by zacząć tworzyć swój wkład w Core, jednak dostępnych jest wiele zasobów pomocnych ambitnym developerom. Wytyczne dla procesu developmentu znajdują się tu aczkolwiek można zacząć od "Łagodnego wprowadzenia do developmentu Bitcoin Core" Jimmiego Songa.

Developer Core, Eric Lombrozo, również napisał krótki tekst o tym jak rozumieć proces dokonywania zmian w repozytorium Core - Proces Merge'owania w Bitcoin Core.

Alex B. napisał doskonały artykuł o filozofii stojącej za developmentem Bitcoina - każdy kto chce zostać poważnym współpracownikiem może zaoszczędzić sobie mnóstwo czasu dzięki tej lekturze.

Nowo przybili mogą być także zainteresowani dołączeniem do Bitcoin Core PR Review Club by przyjrzeć się temu jak wykonywane są rewizje kodu.

Pomocny może być konkretny przykład - w czasie pisania tego artykułu odkryłem trudności podczas prób uruchomienia skryptu verify-commits.py na mojej maszynie w celu zbadania integralności historii commitów w GitHub. Aby uchronić przyszłych developerów od zmagań z tymi problemami, otworzyłem Pull Request usprawniający dokumentację. Jak można zauważyć w historii zmian PR, czterech różnych developerów wtrąciło swoje sugestie jak mógłbym poprawić mój pull request. Te mieściły się w zakresie od pomysłu używania innego znacznika wiki poprzez uproszczenie komendy bash do zasugerowania nowego parametru, który mógłby zostać użyty w skrypcie verify-commits.py. Uznałem, że wszystkie sugestie miały sens, więc zawarłem je w moim kodzie i wypchnąłem poprawioną wersję mojego pull requestu. W tym momencie, developerzy, którzy uczestniczyli w rewizji, potwierdzili, że uznają PR za akceptowalny i opiekun, Marco Falke oznaczył go do umieszczenia w wersji 0.18. Po kilku kolejnych dniach bez zastrzeżeń ze strony innych developerów, kod został zmerge'owany z Core przez opiekuna Samuela Dobsona.

Kto kontroluje Bitcoina?

Jak obszernie argumentowałem przez lata, pełne zrozumienie systemu Bitcoin jest praktycznie niemożliwe. Definicja (kontrola) protokołu Bitcoina jest jak definicja języka. Języki powstają spontanicznie; konsensus na temat znaczeń słów jest raczej organiczny niż podyktowany przez słowniki. Tak jak słowniki bardziej opisują fenomen języka niż definiują go, tak implementacje Bitcoina opisują język Bitcoina przy użyciu kodu. Nikt nie jest zmuszany by zgadzać się z definicją słownikową danego słowa, jak i nikt nie jest zmuszany do uznania kodu danej implementacji Bitcoin poprzez jej uruchomienie.

Języki nie są zarządzane poprzez demokrację i również tak nie jest w przypadku Bitcoina; choć można usłyszeć, że ludzie odnoszą się do górników, węzłów, developerów, lub użytkowników, którzy "głosują", nie ma takiego mechanizmu, który umożliwiałby większości przegłosowanie w jakikolwiek sposób przymuszenia mniejszości dysydentów do zaakceptowania zmian, z którymi się oni nie zgadzają. Bitcoin jest anarchią - bez regulatorów, lecz nie bez reguł. Reguły są definiowane i egzekwowane przez indywidualnych uczestników sieci.

Choć zmiany samego protokołu Bitcoina są zwykle robione poprzez proces Bitcoin Improvement Proposal, nawet to jest jedynie rekomendowaną dobrą praktyką i nikt nie może być zmuszony by jej przestrzegać. Jest to jedynie bardziej sformalizowany sposób próby pokierowania zmianą protokołu poprzez proces wzajemnych rewizji oraz budowania konsensusu.

Tak trudne jak to jest do wyjaśnienia i do zrozumienia, tak istotne jest to dla antykruchości Bitcoina [zespołu właściwości produktu, który zwiększa swoją zdolność do rozwoju w wyniku czynników "stresowych", takich jak pomyłki, awarie, ataki - przyp. akos] - gdyby istniał pojedynczy punkt kontroli, byłby jednocześnie pojedynczym punktem awarii, który zostałby wykorzystany przez potężne podmioty zagrożone sukcesem Bitcoina. Ostatecznie, każdy operator węzła rządzi sam sobą upewniając się, że nikt inny w sieci nie łamie zasad, z którymi się zgadza. Ten model bezpieczeństwa jest fundamentem oddolnego zarządzania Bitcoinem.



Nikt nie kontroluje Bitcoina.

Nikt nie kontroluje punktu skupienia developmentu Bitcoina.

[akos]

Przypisy tłumacza:

1) Niektórych pojęć związanych z procesem tworzenia oprogramowania, jak "merge" lub "commit" (a także popularnych i znanych, jak tytułowy "Bitcoin Core"), postanowiłem nie tłumaczyć na ich najbliższe polskie odpowiedniki w rodzaju "scalanie", "zatwierdzanie", ponieważ, nie licząc literatury książkowej, w praktyce raczej nie spotyka się spolszczeń mogących prowadzić do niejednoznaczności i niedokładnego rozumienia tekstu. Dla programisty będzie to oczywiste a dla nie-programisty znaczenie tych pojęć i tak pozostanie jedynie przybliżone, ale obecność angielskiego oryginału w tłumaczeniu będzie wskazówką, że jest to termin techniczny, o którego sensie powinno się uzupełnić wiedzę dla lepszego rozumienia całego artykułu. Dla ułatwienia umieszczam również w tekście dodatkowe, nie występujące w oryginalnym artykule, linki do źródeł (w miarę dostępności, polskojęzycznych) wyjaśniające poszczególne pojęcia.
Przy czym słowo "commit" w tym tekście prawie zawsze odnosi się co commitów merge'ujących daną zmianę do gałęzi głównej (master) projektu. W ogólniejszym sensie dotyczy ono wprowadzenia dowolnej zmiany w kodzie, również niezatwierdzonej, w różnych gałęziach projektu.

2) Termin focal point, pochodzący z teorii gier odnoszę do "punktu skupienia", zgodnie z tłumaczeniem przyjętym w polskim wydaniu książki Thomasa C. Schellinga pt. Strategia konfliktu, czyli takiego wyobrażonego punktu zaczepienia, który pozwala na zgranie oczekiwań - patrz fragment przedmowy do polskiego wydania, s. XV.
Rozumienie tego pojęcia jest kluczowe dla zrozumienia całego artykułu. Najłatwiej przyswoić jego sens poprzez proste przykłady - np. rozważmy grę, w której gracze nie znający wzajemnie swoich decyzji, mają za zadanie podzielić między siebie 100$, podając kwotę, którą chcieliby otrzymać, przy założeniu, że jeśli obie podane kwoty po zsumowaniu dadzą więcej niż 100, to wówczas nie dostaną pieniędzy. Okazuje się, że większość graczy poda liczbę 50, która wydaje się wyborem "zgrania oczekiwań". Inny przykład - gra polegająca na tym, żeby spotkać się w jakimś punkcie miasta z innymi graczami bez wcześniejszego ustalenia jego lokalizacji. Większość graczy wybierze po prostu najbardziej popularne i rozpoznawalne miejsce, jak np. główny plac w centrum itp.

3) Słowo "opiekun" (maintainer) należy tu rozumieć zamiennie z "serwisant", "konserwator". Tłumaczę je jednak jako "opiekun" dla podkreślenia aspektu odpowiedzialności w tym kontekście.

4) Angielskie "inject" może być tu nieco mylące. W języku programistów słowo to ma ściśle określone znaczenie związane z "wstrzykiwaniem" zależności w niektórych językach obiektowych, takich jak np. Java. W tym kontekście chodzi jednak oczywiście o wprowadzenie złośliwego kodu lub złośliwej modyfikacji kodu.

5) Najprościej mówiąc, pull request polega na upublicznieniu propozycji modyfikacji kodu w celu poddania jej dyskusji oraz weryfikacji przez innych developerów.

6) Chodzi o pokrycie kodu testami - pojęcie pochodzące z techniki Test-driven development (TDD) .

7) Słowo "konsensu" w odniesieniu do procesu developmentu Bitcoin Core, i szerzej jakiegokolwiek oprogramowania, można rozumieć dwojako - w węższym technicznym sensie jako odnoszące się do problemu konsensusu w programowaniu współbieżnym i rozproszonym, zaś szerzej jako konsensus społecznościowy budowany w ramach współpracy przy projekcie. W przypadku zdania do którego jest to komentarz, uznałem (choć nie jestem tego w zupełności pewien), że autor miał na uwadze konsensus techniczny, stąd wprowadzony przeze mnie odnośnik do wiki.

8) Angielskie "contributor" tłumaczę zamiennie, w zależności od kontekstu, jako "współpracownik", "osoba wnosząca wkład" lub po prostu jako "developer" gdy w danym kontekście pojęcia te są równoznaczne.

9) Autor odwołuje się do terminu ukutego podczas prac Internet Engineering Task Force (IETF) oznaczającego, że wystarczy zgoda większości aby podjąć pewną decyzję co do dalszego rozwoju projektu, nie jest natomiast wymagana jednomyślność.

10) W momencie pisania tłumaczenia adres bitcoinfoundation.org zwracał http 403, więc umieściłem odnośnik do ostatniej wersji zarchiwizowanej przez web.archive.org.

11) Termin ten oznacza, że lider powinien być odpowiedzialny za wszystko co dzieje się w jego zespole a także, że każdy członek zespołu powinien czuć pełną współodpowiedzialność za los całej grupy. W przypadku projektu zdecentralizowanego, takiego jak Bitcoin, każdy developer powinien więc czuć się takim liderem odpowiedzialnym za wszystko, nie tylko za jakość i poprawność własnego kodu, ale również za kod każdego innego "towarzysza broni" o ile tylko czas i kompetencje pozwalają mu go zweryfikować.

--------------------------------------------

Roboczy, luźny wniosek końcowy tłumacza i zarazem krótki komentarz do wspomnianych wątków "sensacyjnych":

Zdecentralizowany proces developmentu Bitcoina, opisany jak wyżej, kręcący się wokół punktu skupienia społeczności oznacza, że najgorszą rzeczą jaką ewentualnie mogą zrobić hipotetyczne złowrogie siły "banksterskie" (zakładając chwilowo na potrzeby tego rozumowania, że są faktem - w praktyce nikt przekonująco nie wykazał takich destrukcyjnych powiązań), to popsuć Bitcoina "trochę", tak żeby było to niezauważalne dla większości członków społeczności W momencie popsucia zbyt mocno, punkt skupienia przeniesie się gdzie indziej a "banksterka" zostanie z mało wartościowym forkiem / altem w ręku, na którego przejęcie poświęciła duże zasoby. Taką zabawę w kotka i myszkę można kontynuować bez końca.

edit: poprawka powtórzenia, "ewentualnie mogą zrobić hipotetyczne złowrogie" zamiast "ewentualnie mogą zrobić hipotetyczne ewentualne złowrogie"

[fervi]

Tekst fajny chociaż chyba był już tłumaczony.

A za Bitcoinem stoją żydzi

[akos]

chyba był już tłumaczony

Gdzie? Mnie nie udało się nic znaleźć dlatego sam się za to zabrałem, poza tym było to dla mnie pouczające.

[fusywszklanejkuli]

I tak wszyscy wiemy jak jest:
Kto finansuje Core? Blockstream.
Kto finansuje Blockstream? Digital Currency Group.
Kto stoi za Digital Currency Group? Banksterka.
Co każde dziecko wie o relacji finansowania? Płacę - wymagam.

Dowód zakończony.

Opiekunowie Bitcoin Core są zatem nikim innym jak agentami wpływu banksterki, czuwającymi, by niechciane zmiany nie weszły do repozytorium. Są oczywiście nadzwyczaj kompetentni technicznie i potrafią wiarygodnie uzasadnić odrzucenie każdej niebezpiecznej dla swoich mocodawców propozycji. Gdyby z tego powodu wywiązała się dyskusja, również są w stanie z łatwością przekonać resztę developerów, że proponowane zmiany są niekorzystne. Doskonale pamiętamy casus zwiększenia rozmiaru bloku.

[socjolog2008]

@akos elegancko się czytało. Technicznie DCG , za spekulację Tether -to suka tethera jest https://www.drupal.org/project/usage/tether_stats), ideologicznie kiedyś Satoshi (kij wie kim on/oni są do końca). Dziś odpowiadamy My wszyscy, pan ,pani. Olała by większość Bitcoin Core i rozproszyła uwagę sami by się spakowali, a tak mamy drugi FED(usdt) i drugi Król (tyle że w świecie crypto*)

Spoiler:

https://www.pb.pl/dolar-pozostanie-krol ... lat-973064

Na pewno nie przewodzi BTC jedno już - jakakolwiek idea

[koparki]

złowrogie siły "banksterskie" (zakładając chwilowo na potrzeby tego rozumowania, że są faktem - w praktyce nikt przekonująco nie wykazał takich destrukcyjnych powiązań), to popsuć Bitcoina "trochę", tak żeby było to niezauważalne dla większości członków społeczności W momencie popsucia zbyt mocno, punkt skupienia przeniesie się gdzie indziej a "banksterka" zostanie z mało wartościowym forkiem

Po pierwsze doceniam wkład i czas spędzony na tłumaczeniu i upowszechnieniu.
Wątek na który się powołałeś w pierwszym poście( viewtopic.php?f=8&t=33168 ) miał zupełnie inne przesłanie, otwarte poszukiwania i osobiście nie użyłem tam określeń, że jakaś strona jest zła a inna dobra i że ta zła niszczy/sabotuje bitcoina.
Dla drukarni FED waluta niezależna, która na zasadzie wirusa mogłaby bez kontroli stać się nieformalnym pieniądzem międzynarodowym na 100% była nie na rękę, w taką stronę to mogło pójść i bez możliwości zatrzymania tak jak nie da się zatrzymać do dziś piractwa torrent (Japonia jeszcze przed LN uznała BTC jako w pełnoprawną "walutę obcą"). Ale bitcoin nie poszedł tą drogą, stał się czymś takim: viewtopic.php?f=27&t=25968&p=621021&hil ... to#p621021 (m.zd.)
Co nie oznacza sabotażu i zepsucia bitcoina ale kompromis i akceptowalność jego istnienia. Nikt nigdy się nie dowie czy LN nie było zainspirowane właśnie z tego powodu, to są poszlaki (mam śmiałość te poszlaki sugerować ze względu na dziwne powiązanie deweloperów BTC z DCG). Pamiętam pierwszą wzmiankę o LN , na głównym portalu Bitcoin.pl , admin portalu był wniebowzięty takimi perspektywami skalowania tej sieci i nikt nie ogarniał wtedy że to jest pożegnanie z walutą a przywitanie z platformą wielozadaniową blockchain - dużo było wtedy bankierskiej retoryki w mediach gdzie próbowano wygaszać funkcję waluty, każdy z nas to wtedy zauważał: "technologia blockchain" zamiast "kryptowaluty" i urzeczywistniło się to dziś w BTC.
Ta modyfikacja na pewno była dołączona do kodu z entuzjazmem i nie kojarzona z psuciem sieci. Drukarnia która potrafi obecnie produkować 70-140miliardów $ na miesiąc co było w czasach tworzenia LN jakims śmiesznym mikro-ułamkiem totalnej kapitalizacji bitcoina dysponuje też zapewne najlepszą ekipą tzw. think-tank aby różne problemy rozwiązywać.
Problem waluty rozwiązano mistrzowsko, nie zdelegalizowano i nie uczyniono z niej symbolu walki z systemem (jak nieśmiertelny torrent), zażegnano ewentualne zagrożenie dla systemu walutowego fiat, jest natomiast fajna platforma z marką na której można zrobić to i owo a bankierzy i główni deweloperzy BTC kręcą się wokół jakiś wspólnych interesów, to znaczy jedni są w portfelu drugich - gdyby nie ten fakt to słowem bym się nie odezwał.

[fervi]

Gdzie? Mnie nie udało się nic znaleźć dlatego sam się za to zabrałem, poza tym było to dla mnie pouczające.

Możliwe, że masz rację i czytałem po angielsku; zwracam honor, bo nie znalazłem nic

Dodano po 58 sekundach:

marką na której można zrobić to i owo a bankierzy i główni deweloperzy BTC kręcą się wokół jakiś wspólnych interesów, to znaczy jedni są w portfelu drugich - gdyby nie ten fakt to słowem bym się nie odezwał.

Daleko idąca insynuacja

[akos]

Wątek na który się powołałeś w pierwszym poście( viewtopic.php?f=8&t=33168 ) miał zupełnie inne przesłanie, otwarte poszukiwania i osobiście nie użyłem tam określeń, że jakaś strona jest zła a inna dobra i że ta zła niszczy/sabotuje bitcoina.

Ów wątek już w samym tytule ("Czy najpopularniejsze kryptowaluty rozwijają się jako niezależne,czy mają szanse w konflikcie interesów z drukarzem fiat") zawiera co najmniej 2 założenia pytania:

1) istnieje konflikt interesów najpopularniejszych kryptowalut z jakimś podmiotem
2) "drukarz fiat" jest podmiotem jednolitym i jednomyślnym

Oba założenia wymagają zarówno sprecyzowania jak i uzasadnienia.
Dalej jest jeszcze więcej nieuporządkowanych przemyśleń, stąd niewielu forumowiczom chce się z tym polemizować, bo jest tu dużo roboty w postaci obróbki logicznej zawartych tam treści. Sporo takiej obróbki wykonał w tamtym wątku m.in. @fusywszklanejkuli oraz w wątku dotyczącym rzekomej "afery" z RBF, jak również uporządkował logicznie sam rdzeń sporu dotyczącego rozwoju technologicznego i skalowania.

Można zrobić jeszcze jeden krok i przyjrzeć się punktom, których fusy nie kwestionował:

Każde poniższe zdanie ma oparcie w źródłach

-Deweloperzy bitcoin założyli prywatną spółkę blockstream,
-m.in. finansuje ona deweloperów btc.
-firma blockstram jest w portfelu grupy kapitałowej DCG.
-Grupa DCG jest zarządzana przez byłych pracowników FED,Mastercard,JP Morgan itp.

Powtórzę 1024 raz, nie kwestionuję powyższych.

ponieważ tu mamy również do czynienia z wypełnianiem luk w wiedzy domysłami.

1) Nie wykazano, że Blockstream robi cokolwiek co byłoby niezgodne z punktem skupienia Bitcoin Core.
2) BS nie finansuje wszystkich developerów Core.
3) Nie wiadomo jaki % udziałów DCG posiada w BS, w szczególności prawdopodobnie nie jest to pakiet większościowy.
4) Z faktu, że w DCG pracują byli pracownicy instytucji finansowych nie wynika, że powiązanie DCG z tymi instytucjami jest natury formalnej i biznesowej a nie jedynie personalnej. Tak samo jak z faktu, że ja pracowałem kiedyś w firmie X nie wynika, że X ma udziały w kryptowalutach - to moje prywatne zaangażowanie finansowe.

No i wreszcie, należy pamiętać, że "okrojenie" BTC (czy jakkolwiek rozumiana hipoteza odgórnej zmiany własności BTC aby nie było tym czym miało być) to tylko hipoteza, równie dobrze można uznać, że alty / forki są "okrojone" z pewnego stopnia bezpieczeństwa, np. przez:
- mniejszą moc sieci
- POS lub hybrydy zamiast POW
- 0-conf i przerzucanie części odpowiedzialności w procesie zatwierdzania transakcji na point of sale
- nadmierny rozmiar bloku zwiększający rozmiar łańcucha
- użycie w związku z powyższym punktem np. shardingu, który nie dość, że zwiększa o rząd wielkości trudność problemu konsensusu oprogramowania rozproszonego, to prowadzi do zmniejszenia stopnia redundancji danych a tym samym ich bezpieczeństwa.

Empirycznie natomiast można sprawdzić, że Bitcoin nadal robi to czego od niego oczekiwano na samym początku, tj. pozwala na przechowywanie oraz transfer środków p2p bez pośrednictwa zaufanej trzeciej strony. Co więcej, nadal robi to w najbezpieczniejszej istniejącej w świecie kryptowalut sieci, oraz sprawniej niż miało to miejsce jeszcze 2 lata temu, i to bez wprowadzenia ograniczeń bezpieczeństwa żadnym z ww punktów. Natomiast mikropłatności, których możliwość ma niższy dla focal point priorytet niż bezpieczeństwo warstwy głównej, można bez problemu wydelegować do LN, który, wbrew demagogom, również działa, i to sprawnie oraz tanio. Osiągnięto dość udany (choć nie jedyny możliwy, o czym pisał fusy) kompromis pomiędzy bezpieczeństwem a skalowalnością.

Nie ma więc żadnego imho uzasadnionego powodu by uznać, że Bitcoin stał się czymś innym niż miał być a tym bardziej nie ma powodu by uznać, że za kierunkiem jego rozwoju stoją "drukarze fiat" czy jakikolwiek inny scentralizowany podmiot.

[koparki]

1) istnieje konflikt interesów najpopularniejszych kryptowalut z jakimś podmiotem
2) "drukarz fiat" jest podmiotem jednolitym i jednomyślnym

Odpowiem jednocześnie na te dwa punkty:
oczywiście że istnieje konflikt interesów. Facebook "spytał o pozwolenie" na Librę , reakcja była stanowcza i jednomyślna zarówno w USA jak i EU .

nie ma powodu by uznać, że za kierunkiem jego rozwoju stoją "drukarze fiat" czy jakikolwiek inny scentralizowany podmiot.

Uznać "na pewno" nie ma możliwości ("adwokat" taki jak Ty ich spokojnie wybroni) natomiast zawsze będę propagował fakt, że ważni główni deweloperzy są/byli jednocześnie firmą Blockstream a ta jest w portfelu grupy kapitałowej, która w swoim zespole kierowniczym ma osoby wywodzące się z FED/JP Morgan/Mastercard. Ponadto jest jeszcze jeden konflikt "etyczny", grono czołowych deweloperów posiadało firmę prywatną, która aby istnieć musi się wpasować w rozwój bitcoina albo rozwój bitcoina musi się wpasować w pomysł na działalność firmy, która jest w portfelu DCG - no nie? Wg źródeł do których są linki w odpowiednim wątku BS finansuje BTC Core. Tylko naiwność pomaga zamknąć oczy na te dziwne układy.

Nie ma więc żadnego imho uzasadnionego powodu by uznać, że Bitcoin stał się czymś innym niż miał być

swego czasu Japonia dostosowała prawo i uznała go jako pełnoprawną walutę obcą, tym był i na tym mógł się skupić jego rozwój , potrzebna byłaby i waluta niezależna i system płatności a nie tylko system płatności LN.

[ShadowOfHarbringer]

O, 2016 wróciło.

Ponownie dyskutujemy o tym, jak zwolennicy BTC zostali zrobieni w konia?

Bawcie się dobrze. Ja już zostawiłem za sobą ten etap.

[fervi]

Prawda jest taka, ale nie wrzucajcie tego nigdzie.

Za Bitcoinem stoi Blockstream
Za Blockstream bankierzy
Za bankierami stoję ja

I bawimy się w "jedzie pociąg z daleka"

[akos]

@koparki

Powtarzasz wątpliwości i pytania na które padły już odpowiedzi, więc odniosę się w skrócie jedynie do kilku punktów.

1. Libra to nie kryptowaluta a i działania banków są odmienne wobec Libry i BTC oraz w tym drugim przypadku nie zawsze spójne i jednolite. Poza tym komentarz do tytułu wątku nie polemizował z tezą o ew. konfliktach interesów a miał przede wszystkim na celu wskazanie, że już sam ten tytuł zawiera twierdzenia sugerujące odpowiedź na zadane w nim pytanie, więc nie było to "otwarte poszukiwanie". Dalej w wątku jest tylko gorzej pod tym względem oraz pod względem kolejnych poziomów niejasności.

2. Blockstream i udział spółki typu venture capital to nie są żadne "dziwne" czy "nieetyczne" powiązania a rzecz dość powszechna w świecie startupów. Powtarzam raz jeszcze, że nie wiadomo nawet jaki procent udziałów w BS ma DCG. Nie ma też żadnego argumentu, że BS realizuje swoją wizję, którą narzuca reszcie devów a wręcz przeciwnie, są mocne argumenty, że takiego wpływu nie ma co szeroko opisał J. Lopp w przetłumaczonym artykule. Co istotne, metryka decentralizacji developerów wypada lepiej w BTC niż w altach: Quantifying Decentralization. Wspominałem już o tym artykule w wątku Dasha (być może to też ktoś powinien przetłumaczyć, bo to dość ważny tekst dla rozważań o decentralizacji w ogóle).
Taki ogólnikowy, insynuacyjny zarzut zrzeszenia się w spółkę można by postawić każdemu devteamowi, który szuka jakiegoś sposobu na samofinansowanie czyli prawdopodobnie większości teamów w świecie kryptowalut.

3. Narracja "technologia blockchain" zamiast "kryptowaluty" ("blockchain but not bitcoin") nie zawsze musi mieć związek z konfliktem interesów a np. ze specyfiką potrzeb banków i scentralizowanej finansjery. Pisze o tym również J. Lopp w jednym z artykułów pośrednio podlinkowanych w tłumaczonym tekście (Bitcoin’s Security Model: A Deep Dive -> Bitcoin: The Trust Anchor in a Sea of Blockchains)

As the “blockchain but not bitcoin” buzz continues to intensify, we can see that this is because many existing business and financial use cases don’t see a need for trustlessness and permissionlessness. Traditional financial institutions already have semi-trusted permissioned relationships that they have been established over many decades and their goal is to reestablish these relationships with new technology that makes coordination more efficient and robust.

W miarę nasilania się szumu "blockchain, ale nie bitcoin", możemy zauważyć, że dzieje się tak, gdyż wiele z istniejących biznesowych i finansowych przypadków użycia nie widzi potrzeby dla rozwiązań opartych na braku zaufania i pozwoleń. Tradycyjne instytucje finansowe już posiadają częściowo zaufane relacje oparte na pozwoleniach, które były ustanawiane przez wiele dekad zaś ich celem jest zreformowanie tych relacji przy użyciu nowych technologii, które czynią koordynację wydajniejszą i solidniejszą.

[miluu]

Powinni popracować nad mechanizmem pozwoleń komitowania. Tak, żeby nikt nie mógł pushować do mastera, bez zgody odpowiednio szerokiej reprezentacji posiadaczy waluty. No ale to już musiało by być już coś innego niż GitHub do trzymania source'a.

[akos]

@miluu
Nie wydaje mi się to roztropnym pomysłem. Obecnie o tym co ma zostać zmerge'owane decydują względy merytoryczne, przedyskutowane w publicznie dostępnych rewizjach a nie jakaś anonimowa oligarchia portfeli i chyba tak jest bezpieczniej i przejrzyściej a przy okazji technicznie prościej - każdy kto tylko ma chęci i kompetencje może dowolny commit zweryfikować.

[koparki]

Libra to nie kryptowaluta a i działania banków są odmienne wobec Libry i BTC

Oczywiście że to nie to samo ale konflikt interesów identyczny. Ryzyko, że świat będzie wyceniał dobra i usługi w Libra a nie w USD itp.
Nie jest kryptowalutą? Jest to coś w rodzaju Tron, czyli opiera się na walidatorach ale pierwotna wycena tokenu ma mieć pokrycie w realnych aktywach a wszystko ma byc oKYCowane. Tylko te realne aktywa, które są makulaturą rozjadą się może kiedyś jeśli chodzi o wartość tak jak wartość fizycznego złota rozjeżdża się czasem z jego odpowiednikiem papierowym. Raz wpuszczona do sieci Libra nie wyjdzie już z tej sieci, może ulec modyfikacji zwłaszcza gdy stanie za tym murem miliard użytkowników, których hoduje FB(nie jest tajemnicą już inżynieria społeczna jaka wypływa z analizy każdej z osobowości).
Jest jeszcze kwestia potęgi jaką daje wiedza w skali globalnej kto/komu/kiedy/ile/gdzie/za co płaci, nowe technologie blockchain burzą ustalony już od dekad porządek w prawie do kolekcjonowania tych informacji o nas i też jest to argument dla faktycznego konfliktu interesów

Oczywiście że działania w obu wypadkach są inne (Libra / BTC), W wypadku Libra popularyzacja będzie natychmiastowa, inicjator jest jawny i ma wiele do stracenia jeśli sie nie ułoży z establishmentem i się jeszcze nie dokonało natomiast w wypadku Bitcoina dokonało się, inicjatora "nie ma" a popularyzacja była zdobywana oddolnie i stopniowo. Ale konflikt interesów z drukarniami/bankierami/służbami podobny.

Blockstream i udział spółki typu venture capital to nie są żadne "dziwne" czy "nieetyczne" powiązania a rzecz dość powszechna w świecie startupów.

Oczywiście że na tym poziomie który wykroiłeś z całości jest wszytko ok. Ale już sam bitcoin nie jest "stratupem" podobnym do blockstream, no nie? "nieetyczne" ? trudno mi znaleźć na to odpowiednie słowo (moze prywata byłoby lepsze), wyjaśniłem o co chodzi jesli chodzi o prywatę czołowych deweloperów btc więc powtarzać nie będę. Bitcoin ma niewiele już wspólnego ze spadkiem po Satoshim czyli marka i idea oddolnej waluty. To była przez chwilę naprawdę waluta, nawet jeden z silnych krajów tak to określił prawnie.

Narracja "technologia blockchain" zamiast "kryptowaluty" ("blockchain but not bitcoin") nie zawsze musi mieć związek z konfliktem interesów a np. ze specyfiką potrzeb banków i scentralizowanej finansjery.

Przypatrz się Waluta vs krypto-Waluta natomiast "platforma blockchain" ze swoimi kanałami do przesyłania zapłaty to już nie jest konkurent waluty. Widzisz różnicę? Słowa powielane przez wszystkie newsy to wielka sprawa. To słowami dzielimy rzeczywistość, w słowach są zaklęte uwarunkowania i one są łącznikami z memami ideowymi.

[fervi]

Przypatrz się Waluta vs krypto-Waluta natomiast "platforma blockchain" ze swoimi kanałami do przesyłania zapłaty to już nie jest konkurent waluty.

A dlaczego nie? Jak zrobię ci przelew pieniężny w banku to nie wykonuję go walutą?