BitcoinSV.pl - potencjał & spekulacja & rozwój projektu & aplikacja - Wszystko o BSV

Wygadany
Awatar użytkownika
Posty: 485
Rejestracja: 8 lutego 2020
Reputacja: 863
Reputacja postu: 
1
Napiwki za post: 0 BTC
Lokalizacja: ghidra-sre.org

BitcoinSV.pl - potencjał & spekulacja & rozwój projektu & aplikacja - Wszystko o BSV

Postautor: garlonicon » wtorek, 19 lipca 2022, 07:16

We have demonstrated the knowledge without a digital signature!
Yhy, akurat. Dwie sprawy:
1) Technicznie rzecz biorąc, sygnatura jest niczym innym, jak powiązaniem pomiędzy kluczem publicznym Q, a kluczem publicznym sygnatury R. Zatem, co by to nie było, to jest sygnatura. Jeśli to jest uzyskiwane przez samo dodawanie, tudzież przez samo mnożenie, to nie różni się specjalnie od przejścia z klucza prywatnego na publiczny. Jeśli natomiast jest to kombinacja dodawania i mnożenia, to da się to przekształcić tak, aby uzyskać prawidłową sygnaturę i przekazać to w tej formie.
2) W tym wszystkim nie jest wspominana bardzo ważna kwestia, a mianowicie taka, że aby taki ZCash mógł na tym działać, to musi zostać wybrany klucz, w ramach czegoś takiego, jak "ZCash Ceremony". Oznacza to tyle, że klucz, który tam powstaje, jest istotny z punktu widzenia bezpieczeństwa całości. Jeśli natomiast "każdy sobie rzepkę skrobie" i każdy używa innego klucza, to jest to zupełnie inny model, bo wtedy trzeba każdorazowo sprawdzać, jak taki klucz powstał, więc to już nie jest "zero knowledge", tylko raczej "blockchain-based knowledge".

No i najważniejsze pytanie: eee, a gdzie tu BSV? Gdzie choćby przykład na jakiejś sieci testowej? Gdzie hash jakiejkolwiek transakcji, która tego dotyka i która odbyła się na BSV?

Poza tym, to jest właśnie to, o czym wspominałem: te screeny z kodu z Medium są wstawione w kompletnie niepraktyczny sposób. Raz, że to jest obrazek, a nie tekst, przez co nijak nie idzie tego wygodnie skopiować, dwa, że na obrazku jest scrollbar, co oznacza, że nie widać całości. Jeśli wersja bazująca na tekście z Medium byłaby lepsza, to miałoby to sens, natomiast tutaj jest ewidentnie gorsza, choćby dlatego, że w tekście jest słowo "here" bez żadnego linku dokądkolwiek.

Początkujący
Awatar użytkownika
Posty: 981
Rejestracja: 13 września 2017
Reputacja: 391
Reputacja postu: 
0
Napiwki za post: 0 BTC

BitcoinSV.pl - potencjał & spekulacja & rozwój projektu & aplikacja - Wszystko o BSV

Postautor: zdch » czwartek, 21 lipca 2022, 12:05

ciekawe, ciekawe

Początkujący
Awatar użytkownika
Posty: 981
Rejestracja: 13 września 2017
Reputacja: 391
Reputacja postu: 
0
Napiwki za post: 0 BTC

BitcoinSV.pl - potencjał & spekulacja & rozwój projektu & aplikacja - Wszystko o BSV

Postautor: zdch » sobota, 23 lipca 2022, 17:10

zk-SNARK na BSV

Wygadany
Awatar użytkownika
Posty: 485
Rejestracja: 8 lutego 2020
Reputacja: 863
Reputacja postu: 
0
Napiwki za post: 0 BTC
Lokalizacja: ghidra-sre.org

BitcoinSV.pl - potencjał & spekulacja & rozwój projektu & aplikacja - Wszystko o BSV

Postautor: garlonicon » sobota, 23 lipca 2022, 18:01

