Tento týden přinášíme odkaz na návrh specifikací spojených s taprootovými aktivy a souhrn několika alternativních protokolů, které umožní LN začít používat PTLC. Též nechybí naše pravidelné rubriky se souhrnem sezení Bitcoin Core PR Review Club, oznámeními o nových softwarových vydáních a popisem významných změn v populárním bitcoinovém páteřním software.

Novinky

  • Specifikace Taproot Assets: Olaoluwa Osuntokun zaslal do emailových skupin Bitcoin-Dev a Lightning-Dev dva oddělené příspěvky o protokolu validujícím na straně klienta Taproot Assets. Ve skupině Bitcoin-Dev ohlásil sedm návrhů na BIP (o jeden více než při prvním oznámení protokolu, tehdy pod názvem Taro; viz. zpravodaj č. 195, angl.). Ve skupině Lightning-Dev potom ohlásil návrh BLIPu pro posílání a přijímání taprootových aktiv přes LN pomocí protokolu založeném na experimentálních „jednoduchých taprootových kanálech” plánovaných pro LND 0.17.0-beta.

    I přes svůj název nejsou Taproot Assets součástí bitcoinového protokolu a žádným způsobem nemění protokol konsenzu. Použitím stávajících vlastností poskytuje nové funkce uživatelům, kteří mají zájem.

    Specifikace neobdržely v době psaní žádné komentáře.

  • Změny v LN určené pro PTLC: s blížícím se vydáním první LN implementace s experimentální podporou kanálů používajících P2TR a MuSig2 zaslal Greg Sanders do emailové skupiny Lightning-Dev příspěvek se souhrnem úprav LN zpráv, které by umožnily zasílání plateb pomocí PTLC namísto HTLC. Většinou se změny nezdají být příliš rozsáhlé či invazivní, poznamenáváme však, že většina implementací bude pravděpodobně nadále používat jednu sadu zpráv pro přeposílání obstarožních HTLC a jinou sadu pro přeposílání PTLC. Budou tedy obsahovat dvě odlišné cesty, které budou muset být udržované až do vyřazení HTLC. Pokud by některá z implementací přidala experimentální podporu PTLC ještě před standardizací zpráv, musely by – ke škodě všech – implementace podporovat dokonce tři či více různých protokolů najednou.

    Sandersův souhrn neobdržel v době psaní žádné komentáře.

Bitcoin Core PR Review Club

V této měsíční rubrice shrnujeme nedávné sezení Bitcoin Core PR Review Club a vyzdvihujeme některé z důležitých otázek a odpovědí. Klikněte na otázku a odpověď se vám odhalí.

Abstrakce přenosu je PR od Pietera Wuilleho (sipa), které bylo nedávno začleněno a které přináší abstraktní třídu pro transport dat. Konkrétní implementace této abstraktní třídy přeměňují serializované zprávy z a na přenosový formát. Můžeme si to představit jako implementaci nižší úrovně serializace a deserializace. Tyto třídy neprovádí samotné posílání a přijímání.

PR též přináší dvě implementace třídy Transport: V1Transport (současný stav) a V2Transport (šifrovaný přenos) a je součástí projektu P2P šifrovaného transportního protokolu verze 2 dle BIP324.

  • Jaký je rozdíl mezi net a net_processing?

    Net je zcela naspodu síťového rozhraní a má na starosti nízkoúrovňovou komunikaci mezi spojeními. Nad ním je postaven net_processing, který zprávy validuje a dále zpracovává. 

  • Jmenujte příklady tříd nebo funkcí, které jsou spojeny s net a net_processing.

    net_processing: PeerManager, ProcessMessage. net: CNode, ReceiveMsgBytes, CConnMan

  • Vyžaduje BIP324 změny na net vrstvě, net_processing vrstvě či obou? Má dopad na pravidla či konsenzus?

    Změny jsou pouze na net vrstvě. Nemají žádný dopad na konsenzus. 

  • Jaké jsou příklady implementačních chyb, které by mohly vyústit v nezamýšlenou změnu konsenzu?

    Chyba, která omezuje nejvyšší velikost zprávy na méně než 4 MB, což by mělo za následek odmítání bloků validních podle jiných uzlů. Chyba v deserializiaci bloku, která by způsobila odmítání validních bloků. 

  • CNetMsgMaker i Transport “serializují” zprávy. Jaký je rozdíl mezi těmi dvěma?

    CNetMsgMaker provádí serializaci datových struktur do bytů. Transport obdrží tyto byty, přidá (serializuje) hlavičku a odešle. 

  • Co se děje během převodu objektů jako CTransactionRef (transakce) do bytů či síťových paketů? Do jakých datových struktur jsou převáděny?

    msgMaker.Make() serializuje zprávu CTransactionRef voláním SerializeTransaction(), poté PushMessage() umístí serializovanou zprávu do fronty vSendMsg, potom SocketSendData() přidá hlavičku a kontrolní součet (po tomto PR) a požádá transport o odeslání dalšího paketu. Nakonec zavolá m_sock->Send()

  • Kolik bytů je odesláno po síti zprávou sendtxrcncl (berme tuto zprávu používanou v Erlay jako jednoduchý příklad)?

    36 bytů: 24 bytů je hlavička (4 pevné byty, příkaz 12 bytů, velikost zprávy 4 byty, kontrolní součet 4 byty) a 12 bytů tělo (verze 4 bytů, sůl 8 bytů). 

  • Jsou v době návratu z funkce PushMessage() odeslány již byty odpovídající této zprávě? Ano/ne/možná? Proč?

    Možné jsou všechny odpovědi. Ano: net_processing nemusí činit nic dalšího, aby se zpráva odeslala. Ne: je velice nepravděpodobné, že by příjemce zprávu obdržel ještě před návratem této funkce. Možná: jsou-li všechny fronty prázdné, byla zpráva již odeslána síťové vrstvě jádra; pokud však některé fronty prázdné nejsou, bude odeslání ještě čekat na uvolnění. 

  • Která vlákna mají přístup k CNode::vSendMsg?

    ThreadMessageHandler, pokud je zpráva odeslána synchronně („optimisticky”); ThreadSocketHandler, pokud je zařazena do fronty a odeslána později. 

Vydání nových verzí

Vydání nových verzí oblíbených páteřních bitcoinových projektů. Prosíme, zvažte upgrade či pomoc s testováním.

  • LND v0.17.0-beta.rc2 je kandidátem na vydání příští hlavní verze této oblíbené implementace LN uzlu. Velkou novou experimentální funkcí plánovanou pro toto vydání, které by prospělo testování, je podpora „jednoduchých taprootových kanálů.”

Významné změny v kódu a dokumentaci

Významné změny z tohoto týdne v Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs a Bitcoin Inquisition.

  • Bitcoin Core #26567 mění způsob, jakým peněženka odhaduje váhu podepsaného vstupu z deskriptoru. Původní přístup, který prováděl podepsání nanečisto, nebyl dostatečný pro některé složitější miniscriptové deskriptory.