Zagadki związane z BTC

[The Real McCoin]

./bitcoin-cli

A może by tak rozwiązać zagadkę bez opuszczania przeglądarki?
Tak żeby użytkownicy nie posiadający pełnego klienta, czy innych narzędzi (coś czuję, że zaraz zaczniesz pisać jakiś program w .Net ), mogli sobie sami zreprodukować wszystkie kroki, łącznie z ostatecznym zweryfikowaniem ułożonego scriptSig.

Dodano po 15 minutach 42 sekundach:
Natomiast jeżeli ktoś jest tak dobry, że taką zagadkę rozwiązuje w 5 minut, ale nie chciałby jeszcze jej palić dla innych, to może na razie podać tylko hasz rozwiązania, dowodząc, że już na dany moment je znał, a to co generuje podany hasz zweryfikujemy później.

[pm7]

A może by tak rozwiązać zagadkę bez opuszczania przeglądarki?

Prawie wszystkie narzędzia da się znaleźć w wersji online, więc nie bardzo widzę powód, żeby się ograniczać. Jak ktoś chce odtworzyć kroki, może albo poszukać zamienników, albo spróbować sam znaleźć inną drogę do rozwiązania.
Np. skrypt można zdekodować tutaj: https://chainquery.com/bitcoin-api/decodescript
Ja spróbowałem Pythonem złamać pierwszy hash, ale niestety nic nie znalazłem
Można użyć jakiegoś Python online, ale po co jak ma się środowisko na komputerze?

Kod: Zaznacz cały

import hashlib

def hash256(x):
    x=str(x)
    x=hashlib.sha256(x).hexdigest()
    return hashlib.sha256(x).hexdigest()

wynik="f892622601e484bc3ed1ed952007843dc84a0af359007cb37e962376b0b70f87"
rang=25000

for i in range(rang):
    i-=rang/2
    i+=0x1935736832
    if hash256(i)==wynik:
        print i-0x1935736832
    i-=0x1935736832
    i+=1935736832
    if hash256(i)==wynik:
        print i-1935736832

Drugi hash przynajmniej znalazłem, choć to raczej żadne osiągnięcie

Kod: Zaznacz cały

import hashlib
import binascii

x="04edaa381322ca65ad5f6e333d488b92c42af363f00125241571fe70715b832763f4050c4f664e7a3b3aa702182470e03590c52a4153a0f30657ef0937e4e323e0"
x=binascii.unhexlify(x)
x=hashlib.sha256(x).hexdigest()
x=binascii.unhexlify(x)
h = hashlib.new('ripemd160')
h.update(x)
print h.hexdigest()

Pewnie pierwszy kod trzeba poprawić, by używał unhexlify i zdekodować 0x1935736832 z little endian (o ile nie zostało to wykonane podczas dekodowania skryptu), ale mi się na razie nie chce.

[The Real McCoin]

Kod: Zaznacz cały

rang=25000

Skąd ta dziwna liczba?

Kod: Zaznacz cały

i+=0x1935736832

Kod: Zaznacz cały

i+=1935736832

Dlaczego raz robisz tak, a później inaczej?

[pm7]

Skąd ta dziwna liczba?

Na początku 25, żeby po podzieleniu na dwa zakresy (ujemne i dodatnie), było pełne -10 do +10 z zapasem. Liczba zer się wzięła z tego ile mój laptop jest w stanie sprawdzić natychmiast, żebym mógł szybko sprawdzać kolejne wersje programu. Niby mógłbym ograniczyć się na podstawie OP_SIZE, ale tak mi było prościej.

Dlaczego raz robisz tak, a później inaczej?

Wydaje mi się, że ta liczba jest szesnastkowa, z drugiej strony ponoć niektóre OP z Bitcoin mają ograniczenie przyjmowanego rozmiaru liczb (ciekawe, czy zmienna się przekręca w Bitcoin i dlatego nie znalazłem odpowiedniego wejścia do funkcji skrótu) i nie chciało mi się sprawdzać jak mocno jest dekodowany skrypt (do liczby dziesiętnej? szesnastkowej? szesnastkowej Little endian?), kiedy przeszukanie możliwości było prostsze.

Coś mi się zdaje, ze spytamy się o rozwiązanie zamiast samemu znaleźć

[The Real McCoin]

Wydaje mi się, że ta liczba jest szesnastkowa

Już na pierwszy rzut oka widać, że client podczas deasemblacji zinterpretował pushowany ciąg bajtów jako liczbę, bo na początku scriptPubkey nigdzie nie ma ciągu "1935736832" a jest push czterech bajtów:

Kod: Zaznacz cały

0400006173

Po zamianie 1935736832 w kalkulatorze na hex od razu widać, że interpreter używa Little Endian.

ponoć niektóre OP z Bitcoin mają ograniczenie przyjmowanego rozmiaru liczb (ciekawe, czy zmienna się przekręca w Bitcoin

Z wiki:

When used as numbers, byte vectors are interpreted as little-endian variable-length integers with the most significant bit determining the sign of the integer

Note: Arithmetic inputs are limited to signed 32-bit integers, but may overflow their output.

i dlatego nie znalazłem odpowiedniego wejścia do funkcji skrótu

A może zapomniałeś o zerze ujemnym

[adam1226]

Hmm a czy są jakieś kursy jak się nauczyć tego co robicie od podstaw?:)

[pm7]

Już na pierwszy rzut oka widać, że client podczas deasemblacji zinterpretował pushowany ciąg bajtów jako liczbę, bo na początku scriptPubkey nigdzie nie ma ciągu "1935736832" a jest push czterech bajtów:

W ogóle nie patrzyłem na zakodowany skrypt. Ciekawe, że tak inteligentnie zadziałał (skrót zostawił szesnastkowo).