The first zk-SNARK on Bitcoin.
Tak jak myślałem. Kompletność Turinga objawia się niesamowicie długim Scriptem. Tylko wtedy zachodzi pytanie: czemu Script nie jest jeszcze prostszy? Po co komu OP_CHECKSIG? Przecież można ręcznie jechać, włożyć bit po bicie przez OP_TRUE oraz OP_FALSE, a następnie użyć nawiasów, stosując OP_IF oraz OP_ENDIF w odpowiednich miejscach. Te cztery opkody nie wystarczą?
Size: 11,717,578 B
Łohoho, prawie 12 MB na jedną transakcję stosującą zk-SNARK.
0.00585879 BSV
Opłata też widzę niezła. Jak na przesłanie 0.01 BSV, to procentowo dosyć sporo. Wniosek: przy mikropłatnościach będzie ciężko.

Początkujący
Awatar użytkownika
Posty: 981
Rejestracja: 13 września 2017
Reputacja: 391
Reputacja postu: 
0
Napiwki za post: 0 BTC

BitcoinSV.pl - potencjał & spekulacja & rozwój projektu & aplikacja - Wszystko o BSV

Postautor: zdch » sobota, 23 lipca 2022, 19:29

@garlonicon Da się czy się nie da? Jest ta kompletność Turinga czy jej nie ma? Bitcoin działa i działał tak samo w 2009. Ludzie zostali zmanipulowani i teraz trzeba lat, żeby to wyprostować.

BSV umożliwia 12MB transakcje! Jedna transakcja BSV zajmująca 12 bloków BTC, czyż to nie piękne?
Opłata 33 centy przy obecnej cenie i stawkach dla górników. Wraz z większą ilością transakcji i większymi blokami, opłaty będą niższe.

Jak dla mnie ta jedna, pierwsza transakcja udowodniła kilka ważnych rzeczy. A to dopiero początek.

Najpierw słyszeliśmy że sieć się wykrzaczy na 23BM blokach. Potem że 100MB blok jest nie do przejścia. Potem że nie ma kompletności Turinga. Teraz że transakcja zk-SNARK zajmuje za dużo miejsca :) Co będzie następne? BSV buduje, BSV pokazuje że DA SIĘ! Wolicie kupować shitcoiny i zastanawiać się czy 600% APY na jakimś scamie to dobry interes.

Tutaj macie technologię, która działa i wciąż wam coś nie pasuje, bo trudno jest przyznać się wam do pomyłki. Ludzie nauki akceptują nowe fakty i odrzucają nieprawdę. Polecam.

Wygadany
Awatar użytkownika
Posty: 485
Rejestracja: 8 lutego 2020
Reputacja: 863
Reputacja postu: 
1
Napiwki za post: 0 BTC
Lokalizacja: ghidra-sre.org

BitcoinSV.pl - potencjał & spekulacja & rozwój projektu & aplikacja - Wszystko o BSV

Postautor: garlonicon » sobota, 23 lipca 2022, 20:25

