Artykuł- How Bitcoin Created a Decentralized Crypto-Currency

[smok]

http://www.readwriteweb.com/hack/2010/1 ... itcoin.php Fajny prosto wyjaśnia jak działa Bitcoin (wywiad)

[Mahkul]

http://www.readwriteweb.com/hack/2010/1 ... itcoin.php Fajny prosto wyjaśnia jak działa Bitcoin (wywiad)

Szybkie tłumaczenie tego artykułu na polski (bądźcie wyrozumiali):

Klint Finley: Czy mógłbyś opisać krótko czym jest Bitcoin dla tych, którzy jeszcze o nim nie słyszeli?

Gavin Andresen: Oczywiście. Bitcoin to pierwsza waluta peer-to-peer; są to pieniądze tworzone przez ludzi a nie bank centralny czy rząd.

Klint Finley: I jak to działa?

Gavin Andersen: Każdy, kto próbuje stowrzyć nowe monety lub je wymienia jest podłączony do sieci peer-to-peer. Mechanizm programu zabezpiecza przed oszukiwaniem - nikt nie jest w stanie stworzyć większej ilości monet niż mu wolno, nikt nie może wydać swoich monet więcej niż raz, monety mogą zostać wydane tylko przez ich prawowitego właściciela.

Najbardziej innowacyjnym pomysłem jest mechanizm zabezpieczający przed wydaniem tych samych pieniędzy więcej niż raz - BEZ POTRZEBY polegania na centralnym ośrodku kontroli. Kolejne dość innowacyjne rozwiązanie to ograniczenie zasobów bitcoins również bez udziału centralnego ośrodka.

Klint Finley: A jak to się odbywa bez udziału centralnego ośrodka? Jak klienci i serwery sieci Bitcoin znajdują się nawzajem?

Gavin Andersen: Pozwól, że najpierw odpowiem na to prostsze pytanie - czyli jak klienci i serwery sieci Bitcoin znajdują się nawzajem:

We wszystkich sieciach p2p istnieje tzw. "problem bootstrapping-u" - polega on na tym, że bez obecności centralnego serwera, węzły (komputery) w sieci mają problem ze znalezieniem się nawzajem. Bitcoin radzi sobie z tym problemem używając trzech mechanizmów:

1. Według domyślnej procedury, każdy klient sieci Bitcoin dołącza do kanału IRC i pobiera sobie adresy IP i porty innych klientów, znajdujących się aktualnie na tym kanale. Nazwa tego kanału (podobnie jak i adres serwera IRC) jest sztywno zaprogramowana w aplikacji Bitcoin.

2. Aplikacja Bitcoin zawiera w sobie także listę "dobrze znanych" węzłów sieci Bitcoin, na wypadek, gdyby z jakiegoś powodu nie dało się połączyć z serwerem IRC.

3. Istnieje też możliwość ręcznego dodania adresów IP (poprzez zmianę ustawień w pliku konfiguracyjnym lub sprecyzowanie takiej opcji z linii poleceń) maszyn, do których chcemy się podłączyć.

Kiedy tylko podłączymy się do sieci Bitcoin, wszystkie pozostałe komputery wyślą nam wiadomości zawierające listę adresów IP (oraz portów) innych komputerów podłączonych do sieci. Tak więc po przeprowadzeniu bootstrappingu łatwo znajdziemy inne węzły Bitcoin poprzez sieć Bitcoin samą w sobie.

Prowadzone są intensywne dyskusje na temat alternatywnych machanizmów bootstrappingu, także nie zdziwiłoby mnie, gdyby za rok czy dwa pojawiły się alternatywne implementacje Bitcoin, oferujące nowe rozwiazania.

Klint Finley: Podejrzewam, że można również ręcznie zmienić adres serwera oraz nazwę kanału IRC?

Gavin Andersen: Nie, nie można. Trzebaby przekompilować klienta Bitcoin, żeby to osiągnąć.

Klint Finley: Dlaczego?

Gavin Andersen: Cała idea boostrapping-u polega na zdefiniowaniu jednego miejsca, z którego można pobrać listę pozostałych węzłów; stawianie własnego serwera IRC nie miało by sensu, do jednego serwera IRC może podłączyć się nieograniczona liczba klinetów - dlatego nie ma powodu żeby używać więcej niż jednego.

