BTC/PLN jak zapisujecie dane

[grzem]

Jakie PLN, ja Ci podaję wynik w BTC.

Klient sprzedał 1 BTC, w historii widzi trzy transakcje, każda transakcja to BTC i PLN.
Saldo początkowe 1 BTC, 0 PLN.
Pokaż mi cztery pozostałe pary liczb prezenowanych klientowi, tzn. trzy transakcje po dwie liczby i saldo ostateczne dwie liczby.

[ShadowOfHarbringer]

Przy założeniu, że cena PLN/BTC = 1000 PLN/BTC:

Transakcja 1, Sprzedałeś 0.30000400 BTC za ~300.00 PLN [button pokaż pełną precyzję -> ~300.004]
Transakcja 2, Sprzedałeś 0.30000400 BTC za ~300.00 PLN [button pokaż pełną precyzję -> ~300.004]
Transakcja 3, Sprzedałeś 0.39999200 BTC za ~399.99 PLN [button pokaż pełną precyzję -> ~399.992]

Saldo końcowe: 1000.00 PLN, 0,00 BTC

Przy każdej sumie, po kliknięciu buttona "pokaż pełną precyzję" pokazuje się całkowita suma z pełną precyzją.
To jeden ze sposobów w jaki można to zrealizować, tak aby nie zaśmiecać ekranu i nie zarzucać użytkownika liczbami, których nie rozumie. Pewnie są inne, ale ten mi się podoba najbardziej.

Na koncie użytkownika zawsze jest zapamiętany stan z pełną precyzją (tak że wszystko będzie się zawsze zgadzać co do tysięcznej części PLN), ale nie musimy go zawsze pokazywać.

Tylko co to ma do tematu ? Kompletnie rozjechaliśmy ten topic.

PS.
Zdaje się, że złotówki też trzeba będzie w takim przypadku zapisywać z dokładnością co najmniej 12 miejsc, instynktownie czuję że przy niskiej cenie BTC/PLN mogą być kłopoty z niewystarczającą precyzją...

[grzem]

Tylko co to ma do tematu ? Kompletnie rozjechaliśmy ten topic.

No ma to, że usłyszeliśmy od kilku optymistów (w tym Ciebie), że istnieje proste rozwiązanie.
Jak widać wyżej, nie znamy go lub nie istnieje.
Ja osobiście, przychylałbym się jednak do pomysłu wykorzystania typu całkowitego 64-bitowego, z obcinaniem reszt zawsze na niekorzyść klientów giełdy.

[ShadowOfHarbringer]

Tylko co to ma do tematu ? Kompletnie rozjechaliśmy ten topic.

No ma to, że usłyszeliśmy od kilku optymistów (w tym Ciebie), że istnieje proste rozwiązanie.Jak widać wyżej, nie znamy go lub nie istnieje.

To jest bardzo proste, łatwe i przejrzyste rozwiązanie, co Ty chcesz tutaj prostszego ?

Ja osobiście, przychylałbym się jednak do pomysłu wykorzystania typu całkowitego 64-bitowego,

A co to zmienia na lepsze poza położeniem przecinka i utratą precyzji ?

z obcinaniem reszt zawsze na niekorzyść klientów giełdy.

Pewnie, lepiej okradać klientów giełdy na małe sumy, niż liczyć precyzyjnie.
No teraz to już mam niezły mindfuck.

Ty tak na poważnie w ogóle ?

[powered]

To ja może prościej, na przykładzie:
Klient wystawił zlecenie sprzedaży 1 BTC po 1000 PLN.
Zostało zrealizowane w trzech transakcjach:
30000400 sat
30000400 sat
39999200 sat

Jak ten problem rozwiąże decimal?
Co zobaczy klient (jakie trzy transakcje i jaką sumę) na wyciągu?

A gdzie jest problem ?
Jak decydujesz się na decimal to będziesz zapisywał wartości w BTC a nie w sat (nie będzie przeliczania, mnożenia, dzielenia). Z góry trzeba określić jaką precyzję potrzebujesz i jak duże liczby będą zapisywane. Dla BTC chyba wystarczy zwiększyć precyzję o 4 miejsca po przecinku czyli będzie 12 miejsc po przecinku. Dla złotówek też powinna wystarczyć precyzja o 4 miejsca więcej czyli 6 miejsc po przecinku (bankom wystarczają 4 miejsca po przecinku)
Tak samo jest w BIGINT też trzeba z góry określić precyzję (o ile mnożymy).

