BIP - anulowanie niepotwierdzonej transakcji

[dawidxx7]

Na bitcointalk nie ma odzewu to tutaj wstawiam.

Witam, chciałbym zaprezentować mój pomysł. Jak wiadomo zatwierdzonych transakcji nie da się cofnąć. Jeśli ktoś się pomyli przy wysyłaniu BTC (błędna kwota lub adres) to nie będzie mógł tego cofnąć. Dlatego wpadłem na pomysł, który jest raczej prosty w realizacji. Wystarczy wprowadzić możliwość anulowania transakcji, gdy ta jest jeszcze w mempoolu. Dlatego jeśli ktoś się pomyli i zauważy błąd będzie mógł swoją transakcję anulować. Będzie miał na to czas dopóki żaden górnik nie wykopie bloku z jego transakcją czyli teoretycznie około 10 minut.

Niestety nie jestem aż tak techniczny aby zaprezentować jakikolwiek kod, więc postaram się wytłumaczyć.
Anulowanie mogłoby odbywać się w taki sposób, że użytkownik wysyła do sieci wiadomość, że chce anulować daną transakcję. Taka wiadomość mogłaby zawierać zapewne txid transakcji, którą chce anulować (i pewnie jakieś swoje id tej wiadomości, stempel czasu itp.). Wiadomość musiałaby być podpisana kluczem albo jednego adresu wejściowego felernej transakcji, albo może wszystkimi wejściowymi (jeśli byłoby ich więcej) by udowodnić, że autor tej wiadomości jest posiadaczem adresu z felernej transakcji. Myślę, że dla bezpieczeństwa należałoby podpisać kluczami wszystkich adresów wejściowych.

Górnicy nic by na tym nie stracili. Mogliby kopać blok z felerną transakcją, a gdy odebrali by wiadomość o anulowaniu, wyrzuciliby tę transakcje z kopanego bloku. Czas wykopania bloku nie zwiększałby się ponieważ jest on wartością losową. Prawdopodobieństwo wykopania bloku nie zmieniłoby się. Z resztą zauważyłem, ze górnicy sami wrzucają transakcje do bloku w czasie kopania (może dlatego, że jakaś nowa doszła z dużym fee i zastępują/wywalają transakcję z mniejszym fee) i przecież średni czas wykopania bloku się przez to nie zwiększa.

Niestety nie wiem jakie miałoby to konsekwencje pod względem zapchania się mempoolu. Bo przecież ktoś mógłby zacząć spamować transakcjami i jednocześnie wiadomościami o anulowaniu ich. Nie wiem czy byłby to bardzo uciążliwe dla górników.

Proszę o pozytywne rozpatrzenie mojego wniosku

[rav3n_pl]

1000% DDoS na sieć.
Za darmo.

[dawidxx7]

A gdyby można było anulować wartość transakcji, ale opłata musiałaby zostać zapłacona? Bo jest replace by fee ale nie wiem czy tam da się zmienić wartość transakcji czy tylko fee.

[rav3n_pl]

No tak, można to zrealizować przez RBF zmieniając adres odbiorcy na swój + większe fee.
Ale żeby RBF zadziałał to pierwotna transakcja musi być oznaczona jako "możliwa do podbicia"

[dawidxx7]

A nie wystarczy zmienić wartości transakcji na 0 tj. zachować adres odbiorcy ale przypisać mu, że wysyła się 0 BTC a w adresie wejściowym dać tylko trochę BTC żeby było jako fee. I oczywiście to fee trochę większe niż we wcześniejszej transakcji.

[rav3n_pl]

Uuuupanie poczytaj o budowie transakcji bo herezje wygłaszasz.

[klek]

Na bitcointalk nie ma odzewu to tutaj wstawiam.

Witam, chciałbym zaprezentować mój pomysł. Jak wiadomo zatwierdzonych transakcji nie da się cofnąć. Jeśli ktoś się pomyli przy wysyłaniu BTC (błędna kwota lub adres) to nie będzie mógł tego cofnąć. Dlatego wpadłem na pomysł, który jest raczej prosty w realizacji. Wystarczy wprowadzić możliwość anulowania transakcji, gdy ta jest jeszcze w mempoolu. Dlatego jeśli ktoś się pomyli i zauważy błąd będzie mógł swoją transakcję anulować. Będzie miał na to czas dopóki żaden górnik nie wykopie bloku z jego transakcją czyli teoretycznie około 10 minut.

Niestety nie jestem aż tak techniczny aby zaprezentować jakikolwiek kod, więc postaram się wytłumaczyć.
Anulowanie mogłoby odbywać się w taki sposób, że użytkownik wysyła do sieci wiadomość, że chce anulować daną transakcję. Taka wiadomość mogłaby zawierać zapewne txid transakcji, którą chce anulować (i pewnie jakieś swoje id tej wiadomości, stempel czasu itp.). Wiadomość musiałaby być podpisana kluczem albo jednego adresu wejściowego felernej transakcji, albo może wszystkimi wejściowymi (jeśli byłoby ich więcej) by udowodnić, że autor tej wiadomości jest posiadaczem adresu z felernej transakcji. Myślę, że dla bezpieczeństwa należałoby podpisać kluczami wszystkich adresów wejściowych.

Górnicy nic by na tym nie stracili. Mogliby kopać blok z felerną transakcją, a gdy odebrali by wiadomość o anulowaniu, wyrzuciliby tę transakcje z kopanego bloku. Czas wykopania bloku nie zwiększałby się ponieważ jest on wartością losową. Prawdopodobieństwo wykopania bloku nie zmieniłoby się. Z resztą zauważyłem, ze górnicy sami wrzucają transakcje do bloku w czasie kopania (może dlatego, że jakaś nowa doszła z dużym fee i zastępują/wywalają transakcję z mniejszym fee) i przecież średni czas wykopania bloku się przez to nie zwiększa.

Niestety nie wiem jakie miałoby to konsekwencje pod względem zapchania się mempoolu. Bo przecież ktoś mógłby zacząć spamować transakcjami i jednocześnie wiadomościami o anulowaniu ich. Nie wiem czy byłby to bardzo uciążliwe dla górników.

Proszę o pozytywne rozpatrzenie mojego wniosku

To, co proponujesz, nie jest niczym innym jak "double spend" i jest jak najbardziej możliwe już teraz. Żeby anulować (niepotwierdzoną) transakcję wystarczy wysłać inną transakcję wydającą bitcoiny z tych samych UTXO. Tylko jedna z tych dwóch transakcji (nie wiadomo która) zostanie uwzględniona w łańcuchu bloków. Druga zostanie uznana za nieprawidłową.

Dopóki transakcja nie znajdzie się w jakimś bloku, nie da się stwierdzić, która jest "pierwsza", a która "druga" - to właśnie bloki połączone w łańcuch pozwalają wszystkim węzłom w sieci na ustalenie kolejności transakcji.

Jedynym problemem dzisiaj jest to, że większość portfeli nie pozwala na "double spend".

[pm7]

Jedynym problemem dzisiaj jest to, że większość portfeli nie pozwala na "double spend".

Nie tylko portfele: wiele węzłów sieci nie rozsyła transakcji sprzecznej z otrzymaną wcześniej (chyba, że poprzednia miała ustawione RBF).