Adresy bech32 zostaną zastąpione przez bech32m

Wygadany
Awatar użytkownika
Posty: 593
Rejestracja: 8 lutego 2020
Reputacja: 1114
Reputacja postu: 
9
Napiwki za post: 0 BTC
Lokalizacja: 7-bit secp256k1

Adresy bech32 zostaną zastąpione przez bech32m

Postautor: garlonicon » poniedziałek, 26 lipca 2021, 12:02

W przypadku taproota adresy bech32 zostaną zastąpione adresami bech32m. Definiuje to BIP-350: https://github.com/bitcoin/bips/blob/ma ... .mediawiki

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

Bardzo Zły Moderator
Awatar użytkownika
Posty: 14347
Rejestracja: 16 kwietnia 2012
Reputacja: 2639
Reputacja postu: 
0
Napiwki za post: 0 BTC
Lokalizacja: Polska/Wwa/GW

Adresy bech32 zostaną zastąpione przez bech32m

Postautor: rav3n_pl » wtorek, 3 sierpnia 2021, 09:33

@garlonicon Niezłe :)

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.
Piffko: PLC/BTC 1Rav3nkMayCijuhzcYemMiPYsvcaiwHni
BIP39 Mnemonic z talii kart
Bitcoin Core 0.25
Linki do YT, TT, LI i reszty

Weteran
Posty: 1538
Rejestracja: 25 kwietnia 2016
Reputacja: 667
Reputacja postu: 
0
Napiwki za post: 0 BTC

Adresy bech32 zostaną zastąpione przez bech32m

Postautor: ikswodnal » wtorek, 3 sierpnia 2021, 09:40

rav3n_pl pisze: wtorek, 3 sierpnia 2021, 09:33Jeż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.
Czy można wprowadzić rozwiązania z portfeli BCH gdzie portfel wskazywał jaki adres jest odpowiedni?

Bardzo Zły Moderator
Awatar użytkownika
Posty: 14347
Rejestracja: 16 kwietnia 2012
Reputacja: 2639
Reputacja postu: 
0
Napiwki za post: 0 BTC
Lokalizacja: Polska/Wwa/GW

Adresy bech32 zostaną zastąpione przez bech32m

Postautor: rav3n_pl » wtorek, 3 sierpnia 2021, 09:46

Po wczytaniu się w BIPa: obecne adresy dla segwit v0 pozostaną bez zmian, adresy segwit v1 będą miały nowe checksumowanie.
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).
Piffko: PLC/BTC 1Rav3nkMayCijuhzcYemMiPYsvcaiwHni
BIP39 Mnemonic z talii kart
Bitcoin Core 0.25
Linki do YT, TT, LI i reszty

Wygadany
Awatar użytkownika
Posty: 593
Rejestracja: 8 lutego 2020
Reputacja: 1114
Reputacja postu: 
0
Napiwki za post: 0 BTC
Lokalizacja: 7-bit secp256k1

Adresy bech32 zostaną zastąpione przez bech32m

Postautor: garlonicon » wtorek, 3 sierpnia 2021, 12:36

czy to jakkolwiek wpływa na generowane transakcje
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.

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ć.
Ostatnio zmieniony wtorek, 3 sierpnia 2021, 12:46 przez garlonicon, łącznie zmieniany 1 raz.

Bardzo Zły Moderator
Awatar użytkownika
Posty: 14347
Rejestracja: 16 kwietnia 2012
Reputacja: 2639
Reputacja postu: 
0
Napiwki za post: 0 BTC
Lokalizacja: Polska/Wwa/GW

Adresy bech32 zostaną zastąpione przez bech32m

Postautor: rav3n_pl » wtorek, 3 sierpnia 2021, 12:44

No raczej nie, bo nie skrócisz adresu tak, żeby miał za mało bajtów - nie przejdzie weryfikacji długości.
Cały czas mówimy o weryfikacji adresu w formie "ludzkiej" - na poziomie protokołu problemu nie ma.
Piffko: PLC/BTC 1Rav3nkMayCijuhzcYemMiPYsvcaiwHni
BIP39 Mnemonic z talii kart
Bitcoin Core 0.25
Linki do YT, TT, LI i reszty

Wygadany
Awatar użytkownika
Posty: 593
Rejestracja: 8 lutego 2020
Reputacja: 1114
Reputacja postu: 
0
Napiwki za post: 0 BTC
Lokalizacja: 7-bit secp256k1

Adresy bech32 zostaną zastąpione przez bech32m

Postautor: garlonicon » wtorek, 3 sierpnia 2021, 12:50

No raczej nie, bo nie skrócisz adresu tak, żeby miał za mało bajtów - nie przejdzie weryfikacji długości.
decodescript 511f00000000000000000000000000000000000000000000000000000000000000
{
"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": [
]
}

Bardzo Zły Moderator
Awatar użytkownika
Posty: 14347
Rejestracja: 16 kwietnia 2012
Reputacja: 2639
Reputacja postu: 
0
Napiwki za post: 0 BTC
Lokalizacja: Polska/Wwa/GW

Adresy bech32 zostaną zastąpione przez bech32m

Postautor: rav3n_pl » wtorek, 3 sierpnia 2021, 12:58

@garlonicon 1. używaj "code" albo "pre"
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
bc1pqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqn80y82
można skrócić do
bc1pqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqpfshcs
bc1pqqqqqqqqqqqqqqqqqqqqqqqqqqqqn80y82
i 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).
Piffko: PLC/BTC 1Rav3nkMayCijuhzcYemMiPYsvcaiwHni
BIP39 Mnemonic z talii kart
Bitcoin Core 0.25
Linki do YT, TT, LI i reszty

Wygadany
Awatar użytkownika
Posty: 593
Rejestracja: 8 lutego 2020
Reputacja: 1114
Reputacja postu: 
0
Napiwki za post: 0 BTC
Lokalizacja: 7-bit secp256k1

Adresy bech32 zostaną zastąpione przez bech32m

Postautor: garlonicon » wtorek, 3 sierpnia 2021, 16:36

nie wiem co chcesz pokazać
Tylko to, że adresy Segwitowe mogą mieć różną długość i być nadal prawidłowe, co może stanowić pole do ataku.
Problem pojawiły się w sytuacji, w której źle podany ADRES jest akceptowany i robiona jest z niego transakcja.
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.

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.
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).
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.

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.

Wróć do „Bitcoin”

Kto jest online

Użytkownicy przeglądający to forum: Obecnie na forum nie ma żadnego zarejestrowanego użytkownika i 13 gości