Przy double i float programiści olewali z jaką dokładnością zapisywana jest liczba, a procesory i tak gdzieś muszą ją zaokrąglić, wiec przy tej metodzie była "niekontrolowana precyzja" w dodatku obarczona pewnymi błędami wynikającymi z konstrukcji procesorów. Więc postanowiono że w finansach zabronione jest używanie tego typu zapisu.
Po prostu trzeba zaplanować i podjąć decyzję z jaką dokładnością będą zapisywane kwoty, na kogo korzyść będą zaokrąglane i ograniczyć mikro transakcję, aby nikt nie robił transakcji po 0,00000001 BTC bo po iluś tam tysiącach transakcjach doliczy się że mu brakuje 0,01 PLN.

[ShadowOfHarbringer]

To ja może prościej, na przykładzie:
Klient wystawił zlecenie sprzedaży 1 BTC po 1000 PLN.
Zostało zrealizowane w trzech transakcjach:
30000400 sat
30000400 sat
39999200 sat

Jak ten problem rozwiąże decimal?
Co zobaczy klient (jakie trzy transakcje i jaką sumę) na wyciągu?

A gdzie jest problem ?
Jak decydujesz się na decimal to będziesz zapisywał wartości w BTC a nie w sat (nie będzie przeliczania, mnożenia, dzielenia). Z góry trzeba określić jaką precyzję potrzebujesz i jak duże liczby będą zapisywane. Dla BTC chyba wystarczy zwiększyć precyzję o 4 miejsca po przecinku czyli będzie 12 miejsc po przecinku. Dla złotówek też powinna wystarczyć precyzja o 4 miejsca więcej czyli 6 miejsc po przecinku (bankom wystarczają 4 miejsca po przecinku)
Tak samo jest w BIGINT też trzeba z góry określić precyzję (o ile mnożymy).

Przy double i float programiści olewali z jaką dokładnością zapisywana jest liczba, a procesory i tak gdzieś muszą ją zaokrąglić, wiec przy tej metodzie była "niekontrolowana precyzja" w dodatku obarczona pewnymi błędami wynikającymi z konstrukcji procesorów. Więc postanowiono że w finansach zabronione jest używanie tego typu zapisu.
Po prostu trzeba zaplanować i podjąć decyzję z jaką dokładnością będą zapisywane kwoty, na kogo korzyść będą zaokrąglane i ograniczyć mikro transakcję, aby nikt nie robił transakcji po 0,00000001 BTC bo po iluś tam tysiącach transakcjach doliczy się że mu brakuje 0,01 PLN.

A wiesz ile cyfr potrzebujesz przy INT ?

9 miejsc na liczbę Bitcoinów (zakładamy że poważny silnik musi umieć obliczyć każdą sumę BTC), 8 miejsc na satoshi + 4 miejsca, żeby precyzji nie tracić.
To razem daje 21 miejsc.

Maksymalna liczba dla BIGINT (unsigned), według dokumentacji MySQL to 18446744073709551615. Czyli 20 znaków. Czyli nawet nie wystarczy na 4 dodatkowe miejsca dla precyzji dla dzielenia/mnożenia/innych działań.
O jeden znak za mało jak na mój gust. No ale tak jak mówiłem - ja lubię robić wszystko profesjonalnie.

Właściwie to powinienem w tym momencie dojść do wniosku, że jesteś średnio kompetentnym programistą, a silnik giełdy zaprojektowany przez Ciebie nie byłby dobrym silnikiem (gubienie precyzji na korzyść giełdy, WTF ????).

Nie wiem czy chce mi się kontynuować tą dyskusję, bo widzę iż trafiam na ścianę.

[powered]

Nie powiedziałem ile miejsc po przecinku należy zarezerwować w bigint tylko w decimal.
Ogólnie to napisałem że z góry trzeba sobie to zaplanować w każdym typie zapisu liczb za wyjątkiem double i float.

Natomiast dla mnie bigint spokojnie wystarczy aby zapisać BTC z 12 miejscami po przecinku. Może trochę to "nieprofesjonalnie" ale w moich planach nie będę brał pod uwagę że będę musiał obsłużyć klienta który będzie właścicielem około 90% wszystkich bitcoinów na Świecie

[ShadowOfHarbringer]

Nie powiedziałem ile miejsc po przecinku należy zarezerwować w bigint tylko w decimal.
Ogólnie to napisałem że z góry trzeba sobie to zaplanować w każdym typie zapisu liczb za wyjątkiem double i float.