Da się czy się nie da?
1) da się
2) jest to strasznie nieoptymalne
Jest ta kompletność Turinga czy jej nie ma?
Wiesz, w ten sposób to można nawet bloki wykopywać i sam konsensus egzekwować, gorzej z wydajnością. No bo wtedy pojawia się pytanie: czemu akurat SHA-256? Przecież można zamiast mieć OP_SHA3, to sobie ręcznie robić pushe i składać wszystkie rundy. Można, ale jest to strasznie niewydajne.
Jedna transakcja BSV zajmująca 12 bloków BTC, czyż to nie piękne?
Raczej od 3 do 12 bloków, żeby być ścisłym, ale mniejsza z tym. Przede wszystkim kłopotliwe w utrzymaniu.
Opłata 33 centy przy obecnej cenie i stawkach dla górników. Wraz z większą ilością transakcji i większymi blokami, opłaty będą niższe.
Polemizowałbym, że zrobienie nowego opkodu OP_ZK_SNARK lub czegoś w tym stylu byłoby tańsze, prawdopodobnie analogiczna transakcja na takim łańcuchu, jak ZCash, byłaby tańsza i prostsza, bo łatwiej jest dołożyć nowy opkod w ten czy inny sposób, niż kombinować jak koń pod górkę. Żeby się o tym przekonać, wystarczy spojrzeć na Script. Czy jak czytasz "... OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT ...", to jest to proste i intuicyjne? A co, gdyby tam było OP_DUP zamiast OP_SWAP? Byłoby lepiej czy gorzej i dlaczego? No właśnie. Nie sądzę, że jesteś w stanie dokładnie wyjaśnić, jak działa ten Script i dlaczego tam jest OP_SWAP, a nie coś innego. Tym bardziej nie sądzę, że jesteś w stanie na pierwszy rzut oka stwierdzić, co tam się tak naprawdę dzieje i co należy zmienić, aby dołożyć do tego jakiś prosty warunek w środku.
Najpierw słyszeliśmy że sieć się wykrzaczy na 23BM blokach.
Ile węzłów opuściło sieć od tamtej zmiany?
Potem że 100MB blok jest nie do przejścia.
Jeśli celem jest zniechęcenie kolejnych węzłów, to owszem, można i tak.
Potem że nie ma kompletności Turinga.
Równie dobrze możesz powiedzieć, że każdy algorytm ma stałą złożoność obliczeniową, bo wykonuje się w skończonym czasie. Jestem ciekaw, ile będzie ważyła transakcja z wielokrotnie zagnieżdżonymi pętlami, gdy trzeba będzie każdą taką pętlę rozwinąć i całość zacznie wykładniczo przyrastać. Fibonacciego też można zrobić przez "0 1 OP_ADD 0 1 OP_ADD OP_ADD ...", tylko że to wtedy eksploduje. Same zera, jedynki, a także OP_ADD wystarczą, nie potrzeba żadnych innych opkodów. A jednak lepiej jest mieć takie OP_2DUP, żeby sobie ułatwić życie, prawda?
Teraz że transakcja zk-SNARK zajmuje za dużo miejsca
Bo tak jest. Jeśli to żaden problem, to przecież teraz można cały łańcuch ZCash wciągnąć, prawda? Co, u nas się nie zmieści? Dawaj, kopiemy!
Co będzie następne?
Zależy, jaki ficzer chce mieć BSV. Może Monero i RingCT? Tam zajmuje to około 1800 bajtów, ciekawe, ile zajmie tutaj i czy cały łańcuch Monero też można sobie zassać na BSV. Jak szaleć, to szaleć!
BSV buduje, BSV pokazuje że DA SIĘ!
Pewnie, że się da. Każdy problem można tak rozwiązać. Kopanie jest zbyt scentralizowane? Olać to, niech każdy górnik zgłasza każdy share i wpycha to na łańcuch. Jeśli jeden blok zajmuje 4 GB, to jeśli mamy 1000 bloków o niższej trudności w jakimś poolu w ciągu 10 minut, to dawaj, ładujemy 4 TB na łańcuch, a co! Da się? Pewnie, że się da. Milion shares? Spoko, 4 PB na 10 minut. Można? Można. Warto? Oczywiście nie, ale jeśli BSV tak zrobi, to mnie nie zdziwi.
Wolicie kupować shitcoiny i zastanawiać się czy 600% APY na jakimś scamie to dobry interes.
Nie patrzę na spekulację.
Tutaj macie technologię, która działa i wciąż wam coś nie pasuje, bo trudno jest przyznać się wam do pomyłki.
Jakiej pomyłki? Przecież dawno temu napisałem, że jeśli Script byłby Turing-complete tak, jak ja to rozumiem, to ważyłby więcej niż normalnie, przez co wprowadzenie nowego opkodu jest wydajnościowo lepsze w takim przypadku (bodajże nawet pisałem wprost o "gigabajtowych scriptach"). Tym bardziej, że jeśli jakaś transakcja waży powiedzmy jakieś 1200 bajtów, to widać wyraźnie, na czym polega różnica: jedna transakcja zk-SNARK, czy tysiąc zwykłych transakcji o zwykłym rozmiarze? Wiesz, ile rzeczy można zrobić, wykonując tysiąc normalnych transakcji?

