Bitcoin Miniscript

[qertoip]

Pieter Wuille, Andrew Poelstra, Sanket Kanjalkar opublikowali Miniscript - specyfikację i kompilator.

Miniscript to nowy język "smart kontraktów" dla Bitcoina.

Miniscript kompiluje się do starego Bitcoin Scriptu. Nie wymaga zatem żednego forka.

Miniscript ma na celu radykalne ułatwienie pisania "smart kontraktów" na czele z ich komponowalnością (jak w normalnym programowaniu). Dotychczas praktycznie nikt nie pisał w Bitcoin Script. Wykorzystywano jedynie kilka standardowych konstrukcji wypracowanych w pocie czoła.

Następny krok to zintegrowanie tego z portfelami (na czele z Bitcoin Core).

Przykładowy kod:

and(
  pk(A),
  or(
    pk(B),
    or(
      pk(C),
      older(1000)
    )
  )
)

http://bitcoin.sipa.be/miniscript/

[maky]

Przykładowy kod:

and(
pk(A),
or(
pk(B),
or(
pk(C),
older(1000)
)
)
)

Świetnie. To jeszcze w dwóch słowach co ten kod robi. ;P

[qertoip]

Świetnie. To jeszcze w dwóch słowach co ten kod robi. ;P

Bitcoin Script / Miniscript określa pod jakim warunkiem unspent output może być wydany.

and(
  pk(A),
  or(
    pk(B),
    or(
      pk(C),
      older(1000)
    )
  )
)

Ten skrypt mówi, że:

- zawsze będzie potrzebny podpis kluczem A
- oraz dodatkowo, zawsze będzie potrzebny drugi składnik

teraz

- ten drugi składnik może być podpisem kluczem B
- lub może być podpisem kluczem C
- lub minęło 1000 bloków odkąd ten unspent output został potwierdzony

PS Piszę na szybko i na oko. Nie czytałem jeszcze tej specyfikacji.

[maky]

PS Piszę na szybko i na oko. Nie czytałem jeszcze tej specyfikacji.

Jest w linku. Zastanawiam się czemu nikt wcześniej tego nie zrobił?

[The Real McCoin]

Zastanawiam się czemu nikt wcześniej tego nie zrobił?

No bo jest stos - jest zabawa

[rav3n_pl]

Spoko.
Jeden detal.
Taki skrypt wydania jest traktowany jako "niestandardowy" i węzły domyślnie ich nie przekazują ani kopalnie nie kopią.
Więc.
Można zrobić, można wysłać na powstały adres, ale nie można go później wydać/wykonać.
NIE POLECAM TAKIEJ ZABAWY.
Smartkontraty na BTC daje nam Rootstock. Zostawmy Btc w spokoju.

[fusywszklanejkuli]

Taki skrypt wydania jest traktowany jako "niestandardowy" i węzły domyślnie ich nie przekazują ani kopalnie nie kopią.

Gwoli ścisłości, nie w przypadku redeem scriptu P2SH, który może być prawie dowolny, chyba że coś się zmieniło od wersji 0.11:

If you use anything besides a standard pubkey script in an output, peers and miners using the default Bitcoin Core settings will neither accept, broadcast, nor mine your transaction. When you try to broadcast your transaction to a peer running the default settings, you will receive an error.

If you create a redeem script, hash it, and use the hash in a P2SH output, the network sees only the hash, so it will accept the output as valid no matter what the redeem script says. This allows payment to non-standard scripts, and as of Bitcoin Core 0.11, almost all valid redeem scripts can be spent. The exception is scripts that use unassigned NOP opcodes; these opcodes are reserved for future soft forks and can only be relayed or mined by nodes that don’t follow the standard mempool policy.

Zresztą, wprowadzenie do Miniscriptu wskazuje o jakie skrypty chodzi:

For now, Miniscript is really only designed for P2WSH and P2SH-P2WSH embedded scripts. Most of its constructions works fine in P2SH as well, but some of the (optional) security properties rely on Segwit-specific rules. Furthermore, the implemented policy compilers assume a Segwit-specific cost model.

[rav3n_pl]

Mylisz sprawy.

