Bitcoin Classic

[asocjal]

Nie chodzi o to, że zwiększanie opłat byłoby remedium. Mówię o sytuacji w której jest zgoda na zwiększenie rozmiaru bloku, ale chodzi mi o sposób jego zwiększenia. Nie podoba mi się w ogóle idea hardcodowego limitu (tzn. limitu bloku umieszczonego w kodzie źródłowym). Takich rzeczy powinno się w programowaniu uniknąć. Jak rozumiem taki limit jest po to, żeby jakaś kopalnia nie wrzuciła sobie przy okazji tworzenia bloku miliona darmowych transakcji z jakiś sobie tylko znanych powodów. Przy rozwiązaniu z tą tzw "karą" taka zagrywka sporo by ich kosztowała.

Poza tym jest jeszcze jedna spora zaleta. W tej chwili - jeśli akurat powstanie taki mini-fork i 2 kopalnie wykopią niezależnie od siebie różne bloki, to kolejny blok opłaca się kopać jako kontynuacja bloku który był... mniejszy. Dlatego, że wówczas więcej transakcji może trafić do nowego bloku (bo nie znalazły się w poprzednim). W moim pomyśle jest większa zachęta by budować blok na bazie bloku większego. Kopalnia co prawda zarobi mniej z fee, ale chociaż odzyska "karę" z bloku poprzedniego (tego dużego) płacąc jednocześnie mniejszą karę za swój nowy blok (mniejszy).

[rav3n_pl]

Hardlimit jest pomyślany właśnie po to, żeby nie marnować miejsca u każdego, kto przechowuje cały łańcuch.
Transakcje "śmieciowe" są dość skutecznie odsiewane, nie są propagowane i nie są dołączane do bloku.
Idealnym rozwiązaniem byłoby adaptacyjne regulowanie wielkości (jest na to już kilka pomysłów, najczytelniejszym chyba była mediana wielkości ostatnich bloków*2
Jeżeli kopalnia produkuje bloki zgodne z konsensusem to absolutnie nie można jej w żaden sposób karać.

[AdamM]

Zgodnie z propozycją asocjal kopalnia nie jest karana, chyba że sama się ukarze. Kopalnia po prostu powiększy blok wtedy gdy opłaty za dodatkowe transakcje przewyższą "karę".

[grzem]

Pomysł niezły, ale lepszy byłby gdyby pomniejszać nagrodę za transakcje poniżej pewnego priority, wówczas mogłyby powrócić transakcje z zerowym fee, czyli coś czym bardzo chętnie podpierano się reklamując bitcoin.

[rav3n_pl]

Naprawdę uważasz, że kopalnie dołączałyby transakcje które NIE mają opłaty i dodatkowo ZMNIEJSZAJĄ nagrodę???

[asocjal]

Idealnym rozwiązaniem byłoby adaptacyjne regulowanie wielkości (jest na to już kilka pomysłów, najczytelniejszym chyba była mediana wielkości ostatnich bloków*2

To jest własnie fatalny pomysł. Takie rozwiązanie jest kompletnie nie odporne na nagłe skoki ilości transakcji, które mogłyby mieć miejsce. To oznacza, że jak nagle Satoshi Nakamoto się ujawni i powie, że w ramach promocji bitcoina rozda swoje zaskórniaki po 0.10 BTC na każdego kto się zgłosi, to sieć się zapcha i to porządnie zanim mediana wzrośnie do np. 10MB.

W moim rozwiązaniu powstałoby od razu kilka bloków po kilkadziesiąt BTC a potem sytuacja wróciłaby do normy.

Zgodnie z propozycją asocjal kopalnia nie jest karana, chyba że sama się ukarze. Kopalnia po prostu powiększy blok wtedy gdy opłaty za dodatkowe transakcje przewyższą "karę".

Mogłaby to być kara od całości lub kara od nadwyżki ponad standardowe 1MB.

Pomysł niezły, ale lepszy byłby gdyby pomniejszać nagrodę za transakcje poniżej pewnego priority, wówczas mogłyby powrócić transakcje z zerowym fee, czyli coś czym bardzo chętnie podpierano się reklamując bitcoin.

Był za to chwalony ale na dłuższą metę transakcje z zerowym fee nie mają sensu. Dlaczego kopalnie mają ponosić koszt takich transakcji? Nawet bez proponowanej "kary" kopalnie ponoszą koszt przechowywania i rozgłaszania bloków z takimi transakcjami.

[majkel_94]

Ja bym proprosił o kalkulację, ile fee jest w standardowym pełnym 1MB bloku transakcji standardowych z tym 0.0001 BTC fee

Bo to byłby dobry patent na wymuszenie min. fee - tyle ile wynosi fee za kB, tyle jest kary za transakcje w bloku. Wtedy śmieciowe transakcje karają kopalnie, więc nikt nie wykopie wielkiego bloku nic niewartych transakcji, bo nie dostanie za nie kasy

Oczywiście jak tx ma priorytet bo stare monety, to nie ma za nią kary dla kopalni

[rav3n_pl]

Cały czas pomijacie problem, że te "śmieciowe" transakcje są nadal przesyłane pomiędzy węzłami i trzymane w pamięci.

[asocjal]

Cały czas pomijacie problem, że te "śmieciowe" transakcje są nadal przesyłane pomiędzy węzłami i trzymane w pamięci.

Racja, ale to już inny problem i pewnie wymaga innego rozwiązania.

[ania78]

A tak, niewatpliwie w swietle tego co sie stalo z ETH, pisze dzis CEO Bitpay, jednej z najwazniejszych firm ktore podpisala wrzesniowy list o forku XT oraz wspierających Classic.

https://twitter.com/spair/status/757908557949984769

Tymczasem poparcie dla Classic spadlo o 1% przez ostatnie dni, ponizej 3% I tez nie mam watpliwosci co jest przyczyną.

Jesli ktos ma jeszcze wątpliwosci nad drogą ktora obral Core I chinczycy to ja juz naprawde wysiadam.

[kingscrown]

Jesli ktos ma jeszcze wątpliwosci nad drogą ktora obral Core I chinczycy to ja juz naprawde wysiadam.

Napewno rozumiesz różnicę między HF w BTC a w ETH ? Może nie trzeba wysiadać od razu ale usiąść i poczytać na spokojnie.