Brak "Replay Protection" i zagrożenia z tym związane.

[InformatkSzymonPatyk]

Dziekuje panowie a wiec podsumuje:

1. nie używać do momentu powstania "rozdzielaczy"
Pierwsze "rozdzielacze" będą mogły funkcjonować po 100 blokach od forka, co przy podziale mocy 80/20 po stronie btc1 potrwa mniej niż dzień, a po stronie "btc 1mb" ponad 3 dni. I to jeżeli kopalnie takie serwisy zrobią (bo one pierwsze będą miały "świeże" monety).

2. nie używać do momentu śmierci jednego z forków
3. kopać i zmieszać samemu

4. upewnić się, że odbierający "zaliczy" obie waluty.

Jeżeli odbierający (ten, do kogo wysyłasz przelew) nie pisze, że można wysłać dwa różne forki BTC na ten sam adres, załóż, że nie można.

Tak sobie pomyslalem jak by tu was wykorzystac i wpadlem na swietny pomysl
Jak ten caly chaos sie juz zakonczy to pan Raven or pan Pm7 lub inny madry pan mogli by np potwierdzic ze wszystko wrocilo na wlasciwe tory ... a ja wtedy w ramach podziekowania odwdzieczyl bym sie za dobra robota na piwo...obaj panowie na swieta dostana pod choinke maly prezent ode mnie ... oczywiscie po potwierdzeniu

[rav3n_pl]

Jeżeli odbierający (ten, do kogo wysyłasz przelew) nie pisze, że można wysłać dwa różne forki BTC na ten sam adres, załóż, że nie można.

Trochę myląco napisałeś.
Wysyłając monety po forku Twoja transakcja będzie poprawna w obu - czyli wysyłasz na raz OBIE monety (btc i btc2x). Odbierający powinien zaliczyć Ci obie - bo obydwie dostanie.

[pm7]

Odbierający powinien zaliczyć Ci obie - bo obydwie dostanie.

Niestety, widać, że to co powinni, a to co robią się rozjechało (przykłady z Bitcoin Cash). Dlatego napisałem:

Jeżeli odbierający (ten, do kogo wysyłasz przelew) nie pisze, że można wysłać dwa różne forki BTC na ten sam adres, załóż, że nie można.

[Dopełniacz]

Will TREZOR Wallet support Bitcoin Gold if it implements replay protection?
We will make all of our efforts to develop support for Bitcoin Gold, but we will not do so if it will risk your coins. Therefore, we need to see replay protection as a part of the Bitcoin Gold codebase first. Since the work on the code started so late, we will probably not be ready for the launch day of Bitcoin Gold.
We have been putting pressure on the team and voiced our requirements openly on Twitter and on GitHub, so we hope that replay protection will become a reality.

https://blog.trezor.io/trezor-statement ... cebc0532c7

I to jest prawidłowa postawa, zupełnie odwrotna do S2X...

[pepperoniss]

Note: This replay protection scheme has since been reverted! Please make sure you DO NOT use the protection scheme from this article for anything as you WILL NOT be protected before or after the 2x hard fork.

Czyli tego NIE MA.
Pomysł prosty, ale nie koniecznie dobry.
Pierwsze "rozdzielacze" będą mogły funkcjonować po 100 blokach od forka, co przy podziale mocy 80/20 po stronie btc1 potrwa mniej niż dzień, a po stronie "btc 1mb" ponad 3 dni. I to jeżeli kopalnie takie serwisy zrobią (bo one pierwsze będą miały "świeże" monety).

A mógłbyś wyjaśnić skąd bierze się te 100 bloków po forku i dlaczego do "mieszania" miałyby być użyte "świeże" wydobyte po forku monety?
Może się mylę ale wydaje mi się, że wystarczającym zabezpieczeniem jest "zmieszanie" w jednej transakcji posiadanych monet przedforkowych z jakąkolwiek monetą otrzymaną po forku. O ile może być to trudne do wdrożenia w mieszarkach o tyle we własnym zakresie nie powinno być problemu.

[rav3n_pl]

Wykopane monety nie mogą być wydane wcześnie niż 100 bloków od ich wydobycia.
Jedna z podstaw btc.

[pepperoniss]

Wykopane monety nie mogą być wydane wcześnie niż 100 bloków od ich wydobycia.
Jedna z podstaw btc.

OK. Więc co do "mieszania" przez kopalnie sprawa jest jasna ale co ze "rozdzieleniem" na własną rękę w sposób przeze mnie opisany?

[rav3n_pl]