Natomiast dla mnie bigint spokojnie wystarczy aby zapisać BTC z 12 miejscami po przecinku. Może trochę to "nieprofesjonalnie" ale w moich planach nie będę brał pod uwagę że będę musiał obsłużyć klienta który będzie właścicielem około 90% wszystkich bitcoinów na Świecie

Szczerze mówiąc to chciałbym wiedzieć jaka giełda używa Twojego silnika, żebym mógł jej nie używać.

Z takim nieprecyzyjnym myśleniem daleko nie zajedziesz kolego, problemy będą narastać i narastać aż w końcu coś "rzuci wyjątkiem" i będzie padaka.

[powered]

... aż w końcu coś "rzuci wyjątkiem" i będzie padaka.

"coś" - Takie właśnie twierdzenie można nazwać nieprecyzyjnym myśleniem. Trzeba od razu wiedzieć co może być tym wyjątkiem, w dodatku można ustalić w którym roku może to wystąpić. Ale analizując to realnie po ludzku, a nie zero-jedynkowo jak komputer, można przyjąć że taka sytuacja nigdy nie wystąpi.

Ale mieliśmy chyba rozmawiać o najlepszej metodzie zapisu walut, a nie sprowadzać rozmowę do tego kogo nieistniejąca giełda jest lepsza.

[hanti]

Nie no jesli cos sie moze wydarzyc to jesli wiemy co trzeba zrobic tak zeby sie to nie wydarzylo to trzeba to zrobic. Nie wazne jakie jest prawdopodobienstwo. Ja sie zgadzam z Shadowem

[ShadowOfHarbringer]

... aż w końcu coś "rzuci wyjątkiem" i będzie padaka.

"coś" - Takie właśnie twierdzenie można nazwać nieprecyzyjnym myśleniem.

Widzę, że do niczego tutaj nie dojdziemy.

Jeżeli nie rozumiesz jaki jest problem z tworzeniem sobie potencjalnych kłopotów na przyszłość vs rozwiązywaniem ich jeszcze zanim się pojawią, to nie mam więcej pytań.

Tragedia, jestem zawiedziony - myślałem, że jesteś poważnym człowiekiem.

[rav3n_pl]

Jedynym sensownym rozwiązaniem, które nie pogrąży giełdy, wydaje mi się zaokrąglanie na korzyść giełdy o jedno miejsce dalej niż się rozliczamy. Klient nie widzi a my jesteśmy bezpieczni. win-win.

[powered]

A więc
1. jest możliwe że kiedyś będzie ktoś w posiadaniu ponad 18mln BTC (około 90% z całości)?
2. przeleje wszystkie te swoje BTC na jedną giełdę?
3. rynek wymiany BTC będzie dalej funkcjonował wtedy gdy jedna gruba ryba będzie się bawić kursem?
4. wtedy kiedy to teoretycznie może wystąpić, w obiegu będzie jeszcze na tyle bitcoinów?

Jeżeli nie wierzę że jest to możliwe, to jest to wystarczający powód aby nazwać mnie niepoważnym człowiekiem?
Wiedząc że jest to teoretycznie możliwe nie zrobiłbym jednego małego zabezpieczenia?

Ja natomiast mam bardzo małe zaufanie do programistów którzy robią coś na wyrost i nie są w stanie wytłumaczyć dlaczego tak robią. Można z tego wywnioskować że nie mają zaufania do programu który sami tworzą.

[AdamM]

Jeśli sytuacja jest teoretycznie możliwa i jej obsłużenie nie jest kosztowne ani skomplikowane to dlaczego pchać się w coś innego? Tu nie chodzi o brak zaufania do programu, który się pisze. Tu chodzi o zapewnienie że program działa poprawnie w możliwie każdych warunkach.

[pm7]

Wiesz, teoretycznie możliwe jest, że ludzie tworząc nowe adresy BTC trafią na cudze, już użyte.
Jakoś po wytłumaczeniu szans na to ludzie przestają się tym przejmować.

Jednym z pierwszych kroków pisania programu powinno być ustalenie warunków, np. jakie największe kwoty są możliwe.
Mamy się przejmować, że ktoś dajmy na to wyśle nam na giełdę septylion złoty?

[AdamM]

pm7, zgadzam się z Tobą że nie nie ma sensu implementować rozwiązań na sytuacje, które są nieprawdopodobne. Jednak w tym przypadku wydaje mi się że takie podejście może powodować problemy przy próbach "reużycia" takiego kodu. Np. pewnego dnia ktoś może chcieć opalić na tym kodzie giełdę jakiegoś alta, będącego klonem BTC, w którym wspomniana sytuacja nie będzie już niczym dziwnym. To chyba nie jest zbyt nieprawdopodobna sytuacja? Teoretycznie kod powinien działać bez problemu, a problemy się pojawią.