Edit:
Ludzie nauki akceptują nowe fakty i odrzucają nieprawdę. Polecam.
Znalazłem swój stary wpis. Jeśli źle pisałem, to podaj, w którym miejscu się myliłem.
garlonicon pisze: niedziela, 16 lutego 2020, 11:06 Co do tego, że Script może być Turing-complete, to nie mam wątpliwości. Widzę jednak pewien problem: koszt praktycznego stosowania czegoś takiego. Otóż Script nie ma żadnych pętli. Co z tego wynika? Ano to, że aby taką kompletność Turinga uzyskać, to trzeba powtórzyć dany ciąg opkodów tyle razy, ile razy maksymalnie mógłby się wykonać warunek wewnątrz ifa (czyniąc z niego sztucznie rozwiniętą pętlę tak, jak to niekiedy robią kompilatory). I teraz tak: z jednej strony spoko, bo się da. Z drugiej strony: czy ma sens pchanie do blockchaina gigabajtowej wielkości skryptu po to, aby na przykład umożliwić wydanie monet na podstawie własnej funkcji skrótu?
Edit: CTRL+F, "47fd7cd8168c203c8dca7168916a81975d588181b64550b829a031e1724e6430": 198 wystąpień. Łohoho, to nie tylko jest długie i waży prawie 12 MB. To zawiera powtórzone 256-bitowe liczby, co można byłoby skrócić, stosując inne opkody, na przykład OP_DUP. Wniosek? Nie tylko to jest kosztowne, ale również strasznie źle zoptymalizowane. Poza tym, widać, że autor użył OP_TOALTSTACK, więc ma świadomość istnienia więcej niż jednego stosu i powinien umieć zrobić takie rzeczy. No i z tego też wynika kolejna kwestia: jak masz OP_ZK_SNARK, to wiesz, jak ludzie tego używają i każdy programista wie, co z tym zrobić. A jak masz taki długi Script, to "każdy sobie rzepkę skrobie", co skutecznie zniechęca na przykład do tego, aby stawiać własny węzeł, skoro topornie się to kompresuje (bo każdy sobie to zoptymalizuje inaczej, więc nie można hurtowo skompresować wszystkich tego typu transakcji w ten sam sposób).

Początkujący
Awatar użytkownika
Posty: 981
Rejestracja: 13 września 2017
Reputacja: 391
Reputacja postu: 
1
Napiwki za post: 0 BTC

BitcoinSV.pl - potencjał & spekulacja & rozwój projektu & aplikacja - Wszystko o BSV

Postautor: zdch » sobota, 23 lipca 2022, 21:19

garlonicon pisze: sobota, 23 lipca 2022, 20:25Polemizowałbym, że zrobienie nowego opkodu OP_ZK_SNARK lub czegoś w tym stylu byłoby tańsze,
Z dwóch/trzech powodów jest to zły pomysł:
1) chęć dodania nowego opcodu doprowadził do forka BCH/BSV (OP_CHECKDATASIG). Protokół ma być niezmienny.
2) uproszczenie kodu to pewnego rodzaju kolejna subwencja dla użytkowników, działająca na niekorzyść górników, (dlaczego akurat ten typ transakcji miałby być tańszy?)
3) nie znane skutki prawne dodania takiej transakcji bezpośrednio do protokołu

Poza tym nic nie stoi na przeszkodzie optymalizować te transakcje w jakiś inny sposób. Pewnie wcześniej czy później ktoś znajdzie sposób bez zmian w protokole.
garlonicon pisze: sobota, 23 lipca 2022, 20:25 Jeśli to żaden problem, to przecież teraz można cały łańcuch ZCash wciągnąć, prawda? Co, u nas się nie zmieści? Dawaj, kopiemy!
Craig się odgrażał że całe ETH chce wciągnąć na BSV, jestem ciekaw czy tylko rzucał słowa na wiatr, więc kto wie :P
garlonicon pisze: sobota, 23 lipca 2022, 20:25Może Monero i RingCT?
Podpisy pierścieniowe już były w maju. Argumenty te same jak powyżej dlaczego nie bezpośrednio nowym op_codem. https://xiaohuiliu.medium.com/ring-sign ... 7ba9ee49b6
garlonicon pisze: sobota, 23 lipca 2022, 20:25jedna transakcja zk-SNARK, czy tysiąc zwykłych transakcji o zwykłym rozmiarze? Wiesz, ile rzeczy można zrobić, wykonując tysiąc normalnych transakcji?
Dlaczego nie móc robić obu naraz? Na BSV nic nie stoi na przeszkodzie i to było sedno Bitcoina od początku. Na BSV jest wybór.

Wygadany
Awatar użytkownika
Posty: 485
Rejestracja: 8 lutego 2020
Reputacja: 863
Reputacja postu: 
1
Napiwki za post: 0 BTC
Lokalizacja: ghidra-sre.org

BitcoinSV.pl - potencjał & spekulacja & rozwój projektu & aplikacja - Wszystko o BSV

