Polskie Forum Bitcoin

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

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

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?

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

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

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.

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": [
]
}

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

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.