[PLN] pln.bitcurex.com - Dyskusja Ogólna - ARCHIWUM

[Chancellor]

Tylko 8 miejsc po przecinku precyzji ? Chyba jesteś niepoważny. Przecież przy dzieleniu BTC, który ma 8 miejsc przez PLN, który ma 2 miejsca, ABSOLUTNE MINIMUM to 10 miejsc. Dla bezpieczeństwa, 12. Ba ! Jak napisałem własny silnik giełdy pod kryptowaluty, miał MINIMUM 20 miejsc po przecinku precyzji aby uniknąć JAKICHKOLWIEK możliwych błędów w obliczeniach.

Przecież wiesz, że tak czy inaczej precyzja zapisu liczb w komputerze jest skończona, więc mówienie o uniknięciu jakichkolwiek błędów zdradza nieznajomość zagadnienia. Poza tym precyzja obliczeń do bezpieczeństwa giełdy ma się raczej średnio. Tak czy inaczej wyniki się zawsze zaokrągla do 1 satoshi i 1 grosza.

[konkor]

"Szanowni Użytkownicy,

Prace IT są już na ukończeniu. Dzisiaj w godzinach wieczornych planowane są wewnętrzne testy zmodyfikowanego systemu, po których przeprowadzony będzie finalny audyt zewnętrzny. Po jego pozytywnym zakończeniu opublikujemy komunikat, w którym przekażemy Państwu dokładną datę uruchomienia serwisu oraz wszelkie niezbędne szczegóły.

Jeszcze raz dziękujemy Państwu za cierpliwość i okazane zaufanie - to wiele znaczy dla całego naszego zespołu.

Z poważaniem,
Zespół Bitcurex"

Finalny audyt pewnie przeprowadzimy my (użytkownicy) wycofując wszystko w celu sprawdzenia czy jest pokrycie Potem pewnie sytuacja będzie wracać do normy powoli...

Szczerze mówiąc wczoraj widziałem to zupełnie inaczej - gorzej.

[ShadowOfHarbringer]

Tylko 8 miejsc po przecinku precyzji ? Chyba jesteś niepoważny. Przecież przy dzieleniu BTC, który ma 8 miejsc przez PLN, który ma 2 miejsca, ABSOLUTNE MINIMUM to 10 miejsc. Dla bezpieczeństwa, 12. Ba ! Jak napisałem własny silnik giełdy pod kryptowaluty, miał MINIMUM 20 miejsc po przecinku precyzji aby uniknąć JAKICHKOLWIEK możliwych błędów w obliczeniach.

Przecież wiesz, że tak czy inaczej precyzja zapisu liczb w komputerze jest skończona, więc mówienie o uniknięciu jakichkolwiek błędów zdradza nieznajomość zagadnienia. Poza tym precyzja obliczeń do bezpieczeństwa giełdy ma się raczej średnio. Tak czy inaczej wyniki się zawsze zaokrągla do 1 satoshi i 1 grosza.

Widzisz, i tu jest pies pogrzebany - właśnie nie masz pojęcia o czym mówisz.

Precyzja komputerów jest skończona, ale tylko jeżeli operujemy na typach FLOAT. Dlatego typów FLOAT nie używa się do operacji finansowych, bo gubią precyzję.

Wszystkie popularne języki dzisiaj mają biblioteki do operacji o wysokiej precyzji (DOWOLNEJ PRECYZJI - nawet 100 miejsc po przecinku i więcej).

W php ta biblioteka nazywa się bcmath lub gmp.
http://www.php.net/manual/en/book.bc.php
http://www.php.net/manual/en/book.gmp.php

Proszę Cię, zrób nam wszystkim przysługę i nie bierz się za projektowanie informatycznych systemów finansowych, ok ?

[ShadowOfHarbringer]

Z bazami danych jest z resztą to samo. Używanie typów FLOAT/DOUBLE/REAL do przechowywania danych o wysokiej precyzji kończy się katastrofą.