Postautor: garlonicon » sobota, 23 lipca 2022, 22:41

1) chęć dodania nowego opcodu doprowadził do forka BCH/BSV (OP_CHECKDATASIG). Protokół ma być niezmienny.
Wiesz, protokoł może być niezmienny, jeśli będzie zawierał cztery opkody: OP_TRUE, OP_FALSE, OP_IF oraz OP_ENDIF. Te cztery opkody wystarczą do tego, aby zrobić absolutnie wszystko. A jednak Script z jakiegoś powodu jest bardziej rozbudowany. Więcej: model z whitepaperu nie mówi absolutnie nic o czymś takim, jak Script. Tam są tylko klucze publiczne. I to też by mogło być wystarczające, bo na samym ECDSA masz wszystko: dodawanie, odejmowanie, mnożenie, dzielenie, nawet potęgi i pierwiastki. Także to jest nie tyle kwestia niezmienności, ile kwestia wydajności. Każdy Script da się zastąpić wystarczająco dużym multisigiem, a każdy multisig da się wykonać na P2PK, podpisując transakcję z wieloma wejściami. Wszędzie, gdzie masz sygnaturę, masz co najmniej dodawanie i mnożenie 256-bitowych liczb. Także wiesz, samo P2PK wystarczy. Ale jednak Script istnieje z jakiegoś powodu, prawda? Skoro protokół ma być niezmienny i skoro whitepaper opisuje wyłącznie P2PK, to po co Script?
2) uproszczenie kodu to pewnego rodzaju kolejna subwencja dla użytkowników, działająca na niekorzyść górników
Co wybierze typowy górnik: odpalanie kodu ZCash i wspieranie zk-SNARK bezpośrednio, za pomocą transakcji, których rozmiar jest liczony w bajtach, tudzież kilobajtach? Czy może megabajtowe transakcje, które robią "coś", gdzie jak się patrzy na Script, to ni hu hu nie wiadomo, że to w ogóle zk-SNARK? Wyobraź sobie, że taka funkcjonalność jest nagle powszechnie używana zamiast OP_CHECKSIG. Co wtedy? Trzeba przerzucać całe megabajty, efektywnie robiąc tyle, co da się załatwić paroma kilobajtami? Przecież to oznacza, że trzeba przeczytać takie 12 MB zamiast 12 kB, trzeba to wszystko wykonać, no i nijak nie idzie tego skompresować, bo jeden programista optymalizuje to tak, a drugi inaczej.
(dlaczego akurat ten typ transakcji miałby być tańszy?)
Dlatego, że jeśli jakiś typ transakcji jest popularny i ustandaryzowany, to można go ujednolicić, sprawiając, że te same operacje będą wykonywane w ten sam sposób, co oznacza, że to samo można zrobić prościej i szybciej, a także można to zrównoleglać i optymalizować zbiorowo. A to jest istotne, bo im większe bloki, tym więcej trzeba zrobić w ciągu 10 minut. Jeśli masz funkcjonalność na BSV, która jest identyczna z jakąś funkcjonalnością na jakimś altcoinie, ale różni się głównie tym, że działa wolniej, to jest to niekorzystne, bo odbija się na wydajności, czyli też na tym, ile takich transakcji da się przetworzyć w ciągu 10 minut. A im więcej to waży, tym gorzej. Jeśli to waży 12 MB, to oznacza, że tysiąc takich transakcji waży 12 GB. Jeśli blok ma 4 GB, to oznacza, że masz tysiąc transakcji na trzy takie bloki. A teraz policz, ile OP_CHECKSIG można byłoby zrobić na 4 GB i to porównaj. Albo zobacz, ile było transakcji w ostatnim bloku i weź pod uwagę, że jakby ludzie rzucili się na zk-SNARK, to dostaniesz jakieś trzysta transakcji z hakiem na jeden blok 4 GB. Mało.
3) nie znane skutki prawne dodania takiej transakcji bezpośrednio do protokołu
Aha, czyli jeśli opkody mówią wprost: to jest transakcja zk-SNARK, to prawo jest niejasne. A jeśli z kolei opkody mówią: tu się dzieje "coś", to prawo jest jednoznaczne. Świetnie. Są takie Scripty, gdzie jakby mnie ktoś w sądzie kiedyś zapytał "do czego to służy", to bym ręce rozłożył, a tutaj się nagle dowiaduję, że pod względem prawnym to jest oczywiste. Spoko, dobrze wiedzieć. Czyli jak zobaczę "<pubkey> OP_TUCK OP_CHECKSIGVERIFY OP_TUCK OP_CHECKSIGVERIFY OP_TUCK OP_CHECKSIGVERIFY ...", to pod względem prawnym to jest całkowicie czyste? Bo jasne, technicznie to ja wiem, co tu się dzieje, ale jakby trzeba było tłumaczyć, po co to jest, to mógłby być problem, bo to nie jest oczywista kwestia, zwłaszcza jeśli ta konstrukcja "OP_TUCK OP_CHECKSIGVERIFY" będzie powtórzona wielokrotnie, na przykład tak ze dwadzieścia razy. Wtedy prawidłowa odpowiedź brzmi: to zależy.
Poza tym nic nie stoi na przeszkodzie optymalizować te transakcje w jakiś inny sposób.
Oczywiście, że tak. Tylko że jeśli każdy konstruuje je inaczej, to każdy przypadek musisz rozważyć osobno.
Pewnie wcześniej czy później ktoś znajdzie sposób bez zmian w protokole.
Nie musisz zmieniać protokołu ani o milimetr, aby zoptymalizować cokolwiek. Problem leży w innym miejscu: jeśli każdy pcha kod, który robi to samo, ale za pomocą innych opkodów, to zoptymalizowanie tego jest nieoczywiste i wymaga więcej wysiłku niż zazwyczaj, bo najpierw trawisz te 12 MB, a potem uzyskujesz efekt: "aha, to tylko zk-SNARK, ja to mogę machnąć osobną funkcją i to samo policzyć szybciej". A potem przychodzi kolejna transakcja spod innego portfela, gdzie trawisz kolejne 12 MB, z kompletnie innymi opkodami, żeby się zorientować, że na przykład jedni używają "OP_HASH256", a inni "OP_SHA256 <cośtam> OP_SHA256". I wtedy też się orientujesz, że tamta kolejna transakcja to też w sumie zk-SNARK, ale że klucz publiczny to jest "OP_IF <kluczAlicji> OP_ELSE <kluczBoba> OP_ENDIF". A potem kolejną, gdzie w pierwszym przypadku masz "<jakieś> <dane>", a w drugim "<dane> <jakieś> OP_SWAP". Wiesz, na ile sposobów da się to zrobić? Jest tyle możliwości, że optymalizowanie tego wymaga niesamowitego wysiłku, bo każdy może zrobić to odrobinę inaczej i już będzie pod górkę, żeby to rozplątać i poupraszczać.
Dlaczego nie móc robić obu naraz?
Dlatego, że tysiąc zwykłych transakcji jest w stanie tak bardzo wszystko poprzestawiać, że jedna transakcja zk-SNARK wygląda przy tym naprawdę blado. Kiepsko widzę od strony biznesowej mówienie komuś: "W naszej restauracji podajemy zupę pomidorową za złotówkę albo rosół za 1000 zł". Zamówiłbyś rosół?