Tworząc kontrakt piszesz skrypt WYDANIA, który ma być zrealizowany.
Adres na który wysyłasz środki będące przedmiotem kontraktu powstaje z hasza tego skryptu.
Tak więc w momencie WYSYŁANIA środków skrypt wydania nie jest znany i sieci to wisi - bo nie musi nic dziwnego robić. Po prostu wysyła środki na adres p2sh.
Cyrk zaczyna się przy WYDAWANIU środków z tego adresu - czyli przy realizacji kontraktu.
Taka transakcja musi zawierać cały skrypt oraz wymagane podpisy i co tam w nim zapisaleś. I tu jest haczyk - taka transakcja jest transakcja NIESTANDARDOWĄ ponieważ wszystkie skrypty wydania nie ujęte w kodzie (czyli multisig, timelock i kilka innych) są traktowane jako "szkodliwe/niebezpieczne" i węzły domyślnie ich nie realizują, nie przekazują i nie kopią.
Więc taka transakcja wydania nie jest propagowana w sieci i nie ma szans na zatwierdzenie. Chyba, że masz wtykę w kopalni która to realizuje (miał tak niektóre węzły P2Pool i chyba Slush?).

[randomowy świeżak]

W ostatnim wywiadzie Pieter Wuille zapowiadał że poza Taproot, schnorr czy mast chce mocno skupić się na miniscriptach. Ma to sens w sumie bo jak zbierze się to wszystko razem do kupy to będzie można skonstruować niewyobrażalnie złożone kontrakty a i tak ujawniony do wydania zostanie tylko jeden który akurat się zrealizował i nie będzie to dodatkowo obciążać sieci.

[rav3n_pl]

Ale... po co?
Jest Rootstock z prawdziwymi kontraktami. Nie jakieś mini-kobinacje.
Skalowanie w bok jest lepsze.

[fusywszklanejkuli]

@rav3n_pl, gdyby było jak piszesz, dowolność redeem scriptu byłaby bezużyteczna, ponieważ i tak nie można by wydać środków. W cytacie z mojego posta jest tymczasem czarno na białym: This allows payment to non-standard scripts, and as of Bitcoin Core 0.11, almost all valid redeem scripts can be spent.

Ponadto, Pieter Wuille pół roku temu zapytany o niestandardową transakcję odpowiedział: Such a script is perfectly standard as long as you wrap it in P2SH or P2WSH (in other words, send coins to the P2SH script that contains the hash of your script; when spending, reveal the full script and the inputs necessary to satisfy it).

Pierwotna specyfikacja P2SH rzeczywiście mówiła o standardowości samego redeem scriptu: Transactions that redeem these pay-to-script outpoints are only considered standard if the serialized script - also referred to as the redeemScript - is, itself, one of the other standard transaction types. Najwyraźniej ten warunek został zniesiony w nowszych wersjach. A konkretnie, wtedy kiedy zaimplementowano #4365; później poprawiono też dokumentację.

[rav3n_pl]

Masz rację. Przegapiłem. O_o
Limitem jest obecnie (od v11 lol) 15 operacji weryfikacji podpisów. No i skrypt może mieć maksymalnie 520 bajtów.
Cudów się nie zmieści.
Ten gist opisuje cała zmianę

[randomowy świeżak]

Limitem jest obecnie (od v11 lol) 15 operacji weryfikacji podpisów

czy jesteś pewien ?

https://www.whatbitcoindid.com/podcast/ ... ng-bitcoin

Nie pamiętam w którym dokładnie momencie ale Pieter opowiada tu nad czym obecnie się skupia co robi itd. Mówi on również iż multisig z 100 podpisów również jest jak najbardziej realny ale mało jest ludzi którzy są w ogóle w stanie nad tym pracować.

[fusywszklanejkuli]

Dla P2SH limit 15 wynika bezpośrednio z limitu 520, jak czytamy w pierwotnej specyfikacji:

Thus it is not possible to spend a P2SH output if the redemption script it refers to is >520 bytes in length. For instance while the OP_CHECKMULTISIG opcode can itself accept up to 20 pubkeys, with 33-byte compressed pubkeys it is only possible to spend a P2SH output requiring a maximum of 15 pubkeys to redeem: 3 bytes + 15 pubkeys * 34 bytes/pubkey = 513 bytes.

To się na pewno nie zmieniło, bo kod ciągle wykorzystuje stałą MAX_P2SH_SIGOPS.

Z kolei SegWitowa P2WSH ma własne reguły standardowości i ograniczenia, nie chciałbym się jednak w to szczególnie wgłębiać poza stwierdzeniem, że bez wątpienia wolno więcej; choćby sam rozmiar skryptu P2WSH: reguły konsensusu pozwalają na <=10000 bajtów, reguły standardowości na <=3600 (MAX_STANDARD_P2WSH_SCRIPT_SIZE), podczas gdy P2SH - <=520.

