Skip to content

Commit 4dfa8a4

Browse files
jirijakesbitschmidty
authored andcommitted
Newsletter-259: Add Czech translation
1 parent e9f6790 commit 4dfa8a4

File tree

3 files changed

+282
-0
lines changed

3 files changed

+282
-0
lines changed
Lines changed: 103 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,103 @@
1+
[Minulý příspěvek][policy08] popsal [anchor výstupy][topic anchor outputs] a [CPFP carve
2+
out][topic cpfp carve out] zajišťující, že kterákoliv strana kanálu může
3+
navýšit poplatek sdílené commitment transakce bez nutnosti spolupráce.
4+
Tento přístup stále obsahuje několik nevýhod: prostředky kanálu jsou svázané,
5+
aby mohly vytvořit anchor výstupy, jednotkový poplatek commitment transakce je
6+
většinou o trochu vyšší, aby byl vyšší než minimální poplatek mempoolu, a
7+
CPFP carve out povoluje pouze jednoho potomka navíc. Anchor výstupy nemohou
8+
zajistit podobnou dostupnost navýšení poplatků transakcí sdílených mezi více
9+
než dvěma stranami, jako je [coinjoin][topic coinjoin] nebo protokoly s více
10+
účastníky. Tento příspěvek zkoumá současné snahy adresovat tato i jiná omezení.
11+
12+
[Přeposílání balíčků][topic package relay] obsahuje P2P protokol a změny pravidel,
13+
které umožní transport a validaci skupin transakcí. Díky tomu by mohly být
14+
poplatky commitment transakcí navýšeny potomkem, i kdyby nesplňovaly požadavek
15+
minimálního jednotkového poplatku mempoolu. Dále by _RBF balíčku_ umožnilo
16+
potomkovi navyšujícímu poplatek zaplatit za [nahrazení][topic rbf] transakcí,
17+
se kterými jsou jeho rodiče v konfliktu. Přeposílání balíčků je navrženo tak,
18+
aby odstranilo obecná omezení na základní vrstvě protokolu. Avšak díky jeho
19+
použití pro navyšování poplatků sdílených transakcí byly na jeho základě
20+
představeny pokusy o eliminaci [pinningu][topic transaction pinning]
21+
v některých konkrétních případech. Například by RBF balíčku umožnil commitment
22+
transakcím nahrazení sebe navzájem, pokud by byly zveřejněny spolu se svými
23+
potomky navyšujícími poplatek. Díky tomu by nebylo potřeba mít v každé
24+
commitment transakci několik anchor výstupů.
25+
26+
Drobným zádrhelem je, že existující pravidla pro RBF vyžadují, aby nahrazující
27+
transakce platila vyšší absolutní poplatek než součet poplatků placených všemi
28+
nahrazovanými transakcemi. Toto pravidlo napomáhá prevenci odepření služby
29+
opakovanými nahrazeními, ale umožňuje záškodníkům zvýšit náklady na nahrazení
30+
transakce připojením potomka, který má vysoký poplatek, ale nízký jednotkový
31+
poplatek, což zamezuje transakci ve vytěžení. Tomuto druhu pinningu se často
32+
říká „pinning třetího pravidla.”
33+
34+
Vývojáři též navrhli zcela odlišné způsoby přidávání poplatků předem podepsaným
35+
transakcím. Například podepsání vstupů transakce s `SIGHASH_ANYONECANPAY | SIGHASH_ALL`
36+
by umožnilo odesílateli transakce poskytnout poplatek připojením dodatečných vstupů,
37+
avšak se zachováním výstupů. Jelikož však nemá RBF žádná pravidla vyžadující, aby
38+
měla nahrazující transakce vyšší „těžební skóre” (tj. byla by rychleji vybrána
39+
do bloku), mohl by útočník „přišpendlit” tento druh transakcí vytvořením
40+
nahrazení zatíženého předky s nízkými jednotkovými poplatky. Existující limity
41+
předků a potomků nejsou dostatečné, aby omezily výpočetní náročnost této
42+
kalkulace, což ztěžuje přesný odhad těžebního skóre transakcí a balíčků
43+
transakcí. Jakékoliv připojené transakce mohou ovlivnit pořadí, ve kterém jsou
44+
transakce vybírány do bloku. Komponenta, která je plně propojena (nazývající se
45+
_cluster_), může mít jakoukoliv velikost danou současnými limity předků a potomků.
46+
47+
Dlouhodobým řešením adresování některých nedostatků mempoolu a RBF pinning
48+
útoků je v mempoolu [předělat strukturu dat, aby se sledovaly clustery][mempool
49+
clustering] namísto pouhých množin předků a potomků. Tyto clustery by byly
50+
omezeny ve velikosti. Limity clusterů by omezily způsob, kterým by mohli uživatelé
51+
utrácet nepotvrzená UTXO, ale díky nim by mohl být celý mempool linearizován
52+
použitím těžebního algoritmu založeném na skóre předků, tvorba šablon bloků
53+
by byla extrémně rychlá a mohl by být přidán požadavek, aby nahrazující
54+
transakce měly vyšší těžební skóre než transakce, které chtějí nahradit.
55+
56+
I přesto je možné, že žádná jedna sada pravidel nemůže uspokojit širokou řadu
57+
potřeb a očekávání přeposílání transakcí. Například zatímco pro příjemce dávkové
58+
platby je výhodné, že mohou utratit své nepotvrzené výstupy, uvolněné limity
59+
potomků vytváří prostor pro pinning RBF balíčků sdílené transakce skrz
60+
absolutní poplatky. Návrh na [pravidla přeposílání v3 transakcí][topic v3 transaction
61+
relay] byl vyvinut, aby umožnil protokolům s kontrakty volitelně používat
62+
striktnější sadu limitů balíčků. V3 transakce by povolovaly pouze balíčky o velikosti
63+
dva (jeden předek, jeden potomek) a omezovaly váhu potomka. Tyto limity by
64+
zabraňovaly RBF pinningu skrz absolutní poplatky a nabídly by některé z výhod
65+
mempoolu clusterů bez nutnosti restrukturovat mempool.
66+
67+
[Ephemeral anchors][topic ephemeral anchors] dále vylepšují anchor výstupy na základě
68+
vlastností přeposílání v3 transakcí a balíčků. Anchor výstupy patřící v3 transakci
69+
s nulovým poplatkem budou mít výjimku z [limitu neutratitelnosti][topic
70+
uneconomical outputs] („dust limit”), pokud jsou utráceny potomkem navyšujícím
71+
poplatek. Jelikož transakce s nulovým poplatkem musí mít poplatek navýšený
72+
právě jedním potomkem (jinak by neměl těžař motivaci ji začlenit do bloku),
73+
je tento anchor výstup dočasný („ephemeral”) a nestane se součástí množiny UTXO.
74+
Tento návrh na ephemeral anchors implicitně zabraňuje neanchor výstupům, aby
75+
byly utraceny, dokud jsou nepotvrzené a nemají `1 OP_CSV` časové zámky, neboť
76+
potomek musí tento anchor výstup utratit. Díky tomu by také byl proveditelný
77+
[LN symmetry][topic eltoo] (eltoo), který by mohl využít [CPFP][topic cpfp]
78+
jako mechanismu poskytování poplatků transakcím uzavírajícím kanál. Dále by
79+
mohl být tento mechanismus použit u transakcí sdílených mezi více než dvěma
80+
účastníky. Vývojáři používají k nasazení ephemeral anchors a navrhovaných soft
81+
forků [bitcoin-inquisition][bitcoin inquisition repo], v jehož rámci budují
82+
a testují tyto změny na [signetu][topic signet].
83+
84+
Problém pinningu, popsaný mimo jiné v tomto příspěvku, stál loni za [množstvím
85+
diskuzí a návrhů vylepšení pravidel RBF][2022 rbf] v emailových skupinách,
86+
pull requestech, sociálních médiích a při osobních setkáních. Vývojáři navrhli
87+
a implementovali řešení v různých škálách, od malých úprav až po kompletní
88+
předělání. Volba `-mempoolfullrbf`, jejímž účelem je potýkat se s problémem
89+
pinningu a nesouladem v BIP125 implementacích, nám připomenula náročnost
90+
a důležitost spolupráce v rámci pravidel přeposílání transakcí. A i když byly
91+
upřímné snahy o zapojení komunity použitím obvyklých prostředků včetně konverzace
92+
v emailové skupině Bitcoin-Dev rok dopředu, bylo zřejmé, že existující způsoby
93+
komunikace a rozhodování nevyústily v zamýšlený výsledek a potřebovaly
94+
doladit.
95+
96+
Decentralizované rozhodování je náročným, ale nezbytným procesem v podpoře
97+
různorodého ekosystému protokolů a aplikací, které používají bitcoinovou síť.
98+
Příští týden bude náš poslední příspěvek v této sérii, ve kterém, doufáme,
99+
se nám podaří zapojit čtenáře a zlepšit tento proces.
100+
101+
[mempool clustering]: https://github.com/bitcoin/bitcoin/issues/27677
102+
[policy08]: /cs/newsletters/2023/07/05/#čekání-na-potvrzení-8-pravidla-jako-rozhraní
103+
[2022 rbf]: /en/newsletters/2022/12/21/#rbf