Początkujący
Awatar użytkownika
Posty: 981
Rejestracja: 13 września 2017
Reputacja: 391
Reputacja postu: 
1
Napiwki za post: 0 BTC

BitcoinSV.pl - potencjał & spekulacja & rozwój projektu & aplikacja - Wszystko o BSV

Postautor: zdch » niedziela, 24 lipca 2022, 08:48

garlonicon pisze: sobota, 23 lipca 2022, 22:41A jednak Script z jakiegoś powodu jest bardziej rozbudowany.
Satoshi przewidział różne typy transakcji i dodał script żeby to umożliwić i nie modyfikować protokołu w przyszłości.
garlonicon pisze: sobota, 23 lipca 2022, 22:41Co wybierze typowy górnik
to co się bardziej opłaca
garlonicon pisze: sobota, 23 lipca 2022, 22:41Jeśli masz funkcjonalność na BSV, która jest identyczna z jakąś funkcjonalnością na jakimś altcoinie
to oznacza że altcoin jest niepotrzebny, a wraz ze wzrostem ilości takich transakcji jakiś górnik wpadnie na pomysł jak to przetwarzać efektywniej, a potem inni odgapią.
garlonicon pisze: sobota, 23 lipca 2022, 22:41Zamówiłbyś rosół?
wszystko zależy czy mi się to opłaca. Jeśli to udowodni komuś, że może kupić ode mnie coś za 10k to dlaczego nie?

