Adresy bech32 zostaną zastąpione przez bech32m
- Wygadany
- Posty: 593
- Rejestracja: 8 lutego 2020
- Reputacja: 1114
- Lokalizacja: 7-bit secp256k1
Adresy bech32 zostaną zastąpione przez bech32m
Postautor: garlonicon » poniedziałek, 26 lipca 2021, 12:02
Zmiana sprowadza się do tego, że suma kontrolna na końcu adresu będzie inna, niż w przypadku bech32. Pozostała część adresu będzie taka sama. Przykłady:
decodescript 512079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
tb1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vqqzj3dz bech32 (testnet)
tb1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vq47zagq bech32m (testnet)
Zmiana dotyczy jedynie nowych adresów, czyli na przykład taproota, stare adresy powinny działać bez zmian. Niektóre programy mogą jednak błędnie wyświetlać ostatnie sześć znaków w adresie, na przykład mempool.space używa wszędzie adresów bech32, nawet w przypadku taproota. Same zmiany są potrzebne ze względu na to, że jeśli ostatnim znakiem w adresie bech32 jest "p", to wtedy można dodawać lub usuwać znaki "q", nie zmieniając przy tym sumy kontrolnej. Przykłady: https://github.com/sipa/bech32/issues/51
ii2134hk2xmat79tqp
ii2134hk2xmat79tqqp
ii2134hk2xmat79tqqqp
ii2134hk2xmat79tqqqqp
eyg5bsz1l2mrq5ypl40hqqqp
eyg5bsz1l2mrq5ypl40hqqp
eyg5bsz1l2mrq5ypl40hqp
eyg5bsz1l2mrq5ypl40hp
garlonicon
- Bardzo Zły Moderator
- Posty: 14397
- Rejestracja: 16 kwietnia 2012
- Reputacja: 2663
- Lokalizacja: Polska/Wwa/GW
Adresy bech32 zostaną zastąpione przez bech32m
Postautor: rav3n_pl » wtorek, 3 sierpnia 2021, 09:33
Ponieważ z punktu widzenia sieci adresy nie istnieją, a są tylko wyświetlane dla ludzi zmiana ta nie ma żadnego wpływu na samą sieć, tylko na kompatybilność portfeli.
I na bank będą "kalkulatory" zamieniające adresy jednego typu na drugi - bo są one równoważne (czyli to nie będą dwa różne adresy, tylko jeden adres zapisany na dwa sposoby).
Jeżeli więc nasz portfel będąc zgodny z nowym standardem będzie podawał "nowy" adres a jakiś serwis będzie twierdził że adres jest nieprawidłowy - wystarczy go "przeliczyć' na drugi format.
Podobnie było na LTC z adresami Segwit - przejście z 3 na "L" bodaj.
BIP39 Mnemonic z talii kart
Bitcoin Core 0.26.1
Linki do YT, TT, LI i reszty
rav3n_pl
- Weteran
- Posty: 1541
- Rejestracja: 25 kwietnia 2016
- Reputacja: 667
Adresy bech32 zostaną zastąpione przez bech32m
Postautor: ikswodnal » wtorek, 3 sierpnia 2021, 09:40
Czy można wprowadzić rozwiązania z portfeli BCH gdzie portfel wskazywał jaki adres jest odpowiedni?
ikswodnal
- Bardzo Zły Moderator
- Posty: 14397
- Rejestracja: 16 kwietnia 2012
- Reputacja: 2663
- Lokalizacja: Polska/Wwa/GW
Adresy bech32 zostaną zastąpione przez bech32m
Postautor: rav3n_pl » wtorek, 3 sierpnia 2021, 09:46
Nie jest dozwolone używanie zamiennie tych sum kontrolnych.
Ale to i tak jest kwestia softu a nie samej sieci.
Dodano po 1 minucie 59 sekundach:
Ponadto problem dotyczy tylko jednej możliwości: poprawny adres kończy się na "p" i wtedy można dodawać znaki nie zmieniając poprawności sumy kontrolnej.
W sumie w opisie nie znalazłem, czy to jakkolwiek wpływa na generowane transakcje - bo wydaje mi się że nie powinno (do transakcji idzie część bez bc1 i bez sumy kontrolnej, o stałej długości bajtowej).
BIP39 Mnemonic z talii kart
Bitcoin Core 0.26.1
Linki do YT, TT, LI i reszty
rav3n_pl
- Wygadany
- Posty: 593
- Rejestracja: 8 lutego 2020
- Reputacja: 1114
- Lokalizacja: 7-bit secp256k1
Adresy bech32 zostaną zastąpione przez bech32m
Postautor: garlonicon » wtorek, 3 sierpnia 2021, 12:36
Nie wpływa, o ile mówimy o standardowych transakcjach. Natomiast w przypadku niestandardowych, to nie trzeba żadnych kluczy, żeby ruszyć środki z takiego adresu. Innymi słowy: jeśli jakiś adres ma 20 bajtów, ale środki polecą na adres mający 19 lub 21 bajtów, to skrypt będzie niestandardowy i sprowadzi się przykładowo do "OP_0 <jakiś niezerowy hash>". Żeby wydać takie monety, nie trzeba będzie podawać żadnych sygnatur, bo wartość ze szczytu stosu będzie niezerowa, więc sprawdzanie transakcji zawsze będzie zakończone sukcesem.czy to jakkolwiek wpływa na generowane transakcje
Ciekawostka: o ile monety z adresu 1111111111111111111114oLvT2 o zerowym hashu teoretycznie mogą kiedyś zostać wydane, jeśli ktoś zrobi preimage RIPEMD-160, o tyle monety z adresu bc1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq9e75rs nigdy nie mogą zostać wydane, ponieważ Script zawiera zerowy hash na szczycie stosu, więc węzły sprzed aktualizacji Segwit odrzuciłyby taką transakcję, zatem węzły akceptujące Segwit również muszą to odrzucić.
garlonicon
- Bardzo Zły Moderator
- Posty: 14397
- Rejestracja: 16 kwietnia 2012
- Reputacja: 2663
- Lokalizacja: Polska/Wwa/GW
Adresy bech32 zostaną zastąpione przez bech32m
Postautor: rav3n_pl » wtorek, 3 sierpnia 2021, 12:44
Cały czas mówimy o weryfikacji adresu w formie "ludzkiej" - na poziomie protokołu problemu nie ma.
BIP39 Mnemonic z talii kart
Bitcoin Core 0.26.1
Linki do YT, TT, LI i reszty
rav3n_pl
- Wygadany
- Posty: 593
- Rejestracja: 8 lutego 2020
- Reputacja: 1114
- Lokalizacja: 7-bit secp256k1
Adresy bech32 zostaną zastąpione przez bech32m
Postautor: garlonicon » wtorek, 3 sierpnia 2021, 12:50
decodescript 511f00000000000000000000000000000000000000000000000000000000000000No raczej nie, bo nie skrócisz adresu tak, żeby miał za mało bajtów - nie przejdzie weryfikacji długości.
{
"asm": "1 00000000000000000000000000000000000000000000000000000000000000",
"reqSigs": 1,
"type": "witness_unknown",
"addresses": [
"bc1pqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqpfshcs"
],
"p2sh": "3Jc6DcfFYLu6cHvPqRHG9UzX4n6AATweq5"
}
decodescript 51200000000000000000000000000000000000000000000000000000000000000000
{
"asm": "1 0000000000000000000000000000000000000000000000000000000000000000",
"reqSigs": 1,
"type": "witness_v1_taproot",
"addresses": [
"bc1pqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqpqqenm"
],
"p2sh": "3FP6z5oojAcz1QFozRjvTrWHxn8gM6k1DU"
}
decodescript 5121000000000000000000000000000000000000000000000000000000000000000000
{
"asm": "1 000000000000000000000000000000000000000000000000000000000000000000",
"reqSigs": 1,
"type": "witness_unknown",
"addresses": [
"bc1pqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqn80y82"
],
"p2sh": "3BripJwD2EiXPd7unsXHv4atkBHpeipHny"
}
Zresztą, mam lepszy przykład:
getaddressinfo bc1pqqqqqqqqqqqqqqqqtsc8t8
{
"address": "bc1pqqqqqqqqqqqqqqqqtsc8t8",
"scriptPubKey": "510a00000000000000000000",
"ismine": false,
"solvable": false,
"iswatchonly": false,
"iswitness": true,
"witness_version": 1,
"witness_program": "00000000000000000000",
"ischange": false,
"labels": [
]
}
garlonicon
- Bardzo Zły Moderator
- Posty: 14397
- Rejestracja: 16 kwietnia 2012
- Reputacja: 2663
- Lokalizacja: Polska/Wwa/GW
Adresy bech32 zostaną zastąpione przez bech32m
Postautor: rav3n_pl » wtorek, 3 sierpnia 2021, 12:58
2. nie wiem co chcesz pokazać.
Problem pojawiły się w sytuacji, w której źle podany ADRES jest akceptowany i robiona jest z niego transakcja.
Czy adresy
bc1pqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqpfshcs bc1pqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqn80y82można skrócić do
bc1pqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqpfshcs bc1pqqqqqqqqqqqqqqqqqqqqqqqqqqqqn80y82i przejdzie walidację, a do transakcji trafi coś niewłaściwej długości?
Z tego co kojarzę algorytm robi padding zerami, więc jak się kończy zerami i je skrócisz - to je uzupełni i nadal będzie poprawne (bo i tak mają być zera).
BIP39 Mnemonic z talii kart
Bitcoin Core 0.26.1
Linki do YT, TT, LI i reszty
rav3n_pl
- Wygadany
- Posty: 593
- Rejestracja: 8 lutego 2020
- Reputacja: 1114
- Lokalizacja: 7-bit secp256k1
Adresy bech32 zostaną zastąpione przez bech32m
Postautor: garlonicon » wtorek, 3 sierpnia 2021, 16:36
Tylko to, że adresy Segwitowe mogą mieć różną długość i być nadal prawidłowe, co może stanowić pole do ataku.nie wiem co chcesz pokazać
Prawdopodobnie jest to możliwe, jeśli adres P2WSH zajmujący 32 bajty miałby sumę kontrolną dającą "qqqqqp" na końcu, w takiej sytuacji usunięcie znaków "q" z adresu mogłoby go zmniejszyć do 20 bajtów, co dałoby adres P2WPKH. Suma kontrolna zajmuje 32 bity, może uda mi się wygenerować dobry przykład i wykopać jeden z takich adresów.Problem pojawiły się w sytuacji, w której źle podany ADRES jest akceptowany i robiona jest z niego transakcja.
Sam błąd nie jest jakoś szczególnie groźny, wydaje mi się, że aby rzeczywiście kogoś zaatakować, to trzeba byłoby się nieco namęczyć, aczkolwiek warto taką lukę załatać, więc zostanie to naprawione przy przejściu na taproota. Ze względu na zgodność wsteczną, stare adresy nadal będą podatne.
No chyba że ktoś się posługuje niestandardowymi adresami, wtedy sprawa wygląda gorzej, bo łatwo przeoczyć ten jeden znak różnicy. Domyślnie tylko górnicy mogą takie tworzyć i każdy z nich może je wydawać bez żadnych kluczy, ale z drugiej strony w testnecie ta zasada nie obowiązuje, poza tym nie wiem, czy nie ma przypadkiem jakichś altów korzystających z kodowania bech32 w nietypowy sposób.
W przypadku paddingu zerami nie wiem, czy ten padding byłby wykonany z przodu czy z tyłu i czy nie prowadziłoby to do spalenia monet w niektórych portfelach.Z tego co kojarzę algorytm robi padding zerami, więc jak się kończy zerami i je skrócisz - to je uzupełni i nadal będzie poprawne (bo i tak mają być zera).
Edit: W sumie to jestem w stanie wyobrazić sobie gorszy scenariusz, na przykład gdy jakaś strona wymaga unikalności adresów w pewnym miejscu i gdy ktoś mógłby oszukiwać wykopując różne adresy prowadzące do tych samych Scriptów w blockchainie.
Edit: Mam przykład, adres bc1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqr4n23ceqqqqqqqqqqqqqqqqqqqqp może zostać zastąpiony przez bc1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqr4n23cep, oznacza to tyle, że adresy P2WPKH kończące się na "p" można rozszerzać poprzez doklejanie znaków "q" tak długo, aż się uzyska adres P2WSH. Jeśli mamy portfel, który robi padding automatycznie, to starczy dać jeden znak "q" więcej, wtedy zamiast na adres P2WPKH, taki portfel spali monety, wysyłając je na adres P2WSH.
garlonicon
- Bitcoin
- Bezpieczeństwo
- Giełdy i serwisy - zagrożenia
- Anonimowość i bezpieczeństwo w sieci
- Piramidy i scamy
- Bitcoin
- Rozwój projektu
- Twój wkład w rozwój projektu
- Przedszkole
- Pomoc techniczna
- Generowanie monet
- Pomoc
- Ogólnie o miningu
- Mining pools
- Kopacze (miners)
- Sprzęt (hardware) do miningu
- Bitcoin w mediach
- Projekty związane z Bitcoin
- Imprezy, spotkania, konferencje
- Kwestie prawne
- Ciekawostki
- Organizacje charytatywne, zbiórki, dotacje
- Programowanie i wdrożenia
- Ankiety
- Portfele bitcoin
- Dla zaawansowanych - nowi tylko czytają
- Ekonomia
- Rozważania ekonomiczne
- Ankiety ekonomiczne
- Analiza techniczna
- Tutaj zapłacisz bitcoinami
- Polska
- Świat
- Tablica ogłoszeń
- Towary
- Sprzedam
- Kupię
- Zamienię
- Udziały
- Usługi
- Wymiana walut
- Komentarze
- Nagrody
- Wymiana Face-to-Face
- Dolnośląskie
- Kujawsko-pomorskie
- Lubelskie
- Lubuskie
- Łódzkie
- Małopolskie
- Mazowieckie
- Opolskie
- Podkarpackie
- Podlaskie
- Pomorskie
- Śląskie
- Świętokrzyskie
- Warmińsko-mazurskie
- Wielkopolskie
- Zachodniopomorskie
- Cała Polska
- Szukam/dam pracę
- Boty i strategie
- Giełdy, kantory, bitomaty
- Kantory
- Bitomaty
- Inwestycje
- Metale szlachetne
- ICO
- Forki i Alternatywne kryptowaluty
- LiteCoin
- Ekonomia
- Mining
- Ustawienia i konfiguracje
- Linki
- Dogecoin
- Ekonomia
- Mining
- NameCoin
- Ekonomia
- Mining
- Pozostałe
- Scrypt
- SHA256
- Dash
- Ethereum
- ETC
- Lisk
- Bitcoin Cash
- Kopanie kryptowalut
- Kopanie GPU
- Kopanie CPU
- Kopanie ASIC/FPGA
- Kopalnie kryptowalut
- IOTA
- NEO
- Chia
- SCAMY
- Inne
- Linki
- Faucety, kraniki, gry
- Księga skarg i zażaleń
- AMA
- Strona i forum
- Administrator mówi
- Opinie, propozycje, uwagi
- Propozycje banów
Kto jest online
Użytkownicy przeglądający to forum: Obecnie na forum nie ma żadnego zarejestrowanego użytkownika i 4 gości
- Strefa czasowa UTC+02:00
- Na górę
- Zmień szerokość ekranu
- Usuń ciasteczka witryny
O Polskim Forum Bitcoin
Polskie Forum Bitcoin skupia miłośników Bitcoina w Polsce. Tu możesz zadać pytania odnośnie Bitoina lub podyskutować na ciekawe tematy.
Polecamy
Treści na tym forum mają charakter wyłącznie informacyjno-edukacyjny, a posty są wyrazem osobistych poglądów ich autorów. Treśći na forum ani w całości ani w części nie stanowią "rekomendacji" w rozumieniu przepisów Rozporządzenia Ministra Finansów z dnia 19 października 2005 r. w sprawie informacji stanowiących rekomendacje dotyczące instrumentów finansowych, lub ich emitentów (Dz.U. z 2005 r. Nr 206, poz. 1715).