Przykładowo w MySQL, do liczb wysokiej precyzji mozna użyć typu DECIMAL. W ostateczności można zapisywać precyzję w stringach/charach, ale wiadomo - nie jest to zbyt wydajne.
https://dev.mysql.com/doc/refman/5.0/en ... anges.html

EDIT:
Tak czy siak przeprowadzanie kalkulacji precyzyjnych w samej bazie za pomocą kwerend też może nie być dobrym pomysłem (zdaje się, że przykładowo MySQL miał jakieś błędy precyzji przy liczbach o dużej ilości miejsc po przecinku). Lepiej pobrać dane i kalkulacje przeprowadzić w języku systemu giełdowego.

[__kot__]

@ShadowOfHarbringer - zrób nam przysługę i opisz nam jaki sens i cel ma robienie systemów finansowych operujących na pieniądzu fiat z dokładnością do 100 miejsc po przecinku i zakończmy temat


Co do reszty to powtórzę się z wypowiedzi wczorajszej i ponowię apel: Nie wałkujcie tematu błędów opisując je szczegółowo na publicznym forum!
Nie bronię tu podejścia Curexa do poprawiania błędów (lub jego braku). Moim zdaniem dużo lepszym pomysłem jest pisanie ticketów w ilości choćby 100 dziennie i apelowanie by reszta społeczności robiła to samo.
Opisując błędy na forum tak, jak ma to tutaj miejsce, podcinacie po prostu gałąź, na której siedzicie i siedzi wielu innych użytkowników tego forum.

[Chancellor]

Widzisz, i tu jest pies pogrzebany - właśnie nie masz pojęcia o czym mówisz. [...] Wszystkie popularne języki dzisiaj mają biblioteki do operacji o wysokiej precyzji (DOWOLNEJ PRECYZJI - nawet 100 miejsc po przecinku i więcej).

Zapomniałeś wszak o jednym drobnym szczególe. Bardzo często, a w zasadzie z reguły, wynik jakiegokolwiek dzielenia będzie miał nieskończone rozwinięcie dziesiętne. Tak więc choćbyś wziął 1000 miejsc po przecinku, to i tak nie możesz pisać o uniknięciu "jakiegokolwiek" błędu. Ba, każde mnożenie liczb o niezerowej części ułamkowej zwiększa ilość miejsc po przecinku. Próba zachowania ich wszystkich bardzo szybko doprowadzi do zapchania pamięci nawet największego komputera, o wydajności systemu nie wspomnę. Tak więc jakiej biblioteki byś nie wziął, będziesz zaokrąglał.

Proszę Cię, zrób nam wszystkim przysługę i nie bierz się za projektowanie informatycznych systemów finansowych, ok?

Bezpieczeństwo i stabilność komputerowego systemu finansowego nie zasadza sie na tym ile nadmiarowych miejsc po przecinku będzie obsługiwał. Nie uważasz, że ośmieszasz się rzucaniem tego rodzaju tekstów?

P.S. Myślę, że moderator przeniesie to do HydeParku.

[meetom]

Moim zdaniem dużo lepszym pomysłem jest pisanie ticketów w ilości choćby 100 dziennie i apelowanie by reszta społeczności robiła to samo.

I teraz na czym by się pracownicy giełdy nie skupili (naprawiać błędy czy odpisywać na tickety?) to będzie źle.. Zasypywanie ich ticketami imho nic nie da, poza frustracją, że nie odpisują na czas.. Żadna skrajność nie jest dobra.

[__kot__]