EDIT:
Ogólnie jak chyba wyżej już wspomniałem moim zdaniem wszystko się rozbija tutaj o koszty. Jeśli wdrożenie takiej zmiany nie powoduje znacznych dodatkowych kosztów to IMO należało by je wprowadzić.

[powered]

Samo zmniejszenie precyzji w bigint do 11 miejsc po przecinku nie uchroni bazy od wykrzaczenia się.
Gdy chcemy zapisać waluty, to każdy typ zapisu liczb będzie miał jakieś ograniczenia (skala i precyzja). Więc zawsze powinno się robić zabezpieczenie stosowne do wybranego typu zapisu aby nie wprowadzić za dużej liczby. I teraz mało ważne staje się że teoretycznie pojawi się kiedyś jeden klient z 18 mln BTC.
Jeżeli przy planowaniu giełdy będą takie założenia że liczby mają być w bigint z 12 miejscami po przecinku to dla jednego klienta nie muszą zostać ograniczone możliwości całej giełdy. Ten jeden biedny klient jak mu przyjdzie do głowy wystawić ofertę na giełdzie na taką sumę to będzie skazany na komunikat np tego typu "ze względu na ustawę o przeciwdziałaniu praniu pieniędzy oraz finansowaniu terroryzmu bla bla bla"

[1911pablo]

http://www.six-swiss-exchange.com/parti ... ps_en.html

To ja też jeszcze raz. Mam na koncie 200 PLN = 20000 groszy. Kupuję 0,12345678 BTC (12345678 satoshi) po 876,54 PLN (87654 grosze). W związku z tym z konta trzeba mi zdjąć – licząc w groszach i satoshi – 12345678 * 87654 / 100000000 = 10821,48059412 groszy. I teraz co robisz, albo zaokrąglasz na korzyść mnie, ucinając część ułamkową, albo zaokrąglasz na korzyść giełdy, odliczając z salda złotówkowego 10822 grosze. Jeżeli już pisałbym w ten sposób, to musiałbym uważnie pamiętać o tym, żeby każdą operację zaokrąglać finalnie na korzyść giełdy.

A to jest dopiero początek kłopotów. Dorzućmy do tego wyliczanie prowizji dla giełdy, albo – nie daj Boże – handel z dźwignią i liczenie opłat...

Oczywiście masz rację, nie mniej jednak sprawdź co się stanie jak weźmiesz pod uwagę powyższy link.

[MrLei]

@ShadowOfHarbringer : dobrze wam wyjaśnił sprawę.

Silnik musi być dokładny jak się tylko da.
Precyzja musi być kontrolowana bo poza przeliczaniem samych transakcji dochodzą prowizje od kwot bardzo niskiej wartości zleceń, które zostają zazwyczaj z "resztek" zlecenia które ktoś np:wykupił w 99,9 %, od tego dochodzą prowizje z dźwigni, rozliczenia utrzymania dziennego czy zamknięcia. Bardzo dużo obliczeń wykonuje się właśnie w obszarze tych mniejszych liczb i tam gdzie właśnie ten proces groźnych zaokrągleń się odbywa. Ponadto ważna sprawa jest kontrola bilansów. Tego co się dzieje z przepływami walut. Bez wysokiej precyzji już po kilku tysiącach transakcji zobaczysz efekt "mnożenia" lub " ubytku" walut. Można ten efekt ładnie zaobserwować ściągają jakąś giełdę za darmo i sobie po testować, tam bardzo często widziałem takie kwiatki.

[pm7]

pm7, zgadzam się z Tobą że nie nie ma sensu implementować rozwiązań na sytuacje, które są nieprawdopodobne. Jednak w tym przypadku wydaje mi się że takie podejście może powodować problemy przy próbach "reużycia" takiego kodu. Np. pewnego dnia ktoś może chcieć opalić na tym kodzie giełdę jakiegoś alta, będącego klonem BTC, w którym wspomniana sytuacja nie będzie już niczym dziwnym. To chyba nie jest zbyt nieprawdopodobna sytuacja? Teoretycznie kod powinien działać bez problemu, a problemy się pojawią.

Możesz przygotować się na obsługę dowolnie wielkich liczb, a i tak może powstać waluta z większymi.