Bitcoin Core 0.10

[rav3n_pl]

Kolejna wersja już nie dev
https://github.com/bitcoin/bitcoin/blob ... e-notes.md
https://bitcoin.org/bin/0.10.0/

Główne zmiany:
- szybsza synchronizacja dzięki pobraniu najpierw nagłówków a następnie asynchronicznie bloków (do tej pory bloki były pobierane jeden po drugim)
- zmiana sposobu obliczania minimalnego wymaganego fee (im więcej transakcji czeka tym domyślna opłata rośnie)
- zmiana w sposobie podawania adresów IP dostępu RPC - doczytać, bo tu mogą być schody np w kopalniach czy serwisach które mają osobno demony
- umożliwienie dostępu do części danych z łańcucha bez autoryzacji (mechanizm REST)
- zastąpienie OpenSSL przez libsecp256k1 przy podpisywaniu (OpenSSL się popisał ostatnio kilkoma bykami...)
- możliwość dodania adresów "watch only" do portfela - widzimy stan konta, ale nie możemy go wydać
- rozpoczęcie wdrażania konsensusu - w przyszłości będzie można pobrać na starcie tylko bazę UTXO i demon już będzie działał prawidłowo
- dodanie pewnych skryptów P2SH jako standardowe
- dodanie bitcoin-tx - narzędzie stricte do obsługi transakcji
- zmiana standardu bloków na v3
- wchodzi w życie BIP66

[lenny]

Szybkie ściąganie blockchain, zmienna wartość fee dla potwierdzenia po n-blokach - brawo! Na to czekaliśmy

[Molisz]

Kolejna wersja już nie dev
- zmiana sposobu obliczania minimalnego wymaganego fee (im więcej transakcji czeka tym domyślna opłata rośnie)

Jak to bedzie wygladało?
Demon sam zaproponuje min nową kwotę fee gdy liczba tx ktore czekają w sieci w zrośnie?

[pm7]

Z tego co zerknąłem, demon prowadzi statystyki jakie jest przełożenie opłaty na szybkość potwierdzenia.

[rav3n_pl]

Wg opisu, jest możliwość wyboru fee w zależności, w ike bloków chcemy mieć potwierdzenie.

[wev]

Tutaj jest to fajnie opisane, chociaż dosyć ogólnie: https://blog.bitcoinfoundation.org/floa ... -for-0-10/

A w bitcoin-qt wygląda to tak jak poniżej. Mamy taki suwak w którym zmieniamy w ciągu ilu bloków nasza transakcja prawdopodobnie powinna być dołączona (od 25 do 1). Przy 1 bloku teraz jest to ok 444uBTC/kB. Chociaż jak transakcja jest o wysokim priorytecie (stare monety, duża wartość) można próbować z mniejszym lub bez fee.

bitcoincore.png

[Molisz]

Hmm ... to wygląd tylko jak pewna predykcja że jeśli dasz "tyle" fee to będziesz miał Tx w "mniej więcej" po "tylu" blokach...
a w RPC nie ma tego tylko w GUI jest czy się mylę?

[lenny]

Hmm ... to wygląd tylko jak pewna predykcja że jeśli dasz "tyle" fee to będziesz miał Tx w "mniej więcej" po "tylu" blokach...
a w RPC nie ma tego tylko w GUI jest czy się mylę?

To się ustawia w pliku konfigu, więc raczej w RPC też będzie.
Predykcja - niczym się to nie różni od poprzedniego (w wersji 0.9x) stałego fee, mogłeś wtedy wybrać 0 fee (jeśli możliwe wg zasad darmowej transakcji wszytej w program) albo x fee (gdzie x to ogólnie przyjęta kwota, która tak samo jak teraz, niczego nie gwarantowała i mogłeś się jedynie spodziewać, że transakcja zostanie potwierdzona wkrótce).

[Molisz]

Czyli to tylko taki "suwaczek-kalkulator" który zachęca do dawanie większych tipów.
Czy 0.0001 BTC za kB będzie normalną opłata czy tez ta wartość minimalna za kB się podniesie?

[lenny]

Czyli to tylko taki "suwaczek-kalkulator" który zachęca do dawanie większych tipów.