Spokojnie - od czytania ticketów nie są programiści tylko service desk. Także ludzie, którzy pracują nad kodem nie będą tym obciążeni.
W typowej sytuacji, jeżeli zgłaszam błąd do Service Desk-u to aby go zamknąć wystarczy tzw. workaround i sprawa jest zakończona. Jeżeli przyjdzie np. 1000 zgłoszeń dotyczących tego samego błędu (incydentu) to z incydentu staje się on 'major incident' i jest uruchamiana jest inna procedura obsługi błędu a także tworzony jest tzw. Problem, nad którym pracuje się już oddzielnie i z większym zaangażowaniem i kończy się on zazwyczaj zmianami w aplikacji a nie workaround-em. Także ma to sens - wierz mi

[emsi]

emsi, chyba sobie żartujesz teraz.

Łatanie dziury, tak żeby zadziałało i nie wygenerowało innych błędów moze trwać wiele godzin a nawet dni. Żaden odpowiedzialny admin, nie pozwoliłby żeby post z taką informacją, jak "na legalu" okraść użytkowników, sobie po prostu wisiał wiele dni.

To jest kwestia tzw. responsible disclosure. Oczywiście nie wypada takich rzeczy publikować bez kontaktu z administratorami ale jeśli już ktoś to zrobi to kasowanie to najgorsza rzecz jaką można zrobić. Z internetu nic nie ginie (ktoś kto to wrzucił może zrobić to na 10 innych forach albo ktoś to zapisał). Usunięcie tematu daje fałszywe poczucie bezpieczeństwa, że nie ma tematu a tymczasem sprawa jest zamieciona pod dywan. Zajmuję się bezpieczeństwem od kilkunastu lat i jest to bardzo gorąco dyskutowany temat. Wiele osób w sposób naturalny myśli tak jak Ty bo ma jak najlepsze intencje, jednak wieloletnia praktyka pokazuje, że nie jest to dobra metoda. Gdybym widział tego posta w listopadzie (albo gdyby się o nim zrobiło głośno w mediach) to już bym się ewakuował jako user z Bitcurexa (a tak potencjalnie straciłem sporo gotówki) albo z zawodowej ciekawości podłubał i wysłał im porządnie rozkminioną analizę problemu.

Często zdarza się też, ze administratorzy, suppport nie reagują na takie zgłoszenia? I co wtedy ma zrobić osoba, która odkryła błąd i ma dobre intencje? Czekać aż ktoś mniej przyzwoity znajdzie i wykorzysta dziurę czy opublikować na maksymalnie szerokim forum aby ostrzec użytkowników (pewnie też dotrzeć i wywrzeć w ten sposób większą presję na administratorach) jednocześnie ryzykując że informacja ta dotrze do osób o niecnych zamiarach? Wieloletnia praktyka pokazuje, że ta druga opcja jest lepsza. Po pierwsze jeśli tego nie zrobi to info metodą pantoflową rozejdzie się po różnych środowiskach aż trafi do nieodpowiedniej osoby. Po drugie, publiczna informacja w pewnym stopniu odstrasza hackera, bo skoro "wszyscy" wiedzą o błędzie to pewnie ryzyko jest większe albo zapaczują zanim zdąży ukraść, generalnie tylko amatorzy się połaszą na coś takiego (niestety script kiddies też są groźni).

Co powinien był zrobić Bitcurex? Powinien mieć przede wszystkim kanał do zgłaszania nadużyć i błędów, czyli maila secure@, który miałby bardzo krótki czas reakcji. Zgłoszenia wrzucane w normalną kolejkę supportową mogą czekać wiele godzin albo dni albo trafić do osób niekompetentnych, nie znających tematu, które potrafią tylko zaproponować odpalenie antywirusa. Tylko tyle i aż tyle.

Myślę, że krajowe firmy security już wysłały oferty audytu do Bitcuerexa

[M4v3R]

Tylko 8 miejsc po przecinku precyzji ? Chyba jesteś niepoważny. Przecież przy dzieleniu BTC, który ma 8 miejsc przez PLN, który ma 2 miejsca, ABSOLUTNE MINIMUM to 10 miejsc. Dla bezpieczeństwa, 12.