Oficjalny przedstawiciel projektu
Awatar użytkownika
Posty: 1032
Rejestracja: 20 stycznia 2017
Reputacja: 1245
Reputacja postu: 
0
Napiwki za post: 0 BTC
Napiwki: https://ftx.com/#a=BitcoinSV
Napiwki: https://www.coinex.com/register?refer_code=bthm3

BitcoinSV.pl - potencjał & spekulacja & rozwój projektu & aplikacja - Wszystko o BSV

Postautor: bitup » poniedziałek, 25 lipca 2022, 13:15

W świecie BSV tylko postęp

a w Polsce zabierają się za influancerów ;) wkrótce zapewne i za YouTuba i naganialllo kryptowalutowe

Weteran
Posty: 2427
Rejestracja: 21 marca 2014
Reputacja: 1428
Reputacja postu: 
0
Napiwki za post: 0 BTC

BitcoinSV.pl - potencjał & spekulacja & rozwój projektu & aplikacja - Wszystko o BSV

Postautor: The Real McCoin » poniedziałek, 25 lipca 2022, 14:02

Dziecinnie prosta operacja (jeżeli nie jesteś oszustem):


Początkujący
Awatar użytkownika
Posty: 981
Rejestracja: 13 września 2017
Reputacja: 391
Reputacja postu: 
10
Napiwki za post: 0 BTC

BitcoinSV.pl - potencjał & spekulacja & rozwój projektu & aplikacja - Wszystko o BSV

Postautor: zdch » poniedziałek, 25 lipca 2022, 19:22

@The Real McCoin Charlie Lee to twój autorytet? :D https://bitfinexed.medium.com/coinbase- ... 64ead3facc

Wygadany
Awatar użytkownika
Posty: 485
Rejestracja: 8 lutego 2020
Reputacja: 863
Reputacja postu: 
1
Napiwki za post: 0 BTC
Lokalizacja: ghidra-sre.org

BitcoinSV.pl - potencjał & spekulacja & rozwój projektu & aplikacja - Wszystko o BSV

Postautor: garlonicon » wtorek, 26 lipca 2022, 07:28

Taka mała podpowiedź, odnośnie zk-SNARK, które ważyłoby znacznie mniej:

decodescript 6b2430440220678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb66c7e2103678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb6ac
...
"asm": "OP_TOALTSTACK 30440220678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb6 OP_FROMALTSTACK OP_CAT 03678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb6 OP_CHECKSIG"
...

Oczywiście, należy podmienić obie wartości, ale jeśli ktoś wie, jak działają sygnatury, to zdaje sobie sprawę, że w ten sposób można zrobić bardzo wiele. No i też to jest jeden z powodów, dla których OP_CAT może być groźny. Pytanie za sto punktów: czy ktoś wie, co robi ten Script? W sumie się zastanawiam, czy na ciekawe Scripty osobnego tematu nie machnąć w przyszłości, ale w kontekście zk-SNARK na razie wstawię tutaj taką podpowiedź.

Natomiast uproszczona wersja tego, co robi Script wyżej, mogłaby wyglądać tak:

decodescript 04304402207c20678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb6766b7c7e7e536c7eac
...
"asm": "537019440 OP_SWAP 678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb6 OP_DUP OP_TOALTSTACK OP_SWAP OP_CAT OP_CAT 3 OP_FROMALTSTACK OP_CAT OP_CHECKSIG",
...

Czy teraz widać wyraźniej, jaki jest cel takiego Scriptu? Oczywiście, 256-bitową liczbę można zmieniać, to tylko przykład, bo nie sądzę, że przy takiej wartości ktokolwiek by się zgodził to ruszyć.

Weteran
Awatar użytkownika
Posty: 5359
Rejestracja: 20 grudnia 2015
Reputacja: 8365
Reputacja postu: 
5
Napiwki za post: 0 BTC
Lokalizacja: Trójmiasto

BitcoinSV.pl - potencjał & spekulacja & rozwój projektu & aplikacja - Wszystko o BSV

Postautor: socjolog2008 » środa, 27 lipca 2022, 00:38