Klint Finley: Ale co jeśli ktoś wyłączy istniejący serwer IRC?

Gavin Andersen: Prawdę mówiąc, parę miesięcy temu Bitcoin zmienił adres serwera IRC używanego do bootstrapping-u - nowy klient został wypuszczony, w którym zakodowano już nowy adres serwera. Jeżeli serwer zostałby wyłączony na jakiś czas, aktualne wersje klientów Bitcoin użyłyby list "dobrze znanych" węzłów (zakodowanych w klientach). Stare wersje klienta Bitcoin połączyłyby się wówczas z adresami IP, z którymi łączyły się dotychczas (adresy IP są przechowywane w pliku addr.dat).

Klint Finley: Czy istnieje jakiś mechanizm, który wymuszałby na klientach aktualizację oprogramowania w takiej sytuacji?

Gavin Andersen: Tak... i nie.

Stare wersje programu mogą nadal się łączyć, ciężko pracujemy nad tym, żeby Bitcoin był kompatybliny "w górę". Ale w programie wykryto poważnego bug-a parę miesięcy temu, co popchnęło głównego dewelopera (Satoshi-ego) do zaimplementwania mechanizmu, który informowałby wszystkich korzystających ze starej wersji o tym, że powinni jak najszybciej ją zaktualizować.

Nie pomogło to oczywiście ludziom, którzy używali naprawdę starych wersji. Trzeba zawsze patrzeć do tyłu i do przodu.

Kevin Finley: Zatem co z tą trudniejszą kwestią - zabezpieczeniem przed wydaniem tych samych monet dwa razy oraz ograniczeniem zasobów monet bez udziału centralnego ośrodka kontroli?

Gavin Andersen: Zacznę od ograniczenia zasobów.

Bitcoin jest tak zaprojektowy, że wszystkich monet w obiegu będzie 21 milionów. Na chwilę obecną, monety są tworzone z "prędkością" mniej więcej 50 monet na 10 minut.

Po pierwsze, każda osoba, która próbuje wygenerować nowe monety bierze udział w wyścigu o to, kto pierwszy stworzy tzw. "blok". Blok to po prostu wszystkie transakcje ("Daję/Sprzedaję/Płacę monetami wysyłając je do ciebie"), które miały miejsce od poprzedniego bloku. Żeby wygenerować monety, mój komputer siedzi i nasłuchuje nowych transakcji, dodaje je do bloku a potem przez cały czas wykonuje funkcję hashującą na tych danych. Wykonując funkcję hashującą (co polega na przerabieniu danych o niesprecyzowanej długości na 256-bitowe) moja maszyna próbuje znaleźć hash wystarczająco mały, aby móc rozgłosić w sieci "Wygrałem wyścig o znalezienie kolejnego poprawnego bloku". Kiedy to się dzieje, mój komputer dostaje w nagrodę 50 monet.

W chwili obecnej, każdy nowy blok jest wart 50 monet. Wszystkie węzły w sieci sprawdzają ile bloków zostało stowrzonych przez, mniej więcej, ostatnie dwa tygodnie - i na podstawie tych danych automatycznie (i niezależnie) dostosowują współczynnik trudności w taki sposób, aby w sieci jeden blok znajdywany był mniej więcej co 10 minut. Oto właśnie jak zasoby bitcoins są ograniczane bez udziału żadnego centralnego serwera.

Jedynym sposobem na stworzenie nowego bloku jest rozwiązanie problemu "małego hash-a", który, o ile nam wiadomo, wymaga ogromnej ilości żmudnych obliczeń (polegających na sprawdzeniu wszystkich możliwych wariantów) przeprowadzonych wkoło i wkoło na danych aktualnego bloku i przy bardzo niewielkich zmianach w tym bloku. Każda maszyna w sieci może łatwo sprawdzić, czy naprawdę udało ci się znaleźć ten właściwy hash (wyliczenie jednego hasza jest bardzo proste). Każda maszyna może sprawdzić też, czy wszystkie potwierdzone transakcje zostały zawarte w nowym bloku i czy może przypadkiem nie próbujesz przywłaszczyć sobie tych 50 monet w nowym bloku.

Kevin Finley: Ile transakcji tworzy jeden blok?