_posts/cs/2023-05-17-policy.md

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -76,6 +76,12 @@ h2:not(:first-of-type) { margin-top: 3em; }
7676

7777
{% include specials/policy/cs/08-interface.md %}
7878

79+
## Návrhy pravidel
80+
81+
*Původně vyšlo ve [zpravodaji č. 259](/cs/newsletters/2023/07/12/#čekání-na-potvrzení-9-návrhy-pravidel)*
82+
83+
{% include specials/policy/cs/09-proposals.md %}
84+
7985
{% comment %}<!--
8086
## Footnotes
8187
{:.no_toc}
Lines changed: 173 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,173 @@
1+
---
2+
title: 'Zpravodaj „Bitcoin Optech” č. 259'
3+
permalink: /cs/newsletters/2023/07/12/
4+
name: 2023-07-12-newsletter-cs
5+
slug: 2023-07-12-newsletter-cs
6+
type: newsletter
7+
layout: newsletter
8+
lang: cs
9+
---
10+
Tento týden popisujeme návrh na odstranění některých drobností ze specifikace LN,
11+
které již nejsou relevantní, a přinášíme předposlední část naší krátké týdenní
12+
série o pravidlech mempoolu. Též nechybí naše pravidelné rubriky se souhrnem
13+
sezení Bitcoin Core PR Review Club, oznámeními o nových vydáních a kandidátech
14+
na vydání a popisem významných změn v populárních bitcoinových páteřních
15+
projektech.
16+
17+
## Novinky
18+
19+
- **Návrh na pročištění specifikace LN:** Rusty Russell zaslal do emailové
20+
skupiny Lightning-Dev [příspěvek][russell clean up] s odkazem na
21+
[PR][bolts #1092], ve kterém navrhuje odstranit některé funkce, které již
22+
nejsou podporovány v moderních implementacích LN, a ponechané funkce
23+
označit jako navždy podporované. Russell dále poskytl výsledky svého výzkumu
24+
podporovaných funkcí veřejnými uzly dle jejich gossip zpráv. Výsledky
25+
naznačují, že téměř všechny uzly podporují následující funkce:
26+
27+
- *Onion zprávy s proměnlivou velikostí:* součástí specifikace jsou od
28+
roku 2019 (viz [zpravodaj č. 58][news58 bolts619], *angl.*), tedy od doby,
29+
kdy byly také představeny Type-Length-Value (TLV) pole. Tím byl nahrazen
30+
původní formát šifrovaného onion routingu, který vyžadoval použití
31+
zpráv o pevné délce a omezoval počet skoků na 20. Díky formátu s proměnlivou
32+
velikostí je snazší přeposílat konkrétním skokům libovolná data. Jedinou
33+
nevýhodou je, že celková velikost zprávy zůstává konstantní, čili nárůst
34+
v objemu posílaných dat snižuje maximální počet skoků.
35+
36+
- *Gossip dotazy:* součástí specifikace od roku 2018 (viz [BOLTs #392][]).
37+
Umožňují uzlu vyžádat od svých spojení pouze podmnožinu gossip zpráv
38+
poslaných jinými uzly v síti. Uzel může vyžádat například pouze nejnovější
39+
aktualizace a ignorovat starší, čímž ušetří na datovém přenosu a čase
40+
zpracování.
41+
42+
- *Ochrana před ztrátou dat:* součástí specifikace od roku 2017 (viz
43+
[BOLTs #240][]). Uzly používající tuto funkci posílají před novým připojením
44+
informace o svém posledním stavu kanálu. Díky tomu může uzel detekovat,
45+
že přišel o data. Dále nabádá uzel, který o data nepřišel, aby kanál uzavřel
46+
ve svém posledním stavu. Viz [zpravodaj č. 31][news31 data loss] (*angl.*)
47+
pro další informace.
48+
49+
- *Statické klíče vzdálené strany:* součástí specifikace od roku 2019
50+
(viz [zpravodaj č. 67][news67 bolts642], *angl.*), umožňují uzlu požadovat,
51+
aby každý channel update zavazoval k posílání ne[HTLC][topic htlc] prostředků
52+
na stejnou adresu. Předtím mohla být v každém channel update použita jiná
53+
adresa. Po této změně uzel, který používá tento protokol a ztratí
54+
data, nakonec téměř vždy obdrží alespoň část svých prostředků na zvolenou
55+
adresu, jako je například adresa v [HD peněžence][topic bip32].
56+
57+
První odpovědi k návrhu na pročištění byly pozitivní.
58+
59+
## Čekání na potvrzení 9: návrhy pravidel
60+
61+
_Krátká týdenní [série][policy series] o přeposílání transakcí, začleňování do mempoolu a výběru
62+
transakcí k těžbě včetně vysvětlení, proč má Bitcoin Core přísnější pravidla,
63+
než co je povoleno konsenzem, a jak mohou peněženky využít pravidla co nejefektivněji._
64+
65+
{% include specials/policy/cs/09-proposals.md %}
66+
67+
## Bitcoin Core PR Review Club
68+
69+
*V této měsíční rubrice shrnujeme nedávné sezení [Bitcoin Core PR Review Club][] a
70+
vyzdvihujeme některé z důležitých otázek a odpovědí. Klikněte na otázku a odpověď se vám odhalí.*
71+
72+
[Přestaň přeposílat transakce mimo mempool][review club 27625] je
73+
PR od Marca Falkeho (MarcoFalke) zjednodušující klienta Bitcoin Core
74+
odstraněním paměťové datové struktury `mapRelay`, která může způsobit vysokou
75+
spotřebu paměti a není již více potřebná, respektive poskytuje pouze zcela
76+
okrajové benefity. Tato mapa obsahuje transakce, které mohou či nemusí být
77+
také v mempoolu. Někdy se používá pro generování odpovědi na požadavek
78+
[`getdata`][wiki getdata].
79+
80+
{% include functions/details-list.md
81+
q0="Jaké důvody stojí za odstraněním `mapRelay`?"
82+
a0="Spotřeba paměti této datové struktury je neomezená.
83+
I když v běžném případě nespotřebovává tolik paměti, je na pováženou,
84+
je-li velikost jakékoliv datové struktury určena chováním vnějších
85+
entit (spojení) a nemá žádné maximum. Takové případy mohou vnést DoS
86+
zranitelnosti."
87+
a0link="https://bitcoincore.reviews/27625#l-19"
88+
89+
q1="Proč je těžké určit spotřebu paměti `mapRelay`?"
90+
a1="Každý prvek v `mapRelay` je ukazatelem na transakci (`CTransaction`),
91+
který může být sdílen s mempoolem. Druhý ukazatel na stejný objekt
92+
používá velmi málo dodatečného prostoru v porovnání s jedním ukazatelem.
93+
Je-li sdílená transakce odstraněna z mempoolu, veškerý jeho použitý prostor lze
94+
připsat `mapRelay`. Čili spotřeba paměti `mapRelay` nezávisí pouze na počtu
95+
a velikosti transakcí, ale také na tom, kolik jeho transakcí již není
96+
v mempoolu. Toto není snadné dopředu určit."
97+
a1link="https://bitcoincore.reviews/27625#l-33"
98+
99+
q2="Jaký problém řeší přidaný `m_most_recent_block_txs`?
100+
(Toto je seznam pouze těch transakcí, které jsou v posledním obdrženém bloku.)"
101+
a2="Jelikož `mapRelay` není již k dispozici, nemohli bychom bez něj posílat
102+
právě vytěžené transakce (z posledního bloku) spojením, která o něj požádají.
103+
Tyto transakce již nejsou v našem mempoolu."
104+
a2link="https://bitcoincore.reviews/27625#l-45"
105+
106+
q3="Považujete za nezbytné přidávat `m_most_recent_block_txs`,
107+
či by bylo možné odstranit `mapRelay` bez náhrady?"
108+
a3="Mezi účastníky review klubu panovala u této otázky nejistota.
109+
Někdo navrhl, že by mohl `m_most_recent_block_txs` vylepšit rychlost
110+
propagace bloků, protože pokud naše spojení stále neobdrželo blok, který
111+
my jsme právě obdrželi, může schopnost našeho uzlu poskytnout své transakce
112+
pomoci zkompletovat našemu spojení [kompaktní blok][topic compact block relay].
113+
Jiný návrh byl, že může pomoci v případě chain splitu; pokud by naše spojení
114+
bylo na jiném chainu než my, možná obdrželo transakci jinak než z bloku."
115+
a3link="https://bitcoincore.reviews/27625#l-54"
116+
117+
q4="Jaké jsou paměťové požadavky `m_most_recent_block_txs` v porovnání s
118+
`mapRelay`?"
119+
a4="Počet položek v `m_most_recent_block_txs` je ohraničen počtem transakcí
120+
v bloku. Avšak paměťové požadavky jsou ještě menší, neboť položky v
121+
`m_most_recent_block_txs` jsou sdílené ukazatele na transakce, na které
122+
již ukazuje `m_most_recent_block`."
123+
a4link="https://bitcoincore.reviews/27625#l-65"
124+
125+
q5="Existují případy, ve kterých by v důsledku této změny byly transakce dostupné
126+
po kratší nebo delší dobu než předtím?"
127+
a5="Delší, pokud je doba od posledního bloku delší než 15 minut (což je čas, po
128+
který zůstávají položky uloženy v `mapRelay`), jinak kratší. To je
129+
přijatelné, neboť volba 15 minut byla spíše nahodilá. Avšak tato změna může
130+
snížit dostupnost transakcí v případě chain splitu hlubšího než jeden blok
131+
(ty jsou extrémně vzácné), protože neuchováváme transakce, které jsou obsaženy
132+
pouze v bloku, jež není v našem řetězci."
133+
a5link="https://bitcoincore.reviews/27625#l-70"
134+
%}
135+
136+
## Vydání nových verzí
137+
138+
*Vydání nových verzí oblíbených páteřních bitcoinových projektů. Prosíme,
139+
zvažte upgrade či pomoc s testováním.*
140+
141+
- [LND v0.16.4-beta][] je údržbovým vydáním tohoto uzlu, které opravuje
142+
memory leak postihující některé uživatele.
143+
144+
## Významné změny v kódu a dokumentaci
145+
146+
*Významné změny z tohoto týdne v [Bitcoin Core][bitcoin core repo], [Core
147+
Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo],
148+
[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet
149+
Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay
150+
Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement
151+
Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a
152+
[Bitcoin Inquisition][bitcoin inquisition repo].*
153+
154+
- [Bitcoin Core #27869][] zobrazuje během načítání zastaralé peněženky varování
155+
v rámci pokračující snahy popsané v [Bitcoin Core #20160][], jejímž cílem
156+
je pomoci uživatelům migrovat zastaralé peněženky na peněženky s
157+
[deskriptory][topic descriptors], jak bylo zmíněno ve zpravodajích [č. 125][news125
158+
descriptor wallets], [č. 172][news172 descriptor wallets] (oba *angl.*) a
159+
[č. 230][news230 descriptor wallets].
160+
161+
{% include references.md %}
162+
{% include linkers/issues.md v=2 issues="1092,392,240,20160,27869" %}
163+
[news58 bolts619]: /en/newsletters/2019/08/07/#bolts-619
164+
[policy series]: /cs/blog/waiting-for-confirmation/
165+
[news31 data loss]: /en/newsletters/2019/01/29/#fn:fn-data-loss-protect
166+
[news67 bolts642]: /en/newsletters/2019/10/09/#bolts-642
167+
[lnd v0.16.4-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.16.4-beta
168+
[russell clean up]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-June/004001.html
169+
[review club 27625]: https://bitcoincore.reviews/27625
170+
[wiki getdata]: https://en.bitcoin.it/wiki/Protocol_documentation#getdata
171+
[news125 descriptor wallets]: /en/newsletters/2020/11/25/#how-will-the-migration-tool-from-a-bitcoin-core-legacy-wallet-to-a-descriptor-wallet-work
172+
[news172 descriptor wallets]: /en/newsletters/2021/10/27/#bitcoin-core-23002
173+
[news230 descriptor wallets]: /cs/newsletters/2022/12/14/#bude-bitcoin-core-moci-podepisovat-zpravy-i-se-zastaralymi-penezenkami

0 commit comments

Comments
 (0)