Ba ! Jak napisałem własny silnik giełdy pod kryptowaluty, miał MINIMUM 20 miejsc po przecinku precyzji aby uniknąć JAKICHKOLWIEK możliwych błędów w obliczeniach. A maxymalną liczbę miejsc, jakie mój silnik obsługiwał (twardy limit) to było 64 miejsca.

Jak z takim partackim podejściem się bierzecie za pisanie giełd, to nic dziwnego że potem pieniądze znikają.

Mógłbyś wstrzymać się od osobistych wycieczek? Nigdzie w "zadaniu" które podał 777 nie była mowa o BTC. Jeśli zadałbyś sobie trochę trudu i zrozumiał to co napisałem, to zobaczyłbyś że wystarczy ustawić stałą PRECISION nawet na 64 i otrzymujesz taki efekt jaki chcesz.

[BitBull]

Szanowni Użytkownicy,

Rozumiemy Państwa niepokój, dlatego jeszcze raz oficjalnie potwierdzamy najważniejszą informację: Państwa środki są bezpieczne. Trwające prace mają na celu ponowne uruchomienie serwisu ze wszystkimi jego funkcjonalnościami i jak najszybsze przywrócenie Państwu dostępu do zgromadzonych zasobów.

Z poważaniem,
Zespół Bitcurex

[fun]

Kod: Zaznacz cały

define('PRECISION', 8); // precyzja (ilość mejsc po przecinku) obliczeń
$a = $_GET['a'];
$b = $_GET['b'];
If (!is_numeric($a) || !is_numeric($b)) { die('Invalid input'); }
If (bccomp($b, "0", PRECISION) == 0) { die('Cannot divide by zero!'); }
print "Result: " . bcdiv($a, $b, PRECISION);

I właśnie stąd się biorą opinie o pseudo programistach php.
Proszę, nie pisz żadnej giełdy, co?

[baggins]

co Wy macie z krytyka tego skrawka kodu... poczytajcie parę postów wcześniej o co szło, a nie piszcie o za małej precyzji, że do BTC się nie nadaje i innych bzdur, bo nie o to chodziło

[M4v3R]

I właśnie stąd się biorą opinie o pseudo programistach php.
Proszę, nie pisz żadnej giełdy, co?

Jakiś konkretny zarzut?

[SkyValley]

Załóżcie osobny temat.

[ShadowOfHarbringer]

Widzisz, i tu jest pies pogrzebany - właśnie nie masz pojęcia o czym mówisz. [...] Wszystkie popularne języki dzisiaj mają biblioteki do operacji o wysokiej precyzji (DOWOLNEJ PRECYZJI - nawet 100 miejsc po przecinku i więcej).

Zapomniałeś wszak o jednym drobnym szczególe. Bardzo często, a w zasadzie z reguły, wynik jakiegokolwiek dzielenia będzie miał nieskończone rozwinięcie dziesiętne. Tak więc choćbyś wziął 1000 miejsc po przecinku, to i tak nie możesz pisać o uniknięciu "jakiegokolwiek" błędu. Ba, każde mnożenie liczb o niezerowej części ułamkowej zwiększa ilość miejsc po przecinku.

Widzisz, twoja wypowiedź jest niby poprawna, ale dalej nie rozumiesz o co mi chodziło.

Nie chodzi o to, żeby zachować całkowitą precyzję, bo jest to niewykonalne. Chodzi o to, żeby uniknąć możliwości strat finansowych z powodu kodu zaokrąglającego wynik.

Wystarczy więc, że zaokrąglenie będzie zachodziło kilka miejsc po przecinku niżej niż to konieczne, i straty finansowe z tego względu zejdą poniżej dziesiętnych części grosza na rok. Takie straty można spokojnie zaakceptować i wpisać w koszty prowadzenia biznesu.

[Bitmar]

Nowy wątek dyskusj na temat Bitcurexu: https://forum.bitcoin.pl/pln-bitcurex-c ... 14057.html