Gavin Andersen: Nieokreślona liczba - przynajmniej jedna (pierwsza transakcja w bloku to zawsze transakcja przyznania 50-ciu monet zwycięzcy w wyścigu) aż do niesprecycowanego limitu, który może być łatwo zmieniony w przyszłości. Na stronie Bitcoin Block Explorer można sprawdzić każdy z dotychczasowych 100,000 bloków Bitcoin oraz jakie transakcje miały w nich miejsce.

Kevin Finley: A druga część pytania? Jak zabezpieczyć się przed wydaniem tej samej monety więcej niż raz?

Gavin Andersen: Wszystkie transakcje są rozgłaszane między wszystkimi węzłami w sieci p2p... i to jest pierwsza część rozwiązania tego problemu.

Jeśli transakcja wykorzystująca drugi raz te same monety jest rozgłoszana, wówczas niektóre z węzłów zobaczą najpierw pierwszą transakcję, a inne najpierw drugą.

To, która transakcja "wygra" jest ustalane przez to, której maszynie uda się stworzyć kolejny blok. Wówczas transakcja, która osiągnęła najpierw ten wygrany węzeł w sieci jest zapisywana w nowym bloku. Z chwilą gdy to się dzieje, wszystkie węzły akceptują nowy blok, a transakcja poprzednia (w której monety zostały wydane powtórnie) jest uznawana za nieważną.

Ciekawie robi się, kiedy raz na jakiś czas zdarzy się, że dwóm węzłom uda się wytworzyć blok mniej więcej w tym samym czasie.

Kevin Finley: Czy masz jakiś wgląd w to ile ludzi próbuje oszukiwać?

Gavin Andersen: Dobre pytanie! Chciałbym, żeby ktoś napisał program do nasłuchiwania w sieci w poszukiwaniu takich prób.

Kevin Finley: Czy można wydać te same pieniądze dwa razy niechcący?

Gavin Andersen: Byłoby to bardzo trudne.

Kevin Finley: Jest kilku różnych deweloperów zaangażowanych w rozwój Bitcoin. W jaki sposób projekt jest zarządzany?

Jesteśmy akurat w trakcie "transformacji" z jedno-osobowego projektu (gdzie Satoshi pisze cały kod i aprobuje wszystkie ewentualnie zmiany) w projekt open-source, gdzie cała społeczność Bitcoin ma coś do powiedzenia. Ja podjąłem się bardzo trudnego zadania, mianowicie znalezienia sposobu, aby dało się wspólnie pracować nad projektem bitcoin w bardzo łatwy i szybki sposób. Będziemy próbować robić to w sposób zbliżony do tego, w jaki pisze się patch-e dla Linux-a, gdzie patch-e są wysyłane (używając Github), oceniane, akceptowane i ulepszane.

Kevin Finley: Czy możesz podać jakieś interesujące źródła materiałów dla deweloperów chcących zacząć swoją przygodę z obliczeniami rozproszonymi?

Gavin Andersen: Hm.. dobre pytanie! Tyle w tym temacie jest dopiero w stadium rozwoju, nie wiedziałbym od czego zacząć. Nie jestem specjalistą od sieci p2p, także nie jestem chyba właściwą osobą żeby odpowiadać na to pytanie.

Kevin Finley: Czy uważasz, że obliczenia rozproszone w połączeniu z kryptografią, mogłyby stworzyć alternatywę dla cloud computing, w szczególności dla ludzi, których nie stać na wynajęcie serwerów?

Gavin Andersen: Tak, aczkolwiek umieszczanie aplikacji w "chmurach" jest bardzo niedrogie. Ja używam App Engine (Google) jako front-endu dla moich projektów związanych z Bitcoin, a VPSów i EC2 (Amazon) jako back-endu dla węzłów sieci Bitcoin. Tworzenie aplikacji przy użyciu App Engine to dobry, darmowy sposób na nauczenie się o obliczeniach rozproszonych.

Kevin Finley: Czy uważasz, że kod źródłowy Bitcoin mógłby posłużyć do stworzenia innych projektów peer-to-peer?

Gavin Andersen: Nie - Bitcoin został zaprojektowany, żeby robić jedną rzecz i robić ją dobrze. Inne społeczności peer-to-peer będą miały inne potrzeby.