Z wiki:

Wiem, czytałem oczywiście. 1935736832 się mieści w 32 bitowej liczbie, jakby to był zapis szesnastkowy, to już nie bardzo.

A może zapomniałeś o zerze ujemnym

Zero ujemne plus liczba dodatnia da liczbę dodatnią, a ona miała inne wyjście funkcji skrótu, więc raczej nie.

Hmm a czy są jakieś kursy jak się nauczyć tego co robicie od podstaw?:)

Są kursy, ale nie wiem, czy znajdziesz taki obejmują dokładnie to, co chcesz.
Ponoć niezła książka o programowaniu to "Zrozumieć programowanie" - Gynvael Coldwind.
W tym wypadku użyłem Google'a, głównie wpisów na wiki Bitcoin i podstawowej znajomości Pythona.
Do podstawowej nauki Pythona się często poleca https://www.codecademy.com/learn/python.

@The Real McCoin, może podpowiedz coś?

[The Real McCoin]

może podpowiedz coś?

Jest prosta robota do wykonania więc trzeba wyłączyć mózg i myślenie.
Przestrzeń rozwiązań, którą trzeba przeszukać, jest jasno zdefiniowana.
Bitcoin przy operacjach matematycznych wrzuca na stos i zabiera z niego liczby w Little Endian, więc w języku, którym się użyje, trzeba dopilnować, żeby na wejście sha256 dane wchodziły w odpowiedniej kolejności i formacie.
Skrypt PHP zajmuje 3 linijki.
Zdecydowanie nie używaj już liczby 25000

Dodano po 5 minutach 28 sekundach:
Gdybyś miał rozwiązanie, to na tych stronach się je sprawdzi:

http://bitcoin-script-debugger.visvirial.com musi pokazać: Result: OK
http://n.bitcoin.ninja/checkscript musi pokazać: Valid

[pm7]

Bitcoin przy operacjach matematycznych wrzuca na stos i zabiera z niego liczby w Little Endian, więc w języku, którym się użyje, trzeba dopilnować, żeby na wejście sha256 dane wchodziły w odpowiedniej kolejności i formacie.

Nie mów, naprawdę hash jest wykonywany z liczby zakodowanej w Little Endian?

[The Real McCoin]

Nie mów, naprawdę hash jest wykonywany z liczby zakodowanej w Little Endian?

Pytasz serio?
Weźmy liczbę dziesiętną: 1144201745 (od lewej najstarsze cyfry).
Ta sama liczba w postaci heksadecymalnej: 0x44332211 (od lewej najstarsze cyfry).
Żeby z niej obliczyć SHA256, trzeba wrzucić na stos ciąg bajtów w odwróconej kolejności: 11223344.
Hasz tego ciągu to: 1a835ed8734f86355ca5b835d824d486993aabf1913cd3a011b7446c0514b7c9.

[rav3n_pl]

Tak https://en.bitcoin.it/wiki/Script

The stacks hold byte vectors. When used as numbers, byte vectors are interpreted as little-endian variable-length integers with the most significant bit determining the sign of the integer. Thus 0x81 represents -1. 0x80 is another representation of zero (so called negative 0). Positive 0 is represented by a null-length vector. Byte vectors are interpreted as Booleans where False is represented by any representation of zero, and True is represented by any representation of non-zero.

[wargo]

To rav3n!

[The Real McCoin]

Prosta transakcja z jednym wejściem i jednym wyjściem to 250 bajtów, z czego 150 to opis wejścia, a wyjście i inne rzeczy to 100 bajtów.
Do zweryfikowania tej transakcji węzeł musi sprawdzić podpis cyfrowy wejścia. W tym celu musi przehaszować łącznie 250 bajtów.
Teraz zwiększamy maksymalny rozmiar bloku (przestrzeni na transakcje) do 4 MB, czyli 4 000 000 bajtów. Taki też ustawiamy maksymalny dopuszczalny rozmiar pojedynczej transakcji (innych ograniczeń nie ma).
Pytanie: do przehaszowania jakiej maksymalnej ilości danych można zmusić węzeł w celu weryfikacji transakcji zawartych w bloku, wg przyjętych powyższych założeń?
ok. 4 MB?
ok. 8 MB?
ok. 1 GB?
ok. 100 GB?
ok. 1 TB?
ok. 100 TB?
Jak to zrobić?

[rav3n_pl]

"Zwykłą" transakcją możemy obciążyć przez zrobienie jednej transakcji zawierającej maksimum wejść i jedno wyjście.
Daje to transakcję o (4`000`000-100)/150=26`666 wejść i zmusza do haszowania 26`666*250=6`666`500 bajtów.

[The Real McCoin]

[rav3n_pl]

Znaczy że co? Źle policzyłem?

[pm7]

Zdaje się, że przy transakcjach używających wielu wejść, podpisy cyfrowe są z całej transakcji, więc trzeba sprawdzić koło 4MB*26666=100MB. Może mniej jeżeli część danych się pomija, może więcej (np. niestandardowe transakcje może mogą wymusić przetworzenie olbrzymich ilości danych).

[The Real McCoin]

Było 6 MB, teraz jest 100 MB.
Po minie Picarda widzę, że trzeba czekać dalej.

[rav3n_pl]

Głowy nie dam, ale w którymś changelogu było coś w stylu "hasz transakcji musi być wykonany tylko raz". Aż poszukam jak będę przy kompie.

[pm7]

Rzeczywiście pytanie było o hash, nie o sprawdzanie podpisu. W takim przypadku jednak, jak wyszło Ci że jednorazowe wyliczenie hasha z całej 4MB transakcji wymaga wyliczenia hasha z 6MB danych?