Zgadzam się, też bym to tak nazwał. Nie musisz być 100% zgodny z tym kalkulatorkiem, wyślij swoją transakcję z minimalną opłatą (albo bez niej), i tak w końcu dojdzie do adresata.

Czy 0.0001 BTC za kB będzie normalną opłata czy tez ta wartość minimalna za kB się podniesie?

Teraz możemy wiedzieć każdą minimalną opłatę za n-ty (statystyczny) blok. Z tego co wiem nadal mamy narzut 1 MB per blok, więc statystycznie to opłata za potwierdzenie będzie rosnąć (bo raczej ilość transakcji w sieci Bitcoin będzie rosnąć).

[rav3n_pl]

Wartość fee zaszyta w kodzie się nie zmieniła. Dodali po prostu możliwość ustawienia takiego, jakie chcemy zapłacić w zależności od sytuacji.
Jak robimy arbitraż, to dajemy więcej, jak oddajemy dług to mniej
Demon po prostu zbiera dane i na ich podstawie wylicza, przy jakim fee nasza TX ma szanse być dołączona natychmiast, a przy jakim poczekamy.
Przedtem takiej funkcji nie było w cale, fee było wyliczane najmniejsze możliwe.

[MusX]

z arbitrażem to żartowałeś czy są ludzie którzy faktycznie przelewają zanim zrealizują zysk?

[konkor]

@MusX jak robisz arbitraż między giełdami, to w niektórych przypadkach trzeba przez swój portfel na kompie. Przesłanie bitów z Bitcurex na Krakena bezpośrednio nie jest łatwe - na Curexie nowy adres wymaga kwarantanny, a na Krakenie adresy wpłat się "starzeją" i usuwają - trzeba generować nowe. Sam jakiś czas temu czekałem chyba ze 3-4 godziny na dojście dość dużej ilości BTC w celu arbitrażu, bo w nowo zainstalowanym core było fee ustawione na zero

[MusX]

dlatego trzymasz środki w obu giełdach i wyrównujesz salda bez pośpiechu po zrealizowaniu zysku. Nie wiem dlaczego ktoś by tutaj miał grać na czas, omija się wtedy większość okazji na arbitraż.

[konkor]

No nie bardzo kolego. W tym modelu byłbym na bitach przez większość czasu połową środków Patrząc na wykres w 1w-3d taka zabawa na dłuższą metę nie byłaby opłacalna.

[Molisz]

Mnie interesuje to fee gdyż sam składam tx i podpisuje sobie kluczem który mam w off-line i tylko wysyłam już raw'a podpisanego on-line.
Duże kwoty lub te które wymagają wielu depozytów wejściowych (in'ow) dzieli mi Tx do 1kB , liczy resztę - 0.0001 i już. Nie muszę martwić się o kradziesz portfela czy problem z dyskiem a podział dużej kwoty na kilka Tx zabezpiecza mi utknięciu przypadkowo dużej kwoty w jednej Tx co się czasami zdarza i może przyprawić o zawał serca.
Zastanawiałem się czy gdy będę robił update do 0.10 będę musiał weryfikować fee odpytując demona o statystyki lub coś takiego.

[rav3n_pl]

Nie, bo jak już pisałem, zasady się nie zmieniły.
Statystyki pokazują, że kopalnie wybierają lepiej płatne TX, więc jak zależy na czasie warto zapłacić parę groszy (dosłownie) więcej. A jak nie, to wchodzi nie w pierwszym ale kolejnym bloku.

[majkel_94]

Ale dzięki takiemu mechanizmowi nie będzie już 0-1 tak jak dotychczas (brak fee lub 0.0001 BTC), ale będzie można dać mniej lub więcej wybierając prędkość przelewu. Dzięki temu rozkład fee będzie bardziej równomierny i rzeczywiście będzie wpływ na czas

[AdamM]

Ale przecież do tej pory też można było dać inną wartość fee niż 0.0001...

[lenny]

Ale przecież do tej pory też można było dać inną wartość fee niż 0.0001...

Tak, zgadza się. Ale teraz dodatkowo wiesz, jaka wartość odpowiada (statystycznie) potwierdzeniu po n-blokach.