W jednej transakcji trzeba wydać "stare" monety (które chcemy rozdzielić) i nowe, wkopane w danym forku.
W ten sposób wysyłamy tylko jedną z walut, druga zostaje (bo transakcja nie jest prawidłowa w drugim forku - brak monet ujętych w transakcji.
Pisałem to już kilka razy...

[TypowyFacet]

@rav3n_pl, czyli teraz nie da się rozdzielić tych monet i btc które wypłacamy od giełd są razem z btg?

[rav3n_pl]

Oczywiście.
Chyba, że giełdy wypłacają zmieszane z "nowymi btc", wykopanymi po forku.
Giełdy które deklarują późniejszą obsługę/wypłatę scamgolda a pozwalają na wypłatę btc BEZ mieszania - zrobią sobie kuku proporcjonalne do ilości wypłaconych btc i kursu scamgolda w momencie uruchomienia rynku/wypłat.
Mam nadzieję, że mają kogoś kto tego pilnuje. Bo może nas czekać nagły pad kilku giełd w krótkim czasie.

[TypowyFacet]

Wydaje mi się, że będzie z tego niezły gnój, w sumie nie ma nawet żadnego dowodu, że zrobili ten fork.

[pepperoniss]

To rozumiem. I to akurat jest jasne.
Natomiast wydaje mi się, że jeśli po forku przesyłając z jednego swojego adresu na drugi swój adres prześlę transakcję wyłącznie w gałęzi bitcoin core i w kolejnej transakcji wszystkie środki z tego adresu prześlę na kolejny adres to ta druga transakcja nie będzie prawidłowa w gałęzi segwit2x.

Wydaje mi się, że mniej więcej na tym oparta jest też koncepcja opisana w tym poście https://forum.bitcoin.pl/viewtopic.php? ... 66#p377517 - pomijając jej jawnie naciągacki charakter.

IMHO, problem stanowią wyłącznie transakcje na adresy, w których nie kontroluje się kluczy prywatnych.

Oczywiście.
Chyba, że giełdy wypłacają zmieszane z "nowymi btc", wykopanymi po forku.

No właśnie tego nie rozumiem dlaczego muszą być zmieszane wyłącznie z "nowymi btc" wydobytymi po forku. Przecież po zmieszaniu, o którym piszę w drugiej gałęzi wejścia nie będą istnieć a więc i transakcja nie będzie w niej prawidłowa i powinna zostać odrzucona.

Nie twierdzę, że nie jest tak jak piszesz ale nie chcę też tego przyjmować za aksjomat a na logikę wychodzi mi, że wystarczającym jest "zmieszanie" z monetą pochodzącego z wejścia otrzymanego po forku.

Dodano po 25 minutach 50 sekundach:

Wydaje mi się, że będzie z tego niezły gnój, w sumie nie ma nawet żadnego dowodu, że zrobili ten fork.

Bo nie zrobili a dopiero mają zrobić ale ja bardziej mam na myśli fork, będący przedmiotem wątku choć zdaje mi się, że opisany przeze mnie sposób powinien być uniwersalnym. Oczywiście o ile mój tok rozumowania jest prawidłowy.

[rav3n_pl]

Nie, "wejścia otrzymanego po forku" nie starczy, bo ta transakcja jest prawidłowa w obu gałęziach i nie ma gwarancji że nie ma jakiegoś węzła który łączy się do obu forków.
Muszą być wmieszane nowe monety po forku - wtedy transakcja nie będzie prawidłowa w drugim forku. I wszystkie monety które później będą mieszane z konarami z tej transakcji również będą bezpieczne.

[Dopełniacz]

Co jak co, ale trzeba przyznać że BCH nie zrobiło takiego bałaganu jaki zrobią te nowe "forki"...
Niby waluta "żart" ale przyznaję że jakiś szacunek twórcą się za to należy.

[pepperoniss]

BCH było z góry nastawione na kopanie nawet w gałęzi mniejszościowej, podobnie jak BTG. Stąd też z założenia powinno mieć wbudowane Replay Protecion.
S2X nie chce wprowadzić zabezpieczenia, gdyż zakłada (IMHO niesłusznie), że druga, mniejszościowa gałąź powinna przestać być kopana a S2X stanie się jedynym Bitcoinem poza tymi altcoinami BTG i BTH.
Ja tę filozofię rozumiem aczkolwiek jej nie popieram. Stąd też szukam formuły zabezpieczenia się przed Replay Attack na własną rękę. I uważam, że można się skutecznie zabezpieczyć zanieczyszczając transakcję każdą monetą otrzymaną po forku w jednej z gałęzi. Nie będę jednak dalej ciągnął dyskusji w tym temacie i zapewniam, że dużym respektem darzę @rav3n_pl.

[rav3n_pl]

I uważam, że można się skutecznie zabezpieczyć zanieczyszczając transakcję każdą monetą otrzymaną po forku w jednej z gałęzi.

Jeżeli "każda moneta" oznacza monetę wykopanym w danym forku - to zadziała.
Inaczej NIE.

[InformatkSzymonPatyk]

A teraz prosto: po forku okolo 20.11 czekamy 100 blokow [(lepiej tydzien albo dwa ] kupujemy jakiegos bitka=najlepiej wykopac i miec pewnosc ze to moneta po danym forku, robimy przelew na swoj portfel mieszjac i tyle ,moze byc ??

Ale malo osob kopie prawda wiec skad bede mial pewnosc ze owa monete kupilem po forkowa

I uważam, że można się skutecznie zabezpieczyć zanieczyszczając transakcję każdą monetą otrzymaną po forku w jednej z gałęzi.

Jeżeli "każda moneta" oznacza monetę wykopanym w danym forku - to zadziała.
Inaczej NIE.

[rav3n_pl]

Można śledzić skąd są monety w exploratorze. Wykopać "gold" samemu pewniej.
Mając takie "goldne" monety najprościej:
- przesłać je do portfela który chcemy "oddzielić"
- wysłać razem z monetami z tego portfela na SWÓJ kolejny adres
- sprawdzić, czy w BTC monety nadal są na miejscu.

JEDNAKŻE BEZPIECZNIEJ zrobić odwrotnie - mając "poforkowe" BTC NAJPIERW wysłać BTC, aby "goldy" zostały w starym miejscu.
I dopiero wysyłać goldy.
Lepiej nie przekazywać "niepewnemu" portfelowi kluczy prywatnych od BTC...

[domator]

@rav3n_pl, ale goldy sprzed paru dni MAJA replay protection. Przynajmniej pisza ze maja.
Problem bedzie - jak przypuszczam - w listopadzie. Szczegolnie ze nie wiadomo chyba kto ma wygrac. Wogole jakos nie widze zeby spolecznosc panikowala z tego powodu a dla mnie to jest gruby temat...

[TypowyFacet]

Ja obstawiam, że w listopadzie nie będzie w ogóle tego forka. Dlatego wszyscy tacy spokojni.