Zgaduję, że Wuille mógł rzucić tego multisiga ze 100 podpisami, bo 3 bytes + x bytes + 100 pubkeys * 34 bytes/pubkey = 3403 bytes + x bytes < 3600 bajtów standardowego limitu P2WSH, gdzie x to kilka(naście) dodatkowych bajtów, bo 100 sprawia pewne kłopoty.

[fervi]

A co sądzicie o Rootstocku itd.

Bo pytałem się na reddit ETH jakie są fajne projekty na tej platformie
W sumie to nie ma żadnych pomjając usprawnienia ETH. Chodziło mi o te wszystkie dAppsy i ich nie ma - głównie kasyna i rozwiązania DeFi, które zastępują Bitmeksa

[rav3n_pl]

Rootstock ciągle nie ma powodzenia bo ludzie nie ufają federacyjnej wymianie btc-rsk
Kontrakty można pisać identycznie jak na eth/etc
Nie jestem tylko pewien, czy się opłaca - nie analizowałem kosztów gas w rsk.

[redbog]

Rootstock ciągle nie ma powodzenia bo ludzie nie ufają federacyjnej wymianie btc-rsk

Jeśli tak jest to dobrze ze nie ufają, mają racje. Natomiast mi się wydaje ze brak zaufania nie jest tym co ludzi powstrzymuje od rsk bo jakoś ci sami ludzie nie mają niesrety problemu z zaufaniem dla giełdy i korzystaniu z niej jako portfela.
Rsk nie jest nośnym tematem nie ma tutaj euforii i nikt nie widzi jak można na tym zarobić i to jest moim zdaniem główna przyczyna niepowodzenia rsk. Może to i dobrze nie ma sensu kibicować scentralizowanym rozwiązaniom.

[fervi]

Rootstock ciągle nie ma powodzenia bo ludzie nie ufają federacyjnej wymianie btc-rsk

Ok, bo źle napisałem. Nie do końca mi chodzi o to co zrobić z RSK, tylko jakie są ciekawe projekty na Ethereum (i ostatecznie RSK), które są typowymi dAppsami. Bo jest opinia, że Smart contracty to nowa technologia, ETH master race. Ale potem się zapytałem jakie są ciekawe dAppsy napisane na Ethereum i już ludzie nie wiedzą.

Bo weźmy DEX - fajna idea, ale do tego nie trzeba Smart Contratów (Bisq), ludzie polecają DeFi jako system grania a'la Bitmex (coś w rodzaju pożyczasz pieniądze do grania i jak ci się poszczęści to zarobisz, a jak nie poszczęści to stracisz ). Sam myślałem, że DeFi to zdecentralizowany system zastępujący usługi bankowe, ale nie.

Może to i dobrze nie ma sensu kibicować scentralizowanym rozwiązaniom.

A RSK jest scentralizowane? Bo w sumie nie wiem, można własny węzeł postawić. Pytanie czy taki węzeł jest bezpieczny i weryfikuje sieć czy to taka prowizorka

[redbog]

A RSK jest scentralizowane?

Nie wiem jaka jest sytuacja biezaca bo docelowo miał niby dążyć żeby był zdecentralizowany (na nie do końca jasnych dla mnie zasadach). Natomiast tymczasowo został oparty na reputacji kilku podmiotów(chyba kilku a moze jednego?) i ten stan chyba trwa do dzis wiec trzeba im zaufać żeby korzystać z rsk,

Rsk jest lub ma być docelowo sidechainem. Nie wiem czy się nie myle ale chyba do tej pory jeszcze nie powstał zaden zdecentralizowany sidechain lub bardziej należałoby mówić niewymagający zaufania lub non custodial.

[fusywszklanejkuli]

Ale potem się zapytałem jakie są ciekawe dAppsy napisane na Ethereum i już ludzie nie wiedzą.

[Z przymrużeniem oka, choć prawdy niestety więcej, niż byśmy chcieli.] Lata mijają, a killer dAppki ani widu, ani słychu. [Głosem Shadowa] My, early adopterzy, już w trakcie bańki ICO mówiliśmy, że ten cały blockchain to przereklamowany pic. Coś się zmienia? Nie sądzę.