Czy ja dobrze widzę ;) Bitcoin.pl promuje konferencje organizowaną przez środowisko BSV 8-)
https://bitcoin.pl/banking-unblockchained

Weteran
Posty: 2427
Rejestracja: 21 marca 2014
Reputacja: 1428
Reputacja postu: 
0
Napiwki za post: 0 BTC

BitcoinSV.pl - potencjał & spekulacja & rozwój projektu & aplikacja - Wszystko o BSV

Postautor: The Real McCoin » środa, 27 lipca 2022, 17:19

zdch pisze: poniedziałek, 25 lipca 2022, 19:22@The Real McCoin Charlie Lee to twój autorytet?

Pisałem już o autorytetach, ale chyba nie czytałeś:

The Real McCoin pisze: piątek, 17 czerwca 2022, 13:38
bitup pisze: środa, 15 czerwca 2022, 09:15Ja czy ty na pewnie nie byliśmy w dniu powstania BTC w temacie , natomiast były osoby uchodzące dziś za autorytety
Kryptowaluty korzystają z kryptografii po to by nie trzeba było wierzyć na słowo.


Oficjalny przedstawiciel projektu
Awatar użytkownika
Posty: 1032
Rejestracja: 20 stycznia 2017
Reputacja: 1245
Reputacja postu: 
0
Napiwki za post: 0 BTC
Napiwki: https://ftx.com/#a=BitcoinSV
Napiwki: https://www.coinex.com/register?refer_code=bthm3

BitcoinSV.pl - potencjał & spekulacja & rozwój projektu & aplikacja - Wszystko o BSV

Postautor: bitup » środa, 27 lipca 2022, 20:32



Oficjalny przedstawiciel projektu
Awatar użytkownika
Posty: 1032
Rejestracja: 20 stycznia 2017
Reputacja: 1245
Reputacja postu: 
0
Napiwki za post: 0 BTC
Napiwki: https://ftx.com/#a=BitcoinSV
Napiwki: https://www.coinex.com/register?refer_code=bthm3

BitcoinSV.pl - potencjał & spekulacja & rozwój projektu & aplikacja - Wszystko o BSV

Postautor: bitup » czwartek, 28 lipca 2022, 12:49


Oficjalny przedstawiciel projektu
Awatar użytkownika
Posty: 1032
Rejestracja: 20 stycznia 2017
Reputacja: 1245
Reputacja postu: 
0
Napiwki za post: 0 BTC
Napiwki: https://ftx.com/#a=BitcoinSV
Napiwki: https://www.coinex.com/register?refer_code=bthm3

BitcoinSV.pl - potencjał & spekulacja & rozwój projektu & aplikacja - Wszystko o BSV

Postautor: bitup » piątek, 29 lipca 2022, 16:21




Weteran
Posty: 2427
Rejestracja: 21 marca 2014
Reputacja: 1428
Reputacja postu: 
1
Napiwki za post: 0 BTC

BitcoinSV.pl - potencjał & spekulacja & rozwój projektu & aplikacja - Wszystko o BSV

Postautor: The Real McCoin » poniedziałek, 1 sierpnia 2022, 17:03

Dzisiejszy hit internetu.
Big win dla Craiga :lol: :lol: :lol:
Sąd przyznał Faketoshiemu: £1 (słownie: jednego funta).



@bitup Craig już myśli o tym co sobie kupi?


Jest zrzutka dla Petera. Próbują zebrać jednego funta:




Jeszcze ze 140 milionów takich spraw i może Craig wyjdzie na zero :lol:

Oficjalny przedstawiciel projektu
Awatar użytkownika
Posty: 1032
Rejestracja: 20 stycznia 2017
Reputacja: 1245
Reputacja postu: 
0
Napiwki za post: 0 BTC
Napiwki: https://ftx.com/#a=BitcoinSV
Napiwki: https://www.coinex.com/register?refer_code=bthm3

BitcoinSV.pl - potencjał & spekulacja & rozwój projektu & aplikacja - Wszystko o BSV

Postautor: bitup » piątek, 5 sierpnia 2022, 18:52




Wróć do „Pozostałe”

Kto jest online

Użytkownicy przeglądający to forum: Obecnie na forum nie ma żadnego zarejestrowanego użytkownika i 2 gości