diff --git a/_layouts/topic.html b/_layouts/topic.html index b41bc1d5ff..a3b4dd4325 100644 --- a/_layouts/topic.html +++ b/_layouts/topic.html @@ -21,11 +21,11 @@ {% endfor %} - {% if page.aliases != nil %} - {% assign num_aliases = page.aliases | size %} + {% if page.title-aliases != nil %} + {% assign num_aliases = page.title-aliases | size %} {% capture aliases %}{:.center}{{newline}}*Also covering {% endcapture %} {% if num_aliases > 2 %} - {% for alias in page.aliases %} + {% for alias in page.title-aliases %} {% if forloop.last %} {% capture aliases %}{{aliases}}, and {{alias}}{% endcapture %} {% elsif forloop.first %} @@ -35,7 +35,7 @@ {% endif %} {% endfor %} {% else %} - {% capture aliases %}{{aliases}}{{page.aliases | join: ' and '}}{% endcapture %} + {% capture aliases %}{{aliases}}{{page.title-aliases | join: ' and '}}{% endcapture %} {% endif %} {% assign aliases = aliases | append: '*' %} {% endif %} @@ -124,8 +124,16 @@ {% endif %}
{{newline}}{{newline}} -**Previous Topic:**
{{prev_link}} -**Next Topic:**
{{next_link | default: first_link }} +

+ +**Previous Topic:**
{{prev_link}} + +

+

+ +**Next Topic:**
{{next_link | default: first_link }} + +

{:.center} [Edit page]({{gh_base}}/edit/master/{{page.path}})
diff --git a/_posts/cs/2024-10-10-wallet-integration-guide.md b/_posts/cs/2024-10-10-wallet-integration-guide.md new file mode 100644 index 0000000000..34b2d32191 --- /dev/null +++ b/_posts/cs/2024-10-10-wallet-integration-guide.md @@ -0,0 +1,620 @@ +--- +title: "Průvodce pro peněženky využívající pravidla Bitcoin Core 28.0" +permalink: /cs/bitcoin-core-28-wallet-integration-guide/ +name: 2024-10-10-bitcoin-core-28-wallet-integration-guide-cs +type: posts +layout: post +lang: cs +slug: 2024-10-10-bitcoin-core-28-wallet-integration-guide-cs + +excerpt: > + Bitcoin Core 28.0 přináší nová pravidla pro P2P a mempool, která mohou být užitečná pro rozličné druhy peněženek a transakcí. Gregory Sanders v tomto průvodci nahlíží na tato pravidla a ukazuje příklady jejich použití. + +--- + +{:.post-meta} +*napsal [Gregory Sanders][]* + +[Bitcoin Core 28.0][bc 28.0] přináší [nová][bc 28.0 release notes] pravidla pro P2P +a mempool, která mohou být užitečná pro rozličné druhy peněženek a transakcí. Gregory +Sanders v tomto průvodci nahlíží na tato pravidla a ukazuje příklady jejich použití. + +## Přeposílání balíčků s jedním rodičem a jedním potomkem (1P1C) + +Aby byla před Bitcoin Core 28.0 transakce přidána do jeho mempoolu, musel se její +jednotkový poplatek rovnat či převýšit aktuální minimální jednotkový poplatek mempoolu. +Tato hodnota se zvyšuje či snižuje dle aktuálního zatížení, což způsobuje kolísání +minimální hodnoty potřebné pro propagaci platby. To přináší těžkosti peněženkám, +které se potýkají s předem podepsanými transakcemi a kterým nemohou podepsat +[nahrazení pomocí RBF][topic rbf]. Musí proto předpovídat budoucí poplatky, aby +v potřebný čas dosáhly potvrzení transakce. Jedná se o náročný úkol i v řádu minut, +v několikaměsíčním horizontu je zcela neřešitelný. + +[Přeposílání balíčků][topic package relay] je dlouho očekávaná funkce, která odstraní +riziko zaseknutí transakce bez možnosti navýšit její poplatek. Po řádném vývoji +a širokém nasazení v síti umožní přeposílání balíčků vývojářům peněženek navýšit +poplatek transakce pomocí jiné, související transakce. Díky tomu bude mít předek +s nízkým poplatkem možnost dostat se do mempoolu. + +V Bitcoin Core 28.0 byla implementována omezená varianta přeposílání balíčků týkající +se pouze balíčků s jedním rodičem a jedním potomkem (one parent one child, 1P1C). +1P1C umožňuje jednomu rodiči dostat se do mempoolu bez ohledu na proměnlivý minimální +jednotkový poplatek mempoolu. Využívá k tomu jediného potomka a jednoduché navýšení +poplatku pomocí [Child Pays For Parent (CPFP)][topic cpfp]. Má-li potomek další +nepotvrzené předky, nebude se úspěšně šířit. Toto omezení výrazně zjednodušuje +implementaci a umožňuje nerušeně pokračovat v další práci na mempoolu (např. na +[cluster mempoolu][topic cluster mempool]). + +Každá transakce kromě [TRUC transakcí][topic v3 transaction relay] (viz níže) +musí i nadále splňovat podmínku minimálního poplatku jednoho satoshi na virtuální +bajt. + +Dalším omezením je, že garance šíření jsou u této verze omezené. Je-li uzel +Bitcoin Core připojen k dostatečně motivovanému nepříteli, může narušit propagaci +tohoto rodiče a jeho potomka. Pokračující práce na [projektu][package relay tracking issue] +učiní přeposílání balíčků robustnějším. + +Obecné přeposílání balíčků bude přidáno v budoucnosti. K jeho vývoji se využijí data +z nasazení této omezené formy. + +Následují příkazy pro nastavení peněženky za účelem demonstrace přeposílání 1P1C +v regtestu: + +```hack +bitcoin-cli -regtest createwallet test +{ + "name": "test" +} +``` + +```hack +# Načti adresu pro příjem +bitcoin-cli -regtest -rpcwallet=test getnewaddress +bcrt1qqzv3ekkueheseddqge3mqdcukse6p9d5yuqxv3 +``` + +```hack +# Vytvoř transakci s nízkým poplatkem převyšujícím "minrelay" +bitcoin-cli -regtest -rpcwallet=test -generate 101 +{ + [ + ... + ] +} + +bitcoin-cli -regtest -rpcwallet=test listunspent +[ + { + "txid": "49ea7a01bcba744bd82ecea3e36c4ee9a994f010508a28a09df38f652e74643b", + "vout": 0, + ... + "amount": 50.00000000, + ... + } +] + +# Minfee a minrelay mempoolu jsou shodné. Pro snadnější otestování funkce +# použijeme TRUC transakce, aby bylo možné mít transakce s nulovým poplatkem +# vyžadující 1P1C přeposílání. Fullrbf je též aktivní (výchozí v 28.0). +bitcoin-cli -regtest getmempoolinfo +{ + "loaded": true, + ... + "mempoolminfee": 0.00001000, + "minrelaytxfee": 0.00001000, + ... + "fullrbf": true, +} + +# Začněme s v2 transakcí +bitcoin-cli -regtest createrawtransaction '[{"txid": "49ea7a01bcba744bd82ecea3e36c4ee9a994f010508a28a09df38f652e74643b", "vout": 0}]' '[{"bcrt1qqzv3ekkueheseddqge3mqdcukse6p9d5yuqxv3": "50.00000000"}]' + +02000000013b64742e658ff39da0288a5010f094a9e94e6ce3a3ce2ed84b74babc017aea490000000000fdffffff01f90295000000000016001400991cdadccdf30cb5a04663b0371cb433a095b400000000 + +# Nahraďme úvodní 02 hodnotou 03, což je verze TRUC +03000000013b64742e658ff39da0288a5010f094a9e94e6ce3a3ce2ed84b74babc017aea490000000000fdffffff01f90295000000000016001400991cdadccdf30cb5a04663b0371cb433a095b400000000 + +# Podepiš a odešli +bitcoin-cli -regtest -rpcwallet=test signrawtransactionwithwallet 03000000013b64742e658ff39da0288a5010f094a9e94e6ce3a3ce2ed84b74babc017aea490000000000fdffffff01f90295000000000016001400991cdadccdf30cb5a04663b0371cb433a095b400000000 +{ + "hex": "030000000001013b64742e658ff39da0288a5010f094a9e94e6ce3a3ce2ed84b74babc017aea490000000000fdffffff01f90295000000000016001400991cdadccdf30cb5a04663b0371cb433a095b40247304402200a82f2fd8aa5f32cdfd9540209ccfc36a95eea21518ede1c3787561c8fb7269702207a258e6f027ce156271879c38628ad9b3425b83c33d8cd95fb20dd3c567fdff70121030af1fadce80bcb8ba614634bc82c71eea2ed87a5692d3127766cc896cef1bdb100000000", + "complete": true +} + +bitcoin-cli -regtest sendrawtransaction 030000000001013b64742e658ff39da0288a5010f094a9e94e6ce3a3ce2ed84b74babc017aea490000000000fdffffff01f90295000000000016001400991cdadccdf30cb5a04663b0371cb433a095b40247304402200a82f2fd8aa5f32cdfd9540209ccfc36a95eea21518ede1c3787561c8fb7269702207a258e6f027ce156271879c38628ad9b3425b83c33d8cd95fb20dd3c567fdff70121030af1fadce80bcb8ba614634bc82c71eea2ed87a5692d3127766cc896cef1bdb100000000 + +# Chyba: minimální poplatek přeposílání nebyl naplněn, 0 < 110 +error code: -26 +error message: +min relay fee not met, 0 < 110 + +# Potřebujeme přeposlat jako balíček a navýšit pomocí CPFP +bitcoin-cli -regtest decoderawtransaction 030000000001013b64742e658ff39da0288a5010f094a9e94e6ce3a3ce2ed84b74babc017aea490000000000fdffffff01f90295000000000016001400991cdadccdf30cb5a04663b0371cb433a095b40247304402200a82f2fd8aa5f32cdfd9540209ccfc36a95eea21518ede1c3787561c8fb7269702207a258e6f027ce156271879c38628ad9b3425b83c33d8cd95fb20dd3c567fdff70121030af1fadce80bcb8ba614634bc82c71eea2ed87a5692d3127766cc896cef1bdb100000000 + +{ + "txid": "bf9164db69d216da4af6d9c720a0cec6d7e0bafb1702fdf8c2cd5606101576de", + "hash": "7d855ffbd8bc17892e28f3f326d0e4919d35c27a7370f5d9f9ce538e93a347cf", + "version": 3, + "size": 191, + "vsize": 110, + ... + "vout": [ + ... + "scriptPubKey": { + "hex": "001400991cdadccdf30cb5a04663b0371cb433a095b4", + ... +} + +# Odečti satoshi na CPFP poplatek +bitcoin-cli -regtest createrawtransaction '[{"txid": "bf9164db69d216da4af6d9c720a0cec6d7e0bafb1702fdf8c2cd5606101576de", "vout": 0}]' '[{"bcrt1qqzv3ekkueheseddqge3mqdcukse6p9d5yuqxv3": "49.99994375"}]' +0200000001de7615100656cdc2f8fd0217fbbae0d7c6cea020c7d9f64ada16d269db6491bf0000000000fdffffff0100ed94000000000016001400991cdadccdf30cb5a04663b0371cb433a095b400000000 + +# Podepiš TRUC a odešli jako 1P1C balíček +bitcoin-cli -regtest -rpcwallet=test signrawtransactionwithwallet 0300000001de7615100656cdc2f8fd0217fbbae0d7c6cea020c7d9f64ada16d269db6491bf0000000000fdffffff0100ed94000000000016001400991cdadccdf30cb5a04663b0371cb433a095b400000000 '[{"txid": "bf9164db69d216da4af6d9c720a0cec6d7e0bafb1702fdf8c2cd5606101576de", "vout": 0, "scriptPubKey": "001400991cdadccdf30cb5a04663b0371cb433a095b4", "amount": "50.00000000"}]' +{ + "hex": "03000000000101de7615100656cdc2f8fd0217fbbae0d7c6cea020c7d9f64ada16d269db6491bf0000000000fdffffff0100ed94000000000016001400991cdadccdf30cb5a04663b0371cb433a095b4024730440220685a6d76db97b2c27950f267b70d606f1864002ff6b4617cd2e29afd5ddfac83022037be8bb2ebe8194b4263f16a634e5c00a5f6c4eef0968d12994ed66dcf15b9ac0121020797cc343a24dfe49c7ee9b94bf3daaf15308d8c12e3f0f7e102b95ee55f939f00000000", + "complete": true +} + +bitcoin-cli -regtest -rpcwallet=test submitpackage '["030000000001013b64742e658ff39da0288a5010f094a9e94e6ce3a3ce2ed84b74babc017aea490000000000fdffffff01f90295000000000016001400991cdadccdf30cb5a04663b0371cb433a095b40247304402200a82f2fd8aa5f32cdfd9540209ccfc36a95eea21518ede1c3787561c8fb7269702207a258e6f027ce156271879c38628ad9b3425b83c33d8cd95fb20dd3c567fdff70121030af1fadce80bcb8ba614634bc82c71eea2ed87a5692d3127766cc896cef1bdb100000000", "03000000000101de7615100656cdc2f8fd0217fbbae0d7c6cea020c7d9f64ada16d269db6491bf0000000000fdffffff0100ed94000000000016001400991cdadccdf30cb5a04663b0371cb433a095b4024730440220685a6d76db97b2c27950f267b70d606f1864002ff6b4617cd2e29afd5ddfac83022037be8bb2ebe8194b4263f16a634e5c00a5f6c4eef0968d12994ed66dcf15b9ac0121020797cc343a24dfe49c7ee9b94bf3daaf15308d8c12e3f0f7e102b95ee55f939f00000000"]' +{ + "package_msg": "success", + "tx-results": { + "7d855ffbd8bc17892e28f3f326d0e4919d35c27a7370f5d9f9ce538e93a347cf": { + "txid": "bf9164db69d216da4af6d9c720a0cec6d7e0bafb1702fdf8c2cd5606101576de", + "vsize": 110, + "fees": { + "base": 0.00000000, + "effective-feerate": 0.00025568, + "effective-includes": [ + "7d855ffbd8bc17892e28f3f326d0e4919d35c27a7370f5d9f9ce538e93a347cf", + "4333b3d2eea820373262c7ffb768028bc82f99f47839349722eb60c58cd65b55" + ] + } + }, + "4333b3d2eea820373262c7ffb768028bc82f99f47839349722eb60c58cd65b55": { + "txid": "6c2f4dec614c138703f33e6a5c215112bad4cf79593e9757105e09b09bf3e2de", + "vsize": 110, + "fees": { + "base": 0.00005625, + "effective-feerate": 0.00025568, + "effective-includes": [ + "7d855ffbd8bc17892e28f3f326d0e4919d35c27a7370f5d9f9ce538e93a347cf", + "4333b3d2eea820373262c7ffb768028bc82f99f47839349722eb60c58cd65b55" + ] + } + } + }, + "replaced-transactions": [ + ] +} +``` +1P1C balíček byl vložen do místního mempoolu s efektivním jednotkovým poplatkem +25,568 satoshi na virtuální bajt, i když byla rodičovská transakce pod minimálním +poplatkem pro přeposílání. Úspěch! + +## TRUC transakce + +Transakce do potvrzení topologicky omezené (Topologically Restricted Until +Confirmation, TRUC), též známé jako v3 transakce, je nové, volitelné [pravidlo +mempoolu][policy series] zaměřené na poskytování robustního nahrazování +transakcí poplatkem (RBF). Má za cíl zabránit poplatkovému [pinningu][topic +transaction pinning] transakcí i pinningu zneužívajícímu limitů balíčků. +Jeho ústřední filozofií je: **i když určité vlastnosti nejsou pro všechny +transakce aplikovatelné, můžeme je implementovat pro balíčky s omezenou +topologií**. TRUC vedle topologických restrikcí přináší i způsob, jak +používat tuto robustnější sadu pravidel. + +Ve zkratce, TRUC transakce je transakce verze 3, která je omezena buď na +samotnou transakci o velikosti až 10 kvB nebo na potomka právě jedné TRUC +transakce omezené na 1 kvB. TRUC transakce nemůže utratit neTRUC transakci +a naopak. Všechny TRUC transakce jsou považované za RBF nahraditelné bez ohledu +na signalizaci dle [BIP125][]. Je-li další, nekonfliktní TRUC potomek přidán +k rodičovské TRUC transakci, bude považována za [konfliktní][topic kindred rbf] +vzhledem k původnímu potomkovi a budou aplikována běžná RBF pravidla včetně +jednotkového a celkového poplatku. + +TRUC transakce mohou mít nulový poplatek, pokud potomek dostatečně navyšuje +celkový jednotkový poplatek balíčku. + +Omezená topologie dobře zapadá do konceptu 1P1C přeposílání bez ohledu na to, +co dělají protistrany transakce. Předpokladem je, že všechny podepsané transakce +jsou TRUC. + +TRUC platby jsou nahraditelné, takže jakákoliv transakce, jejíž vstupy odesílatel +minimálně z části nevlastní, může být znovuutracena. Jinými slovy přijímání +TRUC plateb bez konfirmací není bezpečnější než neTRUC. + +## RBF nahrazování balíčků s topologií 1P1C + +Rodič z 1P1C balíčku může být v konfliktu s jiným rodičem v mempoolu. To může nastat, +pokud například existuje více předem podepsaných verzí rodičovské transakce. +Dříve byl rodič během RBF nahrazování uvažován samostatně a byl zahozen, pokud +byl poplatek příliš nízký. + +S RBF nahrazováním balíčku s topologií 1P1C bude i potomek začleněn do úvah, což +umožní vývojářům peněženek využívat robustního posílání 1P1C balíčků P2P sítí +bez ohledu na verze transakcí v lokálním mempoolu. + +Poznamenejme, že v současnosti musí být konfliktní transakce samostatná nebo +v 1P1C balíčku bez dalších závislostí. V opačném případě bude nahrazení odmítnuto. +Jakýkoliv počet takových shluků může být v konfliktu. To bude zvolněno v budoucích +vydáních s cluster mempoolem. + +Pokračujme v našem 1P1C příkladu. Provedeme nahrazení nového balíčku oproti +existujícímu 1P1C balíčku, tentokrát s neTRUC balíčkem: + +```hack +# TRUC rodič a potomek +bitcoin-cli -regtest getrawmempool +[ + "bf9164db69d216da4af6d9c720a0cec6d7e0bafb1702fdf8c2cd5606101576de", + "6c2f4dec614c138703f33e6a5c215112bad4cf79593e9757105e09b09bf3e2de" +] + +# Druhé utracení rodiče novým 1P1C v2 balíčkem, kde poplatky rodiče +# jsou nad minrelay, ale ne dost na RBF balíčku +bitcoin-cli -regtest createrawtransaction '[{"txid": "49ea7a01bcba744bd82ecea3e36c4ee9a994f010508a28a09df38f652e74643b", "vout": 0}]' '[{"bcrt1qqzv3ekkueheseddqge3mqdcukse6p9d5yuqxv3": "49.99999"}]' + +02000000013b64742e658ff39da0288a5010f094a9e94e6ce3a3ce2ed84b74babc017aea490000000000fdffffff0111ff94000000000016001400991cdadccdf30cb5a04663b0371cb433a095b400000000 + +# Podepiš a (neúspěšně) odešli +bitcoin-cli -regtest -rpcwallet=test signrawtransactionwithwallet 02000000013b64742e658ff39da0288a5010f094a9e94e6ce3a3ce2ed84b74babc017aea490000000000fdffffff0111ff94000000000016001400991cdadccdf30cb5a04663b0371cb433a095b400000000 +{ + "hex": "020000000001013b64742e658ff39da0288a5010f094a9e94e6ce3a3ce2ed84b74babc017aea490000000000fdffffff0111ff94000000000016001400991cdadccdf30cb5a04663b0371cb433a095b4024730440220488d98ad79495276bb4cdda4d7c62292043e185fa705d505c7dceef76c4b61d30220567243245416a9dd3b76f3d94bfd749e0915929226ba079ec918f6675cbfa3950121030af1fadce80bcb8ba614634bc82c71eea2ed87a5692d3127766cc896cef1bdb100000000", + "complete": true +} + +bitcoin-cli -regtest sendrawtransaction 020000000001013b64742e658ff39da0288a5010f094a9e94e6ce3a3ce2ed84b74babc017aea490000000000fdffffff0111ff94000000000016001400991cdadccdf30cb5a04663b0371cb433a095b4024730440220488d98ad79495276bb4cdda4d7c62292043e185fa705d505c7dceef76c4b61d30220567243245416a9dd3b76f3d94bfd749e0915929226ba079ec918f6675cbfa3950121030af1fadce80bcb8ba614634bc82c71eea2ed87a5692d3127766cc896cef1bdb100000000 + +# chyba: nedostatečný poplatek, odmítnuté nahrazení, +# menší poplatek než konfliktní transakce; 0,00001 < 0,00005625 +error code: -26 +error message: +insufficient fee, rejecting replacement f17146d87a029cb04777256fc0382c637a31b2375f3981df0fb498b9e44ceb59, less fees than conflicting txs; 0.00001 < 0.00005625 + +# Přidej do nového balíčku poplatky skrze potomky, +# přeplať starý balíček +bitcoin-cli -regtest createrawtransaction '[{"txid": "f17146d87a029cb04777256fc0382c637a31b2375f3981df0fb498b9e44ceb59", "vout": 0}]' '[{"bcrt1qqzv3ekkueheseddqge3mqdcukse6p9d5yuqxv3": "49.99234375"}]' + +020000000159eb4ce4b998b40fdf81395f37b2317a632c38c06f257747b09c027ad84671f10000000000fdffffff01405489000000000016001400991cdadccdf30cb5a04663b0371cb433a095b400000000 + +# Podepiš a odešli jako balíček +bitcoin-cli -regtest -rpcwallet=test signrawtransactionwithwallet 020000000159eb4ce4b998b40fdf81395f37b2317a632c38c06f257747b09c027ad84671f10000000000fdffffff01405489000000000016001400991cdadccdf30cb5a04663b0371cb433a095b400000000 '[{"txid": "f17146d87a029cb04777256fc0382c637a31b2375f3981df0fb498b9e44ceb59", "vout": 0, "scriptPubKey": "001400991cdadccdf30cb5a04663b0371cb433a095b4", "amount": "49.99999"}]' +{ + "hex": "0200000000010159eb4ce4b998b40fdf81395f37b2317a632c38c06f257747b09c027ad84671f10000000000fdffffff01405489000000000016001400991cdadccdf30cb5a04663b0371cb433a095b40247304402205d086fa617bdbf5a3df3a15cc9a927ad884c714d46d9ef6762ad2fa6a259740c022032c60b4fe5d533d990489c27dc3283d8b3999b97f6c12986ac8159b92cb6de820121020797cc343a24dfe49c7ee9b94bf3daaf15308d8c12e3f0f7e102b95ee55f939f00000000", + "complete": true +} + +bitcoin-cli -regtest -rpcwallet=test submitpackage '["020000000001013b64742e658ff39da0288a5010f094a9e94e6ce3a3ce2ed84b74babc017aea490000000000fdffffff0111ff94000000000016001400991cdadccdf30cb5a04663b0371cb433a095b4024730440220488d98ad79495276bb4cdda4d7c62292043e185fa705d505c7dceef76c4b61d30220567243245416a9dd3b76f3d94bfd749e0915929226ba079ec918f6675cbfa3950121030af1fadce80bcb8ba614634bc82c71eea2ed87a5692d3127766cc896cef1bdb100000000", "0200000000010159eb4ce4b998b40fdf81395f37b2317a632c38c06f257747b09c027ad84671f10000000000fdffffff01405489000000000016001400991cdadccdf30cb5a04663b0371cb433a095b40247304402205d086fa617bdbf5a3df3a15cc9a927ad884c714d46d9ef6762ad2fa6a259740c022032c60b4fe5d533d990489c27dc3283d8b3999b97f6c12986ac8159b92cb6de820121020797cc343a24dfe49c7ee9b94bf3daaf15308d8c12e3f0f7e102b95ee55f939f00000000"]' +{ + "package_msg": "success", + "tx-results": { + "fe15d23f59537d12cddf510616397b639a7b91ba2f846c64533e847e53d7c313": { + "txid": "f17146d87a029cb04777256fc0382c637a31b2375f3981df0fb498b9e44ceb59", + "vsize": 110, + "fees": { + "base": 0.00001000, + "effective-feerate": 0.03480113, + "effective-includes": [ + "fe15d23f59537d12cddf510616397b639a7b91ba2f846c64533e847e53d7c313", + "256cebd037963d77b2692cdc33ee36ee0b0944e6b9486a6aaad0792daa0f677c" + ] + } + }, + "256cebd037963d77b2692cdc33ee36ee0b0944e6b9486a6aaad0792daa0f677c": { + "txid": "858fe07b01bc7c1c1dda50ba16a33b164c0bc03d0eff8f9546558c088e087f60", + "vsize": 110, + "fees": { + "base": 0.00764625, + "effective-feerate": 0.03480113, + "effective-includes": [ + "fe15d23f59537d12cddf510616397b639a7b91ba2f846c64533e847e53d7c313", + "256cebd037963d77b2692cdc33ee36ee0b0944e6b9486a6aaad0792daa0f677c" + ] + } + } + }, + "replaced-transactions": [ + "bf9164db69d216da4af6d9c720a0cec6d7e0bafb1702fdf8c2cd5606101576de", + "6c2f4dec614c138703f33e6a5c215112bad4cf79593e9757105e09b09bf3e2de" + ] +} + +``` + +## Pay To Anchor (P2A) + +[Anchory][topic anchor outputs] jsou definovány jako výstupy určené výhradně pro +nahrazení pomocí CPFP. Jelikož nejsou tyto výstupy skutečnými platbami, mají nízkou +hodnotu (blízkou prachu) a jsou okamžitě utracené. + +Byl přidán nový typ výstupního skriptu [Pay To Anchor (P2A)][topic ephemeral anchors], +který přináší optimalizovanou verzi anchorů, která nevyžaduje existenci klíče. +Výstupní skript je `OP_1 <4e73>`. Pro utracení nevyžaduje žádná witnessová data, +což v důsledku znamená redukci poplatku v porovnání s existujícím způsobem. +Též umožňuje, aby CPFP nahrazení transakce provedl kdokoliv. + +P2A může být použito nezávisle na TRUC transakcích i 1P1C balíčkách. Transakce +s P2A výstupem a bez potomků může být zveřejněna, ale výstup je možné triviálně +utratit. Aby mohly balíčky a TRUC transakce vyžít nových možností navyšování +poplatků, nemusí mít žádné P2A výstupy. + +Tento nový druh výstupu má hodnotu prachu (dust limit) 240 satoshi. P2A výstupy +pod touto hodnotou nebudou šířeny, ani když jsou utráceny v balíčku, neboť +tento limit [ekonomičnosti výstupů][topic uneconomical outputs] je nadále plně +vynucován pravidly. Ač byl tento návrh dříve spojován s dočasným prachem +(ephemeral dust), již tomu tak není. + +Příklad vytváření a utrácení P2A: + +```hack +# Adresa P2A na regtestu je "bcrt1pfeesnyr2tx", na mainnetu "bc1pfeessrawgf" +bitcoin-cli -regtest getaddressinfo bcrt1pfeesnyr2tx +{ + "address": "bcrt1pfeesnyr2tx", + "scriptPubKey": "51024e73", + "ismine": false, + "solvable": false, + "iswatchonly": false, + "isscript": true, + "iswitness": true, + "ischange": false, + "labels": [ + ] +} + +# Segwitový výstup typu "anchor" +bitcoin-cli -regtest decodescript 51024e73 +{ + "asm": "1 29518", + "desc": "addr(bcrt1pfeesnyr2tx)#swxgse0y", + "address": "bcrt1pfeesnyr2tx", + "type": "anchor" +} + +# Minimální hodnota P2WPKH a P2A výstupů +bitcoin-cli -regtest createrawtransaction '[{"txid": "49ea7a01bcba744bd82ecea3e36c4ee9a994f010508a28a09df38f652e74643b", "vout": 0}]' '[{"bcrt1qqzv3ekkueheseddqge3mqdcukse6p9d5yuqxv3": "0.00000294"}, {"bcrt1pfeesnyr2tx": "0.00000240"}]' +02000000013b64742e658ff39da0288a5010f094a9e94e6ce3a3ce2ed84b74babc017aea490000000000fdffffff02260100000000000016001400991cdadccdf30cb5a04663b0371cb433a095b4f0000000000000000451024e7300000000 + +# Podepiš a odešli transakci s P2A výstupem +bitcoin-cli -regtest -rpcwallet=test signrawtransactionwithwallet 02000000013b64742e658ff39da0288a5010f094a9e94e6ce3a3ce2ed84b74babc017aea490000000000fdffffff02260100000000000016001400991cdadccdf30cb5a04663b0371cb433a095b4f0000000000000000451024e7300000000 +{ + "hex": "020000000001013b64742e658ff39da0288a5010f094a9e94e6ce3a3ce2ed84b74babc017aea490000000000fdffffff02260100000000000016001400991cdadccdf30cb5a04663b0371cb433a095b4f0000000000000000451024e7302473044022002c7e756b15135a3c0a061df893a857b42572fd816e41d3768511437baaeee4102200c51fcce1e5afd69a28c2d48a74fd5e58b280b7aa2f967460673f6959ab565e80121030af1fadce80bcb8ba614634bc82c71eea2ed87a5692d3127766cc896cef1bdb100000000", + "complete": true + +# Vypni kontrolu rozumnosti poplatku +bitcoin-cli -regtest -rpcwallet=test sendrawtransaction 020000000001013b64742e658ff39da0288a5010f094a9e94e6ce3a3ce2ed84b74babc017aea490000000000fdffffff02260100000000000016001400991cdadccdf30cb5a04663b0371cb433a095b4f0000000000000000451024e7302473044022002c7e756b15135a3c0a061df893a857b42572fd816e41d3768511437baaeee4102200c51fcce1e5afd69a28c2d48a74fd5e58b280b7aa2f967460673f6959ab565e80121030af1fadce80bcb8ba614634bc82c71eea2ed87a5692d3127766cc896cef1bdb100000000 "0" +fdee3b6a5354f31ce32242db10eb9ee66017e939ea87db0c39332262a41a424b + +# Nahrazený předchozí balíček +bitcoin-cli -regtest getrawmempool +[ + "fdee3b6a5354f31ce32242db10eb9ee66017e939ea87db0c39332262a41a424b" +] + +# Propal hodnotu v potomkovi, v 65bajtové transakci s OP_RETURN, +# abychom se vyvarovali stížnostem na příliš malou transakci +bitcoin-cli -regtest createrawtransaction '[{"txid": "fdee3b6a5354f31ce32242db10eb9ee66017e939ea87db0c39332262a41a424b", "vout": 1}]' '[{"data": "feeeee"}]' +02000000014b421aa4622233390cdb87ea39e91760e69eeb10db4222e31cf354536a3beefd0100000000fdffffff010000000000000000056a03feeeee00000000 + +# Netřeba podepisovat, není vyžadován witness +bitcoin-cli -regtest -rpcwallet=test sendrawtransaction 02000000014b421aa4622233390cdb87ea39e91760e69eeb10db4222e31cf354536a3beefd0100000000fdffffff010000000000000000056a03feeeee00000000 +8d092b61ef3c1a58c24915671b91fbc6a89962912264afabc071a4dbfd1a484e + +``` + +## Aplikace + +Pokračujme dále popisem několika běžných vzorců chování peněženek a jak by jim mohly +být tyto novinky užitečné, ať peněženka aktivně provádí změny či ne. + +### Prosté platby + +Jedním obvyklým problémem je, že uživatelé si nemohou být během RBF jisti, zda +se příjemce bitcoinů nepokusí o vytvoření řetězce transakcí vycházejících ze +samotné platby, čímž by se dopustil pinningu. Pokud si uživatel přeje mít +snadněji predikovatelné RBF chování, je jedním ze způsobů použití TRUC transakce. +Příchozím platbám také mohou být spolehlivě navýšeny poplatky pomocí až 1kvB utracení +příchozího vkladu. + +V takových případech by peněženky měly: + +- nastavit verzi na 3 +- použít pouze potvrzené výstupy +- zůstat v 10kvB limitu (oproti neTRUC limitu 100 kvB) + - i nadále jsou možné dávkové platby + - pokud peněženka musí utratit nepotvrzený výstup, musí pocházet z TRUC + transakce a nová transakce musí být pod 1 kvB + +### Coinjoiny + +V případě [coinjoinu][topic coinjoin], kde je cílem soukromí a není potřeba +provést skrytý coinjoin, by mohly být TRUC transakce užitečné. Coinjoin +může mít příliš nízký poplatek a tedy může potřebovat jej navýšit. + +Vedle TRUC transakcí by mohl být také přidán P2A výstup, který by umožňoval +odděleným peněženkám (např. strážním věžím) zaplatit poplatky za transakci. + +Pokud ostatní účastníci utratí své nepotvrzené výstupy, může nastat vyloučení +TRUC sourozenců. Vyloučení sourozenců může zachovat limity na TRUC topologii, +avšak umožňuje přidat poplatek pomocí CPFP: nový potomek může nahradit předchozího +bez utracení konfliktních vstupů. Proto jsou všichni účastníci coinjoinu +vždy schopni navýšit poplatek transakce pomocí CPFP. + +Pozor na pinning: účastníci coinjoinu i tak mohou ekonomicky škodit tím, že +podruhé utratí svůj vlastní vstup do coinjoinu, což si vynutí nahradit pomocí +RBF škodičovu první transakci. + +### Lightning Network + +Transakce generované v Lightning Network protokolu sestávají z několika hlavních +typů: + +1. Financující transakce: financovaná jednou nebo oběma stranami pro otevření + kontraktu; méně časově citlivá. +2. Commitment transakce: transakce, která potvrzuje poslední stav kanálu. Tyto + transakce jsou asymetrické a v současnosti vyžadují obousměrnou zprávu + `update_fee` pro úpravu poplatků. Poplatky musí být dostatečně vysoké na + propagaci sítí do mempoolů těžařů. +3. Předem podepsané HTLC transakce. + +Používání 1P1C přeposílání a RBF balíčků výrazně navyšuje bezpečnost Lightning +Network. Jednostranná uzavření kanálů mohou být učiněna s commitment transakcemi +majícími poplatky pod minima mempoolu nebo kolidující s jiným nízkopoplatkovým +balíčkem s commitment transakcí. Tyto transakce by jinak nebyly rychle začleněny +do bloku. + +Přinejmenším by mohly lightningové peněženky využít výhody, které jim nabízí +RPC příkaz `submitpackge` v Bitcoin Core: + +```hack +bitcoin-cli submitpackage '["", ""]' +``` + +Peněženky by měly tento příkaz integrovat pro použití s commitment transakcemi +i utracením anchoru, aby zajistily zařazení do mempoolů těžařů se správným +poplatkem. + +Poznámka: RPC vrátí úspěch, pokud odešlete balíček s jedním rodičem a mnoha +potomky, nebude však propagován dle 1P1C pravidel. + +Až upgraduje dostatečné množství uzlů v síti, bude moci LN protokol odstranit +zprávu `update_fee`, která je již léta zdrojem zbytečných vynucených uzavření +kanálů během období vysokých poplatků. S odstraněním této zprávy z protokolu +by mohly být commitment transakce nastaveny na statický jednotkový poplatek +1 sat/vbyte. S TRUC transakcemi můžeme zajistit, aby bylo soupeřícím commitment +transakcím s anchory umožněno navýšit si navzájem poplatky, a pokud existují +soupeřící výstupy placené ze stejné commitment transakce, RBF bude moci být +proveden bez ohledu na to, který výstup je právě utrácen. TRUC transakce mohou +mít i nulový poplatek, což by umožnilo snížení složitosti specifikace. S vylučováním +TRUC sourozenců bychom též mohli odstranit jednoblokový CSV časový zámek, +jelikož už by nebylo tak důležité, který nepotvrzený výstup je právě utrácen, +pokud může každá strana sama utratit jediný výstup. + +S TRUC a P2A anchory můžeme snížit používání blokového prostoru ze současných +dvou anchorů na jediný anchor bez použití klíče. Tento anchor nevyžaduje žádný +závazek k veřejnému klíči či podpisu, což ušetří další blokový prostor. Navyšování +poplatků může být delegováno na agenty, kteří nemají k dispozici žádné tajné klíče. +Anchory by také mohly místo P2A obsahovat jediný výstup s klíči sdílenými mezi stranami +za cenu vyššího množství virtuálních bajtů v případě jednostranného uzavření. + +Podobné strategie by mohly být použité během implementace pokročilých funkcí +jako splicingu ke snížení rizika RBF pinningu. Například splice TRUC kanálu, +který má méně než 1 kvB, by mohl navýšit poplatek pomocí CPFP jednostrannému +uzavření jiného kanálu. Následná navýšení mohou být provedena v sérii nahrazením +pouze splicingové transakce. Nevýhodou by bylo odhalení typu TRUC transakce +během splicingu. + +Jak vidno, mohli bychom se s těmito novými schopnostmi vyvarovat nadměrné složitosti +a mohli bychom dosáhnout úspor, pokud by se mohla každá transakce vměstnat do +1P1C schématu. + +### Ark + +Ne všechny vzorce používání transakcí se vměstnají do 1P1C schématu. Příkladem +nechť jsou [Ark][topic ark] výstupy, které pro rozdělení sdíleného UTXO zavazují +až ke třem předem podepsaným (nebo kovenantovým) transakcím. + +Je-li poskytovatel služby Ark (ASP) offline nebo zpracovává-li transakci, může +uživatel jednostranně vystoupit, což si k oddělení jeho větve ze stromu transakcí +od něj vyžádá odeslání série transakcí. Potřeba je O(log n) transakcí. +Potíže mohou nastat, pokud se i další klienti pokouší opustit strom, což může +v mempoolu vyústit v překročení limitů řetězení nebo ve vytvoření konfliktních +transakcí s nedostatečnými poplatky pro včasné zařazení do bloku. Pokud se objeví +výrazně dlouhé období bez začlenění, je ASP schopen si jednostranně všechny prostředky +přisvojit. Uživatelé by o tyto peníze přišli. + +Ideálně by úvodní jednostranné uzavření arkového stromu: + +1. Bylo publikováno jako kompletní větev Merkleova stromu podkladového + virtuálního UTXO (vUTXO). +2. Každá z těchto transakcí by měla nulový poplatek, aby nebylo potřeba činit + předpovídání poplatků nebo dopředu rozhodovat, kdo bude poplatky platit. +3. Konečná transakce v listu stromu by měla anchor s nulovou hodnotou, které + platí pomocí CPFP za publikaci celého Merkleova stromu. + +Pro uskutečnění tohoto ideálu nám ještě pár věcí chybí: + +1. Všeobecné přeposílání balíčků. V současnosti neexistuje způsob robustního + propagování těchto řetězců nízkopoplatkových transakcí P2P sítí. +2. Pokud by bylo mnoho větví publikováno s nízkými poplatky, uživatelé by + nemuseli být schopni včas publikovat své vlastní větve kvůli omezení počtu + předků. To by mohlo být katastrofické v případě vysokého počtu protistran, + což je ideální případ používání Arku. +3. Potřebujeme všeobecné vylučování sourozenců. Nemáme podporu pro výstupy + nehodnotných anchorů mající nulovou hodnotu. + +Zkusme namísto toho požadovanou strukturu transakcí co nejlépe přizpůsobit +schématu s jedním rodičem a jedním potomkem i za cenu dodatečných poplatků. +Všechny transakce arkových stromů, počínaje v kořenu, jsou TRUC transakce +s přidanými P2A výstupy s minimální hodnotou. + +Když se účastník rozhodne jednostranně z Arku vystoupit, publikuje +kořenovou transakci spolu s utracením P2A výstupu na poplatky. Poté čeká +na potvrzení. Po potvrzení uživatel odešle další transakci ve své větvi +Merkleova stromu spolu se svým vlastním utracením P2A na poplatky. Cyklus +pokračuje, dokud není celá větev publikována a dokud nejsou prostředky +bezpečně z arkového stromu extrahovány. Ostatní uživatelé stejného Arku +mohou se špatnými úmysly nebo bez nich zveřejnit transakci stejného vnitřního +uzlu s příliš nízkým jednotkovým poplatkem, ale vylučování sourozenců +by zajistilo, že v každém bodě by čestný potomek s méně než 1 kvB mohl +nahradit (RBF) soupeřícího potomka bez nutnosti uzamknout ostatní výstupy +nebo bez požadavku na existenci více anchorů. + +Předpokládáme-li binární stromy, přichází toto schéma pro prvního uživatele +s téměř dvojnásobnými náklady oproti ideálnímu Arku a o polovinu vyššími +náklady na celý strom v případě kompletního rozdělení. U 4-stromů klesají +dodatečné náklady za celý strom na čtvrtinu. + +### Splicing v Lightning Network + +V pokročilejších konstruktech v Lightning Network se objevují i jiné topologie, +které by vyžadovaly trochu úsilí, aby mohly využívat 1P1C přeposílání. + +[Splicing][topic splicing] v Lightning Network je vznikající standard již v běžném +používání. Každý splice utrácí výstup původní financující transakce a vkládá prostředky +kontraktu do nového výstupu. Řetězec předem podepsaných transakcí zůstává zachován. +Před nabytím potvrzení jsou podepisovány a sledovány stavy původního i nového kanálu. + +V následujícím případě by došlo k překročení schématu 1P1C: + +1. Alice a Bob otevřou kanál. +2. Alice splicingem vynese některé prostředky (splice out) na blockchainovou + adresu ovládanou Carol, která nemůže použít CPFP. Tento splice-out cílí + na potvrzení během několika hodin. +3. Bobův uzel se stane offline nebo z nějakého důvodu vynutí zavření kanálu. +4. Poplatky vystřelí vzhůru (třeba zrovna spustil nějaký token), což výrazně zpozdí + potvrzení splice-outové transakce. + +Alice chce uskutečnit onchain platbu Carol, nechce tedy do blockchainu odeslat +commitment transakci bez splicu. Znamená to, že aby došlo k úspěšné propagaci, +musí být balíček splicová transakce -> commitment transakce -> utracený anchor. + +Zkusme zvážit, jak tuto situaci naroubovat na schéma 1P1C bez zbytečného plýtvání +virtuálními bajty. LN peněženka by mohla namísto jednoho splice-outu na jednu +onchain platbu učinit dva splice-outy, jelikož jsou spolu v konfliktu. Jedna verze +by použila relativně konzervativní odhad poplatku. Druhá verze by obsahovala +P2A výstup s 240 satoshi (nebo v budoucnosti 0 satoshi s [dočasným prachem][topic +ephemeral anchors], ephemeral dust). + +Nejdříve by byl zveřejněn splice-out bez anchoru. + +Pokud by se nic mimořádného nestalo, byl by potvrzen a Alice by mohla pokračovat +v normálním uzavření kanálu. + +V případě vystřelených poplatků by mohl být zveřejněn 1P1C splice s anchorem spolu +s útratou anchoru; RBF nahrazení balíčku by nahradilo první splice-out. Toto navýšení +poplatku by umožnilo potvrzení a platbu Carol. Uzavření kanálu by mohlo následovat. + +Jinou možností je vytvoření několika verzí splice-outových transakcí s různými +úrovněmi poplatků. Každá kopie by však vyžadovala dodatečnou sadu podpisů commitment +transakce a nevybavených HTLC. + +{% include references.md %} + +[Gregory Sanders]: https://github.com/instagibbs +[bc 28.0]: https://github.com/bitcoin/bitcoin/releases/tag/v28.0 +[bc 28.0 release notes]: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-28.0.md +[package relay tracking issue]: https://github.com/bitcoin/bitcoin/issues/27463 +[policy series]: /cs/blog/waiting-for-confirmation/ diff --git a/_posts/cs/2026-02-13-newsletter.md b/_posts/cs/2026-02-13-newsletter.md new file mode 100644 index 0000000000..7eace03e35 --- /dev/null +++ b/_posts/cs/2026-02-13-newsletter.md @@ -0,0 +1,222 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 392' +permalink: /cs/newsletters/2026/02/13/ +name: 2026-02-13-newsletter-cs +slug: 2026-02-13-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Zpravodaj tento týden shrnuje diskuzi o zlepšení situace s nejhorší možnou +efektivitou skenování tichých plateb a popisuje myšlenku na možnost stanovit +mnoho podmínek utrácení v jediném klíči. Též nechybí naše pravidelné rubriky +s oznámeními nových vydání a popisem významných změn v populárním +bitcoinovém páteřním software. + +## Novinky + +- **Návrh na omezení počtu příjemců tichých plateb ve skupině**: Sebastian + Falbesoner zaslal do emailové skupiny Bitcoin-Dev [příspěvek][kmax mailing list] + o objevení a opatření před teoretickým útokem na příjemce [tichých plateb][topic + silent payments]. Útok nastává, když protivník zkonstruuje transakci s velkým + počtem taprootových výstupů (dle aktuálních pravidel konsenzu je maximální + počet výstupů v bloku 23 255), které všechny cílí na stejnou entitu. + Kdyby neexistovalo žádné omezení na velikost skupiny, trvalo by ji zpracovat + několik minut namísto desítek sekund. + + To vedlo k přidání nového parametru `K_max`, který omezuje počet příjemců + na skupinu v rámci jediné transakce. Teoreticky by tato změna nebyla + zpětně kompatibilní, ale v praxi by žádná peněženka podporující tiché platby + neměla být ovlivněna pro dostatečně vysoký `K_max`. Falbesoner navrhuje `K_max=1000`. + + Falbesoner žádá o zpětnou vazbu k navrženému omezení. Dále poznamenává, + že kontaktoval vývojáře většiny peněženek a jsou tedy s problémem seznámeni. + +- **BLISK, logika booleovských obvodů integrovaná do jediného klíče**: Oleksandr + Kurbatov zaslal do fóra Delving Bitcoin [příspěvek][blisk del] o BLISKu, + protokolu navrženém na vyjádření komplexních autorizačních pravidel pomocí + booleovské logiky. BLISK (Boolean circuit Logic Integrated into the Single Key) + má za cíl vyřešit omezení existujících pravidel utrácení. Na příklad protokoly + jako [MuSig2][topic musig], ač efektivní a zachovávající soukromí, jsou schopné + vyjádřit kardinalitu (_k_ z _n_), avšak neumí určit, „kdo” může utrácet. + + BLISK vytváří jednoduché AND/OR booleovské obvody a mapuje logická hradla na + známé kryptografické techniky. Konkrétně: AND hradla vznikají aplikací + _n_ z _n_ vícenásobného podpisu, kde každý účastník musí přispět validním + podpisem. Na druhou stranu, OR hradla vznikají použitím protokolu výměny + klíčů, jako je [ECDH][ecdh wiki], kde kterýkoliv účastník může odvodit + sdílený tajný kód použitím svého soukromého klíče a veřejného klíče kteréhokoliv + z ostatních účastníků. Dále také využívá [neinteraktivního dokladu s nulovou + znalostí][nizk wiki], aby umožnil ověřit výsledek obvodu a tím zabránil podvodům. + Výsledkem řešení obvodu BLISKu je jediný klíč pro ověřování podpisu. Díky tomu + je potřeba ověřit jen jeden [Schnorrův][topic schnorr signatures] podpis oproti + jednomu veřejnému klíči. + + Další výhodou BLISKu oproti jiným přístupům je odstranění nutnosti generovat + čerstvý klíč, jelikož umožňuje připojit existující klíč ke konkrétní instanci + podpisu. + + Kurbatov poskytl pro tento protokol [ověřovací implementaci][blisk gh], i když + uvedl, že zatím nedosáhla produkční kvality. + +## 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.* + +- [Bitcoin Core 29.3][] je údržbovým vydáním předchozí hlavní verze, které + přináší opravu několika chyb v migrování peněženek (viz [zpravodaj + č. 387][news387 wallet]), přidává vyrovnávací paměť mezistavu sighashe vstupů + (snižuje dopady kvadratického algoritmu v zastaralých skriptech, viz + [zpravodaj č. 367][news367 sighash], _angl._) a odstraňuje systém hodnocení + špatného chování peer spojení za nevalidní transakce (viz [zpravodaj + č. 367][news367 discourage], _angl._). [Poznámky k vydání][bcc29.3 rn] + obsahují další podrobnosti. + +- [LDK 0.2.2][] je údržbovým vydáním této knihovny pro budování aplikací + s podporou LN. Mění příznak podpory splicingu na produkční + feature bit (63), opravuje chybu, která mohla po restartování způsobit + zamrznutí databázových asynchronních operací `ChannelMonitorUpdate`, + což vedlo k vynucenému zavření kanálu, a opravuje chybu debug assertu, + která se objevila po přijetí nevalidní splicingové zprávy. + +- [HWI 3.2.0][] je vydáním tohoto balíčku poskytujícího jednotné rozhraní + k několika hardwarovým podpisovým zařízením. Nové vydání přidává podporu + pro zařízení Jade Plus a BitBox02 Nova a podporu pro [MuSig2][topic + musig] PSBT pole dle specifikace v [BIP373][]. + +- [Bitcoin Inquisition 29.2][] je vydáním tohoto [signetového][topic signet] + plného uzlu určeného pro experimentování s návrhy soft forků a jinými + významnými změnami protokolu. Je založeno na Bitcoin Core 29.3r2, implementuje + návrh [BIP54][] ([pročištění konsenzu][topic consensus cleanup]) a deaktivuje + [testnet4][topic testnet]. + +## Významné změny kódu a dokumentace + +_Významné změny z tohoto týdne v [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo] a [repozitáři BINANA][binana repo]._ + +- [Bitcoin Core #32420][] přestává v Mining IPC rozhraní (viz + [zpravodaj č. 310][news310 mining]) přidávat do `scriptSig` mincetvorné + transakce falešný `extraNonce`. Do `CreateNewBlock()` přidává novou volbu + `include_dummy_extranonce` a IPC ji nastavuje na `false`. Klienty + [Stratum v2][topic pooled mining] obdrží v `scriptSig` pouze výšku, + jak konsenzus dle [BIP34][] požaduje, a nemusí tato extra data odstraňovat + nebo ignorovat. + +- [Core Lightning #8772][] odstraňuje podporu zastaralého formátu onion + plateb. I když CLN přestal staré onion používat v roce 2022 (viz + [zpravodaj č. 193][news193 legacy], _angl._), přidal ve verzi 24.05 + překladovou vrstvu, která se starala o několik zbývajících zastaralých + onion zpráv produkovaných staršími LND. Ty nejsou od LND verze + 0.18.3 vytvářeny, podpora již proto není potřebná. Tento zastaralý + formát byl z BOLT specifikace odstraněn v roce 2022 (viz [zpravodaj + č. 220][news220 bolts], _angl._). + +- [LND #10507][] přidává do odpovědi na RPC volání `GetInfo` příznak `wallet_synced`, + který určuje, zda peněženka dokončila synchronizaci s aktuálním vrcholem + řetězce. Na rozdíl od stávajícího příznaku `synced_to_chain` toto nové pole + nevyžaduje, aby router grafu kanálů (který validuje [oznámení kanálů][topic + channel announcements]), ani blockbeat dispatcher (podsystém, který koordinuje + události bloků) synchronizaci již dokončily. + +- [LDK #4387][] mění příznak podpory [splicingu][topic splicing] z provizorního + feature bitu 155 na produkční bit 63. LDK verze 0.2 používala bit 155, + který používá též Eclair pro vlastní implementaci splicingu ve Phoenixu, + která předchází současný návrh specifikace a není s ní v souladu. + Kvůli tomu se Eclair uzly snažily provádět splicing pomocí vlastního + protokolu, což vedlo s LDK uzly k chybám deserializace a odpojování. + +- [LDK #4355][] přidává asynchronní podepisování commitmentů u interaktivně + otevíraných transakcí. Děje se tak během [splicingu][topic splicing] i + [oboustranně financovaných][topic dual funding] kanálů. Po obdržení + `EcdsaChannelSigner::sign_counterparty_commitment` asynchronní podepisující + objekt okamžitě vrátí a ozve se přes callback `ChannelManager::signer_unblocked`, + když je podpis hotov. Oboustranně financované kanály vyžadují pro plnou + podporu asynchronního podepisování další práci. + +- [LDK #4354][] mění výchozí hodnotu volby `negotiate_anchors_zero_fee_htlc_tx` + na `true`, čímž budou standardně vytvářeny kanály s [anchor výstupy][topic + anchor outputs]. Automatické přijímání kanálů bylo odstraněno, + všechny příchozí žádosti o kanál tak musí být schválené manuálně. + To zajistí, že peněženka má v případě vynuceného zavření kanálu dostatek + onchain prostředků na pokrytí poplatků. + +- [LDK #4303][] opravuje dvě chyby, které mohly způsobit dvojité přeposlání + [HTLC][topic htlc] po restartu `ChannelManager`: poprvé, když bylo odchozí + HTLC stále v interní frontě, ale nedošlo na něj, a podruhé, když bylo již + přeposláno, urovnáno a odstraněno z odchozí fronty, ale příchozí + interní fronta pro něj stále měla urovnání. PR dále odstraní příchozí + HTLC onion zprávy poté, co jsou definitivně přeposlané. + +- [HWI #784][] přidává do [PSBT][topic psbt] podporu pro serializaci a + deserializaci [MuSig2][topic musig] polí včetně veřejných klíčů + účastníků, veřejných noncí a částečných podpisů dle specifikace + v [BIP327][]. + +- [BIPs #2092][] přiřazuje zprávě + `feature` jednobajtové ID pro použití s [v2 P2P transport][topic v2 p2p + transport] protokolem a [BIP434][]. Do [BIP324][] přidává nový + soubor zaznamenávající přiřazená ID napříč BIPy, který by měl + vývojářům pomoci vyvarovat se konfliktů. Soubor též zaznamenává + navrhovaná přiřazení pro [Utreexo][topic utreexo]. + +- [BIPs #2004][] přidává [BIP89][] pro Chain Code Delegation (viz + [zpravodaj č. 364][news364 delegation], _angl._), mechanismus pro společnou + správu prostředků (collaborative custody), kde delegující nesdělí + delegovanému [BIP32][] chain code, avšak sdílí s ním pouze informace + nutné pro podepsání; tyto informace nejsou dostatečné pro sledování + ostatních adres. + +- [BIPs #2017][] přidává [BIP110][], který specifikuje dočasný soft fork + pro redukci dat (Reduced Data Temporary Softfork, RDTS). Tento návrh + má za cíl dočasně, na zhruba jeden rok, konsenzem omezit části + transakcí sloužících pro přenos libovolných dat. Pravidla by + zneplatnila scriptPubKey překračující 34 bajtů (kromě `OP_RETURN` + s maximálně 83 bajty), pushdata a položky v zásobníku witnessů + překračující 256 bajtů, utrácení nedefinovaných witness verzí, + přílohy [taprootu][topic taproot], kontrolní bloky překračující + 257 bajtů, opkódy `OP_SUCCESS` a `OP_IF`/`OP_NOTIF` + v [tapscriptech][topic tapscript]. Vstupy utrácející UTXO + vytvořená před aktivací mají výjimku. Aktivace používá modifikovaný + [BIP9][] se sníženým 55% prahem signalizace těžařů a povinnou + fixací zhruba před zářím 2026. Viz též [zpravodaj č. 379][news379 rdts] + (_angl._), který tento návrh již dříve popisoval. + +- [Bitcoin Inquisition #99][] přidává na [signet][topic signet] + implementaci [BIP54][], soft forku [pročištění konsenzu][topic consensus cleanup]. + Implementuje čtyři opatření: omezuje počet potenciálně spuštěných + zastaralých operací nad podpisy (sigops) za každou transakci, + zabraňuje útokům ohýbáním času (timewarp attacks) pomocí dvouhodinového + přechodného období (společně s nemožností negativních intervalů + úpravy složitosti), vyžaduje nastavení časového zámku mincetvorné + transakce na výšku bloku a zneplatňuje 64bajtové transakce. + +{% include snippets/recap-ad.md when="2026-02-17 17:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32420,8772,10507,4387,4355,4354,4303,784,2092,2004,2017,99" %} +[kmax mailing list]: https://groups.google.com/g/bitcoindev/c/tgcAQVqvzVg +[blisk del]: https://delvingbitcoin.org/t/blisk-boolean-circuit-logic-integrated-into-the-single-key/2217 +[ecdh wiki]: https://cs.wikipedia.org/wiki/Diffieho%E2%80%93Hellman%C5%AFv_protokol_s_vyu%C5%BEit%C3%ADm_eliptick%C3%BDch_k%C5%99ivek +[nizk wiki]: https://en.wikipedia.org/wiki/Non-interactive_zero-knowledge_proof +[blisk gh]: https://github.com/zero-art-rs/blisk +[Bitcoin Core 29.3]: https://bitcoincore.org/bin/bitcoin-core-29.3/ +[bcc29.3 rn]: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-29.3.md +[Bitcoin Inquisition 29.2]: https://github.com/bitcoin-inquisition/bitcoin/releases/tag/v29.2-inq +[HWI 3.2.0]: https://github.com/bitcoin-core/HWI/releases/tag/3.2.0 +[LDK 0.2.2]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.2.2 +[news387 wallet]: /cs/newsletters/2026/01/09/#chyba-v-migraci-penezenky-v-bitcoin-core +[news367 sighash]: /en/newsletters/2025/08/15/#bitcoin-core-32473 +[news367 discourage]: /en/newsletters/2025/08/15/#bitcoin-core-33050 +[news310 mining]: /cs/newsletters/2024/07/05/#bitcoin-core-30200 +[news193 legacy]: /en/newsletters/2022/03/30/#c-lightning-5058 +[news220 bolts]: /en/newsletters/2022/10/05/#bolts-962 +[news364 delegation]: /en/newsletters/2025/07/25/#chain-code-withholding-for-multisig-scripts +[news379 rdts]: /en/newsletters/2025/11/07/#temporary-soft-fork-to-reduce-data +[BIP89]: https://github.com/bitcoin/bips/blob/master/bip-0089.mediawiki diff --git a/_posts/cs/newsletters/2022-05-04-newsletter.md b/_posts/cs/newsletters/2022-05-04-newsletter.md index 43d0957738..a16fc8ddf8 100644 --- a/_posts/cs/newsletters/2022-05-04-newsletter.md +++ b/_posts/cs/newsletters/2022-05-04-newsletter.md @@ -21,30 +21,30 @@ verzí a významné změny v populárních bitcoinových infrastrukturních proj jež byl zmíněn ve [zpravodaji č. 195][news195 musig2] *(angl.)*. Připojil několik postřehů z implementace, na které on a další pracovali pro btcd a LND: - - *Interakce s BIP86:* klíče vytvořené podle [BIP32][topic bip32][^bip32] - peněženkou, která též implementuje [BIP86][][^bip86], se řídí doporučením - z [BIP341][][^bip341], aby byly klíče pro platbu klíčem vytvořeny tweaknutím[^tweak] - s hashem sebe sama. Napomáhá to zabránit situacím, ve kterých by mohl - účastník vícenásobného podpisu ([multisignature][topic multisignature]) - ukrást všechny prostředky tajným včleněním další platební podmínky. - Chtějí-li však účastníci vícenásobného podpisu tuto podmínku záměrně začlenit, - musejí sdílet verze svých klíčů před tweaknutím („interní klíč”). - - Osuntokun doporučuje, aby implementace BIP86 vracely jak původní, - interní klíč, tak i klíč tweaknutý. Uživatelé těchto implementací - by si potom mohli vybrat podle potřeby. - - - *Interakce s platbami skriptem:* Klíče určené pro platbu skriptem mají - podobný problém jako v předchozím odstavci: kdo utrácí, musí znát interní klíč. - I zde by napomohlo, kdyby implementace vracely také interní klíč. - - - *Zkratka pro posledního podepisujícího:* Osuntokun také požadoval - objasnění části návrhu, která umožňuje poslednímu podepisujícímu (a pouze - poslednímu) použít pro generování nonce[^nonce] deterministický zdroj - náhodných čísel nebo zdroj nižší kvality. Brandon Black v [odpovědi][black musig2] - popsal situaci, která stála za tímto návrhem: měli účastníka vícenásobného - podpisu, který neměl snadný přístup k bezpečnému prostředí, který ale - mohl pokaždé podepisovat až jako poslední. + - *Interakce s BIP86:* klíče vytvořené podle [BIP32][topic bip32][^bip32] + peněženkou, která též implementuje [BIP86][][^bip86], se řídí doporučením + z [BIP341][][^bip341], aby byly klíče pro platbu klíčem vytvořeny tweaknutím[^tweak] + s hashem sebe sama. Napomáhá to zabránit situacím, ve kterých by mohl + účastník vícenásobného podpisu ([multisignature][topic multisignature]) + ukrást všechny prostředky tajným včleněním další platební podmínky. + Chtějí-li však účastníci vícenásobného podpisu tuto podmínku záměrně začlenit, + musejí sdílet verze svých klíčů před tweaknutím („interní klíč”). + + Osuntokun doporučuje, aby implementace BIP86 vracely jak původní, + interní klíč, tak i klíč tweaknutý. Uživatelé těchto implementací + by si potom mohli vybrat podle potřeby. + + - *Interakce s platbami skriptem:* Klíče určené pro platbu skriptem mají + podobný problém jako v předchozím odstavci: kdo utrácí, musí znát interní klíč. + I zde by napomohlo, kdyby implementace vracely také interní klíč. + + - *Zkratka pro posledního podepisujícího:* Osuntokun také požadoval + objasnění části návrhu, která umožňuje poslednímu podepisujícímu (a pouze + poslednímu) použít pro generování nonce[^nonce] deterministický zdroj + náhodných čísel nebo zdroj nižší kvality. Brandon Black v [odpovědi][black musig2] + popsal situaci, která stála za tímto návrhem: měli účastníka vícenásobného + podpisu, který neměl snadný přístup k bezpečnému prostředí, který ale + mohl pokaždé podepisovat až jako poslední. - **Jak mezi uživateli měřit podporu změny konsenzu:** Keagan McClelland ve svém [příspěvku][mcclelland measure] do emailové skupiny Bitcoin-Dev navrhuje, @@ -196,19 +196,19 @@ Proposals (BIPs)][bips repo] a [Lightning BOLTs][bolts repo].* {% include references.md %} {% include linkers/issues.md v=2 issues="18554,24322,24304,21726,6064,557,981,6361,1425,3476" %} -[tetrud signal favor]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020350.html -[ivgi signal hodl voting]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020364.html -[aronesty signal parse scripts]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020354.html -[grant signal chainalysis]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020355.html -[bishop signal]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020346.html +[tetrud signal favor]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020350.html +[ivgi signal hodl voting]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020364.html +[aronesty signal parse scripts]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020354.html +[grant signal chainalysis]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020355.html +[bishop signal]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020346.html [news115 fee stealing]: /en/newsletters/2020/09/16/#stealing-onchain-fees-from-ln-htlcs -[osuntokun musig2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020361.html +[osuntokun musig2]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020361.html [news195 musig2]: /en/newsletters/2022/04/13/#musig2-proposed-bip -[black musig2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020371.html -[mcclelland measure]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020344.html -[teinturier security]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-April/003561.html -[myers recon]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-April/003551.html -[corallo recon]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-April/003556.html +[black musig2]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020371.html +[mcclelland measure]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020344.html +[teinturier security]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-April/003561.html +[myers recon]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-April/003551.html +[corallo recon]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-April/003556.html [genesis block]: https://en.bitcoin.it/wiki/Genesis_block [btcpay server 1.5.1]: https://github.com/btcpayserver/btcpayserver/releases/tag/v1.5.1 [minimalif bug]: https://bitcoindevkit.org/blog/miniscript-vulnerability/ diff --git a/_posts/cs/newsletters/2022-05-18-newsletter.md b/_posts/cs/newsletters/2022-05-18-newsletter.md index 6614daf208..37ed2feba8 100644 --- a/_posts/cs/newsletters/2022-05-18-newsletter.md +++ b/_posts/cs/newsletters/2022-05-18-newsletter.md @@ -425,28 +425,28 @@ projektech. Navíc oslavujeme 200. číslo zpravodaje. zobrazované informace byly co nejvíce kompaktní. Proto Ingala navrhuje několik vylepšení deskriptorů: - - *Registrace pravidel:* během úvodního nastavení podpisového zařízení - by měl uživatel na zařízení ověřit preferované pravidlo utrácení. - Zařízení s úložištěm by si měla registrovaná pravidla zapamatovat. - Pokud zařízení žádné úložiště nemá, mělo by vrátit kryptograficky - bezpečný doklad registrace, který může být spolu se samotným pravidlem - načten během zapínání zařízení. Návrh nepopisuje detaily, - jak by měla být pravidla na zařízeních registrována, ale poukazuje na - bezpečný způsob nastavení peněženek s vícenásobným podpisem ([BIP129][], - viz též [zpravodaj č. 136][news136 sms], *angl.*). - - - *Zástupné symboly klíčů:* namísto opakovaného vkládání rozšířených [BIP32][] - klíčů navrhuje Ingala umožnit pravidlům nadefinovat krátké symboly, které - by byly během interpretace pravidla nahrazeny BIP32 informacemi. - To by výrazně zmenšilo velikost pravidel a také je učinilo lépe - čitelnými. Ingala také navrhuje nahradit v deskriptorech - některé běžné řetězce zkratkami. - - - *Snížená vyjádřitelnost:* kvůli zjednodušení implementace je podporována - pouze podmnožina deskriptorů, avšak nové vlastnosti mohou být přidány - později, pokud bude vyžadováno. - - Během přípravy zpravodaje obdržel tento návrh v emailové skupině několik komentářů. + - *Registrace pravidel:* během úvodního nastavení podpisového zařízení + by měl uživatel na zařízení ověřit preferované pravidlo utrácení. + Zařízení s úložištěm by si měla registrovaná pravidla zapamatovat. + Pokud zařízení žádné úložiště nemá, mělo by vrátit kryptograficky + bezpečný doklad registrace, který může být spolu se samotným pravidlem + načten během zapínání zařízení. Návrh nepopisuje detaily, + jak by měla být pravidla na zařízeních registrována, ale poukazuje na + bezpečný způsob nastavení peněženek s vícenásobným podpisem ([BIP129][], + viz též [zpravodaj č. 136][news136 sms], *angl.*). + + - *Zástupné symboly klíčů:* namísto opakovaného vkládání rozšířených [BIP32][] + klíčů navrhuje Ingala umožnit pravidlům nadefinovat krátké symboly, které + by byly během interpretace pravidla nahrazeny BIP32 informacemi. + To by výrazně zmenšilo velikost pravidel a také je učinilo lépe + čitelnými. Ingala také navrhuje nahradit v deskriptorech + některé běžné řetězce zkratkami. + + - *Snížená vyjádřitelnost:* kvůli zjednodušení implementace je podporována + pouze podmnožina deskriptorů, avšak nové vlastnosti mohou být přidány + později, pokud bude vyžadováno. + + Během přípravy zpravodaje obdržel tento návrh v emailové skupině několik komentářů. ## Změny ve službách a klientech @@ -535,7 +535,9 @@ Wences Casares, John Pfeffer a Alex Morcos. {% assign sorted_praise = page.praise | sort_natural: "author" %} {% for comment in sorted_praise %}
+ {{comment.text | default: 'TODO'}} +
{:.right} @@ -554,35 +556,33 @@ Wences Casares, John Pfeffer a Alex Morcos. [^descriptors]: [deskriptory][topic descriptors] jsou řetězce, které popisují skripty výstupů; jsou používány peněženkami a jiným software [^signingdevices]: podpisová zařízení („signing devices”) byla dříve nepřesně označována za hardwarové peněženky; od tohoto názvu se již upouští - - {% include references.md %} {% include linkers/issues.md v=2 issues="22235,6450,6345,1309" %} [lnd 0.15.0-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.15.0-beta.rc1 [news27 eltoo]: /en/newsletters/2018/12/28/#april [news166 tluv]: /en/newsletters/2021/09/15/#amount-introspection [news190 recov]: /en/newsletters/2022/03/09/#limiting-script-language-expressiveness -[rubin op_tx recursive]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019872.html +[rubin op_tx recursive]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019872.html [minsc 1/3]: https://min.sc/#c=%24alice%20%3D%20A%3B%0A%24bob%20%3D%20B%3B%0A%24carol%20%3D%20C%3B%0A%0Apk%28%24alice%29%20%7C%7C%20pk%28%24bob%29%20%7C%7C%20pk%28%24carol%29 [news136 sms]: /en/newsletters/2021/02/17/#securely-setting-up-multisig-wallets [news183 dos]: /en/newsletters/2022/01/19/#mailing-list-discussion -[zmnscpxj cat1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020434.html +[zmnscpxj cat1]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020434.html [op_cat]: /en/topics/op_checksigfromstack/#relationship-to-op_cat [news187 op_tx]: /en/newsletters/2022/02/16/#simplified-alternative-to-op-txhash -[ivgi cat]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020442.html -[zmnscpxj cat2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020441.html -[oconnor cat]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020467.html +[ivgi cat]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020442.html +[zmnscpxj cat2]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020441.html +[oconnor cat]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020467.html [poelstra cat]: https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html [news190 recurse]: /en/newsletters/2022/03/09/#introduction-of-turing-completeness -[zmnscpxj cat3]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020462.html +[zmnscpxj cat3]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020462.html [news134 cat]: /en/newsletters/2021/02/03/#replicating-op-checksigfromstack-with-bip340-and-op-cat [turing-complete]: https://en.wikipedia.org/wiki/Turing_completeness -[russell op_tx]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020450.html -[black op_tx]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020454.html -[sanders op_tx]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020458.html -[ingala desc]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020423.html +[russell op_tx]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020450.html +[black op_tx]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020454.html +[sanders op_tx]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020458.html +[ingala desc]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020423.html [supporters]: /#supporters -[founding sponsors]: /about/#founding-sponsors +[founding sponsors]: /en/about/#founding-sponsors [news191 pinning]: /en/newsletters/2022/03/16/#ideas-for-improving-rbf-policy [MyCitadel Wallet]: https://github.com/mycitadel/mycitadel-desktop [RGB]: https://www.rgbfaq.com/what-is-rgb diff --git a/_posts/cs/newsletters/2022-05-25-newsletter.md b/_posts/cs/newsletters/2022-05-25-newsletter.md index 43b13d3d15..aeeeefa130 100644 --- a/_posts/cs/newsletters/2022-05-25-newsletter.md +++ b/_posts/cs/newsletters/2022-05-25-newsletter.md @@ -33,8 +33,8 @@ a významných změn v populárních bitcoinových infrastrukturních projektech - `pckginfo1` poskytuje detaily o balíčku transakcí: jejich počet, identifikátory (wtxid), celkovou velikost (váhu) a celkový poplatek. - Jednotkový poplatek („feerate”) pro celý balíček se spočítá vydělením - celkového poplatku vahou. + Jednotkový poplatek („feerate”) pro celý balíček se spočítá vydělením + celkového poplatku vahou. Dále jsou existující zprávy `inv` a `getdata` rozšířeny o nový typ objektu `MSG_PCKG1`, který uzlu umožňuje informovat svá spojení o schopnosti @@ -70,14 +70,14 @@ a významných změn v populárních bitcoinových infrastrukturních projektech následující dvě nepotvrzené transakce, které jsou dostupné k začlenění v následujícím bloku: - * Alice prodává Bobovi za 1 ETH aktivum *x* - * Bob prodává *x* Carol za 2 ETH (Bob vydělává 1 ETH) + * Alice prodává Bobovi za 1 ETH aktivum *x* + * Bob prodává *x* Carol za 2 ETH (Bob vydělává 1 ETH)
Jsou-li tyto dvě výměny provedeny veřejným obchodovacím protokolem, může těžař Boba z transakce zcela odříznout: - * Alice prodává těžařovi Mallorymu za 1 ETH aktivum *x* - * Těžař Mallory prodává *x* Carol za 2 ETH (Mallory vydělává 1 ETH; Bob nevydělává nic) + * Alice prodává těžařovi Mallorymu za 1 ETH aktivum *x* + * Těžař Mallory prodává *x* Carol za 2 ETH (Mallory vydělává 1 ETH; Bob nevydělává nic)
Toto představuje samozřejmě problém pro Boba, vytváří to však také několik problémů pro celou síť. Prvním problémem je, že těžaři musí příležitosti @@ -206,11 +206,11 @@ V případě chyb či opomenutí spadá zodpovědnost zcela na nás. {% include linkers/issues.md v=2 issues="20799,6529,6524" %} [lnd 0.15.0-beta.rc3]: https://github.com/lightningnetwork/lnd/releases/tag/v0.15.0-beta.rc3 [Core Lightning 0.11.1]: https://github.com/ElementsProject/lightning/releases/tag/v0.11.1 -[zhao package]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020493.html +[zhao package]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020493.html [bip-package-relay]: https://github.com/bitcoin/bips/pull/1324 [zhao preso]: https://docs.google.com/presentation/d/1B__KlZO1VzxJGx-0DYChlWawaEmGJ9EGApEzrHqZpQc/edit#slide=id.p -[fd0 ctv9]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020501.html -[ctv9]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020501.html +[fd0 ctv9]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020501.html +[ctv9]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020501.html [bitmex flashbots]: https://blog.bitmex.com/flashbots/ [news165 waste]: /en/newsletters/2021/09/08/#bitcoin-core-22009 [wiki op_checkmultisig]: https://en.bitcoin.it/wiki/OP_CHECKMULTISIG diff --git a/_posts/cs/newsletters/2022-06-01-newsletter.md b/_posts/cs/newsletters/2022-06-01-newsletter.md index 63cd064aab..3f5e020e13 100644 --- a/_posts/cs/newsletters/2022-06-01-newsletter.md +++ b/_posts/cs/newsletters/2022-06-01-newsletter.md @@ -53,6 +53,6 @@ Proposals (BIPs)][bips repo] a [Lightning BOLTs][bolts repo].* [lnd 0.15.0-beta.rc3]: https://github.com/lightningnetwork/lnd/releases/tag/v0.15.0-beta.rc3 [hwi 2.1.1]: https://github.com/bitcoin-core/HWI/releases/tag/2.1.1 [news194 silent]: /en/newsletters/2022/04/06/#delinked-reusable-addresses -[w0xlt post]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020513.html +[w0xlt post]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020513.html [sp tutorial]: https://gist.github.com/w0xlt/72390ded95dd797594f80baba5d2e6ee [sp address]: https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8?permalink_comment_id=4177027#gistcomment-4177027 diff --git a/_posts/cs/newsletters/2022-06-15-newsletter.md b/_posts/cs/newsletters/2022-06-15-newsletter.md index d042384fb9..217f264a94 100644 --- a/_posts/cs/newsletters/2022-06-15-newsletter.md +++ b/_posts/cs/newsletters/2022-06-15-newsletter.md @@ -23,164 +23,164 @@ projektech. [zpravodaj č. 201][news201 relay]) obdržel v posledních několika týdnech další komentáře: - - *Limity:* Anthony Towns [se ptal][towns relay], zda - by vyjednávání mezi dvěma spojeními o podpoře přeposílání balíčků - nemělo obsahovat informace o nastaveních omezení velikosti a hloubky, - jinak by mohly uzly s nestandardním nastavením plýtvat datovým tokem - opakovanými oznámeními o balíčcích, které nevyžadovaly. Autorka BIP - Gloria Zhao [navrhuje][zhao negotiation], aby první verze protokolu - implikovala maximální velikost balíčku 25 transakcí a 101 000 vbyte. - - - *Zpráva pouze s grafem balíčku:* Eric Voskuil [doporučuje][voskuil graph], - aby spojení, které se dozví o transakci s vysokým poplatkem, která je - potomkem transakce s nízkým poplatkem, jen informovalo svá - spojení o vztahu mezi těmito dvěma transakcemi (tento vztah se nazývá - graf baličku). Příjemce by si potom mohl vyžádat transakce, které nemá. - V jiné části tohoto vlákna Towns [poznamenal][towns graph], že graf - nemůže být validován, dokud nebyly obdrženy všechny transakce. Musí se - tedy zajistit, aby spojení nemohla o grafu lhát za účelem zabránit - šíření transakce. - - - *Používání krátkých ID:* několik vývojářů navrhlo používat krátké - identifikátory ve stylu [BIP152][]. Zhao [vysvětlila][zhao sids], - že krátká ID by měla smysl pro přeposílání bloků, kde uzly nejdříve - validují proof of work nového bloku (jehož vytvoření je nákladné), - aby bylo pro útočníka nákladné zneužít tohoto mechanismu k plýtvání - zdrojů. Avšak pro přeposílání dat, která lze vytvářet snadno, by - mohla být krátká ID zneužita znova a znova, což by umožnilo - DoS útok. - - - *Nestandardní rodiče:* Suhas Daftuar [popisuje][daftuar repeat] - scénář, ve kterém by mohl uzel implementující přeposílání balíčků - dokola vyžadovat stejná data. To by se mohlo stát hlavně v případě, - kdy se pravidla přeposílání liší mezi staršími a novějšími uzly, - například po aktivaci soft forku. - - - *Těžkosti s oznamováním hashe bloku:* Daftuar také poznamenává, - že jedna z vlastností návrhu by mohla způsobit potíže jinému software. - Podle současného návrhu BIP se do každého oznámení o balíčku vkládá - hash bloku, který je pro uzel nejnovější. Umožňuje to příjemci - ignorovat balíčky týkající se starších bloků (nebo i jiného - block chainu). V takovém případě by balíček nemusel správně fungovat - s příjemcovým mempoolem. Jak však poznamenává Daftuar, pravděpodobně - existuje množství software, které odesílá transakce (a které by - nakonec posílalo i balíčky), ale neudržuje si přehled o hashi - nejnovějšího bloku. + - *Limity:* Anthony Towns [se ptal][towns relay], zda + by vyjednávání mezi dvěma spojeními o podpoře přeposílání balíčků + nemělo obsahovat informace o nastaveních omezení velikosti a hloubky, + jinak by mohly uzly s nestandardním nastavením plýtvat datovým tokem + opakovanými oznámeními o balíčcích, které nevyžadovaly. Autorka BIP + Gloria Zhao [navrhuje][zhao negotiation], aby první verze protokolu + implikovala maximální velikost balíčku 25 transakcí a 101 000 vbyte. + + - *Zpráva pouze s grafem balíčku:* Eric Voskuil [doporučuje][voskuil graph], + aby spojení, které se dozví o transakci s vysokým poplatkem, která je + potomkem transakce s nízkým poplatkem, jen informovalo svá + spojení o vztahu mezi těmito dvěma transakcemi (tento vztah se nazývá + graf baličku). Příjemce by si potom mohl vyžádat transakce, které nemá. + V jiné části tohoto vlákna Towns [poznamenal][towns graph], že graf + nemůže být validován, dokud nebyly obdrženy všechny transakce. Musí se + tedy zajistit, aby spojení nemohla o grafu lhát za účelem zabránit + šíření transakce. + + - *Používání krátkých ID:* několik vývojářů navrhlo používat krátké + identifikátory ve stylu [BIP152][]. Zhao [vysvětlila][zhao sids], + že krátká ID by měla smysl pro přeposílání bloků, kde uzly nejdříve + validují proof of work nového bloku (jehož vytvoření je nákladné), + aby bylo pro útočníka nákladné zneužít tohoto mechanismu k plýtvání + zdrojů. Avšak pro přeposílání dat, která lze vytvářet snadno, by + mohla být krátká ID zneužita znova a znova, což by umožnilo + DoS útok. + + - *Nestandardní rodiče:* Suhas Daftuar [popisuje][daftuar repeat] + scénář, ve kterém by mohl uzel implementující přeposílání balíčků + dokola vyžadovat stejná data. To by se mohlo stát hlavně v případě, + kdy se pravidla přeposílání liší mezi staršími a novějšími uzly, + například po aktivaci soft forku. + + - *Těžkosti s oznamováním hashe bloku:* Daftuar také poznamenává, + že jedna z vlastností návrhu by mohla způsobit potíže jinému software. + Podle současného návrhu BIP se do každého oznámení o balíčku vkládá + hash bloku, který je pro uzel nejnovější. Umožňuje to příjemci + ignorovat balíčky týkající se starších bloků (nebo i jiného + block chainu). V takovém případě by balíček nemusel správně fungovat + s příjemcovým mempoolem. Jak však poznamenává Daftuar, pravděpodobně + existuje množství software, které odesílá transakce (a které by + nakonec posílalo i balíčky), ale neudržuje si přehled o hashi + nejnovějšího bloku. - **Shrnutí sezení vývojářů LN:** Olaoluwa Osuntokun poskytl [podrobné shrnutí][osuntokun summary] sezení vývojářů LN, které se konalo minulý týden v Oaklandu. Probíraná témata: - - *Taprootové LN kanály:* účastníci debatovali o první krocích přechodu - LN k plnému využití schopností [taprootu][topic taproot]. Následovat - bude zřejmě začlenění podpory pro [PTLC][topic ptlc][^ptlc] (viz též - [zpravodaj č. 164][news164 taproot ln], *angl.*). - - - *Tapscript a MuSig2[^musig2]:* součástí přechodu na taprootové - kanály je také převod současných skriptů na taprootové způsobem, - který by nejefektivněji využíval blokový prostor. Žádoucí by též - bylo používat [MuSig2][topic musig] pro tvorbu podpisů v místech, - kde se předpokládá spolupráce obou podepisujících. Obě tyto potřeby musí - být naimplementovány a řádně otestovány. - - - *Rekurzivní MuSig2:* jednoduchá implementace MuSig2 umožňuje Alici - a Bobovi se společně podílet na tvorbě podpisu. Rekurzivní MuSig2 by - například umožnil Alici vytvořit svou část podpisu za použití své - horké peněženky i hardwarového podepisujícího zařízení, aniž by - Bob musel učinit jakékoliv zvláštní kroky či vůbec tušil, že Alice - podepsala více než jedním klíčem. Diskutováno bylo, jak navrhnout - použití MuSig2 v LN tak, aby byl rekurzivní MuSig2 k dispozici. - Probírána byla také bezpečnost rekurzivního MuSig2. - - - *BOLT jako rozšíření:* alternativní způsob změn specifikace - protokolu LN. V současnosti se specifikace mění aplikací patche - (diff) na existující specifikaci. Avšak někteří vývojáři preferují - způsob použitý u BIP, kde jsou významné změny protokolu specifikovány - v jednom či více dedikovaných dokumentech. Tito vývojáři věří, že - oddělené dokumenty se snáze čtou i píší a mohly by tak - zjednodušit a zrychlit vývoj. - - - *Aktualizace gossip protokolu:* pokračovalo se v existující - debatě o aktualizaci LN gossip protokolu (viz [zpravodaj č. 188][news188 - gossip], *angl.*), který se používá pro přeposílání oznámení o nových - a pozměněných kanálech. Dle shrnutí by účastníci sezení upřednostňovali - soustředit se v blízké budoucnosti na drobnější změny protokolu: - podpora taprootových kanálů s MuSig2 a plné využití [TLV][news55 tlv][^tlv]. - - - *Efektivní gossip s minisketchem:* jak bylo zmíněno ve [zpravodaji č. 198][news198 - minisketch], pokračuje zkoumání použití knihovny [minisketch][topic minisketch] - s cílem snížit datové nároky LN gossip protokolu mezi uzly, což - by také mohlo snížit nejnižší povolenou dobu mezi aktualizacemi. - - - *DoS onion zpráv:* několik implementací LN již podporuje [onion zprávy][topic - onion messages] jako alternativu k posílání zpráv použitím [keysend][topic - spontaneous payments] plateb i jako komunikační vrstvu pro navrhovaný - [BOLT12 protocol][topic offers] pro nabídky. Avšak jak bylo zmíněno - ve [zpravodaji č. 190][news190 onion] (*angl.*), někteří vývojáři - se obávají, že onion zprávy mohou být zranitelné vůči několika - typům DoS útoků. Několik způsobů ochrany proti DoS bylo diskutováno. - - - *Zaslepené cesty:* mechanismus („blinded paths”) navržený před několika - lety (viz [zpravodaj č. 85][news85 blinded], *angl.*) a dnes používaný - pro onion zprávy je předmětem experimentů pro použití s běžnými platbami. - Umožnil by tím přijímat platby, aniž by byla odhalena identita adresátova - LN uzlu. Výzvou toho přístupu je nutnost komunikace většího množství - routovacích informací, vyžadovány jsou tedy objemnější faktury. Efektivní - implementace tak může záviset na novějších protokolech jako BOLT12 - nabídky nebo [LNURL][]. Diskutováno bylo také několik dalších - obav. - - - *Sondování a sdílení zůstatku:* použitím různých technik je možné - *vysondovat* zůstatky na kanálech v síti. Toto sondování lze provádět - v podstatě zdarma, ale může vedle ztráty soukromí způsobit potíže i - běžným uživatelům sítě. Opatření proti nesouvisejícímu [útoku - zahlcením kanálu][topic channel jamming attacks] („channel jamming - attack”) mohou pomoci omezit sondování, ale v současnosti stále - budí obavy. Účastníci diskutovali o některých rychlých změnách - nastavení uzlu, které by mohly sondování ztížit. - - Jeden myšlenkový experiment, o kterém se již dříve diskutovalo, - se zabýval sdílením informací, které by bylo možné získat sondováním. - Kdyby tak činil každý uzel, datové nároky a ztráta soukromí by - znegovaly hlavní výhody LN, ale zefektivnilo by to routování - plateb. Nikdo tuto myšlenku nenavrhuje, ale diskutovalo se o - dřívějším nápadu, že by každý uzel sdílel tyto informace pouze - se svými kanály. Někteří tvrdili, že by to mohlo významně navýšit - podíl úspěšných plateb, například doplněním o [Just-In-Time (JIT) - vyrovnání zůstatků][topic jit routing]. - - - *Trampolínové routování a mobilní platby:* - [trampolínové routování][topic trampoline payments] umožňuje plátci - delegovat hledání cesty na jiný uzel v síti bez ztráty soukromí (např. - odhalením plátce a adresáta). Toto delegování je užitečné především - pro mobilní LN klienty, které se nesnaží přeposílat jiné platby - pro jiné uzly. Bylo zmíněno, že trampolínové platby by mohly být - zkombinovány se *zadržením platby prvním bodem cesty* - (viz [zpravodaj č. 171][news171 ln offline], *angl.*), kde je - platba pozastavena uzlem, se kterým má plátce otevřený kanál, do doby, - než je příjemce online. To by umožňovalo mobilním uzlům, které - jsou často offline, spolehlivě přijímat platby od jiných mobilních - uzlů. - - - *LNURL s BOLT12:* LNURL protokol umožňuje uzlu vyžádat si [BOLT11][] - fakturu z webového serveru. BOLT12 [nabídky][topic offers] umožňují - vyžádat si fakturu z uzlu sítě. Mezi jinými aspekty těchto protokolů - diskutovali účastníci, jak by mohly být tyto dva protokoly navzájem - kompatibilní, aby mohly uzly používat oba dva. + - *Taprootové LN kanály:* účastníci debatovali o první krocích přechodu + LN k plnému využití schopností [taprootu][topic taproot]. Následovat + bude zřejmě začlenění podpory pro [PTLC][topic ptlc][^ptlc] (viz též + [zpravodaj č. 164][news164 taproot ln], *angl.*). + + - *Tapscript a MuSig2[^musig2]:* součástí přechodu na taprootové + kanály je také převod současných skriptů na taprootové způsobem, + který by nejefektivněji využíval blokový prostor. Žádoucí by též + bylo používat [MuSig2][topic musig] pro tvorbu podpisů v místech, + kde se předpokládá spolupráce obou podepisujících. Obě tyto potřeby musí + být naimplementovány a řádně otestovány. + + - *Rekurzivní MuSig2:* jednoduchá implementace MuSig2 umožňuje Alici + a Bobovi se společně podílet na tvorbě podpisu. Rekurzivní MuSig2 by + například umožnil Alici vytvořit svou část podpisu za použití své + horké peněženky i hardwarového podepisujícího zařízení, aniž by + Bob musel učinit jakékoliv zvláštní kroky či vůbec tušil, že Alice + podepsala více než jedním klíčem. Diskutováno bylo, jak navrhnout + použití MuSig2 v LN tak, aby byl rekurzivní MuSig2 k dispozici. + Probírána byla také bezpečnost rekurzivního MuSig2. + + - *BOLT jako rozšíření:* alternativní způsob změn specifikace + protokolu LN. V současnosti se specifikace mění aplikací patche + (diff) na existující specifikaci. Avšak někteří vývojáři preferují + způsob použitý u BIP, kde jsou významné změny protokolu specifikovány + v jednom či více dedikovaných dokumentech. Tito vývojáři věří, že + oddělené dokumenty se snáze čtou i píší a mohly by tak + zjednodušit a zrychlit vývoj. + + - *Aktualizace gossip protokolu:* pokračovalo se v existující + debatě o aktualizaci LN gossip protokolu (viz [zpravodaj č. 188][news188 + gossip], *angl.*), který se používá pro přeposílání oznámení o nových + a pozměněných kanálech. Dle shrnutí by účastníci sezení upřednostňovali + soustředit se v blízké budoucnosti na drobnější změny protokolu: + podpora taprootových kanálů s MuSig2 a plné využití [TLV][news55 tlv][^tlv]. + + - *Efektivní gossip s minisketchem:* jak bylo zmíněno ve [zpravodaji č. 198][news198 + minisketch], pokračuje zkoumání použití knihovny [minisketch][topic minisketch] + s cílem snížit datové nároky LN gossip protokolu mezi uzly, což + by také mohlo snížit nejnižší povolenou dobu mezi aktualizacemi. + + - *DoS onion zpráv:* několik implementací LN již podporuje [onion zprávy][topic + onion messages] jako alternativu k posílání zpráv použitím [keysend][topic + spontaneous payments] plateb i jako komunikační vrstvu pro navrhovaný + [BOLT12 protocol][topic offers] pro nabídky. Avšak jak bylo zmíněno + ve [zpravodaji č. 190][news190 onion] (*angl.*), někteří vývojáři + se obávají, že onion zprávy mohou být zranitelné vůči několika + typům DoS útoků. Několik způsobů ochrany proti DoS bylo diskutováno. + + - *Zaslepené cesty:* mechanismus („blinded paths”) navržený před několika + lety (viz [zpravodaj č. 85][news85 blinded], *angl.*) a dnes používaný + pro onion zprávy je předmětem experimentů pro použití s běžnými platbami. + Umožnil by tím přijímat platby, aniž by byla odhalena identita adresátova + LN uzlu. Výzvou toho přístupu je nutnost komunikace většího množství + routovacích informací, vyžadovány jsou tedy objemnější faktury. Efektivní + implementace tak může záviset na novějších protokolech jako BOLT12 + nabídky nebo [LNURL][]. Diskutováno bylo také několik dalších + obav. + + - *Sondování a sdílení zůstatku:* použitím různých technik je možné + *vysondovat* zůstatky na kanálech v síti. Toto sondování lze provádět + v podstatě zdarma, ale může vedle ztráty soukromí způsobit potíže i + běžným uživatelům sítě. Opatření proti nesouvisejícímu [útoku + zahlcením kanálu][topic channel jamming attacks] („channel jamming + attack”) mohou pomoci omezit sondování, ale v současnosti stále + budí obavy. Účastníci diskutovali o některých rychlých změnách + nastavení uzlu, které by mohly sondování ztížit. + + Jeden myšlenkový experiment, o kterém se již dříve diskutovalo, + se zabýval sdílením informací, které by bylo možné získat sondováním. + Kdyby tak činil každý uzel, datové nároky a ztráta soukromí by + znegovaly hlavní výhody LN, ale zefektivnilo by to routování + plateb. Nikdo tuto myšlenku nenavrhuje, ale diskutovalo se o + dřívějším nápadu, že by každý uzel sdílel tyto informace pouze + se svými kanály. Někteří tvrdili, že by to mohlo významně navýšit + podíl úspěšných plateb, například doplněním o [Just-In-Time (JIT) + vyrovnání zůstatků][topic jit routing]. + + - *Trampolínové routování a mobilní platby:* + [trampolínové routování][topic trampoline payments] umožňuje plátci + delegovat hledání cesty na jiný uzel v síti bez ztráty soukromí (např. + odhalením plátce a adresáta). Toto delegování je užitečné především + pro mobilní LN klienty, které se nesnaží přeposílat jiné platby + pro jiné uzly. Bylo zmíněno, že trampolínové platby by mohly být + zkombinovány se *zadržením platby prvním bodem cesty* + (viz [zpravodaj č. 171][news171 ln offline], *angl.*), kde je + platba pozastavena uzlem, se kterým má plátce otevřený kanál, do doby, + než je příjemce online. To by umožňovalo mobilním uzlům, které + jsou často offline, spolehlivě přijímat platby od jiných mobilních + uzlů. + + - *LNURL s BOLT12:* LNURL protokol umožňuje uzlu vyžádat si [BOLT11][] + fakturu z webového serveru. BOLT12 [nabídky][topic offers] umožňují + vyžádat si fakturu z uzlu sítě. Mezi jinými aspekty těchto protokolů + diskutovali účastníci, jak by mohly být tyto dva protokoly navzájem + kompatibilní, aby mohly uzly používat oba dva. - **Signalizace likvidity routovacími poplatky:** vývojář ZmnSCPxj poslal do emailové skupiny Lightning-Dev [příspěvek][zmnscpxj hilolohi] s tezí, jak by bylo možné optimálně dosáhnout levných a spolehlivých plateb díky aplikaci teorie her na chování plátců a routovacích uzlů: - - Plátci by měli volit cesty s nižšími routovacími poplatky. + - Plátci by měli volit cesty s nižšími routovacími poplatky. - - Routovací uzly by měly se snižující se kapacitou kanálu žádat - vyšší poplatky. Například pokud je většina zůstatku kanálu na straně - Alice, může spolehlivě přeposílat platby Bobovi a tak by nemusela - žádat vysoké poplatky. Ale jak se zůstatek kanálu přelévá směrem - k Bobovi, schopnost Alice přeposílat platby se snižuje; měla by - si tedy nechat platit více na poplatcích. + - Routovací uzly by měly se snižující se kapacitou kanálu žádat + vyšší poplatky. Například pokud je většina zůstatku kanálu na straně + Alice, může spolehlivě přeposílat platby Bobovi a tak by nemusela + žádat vysoké poplatky. Ale jak se zůstatek kanálu přelévá směrem + k Bobovi, schopnost Alice přeposílat platby se snižuje; měla by + si tedy nechat platit více na poplatcích. ZmnSCPxj argumentuje ekonomií nabídky a poptávky: se zvyšující se poptávkou po platbách jedním směrem (např. od Alice k Bobovi) se nabídka @@ -255,13 +255,13 @@ Proposals (BIPs)][bips repo] a [Lightning BOLTs][bolts repo].* {% include linkers/issues.md v=2 issues="24171,1505,628,593" %} [lnd 0.15.0-beta.rc6]: https://github.com/lightningnetwork/lnd/releases/tag/v0.15.0-beta.rc6 [news201 relay]: /cs/newsletters/2022/05/25/#navrh-na-preposilani-balicku -[towns relay]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020496.html -[zhao negotiation]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020512.html -[voskuil graph]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020518.html -[towns graph]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020520.html -[zhao sids]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020539.html -[daftuar repeat]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020542.html -[osuntokun summary]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003600.html +[towns relay]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020496.html +[zhao negotiation]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020512.html +[voskuil graph]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020518.html +[towns graph]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020520.html +[zhao sids]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020539.html +[daftuar repeat]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020542.html +[osuntokun summary]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003600.html [news164 taproot ln]: /en/newsletters/2021/09/01/#preparing-for-taproot-11-ln-with-taproot [news188 gossip]: /en/newsletters/2022/02/23/#updated-ln-gossip-proposal [news55 tlv]: /en/newsletters/2019/07/17/#bolts-607 @@ -270,4 +270,4 @@ Proposals (BIPs)][bips repo] a [Lightning BOLTs][bolts repo].* [news85 blinded]: /en/newsletters/2020/02/19/#decoy-nodes-and-lightweight-rendez-vous-routing [lnurl]: https://github.com/fiatjaf/lnurl-rfc [news171 ln offline]: /en/newsletters/2021/10/20/#paying-offline-ln-nodes -[zmnscpxj hilolohi]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003598.html +[zmnscpxj hilolohi]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003598.html diff --git a/_posts/cs/newsletters/2022-06-22-newsletter.md b/_posts/cs/newsletters/2022-06-22-newsletter.md index 5fac0e141b..cdb5e6a4a0 100644 --- a/_posts/cs/newsletters/2022-06-22-newsletter.md +++ b/_posts/cs/newsletters/2022-06-22-newsletter.md @@ -76,20 +76,20 @@ bitcoinových infrastrukturních projektech. Zdrojem debaty byla existence dvou rozdílných designů systémů pro vytváření časových značek („timestamping”): - - *Důkaz existence časovou značkou (Time Stamped Proofs of Existence, TSPoE)*: - bitcoinová transakce se zavazuje k hashi, který se zavazuje k nějakému - dokumentu. Když je tato transakce potvrzena v bloku, může tvůrce - závazku („commitment”) dokázat třetí straně, že zmíněný dokument - existoval v čase vytvoření bloku. Všimněte si, že každá transakce - s časovou značkou je zcela nezávislá na jiné takové transakci. - Znamená to, že je možné vytvořit časovou značku stejného dokumentu - opakovaně bez jakéhokoliv spojení mezi nimi. - - - *Řazení událostí (Event Ordering, EO):* v série transakcí navzájem - spojených předepsaným způsobem se každá zavazuje k dokumentům tak, - že komukoliv umožňuje shlédnout všechny tyto závazky. - Je možné určit, kdy získal kterýkoliv z těchto dokumentů časovou - značku poprvé. + - *Důkaz existence časovou značkou (Time Stamped Proofs of Existence, TSPoE)*: + bitcoinová transakce se zavazuje k hashi, který se zavazuje k nějakému + dokumentu. Když je tato transakce potvrzena v bloku, může tvůrce + závazku („commitment”) dokázat třetí straně, že zmíněný dokument + existoval v čase vytvoření bloku. Všimněte si, že každá transakce + s časovou značkou je zcela nezávislá na jiné takové transakci. + Znamená to, že je možné vytvořit časovou značku stejného dokumentu + opakovaně bez jakéhokoliv spojení mezi nimi. + + - *Řazení událostí (Event Ordering, EO):* v série transakcí navzájem + spojených předepsaným způsobem se každá zavazuje k dokumentům tak, + že komukoliv umožňuje shlédnout všechny tyto závazky. + Je možné určit, kdy získal kterýkoliv z těchto dokumentů časovou + značku poprvé. Systém TSPoE, jak byl implementován v OTS, je v podstatě dokonale efektivní. Využívá stejné množství globálního prostoru k uložení časových značek @@ -216,16 +216,16 @@ Proposals (BIPs)][bips repo] a [Lightning BOLTs][bolts repo].* [lnd 0.15.0-beta.rc6]: https://github.com/lightningnetwork/lnd/releases/tag/v0.15.0-beta.rc6 [ldk 0.0.108]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.0.108 [bdk 0.19.0]: https://github.com/bitcoindevkit/bdk/releases/tag/v0.19.0 -[rbf discussion]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html +[rbf discussion]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html [hertzbleed]: https://www.hertzbleed.com/ [news116 sponsorship]: /en/newsletters/2020/09/23/#transaction-fee-sponsorship -[poelstra timestamping]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020569.html -[gibson riddle post]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020555.html +[poelstra timestamping]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020569.html +[gibson riddle post]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020555.html [gibson riddle gist]: https://gist.github.com/AdamISZ/51349418be08be22aa2b4b469e3be92f [bitcoin stack exchange]: https://bitcoin.stackexchange.com/ [open timestamps]: https://opentimestamps.org/ [sybil]: https://en.wikipedia.org/wiki/Sybil_attack -[zmnscpxj riddle]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003607.html +[zmnscpxj riddle]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003607.html [Zeus v0.6.5-rc1]: https://github.com/ZeusLN/zeus/releases/tag/v0.6.5-rc1 [wasabi 2.0]: https://github.com/zkSNACKs/WalletWasabi/releases/tag/v2.0.0.0 [news194 wabisabi]: /en/newsletters/2022/04/06/#wabisabi-alternative-to-payjoin diff --git a/_posts/cs/newsletters/2022-11-30-newsletter.md b/_posts/cs/newsletters/2022-11-30-newsletter.md index ca30df431f..fed7599e69 100644 --- a/_posts/cs/newsletters/2022-11-30-newsletter.md +++ b/_posts/cs/newsletters/2022-11-30-newsletter.md @@ -37,18 +37,18 @@ změnách oblíbeného bitcoinového páteřního software. svá pravidla vydávání osvědčení, Riard však navrhuje několik způsobů jejich distribuce: - - *Předplatné:* chce-li Alice poslat platbu přes Bobův uzel, může nejdřív - od Boba zakoupit osvědčení (přes LN). + - *Předplatné:* chce-li Alice poslat platbu přes Bobův uzel, může nejdřív + od Boba zakoupit osvědčení (přes LN). - - *Předchozí úspěšná platba:* Bobův uzel může Alici poslat osvědčení - (jedno nebo více) za úspěšně provedenou platbu. Díky těmto osvědčením - může Alice opět v budoucnu poslat platby přes Bobův uzel. + - *Předchozí úspěšná platba:* Bobův uzel může Alici poslat osvědčení + (jedno nebo více) za úspěšně provedenou platbu. Díky těmto osvědčením + může Alice opět v budoucnu poslat platby přes Bobův uzel. - - *Důkazy vlastnictví UTXO:* někteří prostředníci mohou experimentovat - s vydáváním osvědčení každému, kdo předloží důkaz o vlastnictví bitcoinového - UTXO. Lze například udělit více osvědčení za starší nebo hodnotnější - UTXO. Jelikož si každý prostředník sám zvolí pravidla - udělování osvědčení, mohou být použita i jakákoliv jiná kritéria. + - *Důkazy vlastnictví UTXO:* někteří prostředníci mohou experimentovat + s vydáváním osvědčení každému, kdo předloží důkaz o vlastnictví bitcoinového + UTXO. Lze například udělit více osvědčení za starší nebo hodnotnější + UTXO. Jelikož si každý prostředník sám zvolí pravidla + udělování osvědčení, mohou být použita i jakákoliv jiná kritéria. Clara Shikhelman, která je spoluautorkou podobného návrhu částečně založeného na lokální reputaci popsaného ve [zpravodaji č. 226][news226 jam] (*angl.*), @@ -133,13 +133,13 @@ Proposals (BIPs)][bips repo] a [Lightning BOLTs][bolts repo].* [lnd 0.15.5-beta.rc2]: https://github.com/lightningnetwork/lnd/releases/tag/v0.15.5-beta.rc2 [core lightning 22.11rc3]: https://github.com/ElementsProject/lightning/releases/tag/v22.11rc3 [cln json ids]: https://github.com/rustyrussell/lightning/blob/a25c5d14fe986b67178988e6ebb79610672cc829/doc/lightningd-rpc.7.md#json-ids -[riard credentials]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003754.html +[riard credentials]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003754.html [riard proposal]: https://github.com/lightning/bolts/blob/80214c83190836c4f7699af9e8920769607f1a00/www-reputation-credentials-protocol.md [blind signature]: https://en.wikipedia.org/wiki/Blind_signature [news226 jam]: /en/newsletters/2022/11/16/#paper-about-channel-jamming-attacks -[shikelman credentials]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003755.html -[riard double spend]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003765.html -[harding paths]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003767.html +[shikelman credentials]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003755.html +[riard double spend]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003765.html +[harding paths]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003767.html [ecdh]: https://cs.wikipedia.org/wiki/Diffieho%E2%80%93Hellman%C5%AFv_protokol_s_vyu%C5%BEit%C3%ADm_eliptick%C3%BDch_k%C5%99ivek [semantic versioning]: https://semver.org/lang/cs/spec/v2.0.0.html [news201 package relay]: /cs/newsletters/2022/05/25/#navrh-na-preposilani-balicku diff --git a/_posts/cs/newsletters/2022-12-07-newsletter.md b/_posts/cs/newsletters/2022-12-07-newsletter.md index a64d658910..8a11e3dd13 100644 --- a/_posts/cs/newsletters/2022-12-07-newsletter.md +++ b/_posts/cs/newsletters/2022-12-07-newsletter.md @@ -220,7 +220,7 @@ Proposals (BIPs)][bips repo] a [Lightning BOLTs][bolts repo].* [news223 anchors]: /en/newsletters/2022/10/26/#ephemeral-anchors [news224 anchors]: /en/newsletters/2022/11/02/#anchor-outputs-workaround [news220 v3tx]: /en/newsletters/2022/10/05/#proposed-new-transaction-relay-policies-designed-for-ln-penalty -[sanders ephemeral]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021222.html +[sanders ephemeral]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021222.html [review club 26152]: https://bitcoincore.reviews/26152 [review club 26152-2]: https://bitcoincore.reviews/26152-2 [rusty semver]: https://github.com/ElementsProject/lightning/issues/5716#issuecomment-1322745630 diff --git a/_posts/cs/newsletters/2022-12-14-newsletter.md b/_posts/cs/newsletters/2022-12-14-newsletter.md index 0e1fab7523..123160d328 100644 --- a/_posts/cs/newsletters/2022-12-14-newsletter.md +++ b/_posts/cs/newsletters/2022-12-14-newsletter.md @@ -29,46 +29,46 @@ popisem významných změn populárních páteřních bitcoinových projektů. Law poznamenává, že existující protokol LN kanálů (obecně zvaný LN–penalty) přináší kanálům otevřeným v rámci továrny dva problémy: - - *Požadavek na dlouhé expirace HTLC:* možnost provést akci bez nutnosti - důvěry vyžaduje, aby byl kterýkoliv účastník továrny schopen odstoupit - a obdržet zpět své prostředky. Aby toho dosáhli, musí účastníci - publikovat aktuální bilanci na blockchainu. Je však potřeba zajistit, - aby nikdo nepublikoval dřívější stav, např. takový, za kterého - měli na své straně více peněz. Původní návrh na továrny k tomu - využívá transakce s časovým zámkem, které zajistí, že novější stav - je potvrzen rychleji než starší. - - Důsledkem tohoto mechanismu, jak popisuje Law, je, že jakákoliv - LN platba (tj. [HTLC][topic htlc]), která je směrována kanálem - z továrny, musí poskytnout dostatečně dlouhý čas na expiraci časového - zámku posledního stavu, aby mohla být továrna jednostranně zavřena. - Ještě horší je, že toto platí pro každou továrnu, přes kterou - je platba směrována. Například je-li platba směrována přes deset - továren, kde má každá z nich jednodenní expiraci, může se stát, že bude - tato platba [pozdržena][topic channel jamming attacks], úmyslně - či ne, na deset dní (nebo déle v závislosti na nastavení HTLC). - - - *Všichni, nebo nic:* aby mohly továrny dosáhnout maximální - efektivnosti, musí všechny její kanály být též uzavřeny v jediné - transakci. Spolupráce na uzavření není možná, je-li některý - z původních účastníků nedostupný; se zvyšujícím se počtem - účastníků se šance na jednoho nedostupného blíží 100 % a možnost - efektivních továren tak klesá. - - Law se odkazuje na předchozí práci – např. návhy - `OP_TAPLEAF_UPDATE_VERIFY` a `OP_EVICT` (viz zpravodaj - [č. 166][news166 tluv] a [č. 189][news189 evict], *angl.*), ve které - mohla továrna zůstat funkční, i když ji jeden z účastníků chtěl opustit - nebo zůstal nedostupný. - - Law představuje tři návrhy protokolu, které tyto problémy řeší. Všechny - jsou založené na jeho předchozím návrhu na *nastavitelné pokuty*, - o kterém [informoval][law tp] v říjnu. Ten nabízí možnost oddělit - mechanismus vynucování (pokuty) od správy ostatních prostředků. Tento - předchozí návrh ještě neobdržel komentáře. V době psaní tohoto článku - nebyla otevřena diskuze ani pod jeho novým návrhem. Budou-li návrhy - přesvědčivé, měly by na rozdíl od jiných výhodu v možnosti použít - stávající pravidla bitcoinového konsenzu. + - *Požadavek na dlouhé expirace HTLC:* možnost provést akci bez nutnosti + důvěry vyžaduje, aby byl kterýkoliv účastník továrny schopen odstoupit + a obdržet zpět své prostředky. Aby toho dosáhli, musí účastníci + publikovat aktuální bilanci na blockchainu. Je však potřeba zajistit, + aby nikdo nepublikoval dřívější stav, např. takový, za kterého + měli na své straně více peněz. Původní návrh na továrny k tomu + využívá transakce s časovým zámkem, které zajistí, že novější stav + je potvrzen rychleji než starší. + + Důsledkem tohoto mechanismu, jak popisuje Law, je, že jakákoliv + LN platba (tj. [HTLC][topic htlc]), která je směrována kanálem + z továrny, musí poskytnout dostatečně dlouhý čas na expiraci časového + zámku posledního stavu, aby mohla být továrna jednostranně zavřena. + Ještě horší je, že toto platí pro každou továrnu, přes kterou + je platba směrována. Například je-li platba směrována přes deset + továren, kde má každá z nich jednodenní expiraci, může se stát, že bude + tato platba [pozdržena][topic channel jamming attacks], úmyslně + či ne, na deset dní (nebo déle v závislosti na nastavení HTLC). + + - *Všichni, nebo nic:* aby mohly továrny dosáhnout maximální + efektivnosti, musí všechny její kanály být též uzavřeny v jediné + transakci. Spolupráce na uzavření není možná, je-li některý + z původních účastníků nedostupný; se zvyšujícím se počtem + účastníků se šance na jednoho nedostupného blíží 100 % a možnost + efektivních továren tak klesá. + + Law se odkazuje na předchozí práci – např. návhy + `OP_TAPLEAF_UPDATE_VERIFY` a `OP_EVICT` (viz zpravodaj + [č. 166][news166 tluv] a [č. 189][news189 evict], *angl.*), ve které + mohla továrna zůstat funkční, i když ji jeden z účastníků chtěl opustit + nebo zůstal nedostupný. + + Law představuje tři návrhy protokolu, které tyto problémy řeší. Všechny + jsou založené na jeho předchozím návrhu na *nastavitelné pokuty*, + o kterém [informoval][law tp] v říjnu. Ten nabízí možnost oddělit + mechanismus vynucování (pokuty) od správy ostatních prostředků. Tento + předchozí návrh ještě neobdržel komentáře. V době psaní tohoto článku + nebyla otevřena diskuze ani pod jeho novým návrhem. Budou-li návrhy + přesvědčivé, měly by na rozdíl od jiných výhodu v možnosti použít + stávající pravidla bitcoinového konsenzu. - **Lokální zahlcení k zamezení vzdáleného zahlcení:** Joost Jager [zaslal][jager jam] do emailové skupiny Lightning-Dev odkaz a vysvětlení @@ -96,45 +96,45 @@ popisem významných změn populárních páteřních bitcoinových projektů. neexpirovaný HTLC ve frontě. Jager popisuje dvě výhody tohoto přístupu: - - *Backpressure:* odmítne-li uzel uprostřed okruhu HTLC, všechny uzly - v okruhu (ne jen ty následující) mohou použít tento HTLC slot a - prostředky na přeposlání další platby. To znamená, že motivace - Alice odmítnout více než 10 HTLC od Malloryho je omezená: může - jednoduše doufat, že jiný uzel dále v okruhu používá CircuitBreaker - či podobný software. - - Pokud však následující uzel (řekněme Bob) používá CircuiBreaker - k uložení přebytečných HTLC do fronty, mohl by Mallory i tak - vyčerpat sloty a prostředky Alice, i když by si Bob a následující - uzly zachovaly stejné výhody jako nyní (s výjimkou možného - navýšení nákladů na uzavření kanálu v určitých případech; pro více - podrobností viz Jagerův email nebo dokumentace CircuitBreakeru). - To vyvíjí drobný tlak na Alici, aby CircuitBreaker nebo podobný - program používala. - - - *Původce selhání:* současný LN protokol dává v mnoha případech - odesílateli možnost identifikovat kanál, který odmítl přeposlat - platbu. Některé implementace se snaží takovému kanálu v budoucnu - vyhnout. V případě odmítnutí HTLC od zlomyslníků jako Mallory to - ze zřejmých důvodů nevadí, odmítne-li však uzel s CircuitBreakerem - HTLC od čestných plátců, mohlo by to snížit jejich výdělek nejen z - odmítnuté platby, ale i z plateb následujících. - - LN protokol však v současnosti nemá široce používaný způsob - určení, který kanál zpozdil HTLC. Zpoždění HTLC tak nese - méně vážné důsledky než prosté odmítnutí. Jager poznamenává, že - tato výhoda může brzy zmizet, neboť mnoho LN implementací pracuje - na podpoře podrobnějších chybových zpráv (viz [zpravodaj č. 224][news224 - fat], *angl.*). - - Jager nazývá CircuitBreaker „jednoduchý, ale nedokonalý nástroj na - ochranu před zahlcením kanálu a spamem.” Práce pokračují na nalezení - a nasazení změn na úrovni protokolu, které by lépe zamezovaly těmto - útokům, ale CircuitBreaker se vyjímá jako slušné řešení, které je - kompatibilní se současným LN protokolem a které může kterýkoliv - uživatel LND hned nasadit. CircuitBreaker je licencovaný pod MIT - a je konceptuálně jednoduchý, mělo by tedy být možné jej přizpůsobit - či portovat i na jiné LN implementace. + - *Backpressure:* odmítne-li uzel uprostřed okruhu HTLC, všechny uzly + v okruhu (ne jen ty následující) mohou použít tento HTLC slot a + prostředky na přeposlání další platby. To znamená, že motivace + Alice odmítnout více než 10 HTLC od Malloryho je omezená: může + jednoduše doufat, že jiný uzel dále v okruhu používá CircuitBreaker + či podobný software. + + Pokud však následující uzel (řekněme Bob) používá CircuiBreaker + k uložení přebytečných HTLC do fronty, mohl by Mallory i tak + vyčerpat sloty a prostředky Alice, i když by si Bob a následující + uzly zachovaly stejné výhody jako nyní (s výjimkou možného + navýšení nákladů na uzavření kanálu v určitých případech; pro více + podrobností viz Jagerův email nebo dokumentace CircuitBreakeru). + To vyvíjí drobný tlak na Alici, aby CircuitBreaker nebo podobný + program používala. + + - *Původce selhání:* současný LN protokol dává v mnoha případech + odesílateli možnost identifikovat kanál, který odmítl přeposlat + platbu. Některé implementace se snaží takovému kanálu v budoucnu + vyhnout. V případě odmítnutí HTLC od zlomyslníků jako Mallory to + ze zřejmých důvodů nevadí, odmítne-li však uzel s CircuitBreakerem + HTLC od čestných plátců, mohlo by to snížit jejich výdělek nejen z + odmítnuté platby, ale i z plateb následujících. + + LN protokol však v současnosti nemá široce používaný způsob + určení, který kanál zpozdil HTLC. Zpoždění HTLC tak nese + méně vážné důsledky než prosté odmítnutí. Jager poznamenává, že + tato výhoda může brzy zmizet, neboť mnoho LN implementací pracuje + na podpoře podrobnějších chybových zpráv (viz [zpravodaj č. 224][news224 + fat], *angl.*). + + Jager nazývá CircuitBreaker „jednoduchý, ale nedokonalý nástroj na + ochranu před zahlcením kanálu a spamem.” Práce pokračují na nalezení + a nasazení změn na úrovni protokolu, které by lépe zamezovaly těmto + útokům, ale CircuitBreaker se vyjímá jako slušné řešení, které je + kompatibilní se současným LN protokolem a které může kterýkoliv + uživatel LND hned nasadit. CircuitBreaker je licencovaný pod MIT + a je konceptuálně jednoduchý, mělo by tedy být možné jej přizpůsobit + či portovat i na jiné LN implementace. - **Monitorování full-RBF nahrazování:** vývojář 0xB10C [oznámil][0xb10c rbf] v emailové skupině Bitcoin-Dev, že začal poskytovat [veřejně přístupný][rbf mpo] @@ -288,16 +288,16 @@ budou pokračovat ve středu 4. ledna. [bcc rn]: https://bitcoincore.org/en/releases/24.0.1/ [bcc milestone 24.0.1]: https://github.com/bitcoin/bitcoin/milestone/59?closed=1 [libsecp256k1 0.2.0]: https://github.com/bitcoin-core/secp256k1/releases/tag/v0.2.0 -[libsecp256k1 announce]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021271.html +[libsecp256k1 announce]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021271.html [core lightning 22.11.1]: https://github.com/ElementsProject/lightning/releases/tag/v22.11.1 [news224 fat]: /en/newsletters/2022/11/02/#ln-routing-failure-attribution -[law factory]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-December/003782.html +[law factory]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-December/003782.html [news166 tluv]: /en/newsletters/2021/09/15/#covenant-opcode-proposal [news189 evict]: /en/newsletters/2022/03/02/#proposed-opcode-to-simplify-shared-utxo-ownership -[law tp]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-October/003732.html -[jager jam]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-December/003781.html +[law tp]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-October/003732.html +[jager jam]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-December/003781.html [circuitbreaker]: https://github.com/lightningequipment/circuitbreaker -[0xb10c rbf]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021258.html +[0xb10c rbf]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021258.html [rbf mpo]: https://fullrbf.mempool.observer/ [news208 rbf]: /en/newsletters/2022/07/13/#bitcoin-core-25353 [tlv]: https://github.com/lightning/bolts/blob/master/01-messaging.md#type-length-value-format diff --git a/_posts/cs/newsletters/2023-01-04-newsletter.md b/_posts/cs/newsletters/2023-01-04-newsletter.md index 325c3eb123..5940087492 100644 --- a/_posts/cs/newsletters/2023-01-04-newsletter.md +++ b/_posts/cs/newsletters/2023-01-04-newsletter.md @@ -25,55 +25,55 @@ software. - **Softwarové forky Bitcoin Core:** minulý měsíc byly vydány dvě modifikace Bitcoin Core: - - *Bitcoin Inquisition:* Anthony Towns [oznámil][towns bci] v emailové - skupině Bitcoin-Dev novou verzi [Bitcoin Inquisition][], softwarového - forku Bitcoin Core navrženého k testování soft forků a jiných změn protokolu - na [signetu][topic signet]. Tato verze obsahuje podporu pro navrhované - [SIGHASH_ANYPREVOUT][topic sighash_anyprevout] a [OP_CHECKTEMPLATEVERIFY][topic - op_checktemplateverify]. Townsův email dále obsahuje dodatečné informace pro - každého, kdy bych se chtěl tohoto testování zúčastnit. - - - *Uzel pro full RBF spojení:* Peter Todd [oznámil][todd rbf node] - patch Bitcoin Core 24.0.1, který nastavuje [full-RBF service bit][] - během oznamování síťových adres dalším uzlům, avšak pouze má-li - uzel nastavenu volbu `mempoolfullrbf`. Uzly běžící s tímto patchem - se navíc připojují až k čtyřem dalším uzlům oznamujícím podporu pro - full RBF. Peter Todd poznamenává, že Bitcoin Knots, jiná implementace - plného uzlu, také oznamuje tento service bit, i když neobsahuje obdobný - kód pro připojování. Patch je založen na Bitcoin Core pull requestu - [#25600][bitcoin core #25600]. + - *Bitcoin Inquisition:* Anthony Towns [oznámil][towns bci] v emailové + skupině Bitcoin-Dev novou verzi [Bitcoin Inquisition][], softwarového + forku Bitcoin Core navrženého k testování soft forků a jiných změn protokolu + na [signetu][topic signet]. Tato verze obsahuje podporu pro navrhované + [SIGHASH_ANYPREVOUT][topic sighash_anyprevout] a [OP_CHECKTEMPLATEVERIFY][topic + op_checktemplateverify]. Townsův email dále obsahuje dodatečné informace pro + každého, kdy bych se chtěl tohoto testování zúčastnit. + + - *Uzel pro full RBF spojení:* Peter Todd [oznámil][todd rbf node] + patch Bitcoin Core 24.0.1, který nastavuje [full-RBF service bit][] + během oznamování síťových adres dalším uzlům, avšak pouze má-li + uzel nastavenu volbu `mempoolfullrbf`. Uzly běžící s tímto patchem + se navíc připojují až k čtyřem dalším uzlům oznamujícím podporu pro + full RBF. Peter Todd poznamenává, že Bitcoin Knots, jiná implementace + plného uzlu, také oznamuje tento service bit, i když neobsahuje obdobný + kód pro připojování. Patch je založen na Bitcoin Core pull requestu + [#25600][bitcoin core #25600]. - **Pokračuje diskuze o RBF:** v pokračující diskuzi o aktivaci [full-RBF][topic rbf] na mainnetu se minulý měsíc v emailové skupině rozvíjelo několik paralelních debat: - - *Uzly s full RBF:* Peter Todd prozkoumal plné uzly, které oznamovaly, - že provozovaly Bitcoin Core 24.x a akceptovaly spojení na IPv4 adrese. - [Zjistil][todd probe], že kolem 17 % přeposílalo full RBF nahrazení: - transakce, které nahradily transakce bez [BIP125][] signálu. - Může to znamenat, že tyto uzly měly aktivovánu volbu `mempoolfullrbf`, - i když je ve výchozím stavu vypnuta. - - - *Nové úvahy o RBF-FSS:* Daniel Lipshitz [zaslal][lipshitz - fss] do emailové skupiny Bitcoin-Dev nápad na druh nahrazování - transakcí nazývaný First Seen Safe (FSS), kde by nahrazující transakce - platila původním výstupům minimálně stejnou částku jako původní transakce. - To by zaručilo, že by mechanismus nahrazování nemohl být použit - ke krádeži prostředků od příjemce původní transakce. Yuval Kogman ve - své [odpovědi][kogman fss] připojil odkaz na [ranější verzi][rbf-fss] - stejné myšlenky sdílené v roce 2015 Peterem Toddem. Todd v - [následující odpovědi][todd fss] popsal, proč je tento způsob - méně preferovaný než opt-in nebo full RBF. - - - *Motivace k full RBF:* Anthony Towns zaslal do vlákna [příspěvek][towns - rbfm] s výčtem motivací různých skupin k používání full RBF. Towns - analyzuje, co znamená a neznamená ekonomická racionalita v kontextu - výběru transakcí těžařem. Těžaři optimalizující pro krátkodobý profit - by přirozeně preferovali full RBF. Avšak, poznamenává Towns, těžaři, - kteří učinili dlouhodobé kapitálové investice do zařízení, mohou namísto - toho optimalizovat příjem z poplatků napříč několika bloky a nemusí - tak nezbytně nutně upřednostňovat full RBF. Navrhuje k úvaze tři různé - scénáře. + - *Uzly s full RBF:* Peter Todd prozkoumal plné uzly, které oznamovaly, + že provozovaly Bitcoin Core 24.x a akceptovaly spojení na IPv4 adrese. + [Zjistil][todd probe], že kolem 17 % přeposílalo full RBF nahrazení: + transakce, které nahradily transakce bez [BIP125][] signálu. + Může to znamenat, že tyto uzly měly aktivovánu volbu `mempoolfullrbf`, + i když je ve výchozím stavu vypnuta. + + - *Nové úvahy o RBF-FSS:* Daniel Lipshitz [zaslal][lipshitz + fss] do emailové skupiny Bitcoin-Dev nápad na druh nahrazování + transakcí nazývaný First Seen Safe (FSS), kde by nahrazující transakce + platila původním výstupům minimálně stejnou částku jako původní transakce. + To by zaručilo, že by mechanismus nahrazování nemohl být použit + ke krádeži prostředků od příjemce původní transakce. Yuval Kogman ve + své [odpovědi][kogman fss] připojil odkaz na [ranější verzi][rbf-fss] + stejné myšlenky sdílené v roce 2015 Peterem Toddem. Todd v + [následující odpovědi][todd fss] popsal, proč je tento způsob + méně preferovaný než opt-in nebo full RBF. + + - *Motivace k full RBF:* Anthony Towns zaslal do vlákna [příspěvek][towns + rbfm] s výčtem motivací různých skupin k používání full RBF. Towns + analyzuje, co znamená a neznamená ekonomická racionalita v kontextu + výběru transakcí těžařem. Těžaři optimalizující pro krátkodobý profit + by přirozeně preferovali full RBF. Avšak, poznamenává Towns, těžaři, + kteří učinili dlouhodobé kapitálové investice do zařízení, mohou namísto + toho optimalizovat příjem z poplatků napříč několika bloky a nemusí + tak nezbytně nutně upřednostňovat full RBF. Navrhuje k úvaze tři různé + scénáře. ## Vydání nových verzí @@ -171,15 +171,15 @@ Proposals (BIPs)][bips repo] a [Lightning BOLTs][bolts repo].* {% include linkers/issues.md v=2 issues="26265,21576,24865,23319,26628,2464,2482,2208,1738,1908,1467,1330,4411,25600" %} [news172 prevout]: /en/newsletters/2021/10/27/#bitcoin-core-22918 [weight units]: https://en.bitcoin.it/wiki/Weight_units -[towns bci]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021275.html +[towns bci]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021275.html [bitcoin inquisition]: https://github.com/bitcoin-inquisition/bitcoin -[todd probe]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021296.html -[lipshitz fss]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021272.html -[kogman fss]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021274.html -[todd fss]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021286.html -[rbf-fss]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html -[towns rbfm]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021276.html -[todd rbf node]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021270.html +[todd probe]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021296.html +[lipshitz fss]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021272.html +[kogman fss]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021274.html +[todd fss]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021286.html +[rbf-fss]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html +[towns rbfm]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021276.html +[todd rbf node]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021270.html [news229 cln]: /cs/newsletters/2022/12/07/#core-lightning-22-11 [full-rbf service bit]: https://github.com/petertodd/bitcoin/commit/c15b8d70778238abfa751e4216a97140be6369af [eclair 0.8.0]: https://github.com/ACINQ/eclair/releases/tag/v0.8.0 diff --git a/_posts/cs/newsletters/2023-01-11-newsletter.md b/_posts/cs/newsletters/2023-01-11-newsletter.md index 6db894dc4c..15d359f62f 100644 --- a/_posts/cs/newsletters/2023-01-11-newsletter.md +++ b/_posts/cs/newsletters/2023-01-11-newsletter.md @@ -46,9 +46,9 @@ páteřních projektech. podpisem Alice a buď Bobovým podpisem nebo expirací několikatýdenního časového zámku (např. 6 000 bloků). [Příklad][potentiam minsc]: - ```hack - pk(A) && (pk(B) || older(6000)) - ``` + ```hack + pk(A) && (pk(B) || older(6000)) + ``` Tato adresa může obdržet platbu a nabírat konfirmace, zatímco je Alice offline. Dokud platba nedosáhne expiračního počtu konfirmací, musí Bob @@ -121,7 +121,7 @@ Proposals (BIPs)][bips repo] a [Lightning BOLTs][bolts repo].* {% include linkers/issues.md v=2 issues="2455,1021" %} [bdk 0.26.0]: https://github.com/bitcoindevkit/bdk/releases/tag/v0.26.0 [hwi 2.2.0-rc1]: https://github.com/bitcoin-core/HWI/releases/tag/2.2.0-rc.1 -[zp potentiam]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-January/003810.html +[zp potentiam]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-January/003810.html [potentiam minsc]: https://min.sc/#c=pk%28A%29%20%26%26%20%28pk%28B%29%20%7C%7C%20older%286000%29%29 -[fournier potentiam]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-January/003813.html +[fournier potentiam]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-January/003813.html [news224 fat]: /en/newsletters/2022/11/02/#ln-routing-failure-attribution diff --git a/_posts/cs/newsletters/2023-01-18-newsletter.md b/_posts/cs/newsletters/2023-01-18-newsletter.md index 271328e114..250f1dae53 100644 --- a/_posts/cs/newsletters/2023-01-18-newsletter.md +++ b/_posts/cs/newsletters/2023-01-18-newsletter.md @@ -19,123 +19,123 @@ páteřního software. op_vault] do emailové skupiny Bitcoin-Dev [návrh][obeirne paper] na soft fork, který by přidal dva nové opkódy: `OP_VAULT` a `OP_UNVAULT`. - - `OP_VAULT` by vyžadoval tři parametry: commitment vysoce - důvěryhodného způsobu platby, [dobu čekání][topic timelocks] - a commitment méně důveryhodného způsobu platby. - - - `OP_UNVAULT` by také vyžadoval tři parametry. V případě použití - podle O'Beirneových představ by tyto parametry byly: stejný - commitment vysoce důvěryhodného způsobu platby, stejná doba - čekání a commitment jednoho nebo více výstupů pro použití - v pozdější transakci. - - Pro vytvoření [úschovny][topic vaults] („vault”) si Alice zvolí - vysoce důvěryhodný způsob platby, např. vícenásobný podpis vyžadující - přístup k několika odděleným podpisovým zařízením nebo studeným - peněženkám uloženým v různých lokalitách. Též si zvolí méně - důvěryhodný způsob platby, jako je jednoduchý podpis ze své horké - peněženky. Nakonec si zvolí dobu čekání ve stejném formátu jako [BIP68][], - který umožní stanovit dobu od několika minut po zhruba rok. Dále - Alice vytvoří běžnou bitcoinovou adresu pro přijetí prostředků - do své úschovny. Tato adresa bude zavázána skriptu používajícímu - `OP_VAULT`. - - Bude-li chtít Alice utratit prostředky dříve přijaté do své úschovny, - začne určením výstupů, kterým si v konečném důsledky přála platit - (např. platba Bobovi a návrat zbytku zpět do úschovny). V obvyklém - případě by Alice naplnila podmínky svého méně důvěryhodného způsobu - platby, např. poskytnutím podpisu ze své horké peněženky, k vytvoření - transakce posílající veškeré uschované prostředky na jediný výstup. - Tento výstup obsahuje `OP_UNVAULT` se stejnými parametry vysoce - důvěryhodného způsobu platby a doby čekání. Třetím parametrem je - commitment výstupům, kterým Alice chce nakonec platit. Alice nyní - může dokončit konstrukci transakce, včetně stanovení poplatků - pomocí [sponzorování poplatků][topic fee sponsorship] („fee - sponsorship”, typ [anchor výstupů][topic anchor outputs]) či jiného - mechanismu. - - Alice transakci odešle a později je zařazena do bloku. To umožní - komukoliv povšimnout si, že probíhá proces o otevření úschovny - („unvault”). Alicin software detekuje utrácení jejích uschovaných - prostředků a ověří, že třetí parametr `OP_UNVAULT` výstupu - potvrzené transakce přesně odpovídá commitmentu, který Alice - předtím vytvořila. Odpovídá-li, počká nyní Alice stanovenou dobu, - po které může odeslat transakci utrácející z `OP_UNVAULT` UTXO - na výstupy, které dříve stanovila (např. Bobovi a zbytek platby - sobě). Toto by bylo úspěšné utracení Aliciných prostředků použitím - jejího méně důvěryhodného způsobu platby, např. pomocí horké - peněženky. - - Avšak představte si, že Alicin software spatří potvrzený pokus o - otevření úschovny a nerozpoznává jej. V takovém případě má software - možnost zmrazit prostředky během čekací doby. Vytvoří transakci - utrácející `OP_UNVAULT` výstup na vysoce důvěryhodnou adresu, která - byla součástí předchozích commitmentů. Pokud se tato transakce - potvrdí, než vyprší čekací doba, jsou Aliciny prostředky v bezpečí - před kompromitací jejího méně důvěryhodného způsobu platby. Poté, - co byly prostředky přesunuty, může je Alice kdykoliv utratit - splněním podmínek vysoce důvěryhodného způsobu platby (například - studenou peněženkou). - - Vedle nových opkódů popisuje O'Beirne také motivaci pro úschovny - a analyzuje i jiné způsoby včetně těch, které již nyní v bitcoinu - existují (používající dopředu podepsané transakce), i takových, - které by závisely na navrhovaném soft forku pro přidání [koventantů][topic - covenants]. Některé z výhod tohoto návrhu: - - - *Menší witnessy:* návrhy flexibilních kovenantů, jako ty používající - navhovaný [OP_CHECKSIGFROMSTACK][topic op_checksigfromstack], - by vyžadovaly, aby witnessy pro transakce otevření úschovny - obsahovaly kopie velkého množství dat z jiných míst transakce. - Tím by se navyšovala velikost a poplatky za tuto transkaci. - `OP_VAULT` vyžaduje mnohem menší skripty a witnessy. - - - *Utrácení vyžaduje méně kroků:* dnes dostupné méně flexibilní - návrhy koventantů a úschoven, které jsou založené na předem - podepsaných transakcích, vyžadují vybrání prostředků na - předurčenou adresu před tím, než mohou být odeslány do konečné - destinace. Tyto návrhy také většinou vyžadují, aby byl každý - výstup utracen v separátní transakci, což znemožňuje použití - [skupinových plateb][topic payment batching]. To navyšuje - počet transakcí, jejich velikost i náklady. - - `OP_VAULT` vyžaduje méně transakcí v typickém případě utrácení - jediného výstupu a také podporuje skupinové transakce v případě - utrácení nebo zmrazování více výstupů. Může tedy ušetřit - velké množství prostoru a umožnit úschovnám obdržet mnohem - více transakcí před tím, než je potřeba konsolidovat jejich - výstupy kvůli bezpečnosti. - - V diskuzi o tomto nápadu navrhl Greg Sanders (jak [shrnul O'Beirne][obeirne - scripthash]) mírně odlišnou konstrukci, která „by například umožnila, - aby byly všechny výstupy [P2TR][topic taproot], což by skrylo - operace nad úschovnou – docela dobrá fíčura.” - - Anthony Towns [poznamenává][towns op_vault], že návrh umožňuje - uživatelům úschoven kdykoliv zmrazit prostředky jejich pouhým - posláním na vysoce důvěryhodnou adresu, ze které je mohou později - rozmrazit. To přináší majitelům úschoven velkou výhodu, protože - k blokaci pokusu o krádež nepotřebují přístup ke svým vysoce - zabezpečeným klíčům (např. ke studeným peněženkám). Na druhou stranu - může každá třetí strana, která se adresu dozví, také zmrazit - uživatelovy prostředky (i když bude muset zaplatit poplatek), což - uživatelovi přinese nepříjemnosti. Aby mohly odlehčené peněženky - nalézt své transakce na blockchainu, prozrazuje mnoho z nich - své adresy třetím stranám. Úschovny postavené na těchto peněženkách - by tak mohly dát neúmyslně třetím stranám možnost přinést jejich - uživatelům nepříjemnosti. Towns navrhuje - alternativní konstrukci podmínek zmrazení tak, aby při iniciaci - zmrazování vyžadovaly nějakou dodatečnou informaci. To by zachovalo - všechny výhody tohoto systému a také by snížilo riziko - nezamýšleného zmrazení. Towns také navrhuje možné vylepšení - podpory skupinových transakcí a zamýšlí se nad podporou taprootu. - - Několik reakcí též zmínilo, že `OP_UNVAULT` může poskytnout mnoho - vlastností navrhovaného [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] - (CTV) včetně výhod pro [DLC][topic dlc] dříve popsané ve [zpravodaji č. 185][news185 - ctv-dlc] (*angl.*), i když s většími náklady na blockchainu. - - V době psaní zpravodaje diskuze stála probíhala. + - `OP_VAULT` by vyžadoval tři parametry: commitment vysoce + důvěryhodného způsobu platby, [dobu čekání][topic timelocks] + a commitment méně důveryhodného způsobu platby. + + - `OP_UNVAULT` by také vyžadoval tři parametry. V případě použití + podle O'Beirneových představ by tyto parametry byly: stejný + commitment vysoce důvěryhodného způsobu platby, stejná doba + čekání a commitment jednoho nebo více výstupů pro použití + v pozdější transakci. + + Pro vytvoření [úschovny][topic vaults] („vault”) si Alice zvolí + vysoce důvěryhodný způsob platby, např. vícenásobný podpis vyžadující + přístup k několika odděleným podpisovým zařízením nebo studeným + peněženkám uloženým v různých lokalitách. Též si zvolí méně + důvěryhodný způsob platby, jako je jednoduchý podpis ze své horké + peněženky. Nakonec si zvolí dobu čekání ve stejném formátu jako [BIP68][], + který umožní stanovit dobu od několika minut po zhruba rok. Dále + Alice vytvoří běžnou bitcoinovou adresu pro přijetí prostředků + do své úschovny. Tato adresa bude zavázána skriptu používajícímu + `OP_VAULT`. + + Bude-li chtít Alice utratit prostředky dříve přijaté do své úschovny, + začne určením výstupů, kterým si v konečném důsledky přála platit + (např. platba Bobovi a návrat zbytku zpět do úschovny). V obvyklém + případě by Alice naplnila podmínky svého méně důvěryhodného způsobu + platby, např. poskytnutím podpisu ze své horké peněženky, k vytvoření + transakce posílající veškeré uschované prostředky na jediný výstup. + Tento výstup obsahuje `OP_UNVAULT` se stejnými parametry vysoce + důvěryhodného způsobu platby a doby čekání. Třetím parametrem je + commitment výstupům, kterým Alice chce nakonec platit. Alice nyní + může dokončit konstrukci transakce, včetně stanovení poplatků + pomocí [sponzorování poplatků][topic fee sponsorship] („fee + sponsorship”, typ [anchor výstupů][topic anchor outputs]) či jiného + mechanismu. + + Alice transakci odešle a později je zařazena do bloku. To umožní + komukoliv povšimnout si, že probíhá proces o otevření úschovny + („unvault”). Alicin software detekuje utrácení jejích uschovaných + prostředků a ověří, že třetí parametr `OP_UNVAULT` výstupu + potvrzené transakce přesně odpovídá commitmentu, který Alice + předtím vytvořila. Odpovídá-li, počká nyní Alice stanovenou dobu, + po které může odeslat transakci utrácející z `OP_UNVAULT` UTXO + na výstupy, které dříve stanovila (např. Bobovi a zbytek platby + sobě). Toto by bylo úspěšné utracení Aliciných prostředků použitím + jejího méně důvěryhodného způsobu platby, např. pomocí horké + peněženky. + + Avšak představte si, že Alicin software spatří potvrzený pokus o + otevření úschovny a nerozpoznává jej. V takovém případě má software + možnost zmrazit prostředky během čekací doby. Vytvoří transakci + utrácející `OP_UNVAULT` výstup na vysoce důvěryhodnou adresu, která + byla součástí předchozích commitmentů. Pokud se tato transakce + potvrdí, než vyprší čekací doba, jsou Aliciny prostředky v bezpečí + před kompromitací jejího méně důvěryhodného způsobu platby. Poté, + co byly prostředky přesunuty, může je Alice kdykoliv utratit + splněním podmínek vysoce důvěryhodného způsobu platby (například + studenou peněženkou). + + Vedle nových opkódů popisuje O'Beirne také motivaci pro úschovny + a analyzuje i jiné způsoby včetně těch, které již nyní v bitcoinu + existují (používající dopředu podepsané transakce), i takových, + které by závisely na navrhovaném soft forku pro přidání [koventantů][topic + covenants]. Některé z výhod tohoto návrhu: + + - *Menší witnessy:* návrhy flexibilních kovenantů, jako ty používající + navhovaný [OP_CHECKSIGFROMSTACK][topic op_checksigfromstack], + by vyžadovaly, aby witnessy pro transakce otevření úschovny + obsahovaly kopie velkého množství dat z jiných míst transakce. + Tím by se navyšovala velikost a poplatky za tuto transkaci. + `OP_VAULT` vyžaduje mnohem menší skripty a witnessy. + + - *Utrácení vyžaduje méně kroků:* dnes dostupné méně flexibilní + návrhy koventantů a úschoven, které jsou založené na předem + podepsaných transakcích, vyžadují vybrání prostředků na + předurčenou adresu před tím, než mohou být odeslány do konečné + destinace. Tyto návrhy také většinou vyžadují, aby byl každý + výstup utracen v separátní transakci, což znemožňuje použití + [skupinových plateb][topic payment batching]. To navyšuje + počet transakcí, jejich velikost i náklady. + + `OP_VAULT` vyžaduje méně transakcí v typickém případě utrácení + jediného výstupu a také podporuje skupinové transakce v případě + utrácení nebo zmrazování více výstupů. Může tedy ušetřit + velké množství prostoru a umožnit úschovnám obdržet mnohem + více transakcí před tím, než je potřeba konsolidovat jejich + výstupy kvůli bezpečnosti. + + V diskuzi o tomto nápadu navrhl Greg Sanders (jak [shrnul O'Beirne][obeirne + scripthash]) mírně odlišnou konstrukci, která „by například umožnila, + aby byly všechny výstupy [P2TR][topic taproot], což by skrylo + operace nad úschovnou – docela dobrá fíčura.” + + Anthony Towns [poznamenává][towns op_vault], že návrh umožňuje + uživatelům úschoven kdykoliv zmrazit prostředky jejich pouhým + posláním na vysoce důvěryhodnou adresu, ze které je mohou později + rozmrazit. To přináší majitelům úschoven velkou výhodu, protože + k blokaci pokusu o krádež nepotřebují přístup ke svým vysoce + zabezpečeným klíčům (např. ke studeným peněženkám). Na druhou stranu + může každá třetí strana, která se adresu dozví, také zmrazit + uživatelovy prostředky (i když bude muset zaplatit poplatek), což + uživatelovi přinese nepříjemnosti. Aby mohly odlehčené peněženky + nalézt své transakce na blockchainu, prozrazuje mnoho z nich + své adresy třetím stranám. Úschovny postavené na těchto peněženkách + by tak mohly dát neúmyslně třetím stranám možnost přinést jejich + uživatelům nepříjemnosti. Towns navrhuje + alternativní konstrukci podmínek zmrazení tak, aby při iniciaci + zmrazování vyžadovaly nějakou dodatečnou informaci. To by zachovalo + všechny výhody tohoto systému a také by snížilo riziko + nezamýšleného zmrazení. Towns také navrhuje možné vylepšení + podpory skupinových transakcí a zamýšlí se nad podporou taprootu. + + Několik reakcí též zmínilo, že `OP_UNVAULT` může poskytnout mnoho + vlastností navrhovaného [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] + (CTV) včetně výhod pro [DLC][topic dlc] dříve popsané ve [zpravodaji č. 185][news185 + ctv-dlc] (*angl.*), i když s většími náklady na blockchainu. + + V době psaní zpravodaje diskuze stála probíhala. ## Změny ve službách a klientech @@ -191,11 +191,11 @@ Proposals (BIPs)][bips repo] a [Lightning BOLTs][bolts repo].* {% include references.md %} {% include linkers/issues.md v=2 issues="5751,1378" %} [hwi 2.2.0]: https://github.com/bitcoin-core/HWI/releases/tag/2.2.0 -[obeirne op_vault]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021318.html +[obeirne op_vault]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021318.html [obeirne paper]: https://jameso.be/vaults.pdf -[obeirne scripthash]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021329.html +[obeirne scripthash]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021329.html [news185 ctv-dlc]: /en/newsletters/2022/02/02/#improving-dlc-efficiency-by-changing-script -[towns op_vault]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021328.html +[towns op_vault]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021328.html [kraken bech32m]: https://blog.kraken.com/post/16740/bitcoin-taproot-address-now-supported-on-kraken/ [whirlpool rust client]: https://github.com/straylight-orbit/whirlpool-client-rs [ledger miniscript]: https://blog.ledger.com/miniscript-is-coming/ diff --git a/_posts/cs/newsletters/2023-01-25-newsletter.md b/_posts/cs/newsletters/2023-01-25-newsletter.md index e59d88859c..10a4ce65a6 100644 --- a/_posts/cs/newsletters/2023-01-25-newsletter.md +++ b/_posts/cs/newsletters/2023-01-25-newsletter.md @@ -150,9 +150,9 @@ Proposals (BIPs)][bips repo] a [Lightning BOLTs][bolts repo].* {% include references.md %} {% include linkers/issues.md v=2 issues="26325,1383,1192" %} [news215 labels]: /en/newsletters/2022/08/31/#wallet-label-export-format -[towns e-vs-shg]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021334.html -[`sighash_group` proposal]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html -[wallace pop]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-January/003820.html +[towns e-vs-shg]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021334.html +[`sighash_group` proposal]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html +[wallace pop]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-January/003820.html [forced soft fork]: https://petertodd.org/2016/forced-soft-forks [remove builder keys]: https://github.com/bitcoin/bitcoin/commit/296e88225096125b08665b97715c5b8ebb1d28ec [guix.sigs repo]: https://github.com/bitcoin-core/guix.sigs/tree/main/builder-keys diff --git a/_posts/cs/newsletters/2023-02-01-newsletter.md b/_posts/cs/newsletters/2023-02-01-newsletter.md index 1c3173d7ef..de1f5c61e1 100644 --- a/_posts/cs/newsletters/2023-02-01-newsletter.md +++ b/_posts/cs/newsletters/2023-02-01-newsletter.md @@ -171,15 +171,15 @@ Proposals (BIPs)][bips repo] a [Lightning BOLTs][bolts repo].* {% include linkers/issues.md v=2 issues="26471,23395,2573,2574,2584,2540,1878,1860,7231" %} [common input ownership heuristic]: https://en.bitcoin.it/wiki/Privacy#Common-input-ownership_heuristic [news132 payjoin]: /en/newsletters/2021/01/20/#payjoin-adoption -[gould payjoin]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021364.html +[gould payjoin]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021364.html [payjoin impl]: https://github.com/chaincase-app/payjoin/pull/21 [noise protocol]: http://www.noiseprotocol.org/ [turn protocol]: https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT [nat]: https://cs.wikipedia.org/wiki/Network_address_translation [nostr protocol]: https://github.com/nostr-protocol/nostr [news235 async]: /cs/newsletters/2023/01/25/#pozadavek-dukazu-ze-asynchronni-platba-byla-prijata -[towns async]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-January/003831.html -[towns sa1]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001034.html -[towns sa2]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001490.html +[towns async]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-January/003831.html +[towns sa1]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001034.html +[towns sa2]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001490.html [osuntokun sigs]: https://github.com/lightningnetwork/lnd/pull/7231#issuecomment-1407138812 [p4tr new hd]: /en/preparing-for-taproot/#use-a-new-bip32-key-derivation-path diff --git a/_posts/cs/newsletters/2023-02-08-newsletter.md b/_posts/cs/newsletters/2023-02-08-newsletter.md index 4fdcf0d6e7..dda9a0886f 100644 --- a/_posts/cs/newsletters/2023-02-08-newsletter.md +++ b/_posts/cs/newsletters/2023-02-08-newsletter.md @@ -192,10 +192,10 @@ Proposals (BIPs)][bips repo] a [Lightning BOLTs][bolts repo].* {% include references.md %} {% include linkers/issues.md v=2 issues="25880,5679,5867,5821,5849,5892,2565,7252,6527" %} [news158 upfront]: /en/newsletters/2021/07/21/#eclair-1846 -[dickinson ordinal]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021370.html -[poelstra ordinal]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021372.html +[dickinson ordinal]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021370.html +[poelstra ordinal]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021372.html [news65 tapscript]: /en/newsletters/2019/09/25/#tapscript-resource-limits -[ckccs jamming]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-January/003834.html +[ckccs jamming]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-January/003834.html [news226 jam]: /en/newsletters/2022/11/16/#paper-about-channel-jamming-attacks [news230 jam]: /cs/newsletters/2022/12/14/#lokalni-zahlceni-k-zamezeni-vzdaleneho-zahlceni [news228 jam]: /cs/newsletters/2022/11/30/#navrh-na-pouziti-osvedceni-o-reputaci-k-zamezeni-zahlcovani-ln diff --git a/_posts/cs/newsletters/2023-02-15-newsletter.md b/_posts/cs/newsletters/2023-02-15-newsletter.md index df5c04adcc..d515022d83 100644 --- a/_posts/cs/newsletters/2023-02-15-newsletter.md +++ b/_posts/cs/newsletters/2023-02-15-newsletter.md @@ -23,47 +23,47 @@ na bitcoinovou technickou dokumentaci a diskuze. vláknech emailové skupiny Bitcoin-Dev pokračovala tento týden diskuze o ukládání dat v blockchainu. - - *Offchain obarvování mincí:* Anthony Towns [poslal][towns color] - souhrn protokolu používaného pro přiřazování zvláštního významu - některým výstupům. Těmto technikám se obecně říká *obarvování mincí*. - Též popsal související protokol používaný pro ukládání binárních - dat uvnitř bitcoinových transakcí a jejich asociaci s konkrétními - obarvenými mincemi. Po souhrnu současného stavu popsal metodu - pro ukládání dat pomocí zpráv na [Nostru][nostr] a jejich asociaci - s obarvenými mincemi, které by mohly být posílány v bitcoinových - transakcích. To by mělo několik výhod: - - - *Redukce nákladů:* žádné transakční poplatky za data přenášená - offchain. - - - *Soukromí:* dva lidé mohou vyměnit obarvené mince, aniž by - kdokoliv jiný věděl o datech, na která poukazují. - - - *Pro vytvoření není třeba transakce:* data mohou být asociována - s existujícími UTXO, není nutné vytvářet nová UTXO. - - - *Odolnost vůči cenzuře:* není-li asociace mezi daty a obarvenými - mincemi běžně známa, je posílání obarvených mincí natolik odolné - vůči cenzuře, jako je sám bitcoin. - - Ve spojení s odolností vůči cenzuře Towns říká, že „obarvené - bitcoiny jsou v podstatě nevyhnutelné a něco, s čím se musíme - potýkat, spíš než něco, co se snažit potlačovat.” Porovnává - myšlenku, že obarvené mince mohou mít větší hodnotu než zaměnitelné - bitcoiny, s provozem bitcoinu a vyžadováním poplatků podle váhy - transakce oproti poplatkům podle přenášené hodnoty. V závěru - říká, že nevěří, že by toto muselo nutně vést ke špatným - incentivám. - - - *Více prostoru pro `OP_RETURN` v běžných transakcích:* - Christopher Allen [se tázal][allen op_return], zda-li je lepší - umístit libovolná data ve witnessu transakce nebo v `OP_RETURN` - výstupu. Po krátké diskuzi se několik účastníků ([1][todd or], - [2][o'connor or], [3][poelstra or]) vyjádřilo, že by souhlasili - s uvolněním výchozích pravidel pro přeposílání a těžbu, aby - umožnila více než 83 bytů v rámci `OP_RETURN` výstupů. Podle nich - by rozšíření `OP_RETURN` nepřineslo větší škody, neboť jsou - již používány i jiné metody ukládání dat. + - *Offchain obarvování mincí:* Anthony Towns [poslal][towns color] + souhrn protokolu používaného pro přiřazování zvláštního významu + některým výstupům. Těmto technikám se obecně říká *obarvování mincí*. + Též popsal související protokol používaný pro ukládání binárních + dat uvnitř bitcoinových transakcí a jejich asociaci s konkrétními + obarvenými mincemi. Po souhrnu současného stavu popsal metodu + pro ukládání dat pomocí zpráv na [Nostru][nostr] a jejich asociaci + s obarvenými mincemi, které by mohly být posílány v bitcoinových + transakcích. To by mělo několik výhod: + + - *Redukce nákladů:* žádné transakční poplatky za data přenášená + offchain. + + - *Soukromí:* dva lidé mohou vyměnit obarvené mince, aniž by + kdokoliv jiný věděl o datech, na která poukazují. + + - *Pro vytvoření není třeba transakce:* data mohou být asociována + s existujícími UTXO, není nutné vytvářet nová UTXO. + + - *Odolnost vůči cenzuře:* není-li asociace mezi daty a obarvenými + mincemi běžně známa, je posílání obarvených mincí natolik odolné + vůči cenzuře, jako je sám bitcoin. + + Ve spojení s odolností vůči cenzuře Towns říká, že „obarvené + bitcoiny jsou v podstatě nevyhnutelné a něco, s čím se musíme + potýkat, spíš než něco, co se snažit potlačovat.” Porovnává + myšlenku, že obarvené mince mohou mít větší hodnotu než zaměnitelné + bitcoiny, s provozem bitcoinu a vyžadováním poplatků podle váhy + transakce oproti poplatkům podle přenášené hodnoty. V závěru + říká, že nevěří, že by toto muselo nutně vést ke špatným + incentivám. + + - *Více prostoru pro `OP_RETURN` v běžných transakcích:* + Christopher Allen [se tázal][allen op_return], zda-li je lepší + umístit libovolná data ve witnessu transakce nebo v `OP_RETURN` + výstupu. Po krátké diskuzi se několik účastníků ([1][todd or], + [2][o'connor or], [3][poelstra or]) vyjádřilo, že by souhlasili + s uvolněním výchozích pravidel pro přeposílání a těžbu, aby + umožnila více než 83 bytů v rámci `OP_RETURN` výstupů. Podle nich + by rozšíření `OP_RETURN` nepřineslo větší škody, neboť jsou + již používány i jiné metody ukládání dat. - **Ředění poplatků v protokolech s více účastníky:** Yuval Kogman [zaslal][kogman dilution] do emailové skupiny Bitcoin-Dev popis @@ -76,21 +76,21 @@ na bitcoinovou technickou dokumentaci a diskuze. witness mnohem větší. To v důsledků sníží jednotkový poplatek za transakci. V emailové skupině bylo probráno několik důsledků: - - *Bob platí za Malloryho:* má-li Mallory vedlejší úmysly, například - chce-li poslat libovolná data, může na jejich poplatek použít - část Bobova poplatku. Příklad: Bob chce vytvořit transakci - o velikosti 1 000 vbytů s poplatkem 10 000 satoshi, tedy - 10 sat/vbyte, s cílem rychlého potvrzení transakce. Mallory přidá - do transakce 9 000 vbytů dat, která Bob neočekával, což sníží - jednotkový poplatek na 1 sat/vbyte. I když Bob platí v obou - případech stejnou absolutní částku, nedostane, co chtěl (rychlou - konfirmaci), a Mallory mohl přidat data v hodnotě 9 000 sat, aniž - by ho to stálo cokoliv navíc. - - - *Mallory zpomaluje konfirmaci:* transakce s nižším jednotkovým - poplatkem může být potvrzena pomaleji. V časově citlivých protokolech - to může pro Boba znamenat vážný problém. V jiných případech - by mohl Bob poplatek navýšit, což by ho stálo dodatečné prostředky. + - *Bob platí za Malloryho:* má-li Mallory vedlejší úmysly, například + chce-li poslat libovolná data, může na jejich poplatek použít + část Bobova poplatku. Příklad: Bob chce vytvořit transakci + o velikosti 1 000 vbytů s poplatkem 10 000 satoshi, tedy + 10 sat/vbyte, s cílem rychlého potvrzení transakce. Mallory přidá + do transakce 9 000 vbytů dat, která Bob neočekával, což sníží + jednotkový poplatek na 1 sat/vbyte. I když Bob platí v obou + případech stejnou absolutní částku, nedostane, co chtěl (rychlou + konfirmaci), a Mallory mohl přidat data v hodnotě 9 000 sat, aniž + by ho to stálo cokoliv navíc. + + - *Mallory zpomaluje konfirmaci:* transakce s nižším jednotkovým + poplatkem může být potvrzena pomaleji. V časově citlivých protokolech + to může pro Boba znamenat vážný problém. V jiných případech + by mohl Bob poplatek navýšit, což by ho stálo dodatečné prostředky. Kogman ve svém příspěvku popisuje několik opatření, avšak všechny vyžadují nějaký kompromis. Ve svém [druhém příspěvku][kogman dilution2] poznamenává, @@ -104,24 +104,24 @@ na bitcoinovou technickou dokumentaci a diskuze. alternativy by vyžadovalo přidání dodatečného 32bytového hashe do witnessu utrácející transakce. - ```text - * + ```text + * + / \ + A * / \ - A * - / \ - A B - ``` - - Znamená to, že i kdyby Mallory poskytl Bobovi platný witness pro svou - tapscriptovou transakci před tím, než by Bob poskytl svůj podpis, mohl by - Mallory stále odeslat alternativní verzi transakce s větším witnessem. - Bob by tomu mohl zabránit, kdyby od Malloryho obdržel kopii kompletního - stromu tapscriptů. - - V kontextu budoucích soft forků bitcoinu otevřel Anthony Towns [pull - request][bitcoin inquisition #19] v repozitáři Bitcoin Inquisition - používaném pro testování [SIGHASH_ANYPREVOUT][topic sighash_anyprevout] - (APO). APO by tak měl k zamezení tohoto problému používat dodatečná data. + A B + ``` + + Znamená to, že i kdyby Mallory poskytl Bobovi platný witness pro svou + tapscriptovou transakci před tím, než by Bob poskytl svůj podpis, mohl by + Mallory stále odeslat alternativní verzi transakce s větším witnessem. + Bob by tomu mohl zabránit, kdyby od Malloryho obdržel kopii kompletního + stromu tapscriptů. + + V kontextu budoucích soft forků bitcoinu otevřel Anthony Towns [pull + request][bitcoin inquisition #19] v repozitáři Bitcoin Inquisition + používaném pro testování [SIGHASH_ANYPREVOUT][topic sighash_anyprevout] + (APO). APO by tak měl k zamezení tohoto problému používat dodatečná data. ## Změny ve službách a klientech @@ -240,16 +240,16 @@ Proposals (BIPs)][bips repo] a [Lightning BOLTs][bolts repo].* [musig draft bip]: https://github.com/jonasnick/bips/blob/musig2/bip-musig2.mediawiki [paper analyzing payjoins]: https://eprint.iacr.org/2022/589.pdf [bitcoinsearch repos]: https://github.com/bitcoinsearch -[towns color]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021396.html +[towns color]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021396.html [nostr]: https://github.com/nostr-protocol/nostr -[allen op_return]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021387.html -[todd or]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021435.html -[o'connor or]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021439.html -[poelstra or]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021438.html -[kogman dilution]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021444.html +[allen op_return]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021387.html +[todd or]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021435.html +[o'connor or]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021439.html +[poelstra or]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021438.html +[kogman dilution]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021444.html [riard dilution]: https://gist.github.com/ariard/7e509bf2c81ea8049fd0c67978c521af#witness-malleability -[kogman dilution2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021459.html -[o'connor tsm]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021452.html +[kogman dilution2]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021459.html +[o'connor tsm]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021452.html [bitcoin inquisition #19]: https://github.com/bitcoin-inquisition/bitcoin/issues/19 [bitcoinsearch.xyz]: https://bitcoinsearch.xyz/ [core lightning 23.02rc2]: https://github.com/ElementsProject/lightning/releases/tag/v23.02rc2 diff --git a/_posts/cs/newsletters/2023-02-22-newsletter.md b/_posts/cs/newsletters/2023-02-22-newsletter.md index df4e87006d..cff5df22b6 100644 --- a/_posts/cs/newsletters/2023-02-22-newsletter.md +++ b/_posts/cs/newsletters/2023-02-22-newsletter.md @@ -86,7 +86,7 @@ páteřních bitcoinových projektů. bech32] adresy. Příklad jednoho takového dílu z návrhu BIP: ```text - ms12namea320zyxwvutsrqpnmlkjhgfedcaxrpp870hkkqrm + ms12namea320zyxwvutsrqpnmlkjhgfedcaxrpp870hkkqrm ``` Hlavní výhodou Codex32 oproti všem existujícím schématům je, že @@ -157,12 +157,12 @@ některé z otázek a odpovědí, které obdržely vysoký počet hlasů.* Vojtěch Strnad vysvětluje, že Ordinals Inscriptions nepoužívají `OP_RETURN`, ale vkládají data do nespuštěné větve skriptu pomocí `OP_PUSHDATAx` opkódů: - ``` - OP_0 - OP_IF - - OP_ENDIF - ``` + ``` + OP_0 + OP_IF + + OP_ENDIF + ``` - [Proč protokol neumožňuje expiraci nepotvrzených transakcí v dané výšce?]({{bse}}116926) Larry Ruane odkazuje na Satoshiho, proč by nebylo moudré, aby transakce @@ -250,23 +250,23 @@ Proposals (BIPs)][bips repo] a [Lightning BOLTs][bolts repo].* [codex32 website]: https://secretcodex32.com/ [codex32 video]: https://www.youtube.com/watch?v=kf48oPoiHX0 [news192 pp]: /en/newsletters/2022/03/23/#payment-delivery-algorithm-update -[obeirne op_vault]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021465.html +[obeirne op_vault]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021465.html [bip op_vault]: https://github.com/jamesob/bips/blob/jamesob-23-02-opvault/bip-vaults.mediawiki [news234 vault]: /cs/newsletters/2023/01/18/#navrh-na-nove-opkody-pro-uschovny -[jager qos]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-February/003842.html -[decker qos]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-February/003844.html -[riard boomerang]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-February/003852.html -[ckc-cs reputation]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-February/003857.html +[jager qos]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-February/003842.html +[decker qos]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-February/003844.html +[riard boomerang]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-February/003852.html +[ckc-cs reputation]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-February/003857.html [slip39]: https://github.com/satoshilabs/slips/blob/master/slip-0039.md [shamir's secret sharing scheme]: https://en.wikipedia.org/wiki/Shamir%27s_secret_sharing [prune mode]: https://bitcoin.org/en/full-node#reduce-storage [pr review 27050]: https://bitcoincore.reviews/27050 -[specialized compression for headers sync]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-March/015851.html -[general LZO-based compression]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011837.html +[specialized compression for headers sync]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-March/015851.html +[general LZO-based compression]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011837.html [news66 dns seed]: /en/newsletters/2019/10/02/#bitcoin-core-15558 [Chaincode Labs Research]: https://research.chaincode.com/research-intro/ [Bitcoin Problems]: https://bitcoinproblems.org/ [weight unit]: https://en.bitcoin.it/wiki/Weight_units -[op codex32]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021469.html +[op codex32]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021469.html [RUSTSEC-2022-0090]: https://rustsec.org/advisories/RUSTSEC-2022-0090 [bdk 0.27.1]: https://github.com/bitcoindevkit/bdk/releases/tag/v0.27.1 diff --git a/_posts/cs/newsletters/2023-03-01-newsletter.md b/_posts/cs/newsletters/2023-03-01-newsletter.md index 6a2af77acb..9049b02576 100644 --- a/_posts/cs/newsletters/2023-03-01-newsletter.md +++ b/_posts/cs/newsletters/2023-03-01-newsletter.md @@ -94,11 +94,11 @@ Proposals (BIPs)][bips repo] a [Lightning BOLTs][bolts repo].* pro zabránění útoků odmítnutí služby způsobeného vyčerpáním zdrojů. Nové limity jsou: - - Maximálně 250 spojení bez kanálu s prostředky. + - Maximálně 250 spojení bez kanálu s prostředky. - - Maximálně 50 spojení pokoušející se otevřít kanál. + - Maximálně 50 spojení pokoušející se otevřít kanál. - - Maximálně 4 kanály bez prostředků na spojení. + - Maximálně 4 kanály bez prostředků na spojení. - [LDK #1977][] zpřístupňuje struktury pro serializaci a parsování [nabídek][topic offers] podle definice v [návrhu BOLT12][bolts #798]. @@ -112,6 +112,6 @@ Proposals (BIPs)][bips repo] a [Lightning BOLTs][bolts repo].* [lnd v0.16.0-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.16.0-beta.rc1 [hwi 2.2.1]: https://github.com/bitcoin-core/HWI/releases/tag/2.2.1 [news239 codex32]: /cs/newsletters/2023/02/22/#navrh-bip-pro-kodovani-seedu-codex32 -[todd codex32]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021498.html -[o'connor codex32]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021504.html +[todd codex32]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021498.html +[o'connor codex32]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021504.html [news217 migratewallet]: /en/newsletters/2022/09/14/#bitcoin-core-19602 diff --git a/_posts/cs/newsletters/2023-03-08-newsletter.md b/_posts/cs/newsletters/2023-03-08-newsletter.md index 49eb3c952e..2fad2b93c4 100644 --- a/_posts/cs/newsletters/2023-03-08-newsletter.md +++ b/_posts/cs/newsletters/2023-03-08-newsletter.md @@ -20,52 +20,52 @@ páteřních bitcoinových projektů. funkce návrhu `OP_VAULT`/`OP_UNVAULT` (viz [zpravodaj č. 234][news234 vault]). Jeho verze by přidala tři opkódy namísto dvou, viz příklad: - - *Alice zašle prostředky do úschovny* zaplacením [P2TR výstupu][topic - taproot] se stromem skriptů, který obsahuje alespoň dva [koncové skripty][topic - tapscript] („leafscript”): jeden pro spuštění procesu otevření úschovny s časovým - zpožděním a druhý pro okamžité zmrazení prostředků, např. - `tr(klíč,{spusť,zmraz})`. - - - Skript *spusť* obsahuje její méně důvěryhodný způsob autorizace - (např. podpis z horké peněženky) a opkód `OP_TRIGGER_FORWARD`. - V době vytvoření tohoto skriptu poskytne opkódu parametr - *časového zpoždění*, např. relativní časový zámek 1 000 bloků - (zhruba jeden týden). - - - Skript *zmraz* obsahuje jakýkoliv Alicin způsob autorizace (nebo žádný) - a opkód `OP_FORWARD_DESTINATION`. V době vytvoření tohoto skriptu - si také zvolí důvěryhodnější způsob autorizace (např. vícenásobný - podpis z několika studených peněženek a podpisových zařízení). - Opkódu poskytne commitment tohoto způsobu v podobě hashe. - - - *Alice spustí otevírání úschovny* utracením výstupu výše uvedeného - skriptu (tj. jeho použitím jako vstupu) a zvolením spouštěcího - skriptu. Zároveň poskytne dva dodatečné parametry opkódu `OP_TRIGGER_FORWARD`: - index výstupu, který obdrží prostředky tohoto vstupu, a commitment - (ve formě hashe), který určí, jak bude později moci prostředky utratit. - Opkód ověří, že uvedený výstup této transakce platí P2TR výstup stromem - skriptů, který je podobný právě utrácenému s tím rozdílem, že spouštěcí - skript je nahrazen skriptem obsahujícím relativní zpoždění (`OP_CHECKSEQUENCEVERIFY`, - CSV) shodné se zpožděním uvedeným dříve (např. 1 000 bloků). Druhým rozdílem - je opkód `OP_FORWARD_OUTPUTS` obsahující hash Alicina commitmentu. - Tento způsob rekonstrukce stromu skriptů připomíná `OP_TAPLEAF_UPDATE_VERIFY`, - dřívější návrh [kovenantů][topic covenants] (viz [zpravodaj č. - 166][news166 tluv], *angl.*). - - - *Alice dokončí otevření úschovny* vyčkáním na uvolnění časového zámku - a následným utracením výstupu se zvoleným skriptem obsahujícím opkód - `OP_FORWARD_OUTPUTS`. Opkód ověří, že hash částky a skriptu výstupu - odpovídá commitmentu, který Alice učinila v předchozí transakci. - V tomto případě Alice úspěšně zaslala prostředky do úschovny, započala - otevření úschovny, musela počkat nejméně 1 000 bloků (aby měl její software - dostatek času na potvrzení záměru) a nakonec platbu dokončila. - - - V případě problémů *Alice prostředky zmrazí*. Může tak učinit kdykoliv - počínaje okamžikem vkladu prostředků do úschovny až do dokončení otevírání - úschovny. Aby mohla prostředky zmrazit, jednoduše zvolí zmrazovací - skript z výstupu transakce (buď vkladové nebo spouštěcí), neboť Alice - vložila zmrazovací skript do vkladové transakce a tento skript byl - automaticky přenesen dále. + - *Alice zašle prostředky do úschovny* zaplacením [P2TR výstupu][topic + taproot] se stromem skriptů, který obsahuje alespoň dva [koncové skripty][topic + tapscript] („leafscript”): jeden pro spuštění procesu otevření úschovny s časovým + zpožděním a druhý pro okamžité zmrazení prostředků, např. + `tr(klíč,{spusť,zmraz})`. + + - Skript *spusť* obsahuje její méně důvěryhodný způsob autorizace + (např. podpis z horké peněženky) a opkód `OP_TRIGGER_FORWARD`. + V době vytvoření tohoto skriptu poskytne opkódu parametr + *časového zpoždění*, např. relativní časový zámek 1 000 bloků + (zhruba jeden týden). + + - Skript *zmraz* obsahuje jakýkoliv Alicin způsob autorizace (nebo žádný) + a opkód `OP_FORWARD_DESTINATION`. V době vytvoření tohoto skriptu + si také zvolí důvěryhodnější způsob autorizace (např. vícenásobný + podpis z několika studených peněženek a podpisových zařízení). + Opkódu poskytne commitment tohoto způsobu v podobě hashe. + + - *Alice spustí otevírání úschovny* utracením výstupu výše uvedeného + skriptu (tj. jeho použitím jako vstupu) a zvolením spouštěcího + skriptu. Zároveň poskytne dva dodatečné parametry opkódu `OP_TRIGGER_FORWARD`: + index výstupu, který obdrží prostředky tohoto vstupu, a commitment + (ve formě hashe), který určí, jak bude později moci prostředky utratit. + Opkód ověří, že uvedený výstup této transakce platí P2TR výstup stromem + skriptů, který je podobný právě utrácenému s tím rozdílem, že spouštěcí + skript je nahrazen skriptem obsahujícím relativní zpoždění (`OP_CHECKSEQUENCEVERIFY`, + CSV) shodné se zpožděním uvedeným dříve (např. 1 000 bloků). Druhým rozdílem + je opkód `OP_FORWARD_OUTPUTS` obsahující hash Alicina commitmentu. + Tento způsob rekonstrukce stromu skriptů připomíná `OP_TAPLEAF_UPDATE_VERIFY`, + dřívější návrh [kovenantů][topic covenants] (viz [zpravodaj č. + 166][news166 tluv], *angl.*). + + - *Alice dokončí otevření úschovny* vyčkáním na uvolnění časového zámku + a následným utracením výstupu se zvoleným skriptem obsahujícím opkód + `OP_FORWARD_OUTPUTS`. Opkód ověří, že hash částky a skriptu výstupu + odpovídá commitmentu, který Alice učinila v předchozí transakci. + V tomto případě Alice úspěšně zaslala prostředky do úschovny, započala + otevření úschovny, musela počkat nejméně 1 000 bloků (aby měl její software + dostatek času na potvrzení záměru) a nakonec platbu dokončila. + + - V případě problémů *Alice prostředky zmrazí*. Může tak učinit kdykoliv + počínaje okamžikem vkladu prostředků do úschovny až do dokončení otevírání + úschovny. Aby mohla prostředky zmrazit, jednoduše zvolí zmrazovací + skript z výstupu transakce (buď vkladové nebo spouštěcí), neboť Alice + vložila zmrazovací skript do vkladové transakce a tento skript byl + automaticky přenesen dále. Jednou z výhod, které tento přístup poskytuje oproti původním designu `OP_VAULT`, je možnost stanovit v zmrazovacím skriptu jakékoliv podmínky @@ -185,7 +185,7 @@ Proposals (BIPs)][bips repo] a [Lightning BOLTs][bolts repo].* [LDK v0.0.114]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.0.114 [BTCPay 1.8.2]: https://github.com/btcpayserver/btcpayserver/releases/tag/v1.8.2 [podcast post]: /cs/podcast-announcement/ -[sanders vault]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-March/021510.html +[sanders vault]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-March/021510.html [news234 vault]: /cs/newsletters/2023/01/18/#navrh-na-nove-opkody-pro-uschovny [news166 tluv]: /en/newsletters/2021/09/15/#covenant-opcode-proposal [news238 peer storage]: /cs/newsletters/2023/02/15/#core-lightning-5361 diff --git a/_posts/cs/newsletters/2023-03-15-newsletter.md b/_posts/cs/newsletters/2023-03-15-newsletter.md index 6f2a9f4e56..39e5a3b5a4 100644 --- a/_posts/cs/newsletters/2023-03-15-newsletter.md +++ b/_posts/cs/newsletters/2023-03-15-newsletter.md @@ -65,5 +65,5 @@ Proposals (BIPs)][bips repo] a [Lightning BOLTs][bolts repo].* [lnd v0.16.0-beta.rc3]: https://github.com/lightningnetwork/lnd/releases/tag/v0.16.0-beta.rc3 [libsecp256k1 0.3.0]: https://github.com/bitcoin-core/secp256k1/releases/tag/v0.3.0 [core lightning v23.02.2]: https://github.com/ElementsProject/lightning/releases/tag/v23.02.2 -[kim utreexo]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-March/021515.html +[kim utreexo]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-March/021515.html [assumeutxo project]: https://github.com/bitcoin/bitcoin/projects/11 diff --git a/_posts/cs/newsletters/2023-03-29-newsletter.md b/_posts/cs/newsletters/2023-03-29-newsletter.md index 3a92dcd809..e129cf21f2 100644 --- a/_posts/cs/newsletters/2023-03-29-newsletter.md +++ b/_posts/cs/newsletters/2023-03-29-newsletter.md @@ -339,7 +339,7 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a [news206 msat]: /en/newsletters/2022/06/29/#core-lightning-5306 [rb sec]: https://github.com/rust-bitcoin/rust-bitcoin/blob/master/SECURITY.md [news239 codex32]: /cs/newsletters/2023/02/22/#navrh-bip-pro-kodovani-seedu-codex32 -[law stranded post]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-March/003886.html +[law stranded post]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-March/003886.html [law stranded paper]: https://github.com/JohnLaw2/ln-hierarchical-channels [obeirne selfish]: https://twitter.com/jamesob/status/1637198454899220485 [sanders requests]: https://twitter.com/theinstagibbs/status/1637235436849442817 diff --git a/_posts/cs/newsletters/2023-04-05-newsletter.md b/_posts/cs/newsletters/2023-04-05-newsletter.md index e588b43b0c..78b2d39177 100644 --- a/_posts/cs/newsletters/2023-04-05-newsletter.md +++ b/_posts/cs/newsletters/2023-04-05-newsletter.md @@ -29,14 +29,14 @@ popisem významných změn v populárních bitcoinových páteřních projektech by mohla Alice tato data a podpis zveřejnit. Avšak, jak Delgado poznamenává, má toto řešení svá úskalí: - - *Požadavky na úložiště*: tento mechanismus by po Alici vyžadoval - ukládání dodatečného podpisu za každý požadavek strážní věži, což - by u aktivních LN kanálů bylo celkem často. + - *Požadavky na úložiště*: tento mechanismus by po Alici vyžadoval + ukládání dodatečného podpisu za každý požadavek strážní věži, což + by u aktivních LN kanálů bylo celkem často. - - *Nemožnost mazání*: tento způsob by zřejmě vyžadoval, aby strážní - věže nikdy nemazaly podklady pro detekci narušení. Avšak to může - být v rozporu s jejich potřebami, např. pokud jsou jejich služby - účtovány za určité období. + - *Nemožnost mazání*: tento způsob by zřejmě vyžadoval, aby strážní + věže nikdy nemazaly podklady pro detekci narušení. Avšak to může + být v rozporu s jejich potřebami, např. pokud jsou jejich služby + účtovány za určité období. Delgado navrhuje použití kryptografických akumulátorů, které by poskytly praktické řešení obou problémů. Akumulátory umožňují v kompaktní formě @@ -126,7 +126,7 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a {% include linkers/issues.md v=2 issues="5967,2566,2062,1031,1032,1040,2125,4826,4782,4799,765" %} [lnd v0.16.0-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.16.0-beta [bdk 1.0.0-alpha.0]: https://github.com/bitcoindevkit/bdk/releases/tag/v1.0.0-alpha.0 -[segura watchtowers post]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-March/003892.html +[segura watchtowers post]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-March/003892.html [segura watchtowers gist]: https://gist.github.com/sr-gi/f91f007fc8d871ea96ead9b27feec3d5 [news85 blinding]: /en/newsletters/2020/02/19/#decoy-nodes-and-lightweight-rendez-vous-routing [news226 bolts1031]: /en/newsletters/2022/11/16/#bolts-1031 diff --git a/_posts/cs/newsletters/2023-04-12-newsletter.md b/_posts/cs/newsletters/2023-04-12-newsletter.md index a39fa01ebe..6a1ff9ccda 100644 --- a/_posts/cs/newsletters/2023-04-12-newsletter.md +++ b/_posts/cs/newsletters/2023-04-12-newsletter.md @@ -191,9 +191,9 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a {% include linkers/issues.md v=2 issues="6012,6124,2607,7437,7069,1372,863" %} [bdk 1.0.0-alpha.0]: https://github.com/bitcoindevkit/bdk/releases/tag/v1.0.0-alpha.0 [news243 bdk]: /cs/newsletters/2023/03/22/#bdk-793 -[neigut splice]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-March/003894.html -[teinturier splice]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-March/003895.html -[erhardt terms]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021550.html +[neigut splice]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-March/003894.html +[teinturier splice]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-March/003895.html +[erhardt terms]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021550.html [terms bip]: https://github.com/Xekyo/bips/pull/1 [news26 pyln-client]: /en/newsletters/2018/12/18/#c-lightning-2161 [news17 splice]: /en/newsletters/2018/10/16/#proposal-for-lightning-network-payment-channel-splicing diff --git a/_posts/cs/newsletters/2023-04-19-newsletter.md b/_posts/cs/newsletters/2023-04-19-newsletter.md index 862b684660..a613c2f797 100644 --- a/_posts/cs/newsletters/2023-04-19-newsletter.md +++ b/_posts/cs/newsletters/2023-04-19-newsletter.md @@ -177,8 +177,8 @@ Proposals (BIPs)][bips repo] a [Lightning BOLTs][bolts repo].* {% include references.md %} {% include linkers/issues.md v=2 issues="27358,6120,2584,863" %} [bdk 1.0.0-alpha.0]: https://github.com/bitcoindevkit/bdk/releases/tag/v1.0.0-alpha.0 -[orlovsky rgb]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021554.html -[tenga rgb]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021558.html +[orlovsky rgb]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021554.html +[tenga rgb]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021558.html [rgb-lightning-sample]: https://github.com/RGB-Tools/rgb-lightning-sample [ldk-sample]: https://github.com/lightningdevkit/ldk-sample [rgb.tech]: https://rgb.tech/ diff --git a/_posts/cs/newsletters/2023-04-26-newsletter.md b/_posts/cs/newsletters/2023-04-26-newsletter.md index baf43aa5ad..9cfe4915fc 100644 --- a/_posts/cs/newsletters/2023-04-26-newsletter.md +++ b/_posts/cs/newsletters/2023-04-26-newsletter.md @@ -134,8 +134,8 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a [Core Lightning 23.05rc1]: https://github.com/ElementsProject/lightning/releases/tag/v23.05rc1 [news56 bloom]: /en/newsletters/2019/07/24/#bitcoin-core-16152 [news60 bloom]: /en/newsletters/2019/08/21/#bitcoin-core-16248 -[clark mempool]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021562.html -[harding mempool]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021563.html +[clark mempool]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021562.html +[harding mempool]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021563.html [unix epoch time]: https://en.wikipedia.org/wiki/Unix_time [ldk 0.0.115]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.0.115 [lnd v0.16.1-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.16.1-beta diff --git a/_posts/cs/newsletters/2023-05-03-newsletter.md b/_posts/cs/newsletters/2023-05-03-newsletter.md index e3e34e821b..1f65d10f17 100644 --- a/_posts/cs/newsletters/2023-05-03-newsletter.md +++ b/_posts/cs/newsletters/2023-05-03-newsletter.md @@ -167,11 +167,11 @@ Proposals (BIPs)][bips repo] a [Lightning BOLTs][bolts repo].* [news129 adaptors]: /en/newsletters/2020/12/23/#ptlcs [news243 rebroadcast]: /cs/newsletters/2023/03/22/#lnd-7448 [news247 rebroadcast]: /cs/newsletters/2023/04/19/#core-lightning-6120 -[ingala vaults]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021588.html +[ingala vaults]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021588.html [news226 matt]: /en/newsletters/2022/11/16/#general-smart-contracts-in-bitcoin-via-covenants [news234 op_vault]: /cs/newsletters/2023/01/18/#navrh-na-nove-opkody-pro-uschovny -[halseth matt]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021593.html -[gibson adaptors]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021594.html -[lee hiring]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021589.html +[halseth matt]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021593.html +[gibson adaptors]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021594.html +[lee hiring]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021589.html [news34 psbt]: /en/newsletters/2019/02/19/#bitcoin-core-13932 [abandontransaction rpc]: https://developer.bitcoin.org/reference/rpc/abandontransaction.html diff --git a/_posts/cs/newsletters/2023-05-10-newsletter.md b/_posts/cs/newsletters/2023-05-10-newsletter.md index 564de264b0..204b9641a7 100644 --- a/_posts/cs/newsletters/2023-05-10-newsletter.md +++ b/_posts/cs/newsletters/2023-05-10-newsletter.md @@ -230,8 +230,7 @@ tuto jednoduchou misi rozšiřovat a proto také poskytujeme průvodce mezi kterými nechyběli mnozí z těch, o kterých máme tu čest psát. Nic z toho by nebylo možné bez našich přispěvatelů, mezi kterými byli -za poslední rok: - +za poslední rok: Adam Jonas, Copinmalin, David A. Harding, @@ -264,11 +263,11 @@ zpravodajů pokračovat. [eclair bitcoin.conf]: https://github.com/ACINQ/eclair/pull/1783/files#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5 [carman hints]: https://github.com/lightningdevkit/rust-lightning/pull/2044#issuecomment-1448840896 [corallo hints]: https://github.com/lightningdevkit/rust-lightning/pull/2044#issuecomment-1461049958 -[hartman powswap]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021605.html +[hartman powswap]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021605.html [hnr powswap]: https://raw.githubusercontent.com/blockrate-binaries/paper/master/blockrate-binaries-paper.pdf [powswap]: https://powswap.com/ [news188 phantom]: /en/newsletters/2022/02/23/#ldk-1199 -[founding sponsors]: /about/#founding-sponsors +[founding sponsors]: /en/about/#founding-sponsors [financial supporters]: /#members [review club 27501]: https://bitcoincore.reviews/27501 [prioritisetransaction rpc]: https://developer.bitcoin.org/reference/rpc/prioritisetransaction.html diff --git a/_posts/cs/newsletters/2023-05-17-newsletter.md b/_posts/cs/newsletters/2023-05-17-newsletter.md index 5ba224bc39..65f9f99339 100644 --- a/_posts/cs/newsletters/2023-05-17-newsletter.md +++ b/_posts/cs/newsletters/2023-05-17-newsletter.md @@ -87,26 +87,26 @@ změn v populárních bitcoinových páteřních projektech. („transaction cut-through”), staré myšlenky na zvýšení soukromí a škálovatelnosti a snížení nákladů: - - *Přeposílání plateb:* namísto platby přímo Bobovi může Alice - zaplatit Bobovýmu prodejci (Carol) a tím snížit dluh, který - Bob u ní má, nebo si předplatit budoucí útratu. - - - *Dávkové přeposílání plateb:* namísto platby přímo Bobovi může - Alice zaplatit několika lidem, kterým Bob dluží peníze (nebo si - u nich chce založit úvěr). Gouldův příklad uvažuje o směnárnách, - které mají stálý tok vkladů a výběrů; payjoin umožňuje, aby - výběry byly placeny novými vklady. - - Obě tyto techniky umožňují snížit počet transakcí z minimálně dvou - na jednu jedinou, což ušetří významné množství prostoru. S použitím - [dávkování][topic payment batching] může být ušetřeného prostoru - ještě více. Z pohledu původního příjemce (např. Bob) je navíc výhodné, - že původní odesílatel (např. Alice) může platit všechny nebo část - poplatků. Odstraňování transakcí z blockchainu a kombinování - operací jako příjímání a utrácení též výrazně ztěžuje špehování - finančních toků. - - V době psaní neobdržel příspěvek v emailové skupině žádné reakce. + - *Přeposílání plateb:* namísto platby přímo Bobovi může Alice + zaplatit Bobovýmu prodejci (Carol) a tím snížit dluh, který + Bob u ní má, nebo si předplatit budoucí útratu. + + - *Dávkové přeposílání plateb:* namísto platby přímo Bobovi může + Alice zaplatit několika lidem, kterým Bob dluží peníze (nebo si + u nich chce založit úvěr). Gouldův příklad uvažuje o směnárnách, + které mají stálý tok vkladů a výběrů; payjoin umožňuje, aby + výběry byly placeny novými vklady. + + Obě tyto techniky umožňují snížit počet transakcí z minimálně dvou + na jednu jedinou, což ušetří významné množství prostoru. S použitím + [dávkování][topic payment batching] může být ušetřeného prostoru + ještě více. Z pohledu původního příjemce (např. Bob) je navíc výhodné, + že původní odesílatel (např. Alice) může platit všechny nebo část + poplatků. Odstraňování transakcí z blockchainu a kombinování + operací jako příjímání a utrácení též výrazně ztěžuje špehování + finančních toků. + + V době psaní neobdržel příspěvek v emailové skupině žádné reakce. - **Souhrn osobních setkání vývojářů Bitcoin Core:** někteří vývojáři pracující na Bitcoin Core se nedávno sešli, aby prodiskutovali @@ -118,18 +118,18 @@ změn v populárních bitcoinových páteřních projektech. Dále byla diskutována dvě další témata, které si podle nás zaslouží zvláštní pozornost: - - [Mempool clustering][] shrnuje návrh na významný redesign ukládání - transakcí a jejich metadat v mempoolu Bitcoin Core. Poznámky - popisují množství problémů se současným designem, poskytují přehled - nového designu a ukazují na některé potíže a kompromisy. Později - byl uveřejněn [popis][bitcoin core #27677] designu a kopie - [slajdů][mempool slides] prezentace. + - [Mempool clustering][] shrnuje návrh na významný redesign ukládání + transakcí a jejich metadat v mempoolu Bitcoin Core. Poznámky + popisují množství problémů se současným designem, poskytují přehled + nového designu a ukazují na některé potíže a kompromisy. Později + byl uveřejněn [popis][bitcoin core #27677] designu a kopie + [slajdů][mempool slides] prezentace. - - [Meta-diskuze o projektu][Project meta discussion] shrnuje pestrou - diskuzi o cílech projektu a jak jich docílit navzdory mnoha překážkám - vnitřním i vnějším. Některé z debat vedly již k pokusným změnám - ve správě projektu, jako je více projektově orientovaný přístup - pro budoucí vydání následující verzi 25. + - [Meta-diskuze o projektu][Project meta discussion] shrnuje pestrou + diskuzi o cílech projektu a jak jich docílit navzdory mnoha překážkám + vnitřním i vnějším. Některé z debat vedly již k pokusným změnám + ve správě projektu, jako je více projektově orientovaný přístup + pro budoucí vydání následující verzi 25. ## Čekání na potvrzení 1: k čemu je mempool? @@ -223,15 +223,15 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a [package relay]: https://btctranscripts.com/bitcoin-core-dev-tech/2023-04-25-package-relay-primer/ [mempool clustering]: https://btctranscripts.com/bitcoin-core-dev-tech/2023-04-25-mempool-clustering/ [project meta discussion]: https://btctranscripts.com/bitcoin-core-dev-tech/2023-04-26-meta-discussion/ -[kcs endorsement]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-April/003918.html -[decker endorsement]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-May/003944.html -[buhler lsp]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-May/003926.html -[zmnscpxj lsp]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-May/003930.html -[teinturier 0conf]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-May/003920.html -[gould payjoin]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021653.html +[kcs endorsement]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-April/003918.html +[decker endorsement]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-May/003944.html +[buhler lsp]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-May/003926.html +[zmnscpxj lsp]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-May/003930.html +[teinturier 0conf]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-May/003920.html +[gould payjoin]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021653.html [transaction cut-through]: https://bitcointalk.org/index.php?topic=281848.0 [news46 qr]: /en/newsletters/2019/05/14/#bech32-sending-support [mempool slides]: https://github.com/bitcoin/bitcoin/files/11490409/Reinventing.the.Mempool.pdf -[secp ml]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021683.html +[secp ml]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021683.html [libsecp256k1 0.3.2]: https://github.com/bitcoin-core/secp256k1/releases/tag/v0.3.2 [ecdh]: https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman diff --git a/_posts/cs/newsletters/2023-05-24-newsletter.md b/_posts/cs/newsletters/2023-05-24-newsletter.md index f408fddd97..13bb4083bc 100644 --- a/_posts/cs/newsletters/2023-05-24-newsletter.md +++ b/_posts/cs/newsletters/2023-05-24-newsletter.md @@ -204,7 +204,7 @@ Proposals (BIPs)][bips repo] a [Lightning BOLTs][bolts repo].* [bitcoin core 23.2]: https://bitcoincore.org/bin/bitcoin-core-23.2/ [bitcoin core 24.1]: https://bitcoincore.org/bin/bitcoin-core-24.1/ [bitcoin core 25.0rc2]: https://bitcoincore.org/bin/bitcoin-core-25.0/ -[linus post]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021679.html +[linus post]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021679.html [lg paper]: https://zerosync.org/zerosync.pdf [news128 bolts803]: /en/newsletters/2020/12/16/#bolts-803 [news247 rgb]: /cs/newsletters/2023/04/19/#aktualizace-rgb diff --git a/_posts/cs/newsletters/2023-05-31-newsletter.md b/_posts/cs/newsletters/2023-05-31-newsletter.md index bd67284ce2..6e1ce6dfad 100644 --- a/_posts/cs/newsletters/2023-05-31-newsletter.md +++ b/_posts/cs/newsletters/2023-05-31-newsletter.md @@ -38,38 +38,38 @@ projektech. v jednom směru, s jedním skokem a bez požadavku na důvěru. Keceli popisuje tři možnosti použití tohoto protokolu pro atomický transfer: - - *Míchání mincí:* několik uživatelů v rámci joinpoolu může - spolu vytvořit atomické výměny svých offchain prostředků za - novou offchain hodnotu o stejné výši. Jelikož jakákoliv chyba - v onchain komponentě jednoduše celou výměnu revokuje a všechny - prostředky vrátí, je tato operace rychlá. Zaslepovací protokol - podobný protokolu v některých existujících implementacích - [coinjoinu][topic coinjoin] může zamezit, aby mohl kdokoliv - spočítat uživateli držené bitcoiny. - - - *Vnitřní transfery:* uživatel může poslat své offchain prostředky - jinému uživateli v rámci stejné protistrany. Atomicita zajišťuje, - že buď příjemce dostane své peníze nebo se vrátí odesílateli. - Příjemci, kteří nedůvěřují ani odesílateli, ani protistraně, budou - muset čekat na stejné množství konfirmací jako v případě běžné - onchain transakce. - - Keceli a jeden z diskutujících [odkázali][keceli reply0] na - [předchozí][harding reply0] výzkum popisující, jak neekonomické - může být dvojí utrácení zero-conf plateb, pokud jsou spojeny - s finančním závazkem, který si těžař může v případě dvojího - utrácení přisvojit. Díky tomu by mohli příjemci akceptovat - platbu za méně než sekundu i v případě nulové důvěry. - - - *Platba LN faktur:* uživatel se může rychle zavázat k platbě - offchainových prostředků protistraně, pokud protistrana zná - tajný kód, což umožní uživateli pomocí protistrany platit - [HTLC][topic HTLC] faktury podobné LN. - - Ani zde, podobně jako v případě vnitřních transferů, nemůže uživatel - obdržet prostředky bez požadavku na důvěru, takže by neměl odhalit - tajný kód, dokud platba neobdrží dostatečné množství potvrzení - nebo není zabezpečena dostatečným finančním závazkem. + - *Míchání mincí:* několik uživatelů v rámci joinpoolu může + spolu vytvořit atomické výměny svých offchain prostředků za + novou offchain hodnotu o stejné výši. Jelikož jakákoliv chyba + v onchain komponentě jednoduše celou výměnu revokuje a všechny + prostředky vrátí, je tato operace rychlá. Zaslepovací protokol + podobný protokolu v některých existujících implementacích + [coinjoinu][topic coinjoin] může zamezit, aby mohl kdokoliv + spočítat uživateli držené bitcoiny. + + - *Vnitřní transfery:* uživatel může poslat své offchain prostředky + jinému uživateli v rámci stejné protistrany. Atomicita zajišťuje, + že buď příjemce dostane své peníze nebo se vrátí odesílateli. + Příjemci, kteří nedůvěřují ani odesílateli, ani protistraně, budou + muset čekat na stejné množství konfirmací jako v případě běžné + onchain transakce. + + Keceli a jeden z diskutujících [odkázali][keceli reply0] na + [předchozí][harding reply0] výzkum popisující, jak neekonomické + může být dvojí utrácení zero-conf plateb, pokud jsou spojeny + s finančním závazkem, který si těžař může v případě dvojího + utrácení přisvojit. Díky tomu by mohli příjemci akceptovat + platbu za méně než sekundu i v případě nulové důvěry. + + - *Platba LN faktur:* uživatel se může rychle zavázat k platbě + offchainových prostředků protistraně, pokud protistrana zná + tajný kód, což umožní uživateli pomocí protistrany platit + [HTLC][topic HTLC] faktury podobné LN. + + Ani zde, podobně jako v případě vnitřních transferů, nemůže uživatel + obdržet prostředky bez požadavku na důvěru, takže by neměl odhalit + tajný kód, dokud platba neobdrží dostatečné množství potvrzení + nebo není zabezpečena dostatečným finančním závazkem. Keceli tvrdí, že základní protokol může být nad bitcoinem implementován již dnes s využitím časté interakce mezi členy joinpoolu. Pokud by byl @@ -93,42 +93,42 @@ projektech. Některé z komentářů zaslaných do emailové skupiny: - - *Požadavek na dokumentaci:* [přinejmenším][stone reply] dva - [diskutující][dryja reply] si vyžádali dodatečnou dokumentaci - o fungování systému. Kvůli úrovni popisu v emailové skupině jej - nedokázali dostatečně analyzovat. Keceli mezitím začal publikovat - [návrhy specifikací][arc specs]. - - - *Obavy o pomalost v porovnání s LN:* [několik][dryja - reply] lidí [poznamenalo][harding reply1], že není v prvotním - designu možné přijímat platbu z joinpoolu bez požadavku na - důvěru (offchain ani onchain) bez čekání na dostatečné množství - konfirmací. To může trvat hodiny, kdežto mnoho LN plateb - je uzavřeno za méně než sekundu. I s finanční pojistkou by byla - LN obecně rychlejší. - - - *Obavy o dopad na blockchain:* jeden [komentující][jk_14] - poznamenal, že v případě jedné transakce každý pět sekund by zhruba - 200 protistran zabralo celý prostor v každém bloku. Jiná - [odpověď][harding reply0] předpokládala, že každá z onchain - transakcí protistran by byla podobně veliká jako otevírací - či uzavírací transakce LN. Protistrana s miliónem uživatelů, - která by vytvářela 6,3 miliónů onchain transakcí za rok, by zabrala - stejné množství prostoru jako otevírací a zavírací transakce - 6,3 kanálů každého z těchto uživatelů za rok. Onchain náklady - na LN by tedy byly nižší, avšak pouze do určitého bodu. - - - *Obavy o velikost horké peněženky a kapitálu:* jedna [reakce][harding - reply0] se zamýšlela nad nutností protistrany držet k dispozici, - zřejmě v horké peněžence, množství bitcoinů rovné částce, kterou - mohou uživatelé utratit v dohledné budoucnosti. Dle současného designu - by po utracení protistrana těmito bitcoiny nemusela disponovat - až po dobu 28 dní. Pokud by protistrana účtovala nízkou úrokovou - sazbu 1,5 % za rok, rovnalo by se to 0,125% poplatku z každé transakce - zprostředkované protistranou (včetně coinjoinů, interních transferů - a LN plateb). Pro porovnání, [veřejné statistky][1ml stats] dostupné - v době psaní (poskytnuté 1ML) ukazují, že medián jednotkového - poplatku za jeden skok LN transferů je 0,0026 %, téměř 50krát nižší. + - *Požadavek na dokumentaci:* [přinejmenším][stone reply] dva + [diskutující][dryja reply] si vyžádali dodatečnou dokumentaci + o fungování systému. Kvůli úrovni popisu v emailové skupině jej + nedokázali dostatečně analyzovat. Keceli mezitím začal publikovat + [návrhy specifikací][arc specs]. + + - *Obavy o pomalost v porovnání s LN:* [několik][dryja + reply] lidí [poznamenalo][harding reply1], že není v prvotním + designu možné přijímat platbu z joinpoolu bez požadavku na + důvěru (offchain ani onchain) bez čekání na dostatečné množství + konfirmací. To může trvat hodiny, kdežto mnoho LN plateb + je uzavřeno za méně než sekundu. I s finanční pojistkou by byla + LN obecně rychlejší. + + - *Obavy o dopad na blockchain:* jeden [komentující][jk_14] + poznamenal, že v případě jedné transakce každý pět sekund by zhruba + 200 protistran zabralo celý prostor v každém bloku. Jiná + [odpověď][harding reply0] předpokládala, že každá z onchain + transakcí protistran by byla podobně veliká jako otevírací + či uzavírací transakce LN. Protistrana s miliónem uživatelů, + která by vytvářela 6,3 miliónů onchain transakcí za rok, by zabrala + stejné množství prostoru jako otevírací a zavírací transakce + 6,3 kanálů každého z těchto uživatelů za rok. Onchain náklady + na LN by tedy byly nižší, avšak pouze do určitého bodu. + + - *Obavy o velikost horké peněženky a kapitálu:* jedna [reakce][harding + reply0] se zamýšlela nad nutností protistrany držet k dispozici, + zřejmě v horké peněžence, množství bitcoinů rovné částce, kterou + mohou uživatelé utratit v dohledné budoucnosti. Dle současného designu + by po utracení protistrana těmito bitcoiny nemusela disponovat + až po dobu 28 dní. Pokud by protistrana účtovala nízkou úrokovou + sazbu 1,5 % za rok, rovnalo by se to 0,125% poplatku z každé transakce + zprostředkované protistranou (včetně coinjoinů, interních transferů + a LN plateb). Pro porovnání, [veřejné statistky][1ml stats] dostupné + v době psaní (poskytnuté 1ML) ukazují, že medián jednotkového + poplatku za jeden skok LN transferů je 0,0026 %, téměř 50krát nižší. Několik komentářů projevilo nad návrhem nadšení a těšilo se na budoucí průzkum. @@ -289,18 +289,18 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a [bitcoin core 25.0]: https://bitcoincore.org/bin/bitcoin-core-25.0/ [1ml stats]: https://1ml.com/statistics [arc specs]: https://github.com/ark-network/specs -[keceli ark]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021694.html -[keceli reply0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021720.html -[harding reply0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021721.html -[harding reply1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021714.html -[stone reply]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021708.html -[dryja reply]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021713.html -[jk_14]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021717.html -[jager nostr]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021700.html +[keceli ark]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021694.html +[keceli reply0]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021720.html +[harding reply0]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021721.html +[harding reply1]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021714.html +[stone reply]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021708.html +[dryja reply]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021713.html +[jk_14]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021717.html +[jager nostr]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021700.html [jager video]: https://twitter.com/joostjgr/status/1658487013237211155 [news85 stuck funds]: /en/newsletters/2020/02/19/#c-lightning-3500 [btcpay server 97e7e]: https://github.com/btcpayserver/btcpayserver/commit/97e7e60ceae2b73d63054ee38ea54ed265cc5b8e [news157 libsecp]: /en/newsletters/2021/07/14/#libsecp256k1-844 [bcc rn]: https://bitcoincore.org/en/releases/25.0/ [news252 incentives]: /cs/newsletters/2023/05/24/#čekání-na-potvrzení-2-incentivy -[morcos limits]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011401.html +[morcos limits]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011401.html diff --git a/_posts/cs/newsletters/2023-06-07-newsletter.md b/_posts/cs/newsletters/2023-06-07-newsletter.md index cd11e21583..6a3bdda5b1 100644 --- a/_posts/cs/newsletters/2023-06-07-newsletter.md +++ b/_posts/cs/newsletters/2023-06-07-newsletter.md @@ -105,11 +105,11 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a [news249 matt]: /cs/newsletters/2023/05/03/#uschovny-zalozene-na-matt [news253 sweep]: /cs/newsletters/2023/05/31/#eclair-2668 [news245 listclosedchannels]: /cs/newsletters/2023/04/05/#core-lightning-5967 -[halseth matt-ctv]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021730.html +[halseth matt-ctv]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021730.html [halseth demo]: https://github.com/halseth/tapsim/blob/b07f29804cf32dce0168ab5bb40558cbb18f2e76/examples/matt/ctv2/README.md [tapsim]: https://github.com/halseth/tapsim -[halseth matt-joinpool]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021719.html +[halseth matt-joinpool]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021719.html [demo joinpool]: https://github.com/halseth/tapsim/tree/matt-demo/examples/matt/coinpool -[ingala matt]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021724.html +[ingala matt]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021724.html [news248 lnd mempool]: /cs/newsletters/2023/04/26/#lnd-7564 [lnd 0.16.3-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.16.3-beta diff --git a/_posts/cs/newsletters/2023-06-14-newsletter.md b/_posts/cs/newsletters/2023-06-14-newsletter.md index dcfbbf7161..d13fd90c5b 100644 --- a/_posts/cs/newsletters/2023-06-14-newsletter.md +++ b/_posts/cs/newsletters/2023-06-14-newsletter.md @@ -169,15 +169,15 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a {% include references.md %} {% include linkers/issues.md v=2 issues="27501,6243,2677,1890,1458,24007" %} [policy series]: /cs/blog/waiting-for-confirmation/ -[jager annex]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021731.html -[riard annex]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/020991.html -[jager annex2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021756.html -[sanders annex]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021736.html +[jager annex]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021731.html +[riard annex]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/020991.html +[jager annex2]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021756.html +[sanders annex]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021736.html [news244 annex]: /cs/newsletters/2023/03/29/#bitcoin-inquisition-22 -[jager annex3]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021743.html -[bs sp]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021750.html +[jager annex3]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021743.html +[bs sp]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021750.html [review club 27600]: https://bitcoincore.reviews/27600 -[jager annex4]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021737.html +[jager annex4]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021737.html [lnd max_cltv]: /en/newsletters/2019/10/23/#lnd-3595 [news250 getprioritisedtransactions]: /cs/newsletters/2023/05/10/#bitcoin-core-pr-review-club [Core Lightning 23.05.1]: https://github.com/ElementsProject/lightning/releases/tag/v23.05.1 diff --git a/_posts/cs/newsletters/2023-06-21-newsletter.md b/_posts/cs/newsletters/2023-06-21-newsletter.md index 263279b15f..8576dcd437 100644 --- a/_posts/cs/newsletters/2023-06-21-newsletter.md +++ b/_posts/cs/newsletters/2023-06-21-newsletter.md @@ -22,42 +22,42 @@ bitcoinových páteřních projektech. tajným kódem a částkou. Voegtlin vysvětluje užitečnost návrhu pro [submarine swaps][topic submarine swaps] a [JIT kanály][topic jit channels]: - - *Submarine swaps* v případě, kdy platba offchain LN faktury vyústí - v přijetí onchain prostředků (opačný směr zde neuvažujeme). - Onchain příjemce zvolí tajný kód a offchain plátce zaplatí [HTLC][topic - htlc] s hashem tohoto kódu, které je směrováno po LN k poskytovateli - submarine swap. Tento poskytovatel obdrží offchain HTLC a vytvoří - onchain transakci platící za toto HTLC. Až bude uživatel považovat - onchain transakci za zabezpečenou, odhalí tajný kód k vyrovnání - onchain HTLC, což umožní poskytovateli vyrovnat offchain HTLC - (a kteroukoliv další platbu v LN závislou na stejném tajném kódu). - - Pokud však příjemce tajný kód neodhalí, neobdrží poskytovatel žádnou - kompenzaci a bude muset utratit právě vytvořený onchain výstup, což - mu přinese nadbytečné náklady. Aby předešly tomuto zneužití, požadují - existující poskytovatelé po plátci LN poplatek (zaslaný před vytvořením - onchain transakce), který může být zcela či zčásti vrácen po vyrovnání - onchain HTLC. Tento poplatek a submarine swap obsahují odlišné částky a - musí být vyrovnány v odlišných časech, musí tedy použít i odlišný tajný - kód. Současná BOLT11 faktura může obsahovat pouze jeden commitment k - tajnému kódu a jednu částku. Každá peněženka poskytující submarine - swaps tedy musí buď interakci se serverem obstarat sama nebo nechat - dokončení tohoto postupu na plátci a příjemci. - - - *Just-in-Time (JIT) kanály*, kde uživatel bez kanálů (nebo bez likvidity) - vytvoří s poskytovatelem služeb virtuální kanál. V okamžiku přijetí - první platby do tohoto virtuálního kanálu vytvoří poskytovatel onchain - transakci, která kanál otevře a zároveň provede tuto platbu. Tato offchain - platba je jako kterékoliv jiné HTLC učiněna oproti tajnému kódu, který - zná jen příjemce (uživatel). Je-li uživatel ujištěn, že otevření JIT - kanálu je zajištěno, odhalí tajný kód a platbu nárokuje. - - Pokud však opět uživatel tajný kód neodhalí, neobdrží poskytovatel - kompenzaci a vyvstanou mu dodatečné onchain náklady. Voegtlin věří, - že existující poskytovatelé JIT kanálů se tomuto problému vyhýbají - tím, že vyžadují odhalení tajného kódu před tím, než je otevírací - transakce zajištěna, což podle něj může vytvářet problémy se zákonem - a zabraňuje nekustodiálním peněženkám podobnou službu nabízet. + - *Submarine swaps* v případě, kdy platba offchain LN faktury vyústí + v přijetí onchain prostředků (opačný směr zde neuvažujeme). + Onchain příjemce zvolí tajný kód a offchain plátce zaplatí [HTLC][topic + htlc] s hashem tohoto kódu, které je směrováno po LN k poskytovateli + submarine swap. Tento poskytovatel obdrží offchain HTLC a vytvoří + onchain transakci platící za toto HTLC. Až bude uživatel považovat + onchain transakci za zabezpečenou, odhalí tajný kód k vyrovnání + onchain HTLC, což umožní poskytovateli vyrovnat offchain HTLC + (a kteroukoliv další platbu v LN závislou na stejném tajném kódu). + + Pokud však příjemce tajný kód neodhalí, neobdrží poskytovatel žádnou + kompenzaci a bude muset utratit právě vytvořený onchain výstup, což + mu přinese nadbytečné náklady. Aby předešly tomuto zneužití, požadují + existující poskytovatelé po plátci LN poplatek (zaslaný před vytvořením + onchain transakce), který může být zcela či zčásti vrácen po vyrovnání + onchain HTLC. Tento poplatek a submarine swap obsahují odlišné částky a + musí být vyrovnány v odlišných časech, musí tedy použít i odlišný tajný + kód. Současná BOLT11 faktura může obsahovat pouze jeden commitment k + tajnému kódu a jednu částku. Každá peněženka poskytující submarine + swaps tedy musí buď interakci se serverem obstarat sama nebo nechat + dokončení tohoto postupu na plátci a příjemci. + + - *Just-in-Time (JIT) kanály*, kde uživatel bez kanálů (nebo bez likvidity) + vytvoří s poskytovatelem služeb virtuální kanál. V okamžiku přijetí + první platby do tohoto virtuálního kanálu vytvoří poskytovatel onchain + transakci, která kanál otevře a zároveň provede tuto platbu. Tato offchain + platba je jako kterékoliv jiné HTLC učiněna oproti tajnému kódu, který + zná jen příjemce (uživatel). Je-li uživatel ujištěn, že otevření JIT + kanálu je zajištěno, odhalí tajný kód a platbu nárokuje. + + Pokud však opět uživatel tajný kód neodhalí, neobdrží poskytovatel + kompenzaci a vyvstanou mu dodatečné onchain náklady. Voegtlin věří, + že existující poskytovatelé JIT kanálů se tomuto problému vyhýbají + tím, že vyžadují odhalení tajného kódu před tím, než je otevírací + transakce zajištěna, což podle něj může vytvářet problémy se zákonem + a zabraňuje nekustodiálním peněženkám podobnou službu nabízet. Voegtlin věří, že kdyby BOLT11 faktura obsahovala dva separátní commitmenty, každý na jinou částku a k jinému tajnému kódu, umožnilo by to použít jeden @@ -65,34 +65,34 @@ bitcoinových páteřních projektech. a částku na vlastní submarine swap nebo otevření JIT kanálu. Návrh obdržel několik komentářů, o některých se zde krátce zmíníme: - - *Logika speciálně pro submarine swaps:* Olaoluwa Osuntokun - [poznamenal][o 2p], že příjemce submarine swap musí vytvořit tajný kód, - distribuovat ho a vyrovnat oproti němu platbu onchain. Nejlevnějším - způsobem tohoto vyrovnání je interakce s poskytovatelem swapu. - Pokud plátce i příjemce musí s poskytovatelem tak jako tak komunikovat, - což se s existujícími implementacemi často děje, nemusí si předávat - dodatečné informace v rámci faktury. Voegtlin [odpověděl][v 2p2], že - tuto interakci může obstarat vyhrazený software a nebude tedy potřeba - přidávat logiku do offchain peněženky, která platí prostředky, a onchain - peněženky, která je přijímá. To by však bylo možné jen, pokud by - LN peněženka mohla učinit dvě oddělené platby v rámci jedné smlouvy. - - - *Stabilita BOLT11:* Matt Corallo [odpověděl][c 2p], že všechny LN - implementace stále ještě nemají podporu pro faktury bez částky (k umožnění - [spontánních plateb][topic spontaneous payments]), nemyslí si tedy, že - by přidání dalšího pole bylo nyní dobrým přístupem. Bastien Teinturier - [odpověděl podobně][t 2p] a navrhl raději přidat podporu do - [nabídek][topic offers]. Voegtlin [nesouhlasí][v 2p3] a myslí si, že - přidání podpory je praktické. - - - *Splice-out jako alternativa:* Corallo se dále táže, proč by měl být - protokol pozměněn, aby podporoval submarine swaps, pokud by byly - dostupné [splice outs][topic splicing]. V konverzaci to nebylo zmíněno, - avšak submarine swaps i splice outs umožňují přesunout offchain prostředky - na onchain výstup, ale splice outs mohou být efektivnější onchain a - netrpí problémem nekompenzovaného poplatku. Voegtlin odpověděl, že - submarine swaps umožňují uživatelům LN navýšit svou kapacitu pro - přijímání LN plateb, což splicing neumožňuje. + - *Logika speciálně pro submarine swaps:* Olaoluwa Osuntokun + [poznamenal][o 2p], že příjemce submarine swap musí vytvořit tajný kód, + distribuovat ho a vyrovnat oproti němu platbu onchain. Nejlevnějším + způsobem tohoto vyrovnání je interakce s poskytovatelem swapu. + Pokud plátce i příjemce musí s poskytovatelem tak jako tak komunikovat, + což se s existujícími implementacemi často děje, nemusí si předávat + dodatečné informace v rámci faktury. Voegtlin [odpověděl][v 2p2], že + tuto interakci může obstarat vyhrazený software a nebude tedy potřeba + přidávat logiku do offchain peněženky, která platí prostředky, a onchain + peněženky, která je přijímá. To by však bylo možné jen, pokud by + LN peněženka mohla učinit dvě oddělené platby v rámci jedné smlouvy. + + - *Stabilita BOLT11:* Matt Corallo [odpověděl][c 2p], že všechny LN + implementace stále ještě nemají podporu pro faktury bez částky (k umožnění + [spontánních plateb][topic spontaneous payments]), nemyslí si tedy, že + by přidání dalšího pole bylo nyní dobrým přístupem. Bastien Teinturier + [odpověděl podobně][t 2p] a navrhl raději přidat podporu do + [nabídek][topic offers]. Voegtlin [nesouhlasí][v 2p3] a myslí si, že + přidání podpory je praktické. + + - *Splice-out jako alternativa:* Corallo se dále táže, proč by měl být + protokol pozměněn, aby podporoval submarine swaps, pokud by byly + dostupné [splice outs][topic splicing]. V konverzaci to nebylo zmíněno, + avšak submarine swaps i splice outs umožňují přesunout offchain prostředky + na onchain výstup, ale splice outs mohou být efektivnější onchain a + netrpí problémem nekompenzovaného poplatku. Voegtlin odpověděl, že + submarine swaps umožňují uživatelům LN navýšit svou kapacitu pro + přijímání LN plateb, což splicing neumožňuje. V době psaní byla diskuze stále aktivní. @@ -173,12 +173,12 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a {% include references.md %} {% include linkers/issues.md v=2 issues="2294,2156" %} [policy series]: /cs/blog/waiting-for-confirmation/ -[v 2p]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-June/003977.html -[o 2p]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-June/003978.html -[v 2p2]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-June/003979.html -[c 2p]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-June/003980.html -[t 2p]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-June/003982.html -[v 2p3]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-June/003981.html +[v 2p]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-June/003977.html +[o 2p]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-June/003978.html +[v 2p2]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-June/003979.html +[c 2p]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-June/003980.html +[t 2p]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-June/003982.html +[v 2p3]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-June/003981.html [eclair v0.9.0]: https://github.com/ACINQ/eclair/releases/tag/v0.9.0 [news162 greenlight]: /en/newsletters/2021/08/18/#blockstream-announces-non-custodial-ln-cloud-service-greenlight [decker twitter]: https://twitter.com/Snyke/status/1666096470884515840 diff --git a/_posts/cs/newsletters/2023-06-28-newsletter.md b/_posts/cs/newsletters/2023-06-28-newsletter.md index 94a16321c7..bfcd41f77e 100644 --- a/_posts/cs/newsletters/2023-06-28-newsletter.md +++ b/_posts/cs/newsletters/2023-06-28-newsletter.md @@ -197,8 +197,8 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a {% include references.md %} {% include linkers/issues.md v=2 issues="6303,2701,2696,7710,2368,2367,2319,2120,2089,2077,1129" %} [policy series]: /cs/blog/waiting-for-confirmation/ -[sanders v3cj]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021780.html -[linus spec]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021781.html +[sanders v3cj]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021780.html +[linus spec]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021781.html [BTCPay Server 1.10.3]: https://github.com/btcpayserver/btcpayserver/releases/tag/v1.10.3 [btcpay 1.10]: https://blog.btcpayserver.org/btcpay-server-1-10-0/ [miningpool observer]: https://miningpool.observer/template-and-block diff --git a/_posts/cs/newsletters/2023-07-12-newsletter.md b/_posts/cs/newsletters/2023-07-12-newsletter.md index 50c0e5b35c..049e2d990d 100644 --- a/_posts/cs/newsletters/2023-07-12-newsletter.md +++ b/_posts/cs/newsletters/2023-07-12-newsletter.md @@ -165,7 +165,7 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a [news31 data loss]: /en/newsletters/2019/01/29/#fn:fn-data-loss-protect [news67 bolts642]: /en/newsletters/2019/10/09/#bolts-642 [lnd v0.16.4-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.16.4-beta -[russell clean up]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-June/004001.html +[russell clean up]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-June/004001.html [review club 27625]: https://bitcoincore.reviews/27625 [wiki getdata]: https://en.bitcoin.it/wiki/Protocol_documentation#getdata [news125 descriptor wallets]: /en/newsletters/2020/11/25/#how-will-the-migration-tool-from-a-bitcoin-core-legacy-wallet-to-a-descriptor-wallet-work diff --git a/_posts/cs/newsletters/2023-07-26-newsletter.md b/_posts/cs/newsletters/2023-07-26-newsletter.md index 89cc1d0d91..edf576bef5 100644 --- a/_posts/cs/newsletters/2023-07-26-newsletter.md +++ b/_posts/cs/newsletters/2023-07-26-newsletter.md @@ -38,116 +38,116 @@ páteřních projektech. Lightning-Dev [příspěvek][kc notes] se souhrnem diskuzí z nedávného setkání vývojářů LN v New Yorku. Mezi diskutovanými tématy bylo: - - *Spolehlivé potvrzování transakcí:* [přeposílání balíčků][topic - package relay], [přeposílání v3 transakcí][topic v3 transaction relay], - [dočasné anchor výstupy][topic ephemeral anchors], [cluster - mempool][topic cluster mempool] i další témata související s - přeposíláním transakcí a těžbou byly předmětem diskuzí v kontextu - hledání jasnější cesty ke spolehlivějšímu potvrzování onchain - transakcí bez hrozby [pinningu][topic transaction pinning] nebo - nutnosti přeplácet během navyšování poplatků pomocí [CPFP][topic cpfp] - a [RBF][topic rbf]. Doporučujeme čtenářům zajímajícím se o pravidla - přeposílání transakcí, která mají dopad na všechny protokoly druhé - vrstvy, aby si přečetli poznámky obsahující zajímavé informace - poskytnuté vývojáři LN. - - - *Taproot a MuSig2 kanály:* krátká diskuze o vývoji kanálů založených - na [P2TR][topic taproot] výstupech a [MuSig2][topic musig] pro - elektronické podpisy. Významná část poznámek se týká zjednodušeného - protokolu kooperativního zavření kanálu, kterému jsme se věnovali - v předchozím bodě. - - - *Aktualizovaná oznámení o kanálech:* gossip protokol LN v současnosti - přeposílá oznámení o nových nebo aktualizovaných kanálech jen, pokud - jsou tyto kanály financovány P2WSH výstupem se skriptem 2-ze-2 `OP_CHECKMULTISIG`. - Abychom mohli začít používat [P2TR][topic taproot] - výstupy a [multisig][topic multisignature] commitmenty založené na - [MuSig2][topic musig], musí být tento gossip protokol aktualizován. - Jedním z diskutovaných [témat][topic channel announcements] během - předchozího setkání LN vývojářů (viz [zpravodaj č. 204][news204 gossip]) - bylo, zda bychom měli učinit minimální aktualizaci protokolu (nazývanou - gossip v1.5), která by pouze přidala P2TR výstupy, či širší aktualizaci - protokolu (gossip v2.0), která by umožnila používat UTXO všech druhů. - Pokud by mohl být použit jakýkoliv výstup, znamenalo by to, že výstup - použitý pro oznámení kanálu nemusí být výstup, který je skutečně - používán pro provoz kanálu. Tato vlastnost by porušila veřejnou vazbu - mezi výstupy a financováním kanálů. - - Další diskutovanou myšlenkou bylo, zda by mělo být UTXO s hodnotou _n_ - umožněno oznamovat kanál s kapacitou větší než _n_. Díky tomu - by mohli účastníci kanálu ponechat některé z otevíracích transakcí - skryté. Například pokud by Alice a Bob spolu otevřeli dva kanály, mohli - by použít jeden kanál k vytvoření oznámení s hodnotou vyšší než je hodnota - tohoto kanálu. Tím by dali najevo, že mohou přeposílat platby vyšší, než - kolik činí hodnota kanálu; k tomu by využívali druhého, skrytého kanálu. - Díky tomu by mohli zvýšit pravděpodobnost, že kterýkoliv - výstup v síti, včetně nikdy neoznámených, by mohl být používán pro - LN kanál. - - Poznámka také hovoří o kompromisním rozhodnutí (gossip v1.75), - které by umožnilo používat jakýkoliv skript, ale bez navýšené - hodnoty. - - - *PTLC a redundantní přeplatky:* dle poznámek bylo krátce diskutováno - i přidání [PTLC][topic ptlc] do protokolu, hlavně v souvislosti se - [signature adaptors][topic adaptor signatures]. Větší část obsahu - poznámky byla věnována vylepšení, které by mělo dopad na obdobné - součásti protokolu: možnost [redundantního přeplacení][topic - redundant overpayments] faktury a následného vrácení většiny nebo - celého přeplatku. Příklad: Alice chce zaplatit Bobovi 1 BTC. - Nejprve pošle Bobovi 20 [plateb s více cestami][topic multipath payments], - každou o hodnotě 0,1 BTC. Díky použití buď matematiky (techniky - nazývané _boomerang_, viz [zpravodaj č. 86][news86 boomerang], *angl.*) - nebo commitmentů s více vrstvami a jednoho kola komunikace navíc - (tzv. _spear_) by byl Bob schopný nárokovat maximálně 10 těchto plateb. - Každá další platba, která by dosáhla jeho uzlu, by byla odmítnuta. Výhodou tohoto - přístupu je, že až 10 částečných plateb od Alice by mohlo selhat, aniž - by byla zpožděna celá platba. Nevýhodou se jeví býti zvýšená - složitost a, v případě spearu, pravděpodobně i nižší rychlost, než - kterou lze dosáhnout v dnešním stavu. Účastníci diskutovali, zda - by mohly být najednou učiněny změny potřebné pro PTLC i redundantní - přeplatky. - - - *Návrhy na obranu před zahlcením kanálu:* podstatná část poznámek - poskytla souhrn diskuze o návrzích na zabránění [útoků zahlcením - kanálu][topic channel jamming attacks]. Diskuze začala tvrzením, - že žádné jedno řešení (jako je reputace nebo poplatek předem) - nemůže úspěšně adresovat problém, aniž by nepřineslo nepřijatelné - vedlejší efekty. Systém reputace musí myslet na nové uzly bez - historie a na přirozenou míru neúspěšných HTLC; těchto by mohl - útočník zneužít a přinést určitou míru škody, i když menší než - dnes. Poplatky předem musí být nastaveny dostatečně vysoko, aby - odradily útočníky, ale ne příliš, aby také neodrazovaly poctivé - uživatele a aby neposkytovaly uzlům podnět k úmyslnému selhání - přeposílaných plateb. Namísto toho bylo navrženo, aby se používalo - několik způsobů najednou, což by umožnilo vyhnout se nejhorším - scénářům. - - Dále se poznámky soustředily na podrobnosti o testování schémat - lokální reputace popsaných ve [zpravodaji č. 226][news226 jamming] - (*angl.*) a přípravy na pozdější implementaci nízkých poplatků - napřed. Zdá se, že účastníci vyjádřili podporu testování - těchto návrhů. - - - *Jednodušší commitmenty:* účastníci diskutovali o protokolu zjednodušených - commitmentů (viz [zpravodaj č. 120][news120 commitments], *angl.*), - který definuje, která strana je zodpovědná za návrh příští změny - commitment transakce (oproti současnému stavu, kdy může změnu provést - kdykoliv kterákoliv strana). Pokud by byla zodpovědnost na jedné - ze stran, odstranilo by to složitost v případech existence dvou - návrhu odeslaných zhruba ve stejnou dobu (např. pokud by Alice - i Bob chtěli ve stejný okamžik přidat [HTLC][topic htlc]). Obzvláště - komplikovaný případ je, pokud jedna ze stran nechce akceptovat návrh - druhé strany. Tato situace je v současném protokolu těžko řešitelná. - Nevýhodou přístupu se zjednodušenými commitmenty je v některých případech - navýšení latence, jelikož by jedna strana musela před změnou požádat - druhou stranu o povolení. Poznámky nezmínily žádný jasný závěr - diskuze. - - - *Proces specifikace:* účastníci diskutovali o několika myšlenkách na - vylepšení procesu specifikace a jeho dokumentů, včetně současných - BOLTů a BLIPů. Diskuze byla, zdá se, velice pestrá a nepřinesla - žádné jasné závěry. + - *Spolehlivé potvrzování transakcí:* [přeposílání balíčků][topic + package relay], [přeposílání v3 transakcí][topic v3 transaction relay], + [dočasné anchor výstupy][topic ephemeral anchors], [cluster + mempool][topic cluster mempool] i další témata související s + přeposíláním transakcí a těžbou byly předmětem diskuzí v kontextu + hledání jasnější cesty ke spolehlivějšímu potvrzování onchain + transakcí bez hrozby [pinningu][topic transaction pinning] nebo + nutnosti přeplácet během navyšování poplatků pomocí [CPFP][topic cpfp] + a [RBF][topic rbf]. Doporučujeme čtenářům zajímajícím se o pravidla + přeposílání transakcí, která mají dopad na všechny protokoly druhé + vrstvy, aby si přečetli poznámky obsahující zajímavé informace + poskytnuté vývojáři LN. + + - *Taproot a MuSig2 kanály:* krátká diskuze o vývoji kanálů založených + na [P2TR][topic taproot] výstupech a [MuSig2][topic musig] pro + elektronické podpisy. Významná část poznámek se týká zjednodušeného + protokolu kooperativního zavření kanálu, kterému jsme se věnovali + v předchozím bodě. + + - *Aktualizovaná oznámení o kanálech:* gossip protokol LN v současnosti + přeposílá oznámení o nových nebo aktualizovaných kanálech jen, pokud + jsou tyto kanály financovány P2WSH výstupem se skriptem 2-ze-2 `OP_CHECKMULTISIG`. + Abychom mohli začít používat [P2TR][topic taproot] + výstupy a [multisig][topic multisignature] commitmenty založené na + [MuSig2][topic musig], musí být tento gossip protokol aktualizován. + Jedním z diskutovaných [témat][topic channel announcements] během + předchozího setkání LN vývojářů (viz [zpravodaj č. 204][news204 gossip]) + bylo, zda bychom měli učinit minimální aktualizaci protokolu (nazývanou + gossip v1.5), která by pouze přidala P2TR výstupy, či širší aktualizaci + protokolu (gossip v2.0), která by umožnila používat UTXO všech druhů. + Pokud by mohl být použit jakýkoliv výstup, znamenalo by to, že výstup + použitý pro oznámení kanálu nemusí být výstup, který je skutečně + používán pro provoz kanálu. Tato vlastnost by porušila veřejnou vazbu + mezi výstupy a financováním kanálů. + + Další diskutovanou myšlenkou bylo, zda by mělo být UTXO s hodnotou _n_ + umožněno oznamovat kanál s kapacitou větší než _n_. Díky tomu + by mohli účastníci kanálu ponechat některé z otevíracích transakcí + skryté. Například pokud by Alice a Bob spolu otevřeli dva kanály, mohli + by použít jeden kanál k vytvoření oznámení s hodnotou vyšší než je hodnota + tohoto kanálu. Tím by dali najevo, že mohou přeposílat platby vyšší, než + kolik činí hodnota kanálu; k tomu by využívali druhého, skrytého kanálu. + Díky tomu by mohli zvýšit pravděpodobnost, že kterýkoliv + výstup v síti, včetně nikdy neoznámených, by mohl být používán pro + LN kanál. + + Poznámka také hovoří o kompromisním rozhodnutí (gossip v1.75), + které by umožnilo používat jakýkoliv skript, ale bez navýšené + hodnoty. + + - *PTLC a redundantní přeplatky:* dle poznámek bylo krátce diskutováno + i přidání [PTLC][topic ptlc] do protokolu, hlavně v souvislosti se + [signature adaptors][topic adaptor signatures]. Větší část obsahu + poznámky byla věnována vylepšení, které by mělo dopad na obdobné + součásti protokolu: možnost [redundantního přeplacení][topic + redundant overpayments] faktury a následného vrácení většiny nebo + celého přeplatku. Příklad: Alice chce zaplatit Bobovi 1 BTC. + Nejprve pošle Bobovi 20 [plateb s více cestami][topic multipath payments], + každou o hodnotě 0,1 BTC. Díky použití buď matematiky (techniky + nazývané _boomerang_, viz [zpravodaj č. 86][news86 boomerang], *angl.*) + nebo commitmentů s více vrstvami a jednoho kola komunikace navíc + (tzv. _spear_) by byl Bob schopný nárokovat maximálně 10 těchto plateb. + Každá další platba, která by dosáhla jeho uzlu, by byla odmítnuta. Výhodou tohoto + přístupu je, že až 10 částečných plateb od Alice by mohlo selhat, aniž + by byla zpožděna celá platba. Nevýhodou se jeví býti zvýšená + složitost a, v případě spearu, pravděpodobně i nižší rychlost, než + kterou lze dosáhnout v dnešním stavu. Účastníci diskutovali, zda + by mohly být najednou učiněny změny potřebné pro PTLC i redundantní + přeplatky. + + - *Návrhy na obranu před zahlcením kanálu:* podstatná část poznámek + poskytla souhrn diskuze o návrzích na zabránění [útoků zahlcením + kanálu][topic channel jamming attacks]. Diskuze začala tvrzením, + že žádné jedno řešení (jako je reputace nebo poplatek předem) + nemůže úspěšně adresovat problém, aniž by nepřineslo nepřijatelné + vedlejší efekty. Systém reputace musí myslet na nové uzly bez + historie a na přirozenou míru neúspěšných HTLC; těchto by mohl + útočník zneužít a přinést určitou míru škody, i když menší než + dnes. Poplatky předem musí být nastaveny dostatečně vysoko, aby + odradily útočníky, ale ne příliš, aby také neodrazovaly poctivé + uživatele a aby neposkytovaly uzlům podnět k úmyslnému selhání + přeposílaných plateb. Namísto toho bylo navrženo, aby se používalo + několik způsobů najednou, což by umožnilo vyhnout se nejhorším + scénářům. + + Dále se poznámky soustředily na podrobnosti o testování schémat + lokální reputace popsaných ve [zpravodaji č. 226][news226 jamming] + (*angl.*) a přípravy na pozdější implementaci nízkých poplatků + napřed. Zdá se, že účastníci vyjádřili podporu testování + těchto návrhů. + + - *Jednodušší commitmenty:* účastníci diskutovali o protokolu zjednodušených + commitmentů (viz [zpravodaj č. 120][news120 commitments], *angl.*), + který definuje, která strana je zodpovědná za návrh příští změny + commitment transakce (oproti současnému stavu, kdy může změnu provést + kdykoliv kterákoliv strana). Pokud by byla zodpovědnost na jedné + ze stran, odstranilo by to složitost v případech existence dvou + návrhu odeslaných zhruba ve stejnou dobu (např. pokud by Alice + i Bob chtěli ve stejný okamžik přidat [HTLC][topic htlc]). Obzvláště + komplikovaný případ je, pokud jedna ze stran nechce akceptovat návrh + druhé strany. Tato situace je v současném protokolu těžko řešitelná. + Nevýhodou přístupu se zjednodušenými commitmenty je v některých případech + navýšení latence, jelikož by jedna strana musela před změnou požádat + druhou stranu o povolení. Poznámky nezmínily žádný jasný závěr + diskuze. + + - *Proces specifikace:* účastníci diskutovali o několika myšlenkách na + vylepšení procesu specifikace a jeho dokumentů, včetně současných + BOLTů a BLIPů. Diskuze byla, zdá se, velice pestrá a nepřinesla + žádné jasné závěry. ## Vybrané otázky a odpovědi z Bitcoin Stack Exchange @@ -222,8 +222,8 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a {% include references.md %} {% include linkers/issues.md v=2 issues="740,1096" %} -[russell closing]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-July/004013.html -[kc notes]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-July/004014.html +[russell closing]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-July/004013.html +[kc notes]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-July/004014.html [news193 gossip]: /en/newsletters/2022/03/30/#continued-discussion-about-updated-ln-gossip-protocol [news204 gossip]: /cs/newsletters/2022/06/15/#aktualizace-gossip-protokolu [news86 boomerang]: /en/newsletters/2020/02/26/#boomerang-redundancy-improves-latency-and-throughput-in-payment-channel-networks diff --git a/_posts/cs/newsletters/2023-08-02-newsletter.md b/_posts/cs/newsletters/2023-08-02-newsletter.md index b6effac613..d467efe288 100644 --- a/_posts/cs/newsletters/2023-08-02-newsletter.md +++ b/_posts/cs/newsletters/2023-08-02-newsletter.md @@ -160,16 +160,16 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a {% include linkers/issues.md v=2 issues="863,26467,6378,6449,6399,6389,6403,6437,6398,5492,2680,7820,7516,5155" %} [clnrest doc]: https://github.com/rustyrussell/lightning/blob/02c2d8a9e3b450ce172e8bc50c855ac2a16f5cac/plugins/clnrest/README.md [news133 usdt]: /en/newsletters/2021/01/27/#bitcoin-core-19866 -[kc scripts]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-July/004025.html +[kc scripts]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-July/004025.html [btcscripts spec]: https://btctranscripts.com/lightning-specification/ [libera.chat]: https://libera.chat/ -[trevethan blind]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-July/021792.html +[trevethan blind]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-July/021792.html [generalized blind schnorr]: https://gist.github.com/moonsettler/05f5948291ba8dba63a3985b786233bb [somsen gist]: https://gist.github.com/RubenSomsen/be7a4760dd4596d06963d67baf140406 [lucre]: https://github.com/benlaurie/lucre [minicash]: https://github.com/phyro/minicash [cashu]: https://github.com/cashubtc/cashu -[fiatjaf custodial]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-July/004008.html +[fiatjaf custodial]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-July/004008.html [news210 commando]: /en/newsletters/2022/07/27/#core-lightning-5370 [dhke]: https://cs.wikipedia.org/wiki/Diffieho%E2%80%93Hellmanova_v%C3%BDm%C4%9Bna_kl%C3%AD%C4%8D%C5%AF [btcpay server 1.11.1]: https://github.com/btcpayserver/btcpayserver/releases/tag/v1.11.1 diff --git a/_posts/cs/newsletters/2023-08-09-newsletter.md b/_posts/cs/newsletters/2023-08-09-newsletter.md index a1fd7f7058..994fc93ce4 100644 --- a/_posts/cs/newsletters/2023-08-09-newsletter.md +++ b/_posts/cs/newsletters/2023-08-09-newsletter.md @@ -339,16 +339,16 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a {% include references.md %} {% include linkers/issues.md v=2 issues="27746,6376,6475,6466,6473,6253,5675,863,1945,759,28132,28130" %} [news245 blinded]: /cs/newsletters/2023/04/05/#bolts-765 -[towns dos]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-July/004020.html +[towns dos]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-July/004020.html [news86 hold fees]: /en/newsletters/2020/02/26/#reverse-up-front-payments -[shikhelman dos]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-July/004033.html -[towns dos2]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-August/004035.html -[kcs endorsement]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-August/004034.html -[todd rbf]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-July/021823.html +[shikhelman dos]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-July/004033.html +[towns dos2]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-August/004035.html +[kcs endorsement]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-August/004034.html +[todd rbf]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-July/021823.html [towns rbf]: https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1657669845 [news207 onion]: /en/newsletters/2022/07/06/#onion-message-rate-limiting [news261 jamming]: /cs/newsletters/2023/07/26/#navrhy-na-obranu-pred-zahlcenim-kanalu -[todd opr]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021840.html +[todd opr]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021840.html [review club 28122]: https://bitcoincore.reviews/28122 [bip352]: https://github.com/bitcoin/bips/pull/1458 [bip158]: https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki diff --git a/_posts/cs/newsletters/2023-08-16-newsletter.md b/_posts/cs/newsletters/2023-08-16-newsletter.md index a984c8830d..5553cc4df1 100644 --- a/_posts/cs/newsletters/2023-08-16-newsletter.md +++ b/_posts/cs/newsletters/2023-08-16-newsletter.md @@ -101,16 +101,16 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a podle specifikace v [BIP324][]. Byly přidány následující šifry a třídy (citováno z PR): - - „ChaCha20Poly1305 AEAD z RFC8439, sekce 2.8” + - „ChaCha20Poly1305 AEAD z RFC8439, sekce 2.8” - - „Proudová šifra FSChaCha20 (forward secrecy) podle specifikace v - BIP324 (rekeying wrapper okolo ChaCha20)” + - „Proudová šifra FSChaCha20 (forward secrecy) podle specifikace v + BIP324 (rekeying wrapper okolo ChaCha20)” - - „FSChaCha20Poly1305 AEAD podle specifikace BIP324 (rekeying - wrapper okolo ChaCha20Poly1305)” + - „FSChaCha20Poly1305 AEAD podle specifikace BIP324 (rekeying + wrapper okolo ChaCha20Poly1305)” - - „Třída BIP324Cipher, která zapouzdřuje vyjednávání o klíči, odvozování - klíčů a proudové šifry a AEAD pro kódování paketů dle BIP324” + - „Třída BIP324Cipher, která zapouzdřuje vyjednávání o klíči, odvozování + klíčů a proudové šifry a AEAD pro kódování paketů dle BIP324” - [LDK #2308][] umožňuje plátci ve svých platbách začlenit vlastní TLV (Tag-Length-Value) položky, které budou moci příjemci používající LDK či kompatibilní @@ -119,10 +119,10 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a {% include references.md %} {% include linkers/issues.md v=2 issues="27213,28008,2308" %} -[todd expire]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021849.html -[gould spj]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021868.html +[todd expire]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021849.html +[gould spj]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021868.html [spj bip]: https://github.com/bitcoin/bips/pull/1483 -[gibson spj]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021872.html -[gould spj2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021880.html +[gibson spj]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021872.html +[gould spj2]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021880.html [news236 spj]: /cs/newsletters/2023/02/01/#navrh-na-bezserverovy-payjoin [core lightning 23.08rc2]: https://github.com/ElementsProject/lightning/releases/tag/v23.08rc2 diff --git a/_posts/cs/newsletters/2023-08-23-newsletter.md b/_posts/cs/newsletters/2023-08-23-newsletter.md index a65989cd09..ef57c4dc44 100644 --- a/_posts/cs/newsletters/2023-08-23-newsletter.md +++ b/_posts/cs/newsletters/2023-08-23-newsletter.md @@ -19,25 +19,25 @@ významných změn v populárním bitcoinovém páteřním software. na službu, která by mohla být penalizována v případě poskytnutí jiné než poslední verze zálohy. Základní mechanismus je jednoduchý: - - Alice má data, která chce zálohovat. Přidá do nich číslo verze, podepíše - je a data i podpis poskytne Bobovi. + - Alice má data, která chce zálohovat. Přidá do nich číslo verze, podepíše + je a data i podpis poskytne Bobovi. - - Okamžitě po obdržení Aliciných dat jí Bob pošle podpis, který zavazuje - k číslu verze jejích dat a k aktuálnímu času. + - Okamžitě po obdržení Aliciných dat jí Bob pošle podpis, který zavazuje + k číslu verze jejích dat a k aktuálnímu času. - - Po čase Alice data aktualizuje, navýší číslo verze a poskytne aktualizaci - Bobovi spolu s novým podpisem. Bob vrátí podpis zavazující k nové, vyšší - verzi a novému, vyššímu aktuální času. Tento krok mnohokrát opakují. + - Po čase Alice data aktualizuje, navýší číslo verze a poskytne aktualizaci + Bobovi spolu s novým podpisem. Bob vrátí podpis zavazující k nové, vyšší + verzi a novému, vyššímu aktuální času. Tento krok mnohokrát opakují. - - V jeden okamžik Alice od Boba vyžádá svá data, aby ho otestovala. Bob - jí pošle verzi dat a její podpis, které může Alice ověřit. Bob jí též - pošle další podpis, který zavazuje k číslu verze dat a aktuálnímu - času. + - V jeden okamžik Alice od Boba vyžádá svá data, aby ho otestovala. Bob + jí pošle verzi dat a její podpis, které může Alice ověřit. Bob jí též + pošle další podpis, který zavazuje k číslu verze dat a aktuálnímu + času. - - Pokud by Bob jednal nečestně a poslal Alici stará data se starým číslem - verze, Alice by mohla vygenerovat _doklad o podvodu_: mohla by prokázat, - že Bob předtím podepsal vyšší číslo verze s dřívějším časem, než ke kterým - zavazuje podpis, který jí poslal právě teď. + - Pokud by Bob jednal nečestně a poslal Alici stará data se starým číslem + verze, Alice by mohla vygenerovat _doklad o podvodu_: mohla by prokázat, + že Bob předtím podepsal vyšší číslo verze s dřívějším časem, než ke kterým + zavazuje podpis, který jí poslal právě teď. Mechanismus generování dokladů o podvodu, jak byl zatím popsán, nemá nic společného s bitcoinem. Voegtlin však poznamenal, že pokud by opkódy @@ -211,12 +211,12 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a [news173 trim]: /en/newsletters/2021/11/03/#c-lightning-4837 [news170 trim]: /en/newsletters/2021/10/13/#ln-spend-to-fees-cve [elements project]: https://elementsproject.org/ -[voegtlin backups]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-August/004043.html -[todd backups1]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-August/004046.html -[todd backups2]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-August/004044.html -[teinturier backups]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-August/004045.html -[ghost43 backups]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-August/004052.html -[voegtlin backups2]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-August/004055.html +[voegtlin backups]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-August/004043.html +[todd backups1]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-August/004046.html +[todd backups2]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-August/004044.html +[teinturier backups]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-August/004045.html +[ghost43 backups]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-August/004052.html +[voegtlin backups2]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-August/004055.html [Scaling Lightning]: https://github.com/scaling-lightning/scaling-lightning [sl twitter update]: https://twitter.com/max_blue__/status/1681781001373065216 [sl tg]: https://t.me/+AytRsS0QKH5mMzM8 diff --git a/_posts/cs/newsletters/2023-08-30-newsletter.md b/_posts/cs/newsletters/2023-08-30-newsletter.md index f4ead902b0..022424998e 100644 --- a/_posts/cs/newsletters/2023-08-30-newsletter.md +++ b/_posts/cs/newsletters/2023-08-30-newsletter.md @@ -199,11 +199,11 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a [LND v0.17.0-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.17.0-beta.rc1 [core lightning 23.08]: https://github.com/ElementsProject/lightning/releases/tag/v23.08 [delv mashup]: https://delvingbitcoin.org/t/combined-ctv-apo-into-minimal-txhash-csfs/60/6 -[morehouse dos]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-August/004064.html +[morehouse dos]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-August/004064.html [morehouse post]: https://morehouse.github.io/lightning/fake-channel-dos/ [news237 dos]: /cs/newsletters/2023/02/08/#core-lightning-5849 [news240 dos]: /cs/newsletters/2023/03/01/#ldk-1988 -[black mashup]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021907.html +[black mashup]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021907.html [news185 txhash]: /en/newsletters/2022/02/02/#composable-alternatives-to-ctv-and-apo [stateless funding]: https://gnusha.org/lightning-dev/2023-08-27.log [bip158 filters]: https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki#block-filters diff --git a/_posts/cs/newsletters/2023-09-06-newsletter.md b/_posts/cs/newsletters/2023-09-06-newsletter.md index 4e93cda520..4364ac0c7e 100644 --- a/_posts/cs/newsletters/2023-09-06-newsletter.md +++ b/_posts/cs/newsletters/2023-09-06-newsletter.md @@ -122,10 +122,10 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a {% include references.md %} {% include linkers/issues.md v=2 issues="28354,2468" %} [LND v0.17.0-beta.rc2]: https://github.com/lightningnetwork/lnd/releases/tag/v0.17.0-beta.rc2 -[briar compress]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021924.html +[briar compress]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021924.html [compress spec]: https://github.com/TomBriar/bitcoin/blob/2023-05--tx-compression/doc/compressed_transactions.md [compress impl]: https://github.com/TomBriar/bitcoin/pull/3 -[farrow cosign]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021917.html +[farrow cosign]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021917.html [frost]: https://eprint.iacr.org/2020/852 [libsecp cl]: https://github.com/bitcoin-core/secp256k1/blob/master/CHANGELOG.md [libsecp256k1 0.4.0]: https://github.com/bitcoin-core/secp256k1/releases/tag/v0.4.0 diff --git a/_posts/cs/newsletters/2023-09-13-newsletter.md b/_posts/cs/newsletters/2023-09-13-newsletter.md index 7235e23fb6..e0400b0a28 100644 --- a/_posts/cs/newsletters/2023-09-13-newsletter.md +++ b/_posts/cs/newsletters/2023-09-13-newsletter.md @@ -159,10 +159,10 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a [net]: https://github.com/bitcoin/bitcoin/blob/master/src/net.h [net_processing]: https://github.com/bitcoin/bitcoin/blob/master/src/net_processing.h [news195 taro]: /en/newsletters/2022/04/13/#transferable-token-scheme -[osuntokun bips]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-September/021938.html -[osuntokun blip post]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-September/004089.html +[osuntokun bips]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-September/021938.html +[osuntokun blip post]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-September/004089.html [osuntokun blip]: https://github.com/lightning/blips/pull/29 [review club 28165]: https://bitcoincore.reviews/28165 -[sanders post]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-September/004088.html +[sanders post]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-September/004088.html [sanders ptlc]: https://gist.github.com/instagibbs/1d02d0251640c250ceea1c66665ec163 [v2 p2p tracking pr]: https://github.com/bitcoin/bitcoin/issues/27634 diff --git a/_posts/cs/newsletters/2023-09-20-newsletter.md b/_posts/cs/newsletters/2023-09-20-newsletter.md index 5d5646b4e9..0d1e50c7a6 100644 --- a/_posts/cs/newsletters/2023-09-20-newsletter.md +++ b/_posts/cs/newsletters/2023-09-20-newsletter.md @@ -139,7 +139,7 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a {% include references.md %} {% include linkers/issues.md v=2 issues="26152,28414,28448,28196,2743,2176,2413,2514,2371" %} [LND v0.17.0-beta.rc4]: https://github.com/lightningnetwork/lnd/releases/tag/v0.17.0-beta.rc4 -[ds brd]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-September/021959.html +[ds brd]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-September/021959.html [news252 bumpfee]: /cs/newsletters/2023/05/24/#bitcoin-core-27021 [news229 bumpfee]: /cs/newsletters/2022/12/07/#bitcoin-core-pr-review-club [Core Lightning 23.08.1]: https://github.com/ElementsProject/lightning/releases/tag/v23.08.1 diff --git a/_posts/cs/newsletters/2023-09-27-newsletter.md b/_posts/cs/newsletters/2023-09-27-newsletter.md index a3f708dabc..7eb1492a08 100644 --- a/_posts/cs/newsletters/2023-09-27-newsletter.md +++ b/_posts/cs/newsletters/2023-09-27-newsletter.md @@ -239,11 +239,11 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a [LND v0.17.0-beta.rc5]: https://github.com/lightningnetwork/lnd/releases/tag/v0.17.0-beta.rc5 [news253 ark]: /cs/newsletters/2023/05/31/#navrh-na-spravovany-joinpool-protokol [maxwell clock stop]: https://www.reddit.com/r/Bitcoin/comments/37fxqd/it_looks_like_blockstream_is_working_on_the/crmr5p2/ -[law cov post]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-September/004092.html +[law cov post]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-September/004092.html [law cov paper]: https://github.com/JohnLaw2/ln-scaling-covenants -[towns cov]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-September/004095.html +[towns cov]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-September/004095.html [ln paper]: https://lightning.network/lightning-network-paper.pdf -[law fee stop]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-September/004102.html +[law fee stop]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-September/004102.html [news221 law]: /en/newsletters/2022/10/12/#ln-with-long-timeouts-proposal [news230 law]: /cs/newsletters/2022/12/14/#navrh-na-ln-protokol-pro-tovarny [news244 law]: /cs/newsletters/2023/03/29/#jak-predejit-uviznuti-kapitalu-pomoci-kanalu-s-vice-stranami-a-tovarnami-kanalu diff --git a/_posts/cs/newsletters/2023-10-04-newsletter.md b/_posts/cs/newsletters/2023-10-04-newsletter.md index 4cafa7be75..967156f01f 100644 --- a/_posts/cs/newsletters/2023-10-04-newsletter.md +++ b/_posts/cs/newsletters/2023-10-04-newsletter.md @@ -153,14 +153,14 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a {% include references.md %} {% include linkers/issues.md v=2 issues="2756,2486,2609,28" %} [LND v0.17.0-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.17.0-beta -[teinturier remote post]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-September/004084.html +[teinturier remote post]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-September/004084.html [news210 commando]: /en/newsletters/2022/07/27/#core-lightning-5370 -[van dam pss post]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-September/004114.html +[van dam pss post]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-September/004114.html [pss plugin]: https://github.com/gijswijs/plugins/tree/master/pss [pss research]: https://eprint.iacr.org/2023/1360 -[zmnscpxj sidepools1]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-September/004099.html +[zmnscpxj sidepools1]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-September/004099.html [peerswap]: https://github.com/ElementsProject/peerswap [duplex payment channels]: https://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf -[zmnscpxj sidepools2]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-September/004108.html +[zmnscpxj sidepools2]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-September/004108.html [lnd rn]: https://github.com/lightningnetwork/lnd/blob/master/docs/release-notes/release-notes-0.17.0.md [lnd 17 blog]: https://lightning.engineering/posts/2023-10-03-lnd-0.17-launch/ diff --git a/_posts/cs/newsletters/2023-10-11-newsletter.md b/_posts/cs/newsletters/2023-10-11-newsletter.md index c7ebd9c240..72e4c2ec15 100644 --- a/_posts/cs/newsletters/2023-10-11-newsletter.md +++ b/_posts/cs/newsletters/2023-10-11-newsletter.md @@ -192,7 +192,7 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a {% include references.md %} {% include linkers/issues.md v=2 issues="27596,28590,28562,28589,28331,28588,28577,28553,754,27609,764,6676,1500" %} -[roose txhash]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-September/021975.html +[roose txhash]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-September/021975.html [news185 txhash]: /en/newsletters/2022/02/02/#composable-alternatives-to-ctv-and-apo [ldk 0.0.117]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.0.117 [bdk 0.29.0]: https://github.com/bitcoindevkit/bdk/releases/tag/v0.29.0 @@ -201,4 +201,4 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a [GenTxid]: https://github.com/bitcoin/bitcoin/blob/dcfbf3c2107c3cb9d343ebfa0eee78278dea8d66/src/primitives/transaction.h#L425 [news104 wtxid]: /en/newsletters/2020/07/01/#bips-933 [assumeutxo core dev]: https://btctranscripts.com/bitcoin-core-dev-tech/2018-03/2018-03-07-priorities/#:~:text=“Assume%20UTXO” -[assumeutxo 2019 mailing list]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-April/016825.html +[assumeutxo 2019 mailing list]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-April/016825.html diff --git a/_posts/cs/newsletters/2023-10-18-newsletter.md b/_posts/cs/newsletters/2023-10-18-newsletter.md index 40d0a6ccdb..00a12469e2 100644 --- a/_posts/cs/newsletters/2023-10-18-newsletter.md +++ b/_posts/cs/newsletters/2023-10-18-newsletter.md @@ -163,16 +163,16 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a {% include references.md %} {% include linkers/issues.md v=2 issues="27255,2703,7267,1041" %} -[linus post]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/021984.html +[linus post]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/021984.html [linus paper]: https://bitvm.org/bitvm.pdf [nand gate]: https://cs.wikipedia.org/wiki/Logick%C3%BD_%C4%8Dlen#NAND_(Shefferova_funkce) [Bitcoin Core 24.2rc2]: https://bitcoincore.org/bin/bitcoin-core-24.2/ [Bitcoin Core 25.1rc1]: https://bitcoincore.org/bin/bitcoin-core-25.1/ -[riard cve]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/021999.html +[riard cve]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/021999.html [mpsbt-bip]: https://github.com/achow101/bips/blob/musig2-psbt/bip-musig2-psbt.mediawiki [kanjalkar mpsbt]: https://gist.github.com/sanket1729/4b525c6049f4d9e034d27368c49f28a6 -[chow mpsbt]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/021988.html -[towns mpsbt]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/021991.html +[chow mpsbt]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/021988.html +[towns mpsbt]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/021991.html [BIP-329 Python Library]: https://github.com/Labelbase/python-bip329 [Doppler]: https://github.com/tee8z/doppler [doppler announced]: https://twitter.com/voltage_cloud/status/1712171748144070863 diff --git a/_posts/cs/newsletters/2023-10-25-newsletter.md b/_posts/cs/newsletters/2023-10-25-newsletter.md index 57e1b687d0..362e6f1e98 100644 --- a/_posts/cs/newsletters/2023-10-25-newsletter.md +++ b/_posts/cs/newsletters/2023-10-25-newsletter.md @@ -85,7 +85,9 @@ Bitcoin Stack Exchange. Aby byl útok výnosný, musí MalloryB sdílet s Bobem kanál, ale MalloryA může být kdekoliv na cestě k Bobovi, například: - MalloryA -> X -> Y -> Z -> Bob -> MalloryB + ``` + MalloryA -> X -> Y -> Z -> Bob -> MalloryB + ``` Replacement cycling má pro LN uzly podobné důsledky jako [transaction pinning útoky][topic transaction pinning]. Avšak techniky jako [přeposílání transakcí verze 3][topic v3 transaction @@ -96,211 +98,211 @@ Bitcoin Stack Exchange. [popsal][riard cycle1] Antoine Riard, v LN implementacích bylo nasazeno několik opatření. - - **Častá opakovaná zveřejňování:** poté, co mempool uzlu nahradí Bobovu transakci - Mallořinou a Mallořin vstup odstraní pomocí její druhé nahrazovací transakce, - je tento uzel okamžitě ochoten znovu přijmout Bobovu transakci. Bob ji jen musí - znovu zveřejnit, což ho bude stát stejný poplatek, jaký byl ochoten - zaplatit již předtím. - - Před soukromým odhalením replacement cycling útoku LN implementace - opakovaně zveřejňovaly své transakce méně často, jednou za blok či méně. - Zveřejňování či opakované zveřejňování transakcí obvykle přináší náklady - v určité [ztrátě soukromí][topic transaction origin privacy]: třetí - strany mohou snáze asociovat Bobovu onchain LN aktivitu s jeho IP adresou. - Jen málo veřejných LN uzlů to však v současnosti bere v potaz. Nově budou - Core Lightning, Eclair, LDK i LND opakovaně zveřejňovat častěji. - - Po každém Bobově opakovaném zveřejnění může Mallory opět použít stejnou - techniku k nahrazení jeho transakce. Avšak pravidla nahrazení dle BIP125 - budou po Mallory vyžadovat dodatečný poplatek za každé další nahrazení, - čili každé další Bobovo zveřejnění snižuje Mallory ziskovost útoku. - - Z toho vyplývá hrubý vzorec pro nejvyšší částku HTLC, kterou by měl - uzel přijmout. Jsou-li útočníkovy náklady za každé kolo nahrazení - _x_, počet bloků, který má obránce k dispozici, je _y_ - a počet efektivních zveřejnění, která obránce průměrně za blok učiní, - je _z_, je HTLC pravděpodobně rozumně zabezpečené do výše kousek pod `x*y*z`. - - - **Delší CLTV expiry delta:** když Bob akceptuje od MalloryA HTLC, - souhlasí, že jí umožní nárokovat onchain refundaci po určitém počtu - bloků (řekněme 200 bloků). Když Bob nabídne ekvivalentní HTLC - MalloryB, dovoluje mu nárokovat refundaci po nižším počtu bloků - (řekněme 100 bloků). Tyto expirační podmínky jsou zapsány pomocí - opkódu `OP_CHECKLOCKTIMEVERIFY` (CLTV), proto se rozdíl mezi nimi - nazývá _CLTV expiry delta_. - - Čím delší je CLTV expiry delta, tím déle musí původní odesílatel - platby čekat na návrat svých prostředků v případě selhání platby, - proto odesílatelé preferují posílat platby cestami s kratšími delta. - Avšak také platí, že čím delší je delta, tím více času má přeposílající - uzel (jako Bob) na reakci na problémy jako [transaction pinning][topic - transaction pinning] a masové zavírání kanálů. Tyto protichůdné - požadavky vedly k častým změnám v LN software v nastavení výchozích delta, - viz zpravodaje čísla [40][news40 delta], [95][news95 delta], [109][news109 delta], - [112][news112 delta], [142][news142 delta] (vše _angl._), [248][news248 delta] a - [255][news255 delta]. - - V případě replacement cycling útoku dává Bobovi delší CLTV delta více možností - opakovaného zveřejnění, což zvyšuje náklady útoku podle výše zmíněného - vzorce. - - Navíc pokaždé, když je Bobova opakovaně zveřejněná transakce v mempoolu - těžaře, existuje šance, že ji těžař vybere do šablony bloku, kterou poté - vytěží. Tím by byl útok zmařen. Mallořino úvodní nahrazení s předobrazem - by též mohlo být vytěženo před tím, než by měla možnost jej nahradit. - I toto by útok překazilo. Stráví-li v každém cyklu tyto dvě - transakce určitou dobu v těžařově mempoolu, každé Bobovo opakované - zveřejnění tuto dobu násobí, stejně jako ji dále násobí CLTV expiry delta. - - Například i když tyto transakce stráví v mempoolu průměrného těžaře pouze 1 % - času na blok, existuje zhruba 50% šance, že útok selže, je-li CLTV expiry delta - jen 70 bloků. Následující graf ukazuje pravděpodobnost selhání Mallořina - útoku za použití současných výchozích hodnot CLTV expiry delta v různých - LN implementacích vypsaných v Riardově emailu. Předpokladem je, že - očekávané HTLC transakce jsou v mempoolech těžařů 0,1 % času, 1 % času - nebo 5 % času. Pro referenci: je-li průměrný čas mezi bloky 600 sekund, - odpovídají tato procenta pouhým 0,6 sekundám, 6 sekundám a 30 sekundám - z každých 10 minut. - - ![Plot of probability attack will fail within x blocks](/img/posts/2023-10-cltv-expiry-delta-cycling.png) - - - **Skenování mempoolu:** design HTLC dává Mallory podnět, aby - nechala potvrdit transakci s předobrazem před tím, než může Bob - nárokovat refundaci. Pro Boba je to praktické: blockchain je široce - dostupný a jeho velikost omezena, Bob tedy může snadno najít - jakýkoliv předobraz, který se ho týká. Kdyby tento systém fungoval - podle záměru, Bob by mohl z blockchainu získat všechny informace potřebné - pro provoz LN. - - Bohužel, replacement cycling znamená, že Mallory již nemusí být - motivována k potvrzení své transakce před Bobovým nárokováním - refundace. Ale aby mohla Mallory zahájit replacement cycle, musí - krátce odhalit předobraz v rámci mempoolů těžařů, chce-li nahradit - Bobovu transakci. Pokud Bob provozuje přeposílající plný uzel, - Mallořina transakce s předobrazem může procházet i Bobovým uzlem. - Pokud by Bob včas detekoval předobraz, útok by odrazil a Mallory - by ztratila všechny peníze, které během pokusu o útok utratila. - - Skenování mempoolu není všemocné: neexistuje záruka, že Mallořina - nahrazující transakce proteče Bobovým uzlem. Avšak čím častěji - Bob opakovaně zveřejňuje svou transakci (viz _častá opakovaná zveřejňování_) - a čím déle musí Mallory před Bobem skrývat svůj předobraz (viz - _delší CLTV expiry delta_), tím pravděpodobnější je, že se jedna z - transakcí s předobrazem včas dostane do Bobova mempoolu. - - Eclair a LND v současnosti implementují skenování mempoolu u - přeposílajících uzlů. - - - **Diskuze o účinnosti opatření:** Riard v úvodním oznámení napsal: - „Věřím, že replacement cycling útoky jsou pro schopné útočníky nadále - praktické.” Matto Corallo [napsal][corallo cycle1], že „nasazená - opatření problém neodstraňují; lze argumentovat, že neposkytují víc - než pouhé PR vyjádření.” Olaoluwa Osuntokun [polemizoval][osuntokun - cycle1]: „[podle mého názoru] se jedná spíše o vratký druh útoku, - který vyžaduje určité aranžmá jednotlivých uzlů, extrémně přesné načasování - a provedení, nepotvrzující postavení všech transakcí a okamžitou - propagaci celou sítí.” - - My v Optechu si myslíme, že je důležité znovu zdůraznit, že tento útok - postihuje pouze přeposílající uzly. Přeposílající uzel je bitcoinová - horká peněženka neustále připojená k internetu. Jedná se o druh - nasazení, který je neustále jednu zranitelnost od ztráty všech prostředků. - Každý, kdo vyhodnocuje dopad replacement cyclingu na rizikovost provozu - přeposílajícího LN uzlu, by tak měl činit v rámci již existujícího rizika. - Pochopitelně je dobré hledat další způsoby snižování rizika. - Tím se zabývá náš další bod. + - **Častá opakovaná zveřejňování:** poté, co mempool uzlu nahradí Bobovu transakci + Mallořinou a Mallořin vstup odstraní pomocí její druhé nahrazovací transakce, + je tento uzel okamžitě ochoten znovu přijmout Bobovu transakci. Bob ji jen musí + znovu zveřejnit, což ho bude stát stejný poplatek, jaký byl ochoten + zaplatit již předtím. + + Před soukromým odhalením replacement cycling útoku LN implementace + opakovaně zveřejňovaly své transakce méně často, jednou za blok či méně. + Zveřejňování či opakované zveřejňování transakcí obvykle přináší náklady + v určité [ztrátě soukromí][topic transaction origin privacy]: třetí + strany mohou snáze asociovat Bobovu onchain LN aktivitu s jeho IP adresou. + Jen málo veřejných LN uzlů to však v současnosti bere v potaz. Nově budou + Core Lightning, Eclair, LDK i LND opakovaně zveřejňovat častěji. + + Po každém Bobově opakovaném zveřejnění může Mallory opět použít stejnou + techniku k nahrazení jeho transakce. Avšak pravidla nahrazení dle BIP125 + budou po Mallory vyžadovat dodatečný poplatek za každé další nahrazení, + čili každé další Bobovo zveřejnění snižuje Mallory ziskovost útoku. + + Z toho vyplývá hrubý vzorec pro nejvyšší částku HTLC, kterou by měl + uzel přijmout. Jsou-li útočníkovy náklady za každé kolo nahrazení + _x_, počet bloků, který má obránce k dispozici, je _y_ + a počet efektivních zveřejnění, která obránce průměrně za blok učiní, + je _z_, je HTLC pravděpodobně rozumně zabezpečené do výše kousek pod `x*y*z`. + + - **Delší CLTV expiry delta:** když Bob akceptuje od MalloryA HTLC, + souhlasí, že jí umožní nárokovat onchain refundaci po určitém počtu + bloků (řekněme 200 bloků). Když Bob nabídne ekvivalentní HTLC + MalloryB, dovoluje mu nárokovat refundaci po nižším počtu bloků + (řekněme 100 bloků). Tyto expirační podmínky jsou zapsány pomocí + opkódu `OP_CHECKLOCKTIMEVERIFY` (CLTV), proto se rozdíl mezi nimi + nazývá _CLTV expiry delta_. + + Čím delší je CLTV expiry delta, tím déle musí původní odesílatel + platby čekat na návrat svých prostředků v případě selhání platby, + proto odesílatelé preferují posílat platby cestami s kratšími delta. + Avšak také platí, že čím delší je delta, tím více času má přeposílající + uzel (jako Bob) na reakci na problémy jako [transaction pinning][topic + transaction pinning] a masové zavírání kanálů. Tyto protichůdné + požadavky vedly k častým změnám v LN software v nastavení výchozích delta, + viz zpravodaje čísla [40][news40 delta], [95][news95 delta], [109][news109 delta], + [112][news112 delta], [142][news142 delta] (vše _angl._), [248][news248 delta] a + [255][news255 delta]. + + V případě replacement cycling útoku dává Bobovi delší CLTV delta více možností + opakovaného zveřejnění, což zvyšuje náklady útoku podle výše zmíněného + vzorce. + + Navíc pokaždé, když je Bobova opakovaně zveřejněná transakce v mempoolu + těžaře, existuje šance, že ji těžař vybere do šablony bloku, kterou poté + vytěží. Tím by byl útok zmařen. Mallořino úvodní nahrazení s předobrazem + by též mohlo být vytěženo před tím, než by měla možnost jej nahradit. + I toto by útok překazilo. Stráví-li v každém cyklu tyto dvě + transakce určitou dobu v těžařově mempoolu, každé Bobovo opakované + zveřejnění tuto dobu násobí, stejně jako ji dále násobí CLTV expiry delta. + + Například i když tyto transakce stráví v mempoolu průměrného těžaře pouze 1 % + času na blok, existuje zhruba 50% šance, že útok selže, je-li CLTV expiry delta + jen 70 bloků. Následující graf ukazuje pravděpodobnost selhání Mallořina + útoku za použití současných výchozích hodnot CLTV expiry delta v různých + LN implementacích vypsaných v Riardově emailu. Předpokladem je, že + očekávané HTLC transakce jsou v mempoolech těžařů 0,1 % času, 1 % času + nebo 5 % času. Pro referenci: je-li průměrný čas mezi bloky 600 sekund, + odpovídají tato procenta pouhým 0,6 sekundám, 6 sekundám a 30 sekundám + z každých 10 minut. + + ![Plot of probability attack will fail within x blocks](/img/posts/2023-10-cltv-expiry-delta-cycling.png) + + - **Skenování mempoolu:** design HTLC dává Mallory podnět, aby + nechala potvrdit transakci s předobrazem před tím, než může Bob + nárokovat refundaci. Pro Boba je to praktické: blockchain je široce + dostupný a jeho velikost omezena, Bob tedy může snadno najít + jakýkoliv předobraz, který se ho týká. Kdyby tento systém fungoval + podle záměru, Bob by mohl z blockchainu získat všechny informace potřebné + pro provoz LN. + + Bohužel, replacement cycling znamená, že Mallory již nemusí být + motivována k potvrzení své transakce před Bobovým nárokováním + refundace. Ale aby mohla Mallory zahájit replacement cycle, musí + krátce odhalit předobraz v rámci mempoolů těžařů, chce-li nahradit + Bobovu transakci. Pokud Bob provozuje přeposílající plný uzel, + Mallořina transakce s předobrazem může procházet i Bobovým uzlem. + Pokud by Bob včas detekoval předobraz, útok by odrazil a Mallory + by ztratila všechny peníze, které během pokusu o útok utratila. + + Skenování mempoolu není všemocné: neexistuje záruka, že Mallořina + nahrazující transakce proteče Bobovým uzlem. Avšak čím častěji + Bob opakovaně zveřejňuje svou transakci (viz _častá opakovaná zveřejňování_) + a čím déle musí Mallory před Bobem skrývat svůj předobraz (viz + _delší CLTV expiry delta_), tím pravděpodobnější je, že se jedna z + transakcí s předobrazem včas dostane do Bobova mempoolu. + + Eclair a LND v současnosti implementují skenování mempoolu u + přeposílajících uzlů. + + - **Diskuze o účinnosti opatření:** Riard v úvodním oznámení napsal: + „Věřím, že replacement cycling útoky jsou pro schopné útočníky nadále + praktické.” Matto Corallo [napsal][corallo cycle1], že „nasazená + opatření problém neodstraňují; lze argumentovat, že neposkytují víc + než pouhé PR vyjádření.” Olaoluwa Osuntokun [polemizoval][osuntokun + cycle1]: „[podle mého názoru] se jedná spíše o vratký druh útoku, + který vyžaduje určité aranžmá jednotlivých uzlů, extrémně přesné načasování + a provedení, nepotvrzující postavení všech transakcí a okamžitou + propagaci celou sítí.” + + My v Optechu si myslíme, že je důležité znovu zdůraznit, že tento útok + postihuje pouze přeposílající uzly. Přeposílající uzel je bitcoinová + horká peněženka neustále připojená k internetu. Jedná se o druh + nasazení, který je neustále jednu zranitelnost od ztráty všech prostředků. + Každý, kdo vyhodnocuje dopad replacement cyclingu na rizikovost provozu + přeposílajícího LN uzlu, by tak měl činit v rámci již existujícího rizika. + Pochopitelně je dobré hledat další způsoby snižování rizika. + Tím se zabývá náš další bod. - **Další navrhovaná opatření před replacement cycling útokem:** v době psaní zpravodaje se v emailových skupinách Bitcoin-Dev a Lightning-Dev objevilo přes 40 reakcí na odhalení útoku. Uvádíme některá navrhovaná opatření: - - **Navyšování poplatků až do úplného konce:** Riardův [článek][riard - cycle paper] o útoku a příspěvky v emailové skupině od [Ziggieho][ziggie - cycle] a [Matta Morehouse][morehouse cycle] navrhují, aby obránce - (např. Bob) namísto pouhého opakovaného zveřejňování své - refundace začal zveřejňovat konfliktní alternativní transakce, - které platí neustále se zvyšující jednotkové poplatky v souladu - s tím, jak se blíží lhůta vyrovnání s útočníkem ve směru proti - toku platby (např. MalloryA). - - Pravidla BIP125 vyžadují, aby útočník ve směru toku platby - (např. MalloryB) platil za každé své nahrazení Bobovy transakce - neustále se zvyšující poplatky, což by Bobovi umožnilo snížit - ziskovost Mallořina útoku, pokud by se zdařil. Uvažme náš hrubý vzorec - `x*y*z` z části o _opatření opakovanými zveřejněními_. Pokud by - pro některá opakovaná zveřejnění narostly náklady na _x_, vzrostly - by celkové náklady útoku a zvýšila by se maximální bezpečná hodnota HTLC. - - Riard ve svém článku vysvětluje, že náklady nemusí být symetrické, - obzvláště v době, kdy se průměrný jednotkový poplatek zvyšuje a - útočník je schopen vyhodit některé své transakce z mempoolů těžařů. - V emailové skupině dále [píše][riard cycle2], že útočník může útok - rozložit mezi více obětí pomocí určitého druhu [dávkových plateb][topic - payment batching], čímž by mírně navýšil účinnost. - - Matt Corallo [poznamenává][corallo cycle2] hlavní nevýhodu tohoto - přístupu v porovnání s prostým opakovaným zveřejněním: i kdyby Bob - útočníka porazil, ztratil by část (nebo i všechnu) hodnoty HTLC. - Teoreticky by útočník nebyl ochoten v útoku pokračovat, pokud - by věřil, že obránce bude následovat cestu vzájemné destrukce. - Bob by tedy ve skutečnosti nemusel vyšší a vyšší jednotkový - poplatek platit. Zda by tomu tak ve skutečnosti v bitcoinové síti - bylo, zůstává nezodpovězeno. - - - **Automatické opakované zkoušení minulých transakcí:** Corallo - [naznačil][corallo cycle1], že „jediná oprava tohoto problému bude, - když budou těžaři ukládat historii transakcí, které viděli, a budou - je zkoušet znova po […] podobném útoku.” Bastien Teinturier - [odpověděl][teinturier cycle]: „Souhlasím ale s Mattem, že bude - nejspíš potřeba nějaké principiálnější změny na bitcoinové vrstvě, - aby mohly L2 protokoly této třídě útoku lépe čelit.” Riard se též - [vyjádřil][riard cycle3] v podobném duchu: „Trvalá oprava se může - uskutečnit [jen] na základní vrstvě, například přidáním paměťově - náročné historie všech viděných transakcí.” - - - **Předem podepsaná navýšení poplatku:** Peter Todd [řekl][todd cycle1], - že „správným způsobem, jak předem podepisovat transakce, je předem - podepsat dostatek *různých* transakcí, které by pokryly všechny - rozumné potřeby navyšování poplatků. […] Neexistuje žádný důvod, - proč by se měly transakce B->C zaseknout.” (Zdůraznění v originále.) - - To by mohlo fungovat následujícím způsobem: pro HTLC mezi Bobem - a MalloryB poskytne Bob MalloryB deset různých podpisů stejné - transakce s předobrazem s různými jednotkovými poplatky. Všimněte - si, že v čase podepisování nemusí MalloryB Bobovi předobraz poskytnout. - Zároveň poskytne MalloryB Bobovi deset různých podpisů stejné - refundovací transakce s různými jednotkovými poplatky. Může tak být - učiněno před zveřejněním refundace. Jednotkové poplatky by - mohly být (sat/vbyte): 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, - což by v dohledné době mělo pokrýt všechny případy. - - Je-li Mallořina transakce s předobrazem předem podepsána, jediné nahrazení, - kterého by mohla dosáhnout, by bylo navýšení jednotkového poplatku. - Nebyla by schopna přidat nový vstup do transakce s předobrazem, a - tedy by nemohla útok zahájit. - - - **OP_EXPIRE:** v samostatném vlákně [navrhl][todd expire1] Peter Todd, - cituje vlákno o útoku, několik změn konsenzu k umožnění opkódu - `OP_EXPIRE`. Ten by učinil transakci nevalidní pro začlenění po určené - výšce, pokud by script spustil `OP_EXPIRE`. Díky tomu by mohla být - Mallořina podmínka s předobrazem v HTLC použitelná pouze před tím, než - by byla Bobova refundovací podmínka utratitelná. To by zabránilo - Mallory v nahrazení Bobovy refundovací transakce, a tím by nemohl - být útok zahájen. `OP_EXPIRE` by též mohlo pomoci v boji proti - některým [transaction pinning útokům][topic transaction pinning] proti - HTLC. - - Hlavní nevýhodou `OP_EXPIRE` je, že vyžaduje změny konsenzu a změny - pravidel přeposílání a mempoolu, aby se vyhnulo určitým problémům, - jako je možnost použít jej k plýtvání zdroji uzlu. - - [Jedna odpověď][harding expire] pod tímto příspěvkem navrhla slabší verzi, - která by dosáhla stejného cíle jako `OP_EXPIRE`, ale bez nutnosti - měnit konsenzus či pravidla přeposílání. Avšak Peter Todd - [odpověděl][todd expire2], že by replacement cycling útoku nezabránila. - - Očekáváme pokračování diskuzí o tomto tématu a v budoucích vydáních - zpravodaje přineseme popis vývoje. + - **Navyšování poplatků až do úplného konce:** Riardův [článek][riard + cycle paper] o útoku a příspěvky v emailové skupině od [Ziggieho][ziggie + cycle] a [Matta Morehouse][morehouse cycle] navrhují, aby obránce + (např. Bob) namísto pouhého opakovaného zveřejňování své + refundace začal zveřejňovat konfliktní alternativní transakce, + které platí neustále se zvyšující jednotkové poplatky v souladu + s tím, jak se blíží lhůta vyrovnání s útočníkem ve směru proti + toku platby (např. MalloryA). + + Pravidla BIP125 vyžadují, aby útočník ve směru toku platby + (např. MalloryB) platil za každé své nahrazení Bobovy transakce + neustále se zvyšující poplatky, což by Bobovi umožnilo snížit + ziskovost Mallořina útoku, pokud by se zdařil. Uvažme náš hrubý vzorec + `x*y*z` z části o _opatření opakovanými zveřejněními_. Pokud by + pro některá opakovaná zveřejnění narostly náklady na _x_, vzrostly + by celkové náklady útoku a zvýšila by se maximální bezpečná hodnota HTLC. + + Riard ve svém článku vysvětluje, že náklady nemusí být symetrické, + obzvláště v době, kdy se průměrný jednotkový poplatek zvyšuje a + útočník je schopen vyhodit některé své transakce z mempoolů těžařů. + V emailové skupině dále [píše][riard cycle2], že útočník může útok + rozložit mezi více obětí pomocí určitého druhu [dávkových plateb][topic + payment batching], čímž by mírně navýšil účinnost. + + Matt Corallo [poznamenává][corallo cycle2] hlavní nevýhodu tohoto + přístupu v porovnání s prostým opakovaným zveřejněním: i kdyby Bob + útočníka porazil, ztratil by část (nebo i všechnu) hodnoty HTLC. + Teoreticky by útočník nebyl ochoten v útoku pokračovat, pokud + by věřil, že obránce bude následovat cestu vzájemné destrukce. + Bob by tedy ve skutečnosti nemusel vyšší a vyšší jednotkový + poplatek platit. Zda by tomu tak ve skutečnosti v bitcoinové síti + bylo, zůstává nezodpovězeno. + + - **Automatické opakované zkoušení minulých transakcí:** Corallo + [naznačil][corallo cycle1], že „jediná oprava tohoto problému bude, + když budou těžaři ukládat historii transakcí, které viděli, a budou + je zkoušet znova po […] podobném útoku.” Bastien Teinturier + [odpověděl][teinturier cycle]: „Souhlasím ale s Mattem, že bude + nejspíš potřeba nějaké principiálnější změny na bitcoinové vrstvě, + aby mohly L2 protokoly této třídě útoku lépe čelit.” Riard se též + [vyjádřil][riard cycle3] v podobném duchu: „Trvalá oprava se může + uskutečnit [jen] na základní vrstvě, například přidáním paměťově + náročné historie všech viděných transakcí.” + + - **Předem podepsaná navýšení poplatku:** Peter Todd [řekl][todd cycle1], + že „správným způsobem, jak předem podepisovat transakce, je předem + podepsat dostatek *různých* transakcí, které by pokryly všechny + rozumné potřeby navyšování poplatků. […] Neexistuje žádný důvod, + proč by se měly transakce B->C zaseknout.” (Zdůraznění v originále.) + + To by mohlo fungovat následujícím způsobem: pro HTLC mezi Bobem + a MalloryB poskytne Bob MalloryB deset různých podpisů stejné + transakce s předobrazem s různými jednotkovými poplatky. Všimněte + si, že v čase podepisování nemusí MalloryB Bobovi předobraz poskytnout. + Zároveň poskytne MalloryB Bobovi deset různých podpisů stejné + refundovací transakce s různými jednotkovými poplatky. Může tak být + učiněno před zveřejněním refundace. Jednotkové poplatky by + mohly být (sat/vbyte): 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, + což by v dohledné době mělo pokrýt všechny případy. + + Je-li Mallořina transakce s předobrazem předem podepsána, jediné nahrazení, + kterého by mohla dosáhnout, by bylo navýšení jednotkového poplatku. + Nebyla by schopna přidat nový vstup do transakce s předobrazem, a + tedy by nemohla útok zahájit. + + - **OP_EXPIRE:** v samostatném vlákně [navrhl][todd expire1] Peter Todd, + cituje vlákno o útoku, několik změn konsenzu k umožnění opkódu + `OP_EXPIRE`. Ten by učinil transakci nevalidní pro začlenění po určené + výšce, pokud by script spustil `OP_EXPIRE`. Díky tomu by mohla být + Mallořina podmínka s předobrazem v HTLC použitelná pouze před tím, než + by byla Bobova refundovací podmínka utratitelná. To by zabránilo + Mallory v nahrazení Bobovy refundovací transakce, a tím by nemohl + být útok zahájen. `OP_EXPIRE` by též mohlo pomoci v boji proti + některým [transaction pinning útokům][topic transaction pinning] proti + HTLC. + + Hlavní nevýhodou `OP_EXPIRE` je, že vyžaduje změny konsenzu a změny + pravidel přeposílání a mempoolu, aby se vyhnulo určitým problémům, + jako je možnost použít jej k plýtvání zdroji uzlu. + + [Jedna odpověď][harding expire] pod tímto příspěvkem navrhla slabší verzi, + která by dosáhla stejného cíle jako `OP_EXPIRE`, ale bez nutnosti + měnit konsenzus či pravidla přeposílání. Avšak Peter Todd + [odpověděl][todd expire2], že by replacement cycling útoku nezabránila. + + Očekáváme pokračování diskuzí o tomto tématu a v budoucích vydáních + zpravodaje přineseme popis vývoje. - **Nahrazení výpočtu hashe množiny bitcoinových UTXO:** Fabian Jahr zaslal do emailové skupiny Bitcoin-Dev [příspěvek][jahr hash_serialized_2] @@ -331,28 +333,28 @@ Bitcoin Stack Exchange. [kovenantů][topic covenants]. Uvádíme některá z jeho zjištění, která pokládáme za významná: - - *Jednoduchost:* v jediném výstupním skriptu a jeho - [taprootovém][topic taproot] commitmentu by bylo možné plně provádět - introspekci pomocí tří nových opkódů a jednoho z dříve navrhovaných - kovenantových opkódů (např. [OP_TX][news187 op_tx]). Každý z nových - opkódů je snadno pochopitelný a jeví se jednoduše implementovatelný. - - - *Stručnost:* Russellovy příklady používají pro účely introspekce - kolem 30 vbytů (vynucovaný skript by byl nad rámec těchto vbytů). - - - *Změny v OP_SUCCESS by prospěly:* [BIP342][] specifikace [tapscriptu][topic - tapscript] definuje několik `OP_SUCCESSx` opkódů, které úspěšně ukončí - skript, jež je obsahuje. To umožňuje budoucím soft forkům přidělit těmto - opkódům nové podmínky (a učinit tak z nich běžné opkódy). Avšak kvůli tomuto - chování by bylo používání introspekce s kovenanty, jež mohou obsahovat části - libovolných skriptů, nebezpečné. Například by mohla Alice vytvořit - kovenant, který by jí umožnil utratit prostředky na libovolnou - adresu, pokud by tyto prostředky nejdříve utratila v oznamovací - transakci [úschovny][topic vaults] a čekala určitý počet bloků, - aby dala možnost zmrazovací transakci toto utracení blokovat. - Pokud by však ona libovolná adresa obsahovala opkód `OP_SUCCESSx`, - mohl by kdokoliv její peníze ukrást. Russell ve svém článku navrhuje dvě - možná řešení tohoto problému. + - *Jednoduchost:* v jediném výstupním skriptu a jeho + [taprootovém][topic taproot] commitmentu by bylo možné plně provádět + introspekci pomocí tří nových opkódů a jednoho z dříve navrhovaných + kovenantových opkódů (např. [OP_TX][news187 op_tx]). Každý z nových + opkódů je snadno pochopitelný a jeví se jednoduše implementovatelný. + + - *Stručnost:* Russellovy příklady používají pro účely introspekce + kolem 30 vbytů (vynucovaný skript by byl nad rámec těchto vbytů). + + - *Změny v OP_SUCCESS by prospěly:* [BIP342][] specifikace [tapscriptu][topic + tapscript] definuje několik `OP_SUCCESSx` opkódů, které úspěšně ukončí + skript, jež je obsahuje. To umožňuje budoucím soft forkům přidělit těmto + opkódům nové podmínky (a učinit tak z nich běžné opkódy). Avšak kvůli tomuto + chování by bylo používání introspekce s kovenanty, jež mohou obsahovat části + libovolných skriptů, nebezpečné. Například by mohla Alice vytvořit + kovenant, který by jí umožnil utratit prostředky na libovolnou + adresu, pokud by tyto prostředky nejdříve utratila v oznamovací + transakci [úschovny][topic vaults] a čekala určitý počet bloků, + aby dala možnost zmrazovací transakci toto utracení blokovat. + Pokud by však ona libovolná adresa obsahovala opkód `OP_SUCCESSx`, + mohl by kdokoliv její peníze ukrást. Russell ve svém článku navrhuje dvě + možná řešení tohoto problému. Výzkum obdržel několik reakcí a Russell naznačil, že pracuje na dalším příspěvku popisující introspekci výstupních částek. @@ -479,27 +481,27 @@ Budou obsaženy v příštím vydání. Za zpoždění se omlouváme._ {% include references.md %} {% include linkers/issues.md v=2 issues="27677" %} [news274 cycle]: /cs/newsletters/2023/10/18/#zverejneni-bezpecnostniho-problemu-postihujiciho-ln -[riard cycle1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/021999.html -[corallo cycle1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022015.html -[osuntokun cycle1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022044.html +[riard cycle1]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/021999.html +[corallo cycle1]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022015.html +[osuntokun cycle1]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022044.html [riard cycle paper]: https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper/replacement-cycling.pdf -[ziggie cycle]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022005.html -[morehouse cycle]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022024.html -[riard cycle2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022029.html -[corallo cycle2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022025.html -[teinturier cycle]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022022.html -[riard cycle3]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022032.html -[todd cycle1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022033.html -[todd expire1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022042.html -[harding expire]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022050.html -[todd expire2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022051.html -[hash_serialized_2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022038.html -[russell scripts]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022031.html +[ziggie cycle]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022005.html +[morehouse cycle]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022024.html +[riard cycle2]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022029.html +[corallo cycle2]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022025.html +[teinturier cycle]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022022.html +[riard cycle3]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022032.html +[todd cycle1]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022033.html +[todd expire1]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022042.html +[harding expire]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022050.html +[todd expire2]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022051.html +[hash_serialized_2]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022038.html +[russell scripts]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022031.html [russell scripts blog]: https://rusty.ozlabs.org/2023/10/20/examining-scriptpubkey-in-script.html [news187 op_tx]: /en/newsletters/2022/02/16/#simplified-alternative-to-op-txhash -[heilman cat]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022049.html +[heilman cat]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022049.html [op_cat bip]: https://github.com/EthanHeilman/op_cat_draft/blob/main/cat.mediawiki -[jahr hash_serialized_2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022038.html +[jahr hash_serialized_2]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022038.html [Bitcoin Core 25.1]: https://bitcoincore.org/bin/bitcoin-core-25.1/ [Bitcoin Core 24.2]: https://bitcoincore.org/bin/bitcoin-core-24.2/ [Bitcoin Core 26.0rc1]: https://bitcoincore.org/bin/bitcoin-core-26.0/ diff --git a/_posts/cs/newsletters/2023-11-01-newsletter.md b/_posts/cs/newsletters/2023-11-01-newsletter.md index fa62cc6517..11e4cd51cd 100644 --- a/_posts/cs/newsletters/2023-11-01-newsletter.md +++ b/_posts/cs/newsletters/2023-11-01-newsletter.md @@ -17,51 +17,51 @@ páteřním software. - **Diskuze o změnách ve skriptu pokračují:** do diskuzí v emailové skupině Bitcoin-Dev, kterým jsme se věnovali dříve, přibylo několik nových reakcí. - - *Výzkum kovenantů:* Anthony Towns zaslal [odpověď][towns cov] - na [příspěvek][russell cov] od Rustyho Russella, který jsme [zmínili][news274 - cov] v minulém čísle. Towns porovnává Russellův přístup s jinými přístupy – zaměřenými - zvláště na [úschovny][topic vaults] založené na [kovenantech][topic covenants] - – a považuje ho za neatraktivní. V následující [odpovědi][russell cov2] Russell - poznamenává, že pro úschovny existují různé návrhy a že jsou úschovny - v porovnání s jinými druhy transakcí neoptimální. Dále vyvozuje, že - optimalizace není pro uživatele úschoven kritická. Tvrdí, že návrh úschoven - dle [BIP345][] je vhodnější jako formát adres spíše než soubor opkódů. - Podle našeho soudu tento výrok znamená, že BIP345 dává větší smysl jako - šablona (podobně jako P2WPKH) navržená pro jednu funkci než jako soubor - opkódů, který je navržen pro tu jednu funkci, ale který má možnost - spolupracovat se zbytkem skriptu potenciálně nepředpokládanými způsoby. - - Towns rovněž uvažuje nad použitím Russellova přístupu jako způsobu, - jak obecně umožnit experimentování, a myslí si, že je „sice zajímavější - […], ale pořád dost kulhá.” Připomíná čtenářům svůj předešlý návrh - na alternativu bitcoinového Scriptu ve stylu Lispu (viz [zpravodaj č. - 191][news191 lisp], _angl._) a ukazuje, jak by mohl přinést větší - flexibilitu a možnosti v provádění introspekce transakcí během - vyhodnocování witnessů. Poskytuje odkazy na svůj testovací kód a - ukazuje na příklady, které napsal. Russell odpověděl: „Stále - věřím, že než ho budeme muset nahradit, existuje prostor pro zlepšení. - Je těžké porovnávat belhající se [S]cript v dnešní podobě s - alternativami, protože ty nejzajímavější případy jsou nemožné.“ - - Towns a Russel též v krátkosti hovořili o [OP_CHECKSIGFROMSTACK][topic - op_checksigfromstack], jmenovitě o jeho schopnosti umístit autentizovaná - data od orákulí přímo do zásobníku. - - - *Návrh na OP_CAT:* několik lidí odpovědělo na [příspěvek][heilman cat] - od Ethana Heilmana oznamující návrh BIPu na [OP_CAT][], který jsme - minulý týden rovněž [zmínili][news274 cat]. - - Po několika reakcích zmiňujících otázku, zda by nebyl `OP_CAT` - příliš omezovaný 520bytovým limitem na velikost prvků v zásobníku, - [popsal][todd 520] Peter Todd způsob, kterým lze budoucím soft forkem - navýšit limit bez použití dodatečných `OP_SUCCESSx` opkódů. Nevýhodou - je, že všechna použití `OP_CAT` by před navýšením vyžadovala přidání - několika již dostupných opkódů do skriptu navíc. - - Ještě před odpovědí Anthonyho Townse na Russellův výzkum kovenantů - zaslal James O'Beirne [příspěvek][o'beirne vault], ve kterém zmiňuje - důležitá omezení `OP_CAT` pro použití v úschovnách. Konkrétně jmenuje - několik vlastností, které `OP_CAT`, na rozdíl od BIP345 úschoven, postrádá. + - *Výzkum kovenantů:* Anthony Towns zaslal [odpověď][towns cov] + na [příspěvek][russell cov] od Rustyho Russella, který jsme [zmínili][news274 + cov] v minulém čísle. Towns porovnává Russellův přístup s jinými přístupy – zaměřenými + zvláště na [úschovny][topic vaults] založené na [kovenantech][topic covenants] + – a považuje ho za neatraktivní. V následující [odpovědi][russell cov2] Russell + poznamenává, že pro úschovny existují různé návrhy a že jsou úschovny + v porovnání s jinými druhy transakcí neoptimální. Dále vyvozuje, že + optimalizace není pro uživatele úschoven kritická. Tvrdí, že návrh úschoven + dle [BIP345][] je vhodnější jako formát adres spíše než soubor opkódů. + Podle našeho soudu tento výrok znamená, že BIP345 dává větší smysl jako + šablona (podobně jako P2WPKH) navržená pro jednu funkci než jako soubor + opkódů, který je navržen pro tu jednu funkci, ale který má možnost + spolupracovat se zbytkem skriptu potenciálně nepředpokládanými způsoby. + + Towns rovněž uvažuje nad použitím Russellova přístupu jako způsobu, + jak obecně umožnit experimentování, a myslí si, že je „sice zajímavější + […], ale pořád dost kulhá.” Připomíná čtenářům svůj předešlý návrh + na alternativu bitcoinového Scriptu ve stylu Lispu (viz [zpravodaj č. + 191][news191 lisp], _angl._) a ukazuje, jak by mohl přinést větší + flexibilitu a možnosti v provádění introspekce transakcí během + vyhodnocování witnessů. Poskytuje odkazy na svůj testovací kód a + ukazuje na příklady, které napsal. Russell odpověděl: „Stále + věřím, že než ho budeme muset nahradit, existuje prostor pro zlepšení. + Je těžké porovnávat belhající se [S]cript v dnešní podobě s + alternativami, protože ty nejzajímavější případy jsou nemožné.“ + + Towns a Russel též v krátkosti hovořili o [OP_CHECKSIGFROMSTACK][topic + op_checksigfromstack], jmenovitě o jeho schopnosti umístit autentizovaná + data od orákulí přímo do zásobníku. + + - *Návrh na OP_CAT:* několik lidí odpovědělo na [příspěvek][heilman cat] + od Ethana Heilmana oznamující návrh BIPu na [OP_CAT][], který jsme + minulý týden rovněž [zmínili][news274 cat]. + + Po několika reakcích zmiňujících otázku, zda by nebyl `OP_CAT` + příliš omezovaný 520bytovým limitem na velikost prvků v zásobníku, + [popsal][todd 520] Peter Todd způsob, kterým lze budoucím soft forkem + navýšit limit bez použití dodatečných `OP_SUCCESSx` opkódů. Nevýhodou + je, že všechna použití `OP_CAT` by před navýšením vyžadovala přidání + několika již dostupných opkódů do skriptu navíc. + + Ještě před odpovědí Anthonyho Townse na Russellův výzkum kovenantů + zaslal James O'Beirne [příspěvek][o'beirne vault], ve kterém zmiňuje + důležitá omezení `OP_CAT` pro použití v úschovnách. Konkrétně jmenuje + několik vlastností, které `OP_CAT`, na rozdíl od BIP345 úschoven, postrádá. ## Vydání nových verzí @@ -138,15 +138,15 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a {% include references.md %} {% include linkers/issues.md v=2 issues="28685,28651,28565,7828,2660,1086,27511" %} [news164 pong]: /en/newsletters/2021/09/01/#lnd-5621 -[towns cov]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022099.html -[russell cov]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022031.html +[towns cov]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022099.html +[russell cov]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022031.html [news274 cov]: /cs/newsletters/2023/10/25/#vyzkum-obecnych-kovenantu-s-minimalnimi-zmenami-scriptu -[russell cov2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022103.html +[russell cov2]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022103.html [news191 lisp]: /en/newsletters/2022/03/16/#using-chia-lisp -[heilman cat]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022049.html +[heilman cat]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022049.html [news274 cat]: /cs/newsletters/2023/10/25/#navrh-bipu-pro-op-cat -[todd 520]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022094.html -[o'beirne vault]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022092.html +[todd 520]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022094.html +[o'beirne vault]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022092.html [Bitcoin Core 26.0rc1]: https://bitcoincore.org/bin/bitcoin-core-26.0/ [bitcoin core developer wiki]: https://github.com/bitcoin-core/bitcoin-devwiki/wiki [bitcoin core pr review club]: https://bitcoincore.reviews/#upcoming-meetings diff --git a/_posts/cs/newsletters/2023-11-08-newsletter.md b/_posts/cs/newsletters/2023-11-08-newsletter.md index 28f93d675f..bfdb5dad88 100644 --- a/_posts/cs/newsletters/2023-11-08-newsletter.md +++ b/_posts/cs/newsletters/2023-11-08-newsletter.md @@ -192,10 +192,10 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a [bitcoin core 26.0rc2]: https://bitcoincore.org/bin/bitcoin-core-26.0/ [core lightning 23.11rc1]: https://github.com/ElementsProject/lightning/releases/tag/v23.11rc1 [lnd 0.17.1-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.17.1-beta.rc1 -[sources]: /internal/sources/ -[bishop lists]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-November/022134.html +[sources]: /en/internal/sources/ +[bishop lists]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-November/022134.html [delvingbitcoin]: https://delvingbitcoin.org/ -[halseth agg]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-October/004181.html +[halseth agg]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-October/004181.html [36c04c8ac]: https://github.com/lightning/bolts/pull/851/commits/36c04c8aca48e04d1fba64d968054eba221e63a1 [news253 stuck]: /cs/newsletters/2023/05/31/#eclair-2666 [bitcoin core pr review club]: https://bitcoincore.reviews/#upcoming-meetings diff --git a/_posts/cs/newsletters/2023-11-22-newsletter.md b/_posts/cs/newsletters/2023-11-22-newsletter.md index 602f2b2d63..0bc3c76092 100644 --- a/_posts/cs/newsletters/2023-11-22-newsletter.md +++ b/_posts/cs/newsletters/2023-11-22-newsletter.md @@ -24,41 +24,41 @@ software. adresy na LN faktury. Teinturier poznamenává, že tento způsob přináší několik problémů: - - _Ztráta soukromí_: provozovatel serveru nejspíše zná IP - adresy plátce i příjemce. + - _Ztráta soukromí_: provozovatel serveru nejspíše zná IP + adresy plátce i příjemce. - - _Hrozba krádeže:_ provozovatel serveru může pomocí man-in-the-middle - útoku ukrást prostředky. + - _Hrozba krádeže:_ provozovatel serveru může pomocí man-in-the-middle + útoku ukrást prostředky. - - _Infrastruktura a závislosti:_ provozovatel serveru musí nastavit - DNS a HTTPS hosting a platící software musí být schopen používat - DNS a HTTPS. + - _Infrastruktura a závislosti:_ provozovatel serveru musí nastavit + DNS a HTTPS hosting a platící software musí být schopen používat + DNS a HTTPS. Teinturier nabízí tři návrhy založené na nabídkách: - - _Svázání domény a uzlu:_ DNS záznam převádí doménu (např. example.com) - na identifikátor LN uzlu. Plátce pošle tomuto uzlu [onion zprávu][topic - onion messages] s žádostí o nabídku konečnému příjemci (např. - alice@example.com). Uzel domény vrátí nabídku podepsanou svým klíčem, - což by plátci pomohlo usvědčit uzel o podvodu, pokud by poskytnutá - nabídka nebyla od Alice. Plátce by nato mohl použít protokol nabídek - k získání faktury od Alice. Plátce dále může svázat adresu alice@example.com - s touto nabídkou, nebude tedy muset před budoucími platbami Alici uzel - znovu kontaktovat. Dle Teinturiera je tento návrh velice jednoduchý. - - - _Certifikáty v oznámeních o uzlu:_ stávající mechanismus, jehož LN uzly - využívají, aby se celé síti oznámily, může být upraven, aby umožnil - začlenění řetězce SSL certifikátů. Ten by prokázal (dle certifikační - autority) tvrzení vlastníka example.com, že je ovládán adresou - alice@example.com. Teinturier poznamenává, že by si to vyžádalo, aby - LN software implementoval kryptografii kompatibilní s SSL. - - - _Ukládání nabídek přímo v DNS:_ doména může mít několik DNS záznamů, - které by přímo obsahovaly nabídky pro určité adresy. Například `TXT` - záznam pro `alice._lnaddress.domain.com` obsahuje nabídku pro Alici. - Jiný záznam `bob._lnaddress.domain.com` obsahuje nabídku pro Boba. - Teinturier poznamenává nutnost vytvořit DNS záznam pro každého - uživatele (a aktualizovat tento záznam při každé změně nabídky). + - _Svázání domény a uzlu:_ DNS záznam převádí doménu (např. example.com) + na identifikátor LN uzlu. Plátce pošle tomuto uzlu [onion zprávu][topic + onion messages] s žádostí o nabídku konečnému příjemci (např. + alice@example.com). Uzel domény vrátí nabídku podepsanou svým klíčem, + což by plátci pomohlo usvědčit uzel o podvodu, pokud by poskytnutá + nabídka nebyla od Alice. Plátce by nato mohl použít protokol nabídek + k získání faktury od Alice. Plátce dále může svázat adresu alice@example.com + s touto nabídkou, nebude tedy muset před budoucími platbami Alici uzel + znovu kontaktovat. Dle Teinturiera je tento návrh velice jednoduchý. + + - _Certifikáty v oznámeních o uzlu:_ stávající mechanismus, jehož LN uzly + využívají, aby se celé síti oznámily, může být upraven, aby umožnil + začlenění řetězce SSL certifikátů. Ten by prokázal (dle certifikační + autority) tvrzení vlastníka example.com, že je ovládán adresou + alice@example.com. Teinturier poznamenává, že by si to vyžádalo, aby + LN software implementoval kryptografii kompatibilní s SSL. + + - _Ukládání nabídek přímo v DNS:_ doména může mít několik DNS záznamů, + které by přímo obsahovaly nabídky pro určité adresy. Například `TXT` + záznam pro `alice._lnaddress.domain.com` obsahuje nabídku pro Alici. + Jiný záznam `bob._lnaddress.domain.com` obsahuje nabídku pro Boba. + Teinturier poznamenává nutnost vytvořit DNS záznam pro každého + uživatele (a aktualizovat tento záznam při každé změně nabídky). Příspěvek vzbudil živou diskuzi. Jedna reakce navrhla použití první a třetí možnosti najednou (svázání uzlu a domény a ukládání nabídek @@ -153,7 +153,7 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a [26.0 testing]: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/26.0-Release-Candidate-Testing-Guide [core lightning 23.11rc3]: https://github.com/ElementsProject/lightning/releases/tag/v23.11rc3 [c-lightning-rest]: https://github.com/Ride-The-Lightning/c-lightning-REST -[teinturier addy]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-November/004204.html +[teinturier addy]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-November/004204.html [lnurl]: https://github.com/fiatjaf/lnurl-rfc [lightning address]: https://lightningaddress.com/ [lnd v0.17.2-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.17.2-beta diff --git a/_posts/cs/newsletters/2023-11-29-newsletter.md b/_posts/cs/newsletters/2023-11-29-newsletter.md index 32422d7083..d082e0c412 100644 --- a/_posts/cs/newsletters/2023-11-29-newsletter.md +++ b/_posts/cs/newsletters/2023-11-29-newsletter.md @@ -127,7 +127,7 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a [bitcoin core 26.0rc3]: https://bitcoincore.org/bin/bitcoin-core-26.0/ [26.0 testing]: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/26.0-Release-Candidate-Testing-Guide [core lightning 23.11]: https://github.com/ElementsProject/lightning/releases/tag/v23.11 -[neigut liqad]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-November/004217.html +[neigut liqad]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-November/004217.html [policy series]: /cs/blog/waiting-for-confirmation/ [p2c paper]: https://arxiv.org/abs/1212.3257 [bcc 0.11.1]: https://bitcoin.org/en/release/v0.11.1#test-for-lows-signatures-before-relaying diff --git a/_posts/cs/newsletters/2023-12-06-newsletter.md b/_posts/cs/newsletters/2023-12-06-newsletter.md index f8b55ea7dc..710d776eff 100644 --- a/_posts/cs/newsletters/2023-12-06-newsletter.md +++ b/_posts/cs/newsletters/2023-12-06-newsletter.md @@ -41,73 +41,73 @@ bitcoinovém páteřním software. Archiv pracovní skupiny je nyní přístupný všem, avšak pouze pozvaní členové mohou přispívat. Vybíráme některá zajímavá diskutovaná témata: - - [Definice a teorie cluster mempoolu][clusterdef] přináší definice - termínů použitých v návrhu cluster mempoolu. Též přináší několik - vět, které demonstrují užitečné vlastnosti tohoto návrhu. Tento jediný - příspěvek vlákna (v době psaní zpravodaje) je užitečný k porozumění - dalších debat pracovní skupiny, ačkoliv jeho autor (Pieter Wuille) - [varuje][wuille incomplete], že je stále „velice neúplný.” - - - [Sloučení neporovnatelných linearizací][cluster merge] zkoumá, jak sloučit - dvě odlišené sady chunků (chunkování, „chunkings”) shodných množin transakcí, - které jsou _neporovnatelné_. Porovnáním dvou odlišných sad chunků (chunkování) - bychom mohli určit, která z nich by byla pro těžaře výhodnější. Chunkování - by mohla být porovnána, pokud by jedno z nich vždy akumulovalo shodnou - nebo vyšší výši poplatků v rámci libovolné hodnoty vbyte (diskrétní - podle velikost chunku). Například: - - ![Comparable chunkings](/img/posts/2023-12-comparable-chunkings.png) - - Naopak neporovnatelná by byla, pokud by jedno z nich akumulovalo - větší výši poplatků v rámci určitého rozmezí vbyte, a to druhé - větší výši poplatků v jiném rozmezí, například: - - ![Incomparable chunkings](/img/posts/2023-12-incomparable-chunkings.png) - - Jak poznamenává jedna z vět zmíněná v předchozím příspěvku, „existují-li - dvě neporovnatelná chunkování, potom musí existovat třetí, které je - lepší než obě.” To znamená, že efektivní způsob, jakým sloučit dvě - odlišná, neporovnatelná chunkování může být mocným nástrojem pro zvýšení - těžařovy profitability. Příklad: je přijata nový transakce, která - souvisí s jinou transakcí z mempoolu. Její cluster musí být aktualizován, - a tedy i její chunkování musí být upraveno. Mohou být provedeny dva různé - způsoby této úpravy: - - 1. Je spočítáno nové chunkování pro aktualizovaný cluster. Pro velké clustery - může být nalezení optimálního chunkování výpočetně nepraktické, nové - chunkování tedy může být méně optimální než staré. - - 2. Předchozí chunkování z předchozího clusteru je aktualizováno - vložením nové transakce na místo, které je validní (předci - před potomky). Výhodou je, že jakékoliv stávající optimalizace - zůstávají nedotčené, na druhou stranu by transakce mohla být - umístěna v neoptimálním místě. - - Když jsou obě metody vykonány, můžeme porovnáním zjistit, že výsledek - jedné je lepší, může tedy být použit. Avšak jsou-li obě aktualizace - neporovnatelné, lze použít metodu, která zaručuje ekvivalentní nebo - lepší výsledek sloučení, k vytvoření třetího chunkování, které obsáhne - nejlepší součásti obou přístupů: použitím nových chunkování, pokud jsou - lepší, nebo zachování předchozích, pokud ta se blíží optimu. - - - [RBF balíčku v době clusterů][cluster rbf] se zabývá alternativami - k pravidlům používaným v současnosti pro [nahrazování poplatkem][topic - rbf]. Obdrží-li uzel validní nahrazení jedné nebo více transakcí, - může být vytvořena dočasná verze všech dotčených clusterů a odvozeno - jejich nové chunkování. To potom může být porovnáno s chunkováním - původních clusterů v mempoolu (bez nahrazení). Pokud chunkování - s nahrazením přináší vždy stejně nebo více na poplatcích než originální - pro jakýkoliv počet vbyte, a pokud navyšuje celkovou hodnotu poplatků - v mempoolu natolik, aby zaplatilo za své poplatky, potom může být - začleněno do mempoolu. - - Toto vyhodnocování založené na důkazech by mohlo nahradit několik - [heuristik][mempool replacements], které jsou v současnosti v Bitcoin - Core používány k určení, zda má být transakce nahrazena. To by mohlo - v několika oblastech zlepšit pravidla RBF, včetně navrhovaného - [přeposílání balíčků][topic package relay] pro nahrazování. - Několik [dalších][cluster rbf-old1] vláken [se též][cluster rbf-old2] - zabývalo [tímto][cluster rbf-old3] tématem. + - [Definice a teorie cluster mempoolu][clusterdef] přináší definice + termínů použitých v návrhu cluster mempoolu. Též přináší několik + vět, které demonstrují užitečné vlastnosti tohoto návrhu. Tento jediný + příspěvek vlákna (v době psaní zpravodaje) je užitečný k porozumění + dalších debat pracovní skupiny, ačkoliv jeho autor (Pieter Wuille) + [varuje][wuille incomplete], že je stále „velice neúplný.” + + - [Sloučení neporovnatelných linearizací][cluster merge] zkoumá, jak sloučit + dvě odlišené sady chunků (chunkování, „chunkings”) shodných množin transakcí, + které jsou _neporovnatelné_. Porovnáním dvou odlišných sad chunků (chunkování) + bychom mohli určit, která z nich by byla pro těžaře výhodnější. Chunkování + by mohla být porovnána, pokud by jedno z nich vždy akumulovalo shodnou + nebo vyšší výši poplatků v rámci libovolné hodnoty vbyte (diskrétní + podle velikost chunku). Například: + + ![Comparable chunkings](/img/posts/2023-12-comparable-chunkings.png) + + Naopak neporovnatelná by byla, pokud by jedno z nich akumulovalo + větší výši poplatků v rámci určitého rozmezí vbyte, a to druhé + větší výši poplatků v jiném rozmezí, například: + + ![Incomparable chunkings](/img/posts/2023-12-incomparable-chunkings.png) + + Jak poznamenává jedna z vět zmíněná v předchozím příspěvku, „existují-li + dvě neporovnatelná chunkování, potom musí existovat třetí, které je + lepší než obě.” To znamená, že efektivní způsob, jakým sloučit dvě + odlišná, neporovnatelná chunkování může být mocným nástrojem pro zvýšení + těžařovy profitability. Příklad: je přijata nový transakce, která + souvisí s jinou transakcí z mempoolu. Její cluster musí být aktualizován, + a tedy i její chunkování musí být upraveno. Mohou být provedeny dva různé + způsoby této úpravy: + + 1. Je spočítáno nové chunkování pro aktualizovaný cluster. Pro velké clustery + může být nalezení optimálního chunkování výpočetně nepraktické, nové + chunkování tedy může být méně optimální než staré. + + 2. Předchozí chunkování z předchozího clusteru je aktualizováno + vložením nové transakce na místo, které je validní (předci + před potomky). Výhodou je, že jakékoliv stávající optimalizace + zůstávají nedotčené, na druhou stranu by transakce mohla být + umístěna v neoptimálním místě. + + Když jsou obě metody vykonány, můžeme porovnáním zjistit, že výsledek + jedné je lepší, může tedy být použit. Avšak jsou-li obě aktualizace + neporovnatelné, lze použít metodu, která zaručuje ekvivalentní nebo + lepší výsledek sloučení, k vytvoření třetího chunkování, které obsáhne + nejlepší součásti obou přístupů: použitím nových chunkování, pokud jsou + lepší, nebo zachování předchozích, pokud ta se blíží optimu. + + - [RBF balíčku v době clusterů][cluster rbf] se zabývá alternativami + k pravidlům používaným v současnosti pro [nahrazování poplatkem][topic + rbf]. Obdrží-li uzel validní nahrazení jedné nebo více transakcí, + může být vytvořena dočasná verze všech dotčených clusterů a odvozeno + jejich nové chunkování. To potom může být porovnáno s chunkováním + původních clusterů v mempoolu (bez nahrazení). Pokud chunkování + s nahrazením přináší vždy stejně nebo více na poplatcích než originální + pro jakýkoliv počet vbyte, a pokud navyšuje celkovou hodnotu poplatků + v mempoolu natolik, aby zaplatilo za své poplatky, potom může být + začleněno do mempoolu. + + Toto vyhodnocování založené na důkazech by mohlo nahradit několik + [heuristik][mempool replacements], které jsou v současnosti v Bitcoin + Core používány k určení, zda má být transakce nahrazena. To by mohlo + v několika oblastech zlepšit pravidla RBF, včetně navrhovaného + [přeposílání balíčků][topic package relay] pro nahrazování. + Několik [dalších][cluster rbf-old1] vláken [se též][cluster rbf-old2] + zabývalo [tímto][cluster rbf-old3] tématem. - **Testování s warnetem:** Matthew Zipkin zaslal do Delving Bitcoin [příspěvek][zipkin warnet] s výsledky simulací, které provádí pomocí diff --git a/_posts/cs/newsletters/2023-12-13-newsletter.md b/_posts/cs/newsletters/2023-12-13-newsletter.md index 29ba2eb345..13f02e46a8 100644 --- a/_posts/cs/newsletters/2023-12-13-newsletter.md +++ b/_posts/cs/newsletters/2023-12-13-newsletter.md @@ -174,7 +174,7 @@ vydáme náš šestý roční přehled. Pravidelné vydávání zpravodaje bude {% include references.md %} {% include linkers/issues.md v=2 issues="2685,5389,5490,1446,27995" %} [LND 0.17.3-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.17.3-beta -[teinturier liqad]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-December/004227.html +[teinturier liqad]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-December/004227.html [ms fee api]: https://mempool.space/docs/api/rest#get-recommended-fees [mempool.space]: https://mempool.space/ [news136 bip129]: /en/newsletters/2021/02/17/#securely-setting-up-multisig-wallets diff --git a/_posts/cs/newsletters/2024-01-03-newsletter.md b/_posts/cs/newsletters/2024-01-03-newsletter.md index bbe9179f91..f0253f9c55 100644 --- a/_posts/cs/newsletters/2024-01-03-newsletter.md +++ b/_posts/cs/newsletters/2024-01-03-newsletter.md @@ -29,14 +29,14 @@ páteřních projektech. známým zranitelnostem okamžitou aktualizaci. Následuje stručný popis těchto zranitelností: - - DoS zranitelnost, která mohla vést k zahlcení paměti a pádu a následné - nemožnosti zveřejnit časově citlivé transakce, což mohlo vést ke - ztrátě prostředků. + - DoS zranitelnost, která mohla vést k zahlcení paměti a pádu a následné + nemožnosti zveřejnit časově citlivé transakce, což mohlo vést ke + ztrátě prostředků. - - Zranitelnost, která umožňovala útočníkovi zabránit LND uzlu, - aby se dozvěděl o aktualizacích kanálů napříč sítí. Útočník tím mohl - ovlivnit výběr tras a obdržet tak více peněz na poplatcích i více - informací o odesílaných platbách. + - Zranitelnost, která umožňovala útočníkovi zabránit LND uzlu, + aby se dozvěděl o aktualizacích kanálů napříč sítí. Útočník tím mohl + ovlivnit výběr tras a obdržet tak více peněz na poplatcích i více + informací o odesílaných platbách. Gögge zranitelnosti nahlásil vývojářům před více než dvěma lety a opravné verze jsou dostupné již více než 18 měsíců. Nejsme si vědomi žádných @@ -345,20 +345,20 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a {% include references.md %} {% include linkers/issues.md v=2 issues="28349,6957,6869,2796,2787,2781,2723,1504,2688" %} [gogge lndvuln]: https://delvingbitcoin.org/t/denial-of-service-bugs-in-lnds-channel-update-gossip-handling/314/1 -[law fdt]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-December/004254.html +[law fdt]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-December/004254.html [original lightning network paper]: https://lightning.network/lightning-network-paper.pdf -[riard fdt]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-December/004256.html -[boris fdt]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-December/004256.html -[harding pruned]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-December/004256.html -[evo fdt]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-December/004260.html +[riard fdt]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-December/004256.html +[boris fdt]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-December/004256.html +[harding pruned]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-December/004256.html +[evo fdt]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-December/004260.html [ismail cluster]: https://delvingbitcoin.org/t/package-aware-fee-estimator-post-cluster-mempool/312/1 [ingala undesc]: https://delvingbitcoin.org/t/unspendable-keys-in-descriptors/304/1 [wuille undesc]: https://delvingbitcoin.org/t/unspendable-keys-in-descriptors/304/2 [wuille undesc2]: https://gist.github.com/sipa/06c5c844df155d4e5044c2c8cac9c05e#unspendable-keys -[todd v3]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022211.html -[seedhammer descpsbt]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022200.html -[seedhammer descpsbt2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-November/022184.html -[black descpsbt]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-November/022186.html +[todd v3]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022211.html +[seedhammer descpsbt]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022200.html +[seedhammer descpsbt2]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-November/022184.html +[black descpsbt]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-November/022186.html [halseth ccv]: https://delvingbitcoin.org/t/verification-of-risc-v-execution-using-op-ccv/313 [elftrace]: https://github.com/halseth/elftrace [matt]: /en/newsletters/2022/11/16/#general-smart-contracts-in-bitcoin-via-covenants diff --git a/_posts/cs/newsletters/2024-01-10-newsletter.md b/_posts/cs/newsletters/2024-01-10-newsletter.md index d6201015c4..56d4c3668e 100644 --- a/_posts/cs/newsletters/2024-01-10-newsletter.md +++ b/_posts/cs/newsletters/2024-01-10-newsletter.md @@ -168,33 +168,33 @@ bitcoinovém páteřním software. změnou protokolu jako [SIGHASH_ANYPREVOUT][topic sighash_anyprevout]. Sanders nabízí několik postřehů: - - *Jednoduchost:* LN-Symmetry je mnohem jednodušším protokolem než současný - protokol LN-Penalty/[LN-Anchors][topic anchor outputs]. - - - *Pinning:* „[Pinningu][topic transaction pinning] je hrozně těžké se - vyhnout.“ Sandersova práce v této oblasti mu dala vhled a inspiraci, - která vedla v jeho příspěvky do [přeposílání balíčků][topic package relay] - a jeho široce uznávaný návrh na [dočasné anchory][topic ephemeral anchors]. - - - *CTV:* „[CTV][topic op_checktemplateverify] (emulované) - […] umožňuje ‚rychlá přeposílání’, která jsou jednoduchá a pravděpodobně by - v případě širokého používání redukovala časy plateb.” - - - *Tresty:* Tresty se skutečně zdají nepotřebné, jak vývojáři doufali. Avšak - někteří lidé mysleli, že by tresty i nadále byly nutné pro odrazování - zlomyslných protistran od pokusů o krádež. Podpora pro tresty by výrazně - zvýšila složitost protokolu a vyžadovala by rezervování části prostředků - na placení pokut. Bylo by tedy lepší se podpory trestů vyvarovat, pokud by - nebyly nezbytně nutné pro bezpečnost. - - - *Expiry delta:* LN-Symmetry vyžaduje delší CLTV expiry delta, než bylo - očekáváno. Když Alice přepošle HTLC Bobovi, dá mu určitý počet bloků - na nárokování svých prostředků pomocí předobrazu. Po vypršení doby - si může prostředky vzít zpět. Pokud Bob HTLC dále přepošle Carol, - dá on jí nižší počet bloků na odhalení předobrazu. Rozdíl mezi těmito - dvěma hodnotami je _CLTV expiry delta_. Sanders zjistil, že tyto rozdíly - musí být dostatečně dlouhé, aby zabránily protistraně v obohacení, - pokud by protokol v půlce přerušila. + - *Jednoduchost:* LN-Symmetry je mnohem jednodušším protokolem než současný + protokol LN-Penalty/[LN-Anchors][topic anchor outputs]. + + - *Pinning:* „[Pinningu][topic transaction pinning] je hrozně těžké se + vyhnout.“ Sandersova práce v této oblasti mu dala vhled a inspiraci, + která vedla v jeho příspěvky do [přeposílání balíčků][topic package relay] + a jeho široce uznávaný návrh na [dočasné anchory][topic ephemeral anchors]. + + - *CTV:* „[CTV][topic op_checktemplateverify] (emulované) + […] umožňuje ‚rychlá přeposílání’, která jsou jednoduchá a pravděpodobně by + v případě širokého používání redukovala časy plateb.” + + - *Tresty:* Tresty se skutečně zdají nepotřebné, jak vývojáři doufali. Avšak + někteří lidé mysleli, že by tresty i nadále byly nutné pro odrazování + zlomyslných protistran od pokusů o krádež. Podpora pro tresty by výrazně + zvýšila složitost protokolu a vyžadovala by rezervování části prostředků + na placení pokut. Bylo by tedy lepší se podpory trestů vyvarovat, pokud by + nebyly nezbytně nutné pro bezpečnost. + + - *Expiry delta:* LN-Symmetry vyžaduje delší CLTV expiry delta, než bylo + očekáváno. Když Alice přepošle HTLC Bobovi, dá mu určitý počet bloků + na nárokování svých prostředků pomocí předobrazu. Po vypršení doby + si může prostředky vzít zpět. Pokud Bob HTLC dále přepošle Carol, + dá on jí nižší počet bloků na odhalení předobrazu. Rozdíl mezi těmito + dvěma hodnotami je _CLTV expiry delta_. Sanders zjistil, že tyto rozdíly + musí být dostatečně dlouhé, aby zabránily protistraně v obohacení, + pokud by protokol v půlce přerušila. Sanders v současnosti pracuje na vylepšení mempoolu Bitcoin Core a pravidel přeposílání, která v budoucnosti usnadní nasazení LN-Symmetry i jiných protokolů. diff --git a/_posts/cs/newsletters/2024-01-17-newsletter.md b/_posts/cs/newsletters/2024-01-17-newsletter.md index 3d4478953f..00531b18df 100644 --- a/_posts/cs/newsletters/2024-01-17-newsletter.md +++ b/_posts/cs/newsletters/2024-01-17-newsletter.md @@ -85,32 +85,32 @@ páteřním software. architektů návrhu. Jedna drobnost, kterou jsme před tím nepopsali, upoutala naši pozornost: - - *CPFP carve out musí být odstraněno:* pravidlo mempoolu - [CPFP carve out][topic cpfp carve out], které bylo do Bitcoin Core - [přidáno][news56 carveout] v roce 2019, adresuje CPFP verzi [pinningu - transakcí][topic transaction pinning]. V této obdobě protistrana-útočník - zneužívá omezení v Bitcoin Core na počet a velikost souvisejících transakcí, - aby pozdržel operace nad dceřinou transakcí patřící čestnému spojení. - Pravidlo carve out umožňuje, aby jedna transakce tato omezení mírně - překročila. V cluster mempoolu jsou související transakce umístěny - do clusteru a omezení jsou aplikována na cluster, nikoliv na jednotlivé - transakce. S tímto pravidlem není možné zajistit, aby cluster obsahoval - maximálně jeden carve out, aniž bychom začali omezovat vztahy mezi - přeposílanými transakcemi daleko za hranicí dnešních omezení. - Cluster s několika carve out by mohl výrazně překročit limity, - načež by musel být pro ně protokol přestavěn. To by sice vyhovovalo - uživatelům carve out, ale omezovalo by to možnosti během běžného - zveřejňování transakcí. - - Navržené řešení nekompatibility mezi carve out pravidlem a cluster - mempoolem je [přeposílání transakcí verze 3][topic v3 transaction - relay]. To by umožňovalo běžným uživatelům transakcí verzí 1 a 2 - pokračovat obvyklým způsobem, ale zároveň by mohli uživatelé - protokolů jako LN zvolit použití v3 transakcí, které vynucují - omezení sady vztahů mezi transakcemi (_topologie_). Tato omezená - topologie by bránila pinningu transakcí a mohla by být zkombinována - s náhradami carve out transakcí jakou jsou [dočasné anchory][topic ephemeral - anchors]. + - *CPFP carve out musí být odstraněno:* pravidlo mempoolu + [CPFP carve out][topic cpfp carve out], které bylo do Bitcoin Core + [přidáno][news56 carveout] v roce 2019, adresuje CPFP verzi [pinningu + transakcí][topic transaction pinning]. V této obdobě protistrana-útočník + zneužívá omezení v Bitcoin Core na počet a velikost souvisejících transakcí, + aby pozdržel operace nad dceřinou transakcí patřící čestnému spojení. + Pravidlo carve out umožňuje, aby jedna transakce tato omezení mírně + překročila. V cluster mempoolu jsou související transakce umístěny + do clusteru a omezení jsou aplikována na cluster, nikoliv na jednotlivé + transakce. S tímto pravidlem není možné zajistit, aby cluster obsahoval + maximálně jeden carve out, aniž bychom začali omezovat vztahy mezi + přeposílanými transakcemi daleko za hranicí dnešních omezení. + Cluster s několika carve out by mohl výrazně překročit limity, + načež by musel být pro ně protokol přestavěn. To by sice vyhovovalo + uživatelům carve out, ale omezovalo by to možnosti během běžného + zveřejňování transakcí. + + Navržené řešení nekompatibility mezi carve out pravidlem a cluster + mempoolem je [přeposílání transakcí verze 3][topic v3 transaction + relay]. To by umožňovalo běžným uživatelům transakcí verzí 1 a 2 + pokračovat obvyklým způsobem, ale zároveň by mohli uživatelé + protokolů jako LN zvolit použití v3 transakcí, které vynucují + omezení sady vztahů mezi transakcemi (_topologie_). Tato omezená + topologie by bránila pinningu transakcí a mohla by být zkombinována + s náhradami carve out transakcí jakou jsou [dočasné anchory][topic ephemeral + anchors]. Je důležité, že tato velká změna správy mempoolu Bitcoin Core bere do úvahy všechny současné i možné budoucí způsoby používání bitcoinu. @@ -265,7 +265,7 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a [daftuar cluster]: https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393/ [news280 cluster]: /cs/newsletters/2023/12/06/#diskuze-o-cluster-mempoolu [news267 compress]: /cs/newsletters/2023/09/06/#komprimovane-bitcoinove-transakce -[briar compress]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2024-January/022274.html +[briar compress]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2024-January/022274.html [compress spec]: https://github.com/bitcoin/bitcoin/blob/7e8511c1a8229736d58bd904595815636f410aa8/doc/compressed_transactions.md [news201 mev]: /cs/newsletters/2022/05/25/#debata-o-tezari-extrahovatelne-hodnote [news266 lnbugs]: /cs/newsletters/2023/08/30/#zverejneni-probehle-zranitelnosti-ln-spojene-s-falesnym-financovanim diff --git a/_posts/cs/newsletters/2024-01-24-newsletter.md b/_posts/cs/newsletters/2024-01-24-newsletter.md index 03acd5b496..7caa6deba0 100644 --- a/_posts/cs/newsletters/2024-01-24-newsletter.md +++ b/_posts/cs/newsletters/2024-01-24-newsletter.md @@ -103,22 +103,22 @@ vydání a souhrnem významných změn v populárním bitcoinovém páteřním s protokolů _Bitcoin Inquisition Numbers And Names Authority_ ([BINANA][binana repo]). V době psaní obsahuje repozitář čtyři specifikace: - - [BIN24-1][] `OP_CAT` od Ethana Heilmana a Armina Sabouriho. Viz popis jejich - soft forku ve [zpravodaji č. 274][news274 cat]. + - [BIN24-1][] `OP_CAT` od Ethana Heilmana a Armina Sabouriho. Viz popis jejich + soft forku ve [zpravodaji č. 274][news274 cat]. - - [BIN24-2][] dědičné nasazování („heretical deployments”) od Anthonyho Townse - popisující používání [Bitcoin Inquisition][bitcoin inquisition repo] pro - návrhy soft forků a další změny na [signetu][topic signet]. Viz rozšířený popis ve - [zpravodaji č. 232][news232 inqui]. + - [BIN24-2][] dědičné nasazování („heretical deployments”) od Anthonyho Townse + popisující používání [Bitcoin Inquisition][bitcoin inquisition repo] pro + návrhy soft forků a další změny na [signetu][topic signet]. Viz rozšířený popis ve + [zpravodaji č. 232][news232 inqui]. - - [BIN24-3][] `OP_CHECKSIGFROMSTACK` od Brandona Blacka specifikující - tuto [dlouho navrhnovanou myšlenku][topic OP_CHECKSIGFROMSTACK]. - [Minulé číslo zpravodaje][news285 lnhance] popisuje Blackův návrh na - začlenění tohoto opkódu do soft forku LNHANCE. + - [BIN24-3][] `OP_CHECKSIGFROMSTACK` od Brandona Blacka specifikující + tuto [dlouho navrhnovanou myšlenku][topic OP_CHECKSIGFROMSTACK]. + [Minulé číslo zpravodaje][news285 lnhance] popisuje Blackův návrh na + začlenění tohoto opkódu do soft forku LNHANCE. - - [BIN24-4][] `OP_INTERNALKEY` do Brandona Blacka specifikující opkód, - který umožní načíst taprootový interní klíč z interpretru skriptu. - Také tento opkód byl popsán v minulém čísle v rámci LNHANCE. + - [BIN24-4][] `OP_INTERNALKEY` do Brandona Blacka specifikující opkód, + který umožní načíst taprootový interní klíč z interpretru skriptu. + Také tento opkód byl popsán v minulém čísle v rámci LNHANCE. Bitcoin Optech přidal repozitář BINANA na seznam zdrojů, které monitorujeme. Mezi další zdroje patří BIPy, BOLTy a BLIPy. Budoucí aktualizace budou popsány @@ -198,7 +198,7 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo] a {% include references.md %} {% include linkers/issues.md v=2 issues="29239,2810,2791,2801,2812,2230" %} [teinturier v3]: https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral-anchors/418/ -[towns binana]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2024-January/022289.html +[towns binana]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2024-January/022289.html [sanders transition]: https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral-anchors/418/2 [news283 v3pin]: /cs/newsletters/2024/01/03/#naklady-na-pinning-v3-transakci [news274 cat]: /cs/newsletters/2023/10/25/#navrh-bipu-pro-op-cat diff --git a/_posts/cs/newsletters/2024-01-31-newsletter.md b/_posts/cs/newsletters/2024-01-31-newsletter.md index 8fd4d4fc27..4c9dfd9ccc 100644 --- a/_posts/cs/newsletters/2024-01-31-newsletter.md +++ b/_posts/cs/newsletters/2024-01-31-newsletter.md @@ -237,6 +237,6 @@ repo]._ [news259 lncleanup]: /cs/newsletters/2023/07/12/#navrh-na-procisteni-specifikace-ln [news284 ptexogenous]: /cs/newsletters/2024/01/10/#caste-pouzivani-externich-poplatku-muze-ohrozovat-decentralizaci-tezby [zhao kindredimpl]: https://github.com/bitcoin/bitcoin/pull/29306 -[pt ctv]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2024-January/022309.html +[pt ctv]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2024-January/022309.html [news286 imbued]: /cs/newsletters/2024/01/24/#vstipena-v3-logika [news216 headers presync]: /en/newsletters/2022/09/07/#bitcoin-core-25717 diff --git a/_posts/cs/newsletters/2024-02-07-newsletter.md b/_posts/cs/newsletters/2024-02-07-newsletter.md index 3d5340dcc7..422c61cdb6 100644 --- a/_posts/cs/newsletters/2024-02-07-newsletter.md +++ b/_posts/cs/newsletters/2024-02-07-newsletter.md @@ -38,7 +38,9 @@ skupiny Bitcoin-Dev. kanály, které ovládá na obou stranách oběti, k přeposílání jím vytvořených plateb. Například: - Útočník-plátce –> Oběť-přeposílající –> Útočník-příjemce + ``` + Útočník-plátce –> Oběť-přeposílající –> Útočník-příjemce + ``` Útočník ve spolupráci s těžařem vytvoří blok, který jednostranně uzavírá kanál na příjemcově straně, aniž by prvně přeposlal transakci v nepotvrzeném stavu @@ -63,15 +65,15 @@ skupiny Bitcoin-Dev. Dle Siegela byly pro zabránění útoku provedeny dvě změny v Bitcoin Core: - - [Bitcoin Core #22144][] přidává náhodnost do pořadí, ve kterém jsou - spojení ve vlákně zpracovávajícím zprávy obsloužena. Viz [zpravodaj č. - 154][news154 stall] (_angl._). + * [Bitcoin Core #22144][] přidává náhodnost do pořadí, ve kterém jsou + spojení ve vlákně zpracovávajícím zprávy obsloužena. Viz [zpravodaj č. + 154][news154 stall] (_angl._). - - [Bitcoin Core #22147][] udržuje alespoň jedno odchozí spojení se širokým - pásmem pro kompaktní bloky, i když mají příchozí spojení lepší - výkonnost. Místní uzel si svá odchozí spojení sám vybírá, mají tedy - nižší pravděpodobnost dostat se pod kontrolu útočníka. Z bezpečnostních - důvodů je výhodné udržovat alespoň jedno odchozí spojení. + * [Bitcoin Core #22147][] udržuje alespoň jedno odchozí spojení se širokým + pásmem pro kompaktní bloky, i když mají příchozí spojení lepší + výkonnost. Místní uzel si svá odchozí spojení sám vybírá, mají tedy + nižší pravděpodobnost dostat se pod kontrolu útočníka. Z bezpečnostních + důvodů je výhodné udržovat alespoň jedno odchozí spojení. - **Bezpečné otevírání 0-conf kanálů s transakcemi verze 3:** Matt Corallo zaslal do fóra Delving Bitcoin [příspěvek][corallo 0conf], aby @@ -284,9 +286,9 @@ repo]._ [teinturier splice]: https://delvingbitcoin.org/t/0conf-ln-channels-and-v3-anchors/494/2 [teinturier segwit]: https://delvingbitcoin.org/t/malleability-issues-when-creating-shared-transactions-with-segwit-v0/497 [news97 spk]: /en/newsletters/2020/05/13/#request-for-an-additional-taproot-signature-commitment -[todd rbfr]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2024-January/022298.html -[erhardt rbfr1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2024-January/022302.html -[erhardt rbfr2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2024-January/022316.html +[todd rbfr]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2024-January/022298.html +[erhardt rbfr1]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2024-January/022302.html +[erhardt rbfr2]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2024-January/022316.html [sz rbfr]: https://delvingbitcoin.org/t/replace-by-fee-rate-vs-v3/488/ [libre relay]: https://github.com/petertodd/bitcoin/tree/libre-relay-v26.0 [libbitcoinkernel]: https://github.com/bitcoin/bitcoin/issues/27587 diff --git a/_posts/cs/newsletters/2024-02-14-newsletter.md b/_posts/cs/newsletters/2024-02-14-newsletter.md index 34b14a9dfd..c4aece878d 100644 --- a/_posts/cs/newsletters/2024-02-14-newsletter.md +++ b/_posts/cs/newsletters/2024-02-14-newsletter.md @@ -47,8 +47,8 @@ změn v populárním bitcoinovém páteřním software. logiku by mohl druhý potomek nahradit prvního potomka v rámci [balíčku][topic package relay] (viz [zpravodaj č. 287][news287 kindred]). - - Kolem 1,2 % bylo očividně prapotomkem commitment transakce, tedy utracení - utracení anchor výstupu. LN peněženky to mohou dělat + - Kolem 1,2 % bylo očividně prapotomkem commitment transakce, tedy utracení + utracení anchor výstupu. LN peněženky to mohou dělat z několika různých důvodů, od zavírání několika anchor kanálů v řadě po otevírání nových kanálů zůstatkem po zavření anchor kanálu. LN peněženky by toto chování musely opustit, pokud by byly anchor výstupům vštípeny vlastnosti @@ -268,6 +268,6 @@ repo]._ [review club 24538]: https://bitcoincore.reviews/24538 [review club 27501]: https://bitcoincore.reviews/27501 [news287 kindred]: /cs/newsletters/2024/01/31/#pribuzenske-nahrazovani-poplatkem -[migration email]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2024-February/022327.html +[migration email]: https://gnusha.org/pi/bitcoindev/CABaSBaxDjj6ySBx4v+rmpfrw4pE9b=JZJPzPQj_ZUiBg1HGFyA@mail.gmail.com/ [news276 ml]: /cs/newsletters/2023/11/08/#hosting-emailove-skupiny [news288 ml]: /cs/newsletters/2024/02/07/#aktualizace-migrace-emailove-skupiny-bitcoin-dev diff --git a/_posts/cs/newsletters/2024-02-28-newsletter.md b/_posts/cs/newsletters/2024-02-28-newsletter.md index df31780f4b..21075ee425 100644 --- a/_posts/cs/newsletters/2024-02-28-newsletter.md +++ b/_posts/cs/newsletters/2024-02-28-newsletter.md @@ -144,52 +144,104 @@ projektech. - - - - + + + + - - - - + + + + - - - - + + + + - - - - + + + + - - - - + + + + - - - - + + + + - - - - + + + +
Předem podepsanéBIP345 `OP_VAULT``OP_CAT` se SchnorremPředem podepsané + + BIP345 `OP_VAULT` + + + + `OP_CAT` se Schnorrem + +
Dostupnost**Nyní**Vyžaduje soft fork s `OP_VAULT` a [OP_CTV][topic op_checktemplateverify]Vyžaduje soft fork s `OP_CAT`Dostupnost + + **Nyní** + + + + Vyžaduje soft fork s `OP_VAULT` a [OP_CTV][topic op_checktemplateverify] + + + + Vyžaduje soft fork s `OP_CAT` + +
Útok nahrazení adresy na poslední chvíliZranitelné**Nejsou zranitelné****Nejsou zranitelné**Útok nahrazení adresy na poslední chvíliZranitelné + + **Nejsou zranitelné** + + + + **Nejsou zranitelné** + +
Vybrání části prostředkůPokud zajištěno předem**Ano**NeVybrání části prostředkůPokud zajištěno předem + + **Ano** + + Ne
Statické a neinteraktivně odvoditelné adresy pro vkladyNe**Ano****Ano**Statické a neinteraktivně odvoditelné adresy pro vkladyNe + + **Ano** + + + + **Ano** + +
Redukce poplatků dávkovým návratem do úschovnyNe**Ano**NeRedukce poplatků dávkovým návratem do úschovnyNe + + **Ano** + + Ne
Provozní účinnost v nejlepším případě, tedy pouze legitimní platby
*(hrubý odhad Optechu)*		**2× velikost běžné single-sig**3× velikost běžné single-sig4× velikost běžné single-sig + + Provozní účinnost v nejlepším případě, tedy pouze legitimní platby
*(hrubý odhad Optechu)* + + 		+ + **2× velikost běžné single-sig** + + 3× velikost běžné single-sig4× velikost běžné single-sig
diff --git a/_posts/cs/newsletters/2024-04-10-newsletter.md b/_posts/cs/newsletters/2024-04-10-newsletter.md new file mode 100644 index 0000000000..d15bcee129 --- /dev/null +++ b/_posts/cs/newsletters/2024-04-10-newsletter.md @@ -0,0 +1,305 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 297' +permalink: /cs/newsletters/2024/04/10/ +name: 2024-04-10-newsletter-cs +slug: 2024-04-10-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Zpravodaj tento týden oznamuje nový doménově specifický jazyk pro +experimenty s kontrakty, shrnuje diskuzi o úpravě zodpovědností +editorů BIPů a popisuje návrh na restart a změny testnetu. Též nechybí +naše pravidelné rubriky se souhrnem sezení Bitcoin Core PR Review Clubu, +oznámeními nových vydání a popisem významných změn v populárním bitcoinovém +páteřním software. + +## Novinky + +- **DSL pro experimenty s kontrakty:** Kulpreet Singh zaslal do + fóra Delving Bitcoin [příspěvek][singh dsl], ve kterém popisuje + doménově specifický jazyk (DSL) pro bitcoin, který vyvíjí. Jazyk + umožňuje popsat operace, které by měl protokol kontraktu vykonávat. + Díky němu bude možné rychle spouštět kontrakt v testovacím prostředí, + aby se zajistilo, že se chová dle očekávání. Výsledkem bude možnost + rychleji vyvíjet nové protokoly a poskytnout základ, oproti kterému + může být později vyvíjen plnohodnotný software. + + Robin Linus ve své [odpovědi][linus dsl] odkázal na podobný projekt + používající vysoko-úrovňový jazyk k popisu protokolu, který lze + přeložit na nízkoúrovňový kód a nezbytné operace. Těmi je potom možné + protokol vykonat. Tento projekt je součástí práce na [BitVM][topic acc]. + +- **Aktualizace BIP2:** Tim Ruffing zaslal do emailové skupiny Bitcoin-Dev + [příspěvek][ruffing bip2] o aktualizaci [BIP2][], který stanovuje současný + proces přidávání nových BIPů a údržbu stávajících. Ruffing i další zmínili + několik problémů, kterými současný proces trpí, například: + + - *Redakční zásahy a osobní postoje:* kolik úsilí by měli editoři + u nových BIPů vynakládat, aby zajistili jejich vysokou kvalitu a zaměření + na bitcoin? A jakou roli by měli hrát jejich osobní postoje při + odmítání nových BIPů? Ruffing spolu s několika dalšími diskutujícími + zmínili, že by preferovali minimalizaci redakčních požadavků a privilegií. + Ideálně by editoři měli za úkol pouze bránit zneužívání (např. spamu). + Samozřejmě by mohli editoři BIPů stejně jako ostatní členové komunity + dobrovolně navrhovat vylepšení návrhů, které jsou dle nich zajímavé. + + - *Licence:* některé povolené licence BIPů jsou navržené pro software a + nemusí pro dokumentaci dávat smysl. + + - *Komentáře:* jednou změnou mezi [BIP1][] a BIP2 byl pokus poskytnout + u každého BIPu prostor pro zpětnou vazbu komunity. Této možnosti nebylo + často využíváno a výsledky byly kontroverzní. + + V době psaní zpravodaje byla myšlenka na aktualizace BIP2 stála diskutována. + + Jiná, avšak související diskuze, kterou jsme zmínili [v minulém čísle][news296 editors], + se zabývala volbou nových editorů BIPů. Termín nominací a obhajoby byl [rozšířen][erhardt + editors] do konce pátku 19. dubna. Noví editoři by měli obdržet přístup + do repozitáře do konce následujícího pondělí. + +- **Diskuze o restartu a úpravě testnetu:** Jameson Lopp zaslal do emailové + skupiny Bitcoin-Dev [příspěvek][lopp testnet] s popisem problémů se současnou + veřejnou bitcoinovou testovací sítí (testnet3). Dále navrhl její restart, + případně s upravenými pravidly konsenzu pro okrajové případy. + + Předchozí verze testnetu byly restartovány, když někdo začal přisuzovat + testovacím mincím ekonomickou hodnotu. Kvůli tomu se mince staly hůře + dostupné lidem, kteří chtěli provádět skutečné testování. Lopp poskytl + důkazy, že se tak znovu děje. Dále popsal známý problém se zneužíváním + testnetového algoritmu výpočtu obtížnosti (difficulty), kvůli kterému dochází + k záplavě bloků. Několik účastníků diskutovalo případné změny, které + by adresovaly tyto i jiné problémy testnetu. Přinejmenším jeden + diskutující [by preferoval][kim testnet], aby popsané problémy nadále + pokračovaly, neboť umožňují zajímavé testování. + +## 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í.* + +[Přidej do interpretru Scriptu opkódy pro 64bitovou aritmetiku][review +club 29221] je PR od Chrise Stewarta (Christewart na GitHubu), které přináší +nové opkódy umožňující v Bitcoin Scriptu provádět aritmetické operace na větších +(64bitových) operandech, než kolik je umožněno nyní (32 bitů). + +Tato změna by v kombinaci s nějakým jiným existujícím návrhem na soft fork +(např. [OP_TLUV][ml OP_TLUV] přinášející introspekci transakcí) umožnila +používat skriptovací logiku založenou na výstupních částkách uvedených +v satoshi, které mohou snadno v 32bitových celočíselných datových typech přetéct. + +Diskuze o přístupu, např. zda-li změnit existující opkódy či vytvořit nové +(např. `OP_ADD64`), nadále probíhá. + +Více informací lze nalézt v rozpracovaném [BIPu][bip 64bit arithmetic] +a ve [vlákně][delving 64bit arithmetic] fóra Delving Bitcoin. + +{% include functions/details-list.md + + q0="Jakou roli má parametr `nMaxNumSize` v `CScriptNum`?" + a0="Představuje maximální velikost v bajtech, kterou může mít právě vykonávaný + prvek (typu `CScriptNum`) zásobníku. Ve výchozím stavu je nastavena + na čtyři bajty." + a0link="https://bitcoincore.reviews/29221#l-34" + + q1="Které dva opkódy akceptují pětibajtové číselné vstupy?" + a1="`OP_CHECKSEQUENCEVERIFY` a `OP_CHECKLOCKTIMEVERIFY` používají pro + reprezentaci časového razítka celá čísla se znaménkem. Pokud by byly použity + čtyři bajty, byl by rozsah možných dat omezen rokem 2038. Z tohoto + důvodu byla těmto dvěma opkódům učiněna výjimka, aby mohly používat + pět bajtů. Vše je řádně [dokumentováno][docs 5byte carveout] v kódu." + a1link="https://bitcoincore.reviews/29221#l-45" + + q2="Proč byl do `CScriptNum` přidán příznak `fRequireMinimal`?" + a2="`CScriptNum` je kódován s proměnlivou délkou. Jak je popsáno v + [BIP62][] (pravidlo 4), způsobuje toto kódování poddajnost (malleability). + Například nula může být kódována jako `OP_0`, `0x00`, `0x0000`, apod. + [Bitcoin Core #5065][] opravil tento problém u standardních transakcí + tím, že stanovil [minimální požadavky][doc SCRIPT_VERIFY_MINIMALDATA] na reprezentaci + dat a čísel přidávaných do zásobníku." + a2link="https://bitcoincore.reviews/29221#l-57" + + q3="Je implementace v tomto PR odolná vůči poddajnosti? Proč?" + a3="Současná implementace vyžaduje přesně osmibajtovou reprezentaci + operandů 64bitových opkódů, díky čemuž je odolná vůči poddajnosti. Tento + přístup je zdůvodněn jednodušší logikou implementace na úkor většího + zabraného blokového prostoru. Autor [v jiné větvi][64bit arith cscriptnum] + též zkoumal možnost používat `CScriptNum` s kódováním s proměnlivou délkou." + a3link="https://bitcoincore.reviews/29221#l-67" +%} + +## 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.* + +- [HWI 3.0.0][] je vydáním nové verze tohoto balíčku poskytujícího + společné rozhraní několika hardwarovým podpisovým zařízením. Jedinou + významnou změnou je, že emulované hardwarové peněženky již nebudou + automaticky detekovány. [HWI #729][] obsahuje podrobnosti. + +- [Core Lightning 24.02.2][] je údržbovým vydáním, které opravuje + „[drobnou nekompatibilitu][core lightning #7174]“ mezi Core Lighting + a LDK v jedné konkrétní části gossip protokolu. + +- [Bitcoin Core 27.0rc1][] je kandidátem na vydání příští hlavní verze + této převládající implementace plného uzlu. Testeři jsou vyzýváni, aby + shlédli seznam [navržených témat k testování][bcc testing]. + +## Významné změny kódu a dokumentace + +_Významné změny z tohoto týdne v [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Bitcoin Inquisition][bitcoin inquisition repo] a [repozitáři BINANA][binana +repo]._ + +*Poznámka: commity do Bitcoin Core uvedené níže se vztahují na jeho vývojovou, +master větev. Nebudou tedy pravděpodobně vydány před uplynutím zhruba +šesti měsíců po vydání nadcházející verze 27.* + +- [Bitcoin Core #29648][] odstraňuje libconsensus po nedávnem zastarání + (viz [zpravodaj č. 288][news288 libconsensus]). Libconsensus byl pokusem + poskytnout logiku konsenzu Bitcoin Core i jinému software. Avšak knihovna + se nesetkala s významným používáním a stala se v údržbě Bitcoin Core přítěží. + +- [Bitcoin Core #29130][] přidává dvě nová RPC volání. První z nich na základě + uživatelových nastavení vygeneruje deskriptor a přidá jej do peněženky. + Například následující příkaz přidá podporu pro [taproot][topic taproot] do staré + peněženky, která jej dříve nepodporovala: + + ``` + bitcoin-cli --rpcwallet=mywallet createwalletdescriptor bech32m + ``` + + Druhým voláním je `gethdkeys` pro načtení [hierarchických deterministických][topic + bip32] klíčů. RPC vrátí každý xpub (rozšířený veřejný klíč) používaný peněženkou + a (volitelně) též každý xpriv (rozšířený soukromý klíč). Obsahuje-li peněženka + více xpub, je možné během volání `createwalletdescriptor` zvolit, který z nich + má být použit. + +- [LND #8159][] a [#8160][lnd #8160] přidávají experimentální (ve výchozím + nastavení deaktivovanou) podporu pro odesílání plateb na [zaslepené cesty][topic + rv routing]. Očekává se, že [následné PR][lnd #8485] se kompletně vypořádá + s chybami neúspěšných zaslepených plateb. + +- [LND #8515][] přidává do několika RPC volání možnost určit název použité + [strategie výběru mincí][topic coin selection]. Toto PR staví na předchozím + navýšení flexibility výběru mincí, které bylo popsáno ve [zpravodaji č. 292][news292 + lndcs]. + +- [LND #6703][] a [#6934][lnd #6934] přidávají podporu pro příchozí routovací + poplatky. Uzel již nyní může ohlásit cenu, za kterou bude určitým odchozím + kanálem přeposílat platby. Například Carol může oznámit, že bude kanálem + k Danovi přeposílat platby za 0,1 % přeposílané částky. Pokud tento poplatek + sníží průměrné množství satoshi za minutu, které Carol přeposílá směrem + k Danovi, pod průměrnou částku, kterou on posílá směrem k ní, skončí + nakonec veškerý zůstatek na Carolině straně. Dan tak nebude moci směrem + ke Carol nic posílat a oba budou kráceni na výdělcích. Aby tomu zabránila, + může Carol snížit poplatek za použití kanálu směrem k Danovi na 0,05 %. + Podobně pokud je Carolin odchozí poplatek příliš nízký, v průměru bude posílat + více satoshi za minutu směrem k Danovi a celý zůstatek nakonec skončí + na jeho straně. V takovém případě může Carol odchozí poplatek zvýšit. + + Odchozí poplatky se ovšem týkají pouze odchozích kanálů. Carol si účtuje + stejný poplatek bez ohledu na kanál, ze kterého platbu obdrží. Například + požaduje stejný poplatek, ať již obdrží platbu od Alice nebo od Boba: + + ``` + Alice -> Carol -> Dan + Bob -> Carol -> Dan + ``` + + Je to pochopitelné, neboť LN protokol neplatí Carol nic za to, že obdrží + od Alice či Boba požadavek na přeposlání. Alice a Bob na svých + kanálech ke Carol poplatky stanovit mohou a je na nich, jak budou + nastavením poplatků udržovat likviditu kanálů. Podobně může Carol + nastavovat poplatky za použití kanálů směrem k Alici a Bobovi (např. + `Dan -> Carol -> Bob`), aby zajistila likviditu kanálů. + + Nicméně Carol může chtít mít více kontroly nad pravidly, které se jí + týkají. Například pokud Alice špatně spravuje svůj uzel, může často + přeposílat směrem ke Carol platby, aniž by později někdo chtěl posílat + platby i v opačném směru. To by nakonec vyústilo v nahromadění veškerého + zůstatku na Carolině straně, čímž by bylo znemožněno přeposílání dalších + plateb v tomto směru. Před tímto PR nebylo nic, co mohla Carol učinit, + kromě včasného zavření kanálu s Alicí před vyplýtváním přílišného množství + Carolina kapitálu. + + Díky tomuto PR může Carol nově účtovat _poplatek za příchozí žádost_, + který lze určit pro každý kanál. Například může požadovat vysoký poplatek + za platby přicházející z Alicina problematického uzlu, ale nižší poplatek + za platby přicházející z Bobova vysoce likvidního uzlu. Zprvu + budou příchozí poplatky vždy negativní, aby byla zaručena kompatibilita + se staršími uzly, které příchozím poplatkům nerozumí. Například by mohla + Carol nastavit 10% slevu na platby přicházející od Boba a 0% slevu + na platby přicházející od Alice. + + Tyto poplatky jsou posuzovány zároveň s poplatky odchozími. Například + pokud Alice nabídne Carol platbu, aby ji přeposlala Danovi, spočítá + Carol původní poplatek `odchozí_k_danovi`, spočítá nový poplatek + `příchozí_od_alice` a ujistí se, že přeposílaná platba jí na poplatku + nabídne nejméně součet obou. V opačném případě [HTLC][topic htlc] + odmítne. Jelikož se očekává, že budou zpočátku příchozí poplatky + negativní, nebude Carol odmítat žádné platby, které platí dostatečný + odchozí poplatek, avšak každý uzel, který příchozím poplatkům rozumí, + bude moci obdržet slevu. + + Příchozí routovací poplatky byly poprvé [navrženy][bolts #835] před + třemi lety, o rok později se o nich [diskutovalo][jager inbound] v + emailové skupině Lightning-Dev a ve stejné době byly zdokumentovány + v navrhovaném [BLIP #18][BLIPs #18]. Od doby prvního návrhu se několik + vývojářů jiných implementací LN stavělo proti němu. Někteří z + [principiálních důvodů][teinturier bolts835], jiní mu vyčítali + [příliš těsnou vazbu na LND][corallo overly specific] namísto lokální + a obecné změny, která by okamžitě umožňovala používat kladné příchozí + poplatky za přeposílání a nevyžadovala za každý kanál globální inzerování + dalších detailů o poplatcích. Alternativní přístup byl navržen v + [BLIP #22][BLIPs #22]. Víme pouze o jednom vývojáři mimo tým LND, který + [naznačil][corallo free money], že funkcionalitu implementují shodně s LND. + A to pouze v případě, že budou nabízeny záporné příchozí poplatky, neboť + „jsou to peníze zdarma pro naše uživatele.” + +- [Rust Bitcoin #2652][] mění, který veřejný klíč je vrácen po podepsání + [taprootového][topic taproot] vstupu během zpracování [PSBT][topic psbt]. + Dříve byl vrácen veřejný klíč podepisujícího soukromého klíče, avšak jak + PR poznamenává, „běžně se interní klíč považuje za ten, který podepisuje, + i když to technicky není pravda. Tento interní klíč je navíc v PSBT + již obsažen.” Nyní po začlenění PR bude vrácen interní klíč. + +- [HWI #729][] přestává automaticky vypisovat a používat emulátory zařízení. + Emulátory jsou převážně používány vývojáři HWI a hardwarových peněženek, + avšak jejich automatická detekce může přinést problémy běžným uživatelům. + Vývojáři pracující s emulátory musí nově přidat volbu `--emulators`. + +{% assign day_after_posting = page.date | date: "%s" | plus: 86400 | date: "%Y-%m-%d 16:00" %} +{% include snippets/recap-ad.md when=day_after_posting %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="729,29648,29130,8159,8160,8485,8515,6703,6934,835,18,22,2652,7174,5065" %} +[bcc testing]: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/27.0-Release-Candidate-Testing-Guide +[Bitcoin Core 27.0rc1]: https://bitcoincore.org/bin/bitcoin-core-27.0/test.rc1/ +[HWI 3.0.0]: https://github.com/bitcoin-core/HWI/releases/tag/3.0.0 +[Core Lightning 24.02.2]: https://github.com/ElementsProject/lightning/releases/tag/v24.02.2 +[news292 lndcs]: /cs/newsletters/2024/03/06/#lnd-8378 +[news288 libconsensus]: /cs/newsletters/2024/02/07/#bitcoin-core-29189 +[teinturier bolts835]: https://github.com/lightning/bolts/issues/835#issuecomment-764779287 +[corallo free money]: https://github.com/lightning/blips/pull/18#issuecomment-1304319234 +[corallo overly specific]: https://github.com/lightningnetwork/lnd/pull/6703#issuecomment-1374694283 +[jager inbound]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-July/003643.html +[singh dsl]: https://delvingbitcoin.org/t/dsl-for-experimenting-with-contracts/748 +[linus dsl]: https://delvingbitcoin.org/t/dsl-for-experimenting-with-contracts/748/4 +[ruffing bip2]: https://gnusha.org/pi/bitcoindev/59fa94cea6f70e02b1ce0da07ae230670730171c.camel@timruffing.de/ +[news296 editors]: /cs/newsletters/2024/04/03/#vyber-novych-editoru-bipu +[erhardt editors]: https://gnusha.org/pi/bitcoindev/c304a456-b15f-4544-8f86-d4a17fb0aa8c@murch.one/ +[lopp testnet]: https://gnusha.org/pi/bitcoindev/CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw@mail.gmail.com/ +[kim testnet]: https://gnusha.org/pi/bitcoindev/950b875a-e430-4bd8-870d-f9a9fab2493an@googlegroups.com/ +[review club 29221]: https://bitcoincore.reviews/29221 +[delving 64bit arithmetic]: https://delvingbitcoin.org/t/64-bit-arithmetic-soft-fork/397 +[bip 64bit arithmetic]: https://github.com/bitcoin/bips/pull/1538 +[64bit arith cscriptnum]: https://github.com/Christewart/bitcoin/tree/64bit-arith-cscriptnum +[docs 5byte carveout]: https://github.com/bitcoin/bitcoin/blob/3206e45412ded0e70c1f15ba66c2ba3b4426f27f/src/script/interpreter.cpp#L531-L544 +[doc SCRIPT_VERIFY_MINIMALDATA]: https://github.com/bitcoin/bitcoin/blob/3206e45412ded0e70c1f15ba66c2ba3b4426f27f/src/script/interpreter.h#L69-L73 +[ml OP_TLUV]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html diff --git a/_posts/cs/newsletters/2024-04-17-newsletter.md b/_posts/cs/newsletters/2024-04-17-newsletter.md new file mode 100644 index 0000000000..e8e8629afb --- /dev/null +++ b/_posts/cs/newsletters/2024-04-17-newsletter.md @@ -0,0 +1,189 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 298' +permalink: /cs/newsletters/2024/04/17/ +name: 2024-04-17-newsletter-cs +slug: 2024-04-17-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Zpravodaj tento týden shrnuje analýzu chování uzlu s cluster mempoolem, kterému +byly předány všechny transakce nalezené v síti během roku 2023. Též nechybí +naše pravidelné rubriky s popisem nedávných změn v klientech a službách, +oznámeními o nových vydáních a souhrnem významných změn v populárním bitcoinovém +páteřním software. + +## Novinky + +- **Co by nastalo, kdyby byl cluster mempool nasazen před rokem?** + Suhas Daftuar ve svém [příspěvku][daftuar cluster] ve fóru Delving Bitcoin + uvedl, že uložil všechny transakce, které jeho uzel obdržel během roku 2023, + a prohnal je vývojovou verzí Bitcoin Core s aktivovaným [cluster + mempoolem][topic cluster mempool], aby kvantifikoval rozdíly mezi stávající + a vývojovou verzí. Mezi jeho nálezy patří: + + - *Uzel s cluster mempoolem přijal o 0,01 % více transakcí:* „V roce 2023 + bylo v aktuální verzi kvůli limitům předků a potomků odmítnuto přes + 46 000 transakcí. […] Jen kolem 14 000 transakcí bylo odmítnuto kvůli + limitům velikosti clusterů.“ Kolem 10 000 transakcí původně odmítnutých + cluster mempoolem (70 % ze 14 000) by bylo později přijato, pokud by + transakce byly po potvrzení předků znovu zveřejněny. Toto je očekávané + chování. + + - *Rozdíly v RBF jsou zanedbatelné:* „Pravidla RBF vynucovaná oběma simulacemi + nejsou totožná, avšak ukázalo se, že má tento rozdíl na počet přijetí zanedbatelný + vliv.” Níže uvádíme více podrobností. + + - *Cluster mempool byl pro těžaře stejně dobrý jako původní výběr transakcí:* + Daftuar poznamenal, že v současnosti nakonec skončí téměř každá transakce + v nějakém bloku, aktuální výběr transakcí v Bitcoin Core i výběr s cluster + mempoolem by tedy obdržely na poplatcích stejnou částku. Avšak v analýze, + o které se Daftuar domnívá, že výsledky nadhodnocuje, obdržel cluster mempool + více poplatků v 73 % případů. Původní výběr transakcí byl lepší v 8 % případů. + Daftuar uvedl, že „i když není jasné, zda je na základě aktivity z roku 2023 cluster + mempool materiálně lepší než současná verze, vidím jako nepravděpodobné, + že by byl cluster mempool materiálně horší.” + + Daftuar též uvažoval nad dopadem cluster mempoolu na nahrazování transakcí + poplatkem ([RBF][topic rbf]). Na začátku podrobně shrnuje rozdíl mezi současným + chováním Bitcoin Core a fungováním s cluster mempoolem (zvýrazňování + i odkazy jsou původní): + + > Centrálním bodem RBF pravidel cluster mempoolu je, zda by se po uskutečněném + > nahrazení [poplatkový diagram mempoolu zlepšil][feerate diagram]. Současná + > RBF pravidla v Bitcoin Core jsou zhruba popsána v BIP125 a [zdokumentována + > zde][rbf doc]. + > + > Na rozdíl od BIP125 se navrhovaná RBF pravidla [cluster mempoolu] soustředí + > na **výsledek** nahrazení. Teoreticky může být transakce lepší, než je + > v praxi: možná „by měla“ být akceptována na základě teoretického porozumění + > toho, co je dobré pro mempool, ale pokud by byl z jakéhokoliv důvodu výsledný + > poplatkový diagram horší (třeba kvůli neoptimálnímu algoritmu linearizace), + > nahrazení odmítneme. + + Též zde znovu uvedeme závěr jedné sekce, o které se domníváme, + že byla dobře podložená daty a analýzou, kterou poskytl: + + > Co se týče RBF, celkově byly rozdíly mezi cluster mempoolem a stávajícími + > pravidly minimální. Liší se hlavně v bodech, kde navrhovaná nová pravidla RBF + > chrání mempool před nahrazeními, která nejsou v souladu s ekonomickými záměry + > (to je dobrá změna). Je ale důležité vědět, že by teoreticky mohlo dojít + > k odmítnutí nahrazení v případech, kdy by bylo v ideálním světě [nyní] přijato, + > protože někdy může zjevně dobré nahrazení vést k neoptimálnímu chování, které + > dříve (dle pravidel BIP125) nebylo detekováno, ale s novými pravidly by detekováno + > bylo a nahrazení by bylo zabráněno. + + V době psaní zpravodaje neobdržel příspěvek žádné reakce. + +## Změny ve službách a klientech + +*V této měsíční rubrice upozorňujeme na zajímavé aktualizace bitcoinových +peněženek a služeb.* + +- **Ohlášena serverová verze Phoenix:** + Phoenix Wallet ohlásila zjednodušený Lightning uzel bez grafického rozhraní + [phoenixd][phoenixd github], který se soustředí na odesílání a příjem plateb. + Phoenixd cílí na vývojáře, je založen na existujícím software Phoenix Wallet + a automatizuje správu kanálů, spojení a likvidity. + +- **Mercury Layer přidává Lightning swapování:** + [Statechain][topic statechains] Mercury Layer umí díky [pozdrženým fakturám][topic + hold invoices] („hold invoices”) swapovat mince statechainu za lightningové + platby. + +- **Vydána referenční implementace Stratum V2 v1.0.0:** + [Vydání v1.0.0][sri blog] „je výsledkem vylepšení specifikace Stratum V2, které + vzešlo ze spolupráce v rámci pracovní skupiny a důsledného testování.“ + +- **Aktualizace Teleport Transactions:** + Byl [ohlášen][tt tweet] fork [původního repozitáře Teleport Transactions][news192 tt] + obsahující několik aktualizací a vylepšení. + +- **Vydán Bitcoin Keeper v1.2.1:** + [Vydání v1.2.1][bitcoin keeper v.1.2.1] přidává podporu pro [taprootové][topic + taproot] peněženky. + +- **Software správy štítků dle BIP329:** + Vydání [Labelbase][labelbase blog] verze 2 obsahuje mimo jiné možnost vlastního hostování a + importu a exportu dle [BIP329][]. + +- **Spuštěn správce klíčů Sigbash:** + Podpisová služba [Sigbash][] umožňuje uživatelům zakoupit xpub, který může + být použit v konfiguracích s vícenásobnými podpisy. Služba podepíše + [PSBT][topic psbt] pouze, pokud nastane nějaká uživatelem zvolená podmínka + (hashrate, cena bitcoinu, zůstatek na adrese, uplynutí lhůty). + +## 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.* + +- [Bitcoin Core 27.0][] je vydání příští hlavní verze této převládající implementace + plného uzlu. Tato verze zastarává libbitcoinconsensus (viz zpravodaje + [č. 288][news288 libconsensus] a [č. 297][news297 libconsensus]), ve výchozím + nastavení aktivuje [šifrovaný P2P přenos verze 2][topic v2 p2p transport] + (viz [zpravodaj č. 288][news288 v2 p2p]), umožňuje volitelné používání + pravidel transakcí do potvrzení topologicky omezených ([TRUC][topic v3 + transaction relay], „topologically restricted until confirmation,” též nazývané + _přeposílání verze 3_) na testovacích sítích (viz [zpravodaj č. 289][news289 truc]) + a přidává novou strategii [výběru mincí][topic coin selection] použitelnou + v období vysokých poplatků (viz [zpravodaj č. 290][news290 coingrinder]). + [Poznámky k vydání][bcc27 rn] obsahují úplný seznam významných změn. + +- [BTCPay Server 1.13.1][] je nejnovějším vydáním tohoto platebního procesoru + nabízející vlastní hostování. Od naší poslední zmínky o aktualizaci + BTCPay Serveru ve [zpravodaji č. 262][news262 btcpay] byly [rozšířeny][btcpay + server #5421] webhooks, byla přidána podpora pro import multisig peněženek dle + [BIP129][] (viz [zpravodaj č. 281][news281 bip129]), vylepšena byla + flexibilita pluginů, započala migrace podpory všech altcoinů do pluginů + a byla přidána podpora pro [PSBT][topic psbt] kódované pomocí BBQr + (viz [zpravodaj č. 295][news295 bbqr]). Vydání obsahuje i další nové + funkce a opravy chyb. + +- [LDK 0.0.122][] je nejnovějším vydáním této knihovny pro budování + aplikací s LN. Následuje po vydání [0.0.121][ldk 0.0.121], které opravilo + zranitelnost způsobující odepření služby. Nové vydání též opravuje + několik chyb. + +## Významné změny kódu a dokumentace + +_Významné změny z tohoto týdne v [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Bitcoin Inquisition][bitcoin inquisition repo] a [repozitáři BINANA][binana +repo]._ + +- [LDK #2704][] přináší významnou aktualizaci a rozšíření dokumentace `ChannelManager`. + Tato třída je „konečným automatem stavu kanálu a logikou správy plateb; zprostředkovává + posílání, přeposílání a příjem plateb lightningovými kanály.” + +{% assign day_after_posting = page.date | date: "%s" | plus: 86400 | date: "%Y-%m-%d 14:30" %} +{% include snippets/recap-ad.md when=day_after_posting %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="2704,5421" %} +[Bitcoin Core 27.0]: https://bitcoincore.org/bin/bitcoin-core-27.0/ +[feerate diagram]: https://delvingbitcoin.org/t/mempool-incentive-compatibility/553/1 +[rbf doc]: https://github.com/bitcoin/bitcoin/blob/0de63b8b46eff5cda85b4950062703324ba65a80/doc/policy/mempool-replacements.md +[daftuar cluster]: https://delvingbitcoin.org/t/research-into-the-effects-of-a-cluster-size-limited-mempool-in-2023/794 +[bcc27 rn]: https://github.com/bitcoin/bitcoin/blob/c7567d9223a927a88173ff04eeb4f54a5c02b43d/doc/release-notes/release-notes-27.0.md +[news288 libconsensus]: /cs/newsletters/2024/02/07/#bitcoin-core-29189 +[news297 libconsensus]: /cs/newsletters/2024/04/10/#bitcoin-core-29648 +[news288 v2 p2p]: /cs/newsletters/2024/02/07/#bitcoin-core-29347 +[news289 truc]: /cs/newsletters/2024/02/14/#bitcoin-core-28948 +[news290 coingrinder]: /cs/newsletters/2024/02/21/#bitcoin-core-27877 +[news281 bip129]: /cs/newsletters/2023/12/13/#btcpay-server-5389 +[news295 bbqr]: /cs/newsletters/2024/03/27/#btcpay-server-5852 +[news262 btcpay]: /cs/newsletters/2023/08/02/#btcpay-server-1-11-1 +[ldk 0.0.122]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.0.122 +[ldk 0.0.121]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.0.121 +[btcpay server 1.13.1]: https://github.com/btcpayserver/btcpayserver/releases/tag/v1.13.1 +[phoenixd github]: https://github.com/ACINQ/phoenixd +[sri blog]: https://stratumprotocol.org/blog/sri-1-0-0/ +[news192 tt]: /en/newsletters/2022/03/23/#coinswap-implementation-teleport-transactions-announced +[tt tweet]: https://twitter.com/RajarshiMaitra/status/1768623072280809841 +[bitcoin keeper v.1.2.1]: https://github.com/bithyve/bitcoin-keeper/releases/tag/v1.2.1 +[labelbase blog]: https://labelbase.space/ann-v2/ +[Sigbash]: https://sigbash.com/ diff --git a/_posts/cs/newsletters/2024-04-24-newsletter.md b/_posts/cs/newsletters/2024-04-24-newsletter.md new file mode 100644 index 0000000000..81738fbe8c --- /dev/null +++ b/_posts/cs/newsletters/2024-04-24-newsletter.md @@ -0,0 +1,224 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 299' +permalink: /cs/newsletters/2024/04/24/ +name: 2024-04-24-newsletter-cs +slug: 2024-04-24-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Zpravodaj tento týden popisuje návrh na přeposílání slabých bloků za účelem +vylepšení výkonnosti kompaktních bloků v síti s rozmanitými pravidly mempoolu +a oznamuje přidání pětice editorů BIPů. Též nechybí naše pravidelné rubriky +s vybranými otázkami a odpověďmi z Bitcoin Stack Exchange, oznámeními o nových +vydáních a souhrnem významných změn v populárním bitcoinovém páteřním software. + +## Novinky + +- **Implementace ověření konceptu slabých bloků:** Greg Sanders zaslal do fóra + Delving Bitcoin [příspěvek][sanders weak] o použití _slabých bloků_ + (weak blocks) za účelem vylepšení [přeposílání kompaktních bloků][topic + compact block relay], obzvláště ve stavu roztříštěnosti těžby a pravidel + pro přeposílání transakcí. Slabý blok je blok po všech stránkách validní, + který však nemá dostatečný proof of work (PoW) na to, aby se stal příštím blokem. + Těžaři produkují slabé bloky poměrně k procentu požadovaného PoW každého + bloku. Například těžař vyprodukuje v průměru devět slabých bloků + při požadovaných deseti procentech PoW na každý jím vyprodukovaný blok s + plným PoW. + + Těžaři neví, kdy vyprodukují slabý blok. Každý jejich kandidát na blok + má shodnou šanci dosáhnout plného PoW; některé z těchto kandidátů se namísto + toho stanou slabými bloky. Jediným způsobem, jak slabý blok vytvořit, je provádět + stejnou práci nutnou pro blok s plným PoW. Slabý blok tedy přesně odráží, + které transakce se těžař pokoušel vytěžit v čase, kdy byl slabý blok vytvořen. + Například jedinou možností, jak zahrnout nevalidní transakci do slabého bloku, + je riskovat vytvoření bloku s plným PoW se stejnou nevalidní transakcí. + Tento nevalidní blok by plné uzly odmítly a těžař by neobdržel odměnu. + Samozřejmě těžař, který by nechtěl publikovat, jaké transakce se pokoušel + vytěžit, může jednoduše odmítnout své slabé bloky zveřejnit. + + Díky vysoké obtížnosti vytváření desetiprocentních slabých bloků a vysokým nákladům + na vytváření slabých bloků s nevalidními transakcemi by byly slabé bloky + silně odolné vůči útokům odepřením služby, které by se mohly pokusit o plýtvání + velkého množství šířky pásma uzlu, procesoru a paměti. + + Jelikož jsou slabé bloky standardními bloky s mírně nedostatečným PoW, mají i stejnou + velikost jako běžné bloky. Když bylo přeposílání slabých bloků před deseti lety + poprvé popsáno, znamenalo to, že by přeposílání desetiprocentních slabých bloků + zvýšilo objem dat potřebných pro přeposílání bloků až desetkrát. Avšak před mnoha + lety začal Bitcoin Core používat přeposílání kompaktních bloků, které v rámci bloku + nahrazuje transakce krátkými identifikátory. To umožňuje přijímajícímu uzlu vyžádat + si pouze ty transakce, které zatím neviděl. V běžném případě to snižuje objem přenášených + dat o více než 99 %. Sanders poznamenává, že by to stejným způsobem fungovalo i + v případě slabých bloků. + + U bloků s plným PoW nejenže přeposílání kompaktních bloků snižuje nároky na + přenosové pásmo, ale též výrazně urychluje propagaci bloků. Čím méně dat + (tedy méně kompletních transakcí) je potřeba poslat, tím rychleji mohou být + zbývající data poslána. Rychlejší propagace nových bloků je důležitá pro + decentralizaci těžby: těžař, který nalezne nový blok, může na jeho následníkovi + začít pracovat okamžitě, ale ostatní těžaři musí čekat, až ze sítě nový blok obdrží. + To dává výhodu velkým těžařským poolům a vytváří to nezamýšlený druh útoku, + sobecké těžby (viz [zpravodaj č. 244][news244 selfish]). Tento problém byl před + příchodem přeposílání kompaktních bloků běžný a vedl k centralizaci těžby do + velkých poolů a k používání problematických technik, jako je podloudná těžba vedoucí + v červenci 2015 k [štěpením blokchainu][July 2015 chain forks]. + + Přeposílání kompaktních bloků šetří přenosové pásmo a urychluje propagaci + bloků pouze, pokud příjemce nového bloku již viděl většinu jeho transakcí. + Avšak jak Sanders poznamenává, někteří těžaři v současnosti vytváří bloky s + mnoha transakcemi, které se mezi uzly nešíří. To snižuje účinnost přeposílání + kompaktních bloků a zvyšuje riziko výskytu stejných problémů, které existovaly + před příchodem kompaktních bloků. Jako řešení navrhuje přeposílání slabých bloků: + + - Těžaři, kteří vytvoří slabé bloky (např. desetiprocentní), by je příležitostně + přeposlali uzlům. Příležitostně znamená, že by byl přenos považován za + běžný P2P síťový provoz, podobně jako přeposílání nových, nepotvrzených transakcí, + a nikoliv jako prioritní provoz, který využívají například nové bloky. + + - Uzly by příležitostně tyto slabé bloky přijaly a validovaly. Ověření PoW + je triviální a nastalo by okamžitě. Poté by byl blok dočasně uložen v paměti, + zatímco by byly ověřovány jeho transakce. Validní transakce + z tohoto slabého bloku by byly přidány do mempoolu. Transakce, které validací + neprojdou, by byly uloženy do vyhrazené mezipaměti. Podobné mezipaměti již + Bitcoin Core používá k dočasnému uložení transakcí, které do mempoolu přidány + být nemohou (např. mezipaměť osiřelých transakcí). + + - Další příchozí slabé bloky by mempool a mezipaměť aktualizovaly. + + - Když uzel pomocí kompaktního přeposílání obdrží blok s plným PoW, mohl + by využít transakce uložené v mempoolu a mezipaměti slabých bloků. + Potřeba další prodlevy a přenosového pásma by tak byla minimalizovaná. + Díky tomu by mohla síť, ve které se vyskytuje mnoho uzlů s roztříštěnými + pravidly, i nadále využívat výhod kompaktních bloků. + + Dále Sanders poukazuje na předchozí diskuzi o slabých blocích (viz + [zpravodaj č. 173][news173 weak], _angl._) popisující, jak by mohly slabé + bloky pomoci v boji proti [pinningovým útokům][topic transaction pinning] + a ve vylepšení [odhadu poplatků][topic fee estimation]. Používání slabých bloků + bylo též dříve zmíněno v diskuzi o přeposílání transakcí protokolem Nostr + (viz [zpravodaj č. 253][news253 weak]). + + Sanders napsal „základ [ověření konceptu][sanders poc] s jednoduchými testy, + které ukazují jádro myšlenky.“ Diskuze v době psaní zpravodaje nadále + probíhala. + +- **Aktualizace o editorech BIPů:** po veřejné diskuzi (viz zpravodaje + [č. 292][news292 bips], [č. 296][news296 bips] a [č. 297][news297 bips]) byli + [představeni][chow editors] noví editoři BIPů: Bryan „Kanzure“ Bishop, + Jon Atack, Mark „Murch” Erhardt, Olaoluwa „Roasbeef” Osuntokun a + Ruben Somsen. + +## Vybrané otázky a odpovědi z Bitcoin Stack Exchange + +*[Bitcoin Stack Exchange][bitcoin.se] je jedním z prvních míst, kde hledají +přispěvatelé Optechu odpovědi na své otázky a kde – najdou-li volnou chvíli – +pomáhají zvědavým či zmateným uživatelům. V této měsíční rubrice nabízíme +některé z otázek a odpovědí, které obdržely vysoký počet hlasů.* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- [Kde přesně je ve výpočtu obtížnosti off-by-one chyba?]({{bse}}20597) + Antoine Poinsot vysvětluje off-by-one chybu (o jedničku vedle) ve výpočtu + nové hodnoty obtížnosti, která umožňuje [útok ohýbáním času][topic time warp] + („time warp attack”). Tuto chybu se snaží adresovat návrh na [pročištění konsenzu][topic consensus + cleanup] (viz [zpravodaj č. 296][news296 cc]). + +- [Jak je z vývojářova pohledu v používání opkódů odlišné P2TR oproti P2PKH?]({{bse}}122548) + Murch usuzuje, že by skript z příkladu použitý jako P2PKH výstup byl nestandardní + a dražší než P2TR, ale validní z pohledu konsenzu. + +- [Jsou nahrazující transakce větší než jejich předchůdci a neRBF transakce?]({{bse}}122473) + Vojtěch Strnad poznamenává, že transakce signalizující [RBF][topic rbf] mají stejnou + velikost jako nesignalizující transakce. Dále uvádí scénáře, ve kterých by nahrazující + transakce mohla být buď stejně velká, větší či menší než původní, nahrazovaná transakce. + +- [Jsou bitcoinové podpisy stále zranitelné opakovaným používáním nonce?]({{bse}}122621) + Pieter Wuille potvrzuje, že [Schnorrovy podpisy][topic schnorr signatures] i ECDSA + podpisy – včetně jejich [multisig][topic multisignature] variant – jsou zranitelné + vůči opakovanému používání nonce. + +- [Jak těžaři ručně přidávají transakce do šablony bloku?]({{bse}}122725) + Ava Chow nastiňuje odlišné přístupy, kterých by těžař mohl využít k začlenění + transakcí do bloku, které by v něm po použití volání Bitcoin Core `getblocktemplate` + jinak chyběly: + + - voláním `sendrawtransaction` přidat transakci do těžařova mempoolu a nato + upravit její [zjevný absolutní poplatek][prioritisetransaction fee_delta] + pomocí `prioritisetransaction` + - použít upravenou implementaci `getblocktemplate` nebo zvláštní software pro + tvorbu bloků + +## 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.5-beta][] je údržbovým vydáním, které přináší kompatibilitu s + Bitcoin Core 27.x. + + Jak bylo vývojářům LND [reportováno][lnd #8571], starší verze LND závisející + na starší verzi [btcd][] zamýšlela nastavit maximální jednotkový + poplatek na 10 miliónů sat/kB (0,1 BTC/kB). Avšak Bitcoin Core vyžaduje + jednotkové poplatky v BTC/kvB; maximální jednotkový poplatek byl tedy + nastaven na 10 miliónů BTC/kvB. Bitcoin Core 27.0 obsahuje [PR][bitcoin core #29434], + které omezuje maximální jednotkový poplatek na 1 BTC/kvB, aby předešel + některým problémům. Předpokládá, že pokud by někdo nastavoval vyšší + hodnotu, pravděpodobně by to bylo kvůli chybě (pokud by opravdu vyšší hodnotu + zamýšlel, mohl by nastavit parametr na 0 a tím kontrolu obejít). V tomto případě + LND (via btcd) opravdu chybu činilo, ale změna v Bitcoin Core zabraňovala LND + v odesílání onchain transakcí. To může být pro LN uzel nebezpečné, neboť někdy + spoléhá na časově citlivé transakce. Toto údržbové vydání správně nastavuje + maximální hodnotu na 0,1 BTC/kvB v souladu s novými verzemi Bitcoin Core. + +## Významné změny kódu a dokumentace + +_Významné změny z tohoto týdne v [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Bitcoin Inquisition][bitcoin inquisition repo] a [repozitáři BINANA][binana +repo]._ + +- [Bitcoin Core #29850][] omezuje maximální počet IP adres akceptovaný od jednoho + DNS seedu na 32 na dotaz. Při dotazování DNS přes UDP omezuje maximální velikost + paketu tento počet na 33, avšak alternativní dotazování DNS přes TCP může nyní + vrátit mnohem vyšší počet výsledků. Aby posbíraly IP adresy, připojují se nové uzly + k několika DNS seedům. Poté náhodně vyberou některé z těchto adres a připojí + se k nim. Pokud tento uzel obdrží od každého seedu zhruba stejný počet IP adres, + je nepravděpodobné, že by všechny zvolené uzly, ke kterým se připojí, pocházely + od stejného seedu. To napomáhá zajisti, aby měl uzel rozmanitý pohled na síť + a nebyl náchylný k [útokům zastíněním][topic eclipse attacks]. + + Avšak pokud by některý ze seedů vrátil mnohem větší počet IP adres než ostatní, + existovala by vysoká pravděpodobnost, že by tento uzel náhodně zvolil množinu + IP adres pocházejících právě od toho seedu. Pokud by měl tento seed zlé úmysly, + mohl by uzel izolovat od čestné sítě. [Testování][bitcoin core #16070] ukázalo, + že všechny seedy v té době vracely 50 či méně výsledků, ačkoliv byl maximální + povolený počet 256. Toto začleněné PR omezuje maximální počet na podobnou velikost, + kterou současné seedy vrací. + +{% assign day_after_posting = page.date | date: "%s" | plus: 86400 | date: "%Y-%m-%d 14:30" %} +{% include snippets/recap-ad.md when=day_after_posting %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="8571,29434,29850,16070" %} +[sanders weak]: https://delvingbitcoin.org/t/second-look-at-weak-blocks/805 +[news173 weak]: /en/newsletters/2021/11/03/#feerate-communication +[news253 weak]: /cs/newsletters/2023/05/31/#preposilani-transakci-po-nostru +[sanders poc]: https://github.com/instagibbs/bitcoin/commits/2024-03-weakblocks_poc/ +[july 2015 chain forks]: https://en.bitcoin.it/wiki/July_2015_chain_forks +[selfish mining attack]: https://bitcointalk.org/index.php?topic=324413.msg3476697#msg3476697 +[news244 selfish]: /cs/newsletters/2023/03/29/#bitcoin-core-27278 +[btcd]: https://github.com/btcsuite/btcd/pull/2142 +[chow editors]: https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/T/#m654f52c426bd5696d88668b3bff25197846e14af +[news292 bips]: /cs/newsletters/2024/03/06/#diskuze-o-pridani-dalsich-editoru-bipu +[news296 bips]: /cs/newsletters/2024/04/03/#vyber-novych-editoru-bipu +[news297 bips]: /cs/newsletters/2024/04/10/#aktualizace-bip2 +[LND v0.17.5-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.17.5-beta +[news296 cc]: /cs/newsletters/2024/04/03/#navrat-k-tematu-procisteni-konsenzu +[prioritisetransaction fee_delta]: https://developer.bitcoin.org/reference/rpc/prioritisetransaction.html#argument-3-fee-delta +[taproot nonces]: /en/preparing-for-taproot/#multisignature-nonces diff --git a/_posts/cs/newsletters/2024-05-01-newsletter.md b/_posts/cs/newsletters/2024-05-01-newsletter.md new file mode 100644 index 0000000000..23f3b178fd --- /dev/null +++ b/_posts/cs/newsletters/2024-05-01-newsletter.md @@ -0,0 +1,234 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 300' +permalink: /cs/newsletters/2024/05/01/ +name: 2024-05-01-newsletter-cs +slug: 2024-05-01-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Zpravodaj tento týden shrnuje návrh ve stylu CTV, který používá commitmenty +vložené do veřejných klíčů, zkoumá analýzu kontraktového protokolu s Alloy, +oznamuje zatčení bitcoinových vývojářů a odkazuje na zápisky ze setkání vývojářů +CoreDev.tech. Též nechybí naše pravidelné rubriky s oznámeními nových vydání +a souhrnem významných změn v populárních bitcoinových páteřních projektech. + +## Novinky + +- **Návrh na rozrůstající se klíče ve stylu CTV:** Tadge Dryja zaslal do fóra + Delving Bitcoin [příspěvek][dryja exploding] s návrhem na mírně efektivnější + verzi hlavní myšlenky [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] + (CTV). Použitím CTV může Alice platit na výstup typu: + + ```text + OP_CTV + ``` + + Předobraz hashe zavazuje hlavním částem transakce, zejména částce + každého výstupu a skriptu, na který každý výstup platí. Například: + + ```text + hash( + 2 BTC pro KlíčB, + 3 BTC pro KlíčC, + 4 BTC pro KlíčD + ) + ``` + + Opkód `OP_CTV` skončí úspěchem, pokud je vykonán v transakci přesně odpovídající + těmto parametrům. Znamená to, že Alicin výstup v jedné transakci může být + utracen v jiné bez požadavku na další dodatečný podpis nebo jiná data, pokud se tato + druhá transakce přesně shoduje s Aliciným očekáváním. + + Dryja navrhuje alternativní způsob. Alice platí na veřejný klíč (podobně jako na + [taprootový][topic taproot] výstup, avšak s jinou segwit verzí). Ten + je zkonstruován z [MuSig2][topic musig] agregace jednoho nebo více skutečných + veřejných klíčů s aplikovanými tweaky, které zavazují částkám. Následující příklad + je odvozen z Dryjova příspěvku: + + ```text + musig2( + KlíčB + hash(2 BTC, KlíčB)*G, + KlíčC + hash(3 BTC, KlíčC)*G, + KlíčD + hash(4 BTC, KlíčD)*G + ) + ``` + + Transakce je platná, pokud posílá přesné částky na vnořené veřejné klíče. + V takovém případě není vyžadován žádný podpis. V porovnání s CTV v taprootu + ušetří tato metoda kolem 16 vbytes. Zdá se, že v porovnání s CTV v holém + skriptu (tedy umístěným přímo ve výstupním skriptu) zabírá podobný prostor. + + Pokud se CTV použije v taprootu, může být poskytnut alternativní způsob platby + v podobě platby klíčem (keypath spend), na kterém se shodnou všechny zúčastněné + strany. Díky tomu mohou účastníci změnit příjemce prostředků. Rozrůstající se + klíče („exploding keys”) umožní dosáhnout téhož těmi, kdo kontrolují + KlíčB, KlíčC, KlíčD. Efektivita je v obou případech shodná. + + Dryja píše, že rozrůstající se klíče „nabízí základní funkcionalitu OP_CTV, + avšak umí ušetřit pár bajtů dat witnessu. Samy o sobě asi nevypadají tak působivě, + ale chtěl jsem to zveřejnit, protože by to mohl být užitečný základ pro + složitější konstrukce kovenantů.” + +- **Analýza kontraktového protokolu pomocí Alloy:** Dmitry Petukhov + zaslal do fóra Delving Bitcoin [příspěvek][petukhov alloy] se + [specifikací][petukhov spec] jednoduché úschovny založené na `OP_CAT` + (viz [zpravodaj č. 291][news291 catvault]). Pro specifikaci použil jazyk + [Alloy][]. Petukhov díky Alloy [nalezl][petukhov mods] několik užitečných + modifikací a důležitých omezení, která by měl mít každý implementující na vědomí. + Všem zájemcům o formální modelování kontraktových protokolů doporučujeme + přečtení jeho příspěvku a důkladně dokumentované specifikace. + +- **Zatčení bitcoinových vývojářů:** jak bylo široce reportováno jinde, dva vývojáři + bitcoinové peněženky Samourai nabízející funkce pro zlepšení soukromí byli minulý týden + zatčeni v souvislosti se svým software. Zatčení byla provedna na základě + obvinění amerických orgánů činných v trestním řízení. Dvě další firmy nato + oznámily záměr ukončit kvůli právním rizikům nabídku svých služeb americkým zákazníkům. + + Optech se specializuje na psaní o bitcoinových technologiích, přenecháme tedy + informování o této právní situaci jiným publikacím. Avšak vyzýváme všechny, + kteří mají zájem na úspěchu bitcoinu, obzvláště pokud sídlí v USA nebo mají vazby + na tamní lidi, aby si zjistili podrobnosti a v případě možnosti zvážili podporu. + +- **Setkání CoreDev.tech v Berlíně:** množství přispěvatelů Bitcoin Core se minulý měsíc + osobně sešlo v Berlíně v rámci pravidelného setkání [CoreDev.tech][]. Účastníci poskytli + [přepisy][coredev xs] některých sezení. Prezentace, revize kódu, pracovní + skupiny a další sezení se mimo jiné zabývaly těmito tématy: + + - nálezy bádání ASMap + - připravenost assumeUTXO na mainnetu + - BTC Lisp + - CMake + - cluster mempool + - výběr mincí + - agregace podpisů napříč vstupy (cross-input signature aggregation) + - současný spam v síti + - odhad poplatků + - obecná diskuze o BIP + - velké pročištění konsenzu + - diskuze o GUI + - odstranění zastaralé peněženky + - libbitcoinkernel + - MuSig2 + - monitorování P2P + - revize přeposílání balíčků + - odesílání soukromých transakcí + - revize současných tiketů na GitHubu + - revize současných PR na GitHubu + - signet/testnet4 + - tiché platby + - poskytování šablon se Stratum v2 + - warnet + - slabé bloky + + +## 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.* + +- [Bitcoin Inquisition 25.2][] je nejnovějším vydáním tohoto experimentálního + plného uzlu navrženého na [signetové][topic signet] testování změn protokolu. + Poslední verze přidává podporu pro [OP_CAT][topic op_cat] na signetu. + +- [LND v0.18.0-beta.rc1][] je kandidátem na vydání příští hlavní verze tohoto + oblíbeného LN uzlu. + +## Významné změny kódu a dokumentace + +_Významné změny z tohoto týdne v [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Bitcoin Inquisition][bitcoin inquisition repo] a [repozitáři BINANA][binana +repo]._ + +- [Bitcoin Core #27679][] umožňuje, aby byly notifikace posílané pomocí + [ZMQ][] přeposílány na unixový soket. To bylo dříve (zřejmě neúmyslně) + podporováno předáním konfigurační volby nedokumentovaným způsobem. + [Bitcoin Core #22087][] zpřísnil parsování této volby, čímž v Bitcoin Core + 27.0 změnil nedokumentované chování. Tato změna [postihla LND][gugger zmq] + a možná i jiné programy. Toto PR přináší pro volbu oficiální podporu a + drobně mění její sémantiku, aby byla konzistentní s dalšími podobnými + volbami v Bitcoin Core, viz například změny popsané ve [zpravodaji č. 294][news294 + sockets]. + +- [Core Lightning #7240][] přidává podporu pro stahování potřebných bloků + z bitcoinové P2P sítě, pokud je místní ořezaný bitcoinový uzel odstranil. + Pokud CLN takový blok potřebuje, zavolá `getblockfrompeer`, aby uzel tento blok + stáhl od svého spojení. Po přijetí bloku jej Bitcoin Core autentizuje + propojením s hlavičkou, kterou ukládá i během ořezávání. Dále blok + uloží a tím ho zpřístupní standardními RPC voláními. + +- [Eclair #2851][] začíná vyžadovat Bitcoin Core 26.1 či novější a odstraňuje + kód pro financování s nepotvrzenými předky. Po upgradu bude využívat + funkci Bitcoin Core, která je navržena, aby kompenzovala jakýkoliv _schodek + poplatku_ (viz [zpravodaj č. 269][news269 fee deficit]). + +- [LND #8147][], [#8422][lnd #8422], [#8423][lnd #8423], [#8148][lnd + #8148], [#8667][lnd #8667] a [#8674][lnd #8674] nahrazují starý sweeper + (nástroj pro „zametení” UTXO zpět do vlastní peněženky, zejména po vynuceném + zavření kanálu) novou implementací, která umožňuje zveřejnění urovnávajících + transakcí i jakýchkoliv dalších, které jsou potřebné pro efektivní navyšování + jejích poplatků. Nová implementace akceptuje většinu parametrů staré, + jako je například časová lhůta, do které musí být transakce potvrzena, + a počáteční poplatek. Nová implementace dále přidává volbu `budget`, která + stanovuje maximální částku použitelnou na poplatky. Nová implementace + umožňuje podrobnější nastavení, usnadňuje psaní testů, umí používat + navyšování poplatků dle [CPFP][topic cpfp] i [RBF][topic rbf] (každý + podle situace), lépe dávkuje navyšování poplatků a aktualizuje + poplatky každý blok namísto každých 30 sekund. + +- [LND #8627][] nově ve výchozím nastavení odmítá uživatelem vyžádané změny + nastavení kanálu, které vyžadují kladný _příchozí poplatek za přeposílání._ + Například si představme, že Alice chce Carol přeposlat platbu přes Boba. + Ve výchozím nastavení již Bob nemůže použít nově přidanou funkci pro + příchozí poplatky za přeposílání (viz [zpravodaj č. 297][news297 inbound]), + aby od Alice obdržel poplatek navíc. Toto nové výchozí chování zajišťuje, + aby zůstal Bobův uzel kompatibilní s uzly, které příchozí poplatky + nepodporují (což jsou v současnosti téměř všechny LN uzly). Bob může + přestat být zpětně kompatibilní překrytím výchozího chování pomocí + konfiguračního nastavení `accept-positive-inbound-fees`. Jinou možností, + jak může Bob dosáhnout požadovaného výsledku a zůstat zpětně kompatibilní, + je zvýšit odchozí poplatek za přeposlání Carol a poté pomocí záporného + příchozího poplatku nabídnout slevu na platby nepocházející od Alice. + +- [Libsecp256k1 #1058][] mění algoritmus používaný pro generování veřejných + klíčů a podpisů. Starý i nový algoritmus běží v konstantním čase, aby zabránily + vytváření příležitostí pro časované útoky [postranním kanálem][topic side channels]. + Výkonnostní testy ukazují, že nový algoritmus je zhruba o 12 % rychlejší. + Jeden z účastníků PR review popsal fungování nového algoritmu ve svém [blogovém + příspěvku][stratospher comb]. + +- [BIPs #1382][] přiřazuje návrhu na [přeposílání balíčku předků][topic package relay] + číslo [BIP331][]. + +- [BIPs #1068][] zaměňuje pořadí dvou parametrů ve verzi 1 opakovaně použitelných + platebních kódů ([BIP47][]), aby odpovídaly implementaci v peněžence + Samourai. Dále jsou k BIPu přidány odkazy na informace o dalších verzích. + Poznamenáváme, že původní implementace BIP47 v Samourai se objevila před lety + a toto PR bylo otevřeno přes tři roky. Začleněno bylo minulý týden. + +{% assign day_after_posting = page.date | date: "%s" | plus: 86400 | date: "%Y-%m-%d 14:30" %} +{% include snippets/recap-ad.md when=day_after_posting %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="27679,7240,2851,22087,8147,8422,8423,8148,8667,8627,1058,1382,1068,8674" %} +[gugger zmq]: https://github.com/lightningnetwork/lnd/pull/8664#issuecomment-2065802617 +[news269 fee deficit]: /cs/newsletters/2023/09/20/#bitcoin-core-26152 +[news 297 inbound]: /cs/newsletters/2024/04/10/#lnd-6703 +[stratospher comb]: https://github.com/stratospher/blogosphere/blob/main/sdmc.md +[petukhov alloy]: https://delvingbitcoin.org/t/analyzing-simple-vault-covenant-with-alloy/819 +[petukhov mods]: https://delvingbitcoin.org/t/basic-vault-prototype-using-op-cat/576/16 +[petukhov spec]: https://gist.github.com/dgpv/514134c9727653b64d675d7513f983dd +[alloy]: https://en.wikipedia.org/wiki/Alloy_(specification_language) +[dryja exploding]: https://delvingbitcoin.org/t/exploding-keys-covenant-construction/832 +[zmq]: https://en.wikipedia.org/wiki/ZeroMQ +[news291 catvault]: /cs/newsletters/2024/02/28/#prototyp-jednoduche-uschovny-pouzivajici-op-cat +[news297 inbound]: /cs/newsletters/2024/04/10/#lnd-6703 +[coredev.tech]: https://coredev.tech/ +[coredev xs]: https://btctranscripts.com/bitcoin-core-dev-tech/2024-04/ +[news294 sockets]: /cs/newsletters/2024/03/20/#bitcoin-core-27375 +[bitcoin inquisition 25.2]: https://github.com/bitcoin-inquisition/bitcoin/releases/tag/v25.2-inq +[lnd v0.18.0-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.18.0-beta.rc1 diff --git a/_posts/cs/newsletters/2024-05-08-newsletter.md b/_posts/cs/newsletters/2024-05-08-newsletter.md new file mode 100644 index 0000000000..f9fdd20d20 --- /dev/null +++ b/_posts/cs/newsletters/2024-05-08-newsletter.md @@ -0,0 +1,305 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 301' +permalink: /cs/newsletters/2024/05/08/ +name: 2024-05-08-newsletter-cs +slug: 2024-05-08-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Zpravodaj tento týden popisuje nápad na zabezpečení transakcí Lamportovými +podpisy bez nutnosti měnit konsenzus. Též nechybí naše pravidelné rubriky se +souhrnem sezení Bitcoin Core PR Review Clubu, oznámeními nových vydání +a popisem významných změn v populárním bitcoinovém páteřním software. + +## Novinky + +- **Lamportovy podpisy postavené nad ECDSA podpisy, vynucované konsenzem:** + Ethan Heilman zaslal do emailové skupiny Bitcoin-Dev [příspěvek][heilman lamport] s popisem + metody, jak může být po transakci vyžadován [Lamportův podpis][lamport signature], aby byla + validní. Díky tomu by mohly být P2SH a P2WSH výstupy [kvantově odolné][topic quantum resistance], + což dle Andrew Poelstry [znamená][poelstra lamport1], „že jediným zbývajícím důvodem, proč bitcoin nemá + kovenanty, jsou prostorová omezení.” Níže uvádíme shrnutí protokolu, ale pro + zachování jednoduchosti a snadné pochopitelnosti vynecháme upozornění na nebezpečná + místa. Prosíme, neimplementujte nic na základě tohoto popisu. + + Lamportův veřejný klíč obsahuje dva seznamy hašovacích otisků. Lamportův + podpis obsahuje předobrazy vybraných otisků. Program sdílený podepisovací + i ověřovací funkcí interpretuje, které předobrazy jsou odhaleny, jako instrukce. + Například Bob chce ověřit, že Alice podepsala číslo mezi 0 a 31 (v binární + soustavě číslo mezi 00000 a 11111). Alice vytvoří Lamportův soukromý klíč + ze dvou seznamů náhodných čísel: + + ```text + private_zeroes = [random(), random(), random(), random(), random()] + priavte_ones = [random(), random(), random(), random(), random()] + ``` + + Každé z těchto čísel zahašuje, čímž vytvoří veřejný Lamportův klíč: + + ```text + public_zeroes = [hash(private_zeroes[0]), ..., hash(private_zeroes[4])] + public_ones = [hash(private_ones[0]), ..., hash(private_ones[4])] + ``` + + Svůj veřejný klíč poskytne Bobovi. Nato chce ověřitelným způsobem Bobovi sdělit + číslo 21. Zašle následující předobrazy: + + ```text + private_ones[0] + private_zeroes[1] + private_ones[2] + private_zeroes[3] + private_ones[4] + ``` + + Ty odpovídají binárnímu číslu 10101. Bob ověří, že každý z předobrazů odpovídá + veřejnému klíči, který předtím obdržel. To ho ujistí, že zprávu „21“ mohla + vygenerovat pouze Alice, která zná předobrazy. + + Bitcoin kóduje ECDSA podpisy [DER standardem][der encoding], který v obou dvou komponentách podpisu + vynechává úvodní nulové bajty (0x00). U náhodných hodnot se nulový bajt objeví + v každém 256. případě. Bitcoinové podpisy se tedy přirozeně liší ve velikosti. + Tato variabilita je umocněna tím, že úvodní bajt hodnot R je nulový v polovině + případů (viz [low-r grinding][topic low-r grinding]), ale v teoretické úrovni lze + dosáhnout zmenšení transakce o jeden bajt v jednom z 256 případů. + + I kdyby rychlý kvantový počítač umožnil útočníkovi vytvořit podpis bez předchozí + znalosti soukromého klíče, ECDSA podpisy v DER kódování by nadále měly proměnlivou + délku a musely by být zavázány transakcím, které je obsahují, a tyto transakce + by i nadále musely obsahovat dodatečná data potřebná k její validaci, jako jsou + předobrazy hašů. + + Díky tomuto schématu může P2SH redeem skript obsahovat kontrolu ECDSA podpisu, + který bude zavazovat transakci a Lamportově podpisu, který sám bude zavázán skutečné + velikosti ECDSA podpisu. Například: + + ```text + OP_DUP OP_CHECKSIGVERIFY OP_SIZE OP_EQUAL + OP_IF + # Nyní víme, že velikost je bajtů + OP_SHA256 OP_CHECKEQUALVERIFY + OP_ELSE + # Nyní víme, že velikost není bajtů + OP_SHA256 OP_CHECKEQUALVERIFY + OP_ENDIF + ``` + + Aby mohl být tento fragment úspěšně vykonán, musí plátce poskytnout + ECDSA podpis. Ten je poté duplikován a ověřen; pokud se jedná o neplatný + podpis, skript skončí neúspěchem. V době pokvantové by mohl útočník tímto + testem projít a pokračovat ve validaci skriptu. Dále je změřena velikost + podpisu. Pokud se rovná `` bajtům, musí plátce odhalit předobraz + otisku ``. Tato velikost `` může být nastavena na hodnotu + o jeden bajt menší, než je běžné, což se přirozeně stane u jednoho z 256 + podpisů. V opačném, běžném případě nebo v případě větších podpisů musí + plátce odhalit předobraz pro otisk ``. Skript selže, pokud není + poskytnut správný předobraz. + + Ani pokud by bylo ECDSA zcela prolomeno, nemohl by útočník prostředky + utratit, pokud by neznal Lamportův soukromý klíč. Samo o sobě to není příliš + zajímavé, P2SH i P2WSH tuto základní vlastnost, kdy jsou jejich předobrazy + (skripty) drženy v tajnosti, [již mají][news141 key hiding]. Avšak po zveřejnění + Lamportova podpisu by útočník, který by jej chtěl znovu použít s padělaným + ECDSA podpisem, musel zajistit stejnou délku ECDSA podpisu, jako má podpis + původní. To může po útočníkovi vyžadovat hledání vyhovujícího podpisu, + které čestný uživatel provádět nemusí (tomuto hledání se říká „grinding” + čili „obrušování”). + + Jak dlouho musí útočník obrušovat podpisy lze exponenciálně zvýšit přidáním + dalších párů ECDSA a Lamportových podpisů. Jelikož se ECDSA podpisy liší ve + velikosti přirozeně jednou v 256 případech, abychom dosáhli praktické + bezpečnosti, museli bychom poskytnout velmi vysoký počet podpisů. + Heilman [popisuje][heilman lamport2] mnohem efektivnější mechanismus. + S jeho použitím je sice stále překročen limit velikosti P2SH daný konsenzem, + avšak věříme, že by to mohlo fungovat s vyššími limity P2WSH. + + Dále by útočník s rychlým kvantovým počítačem nebo dostatečně výkonným + klasickým počítačem mohl nalézt krátký ECDSA nonce, který by mu umožnil + snadno okrást kohokoliv, kdo takto krátký nonce neočekával. Minimální velikost + nonce je známa, tomuto útoku se tedy lze vyhnout, avšak soukromá část nonce + známa není, proto by každý, kdo se snaží tomuto útoku zabránit, nemohl + utratit své bitcoiny, dokud se nevynalezne rychlý kvantový počítač. + + Tato verifikace Lamportova podpisu je v praxi podobná navrhovanému opkódu + [OP_CHECKSIGFROMSTACK][topic op_checksigfromstack]. V obou případech jsou + ověřovaná data – veřejný klíč a podpis – umístěna do zásobníku a operace + skončí úspěchem, pokud podpis odpovídá veřejnému klíči a zároveň zavazuje + položkám v zásobníku. Andrew Poelstra [popsal][poelstra lamport2], jak + by tento mechanismus mohl být v kombinaci s operacemi ve stylu [BitVM][topic acc] + použit k vytváření [kovenantů][topic covenants]. Varuje však, že téměř + jistě by byl přesažen alespoň jeden limit velikosti vynucovaný konsenzem. + +## 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í.* + +[Indexuj TxOrphanage hodnotou wtxid, umožni položky se stejným txid][review club +30000] je PR od Glorie Zhao (glozow na GitHubu), které umožňuje, aby skupina transakcí +se stejným `txid` mohla být naráz umístěna v `TxOrphanage` (objekt držící osiřelé transakce, +je tedy nazýván sirotčincem) tím, že používá pro indexaci `wtxid` namísto `txid`. + +Díky tomuto PR je příležitostné [přijetí balíčku][topic package relay] s jedním rodičem +a jedním potomkem (1-parent-1-child, 1p1c) představené v [Bitcoin Core #28970][] +robustnější. + +{% include functions/details-list.md + q0="Proč bychom měli umožnit současnou existenci více transakcí se + stejným txid v TxOrphanage? Jakým situacím to má zabránit?" + a0="Dle definice nemohou být witness data transakce bez rodičů + validována, protože rodičovská transakce není známa. Když je + přijato více transakcí s odlišnými wtxid, ale stejnými txid, + je tedy nemožné vědět, která verze je ta správná. Tím, že umožníme + jejich paralelní existenci uvnitř TxOrphanage, nemůže útočník + poslat nesprávnou, upravenou verzi, která by zabránila přijetí + správné verze." + a0link="https://bitcoincore.reviews/30000#l-11" + + q1="Jaké jsou příklady osiřelých transakcí se stejným txid, ale odlišným witnessem?" + a1="Taková transakce může obsahovat nevalidní podpis (a tím být celá nevalidní) + nebo větší witness (stejný poplatek, a tedy nižší jednotkový poplatek)." + a1link="https://bitcoincore.reviews/30000#l-67" + + q2="Uvažujme, co nastane, pokud bychom umožnili pouze jeden záznam na txid. + Co se stane, pokud nám zákeřné spojení pošle upravenou verzi osiřelé + transakce, která nemá rodiče s nízkým jednotkovým poplatkem? + Co se musí stát, aby byl tento potomek přijat do mempoolu? Existuje + více odpovědí." + a2="Pokud je upravený potomek v sirotčinci a obdržíme validního rodiče + s nenízkým jednotkovým poplatkem, rodič bude do mempoolu přijat + a upravený potomek bude zneplatněn a ze sirotčince odstraněn." + a2link="https://bitcoincore.reviews/30000#l-52" + + q3="Uvažujme, co se stane, pokud máme balíček s jedním rodičem a jedním + potomkem (1p1c), kde rodič má nízký jednotkový poplatek a musí být + doprovázen svým potomkem. Co se musí stát, abychom do mempoolu správně + přijali tento balíček rodiče s potomkem?" + a3="Jelikož má rodič nízký jednotkový poplatek, nebude sám o sobě do mempoolu + přijat. Nicméně po [Bitcoin Core #28970][] může být příležitostně přijat + jako 1p1c balíček, pokud je potomek v sirotčinci. Pokud je osiřelý + potomek pozměněn, rodič je z mempoolu vyloučen a sirotek odstraněn + ze sirotčince." + a3link="https://bitcoincore.reviews/30000#l-60" + + q4="Namísto držení více transakcí se stejným txid (kde očividně plýtváme + prostorem na verzi, kterou neakceptujeme), měli bychom umožnit, aby + transakce nahradila existující položku v sirotčinci? Jaké by byly + požadavky?" + a4="Zdá se, že neexistuje dobrá metrika, která by rozhodovala o nahrazení + existující transakce. Jedním možným směrem je nahrazovat duplikované + transakce pouze přicházející od stejného spojení." + a4link="https://bitcoincore.reviews/30000#l-80" +%} + +## 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.* + +- [Libsecp256k1 v0.5.0][] je vydáním této knihovny pro provádění kryptografických + operací. Zrychluje generování klíčů a podepisování (viz [minulé číslo + zpravodaje][news300 secp]) a snižuje velikost zkompilované verze, „což bude zvláště + výhodné pro vestavěná zařízení.“ Dále přidává funkci pro řazení veřejných klíčů. + +- [LND v0.18.0-beta.rc1][] je kandidátem na vydání příští hlavní verze tohoto + oblíbeného LN uzlu. + +## Významné změny kódu a dokumentace + +_Významné změny z tohoto týdne v [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Bitcoin Inquisition][bitcoin inquisition repo] a [repozitáři BINANA][binana +repo]._ + +- [Bitcoin Core #28970][] a [#30012][bitcoin core #30012] přidávají podporu + pro omezenou formu [přeposílání balíčku][topic package relay] sestávajícího + se z jednoho rodiče a jednoho potomka (1p1c), která nevyžaduje žádné změny + P2P protokolu. Představme si, že má Alice rodičovskou transakci pod úrovní + [BIP133][] poplatkových filtrů všech svých spojení. Ví, že by transakci + žádné její spojení nepřijalo, nebude se tedy snažit o její odeslání. + Dále má potomka, který platí dostatečný poplatek za sebe i za rodiče. + Alice a její spojení provedou následující proces: + + - Alice odešle potomka svému spojení. + + - Její spojení si uvědomí, že nezná rodiče transakce, uloží tedy transakci + do _sirotčince_. Všechny verze Bitcoin Core z poslední dekády obsahují + sirotčinec, do kterého dočasně ukládají omezený počet transakcí, které + jsou přijaty dříve než její rodiče. Tím se napraví situace, kdy v P2P + síti někdy přicházejí transakce v zaměněném pořadí. + + - Po několika okamžicích odešle Alice rodičovskou transakci. + + - Před tímto PR by si uzel všiml, že jednotkový poplatek rodiče + je příliš nízký a transakci by nepřijal. Dále by ze sirotčince + odstranil potomka, neboť už poznal jeho rodiče. Po tomto PR + si uzel všimne, že již má potomka tohoto rodiče v sirotčinci a + vyhodnotí jejich poplatky dohromady. Pokud je tento poplatek + nad prahem (a pokud jsou obě transakce jinak v souladu s pravidly + uzlu), jsou obě transakce přijaty do mempoolu. + + Je známo, že útočník může tento mechanismus narušit. Sirotčinec v Bitcoin + Core je kruhový buffer, do kterého může položky přidat kterékoliv spojení. + Útočník, který chce oběti zabránit v přeposlání tohoto druhu balíčku, + tak musí zaplavit spojení mnoha osiřelými transakcemi. To může potenciálně + vést k vyloučení platícího potomka ještě před přijetím rodiče. [Následné PR][bitcoin + core #27742] může poskytnout každému spojení exkluzivní přístup do části + sirotčince, čímž by byl tento problém eliminován. Pro jiné, související + PR viz rubriku _Bitcoin PR Review Club_ v tomto čísle zpravodaje. Další + vylepšení vyžadující změny P2P protokolu jsou popsány v [BIP331][]. + +- [Bitcoin Core #28016][] se nejprve dotáže všech seedových uzlů před tím, + než odešle dotazy DNS seedům. Uživatelé mohou nastavit seznam seedových uzlů + i DNS seedů. Seedový uzel je běžný bitcoinový plný uzel. Bitcoin Core + k němu může otevřít TCP spojení, vyžádat si seznam adres potenciálních + dalších spojení a odpojit se. DNS seed vrací IP adresy potenciálních + spojení přes DNS. Díky tomu může tato informace putovat (a být dočasně + uložena) DNS sítí, takže vlastník serveru DNS seedu se nedozví, která + IP adresa si informaci vyžádala. Ve výchozím nastavení se Bitcoin Core + pokouší vytvořit spojení s IP adresami, které již zná. Pokud žádný pokus + není úspěšný, dotáže se DNS seedů. Pokud není žádný DNS seed dosažitelný, + kontaktuje množinu napevno zakódovaných seedových uzlů. Uživatelé mají + možnost poskytnout vlastní seznam seedových uzlů. + + Pokud uživatel před tímto PR nastavil vlastní seznam seedových uzlů + a zároveň ponechal ve výchozím nastavení používání DNS seedů, obě skupiny + byly kontaktovány najednou a adresy toho rychlejšího v odpovědích + dominovaly. Jelikož má DNS nižší požadavky a odpovědi jsou často kešovány + blízkým serverem, DNS zvítězilo téměř vždy. Po tomto PR mají seedové + uzly přednost; pokud uživatel sám nastavil volbu `seednode`, zřejmě preferuje + její výsledky. + +- [Bitcoin Core #29623][] lépe varuje uživatele, + pokud se jeho lokální čas jeví být více než deset minut mimo oproti + času jeho spojení. Uzel se špatným časem může dočasně odmítat validní + bloky, což může potenciálně vést k vážným bezpečnostním problémům. + Tato změna následuje po odstranění síťově upraveného času z kódu konsenzu + (viz [zpravodaj č. 288][news288 time]). + +## Korekce + +Ukázkový skript ověření Lamportova podpisu původně používal `OP_CHECKSIG`, +avšak byl po publikaci nahrazen opkódem `OP_CHECKSIGVERIFY`. Děkujeme +Antoineovi Poinsotovi za upozornění na naši chybu. + +{% assign day_after_posting = page.date | date: "%s" | plus: 86400 | date: "%Y-%m-%d 14:30" %} +{% include snippets/recap-ad.md when=day_after_posting %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="30012,28016,29623,27742,28970" %} +[lnd v0.18.0-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.18.0-beta.rc1 +[libsecp256k1 v0.5.0]: https://github.com/bitcoin-core/secp256k1/releases/tag/v0.5.0 +[heilman lamport]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAEM=y+XyW8wNOekw13C5jDMzQ-dOJpQrBC+qR8-uDot25tM=XA@mail.gmail.com/ +[lamport signature]: https://en.wikipedia.org/wiki/Lamport_signature +[poelstra lamport1]: https://mailing-list.bitcoindevs.xyz/bitcoindev/ZjD-dMMGxoGNgzIg@camus/ +[der encoding]: https://en.wikipedia.org/wiki/X.690#DER_encoding +[heilman lamport2]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CAEM=y+UnxB2vKQpJAa-z-qGZQfpR1ZeW3UyuFFZ6_WTWFYGfjw@mail.gmail.com/ +[poelstra lamport2]: https://gnusha.org/pi/bitcoindev/Zjo72iTDYjwwsXW3@camus/T/#m9c4d5836e54ed241c887bcbf3892f800b9659ee2 +[news300 secp]: /cs/newsletters/2024/05/01/#libsecp256k1-1058 +[news288 time]: /cs/newsletters/2024/02/07/#bitcoin-core-28956 +[news141 key hiding]: /en/newsletters/2021/03/24/#p2pkh-hides-keys +[review club 30000]: https://bitcoincore.reviews/30000 diff --git a/_posts/cs/newsletters/2024-05-15-newsletter.md b/_posts/cs/newsletters/2024-05-15-newsletter.md new file mode 100644 index 0000000000..64e4cc1465 --- /dev/null +++ b/_posts/cs/newsletters/2024-05-15-newsletter.md @@ -0,0 +1,188 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 302' +permalink: /cs/newsletters/2024/05/15/ +name: 2024-05-15-newsletter-cs +slug: 2024-05-15-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Zpravodaj tento týden oznamuje vydání beta verze plného uzlu s podporou +utreexo a shrnuje dvě navrhovaná rozšíření BIP119 `OP_CHECKTEMPLATEVERIFY`. +Též nechybí naše pravidelné rubriky s oznámeními nových vydání a popisem +významných změn v populárním bitcoinovém páteřním software. + +## Novinky + +- **Vydání beta verze utreexod:** Calvin Kim zaslal do emailové skupiny + Bitcoin-Dev [příspěvek][kim utreexo] s oznámením vydání beta verze + utreexod, plného uzlu s podporou [utreexo][topic utreexo]. Utreexo + umožňuje uzlu namísto kompletní množiny UTXO ukládat pouze malé + závazky (commitmenty) jejího stavu. Závazek může mít pouhých 32 bajtů, + což jej činí při současné velikosti plné množiny kolem 12 GB řádově + miliardkrát menším. Za účelem snížení používání přenosového pásma + může utreexo ukládat další dodatečné commitmenty; zvýší se sice + používání diskového prostoru, ale bude i přesto řádově milionkrát nižší + než u tradičních plných uzlů. Utreexový uzel, který navíc ořezává + staré bloky, může být provozován s malým konstantním diskovým prostorem. + To je výhodné v porovnání s běžným ořezaným plným uzlem, který může + vyžadovat prostor větší, než je disková kapacita zařízení. + + Kimovy poznámky k vydání naznačují, že uzel je kompatibilní s peněženkami + založenými na [BDK][bdk repo] a mnoha dalšími, které podporují + [Electrum personal server][]. Uzel podporuje přeposílání transakcí + díky rozšíření P2P protokolu, které umožňuje přeposílání utreexo + důkazů. Podporovány jsou _běžné_ i _přemosťovací_ utreexo uzly; běžné utreexo + uzly používají utreexo commitmenty za účelem šetření diskovým prostorem, + přemosťovací uzly ukládají kompletní stav UTXO s dodatečnými daty + a jsou schopné připojit utreexo důkazy k blokům a transakcím, které + byly vytvořené uzly bez podpory utreexo. + + Utreexo nevyžaduje změnu konsenzu a utreexo uzly nekolidují s uzly + bez utreexo podpory, avšak běžné utreexo uzly se mohou spojit pouze + s jinými utreexo uzly, běžnými či přemosťovacími. + + Kim ke svému oznámení připojuje několik varování: „kód ani protokol + neprošly důkladnou revizí, […] přijdou změny bez zpětné kompatibility + […] a utreexod je založen na [btcd][], které může být nekompatibilní + s konsenzem.” + +- **Rozšířený BIP119 s menšími hašemi a závazky libovolným datům:** + Jeremy Rubin zaslal do emailové skupiny Bitcoin-Dev [příspěvek][rubin + bip119e] s [návrhem BIPu][bip119e] rozšiřujícího navrhovaný opkód + [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] (`OP_CTV`) dvěma + novými možnostmi: + + - *Podpora pro hašovací funkci HASH160:* jedná se o haše používané pro + P2PKH, P2SH a P2WPKH adresy. Mají 20 bajtů narozdíl od 32bajtových hašů + používaných v návrhu [BIP119][]. V naivních protokolech s více stranami + může být [útok hledáním kolize][collision attack] na 20bajtové haše proveden + zhruba s 280 operacemi hrubé síly, což je v dosahu vysoce + motivovaného útočníka. Z tohoto důvodu moderní bitcoinové opkódy + obvykle používají 32bajtové haše. Avšak zabezpečení protokolů s jedním + účastníkem nebo dobře navržených protokolů s více stranami používajících + 20bajtové haše může být navýšeno tak, že jeho kompromitace v méně + než 2160 operacích je nepravděpodobná. Díky tomu mohou + protokoly vyžadovat o 12 bajtů na haš méně. Jedním příkladem, kde to + může být přínosné, je implementace protokolu [eltoo][topic eltoo] + (viz [zpravodaj č. 284][news284 eltoo]). + + - *Podpora pro více druhů commitmentů:* `OP_CTV` skončí úspěšně, je-li + spuštěn v transakci, jejíž vstupy a výstupy jsou zahašovány do stejných + hodnot jako poskytnuté otisky. Jedním z těchto výstupů by mohl být + `OP_RETURN`, který zavazuje nějakým datům, která chce autor skriptu + publikovat na blockchainu, například data nezbytná pro obnovení LN + kanálu ze zálohy. Avšak umístit tato data ve witnessu by bylo výrazně + levnější. Navržená rozšířená forma `OP_CTV`umožňuje autorovi skriptu + požadovat, aby byla během hašování vstupů a výstupů použita i část dat + ze zásobníku witnessu. Tato data budou porovnána s otiskem poskytnutým + autorem skriptu. Díky tomu budou mít data publikovaná v blockchainu + minimální váhu. + + Návrh neobdržel v době psaní tohoto čísla žádné reakce. + +## 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.* + +- [LDK v0.0.123][] je vydáním této knihovny pro budování LN aplikací. + Obsahuje aktualizaci nastavení [ořezaných HTLC][topic trimmed htlc], + vylepšení podpory [nabídek][topic offers] a další. + +- [LND v0.18.0-beta.rc2][] je kandidátem na vydání příští hlavní verze + tohoto oblíbeného LN uzlu. + +## Významné změny kódu a dokumentace + +_Významné změny z tohoto týdne v [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Bitcoin Inquisition][bitcoin inquisition repo] a [repozitáři BINANA][binana +repo]._ + +- [Bitcoin Core #29845][] mění v několika RPC voláních typu `get*info` pole + `warnings`. Namísto jednoduchého řetězce nově obsahuje pole řetězců, aby + mohlo vrátit více než jedno varování. + +- [Core Lightning #7111][] zpřístupňuje pluginům RPC příkaz `check`. Možnosti + příkazu byly dále rozšířeny o `check setconfig`, které kontroluje platnost + konfiguračních voleb, a `check keysend` zjišťující, zda by hsmd danou + transakci schválilo. Byla přidána předinicializační zpráva s přednastavenými + vývojovými HSM příznaky. O příkazu `check` jsme se též zmiňovali ve zpravodajích + [č. 25][news25 cln check] a [č. 47][news47 cln check] (oba _angl._). + +- [Libsecp256k1 #1518][] přidává funkci `secp256k1_pubkey_sort`, která kanonicky + seřadí množinu veřejných klíčů. To je užitečné pro [MuSig2][topic musig], [tiché + platby][topic silent payments] a zřejmě i mnoho dalších protokolů používajících + více klíčů. + +- [Rust Bitcoin #2707][] upravuje API pro tagované haše představené jako součást + [taprootu][topic taproot] tím, že ve výchozím stavu očekává otisky v _interním + pořadí bajtů_. Dříve API očekávalo haše v _pořadí bajtů pro zobrazování_, které + lze nově vyžádat atributem `#[hash_newtype(backward)]`. Z [historických důvodů][mb3e + byte order] jsou haše použité jako txid a identifikátory bloků uložené v transakcích + a blocích v jednom pořadí bajtů (interní), ale zobrazovány jsou v opačném pořadí + (pořad pro zobrazování). Toto PR se snaží zabránit, aby i další haše měly + v různých případech různá pořadí bajtů. + +- [BIPs #1389][] přidává [BIP388][], které popisuje „pravidla peněženek pro deskriptorové + peněženky.” Jedná se o sadu šablon [deskriptorů výstupních skriptů][topic descriptors], + které mohou širokému spektru peněženek usnadnit jejich podporu v kódu a + uživatelském rozhraní. Deskriptory mohou být náročné na implementaci v hardwarových + peněženkách s omezenými zdroji a zobrazovacím prostorem. Pravidla dle BIP388 + umožní software i hardware přijmout zjednodušující předpoklady o tom, + jak budou deskriptory používány. Dosáhnou tak redukce potřebného kódu a množství + detailů, které musí uživatelé ověřit. Software, který vyžaduje kompletní + podporu deskriptorů, je může nadále používat nezávisle na BIP388. Další + podrobnosti přinesl [zpravodaj č. 200][news200 policies]. + +- [BIPs #1567][] přidává [BIP387][] popisující nové deskriptory `multi_a()` a + `sortedmultia_a()`, které poskytují možnosti skriptovaných multisig operací + uvnitř [tapscriptu][topic tapscript]. BIP uvádí příklad fragmentu deskriptoru: + `multi_a(k,KEY_1,KEY_2,...,KEY_n)` vyprodukuje skript + `KEY_1 OP_CHECKSIG KEY_2 OP_CHECKSIGADD ... KEY_n OP_CHECKSIGADD OP_k + OP_NUMEQUAL`. Dále viz zpravodaje [č. 191][news191 multi_a] (_angl._), + [č, 227][news227 multi_a] a [č. 273][news273 multi_a]. + +- [BIPs #1525][] přidává [BIP347][], který navrhuje opkód [OP_CAT][topic op_cat]. + Tento opkód by mohl být v případě [aktivace][topic soft fork activation] v soft forku + používán v [tapscriptech][topic tapscript]. Dále viz zpravodaje [č, 274][news274 op_cat], + [č. 275][news275 op_cat] a [č. 293][news293 op_cat]. + +## Změna času publikace zpravodaje + +V následujících týdnech bude Optech experimentovat s alternativním časem publikování. +Nebuďte prosím překvapeni, pokud obdržíte zpravodaj o několik dní dříve či později. +Během krátké doby věnované experimentu budou zpravodaje zaslané emailem obsahovat trasovací +kód, který nám pomůže určit jeho čtenost. Sledování můžete zabránit předchozím zákazem načítání +externích zdrojů. Pokud vyžadujete více soukromí, doporučujeme odebírat náš [RSS feed][] +přes dočasné Tor spojení. Za jakékoliv nesnáze se omlouváme. + +{% assign day_after_posting = page.date | date: "%s" | plus: 86400 | date: "%Y-%m-%d 14:30" %} +{% include snippets/recap-ad.md when=day_after_posting %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="1525,1567,1389,2707,1518,7111,29845" %} +[lnd v0.18.0-beta.rc2]: https://github.com/lightningnetwork/lnd/releases/tag/v0.18.0-beta.rc2 +[mb3e byte order]: https://github.com/bitcoinbook/bitcoinbook/blob/6d1c26e1640ae32b28389d5ae4caf1214c2be7db/ch06_transactions.adoc#internal_and_display_order +[news200 policies]: /cs/newsletters/2022/05/18/#prizpusobeni-miniscriptu-miniscript-a-deskriptoru-descriptors-podpisovym-zarizenim-signingdevices +[news191 multi_a]: /en/newsletters/2022/03/16/#bitcoin-core-24043 +[news227 multi_a]: /cs/newsletters/2022/11/23/#jak-mohu-vytvorit-taprootovou-adresu-s-vicenasobnym-podpisem +[news273 multi_a]: /cs/newsletters/2023/10/18/#bitcoin-core-27255 +[news274 op_cat]: /cs/newsletters/2023/10/25/#navrh-bipu-pro-op-cat +[news275 op_cat]: /cs/newsletters/2023/11/01/#navrh-na-op-cat +[news293 op_cat]: /cs/newsletters/2024/03/13/#bitcoin-core-pr-review-club +[kim utreexo]: https://mailing-list.bitcoindevs.xyz/bitcoindev/d5f47120-3397-4f56-93ca-dd310d845f3cn@googlegroups.com/T/#u +[electrum personal server]: https://github.com/chris-belcher/electrum-personal-server +[btcd]: https://github.com/btcsuite/btcd +[rubin bip119e]: https://mailing-list.bitcoindevs.xyz/bitcoindev/35cba1cd-eb67-48d1-9615-e36f2e78d051n@googlegroups.com/T/#u +[bip119e]: https://github.com/bitcoin/bips/pull/1587 +[news284 eltoo]: /cs/newsletters/2024/01/10/#ctv +[collision attack]: https://cs.wikipedia.org/wiki/%C3%9Atok_nalezen%C3%ADm_kolize +[rss feed]: /feed.xml +[ldk v0.0.123]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.0.123 +[news25 cln check]: /en/newsletters/2018/12/11/#c-lightning-2123 +[news47 cln check]: /en/newsletters/2019/05/21/#c-lightning-2631 diff --git a/_posts/cs/newsletters/2024-05-17-newsletter.md b/_posts/cs/newsletters/2024-05-17-newsletter.md new file mode 100644 index 0000000000..35032925ab --- /dev/null +++ b/_posts/cs/newsletters/2024-05-17-newsletter.md @@ -0,0 +1,180 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 303' +permalink: /cs/newsletters/2024/05/17/ +name: 2024-05-17-newsletter-cs +slug: 2024-05-17-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Zpravodaj tento týden představuje nové schéma pro anonymní tokeny užívání, které +by mohly být použity pro oznamování LN kanálů a v několika dalších koordinačních +protokolech odolných vůči sybilím útokům, odkazuje na diskuzi o novém schématu +rozdělování BIP39 vět seedu, oznamuje alternativu k BitVM pro ověřování úspěšného +spuštění libovolných programů v interaktivních kontraktových protokolech +a sdílí návrhy na aktualizaci procesu tvorby BIPů. + +## Novinky + +- **Anonymní tokeny užívání:** Adam Gibson zaslal do fóra Delving Bitcoin + [příspěvek][gibson autct] o schématu, které vyvinul a které umožní komukoliv, + kdo je schopen [utratit klíčem][topic taproot] nějaké UTXO, aby prokázal možnost + utratit jej bez nutnosti konkrétní UTXO odhalit. Tato práce navazuje na Gibsonův + předchozí vývoj [PoDLE][news85 podle], mechanismu proti sybilímu útoku (je + používán v implementaci [coinjoinu][topic coinjoin] Joinmarket), a [RIDDLE][news205 riddle]. + + Jednou možností použití, kterou popisuje, je oznamování LN kanálů. Každý LN + uzel oznamuje ostatním uzlům své kanály, aby mohly nalézt cesty sítí pro platby. + Část těchto informací o kanálu je uložena v paměti a oznámení jsou často + posílána opakovaně, aby bylo zajištěno, že dosáhnou co největšího počtu uzlů. + Byl-li by útočník schopen levně produkovat oznámení o falešných kanálech, + narušoval by tím hledání cest a plýtval by významným množstvím paměti a přenosového + pásma čestných uzlů. LN uzly se proti tomu brání tím, že akceptují pouze oznámení + podepsaná klíčem, který patří validnímu UTXO. To po vlastnících kanálu požaduje, + aby identifikovali konkrétní UTXO, které spolu vlastní. Kvůli tomu lze + asociovat prostředky kanálu s jinými minulými i budoucími onchain transakcemi, + které vytvoří (nebo někdo může kvůli tomu vytvořit nepřesné asociace). + + Gibsonovo schéma, nazývané anonymní tokeny užívání se stromy křivek + (anonymous usage tokens with curve trees, autct), umožňuje spoluvlastníkům + kanálu podepsat zprávu, aniž by museli odhalit své UTXO. Útočník bez UTXO + by nemohl takový validní podpis vytvořit. Útočník, který UTXO má k dispozici, + by validní podpis vytvořit mohl, avšak musel by v něm držet tolik prostředků, + kolik by uzel musel držet v kanálu. To omezuje dopady útoku v nejhorším možném + případě. [Zpravodaj č. 261][news261 lngossip] obsahuje předchozí diskuzi + o přerušení vztahu mezi [oznámeními kanálu][topic channel announcements] + a konkrétními UTXO. + + Gibson dále popisuje několik dalších možných způsobů použití autct. Základní + mechanismus pro podobný druh soukromí – kruhové podpisy (ring signatures) – + je známý již dlouho. Avšak Gibson používá nový kryptografický konstrukt + ([curve trees][], stromy křivek), díky kterému jsou důkazy kompaktnější + a rychlejší na ověření. Každý důkaz skrytě zavazuje použitému klíči, + jediné UTXO tedy nemůže vytvořit neomezený počet validních podpisů. + + Vedle [kódu][autct repo] zveřejnil Gibson také [fórum][hodlboard] jako + ověření konceptu, které pro zaregistrování vyžaduje poskytnutí autct + důkazu. Výsledkem je prostředí, kde je o každém účastníkovi známo, + že vlastní bitcoiny, ale nikdo nemusí poskytnout žádné další informace + o sobě či svých bitcoinech. + +- **Dělení BIP39 vět seedu:** Rama Gan zaslal do emailové skupiny + Bitcoin-Dev odkaz na [sadu nástrojů][penlock website] pro generování + a dělení [BIP39][] vět seedu bez nutnosti používání jakýchkoliv + elektronických výpočetních zařízení (kromě tisku instrukcí a šablon). + Podobá se schématu [codex32][topic codex32], ale pracuje s BIP39, + které jsou kompatibilní s téměř všemi současnými hardwarovými + podpisovými zařízeními a mnoha softwarovými peněženkami. + + Andrew Poelstra, spoluautor codex32, poskytl v [odpovědi][poelstra penlock1] + několik komentářů a návrhů. Bez vyzkoušení obou schémat (každé + by zabralo několik hodin) nám není přesně známo, kde každé z nich + učinilo kompromisy. Avšak zdá se, že obě dvě v základu nabízejí shodné + možnosti: instrukce pro bezpečné offline generování seedu, možnost + rozdělit seed do několika částí pomocí [Shamirova sdílení tajných dat][sss], + schopnost spojit části do původního seedu a schopnost ověřit kontrolní + součty jednotlivých částí i původního seedu, čímž může uživatel odhalit + poškození dat dostatečně brzy na to, aby původní data mohl stále obnovit. + +- **Alternativa k BitVM:** Sergio Demian Lerner se spoluautory zaslali + do emailové skupiny Bitcoin-Dev [příspěvek][lerner bitvmx] o nové + virtuální procesorové architektuře částečně založené na myšlenkách + stojících za [BitVM][topic acc]. Cílem jejich projektu nazvaného + BitVMX je efektivně vytvářet doklady o řádném provedení nějakého + programu, který může být zkompilován pro běh na běžné procesorové + architektuře, jako je [RISC-V][]. Podobně jako BitVM nevyžaduje ani + BitVMX změny konsenzu, ale potřebuje, aby se jedna či více určených + stran ujaly role důvěryhodného ověřovatele. Znamená to, že skupina uživatelů, + kteří se interaktivně účastní protokolu, může zabránit jednomu (či více) + z účastníků ve výběru peněz z kontraktu, dokud tento účastník úspěšně + nespustí libovolný program specifikovaný tímto kontraktem. + + Lerner odkazuje na [článek][bitvmx paper] o BitVMX, který jej porovnává + s původním BitVM (viz [zpravodaj č. 273][news273 bitvm]) a (i přes nedostupné + podrobnosti) k následným projektům původních vývojářů BitVM. Doprovodná + [webová stránka][bitvmx website] poskytuje dodatečné informace v méně + technické podobě. + +- **Diskuze o změnách BIP2 pokračuje:** Mark „Murch” Erhardt + [pokračuje][erhardt bip2] v emailové skupině Bitcoin-Dev v diskuzi + o změnách [BIP2][], což je dokument, který popisuje proces navrhování + a schvalování BIP, návrhů na zlepšení bitcoinu. Jeho email popisuje + několik problémů, navrhuje řešení mnoha z nich a žádá o poskytnutí + zpětné vazby. [Zpravodaj č. 297][news297 bip2] popisuje předchozí + diskuzi o změnách BIP2. + +## 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.18.0-beta.rc2][] je kandidátem na vydání příští hlavní verze + tohoto oblíbeného LN uzlu. + +## Významné změny kódu a dokumentace + +_Významné změny z tohoto týdne v [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Bitcoin Inquisition][bitcoin inquisition repo] a [repozitáři BINANA][binana +repo]._ + +- [Core Lightning #7190][] přidává do výpočtu hodnoty časového zámku [HTLC][topic htlc] + dodatečný offset (nazývaný `chainlag`). To umožní HTLC cílit aktuální výšku bloku namísto + výšky, kterou uzel naposledy zpracoval. Díky tomu mohou být platby bezpečné + i během synchronizace blockchainu. + +- [LDK #2973][] přidává do `OnionMessenger`u podporu pro zachycování [onion zpráv][topic + onion messages] určených pro offline uzly. Generuje události při zachycení zprávy a když + je spojení opět online. Uživatelé by měli udržovat seznam spojení, pro která se budou + zprávy ukládat. Jedná se o další krok v podpoře [asynchronních plateb][topic async payments] + pomocí `held_htlc_available` ([BOLTs #989][]). Například Alice chce Carol + poslat peníze přes Boba, ale Alice neví, zda je Carol online. Alice pošle Bobovi + onion zprávu, Bob zprávu drží, dokud není Carol online. Nato Carol zprávu otevře + a na základě ní pošle Alici (či jejímu poskytovateli služeb) žádost o platbu. + Nakonec Alice Carol zaplatí běžným způsobem. + +- [LDK #2907][] rozšiřuje metodu zpracovávající `OnionMessage` o volitelný parametr + `Responder` a mění její návratový typ na `ResponseInstructions`, který udává, jak + má být s odpovědí na zprávu naloženo. Tato změna umožní asynchronní odpovědi + na onion zprávy a otevírá dveře komplexnějším mechanismům odpovědí, jakou jsou + ty potřebné pro [asynchronní platby][topic async payments]. + +- [BDK #1403][] upravuje modul `bdk_electrum` tak, aby používal nové sync/full-scan + struktury představené v [BDK #1413][], dotazovatelné spojové seznamy `CheckPoint`ů + ([BDK #1369][]) a snadno klonovatelné transakce zapouzdřené v `Arc` ([BDK #1373][]). + Tato změna zvyšuje efektivitu skenování transakcí během používání podobných serverů, jako + je Electrum. Dále nově umožňuje načíst předchozí výstupy, což umožní výpočet poplatků + transakcí přijatých z externí peněženky. + + - [BIPs #1458][] přidává [BIP352][], který navrhuje [tiché platby][topic silent + payments], protokol pro znovupoužitelné adresy generující při každém použití onchain + unikátní adresu. Návrh BIPu byl poprvé diskutován ve [zpravodaji č. 255][news255 bip352]. + +{% assign day_after_posting = page.date | date: "%s" | plus: 86400 | date: "%Y-%m-%d 14:30" %} +{% include snippets/recap-ad.md when="2024-05-21 14:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="7190,2973,2907,1403,1458,989,1413,1369,1373" %} +[lnd v0.18.0-beta.rc2]: https://github.com/lightningnetwork/lnd/releases/tag/v0.18.0-beta.rc2 +[gibson autct]: https://delvingbitcoin.org/t/anonymous-usage-tokens-from-curve-trees-or-autct/862/ +[news261 lngossip]: /cs/newsletters/2023/07/26/#aktualizovana-oznameni-o-kanalech +[news205 riddle]: /cs/newsletters/2022/06/22/#riddle-novy-system-proti-sybil-utokum +[news85 podle]: /en/newsletters/2020/02/19/#using-podle-in-ln +[curve trees]: https://eprint.iacr.org/2022/756 +[autct repo]: https://github.com/AdamISZ/aut-ct +[hodlboard]: https://hodlboard.org/ +[gan penlock]: https://mailing-list.bitcoindevs.xyz/bitcoindev/9bt6npqSdpuYOcaDySZDvBOwXVq_v70FBnIseMT6AXNZ4V9HylyubEaGU0S8K5TMckXTcUqQIv-FN-QLIZjj8hJbzfB9ja9S8gxKTaQ2FfM=@proton.me/ +[penlock website]: https://beta.penlock.io/ +[poelstra penlock1]: https://mailing-list.bitcoindevs.xyz/bitcoindev/ZkIYXs7PgbjazVFk@camus/ +[sss]: https://cs.wikipedia.org/wiki/%C5%A0amirovo_sd%C3%ADlen%C3%AD_tajemstv%C3%AD +[lerner bitvmx]: https://mailing-list.bitcoindevs.xyz/bitcoindev/5189939b-baaf-4366-92a7-3f3334a742fdn@googlegroups.com/ +[risc-v]: https://cs.wikipedia.org/wiki/RISC-V +[bitvmx paper]: https://bitvmx.org/files/bitvmx-whitepaper.pdf +[news273 bitvm]: /cs/newsletters/2023/10/18/#platby-podminene-libovolnym-vypoctem +[bitvmx website]: https://bitvmx.org/ +[erhardt bip2]: https://mailing-list.bitcoindevs.xyz/bitcoindev/0bc47189-f9a6-400b-823c-442974c848d5@murch.one/ +[news297 bip2]: /cs/newsletters/2024/04/10/#aktualizace-bip2 +[news255 bip352]: /cs/newsletters/2023/06/14/#navrh-bip-na-tiche-platby diff --git a/_posts/cs/newsletters/2024-05-24-newsletter.md b/_posts/cs/newsletters/2024-05-24-newsletter.md new file mode 100644 index 0000000000..4256ba225c --- /dev/null +++ b/_posts/cs/newsletters/2024-05-24-newsletter.md @@ -0,0 +1,342 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 304' +permalink: /cs/newsletters/2024/05/24/ +name: 2024-05-24-newsletter-cs +slug: 2024-05-24-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Zpravodaj tento týden shrnuje analýzu několika návrhů na upgradování +LN kanálů bez nutnosti je zavřít a znovu otevřít, diskutuje obtíže +v zajištění korektních výplat odměn těžařům v poolech, odkazuje na +diskuzi o bezpečném používání PSBT pro tiché platby, oznamuje návrh +BIPu pro miniscript a shrnuje návrh na využívání časté změny zůstatku +LN kanálu k simulaci kontraktů s cenovými futures. Též nechybí naše +pravidelné rubriky se souhrnem změn ve službách a klientech, oznámeními +nových vydání a souhrnem významných změn v populárním bitcoinovém +páteřním software. + +## Novinky + +- **Upgradování existujících LN kanálů:** Carla Kirk-Cohen zaslala do + fóra Delving Bitcoin [příspěvek][kc upchan], ve kterém shrnuje a + analyzuje současné návrhy na upgradování existujících LN kanálů. + Upgrade slouží k přidání podpory nových funkcí. Zkoumá řadu rozličných + případů, např: + + - *Změny parametrů:* v současnosti jsou některá nastavení kanálu dojednána + mezi stranami a nemohou být později změněna. Změna parametrů by umožňovala + případné nové vyjednávání o nastavení, například by mohly uzly chtít + změnit množství satoshi, při kterém začnou [ořezávat HTLC][topic trimmed htlc], + nebo výši rezerv kanálu, kterou od protistrany očekávají jako pojistku + proti jeho zavření ve starém stavu. + + - *Změny commitmentů:* _commitment transakce_ v LN umožňují, aby jednotlivec + mohl poslat současný stav kanálu do blockchainu. Změny commitmentů by umožnily + kanálům založeným na P2WSH přepnout na [anchor výstupy][topic anchor outputs] + a [v3 transakce][topic v3 transaction relay] a [jednoduchým taprootovým kanálům][topic + simple taproot channels] na [PTLC][topic ptlc]. + + - *Obměna financování:* LN kanály jsou v blockchainu ukotvené ve _financující + transakci_, jejíž výstup je offchain opakovaně utrácen jako commitment + transakce. Původně používaly všechny financující transakce P2WSH výstup, + avšak novější možnosti jako [PTLC][topic ptlc] vyžadují P2TR výstupy. + + Kirk-Cohen srovnává předchozí tři návrhy upgradování kanálů: + + - *Dynamické commitmenty:* jak popisuje [návrh specifikace][BOLTs #1117], + umožňují změnit téměř všechny parametry kanálu a navíc poskytují + všeobecný způsob upgradování financování a commitment transakcí + díky nové „kickoff” transakci. + + - *Upgrade po splicu:* tato myšlenka umožňuje, aby [splicingová transakce][topic + splicing], která již nezbytně aktualizuje onchain financování kanálu, + mohla též změnit typ použitého financování a volitelně formát commitment + transakce. Přímo se netýká změn parametrů kanálu. + + - *Upgrade při opakovaném navázání spojení:* jak popisuje [návrh + specifikace][bolts #868], tento způsob umožňuje změnit několik parametrů + kanálu během opakovaného navázání spojení mezi dvěma uzly. Přímo se netýká + financování a upgradu commitment transakce. + + Kirk-Cohen dále v tabulce porovnává všechny možnosti: vypisuje jejich onchain + náklady, výhody a nevýhody. Též je porovnává s onchain náklady v případě, + pokud žádný upgrade nenastane. Mezi jejími závěry nechybí: „Myslím, že má + smysl začít pracovat na upgradování parametrů i commitmentů pomocí + [dynamických commitmentů][bolts #1117], bez ohledu na naši volbu způsobu + upgradování na taprootové kanály. To nám dává možnost upgradovat na + `option_zero_fee_htlc_tx` anchor kanály a poskytnout mechanismus + upgradování formátů commitmentů, který může být použit pro V3 kanály + (jakmile budou specifikovány).” + +- **Obtíže s odměňováním těžařů v poolech:** Ethan Tuttle zaslal do fóra Delving + Bitcoin [příspěvek][tuttle poolcash] s návrhem, aby mohly [těžební pooly][topic + pooled mining] odměňovat těžaře [ecashovými][topic ecash] tokeny poměrně + k počtu vytěžených share. Těžaři by hned nato mohli tokeny prodat či + přeposlat nebo by mohli počkat, až pool vytěží blok, načež by pool směnil + tokeny za satoshi. + + Mezi reakcemi nechyběla kritika i další návrhy. Obzvláště zajímavou jsme + shledali [reakci][corallo pooldelay] Matta Coralla, ve které popisuje + základní problém: neexistují standardizované platební metody implementované + velkými pooly, které by těžařům umožnily v krátkých intervalech spočítat své + odměny. Dva rozšířené způsoby výplat odměn jsou: + + - *Platba za share (PPS):* vyplácí těžařovi odměnu v poměru za množství + vykonané práce, i pokud není nalezen žádný blok. Spočítat poměrnou + výši odměny těžařovi za odměnu za vytěžený blok je snadné, avšak spočítat + ji za transakční poplatky je složitější. Corallo poznamenává, že většina + poolů používá průměr poplatků posbíraných během dne, ve kterém byl share + vytvořen. Znamená to, že výše odměny za share nemůže být ve stejný den + spočítána. Pooly mohou navíc průměrem poplatků různými způsoby manipulovat. + + - *Platba za posledních n share (PPLNS):* odměňuje těžaře za share nalezené + blízko okamžiku nalezení bloku. Avšak těžař si může být jist, že pool + nalezl blok, pouze, pokud jej nalezl tento těžař sám. Neexistuje způsob + (v krátkém časovém horizontu), kterým by mohl běžný těžař ověřit, že mu pool + vyplácí korektní odměny. + + Kvůli těmto chybějícím informacím nejsou těžaři schopni rychle přepínat mezi jednotlivými + pooly, pokud zjistí, že jejich hlavní pool je začíná na odměnách krátit. + [Stratum v2][topic pooled mining] řešení nenabízí, avšak čestné pooly mohou + použít standardizované zprávy k informování těžařů, že se chystají přestat + za share platit. Corallo dále odkazuje na [návrh][corallo sv2 proposal] + změny Stratum v2, která by těžařům umožnila ověřit, že za své share obdrželi + korektní odměny, což by alespoň těžařům poskytlo možnost po delší době + (hodiny až dny) odhalit, že je pool krátí na výplatách. + + V době psaní diskuze stále probíhala. + +- **Diskuze o PSBT pro tiché platby:** Josie Baker započal na fóru Delving Bitcoin + [diskuzi][baker psbtsp] o rozšíření [PSBT][topic psbt] pro [tiché platby][topic silent + payments] (SP) dle [návrhu specifikace][toth psbtsp] od Andrew Totha. + PSBT pro SP mají tato dvě hlediska: + + - **Platby na SP adresy:** výstupní skript transakce závisí zároveň na adrese + tiché platby a na vstupech transakce. Jakákoliv změna vstupů v PSBT + může potenciálně způsobit, že nebudou standardní peněženky schopné SP výstup + utratit. Je tedy nutná dodatečná validace PSBT. Některé druhy vstupů + nemohou být v SP používané, i toto musí být validováno. + + Pro vstupy, které použité být mohou, potřebuje mít SP logika přístup + k jejich soukromým klíčům, které však peněženka nemusí mít k dispozici, + jsou-li její klíče uložené v hardwarovém podpisovém zařízení. Baker + popisuje schéma, které by plátci umožnilo vytvořit SP výstupní skript bez + soukromého klíče, avšak hrozí s ním možnost úniku soukromého klíče, + implementace v hardwarových podpisových zařízeních se tedy zřejmě neuskuteční. + + - **Utracení dříve obdržených SP výstupů:** PSBT budou must obsahovat + sdílený tajný kód, který se používá k tweaknutí klíče pro utracení. + Může se jednat o nové PSBT pole. + + Diskuze v době psaní nadále probíhala. + +- **Návrh BIPu pro miniscript:** Ava Chow zaslala do emailové skupiny Bitcoin-dev + [příspěvek][chow miniscript] s [návrhem BIPu][chow bip] pro [miniscript][topic + miniscript], jazyk, který může být převeden do bitcoinového Scriptu, který ale + umožňuje kompozici, práci se šablonami a konečnou analýzu. Návrh BIPu je odvozen + z dlouhotrvající webové stránky miniscriptu a měl by odpovídat existujícím + implementacím miniscriptu pro P2WSH witness skripty i pro P2TR [tapscript][topic + tapscript]. + +- **Navázaná hodnota kanálu:** Tony Klausing zaslal do fóra Delving Bitcoin + [příspěvek][klausing stable] s návrhem a doprovodným [kódem][klausing code] + _stabilních kanálů_. Představme si, že Alice chce držet množství bitcoinů + odpovídající 1 000 dolarům. Bob je ochoten to garantovat, ať již z důvodu očekávání + nárůstu hodnoty BTC nebo protože mu Alice platí (nebo oboje). Otevřou spolu LN + kanál a každou minutu provedou následující operace: + + - Oba zkontrolují stejné zdroje kurzu mezi BTC a USD. + + - Zvýší-li se hodnota BTC, Alice sníží svůj bitcoinový zůstatek, dokud + není roven 1 000 dolarům (nadbytek pošle Bobovi). + + - Sníží-li se hodnota BTC, Bob pošle Alici dostatečné množství BTC, + dokud není její zůstatek opět roven 1 000 dolarům. + + Cílem je, aby k aktualizacím zůstatků docházelo dostatečně často na to, + aby byla změna ceny pod náklady na uzavření kanálu znevýhodněnou stranou. + Tato strana by tak byla motivována, aby jednoduše zaplatila a pokračovala dále. + + Klausing se domnívá, že by někteří obchodníci mohli upřednostňovat tento vztah s + požadavkem na minimální důvěru před kustodiálním trhem s futures. Dále navrhuje, + že by mohl být používán jako základ pro banku, která vydává [ecash][topic ecash] + denominovaný v dolarech. Toto schéma by fungovalo s jakýmkoliv aktivem, pro nějž + by mohla být určena tržní cena. + +## Změny ve službách a klientech + +*V této měsíční rubrice upozorňujeme na zajímavé aktualizace bitcoinových +peněženek a služeb.* + +- **Zdroje k tichým platbám:** + Bylo ohlášeno několik nových zdrojů na téma [tiché platby][topic silent payments] včetně + informační webové stránky [silentpayments.xyz][sp website], [dvou][bi + ts sp] typescriptových [knihoven][bw ts sp], [backendu][gh blindbitd] založeného na Go, + [webové peněženky][gh silentium] a [dalších][sp website devs]. Doporučujeme opatrnost, neboť + většina tohoto software je nová, v beta verzi či v aktivním vývoji. + +- **Cake Wallet přidává tiché platby:** + [Cake Wallet][cake wallet website] nedávno [ohlásila][cake wallet + announcement], že její nejnovější beta verze podporuje tiché platby. + +- **Ověření konceptu coinjoinu bez koordinátora:** + [Emessbee][gh emessbee] je ověřením konceptu pro vytváření [coinjoinových][topic coinjoin] + transakcí bez ústředního koordinátora. + +- **OCEAN přidává podporu pro BOLT12:** + Těžební pool OCEAN používá jako součást svého řešení [výplat po LN][ocean docs] + [podepsané zprávy][topic generic signmessage] pro propojení bitcoinové adresy a + [BOLT12 nabídky][topic offers]. + +- **Coinbase přidává podporu pro Lightning:** + [Coinbase přidal][coinbase blog] podporu pro lightningové vklady a výběry za pomoci + lightningové infrastruktury od [Lightspark][lightspark website]. + +- **Ohlášeny nástroje pro bitcoinová svěřenectví:** + Tým [BitEscrow][bitescrow website] ohlásil sadu [vývojových nástrojů][bitescrow docs] + pro implementování nekustodiálních bitcoinových svěřenectví třetí stranou (escrow). + +- **Block žádá těžařskou komunitu o zpětnou vazbu:** + V [aktualizaci][block blog] o vývoji svého 3nm čipu vyzývá Block těžařskou komunitu + o poskytnutí zpětné vazby mimo jiné k funkcím software těžebního hardware a údržbě. + +- **Vydána peněženka Sentrum:** + [Sentrum][gh sentrum] je peněženka umožňující pouze sledování (watch-only), která podporuje + různé kanály pro notifikace. + +- **Stack Wallet přidává podporu pro FROST:** + [Stack Wallet v2.0.0][gh stack wallet] přidává podporu pro FROST, schéma [prahového][topic threshold signature] + vícenásobného elektronického podpisu, díky použití rustové knihovny Modular FROST. + +- **Ohlášen nástroj pro zveřejňování transakcí:** + [Pushtx][gh pushtx] je jednoduchý rustový program, který odesílá transakce přímo + do bitcoinové P2P sítě. + +## 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.* + +- [Bitcoin Inquisition 27.0][] je nejnovějším hlavním vydáním tohoto forku Bitcoin Core + navrženého pro testování soft forků a jiných významných změn protokolu na [signetu][topic + signet]. Novinkou tohoto vydání je vynucování [OP_CAT][] dle specifikace v [BIN24-1][] + a [BIP347][]. Dále byl přidán „do `bitcoin-util` nový příkaz `evalscript`, který může + otestovat chování opkódu skriptu.” Odstraněna byla podpora pro `annexdatacarrier` + a pseudo [dočasné anchory][topic ephemeral anchors] (viz zpravodaje [č. 244][news244 + annex] a [č. 248][news248 ephemeral]). + +- [LND v0.18.0-beta.rc2][] je kandidátem na vydání příští hlavní verze této populární + implementace LN uzlu. + +## Významné změny kódu a dokumentace + +_Významné změny z tohoto týdne v [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Bitcoin Inquisition][bitcoin inquisition repo] a [repozitáři BINANA][binana +repo]._ + +- [Bitcoin Core #27101][] přináší podporu pro požadavky a odpovědi dle JSON-RPC 2.0. + Server nově vždy vrátí HTTP 200 \"OK\", pokud nenastane chyba HTTP nebo není chybně formátovaný + požadavek. Vrací buď pole `error` nebo `result`, nikdy však oboje. Jediný i dávkovaný + požadavek používají stejný způsob nakládání s chybami. Není-li v těle požadavku specifikována + verze 2.0, bude použit stávající protokol JSON-RPC 1.1. + +- [Bitcoin Core #30000][] používá pro indexování záznamů v `TxOrphanage` `wtxid` + namísto `txid`, aby mohl obsahovat skupinu transakcí se stejným `txid`. + Sirotčinec (orphanage) je prostor s omezenou velikostí, který Bitcoin Core + používá k ukládání transakcí odkazující na rodičovské transakce, ke kterým + aktuálně nemá Bitcoin Core přístup. Přijme-li později odkazovanou rodičovskou transakci, + může tohoto potomka dále zpracovat. Příležitostné [přijetí balíčku][topic package relay] + s jedním rodičem a jedním potomkem (1p1c) pošle nejdříve potomka (v očekávání, že + bude uložen v sirotčinci) a nato pošle rodiče; díky tomu je možné zvážit jejich + poplatek dohromady. + + Avšak když byl kód příležitostného 1p1c začleněn (viz [zpravodaj č. 301][news301 bcc28970]), + bylo známo, že může útočník čestnému uživatelovi zabránit v používání této + možnosti tím, že zveřejní verzi potomka transakce s nevalidními daty ve witnessu. + Tento znetvořený potomek by měl stejné txid jako čestný potomek, ale neprošel + by po přijetí rodiče validací. Kvůli tomu by nemohl potomek přispět na poplatek + ([CPFP][topic cpfp]), který by byl nutný pro akceptování balíčku. + + Jelikož byly dříve transakce v sirotčinci indexovány pomocí txid, byla v sirotčinci + uložena první přijatá verze transakce s konkrétním txid. Útočník, který byl + schopen zveřejnit transakce rychleji a častěji než čestný uživatel, tak mohl čestného + uživatele donekonečna blokovat. Po této změně může být přijato více transakcí se + shodnými txid, které se však liší v obsahu witnessu a generují tak odlišná wtxid. + V okamžiku přijetí rodičovské transakce má uzel dostatek informací na odstranění + znetvořeného potomka a může tak akceptovat potomka validního. Toto PR bylo dříve + diskutováno v PR Review Clubu shrnutém ve [zpravodaji č. 301][news301 prclub]. + +- [Bitcoin Core #28233][] stavějící na [#17487][bitcoin core #17487] odstraňuje + každodenní periodické zapisování na disk a čistění mezipaměti horkých mincí (UTXO). + Před #17487 snižovalo časté zapisování na disk riziko, že by bylo po pádu uzlu či + hardwaru nutné podstoupit zdlouhavý process obnovy indexu. Po #17487 + mohou být nová UTXO zapsána na disk bez nutnosti vyprázdnění mezipaměti + (ta i nadále musí být vyprázdněna v případě nedostatku paměti). Horká + mezipaměť ve výchozím nastavení téměř zdvojnásobuje rychlost validace bloku, + vyšších rychlostí je možné dosáhnout alokováním dodatečné paměti. + +- [Core Lightning #7304][] přidává řešení pro situace, kdy `invoice_requests` nemůže + nalézt cestu k uzlu určenému v `reply_path`. Démon `connectd` otevře k dotyčnému uzlu + dočasné TCP/IP spojení a doručí [onion zprávu][topic onion messages] obsahující + fakturu. Tato změna navyšuje interoperabilitu s LDK a navíc umožňuje používat onion + zprávy i v situacích, kdy jsou podporovány pouze několika málo uzly (viz [zpravodaj č. 283][news283 + ldk2723]). + +- [Core Lightning #7063][] činí bezpečnostní multiplikátor poplatků dynamickým, aby lépe + odrážel předpokládané nárůsty poplatků. Multiplikátor se snaží zajistit, aby transakce + platily dostatečně vysoké poplatky na dosažení včasné konfirmace, ať napřímo (u transakcí, + jejichž poplatky nemohou být navýšeny později) či pomocí navyšování poplatků. Multiplikátor + nyní začíná na dvojnásobku aktuálního [odhadu][topic fee estimation] v době nízkých poplatků + (1 sat/vbyte) a s poplatky blížícími se k `maxfeerate` se postupně snižuje až na 1,1násobek. + +- [Rust Bitcoin #2740][] přidává do modulu `pow` funkci `from_next_work_required`, která z předaného + `CompactTarget` (předchozí cíl složitosti), `timespan` (časový rozdíl mezi aktuálním a předchozími + bloky) a `Params` (parametry sítě) vypočítá nový `CompactTarget` představující příští cíl složitosti. + Algoritmus implementovaný touto funkcí je založen `pow.cpp` z Bitcoin Core. + +{% assign day_after_posting = page.date | date: "%s" | plus: 86400 | date: "%Y-%m-%d 14:30" %} +{% include snippets/recap-ad.md when="2024-05-27 14:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="27101,30000,28233,7304,7063,2740,1117,868,17487" %} +[lnd v0.18.0-beta.rc2]: https://github.com/lightningnetwork/lnd/releases/tag/v0.18.0-beta.rc2 +[kc upchan]: https://delvingbitcoin.org/t/upgrading-existing-lightning-channels/881 +[tuttle poolcash]: https://delvingbitcoin.org/t/ecash-tides-using-cashu-and-stratum-v2/870 +[corallo pooldelay]: https://delvingbitcoin.org/t/ecash-tides-using-cashu-and-stratum-v2/870/14 +[corallo sv2 proposal]: https://github.com/stratum-mining/sv2-spec/discussions/76#discussioncomment-9472619 +[baker psbtsp]: https://delvingbitcoin.org/t/bip352-psbt-support/877 +[toth psbtsp]: https://gist.github.com/andrewtoth/dc26f683010cd53aca8e477504c49260 +[chow miniscript]: https://mailing-list.bitcoindevs.xyz/bitcoindev/0be34bd2-637b-44b1-a0d5-e0ad5812d505@achow101.com/ +[chow bip]: https://github.com/achow101/bips/blob/miniscript/bip-miniscript.md +[klausing stable]: https://delvingbitcoin.org/t/stable-channels-peer-to-peer-dollar-balances-on-lightning/875 +[klausing code]: https://github.com/toneloc/stable-channels/ +[news244 annex]: /cs/newsletters/2023/03/29/#bitcoin-inquisition-22 +[news248 ephemeral]: /cs/newsletters/2023/04/26/#bitcoin-inquisition-23 +[Bitcoin Inquisition 27.0]: https://github.com/bitcoin-inquisition/bitcoin/releases/tag/v27.0-inq +[news301 prclub]: /cs/newsletters/2024/05/08/#bitcoin-core-pr-review-club +[news301 bcc28970]: /cs/newsletters/2024/05/08/#bitcoin-core-28970 +[news283 ldk2723]: /cs/newsletters/2024/01/03/#ldk-2723 +[sp website]: https://silentpayments.xyz/ +[bi ts sp]: https://github.com/Bitshala-Incubator/silent-pay +[bw ts sp]: https://github.com/BlueWallet/SilentPayments +[gh blindbitd]: https://github.com/setavenger/blindbitd +[gh silentium]: https://github.com/louisinger/silentium +[sp website devs]: https://silentpayments.xyz/docs/developers/ +[cake wallet website]: https://cakewallet.com/ +[cake wallet announcement]: https://twitter.com/cakewallet/status/1791500775262437396 +[gh emessbee]: https://github.com/supertestnet/coinjoin-workshop +[coinbase blog]: https://www.coinbase.com/blog/coinbase-integrates-bitcoins-lightning-network-in-partnership-with +[lightspark website]: https://www.lightspark.com/ +[block blog]: https://www.mining.build/latest-updates-3nm-system/ +[gh sentrum]: https://github.com/sommerfelddev/sentrum +[ocean docs]: https://ocean.xyz/docs/lightning +[bitescrow website]: https://www.bitescrow.app/ +[bitescrow docs]: https://www.bitescrow.app/dev +[gh stack wallet]: https://github.com/cypherstack/stack_wallet/releases/tag/build_222 +[gh pushtx]: https://github.com/alfred-hodler/pushtx diff --git a/_posts/cs/newsletters/2024-05-31-newsletter.md b/_posts/cs/newsletters/2024-05-31-newsletter.md new file mode 100644 index 0000000000..c6db54d860 --- /dev/null +++ b/_posts/cs/newsletters/2024-05-31-newsletter.md @@ -0,0 +1,219 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 305' +permalink: /cs/newsletters/2024/05/31/ +name: 2024-05-31-newsletter-cs +slug: 2024-05-31-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Zpravodaj tento týden popisuje návrh protokolu pro používání tichých plateb +lehkými klienty, shrnuje návrhy dvou deskriptorů pro taproot a odkazuje +na diskuzi o tom, zda by měly být soft forkem přidávány opkódy s překrývajícími +se schopnostmi. Též nechybí naše pravidelné rubriky s populárními otázkami +a odpověďmi z Bitcoin Stack Exchange, oznámeními nových vydání a souhrnem +významných změn v populárním bitcoinovém páteřním software. + +## Novinky + +- **Protokol pro tiché platby v lehkých klientech:** Setor Blagogee + zaslal do fóra Delving Bitcoin [příspěvek][blagogee lcsp] s popisem návrhu + specifikace protokolu, který by umožnil lehkým klientům přijímat + [tiché platby][topic silent payments] (SP). Přidání několika kryptografických + primitiv postačuje k rozšíření možností peněženek o odesílání SP, ale + kromě těchto primitiv vyžaduje přijímání SP přístup k informacím o každé + onchain transakci kompatibilní s SP. Pro plné uzly jako Bitcoin Core je to + snadný úkol, neboť již zpracovávají každou onchain transakci, avšak na lehké + klienty, které se snaží minimalizovat množství vyžadovaných dat, to klade nové požadavky. + + V základním protokolu generuje nějaký poskytovatel služby pro každý blok + index veřejných klíčů, které mohou být použity s tichými platbami. Klient + tento index stáhne spolu s [kompaktními filtry bloků][topic compact block filters] + stejného bloku. Klient pro každý z klíčů (nebo sadu klíčů) spočítá svůj tweak + a určí, zda filtr bloků obsahuje platbu na korespondující tweaknutý klíč. + Pokud ano, klient stáhne dodatečná data, která mu umožní určit výši přijaté + částky a později tuto platbu utratit. + +- **Nezpracované taprootové deskriptory:** Oghenovo Usiwoma zaslal do fóra Delving Bitcoin + [příspěvek][usiwoma descriptors] s návrhem dvou nových [deskriptorů][topic + descriptors] pro konstruování [taprootových][topic taproot] platebních podmínek: + + - `rawnode()` obsahuje haš uzlu Merkleova stromu, ať již vnitřního uzlu + či listu. To umožní peněžence či jinému skenovacímu programu nalézt konkrétní + výstupní skripty bez nutnosti přesně znát, jaké tapscripty obsahují. Ve většině + případů se nejedná o bezpečný způsob přijímání peněz (neznámý skript může + být neutratitelný nebo může umožnit třetí straně prostředky utratit), avšak + mohou existovat protokoly, kde je takové použití bezpečné. + + Anthony Towns poskytl [příklad][towns descriptors], ve kterém Alice chce, + aby mohl Bob zdědit její peníze. Za své učiněné platby poskytne Alice Bobovi pouze + nezpracované haše uzlů. Pro Bobovo dědictví poskytne Alice Bobovi šablonu + deskriptoru (obsahující například časový zámek, aby nemohl Bob prostředky utratit + před vypršením nějaké doby). Tento způsob je pro Boba bezpečný, neboť peníze + nejsou jeho, a je výhodný pro Alicino soukromí, neboť nemusí Bobovi dopředu odhalit + žádnou ze svých platebních podmínek (ačkoliv se o nich může Bob dozvědět z Aliciných + onchain transakcí). + + - `rawleaf( diff --git a/en/scaling/fee-bumping/img/mempool.png b/en/scaling/fee-bumping/img/mempool.png deleted file mode 100644 index 84ec6b400b..0000000000 Binary files a/en/scaling/fee-bumping/img/mempool.png and /dev/null differ diff --git a/en/scaling/fee-bumping/index.md b/en/scaling/fee-bumping/index.md deleted file mode 100644 index 2190588071..0000000000 --- a/en/scaling/fee-bumping/index.md +++ /dev/null @@ -1,394 +0,0 @@ ---- -title: Introduction to fee bumping -layout: chapter ---- -The fee market in Bitcoin can be very dynamic, with the fee-rate required for a -transaction to be included in a block increasing or decreasing rapidly. - -{% assign label="Six months of mempool size, grouped by fee-rate, from https://jochen-hoenicke.de/queue/#1,24h" %} -{:.center} -![{{label}}](./img/mempool.png)
-*({{label}})* - -One of the reasons for the volatility in the fee-rate is that the mechanism -used to select what to include in a block is a market. In this market, the -miners supply 4Mweight of block space every ~10 minutes and users bid (through -transaction fees) to have their transaction included in a block. Different -wallets’ fee estimation algorithms are often naive and users are sometimes -insensitive to high fee-rates, which means that when the mempool grows to more -than a few megabytes and expected confirmation times start rising, a rapidly -escalating bidding war can ensue, with wallets attaching extremely high fees to -transactions. - -This market has one strange quirk: if a user’s bid is unsuccessful and the -transaction isn’t included in a block, _the bid is not withdrawn_, and is still -valid for the next block. This is because transactions have an invariant -property that once they’re valid for inclusion in a block, then they will be -valid for inclusion in any subsequent block. In fact, the only way to -invalidate an already valid transaction (and thereby ‘withdraw’ that -transaction’s bid for block inclusion) is to spend its inputs in a conflicting -transaction. - -This quirk generally isn’t a problem for users, since if a user signs a -transaction and they’re happy for it to be confirmed now, then presumably -they’d be happy for it to be confirmed at some point in the future for that -same fee-rate. However, there is one scenario in which the inability to -withdraw a transaction from the mempool can become a serious problem for users: -when the user has not attached a high enough fee-rate for the transaction to be -confirmed in a block, and the user has an urgent need for the transaction to be -confirmed. This could happen for many reasons: the wallet or user has -underestimated how much fee is required, the user has tried to save fees by -bidding at the low end of the fee estimation range, or the required fee rate -has just spiked unexpectedly after the transaction was broadcast. Whatever the -reason, the user finds himself with a transaction that is ‘stranded’ in the -mempool with a low fee rate, and a very low chance of being confirmed in future -blocks. - -The risk of having a transaction getting stuck impedes on users’ leeway to -make low bids on transaction fees. If there is no way to get a transaction -unstuck after it’s been broadcast, then users are forced to bid conservatively -(high) to avoid the risk of having their transaction get stuck. - -We therefore need a method to bump up the fee on an already broadcast -transaction for a couple of reasons: - -1. To allow users to ‘unstick’ an already broadcast transaction. -1. To give users the leeway to bid low on transaction fee-rate, with the - option to later bump the fee up. - -## The solutions - -There are two common solutions for unsticking a payment that is stranded in the -mempool: Replace-by-fee (RBF) and Child Pays for Parent (CPFP): - -### Replace By Fee (RBF) - -The user constructs and signs a replacement transaction which spends one or -more of the same inputs as the stuck transaction but pays additional fee -(usually by reducing the amount of bitcoin for the change output and leaving -the extra value as additional fee). If the replacement transaction attaches -enough fee, then miners will be incentivized to include it in a block. - -### Child Pays For Parent (CPFP)  - -The user creates a new transaction which spends one or more of the outputs of -the stuck transaction. This child transaction attaches a large fee - enough to -increase the combined fee-rate for itself and the stuck transaction above the -required fee-rate for inclusion in a block. Note that this is only possible -when the user owns some of the outputs - -When selecting transactions for inclusion in a block, miners will consider -‘packages’ of transactions, and will look at the total fee-rate across the -entire package of ancestors and descendants. The miner is incentivized to do -this to maximize the total fee yield from the block. - -This feature could rightly be called Descendants-Pay-For-Ancestors since a -rational miner will try to maximize their fee by considering packages of -transactions greater than 2 deep. For example, the Bitcoin Core mining code -considers packages of up to 25 transactions in any length of chain. - -## User experience considerations - -Fee bumping strategy has a very visible impact on user experience of a Bitcoin -wallet or service. Bitcoin services need to consider issues such as: - -- Having no fee bumping strategy at all can lead to very poor user experience in - cases where mempool fee-rates spike and a transaction becomes stuck - indefinitely. -- Some services offer Service Level Agreements that guarantee confirmations - within a certain number of blocks or within a certain time period. Failing to - meet those SLAs leads to customer complaints and tickets. (Whether such SLAs - are realistic or desirable is outside the scope of this document!) -- Some Bitcoin wallets and services treat transactions that signal - opt-in RBF differently from those that don’t (for example not showing RBF - transactions in a user’s balance). This can be confusing for users sending from - wallets that signal opt-in RBF. -- Fee bumping with RBF creates a new transaction with a new txid. This can be - confusing for users if they don’t understand that a payment’s txid/vout index - will change when the transaction is RBF’ed. -- Fee bumping with RBF invalidates the signatures in the original transaction - and requires all signers to re-sign. This is especially problematic for - multisig transactions or where signing is done on a dedicated hardware wallet - or HSM. -- By definition, fee bumping increases the fee attached to a transaction. For - CPFP especially, the new fee can be significantly higher. Accounting for that - fee and who pays it (the user or the service provider) can be difficult. - -These issues will be discussed in more detail in later sections of this -document. - -## Considerations for high volume users - -There are additional considerations for entities that make heavy use of the -Bitcoin blockchain, such as exchanges or custodians: - -- Services have a certain number of UTXOs in their hot wallet. If all of those - UTXOs are tied up in stuck transactions, and the service’s wallet doesn’t use - unconfirmed UTXOs as inputs, then they can run out of UTXOs for new - transactions. -- Using opt-in RBF allows services to ‘low ball’ their initial fee-rate. If the - transaction fails to confirm in the desired time, the fee can be bumped. For - entities sending a lot of transactions, the savings in fee can be significant. -- Using CPFP to bump the fee can increase the total fee significantly, since - the total fee has to pay for both the child and parent transactions - whereas - an RBF transaction is replaced entirely and so doesn’t need to provide fee to - cover an extra transaction. For entities sending a lot of transactions, the - additional fees can be significant. -- Services that are very frequent spenders and broadcast transactions to the - blockchain every block can chain together spends and use CPFP without any - additional overhead. If a transaction has not been confirmed by the time - they need to broadcast their next transaction, they can use the change output - from the first transaction in the second, and attach enough fee to bump the - feerate across the entire package. -- Services that use - [payment batching](https://en.bitcoin.it/wiki/Techniques_to_reduce_transaction_fees#Payment_batching) - effectively can bump many payments with a single RBF or CPFP. -- Services that are not using payment batching can use a large CPFP to bump - multiple transactions at the same time, and potentially consolidate the UTXOs - from those multiple transactions at the same time. -- The mempool code only allows transaction packages of up to 25 unconfirmed - transactions (with a maximum weight of 404Kweight), so there’s a limit to the - number of transactions that can be bumped with a single CPFP transaction. -- Services that have a coin selection algorithm that is effective at - [change avoidance](https://en.bitcoin.it/wiki/Techniques_to_reduce_transaction_fees#Change_avoidance) - will have many transactions without change outputs, which can’t be bumped using - CPFP. Larger wallets are able to avoid change more often since they have a - larger set of UTXOs to choose from. - -These issues will be discussed in more detail in later sections of this document. - -## Introduction to RBF - -TODO1 - -### Overview of what RBF is - -TODO2 - -### History of RBF - -TODO3 - -### BIP 125 - -TODO4 - -#### 5 conditions for RBF - -TODO5 - -### User Experience Recommendations - -Even wallets and services that do not themselves support creating opt-in RBF or -replacement transactions should present a clear and accurate experience to -their users when dealing with RBF transactions: - -- wallets that receive transactions that have opt-in RBF signaled may - display that the transaction is signaling opt-in RBF (with a tooltip - or pop-up box giving additional information about RBF). -- wallets must not double account replaced transactions (ie count a debit - or credit twice if it appears in a replaced and replacement transaction). -- wallets and block explorers should continue to show replaced transactions - after they have been replaced (either grayed out or hidden), with a clear - indiction that the transaction was replaced and is no longer valid. -- wallets and block explorers should include information about the previous - transactions that a replacement transaction has replaced. For example, if - transaction A2 replaces A1, the page for A2 should include the information - that "this transaction replaced transaction A1". -- Links to transactions that have been replaced should remain live on block - explorers. They may redirect to the transaction which replaced them. - -### Interoperability & compatibility matrix - -TODO6 - -### Example of a company using RBF - -TODO7 - -## Child-Pays-For-Parent - -Child Pays for Parent (CPFP) is a wallet feature where a user spends the output -of an unconfirmed (_parent_) transaction as an input to a new (_child_) -transaction. The wallet attaches enough fee to the child transaction to -increase the combined feerate across the parent and child transactions. - -### How does CPFP work? - -When constructing a new block, miners are incentivized to fill the 1vMB with -the set of transactions that maximize the transaction fees. If all unconfirmed -transactions were independent, this would be a very straightforward operation - -the miner would select the transaction with the highest feerate and add it to -the candidate block. She'd then take the transaction with the next highest -feerate and add it to the block. She'd continue to do this until the block was -full. This trivially maximizes her profit from the block (with a little -complication around the final few bytes of the block to ensure that she'd -maximally filled the block). - -However, unconfirmed transactions _aren't_ independent. It is possible to have -chains of unconfirmed transactions by spending the output from a transaction -before it is included in a block. For example, if tx A has two outputs a1 and -a2, transaction B could use one of those outputs as an input before A has -been included in a block. In this case, if the miner wants to include -transaction B in the block, she must also include transaction A, since without -A, B is spending a non-existent output and is invalid. - -If the miner considered transactions independently when constructing her block, -she may forego transactions with very high fees if they depended on -transactions with very low fees (or worse, she may construct an invalid block -with a transaction that depends on an unincluded transaction). To maximize her -profit, the miner should therefore consider transactions in _packages_ (sets of -transactions with dependencies on each other) when constructing a new block. - -Wallets can take advantage of this rational behavior by miners to incentivize -them to include a stuck, low-fee transaction, by spending one of its outputs -and increasing the total feerate across the transaction package. - -### History of CPFP - -For users to be able to bump a transaction using CPFP, two elements are required: - -- a wallet that will spend the output of a stuck unconfirmed transaction in - order to bump the combined feerate. -- The expectation that miners will maximize their profit by considering - packages of transactions. - -Before 2012 blocks were rarely full and so there was no fee market. The -Bitcoin Core mining component was therefore not very optimized to maximize -transaction fees when selecting transactions for block inclusion. Transactions were -first ordered by 'priority' (the sum of the (value X coin age) for each -transaction input, divided by the transaction size), with an [increasing -feerate required][pre 0.7 tx selection] as the block filled up. Bitcoin Core -[PR #1590][] changed the mining code to predominantly sort transactions by -feerate, with some space reserved for transactions with a high priority score. -[Version 0.7.0][], released in September 2012 was therefore the first Bitcoin -Core release to primarily order transactions by feerate. - -[pre 0.7 tx selection]: https://github.com/bitcoin/bitcoin/blob/9b8eb4d6907502e9b1e74b62a850a11655d50ab5/main.h#L586 -[PR #1590]: https://github.com/bitcoin/bitcoin/pull/1590 -[Version 0.7.0]: https://bitcoin.org/en/release/v0.7.0 - -At around the same time, Luke-jr started maintaining [a patch][CPFP patch] -which took into account the transaction fee of children transaction when -sorting transactions for inclusion in a block. This patch was used by at least -some miners, but was never merged into Bitcoin Core due to a lack of testing -and benchmarking, and concerns that it could open a DoS vector against miners. - -[CPFP patch]: https://github.com/bitcoin/bitcoin/pull/1240 - -The Bitcoin Core mining code was updated [in 2016][CPFP PR] to better account -for packages of transactions. The mining code will consider packages of up to -25 transactions or 101vkB. This change was included in [V0.13][]. - -[CPFP PR]: https://github.com/bitcoin/bitcoin/pull/7600 -[V0.13]: https://bitcoincore.org/en/releases/0.13.0/#mining-transaction-selection-child-pays-for-parent - -At the time or writing (November 2018), it is almost certain that a majority of -miners are running Bitcoin Core V0.13 or later, or a derivative thereof. -Wallets can therefore safely assume that descendant transaction fees will be taken -into account when miners construct blocks. - -### CPFP case study - -The Hodlers Bitcoin Exchange (HBE) has several hundred thousand customers and -services thousands of withdrawals per day. Since they need to send many withdrawal -payments in every block, they batch withdrawals into a single transaction every -ten minutes. - -[//]: # (TODO: Include a link to batching chapter) - -HBE likes to keep fees low for their customers, so they set their transaction -fee very economically - they prefer to pay just enough to get into a block, but -no more! Occasionally, this means that the batch withdrawal transaction is not -confirmed and gets stuck in the mempool. This leads to customers complaining -about slow or stuck transactions. - -To improve the experience for their customers, HBE implemented CPFP to bump the -feerate on stuck batch withdrawal transactions. To do this, they use the change -output from one batch withdrawal as the first input into the next withdrawal, -and make sure to include enough fee on the second withdrawal to raise the -average feerate across the two transactions. If that still doesn't bring the -feerate up to a high enough level to be mined, they then use the change output -from the second batch withdrawal as the input to a third batch withdrawal, and -so on. - -There were a number of aspects that HBE needed to consider when implementing -their CPFP system: - -- they need to ensure that every batch withdrawal includes a change output that - comes back to them. If there's no change output, then they can't construct a - child transaction to bump the fee of the parent transaction. -- they needed to do careful testing around the fee rate logic. The child - transaction must pay for the parent transaction, so their algorithm needed to - take the weight of the parent transaction and the fee that had already been - paid into consideration when calculating the average fee rate. They needed to - do the same process when creating a 3rd or 4th generation transaction to pay - for its ancestors. -- the Bitcoin Core mining algorithm will only consider packages of up to 25 - transactions or 101vkB. HBE therefore needs to make sure they're not creating - chains of transactions larger than that. - -Overall, HBE is very happy with their new CPFP implementation. Support tickets -are down, and customers are usually unaware that their withdrawals are -being fee bumped using CPFP, since the transaction id and output index of their -withdrawal does not change. - -### User Experience Recommendations - -Wallets and explorers should present relevant information about transaction -packages to users: - -- if an unconfirmed transaction is part of a package of unconfirmed - transactions, the service should allow an expert user to view ancestor and - descendant feerate of the transaction alongside its feerate, to allow the - user to more accurately predict the package's chance of inclusion in future - blocks. -- block explorers may display transactions as 'malleable' if any of their - inputs are non-segwit. Malleable transactions may not be safe to include in - chains of unconfirmed transactions, since malleating the signature invalidates - any descendant transactions. - -## RBF or CPFP (or both) - -TODO8 - - -### Advantages of RBF - -TODO9 - -### Advantages of CPFP - -TODO10 - -### Using both together - -TODO11 - -### Implementation gotchas - -TODO12 - -## Conclusion - -Both Replace-By-Fee and Child-Pays-For-Parent are useful techniques for bumping -the fee on a stuck unconfirmed transaction. Each comes with its own benefits -and drawbacks, and depending on the situation it may be appropriate to use one -or the other (or both together). - -Bitcoin engineers should be familiar with both techniques, and Bitcoin products -and services should present a clear and accurate experience to users when those -techniques are being used, even if they do not support creating RBF or CPFP -transactions. - -## Footnotes - -### Consensus, policy and incentive compatibility - -Both solutions discussed in this article are related to network node and miner -behavior before a transaction is included in a block. That behavior is -therefore a question of policy rather than consensus. Both solutions are also -miner incentive-compatible - a miner who is trying to maximize his revenue will -accept both RBF’ed transactions and CPFP packages. Individual nodes’ mempools -(which should be a node’s best guess for what will be included in the next -blocks) should therefore also accept RBF’ed transactions and CPFP packages. diff --git a/en/scaling/index.md b/en/scaling/index.md deleted file mode 100644 index c9b32a51dd..0000000000 --- a/en/scaling/index.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: The Bitcoin Optech Scaling Book -layout: page ---- -The Bitcoin Optech Scaling Book is a guide to effective practices -and techniques that engineers interacting with the Bitcoin block chain -can adopt today. The following chapters are currently available: - -{% for chapter in site.data.scaling.toc %} - - [{{chapter.name}}]({{chapter.permalink}}) -{% endfor %} - -Additional chapters are being written. When published, they will be -announced in the [newsletter][]. - -{% include references.md %} -[newsletter]: /{{page.lang | default: 'en'}}/newsletters/ diff --git a/en/scaling/introduction/index.md b/en/scaling/introduction/index.md deleted file mode 100644 index 9e34b78ae3..0000000000 --- a/en/scaling/introduction/index.md +++ /dev/null @@ -1,195 +0,0 @@ ---- -title: The Bitcoin Optech Scaling Book -layout: chapter ---- -The Bitcoin Optech Scaling Book is a guide to effective practices and -techniques that engineers interacting with the Bitcoin blockchain can adopt -today. These practices are good for your business (they make your operations -run more efficiently and save you money) and good for the ecosystem (they minimise -your usage of common network resources and ensure that the Bitcoin network -remains available for as many users and use cases as possible). - -What is it that we mean by _scaling_ when talking about the Bitcoin blockchain? -In general, we can call a system 'scalable' if the resources consumed by the -system scales no worse than linearly with the number of users or units of -activity in the system. The Bitcoin base layer as a payment network does not -appear to achieve this definition of scalability. Since the Bitcoin network -makes use of a peer-to-peer gossip protocol in which every node validates every -transaction, the global amount of computation, bandwidth and storage required -scales (in at least some senses) quadratically with the number of users. n -users validating transactions from n users results in the order of n2 -validations. Even if we radically reduce the security by requiring new users to -be 'light clients' and not validate the full state of the system, adding new -users by increasing the transaction throughput is still at best linear in total -global resource cost. - -And there's another problem. In many systems, the costs of the additional -resources consumed is borne by the party benefiting from the additional -activity. If a company needs to acquire additional computing resource to serve -new customers, then that company would pay for the additional servers or cloud -computing resources and benefit from the increased revenue generated by the -customers. That isn't the case with on-chain Bitcoin transactions. Each full -node operator bears the resource costs of validating transactions, in the form -of bandwidth, compute, memory and storage. Naively increasing the transaction -throughput of the Bitcoin network would therefore benefit parties creating additional -transactions at the expense of everyone running a full node. Many users -recognise that a vital component of maintaining a decentralized network is keeping -the cost of running a full node low and allowing as many users as possible to -run a full node. An attempt in 2017 to double the block size (and hence increase -the resource requirements of running a full node), failed to gain consensus and -was [withdrawn by its proponents][segwit2x]. - -[segwit2x]: https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-November/000685.html - -So if scaling up the underlying resource requirements is not currently an -option (and in any case could not deliver the global scale that Bitcoin -proponents would like to see), scaling Bitcoin becomes a question of -how to maximize the utility that can be delivered _within the constraints_ of -the system, or in other words, how we can achieve _more with less_? - -The utility that the Bitcoin blockchain delivers is _payments_, since that’s -what users want to use the Bitcoin system for. To confuse the logical concept -of a Bitcoin _transaction_ with the social concept of a payment is a -conspicuous (and sadly very common) error. A _payment_ is a transfer of value -from one party to another. In Bitcoin, a _transaction_ is a transformation on -the global set of unspent transaction outputs, consuming some UTXOs and -producing some new UTXOs. _Transaction_ can also refer to a data structure -that is passed over the P2P network that both describes the transformation on -the UTXO set and carries a witness that the transformation is valid. In neither -of these definitions does a transaction correspond to a payment - each -transaction can realize one, many or even no payments. - -To try to measure scalability with a metric like _transactions per second_ -(_tps_) is therefore flawed. Firstly, _tps_ is not measuring what we’re -interested in, and secondly, not all payments are equally useful. - -To give a concrete Example of the first point, if high-frequency Bitcoin users -switched from sending many single-recipient transactions per day to sending a -single batched transaction per day, the average blockchain weight per _payment_ -would decrease, but the average blockchain weight per _transaction_ would -increase. We'd very likely see a Bitcoin network with fewer transactions per -day, but a greater number of payments. Utility is up, but _tps_ is down! - -The second reason is that not all transactions are equally useful. Since each -transaction is simply a transformation on the set of UTXOs, the Bitcoin -consensus rules do not recognise any difference in importance between different -transactions. The transaction produced by an institutional investor moving -hundreds of Bitcoin into a cold storage multisig output as part of a long-term -investment strategy could look identical to the transaction for a customer -paying for a cup of coffee. Each counts as one 'transaction' but the first user -probably gets much more utility from his transaction than the second user. The -former may be prepared to pay a high fee to have his transaction recorded in a -decentralized, trustless, immutable ledger, whereas the latter may be equally -satisfied to have his payment made on a second-layer like lightning, a -side-chain or even a trusted off-chain payment network. - -The Bitcoin network has a mechanism for users to express the urgency and -utility of their transactions through transaction fees, but at the time of -writing, the fee market is underdeveloped, inelastic and immature. As the network -develops, it is expected that the fee market will become more sophisticated. - -When considered in this light, many practices which might not at first be -considered as 'scaling technologies' can be considered as such. For example, a -functioning fee market, and above all a reliable way to 'bump' fees on a -transaction that has not yet included in a block, allows users to better -express their time preference for a transaction to be confirmed. That means -that the scarce block space can be allocated more efficiently to those users -who value it more, and therefore the total utility delivered by the network is -increased. This book takes this wider view of 'scalability'. Any technique that -can increase the usefulness of the network in aggregate can be thought of as -contributing to scaling. - -Take this book then as a guide to extracting the most possible value out of -this scarce and precious resource called the Bitcoin blockchain. The protocol -wizards continue to innovate on the base and second layers, and exciting -developments like Schnorr signatures, taproot, signature aggregation, eltoo, -atomic multi path payments and channel splicing are all in the works. But for -now, we can all do our bit to minimize our impact on the base layer and allow -as many users as possible to transact permissionlessly and trustlessly. - -# About Bitcoin Optech - -Bitcoin Optech was formed in early 2018. Our aim is to help Bitcoin companies -adopt the best scaling technologies and practices available to make efficient -use of the blockchain, and thereby help Bitcoin to scale to more users and use -cases. - -During late 2017 and early 2018, we saw demand for Bitcoin usage explode and -many users and companies were unready for the sudden spike in transaction -volume. Block space suddenly became a competitive a rivalrous good, and -transaction fees jumped as demand exceeded supply. - -At the same time, many well-understood scaling technologies were being -underutilized. Segwit usage remained below 40%, some high-frequency users -of the chain were sending payments as individual transactions rather than -batching, fee estimates were failing to react to fee market conditions and -poor coin selection led to wallets accumulating low value UTXOs and paying -very high fees. - -The end result was a poor and costly experience for users, some use cases -being priced out entirely, and Bitcoin failing to scale to meet demand. At -Bitcoin Optech, we believe that seawalls are best built during low tide, and -hope that Bitcoin companies will take advantage of conditions of low network -usage and transaction fees to implement these scaling techniques. Those -that do will be best positioned to continue offering their customers the -best reliability and value when Bitcoin usage surges again. - -# Intended Audience - -This book is intended for engineers who work in developer or operational roles -at companies that interact with the Bitcoin blockchain. It is meant as a -practical guide for people who are already familiar with standard Bitcoin -concepts like ScriptPubKeys, ScriptSigs and witnesses; the SCRIPT language and -standard output types; public and private keys; and transaction serialization. -See [Mastering Bitcoin][antonopoulos] or [Bitcoin and Cryptocurrency -Technologies][narayanan] for a beginners guide to those concepts or -[btcinformation.org][] for a comprehensive reference. - -[antonopoulos]: https://bitcoinbook.info/ -[narayanan]: http://bitcoinbook.cs.princeton.edu/ -[btcinformation.org]: https://btcinformation.org/en/developer-documentation - -Likewise, this book is not overly concerned with the cryptographic -underpinnings of Bitcoin, except where those are directly required for -improving the efficiency and scalability of Bitcoin operations. Cryptography is -a fascinating subject and [Dan Boneh's Applied Cryptography course][boneh] is -an excellent introduction for those wishing to begin their exploration. - -[boneh]: https://crypto.stanford.edu/~dabo/courses/OnlineCrypto/ - -# Conventions - -Most terms are used as readers would expect. The script in a transaction output -which encumers the output is the scriptPubKey. The script in the transaction -input which unlocks the funds is the scriptSig. The *scriptCode* is the -actually executed script (which is the redeemscript in non-segwit P2SH, and the -witnesscript in P2WSH/P2WPKH). - -The smallest unit of account is referred to as a satoshi by convention, and -10^8 satoshis is named a bitcoin. No other units of account are used. - -The party making a payment is called the _spender_ (_sender_ could be -ambiguously refer to a party sending Bitcoin or a party sending data). There is -no equivalent word in English to disambiguate the receiver of a payment and -the receiver of data, so we use the word _recipient_ to refer to one receiving -a payment, and live with the ambiguity. - -## Transaction weight and virtual bytes - -The consensus rule for block size is that the combined _weight_ of -transactions must be less than 4,000,000. The weight of a single -transaction is calculated as follows: - -- The _base size_ of a transaction is the number of bytes to serialize the - block without witness -- The _size_ of a transaction is the number of bytes to serialize the block - with witness -- The _weight_ is 3 x base size + size - -This formula means that the bytes in the witness are 'discounted' by a factor -of 4. They count less towards the weight of the transaction than bytes in -the base transaction. - -The _virtual size_ of a transaction is weight / 4 and is measured in _virtual bytes_ -or _vBytes_. For transactions without any segwit inputs, the base size, size and -virtual size are all equal. diff --git a/en/tools/calc-size.md b/en/tools/calc-size.md index 328afcffe0..7362eded2a 100644 --- a/en/tools/calc-size.md +++ b/en/tools/calc-size.md @@ -35,6 +35,7 @@ size: ## Common elements ecdsa_pubkey: 33 ecdsa_signature: 72 + ecdsa_signature_low_r: 71 schnorr_public_key: 32 schnorr_signature: 64 public_key_hash: 20 @@ -104,10 +105,10 @@ sections are [vbytes][]. Sizes in the *common elements* section are bytes. someone controlling the appropriate private keys. For the templates used by this calculator, the scriptSigs sizes are: - - **P2PKH** ({{page.size.p2pkh_ss}}) - `OP_PUSH72 OP_PUSH33 ` + - **P2PKH** ({{page.size.p2pkh_ss}}) + `OP_PUSH72 OP_PUSH33 ` - - **P2SH 2-of-3** ({{page.size.p2sh23_ss}}) `OP_0 OP_PUSH72 OP_PUSH72 OP_PUSHDATA1 105 OP_PUSH33 OP_PUSH33 OP_3 OP_CHECKMULTISIG>` + - **P2SH 2-of-3** ({{page.size.p2sh23_ss}}) `OP_0 OP_PUSH72 OP_PUSH72 OP_PUSHDATA1 105 OP_PUSH33 OP_PUSH33 OP_3 OP_CHECKMULTISIG>` - **nSequence** ({{page.size.nsequence}}) The sequence number for the @@ -124,18 +125,18 @@ sections are [vbytes][]. Sizes in the *common elements* section are bytes. Each item is prefixed by a [compactsize][] `size()` identifier. For the templates used by this calculator, the witness data sizes are: - - **P2WPKH** ({{page.size.p2wpkh_witness}}) - - (73) `size(72) signature` - - (34) `size(33) public_key` + - **P2WPKH** ({{page.size.p2wpkh_witness}}) + - (73) `size(72) signature` + - (34) `size(33) public_key` - - **P2WSH 2-of-3** ({{page.size.p2wsh23_witness}}) - - (1) `size(0) (empty)` - - (73) `size(72) ecdsa_signature` - - (73) `size(72) ecdsa_signature` - - (106) `size(105) OP_2 OP_PUSH33 OP_PUSH33 OP_PUSH33 OP_3 OP_CHECKMULTISIG` + - **P2WSH 2-of-3** ({{page.size.p2wsh23_witness}}) + - (1) `size(0) (empty)` + - (73) `size(72) ecdsa_signature` + - (73) `size(72) ecdsa_signature` + - (106) `size(105) OP_2 OP_PUSH33 OP_PUSH33 OP_PUSH33 OP_3 OP_CHECKMULTISIG` - - **P2TR** ({{page.size.p2tr_witness}}) - - (65) `size(64) schnorr_signature` + - **P2TR** ({{page.size.p2tr_witness}}) + - (65) `size(64) schnorr_signature` ## Output @@ -150,17 +151,17 @@ sections are [vbytes][]. Sizes in the *common elements* section are bytes. be fulfilled in order for this output to be spent. For the templates used by this calculator, the scriptPubKeys are: - - **P2PKH** ({{page.size.p2pkh_spk}}) `OP_DUP OP_HASH160 - OP_PUSH20 OP_EQUALVERIFY OP_CHECKSIG` + - **P2PKH** ({{page.size.p2pkh_spk}}) `OP_DUP OP_HASH160 + OP_PUSH20 OP_EQUALVERIFY OP_CHECKSIG` - - **P2WPKH** ({{page.size.p2wpkh_spk}}) `OP_0 OP_PUSH20 ` + - **P2WPKH** ({{page.size.p2wpkh_spk}}) `OP_0 OP_PUSH20 ` - - **P2SH 2-of-3** ({{page.size.p2sh23_spk}}) `OP_HASH160 - OP_PUSH20 OP_EQUAL` + - **P2SH 2-of-3** ({{page.size.p2sh23_spk}}) `OP_HASH160 + OP_PUSH20 OP_EQUAL` - - **P2WSH 2-of-3** ({{page.size.p2wsh23_spk}}) `OP_0 OP_PUSH32 ` + - **P2WSH 2-of-3** ({{page.size.p2wsh23_spk}}) `OP_0 OP_PUSH32 ` - - **P2TR** ({{page.size.p2tr_spk}}) `OP_1 OP_PUSH32 ` + - **P2TR** ({{page.size.p2tr_spk}}) `OP_1 OP_PUSH32 ` ## Common elements @@ -174,9 +175,12 @@ four. - `ecdsa_public_key` ({{page.size.ecdsa_pubkey}})---old wallets may use 65-byte public keys -- `ecdsa_signature` ({{page.size.ecdsa_signature}}) (about half of all - signatures generated with a random nonce are this size, about half are - one byte smaller, and a small percentage are smaller than that) +- `ecdsa_signature` ({{page.size.ecdsa_signature}})---ECDSA signatures have variable size. About + half of all signatures generated with a random nonce are {{page.size.ecdsa_signature}}, about half + are one byte smaller ({{page.size.ecdsa_signature_low_r}}), and a small percentage are smaller + than that. This calculator conservatively estimates all transaction sizes based on the upper bound + of signature sizes. If your signing device or software uses [low-r grinding][], your transactions + will consistently have signature sizes of {{page.size.ecdsa_signature_low_r}}. - `schnorr_public_key` ({{page.size.schnorr_public_key}}) @@ -370,3 +374,4 @@ updateTotal(); [compactSize]: https://btcinformation.org/en/developer-reference#compactsize-unsigned-integers [epoch time]: https://en.wikipedia.org/wiki/Unix_time [vbytes]: https://en.bitcoin.it/wiki/Vsize +[low-r grinding]: /en/topics/low-r-grinding/ diff --git a/en/tools/reorg-calculator.md b/en/tools/reorg-calculator.md new file mode 100644 index 0000000000..84155a7287 --- /dev/null +++ b/en/tools/reorg-calculator.md @@ -0,0 +1,144 @@ +--- +permalink: /en/tools/reorg-calculator/ +title: "Reorg Calculator" +layout: page +breadcrumbs: false +--- + + +
+
+ Attacker's hash power (%):
+ Blocks to catch up:
+ Time ratio (κ): + +

+
+
+
+ + + +

+This calculator shows the probability that an attacker with a given percentage of the total network hashrate could successfully reorganize `z` blocks, based on the *conditional* formula in [Double Spend Races] which includes **κ** (time ratio). + + + +### Parameters: + +- **Attacker hashrate (% q)**: The portion of total network hashrate controlled by the attacker +- **Honest hashrate (% p)**: The portion controlled by honest miners (1 - q) +- **Blocks behind (z):** How many blocks the honest chain is ahead. +- **Time ratio (κ):** + - If `κ > 1`, honest blocks took *longer* than average ⇒ attacker has higher chance. + - If `κ < 1`, honest blocks were *faster* ⇒ lower attacker chance. + - If `κ=1`, you ignore timing and assume an "average" scenario (Satoshi's formula). + + +{% include references.md %} +[Double Spend Races]: https://diyhpl.us/~bryan/papers2/bitcoin/Double%20spend%20races%20-%202017.pdf \ No newline at end of file diff --git a/en/topic-categories.md b/en/topic-categories.md index f87e9bfccf..abfec87728 100644 --- a/en/topic-categories.md +++ b/en/topic-categories.md @@ -7,10 +7,10 @@ layout: page {% capture raw_categories %} {%- for topic in site.topics -%} - {%- if topic.categories == empty -%} + {%- if topic.topic-categories == empty -%} {% include ERROR_92_MISSING_TOPIC_CATEGORY %} {%- endif -%} - {%- for category in topic.categories -%} + {%- for category in topic.topic-categories -%} {{category}}| {%- endfor -%} {%- endfor -%} @@ -18,6 +18,7 @@ layout: page {% assign categories = raw_categories | split: "|" | sort_natural | uniq %}
+ {{ categories | size }} categories for {{site.topics | size}} unique topics, with many topics appearing in multiple categories. @@ -32,7 +33,7 @@ produce code blocks -->{% endcomment %}

{{category}}

    {% for topic in site.topics %} - {% if topic.categories contains category %} + {% if topic.topic-categories contains category %}
  • {{topic.title}}
    • {% endif %} {% endfor %} diff --git a/en/topic-dates.md b/en/topic-dates.md index e3ed08fa5f..77625f6d7c 100644 --- a/en/topic-dates.md +++ b/en/topic-dates.md @@ -4,6 +4,7 @@ permalink: /en/topic-dates/ layout: page --- {% include linkers/topic-pages.md %} + {% assign this_year = site.time | date: "%Y" | plus: 0 %} {% capture months %} @@ -74,10 +75,12 @@ before the main content --> {% endcapture %}
    + {{number_of_events}} indexed events in {{number_of_months}} months -[2018](#d2018-12) | [2019](#d2019-12) | [2020](#d2020-12) | -[2021](#d2021-12) +[2018](#d2018-12) \| [2019](#d2019-12) \| [2020](#d2020-12) \| [2021](#d2021-12) \| +[2022](#d2022-12) \| [2023](#d2023-12) \| [2024](#d2024-12) \| [2025](#d2025-12) +
    {% comment %}{% endcomment %} {% capture raw_topics_list %} {%- for topic in site.topics -%} + [{{topic.title}}]({{topic.url}})ENDTOPIC - {%- for alias in topic.aliases -%} - *[{{alias}}]({{topic.url}})*ENDTOPIC - {%- endfor -%} + {%- for alias in topic.title-aliases -%}*[{{alias}}]({{topic.url}})*ENDTOPIC{%- endfor -%} {%- endfor -%} {% endcapture %} @@ -25,6 +24,7 @@ rather than URL. -->{% endcomment %} {% assign number_of_aliases = number_of_entries | minus: number_of_topics %}
    + {{number_of_topics}} topics (and {{number_of_aliases}} aliases in *italics* for topics with alternative names). diff --git a/en/workshops.md b/en/workshops.md new file mode 100644 index 0000000000..40804723b7 --- /dev/null +++ b/en/workshops.md @@ -0,0 +1,88 @@ +--- +layout: page +title: Workshops +permalink: /en/workshops/ +redirect_from: /workshops +--- + +Bitcoin Optech will run a series of workshops to bring Bitcoin engineers +together to discuss approaches and challenges in implementing scaling +technologies. Each workshop will be tailored to the member companies attending +and the specific scaling challenges that they are facing. + +If you have any requests or suggestions for future workshop events, please +[contact us][optech email]. + +## Workshops #3, #4 and #5 - Schnorr and Taproot Seminars {#taproot-workshop} + +- San Francisco, September 24 2019 +- New York, September 27 2019 +- London, February 5 2020 + +*Schnorr signatures* and *Taproot* are proposed changes to the Bitcoin +protocol that promise greatly improved privacy, fungibility, scalability and +functionality. + +Bitcoin Optech hosted two seminar format workshops which included a mixture of +presentations, coding exercises and discussions, and gave engineers at +member companies an understanding of how these new technologies work and how +they can be applied to their products and services. The workshops also provided +engineers an opportunity to take part in the feedback process while these +technologies are still in the proposal stage. + +[All material from the workshops][taproot workshop blog post] is available on this website, so engineers can +learn about the schnorr/taproot proposals at home. + +## Workshop #2 - Paris, November 12-13 2018 + +Bitcoin Optech held our second roundtable workshop in Paris on November 12-13 2018. +The format was the same as the first workshop in San Francisco. + +In attendance were 24 engineers from Bitcoin companies and open source +projects. + +#### Topics + +- Replace-by-fee vs. child-pays-for-parent as fee replacement techniques +- Partially Signed Bitcoin Transactions ([BIP 174](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki)) +- [Output script descriptors](https://gist.github.com/sipa/e3d23d498c430bb601c5bca83523fa82) for wallet interoperability +- Lightning wallet integration and applications for exchanges +- Approaches to coin selection & consolidation + +#### Thanks + +Thanks to Ledger for hosting the workshop and helping with organization. + +## Workshop #1 - San Francisco, July 17 2018 + +Bitcoin Optech held our first roundtable workshop in San Francisco on July 17 2018: + +- Topics were discussed in a roundtable format in which every participant had an + equal opportunity to engage. + +- Each topic had a moderator and notetaker. The moderator was responsible for a + brief introduction of a topic and keeping discussion on track and on time. + +- To make sure that participants were comfortable to speak freely, notes and + action items were distributed to participants but not beyond. Participants + were free to share discussion details internally at their companies and + publicly, but did not attribute any particular statement to a given individual + (Chatham House Rules). + +In attendance were 14 engineers from SF Bay Area Bitcoin companies and open +source projects. + +#### Topics + +- Coin selection +- Fee estimation, RBF, CPFP best practices +- Optech community and communication + +#### Thanks + +Thanks to Square for hosting the workshop and Coinbase for helping with +organization. + +{% include references.md %} + +[taproot workshop blog post]: /en/schorr-taproot-workshop/ diff --git a/fr/newsletters.md b/fr/newsletters.md index 4e26b33288..99e6536bf9 100644 --- a/fr/newsletters.md +++ b/fr/newsletters.md @@ -9,4 +9,4 @@ version: 1 --- Voulez-vous aider à traduire nos publications ? Regardez la documentation [CONTRIBUTING](https://github.com/bitcoinops/bitcoinops.github.io/blob/master/CONTRIBUTING.md#translations) -et les problèmes et demandes de modifications de [tradcuction française sur notre dépot github](https://github.com/bitcoinops/bitcoinops.github.io/pulls?&q=label%3Alocalization-french) +et les problèmes et demandes de modifications de [traduction française sur notre dépot github](https://github.com/bitcoinops/bitcoinops.github.io/pulls?&q=label%3Alocalization-french) diff --git a/fr/publications.md b/fr/publications.md index 609c17fcfb..ba24ec035f 100644 --- a/fr/publications.md +++ b/fr/publications.md @@ -8,8 +8,6 @@ share: false version: 1 --- {%- if jekyll.environment == 'future' -%} -- [Manuel de mise à l'échelle][]: Un guide des pratiques et techniques efficaces que les ingénieurs interagissant avec la Blockchain Bitcoin peuvent aujourd'hui adopter. - - [Newsletters][]: Un résumé hebdomadaire des nouvelles sur le développement Bitcoin. - [Blog posts][]: Mises à jour occasionnelles et documents de référence de l'équipe Optech. @@ -23,4 +21,3 @@ Publications récentes sur nos [blog posts][] et [newsletters][]. [blog posts]: /fr/blog/ [newsletters]: /fr/newsletters/ -[manuel de mise à l'échelle]: /fr/scaling/ diff --git a/img/compatibility/abra/abra.png b/img/compatibility/abra/abra.png deleted file mode 100644 index 502ee0accd..0000000000 Binary files a/img/compatibility/abra/abra.png and /dev/null differ diff --git a/img/compatibility/abra/rbf/notification-incoming-replacement.png b/img/compatibility/abra/rbf/notification-incoming-replacement.png deleted file mode 100644 index 1906afbf78..0000000000 Binary files a/img/compatibility/abra/rbf/notification-incoming-replacement.png and /dev/null differ diff --git a/img/compatibility/abra/rbf/send-confirm.png b/img/compatibility/abra/rbf/send-confirm.png deleted file mode 100644 index 0618475328..0000000000 Binary files a/img/compatibility/abra/rbf/send-confirm.png and /dev/null differ diff --git a/img/compatibility/abra/rbf/send-fee-notice.png b/img/compatibility/abra/rbf/send-fee-notice.png deleted file mode 100644 index 0ae6112de4..0000000000 Binary files a/img/compatibility/abra/rbf/send-fee-notice.png and /dev/null differ diff --git a/img/compatibility/abra/rbf/send-screen-default.png b/img/compatibility/abra/rbf/send-screen-default.png deleted file mode 100644 index 5e013326a3..0000000000 Binary files a/img/compatibility/abra/rbf/send-screen-default.png and /dev/null differ diff --git a/img/compatibility/abra/rbf/transaction-details-replacement-confirmed.png b/img/compatibility/abra/rbf/transaction-details-replacement-confirmed.png deleted file mode 100644 index dc4c33e5db..0000000000 Binary files a/img/compatibility/abra/rbf/transaction-details-replacement-confirmed.png and /dev/null differ diff --git a/img/compatibility/abra/rbf/transaction-details-sent.png b/img/compatibility/abra/rbf/transaction-details-sent.png deleted file mode 100644 index 7b2bddfc4a..0000000000 Binary files a/img/compatibility/abra/rbf/transaction-details-sent.png and /dev/null differ diff --git a/img/compatibility/abra/rbf/transaction-list-incoming-rbf.png b/img/compatibility/abra/rbf/transaction-list-incoming-rbf.png deleted file mode 100644 index 61c072785e..0000000000 Binary files a/img/compatibility/abra/rbf/transaction-list-incoming-rbf.png and /dev/null differ diff --git a/img/compatibility/abra/rbf/transaction-list-incoming-replacement.png b/img/compatibility/abra/rbf/transaction-list-incoming-replacement.png deleted file mode 100644 index 451a089801..0000000000 Binary files a/img/compatibility/abra/rbf/transaction-list-incoming-replacement.png and /dev/null differ diff --git a/img/compatibility/abra/rbf/transaction-list-sent.png b/img/compatibility/abra/rbf/transaction-list-sent.png deleted file mode 100644 index 1b8cbf4711..0000000000 Binary files a/img/compatibility/abra/rbf/transaction-list-sent.png and /dev/null differ diff --git a/img/compatibility/abra/segwit/receive-screen.png b/img/compatibility/abra/segwit/receive-screen.png deleted file mode 100644 index 3453de21dc..0000000000 Binary files a/img/compatibility/abra/segwit/receive-screen.png and /dev/null differ diff --git a/img/compatibility/abra/segwit/send-bech32-qr.png b/img/compatibility/abra/segwit/send-bech32-qr.png deleted file mode 100644 index 16b50a2ea7..0000000000 Binary files a/img/compatibility/abra/segwit/send-bech32-qr.png and /dev/null differ diff --git a/img/compatibility/abra/segwit/send-bech32.png b/img/compatibility/abra/segwit/send-bech32.png deleted file mode 100644 index 09d867994d..0000000000 Binary files a/img/compatibility/abra/segwit/send-bech32.png and /dev/null differ diff --git a/img/compatibility/abra/segwit/send-non-bech32.png b/img/compatibility/abra/segwit/send-non-bech32.png deleted file mode 100644 index c1995738e1..0000000000 Binary files a/img/compatibility/abra/segwit/send-non-bech32.png and /dev/null differ diff --git a/img/compatibility/binance/binance.png b/img/compatibility/binance/binance.png deleted file mode 100755 index 0c3d5be328..0000000000 Binary files a/img/compatibility/binance/binance.png and /dev/null differ diff --git a/img/compatibility/binance/rbf/send-screen.png b/img/compatibility/binance/rbf/send-screen.png deleted file mode 100644 index c1d3459f66..0000000000 Binary files a/img/compatibility/binance/rbf/send-screen.png and /dev/null differ diff --git a/img/compatibility/binance/rbf/transaction-list-incoming-rbf.png b/img/compatibility/binance/rbf/transaction-list-incoming-rbf.png deleted file mode 100644 index d81de89385..0000000000 Binary files a/img/compatibility/binance/rbf/transaction-list-incoming-rbf.png and /dev/null differ diff --git a/img/compatibility/binance/rbf/transaction-list-replacement-confirmed.png b/img/compatibility/binance/rbf/transaction-list-replacement-confirmed.png deleted file mode 100644 index a25208fb04..0000000000 Binary files a/img/compatibility/binance/rbf/transaction-list-replacement-confirmed.png and /dev/null differ diff --git a/img/compatibility/binance/rbf/transaction-list-sent.png b/img/compatibility/binance/rbf/transaction-list-sent.png deleted file mode 100644 index 2f613ac08a..0000000000 Binary files a/img/compatibility/binance/rbf/transaction-list-sent.png and /dev/null differ diff --git a/img/compatibility/binance/segwit/address-book-add.png b/img/compatibility/binance/segwit/address-book-add.png deleted file mode 100644 index bcd626e53a..0000000000 Binary files a/img/compatibility/binance/segwit/address-book-add.png and /dev/null differ diff --git a/img/compatibility/binance/segwit/receive-screen.png b/img/compatibility/binance/segwit/receive-screen.png deleted file mode 100644 index 0a280df40a..0000000000 Binary files a/img/compatibility/binance/segwit/receive-screen.png and /dev/null differ diff --git a/img/compatibility/binance/segwit/send-address-error.png b/img/compatibility/binance/segwit/send-address-error.png deleted file mode 100644 index 6169495b16..0000000000 Binary files a/img/compatibility/binance/segwit/send-address-error.png and /dev/null differ diff --git a/img/compatibility/binance/segwit/send-p2wsh-error.png b/img/compatibility/binance/segwit/send-p2wsh-error.png deleted file mode 100644 index 61b5b8940d..0000000000 Binary files a/img/compatibility/binance/segwit/send-p2wsh-error.png and /dev/null differ diff --git a/img/compatibility/binance/segwit/send-screen.png b/img/compatibility/binance/segwit/send-screen.png deleted file mode 100644 index 52f679f8e9..0000000000 Binary files a/img/compatibility/binance/segwit/send-screen.png and /dev/null differ diff --git a/img/compatibility/bitcoin-core/bitcoin-core.png b/img/compatibility/bitcoin-core/bitcoin-core.png deleted file mode 100755 index c6a8df8a9d..0000000000 Binary files a/img/compatibility/bitcoin-core/bitcoin-core.png and /dev/null differ diff --git a/img/compatibility/bitcoin-core/default-wallet-send-screen.png b/img/compatibility/bitcoin-core/default-wallet-send-screen.png deleted file mode 100644 index 6beca44195..0000000000 Binary files a/img/compatibility/bitcoin-core/default-wallet-send-screen.png and /dev/null differ diff --git a/img/compatibility/bitcoin-core/increase-fee-confirmation-prompt.png b/img/compatibility/bitcoin-core/increase-fee-confirmation-prompt.png deleted file mode 100644 index 1e94673e4b..0000000000 Binary files a/img/compatibility/bitcoin-core/increase-fee-confirmation-prompt.png and /dev/null differ diff --git a/img/compatibility/bitcoin-core/low-fee-confirmation-with-rbf-note-enabled.png b/img/compatibility/bitcoin-core/low-fee-confirmation-with-rbf-note-enabled.png deleted file mode 100644 index abdfd7911c..0000000000 Binary files a/img/compatibility/bitcoin-core/low-fee-confirmation-with-rbf-note-enabled.png and /dev/null differ diff --git a/img/compatibility/bitcoin-core/low-fee-confirmation-with-rbf-note.png b/img/compatibility/bitcoin-core/low-fee-confirmation-with-rbf-note.png deleted file mode 100644 index 6a2498346d..0000000000 Binary files a/img/compatibility/bitcoin-core/low-fee-confirmation-with-rbf-note.png and /dev/null differ diff --git a/img/compatibility/bitcoin-core/notification-incoming-transaction.png b/img/compatibility/bitcoin-core/notification-incoming-transaction.png deleted file mode 100644 index eeae04266c..0000000000 Binary files a/img/compatibility/bitcoin-core/notification-incoming-transaction.png and /dev/null differ diff --git a/img/compatibility/bitcoin-core/notification-replacement-transaction.png b/img/compatibility/bitcoin-core/notification-replacement-transaction.png deleted file mode 100644 index 23906a0004..0000000000 Binary files a/img/compatibility/bitcoin-core/notification-replacement-transaction.png and /dev/null differ diff --git a/img/compatibility/bitcoin-core/segwit/address-screen.png b/img/compatibility/bitcoin-core/segwit/address-screen.png deleted file mode 100644 index 5d7218af9d..0000000000 Binary files a/img/compatibility/bitcoin-core/segwit/address-screen.png and /dev/null differ diff --git a/img/compatibility/bitcoin-core/segwit/receive-screen.png b/img/compatibility/bitcoin-core/segwit/receive-screen.png deleted file mode 100644 index e2e08e4e3d..0000000000 Binary files a/img/compatibility/bitcoin-core/segwit/receive-screen.png and /dev/null differ diff --git a/img/compatibility/bitcoin-core/segwit/send-screen.png b/img/compatibility/bitcoin-core/segwit/send-screen.png deleted file mode 100644 index 390b789ce0..0000000000 Binary files a/img/compatibility/bitcoin-core/segwit/send-screen.png and /dev/null differ diff --git a/img/compatibility/bitcoin-core/transaction-details-bumped-transaction.png b/img/compatibility/bitcoin-core/transaction-details-bumped-transaction.png deleted file mode 100644 index fe1e83418f..0000000000 Binary files a/img/compatibility/bitcoin-core/transaction-details-bumped-transaction.png and /dev/null differ diff --git a/img/compatibility/bitcoin-core/transaction-details-context-menu-increase-fee.png b/img/compatibility/bitcoin-core/transaction-details-context-menu-increase-fee.png deleted file mode 100644 index ad393757ce..0000000000 Binary files a/img/compatibility/bitcoin-core/transaction-details-context-menu-increase-fee.png and /dev/null differ diff --git a/img/compatibility/bitcoin-core/transaction-details-original.png b/img/compatibility/bitcoin-core/transaction-details-original.png deleted file mode 100644 index 538b2db609..0000000000 Binary files a/img/compatibility/bitcoin-core/transaction-details-original.png and /dev/null differ diff --git a/img/compatibility/bitcoin-core/transaction-details-outgoing-rbf.png b/img/compatibility/bitcoin-core/transaction-details-outgoing-rbf.png deleted file mode 100644 index b285db4156..0000000000 Binary files a/img/compatibility/bitcoin-core/transaction-details-outgoing-rbf.png and /dev/null differ diff --git a/img/compatibility/bitcoin-core/transaction-details-rbf-incoming.png b/img/compatibility/bitcoin-core/transaction-details-rbf-incoming.png deleted file mode 100644 index 253b237959..0000000000 Binary files a/img/compatibility/bitcoin-core/transaction-details-rbf-incoming.png and /dev/null differ diff --git a/img/compatibility/bitcoin-core/transaction-details-replacement.png b/img/compatibility/bitcoin-core/transaction-details-replacement.png deleted file mode 100644 index 4e0d27d294..0000000000 Binary files a/img/compatibility/bitcoin-core/transaction-details-replacement.png and /dev/null differ diff --git a/img/compatibility/bitcoin-core/transaction-list-outgoing-rbf-transaction.png b/img/compatibility/bitcoin-core/transaction-list-outgoing-rbf-transaction.png deleted file mode 100644 index 5802c67a9e..0000000000 Binary files a/img/compatibility/bitcoin-core/transaction-list-outgoing-rbf-transaction.png and /dev/null differ diff --git a/img/compatibility/bitcoin-core/transaction-list-post-bump.png b/img/compatibility/bitcoin-core/transaction-list-post-bump.png deleted file mode 100644 index 985ce011b3..0000000000 Binary files a/img/compatibility/bitcoin-core/transaction-list-post-bump.png and /dev/null differ diff --git a/img/compatibility/bitcoin-core/transaction-list-rbf-incoming.png b/img/compatibility/bitcoin-core/transaction-list-rbf-incoming.png deleted file mode 100644 index e3a897fc82..0000000000 Binary files a/img/compatibility/bitcoin-core/transaction-list-rbf-incoming.png and /dev/null differ diff --git a/img/compatibility/bitcoin-core/transaction-list-replacement-incoming.png b/img/compatibility/bitcoin-core/transaction-list-replacement-incoming.png deleted file mode 100644 index b3cfd7592c..0000000000 Binary files a/img/compatibility/bitcoin-core/transaction-list-replacement-incoming.png and /dev/null differ diff --git a/img/compatibility/bitcoin-core/wallet-send-screen-fee-details.png b/img/compatibility/bitcoin-core/wallet-send-screen-fee-details.png deleted file mode 100644 index 0fe32d8493..0000000000 Binary files a/img/compatibility/bitcoin-core/wallet-send-screen-fee-details.png and /dev/null differ diff --git a/img/compatibility/bitcoin-wallet/bitcoin-wallet.png b/img/compatibility/bitcoin-wallet/bitcoin-wallet.png deleted file mode 100644 index 720a163baa..0000000000 Binary files a/img/compatibility/bitcoin-wallet/bitcoin-wallet.png and /dev/null differ diff --git a/img/compatibility/bitgo/bitgo.png b/img/compatibility/bitgo/bitgo.png deleted file mode 100644 index 4513bee9a2..0000000000 Binary files a/img/compatibility/bitgo/bitgo.png and /dev/null differ diff --git a/img/compatibility/bitgo/rbf/notification-incoming-rbf.png b/img/compatibility/bitgo/rbf/notification-incoming-rbf.png deleted file mode 100644 index 63c9eff2c5..0000000000 Binary files a/img/compatibility/bitgo/rbf/notification-incoming-rbf.png and /dev/null differ diff --git a/img/compatibility/bitgo/rbf/send-screen.png b/img/compatibility/bitgo/rbf/send-screen.png deleted file mode 100644 index ce26015f81..0000000000 Binary files a/img/compatibility/bitgo/rbf/send-screen.png and /dev/null differ diff --git a/img/compatibility/bitgo/rbf/sent-confirmation.png b/img/compatibility/bitgo/rbf/sent-confirmation.png deleted file mode 100644 index 134358b230..0000000000 Binary files a/img/compatibility/bitgo/rbf/sent-confirmation.png and /dev/null differ diff --git a/img/compatibility/bitgo/rbf/transaction-list-incoming-rbf.png b/img/compatibility/bitgo/rbf/transaction-list-incoming-rbf.png deleted file mode 100644 index da61cb8a25..0000000000 Binary files a/img/compatibility/bitgo/rbf/transaction-list-incoming-rbf.png and /dev/null differ diff --git a/img/compatibility/bitgo/rbf/transaction-list-replacement-confirmed.png b/img/compatibility/bitgo/rbf/transaction-list-replacement-confirmed.png deleted file mode 100644 index a624068c44..0000000000 Binary files a/img/compatibility/bitgo/rbf/transaction-list-replacement-confirmed.png and /dev/null differ diff --git a/img/compatibility/bitgo/rbf/transaction-list-sent.png b/img/compatibility/bitgo/rbf/transaction-list-sent.png deleted file mode 100644 index 2b5fa93e2a..0000000000 Binary files a/img/compatibility/bitgo/rbf/transaction-list-sent.png and /dev/null differ diff --git a/img/compatibility/bitgo/segwit/receive-screen.png b/img/compatibility/bitgo/segwit/receive-screen.png deleted file mode 100644 index 815d6a8b6e..0000000000 Binary files a/img/compatibility/bitgo/segwit/receive-screen.png and /dev/null differ diff --git a/img/compatibility/bitgo/segwit/send-screen.png b/img/compatibility/bitgo/segwit/send-screen.png deleted file mode 100644 index 61cba53008..0000000000 Binary files a/img/compatibility/bitgo/segwit/send-screen.png and /dev/null differ diff --git a/img/compatibility/bitgo/segwit/send-v1.png b/img/compatibility/bitgo/segwit/send-v1.png deleted file mode 100644 index 49c9e5899e..0000000000 Binary files a/img/compatibility/bitgo/segwit/send-v1.png and /dev/null differ diff --git a/img/compatibility/bitmex/bitmex.png b/img/compatibility/bitmex/bitmex.png deleted file mode 100644 index fe9a81e350..0000000000 Binary files a/img/compatibility/bitmex/bitmex.png and /dev/null differ diff --git a/img/compatibility/bitmex/rbf/send-screen.png b/img/compatibility/bitmex/rbf/send-screen.png deleted file mode 100644 index b35c1c6090..0000000000 Binary files a/img/compatibility/bitmex/rbf/send-screen.png and /dev/null differ diff --git a/img/compatibility/bitmex/segwit/receive-screen.png b/img/compatibility/bitmex/segwit/receive-screen.png deleted file mode 100644 index 6278d51f41..0000000000 Binary files a/img/compatibility/bitmex/segwit/receive-screen.png and /dev/null differ diff --git a/img/compatibility/bitnob/bitnob.png b/img/compatibility/bitnob/bitnob.png deleted file mode 100644 index e02b31582a..0000000000 Binary files a/img/compatibility/bitnob/bitnob.png and /dev/null differ diff --git a/img/compatibility/bitnob/rbf/send-fee-notice.png b/img/compatibility/bitnob/rbf/send-fee-notice.png deleted file mode 100644 index 5999fdf9a5..0000000000 Binary files a/img/compatibility/bitnob/rbf/send-fee-notice.png and /dev/null differ diff --git a/img/compatibility/bitnob/rbf/transaction-list-incoming-rbf.png b/img/compatibility/bitnob/rbf/transaction-list-incoming-rbf.png deleted file mode 100644 index 9d2aa66559..0000000000 Binary files a/img/compatibility/bitnob/rbf/transaction-list-incoming-rbf.png and /dev/null differ diff --git a/img/compatibility/bitnob/segwit/receive-screen.png b/img/compatibility/bitnob/segwit/receive-screen.png deleted file mode 100644 index 31fbf4d86a..0000000000 Binary files a/img/compatibility/bitnob/segwit/receive-screen.png and /dev/null differ diff --git a/img/compatibility/bitnob/segwit/send-screen-default.png b/img/compatibility/bitnob/segwit/send-screen-default.png deleted file mode 100644 index 3870145f07..0000000000 Binary files a/img/compatibility/bitnob/segwit/send-screen-default.png and /dev/null differ diff --git a/img/compatibility/bitpowr/bitpowr.png b/img/compatibility/bitpowr/bitpowr.png deleted file mode 100644 index ac9aa20ac4..0000000000 Binary files a/img/compatibility/bitpowr/bitpowr.png and /dev/null differ diff --git a/img/compatibility/bitpowr/rbf/send-change-fee.png b/img/compatibility/bitpowr/rbf/send-change-fee.png deleted file mode 100644 index 70d25ea80b..0000000000 Binary files a/img/compatibility/bitpowr/rbf/send-change-fee.png and /dev/null differ diff --git a/img/compatibility/bitpowr/rbf/send-fee-notice.png b/img/compatibility/bitpowr/rbf/send-fee-notice.png deleted file mode 100644 index 0ea2e73514..0000000000 Binary files a/img/compatibility/bitpowr/rbf/send-fee-notice.png and /dev/null differ diff --git a/img/compatibility/bitpowr/rbf/send-screen-with-amount.png b/img/compatibility/bitpowr/rbf/send-screen-with-amount.png deleted file mode 100644 index 89c40b21bf..0000000000 Binary files a/img/compatibility/bitpowr/rbf/send-screen-with-amount.png and /dev/null differ diff --git a/img/compatibility/bitpowr/rbf/send-screen.png b/img/compatibility/bitpowr/rbf/send-screen.png deleted file mode 100644 index 29d613ffc9..0000000000 Binary files a/img/compatibility/bitpowr/rbf/send-screen.png and /dev/null differ diff --git a/img/compatibility/bitpowr/rbf/transactions-list.png b/img/compatibility/bitpowr/rbf/transactions-list.png deleted file mode 100644 index eaa0c1b9b4..0000000000 Binary files a/img/compatibility/bitpowr/rbf/transactions-list.png and /dev/null differ diff --git a/img/compatibility/bitpowr/segwit/receive-screen.png b/img/compatibility/bitpowr/segwit/receive-screen.png deleted file mode 100644 index 911b5dee25..0000000000 Binary files a/img/compatibility/bitpowr/segwit/receive-screen.png and /dev/null differ diff --git a/img/compatibility/bitpowr/segwit/send-change-segwit.png b/img/compatibility/bitpowr/segwit/send-change-segwit.png deleted file mode 100644 index 3c91cdb559..0000000000 Binary files a/img/compatibility/bitpowr/segwit/send-change-segwit.png and /dev/null differ diff --git a/img/compatibility/bitpowr/segwit/send-screen.png b/img/compatibility/bitpowr/segwit/send-screen.png deleted file mode 100644 index 29d613ffc9..0000000000 Binary files a/img/compatibility/bitpowr/segwit/send-screen.png and /dev/null differ diff --git a/img/compatibility/bitrefill/bitrefill.png b/img/compatibility/bitrefill/bitrefill.png deleted file mode 100644 index 9a72123f82..0000000000 Binary files a/img/compatibility/bitrefill/bitrefill.png and /dev/null differ diff --git a/img/compatibility/bitrefill/rbf/send-screen.png b/img/compatibility/bitrefill/rbf/send-screen.png deleted file mode 100644 index 78a3cdb8ce..0000000000 Binary files a/img/compatibility/bitrefill/rbf/send-screen.png and /dev/null differ diff --git a/img/compatibility/bitrefill/rbf/transaction-list-incoming-rbf.png b/img/compatibility/bitrefill/rbf/transaction-list-incoming-rbf.png deleted file mode 100644 index 19f37f19c5..0000000000 Binary files a/img/compatibility/bitrefill/rbf/transaction-list-incoming-rbf.png and /dev/null differ diff --git a/img/compatibility/bitrefill/rbf/transaction-list-incoming-replacement.png b/img/compatibility/bitrefill/rbf/transaction-list-incoming-replacement.png deleted file mode 100644 index d3c35969e9..0000000000 Binary files a/img/compatibility/bitrefill/rbf/transaction-list-incoming-replacement.png and /dev/null differ diff --git a/img/compatibility/bitrefill/rbf/transaction-list-replacement-confirmed.png b/img/compatibility/bitrefill/rbf/transaction-list-replacement-confirmed.png deleted file mode 100644 index f0c45e6e45..0000000000 Binary files a/img/compatibility/bitrefill/rbf/transaction-list-replacement-confirmed.png and /dev/null differ diff --git a/img/compatibility/bitrefill/rbf/transaction-list-sent.png b/img/compatibility/bitrefill/rbf/transaction-list-sent.png deleted file mode 100644 index 4e7e60cba0..0000000000 Binary files a/img/compatibility/bitrefill/rbf/transaction-list-sent.png and /dev/null differ diff --git a/img/compatibility/bitrefill/segwit/receive-screen.png b/img/compatibility/bitrefill/segwit/receive-screen.png deleted file mode 100644 index 7688f13363..0000000000 Binary files a/img/compatibility/bitrefill/segwit/receive-screen.png and /dev/null differ diff --git a/img/compatibility/bitrefill/segwit/send-screen.png b/img/compatibility/bitrefill/segwit/send-screen.png deleted file mode 100644 index a04aa28f68..0000000000 Binary files a/img/compatibility/bitrefill/segwit/send-screen.png and /dev/null differ diff --git a/img/compatibility/bitrefill/segwit/send-v1.png b/img/compatibility/bitrefill/segwit/send-v1.png deleted file mode 100644 index 4fc52f95e0..0000000000 Binary files a/img/compatibility/bitrefill/segwit/send-v1.png and /dev/null differ diff --git a/img/compatibility/bitstamp/bitstamp.png b/img/compatibility/bitstamp/bitstamp.png deleted file mode 100644 index 17c2e1bcb4..0000000000 Binary files a/img/compatibility/bitstamp/bitstamp.png and /dev/null differ diff --git a/img/compatibility/bitstamp/rbf/send-screen.png b/img/compatibility/bitstamp/rbf/send-screen.png deleted file mode 100644 index a87e08cf17..0000000000 Binary files a/img/compatibility/bitstamp/rbf/send-screen.png and /dev/null differ diff --git a/img/compatibility/bitstamp/rbf/transaction-list-incoming-rbf.png b/img/compatibility/bitstamp/rbf/transaction-list-incoming-rbf.png deleted file mode 100644 index 7ec418ccb0..0000000000 Binary files a/img/compatibility/bitstamp/rbf/transaction-list-incoming-rbf.png and /dev/null differ diff --git a/img/compatibility/bitstamp/rbf/transaction-list-replacement-confirmed.png b/img/compatibility/bitstamp/rbf/transaction-list-replacement-confirmed.png deleted file mode 100644 index f2da47bf6a..0000000000 Binary files a/img/compatibility/bitstamp/rbf/transaction-list-replacement-confirmed.png and /dev/null differ diff --git a/img/compatibility/bitstamp/rbf/transaction-list-sent.png b/img/compatibility/bitstamp/rbf/transaction-list-sent.png deleted file mode 100644 index 598f3a50cb..0000000000 Binary files a/img/compatibility/bitstamp/rbf/transaction-list-sent.png and /dev/null differ diff --git a/img/compatibility/bitstamp/segwit/receive-screen.png b/img/compatibility/bitstamp/segwit/receive-screen.png deleted file mode 100644 index 7d7d250ef6..0000000000 Binary files a/img/compatibility/bitstamp/segwit/receive-screen.png and /dev/null differ diff --git a/img/compatibility/blockchaininfo/blockchaininfo.png b/img/compatibility/blockchaininfo/blockchaininfo.png deleted file mode 100644 index 31858a081c..0000000000 Binary files a/img/compatibility/blockchaininfo/blockchaininfo.png and /dev/null differ diff --git a/img/compatibility/blockchaininfo/rbf/send-default-screen.png b/img/compatibility/blockchaininfo/rbf/send-default-screen.png deleted file mode 100644 index 2e02a72ef8..0000000000 Binary files a/img/compatibility/blockchaininfo/rbf/send-default-screen.png and /dev/null differ diff --git a/img/compatibility/blockchaininfo/rbf/send-screen-custom-fees.png b/img/compatibility/blockchaininfo/rbf/send-screen-custom-fees.png deleted file mode 100644 index 4778f29b6a..0000000000 Binary files a/img/compatibility/blockchaininfo/rbf/send-screen-custom-fees.png and /dev/null differ diff --git a/img/compatibility/blockchaininfo/rbf/transaction-list-incoming-rbf.png b/img/compatibility/blockchaininfo/rbf/transaction-list-incoming-rbf.png deleted file mode 100644 index ee07b2305d..0000000000 Binary files a/img/compatibility/blockchaininfo/rbf/transaction-list-incoming-rbf.png and /dev/null differ diff --git a/img/compatibility/blockchaininfo/rbf/transaction-list-sent.png b/img/compatibility/blockchaininfo/rbf/transaction-list-sent.png deleted file mode 100644 index 5c80bf0e12..0000000000 Binary files a/img/compatibility/blockchaininfo/rbf/transaction-list-sent.png and /dev/null differ diff --git a/img/compatibility/blockchaininfo/segwit/receive-screen.png b/img/compatibility/blockchaininfo/segwit/receive-screen.png deleted file mode 100644 index 4179069e7a..0000000000 Binary files a/img/compatibility/blockchaininfo/segwit/receive-screen.png and /dev/null differ diff --git a/img/compatibility/blockchaininfo/segwit/send-screen.png b/img/compatibility/blockchaininfo/segwit/send-screen.png deleted file mode 100644 index e8ec19bdf2..0000000000 Binary files a/img/compatibility/blockchaininfo/segwit/send-screen.png and /dev/null differ diff --git a/img/compatibility/blockchaininfo/segwit/send-v1-error.png b/img/compatibility/blockchaininfo/segwit/send-v1-error.png deleted file mode 100644 index 6424a670c0..0000000000 Binary files a/img/compatibility/blockchaininfo/segwit/send-v1-error.png and /dev/null differ diff --git a/img/compatibility/blocksettle/blocksettle.png b/img/compatibility/blocksettle/blocksettle.png deleted file mode 100644 index 1ea7dccaf3..0000000000 Binary files a/img/compatibility/blocksettle/blocksettle.png and /dev/null differ diff --git a/img/compatibility/blocksettle/rbf/RBF_change_outputs.png b/img/compatibility/blocksettle/rbf/RBF_change_outputs.png deleted file mode 100644 index 126f669891..0000000000 Binary files a/img/compatibility/blocksettle/rbf/RBF_change_outputs.png and /dev/null differ diff --git a/img/compatibility/blocksettle/rbf/RBF_default_check.png b/img/compatibility/blocksettle/rbf/RBF_default_check.png deleted file mode 100644 index db0c2a37ac..0000000000 Binary files a/img/compatibility/blocksettle/rbf/RBF_default_check.png and /dev/null differ diff --git a/img/compatibility/blocksettle/rbf/RBF_default_outputs.png b/img/compatibility/blocksettle/rbf/RBF_default_outputs.png deleted file mode 100644 index 5793c56245..0000000000 Binary files a/img/compatibility/blocksettle/rbf/RBF_default_outputs.png and /dev/null differ diff --git a/img/compatibility/blocksettle/rbf/RBF_desktop_notification.png b/img/compatibility/blocksettle/rbf/RBF_desktop_notification.png deleted file mode 100644 index 60b2f0a041..0000000000 Binary files a/img/compatibility/blocksettle/rbf/RBF_desktop_notification.png and /dev/null differ diff --git a/img/compatibility/blocksettle/rbf/RBF_right_click.png b/img/compatibility/blocksettle/rbf/RBF_right_click.png deleted file mode 100644 index 9d0d779095..0000000000 Binary files a/img/compatibility/blocksettle/rbf/RBF_right_click.png and /dev/null differ diff --git a/img/compatibility/blocksettle/rbf/RBF_txdetail_signalling.png b/img/compatibility/blocksettle/rbf/RBF_txdetail_signalling.png deleted file mode 100644 index 6faaed4727..0000000000 Binary files a/img/compatibility/blocksettle/rbf/RBF_txdetail_signalling.png and /dev/null differ diff --git a/img/compatibility/blocksettle/rbf/RBF_txdetails_send.png b/img/compatibility/blocksettle/rbf/RBF_txdetails_send.png deleted file mode 100644 index e587bcb4ca..0000000000 Binary files a/img/compatibility/blocksettle/rbf/RBF_txdetails_send.png and /dev/null differ diff --git a/img/compatibility/blocksettle/rbf/RBF_txlist_replacement.png b/img/compatibility/blocksettle/rbf/RBF_txlist_replacement.png deleted file mode 100644 index 91feacb2e2..0000000000 Binary files a/img/compatibility/blocksettle/rbf/RBF_txlist_replacement.png and /dev/null differ diff --git a/img/compatibility/blocksettle/rbf/RBF_txlist_signalling.png b/img/compatibility/blocksettle/rbf/RBF_txlist_signalling.png deleted file mode 100644 index e29d652fe8..0000000000 Binary files a/img/compatibility/blocksettle/rbf/RBF_txlist_signalling.png and /dev/null differ diff --git a/img/compatibility/blocksettle/rbf/RBF_txoverview.png b/img/compatibility/blocksettle/rbf/RBF_txoverview.png deleted file mode 100644 index 7545de92c8..0000000000 Binary files a/img/compatibility/blocksettle/rbf/RBF_txoverview.png and /dev/null differ diff --git a/img/compatibility/blocksettle/segwit/SegWit_change.png b/img/compatibility/blocksettle/segwit/SegWit_change.png deleted file mode 100644 index a4c3494a34..0000000000 Binary files a/img/compatibility/blocksettle/segwit/SegWit_change.png and /dev/null differ diff --git a/img/compatibility/blocksettle/segwit/SegWit_default.png b/img/compatibility/blocksettle/segwit/SegWit_default.png deleted file mode 100644 index c3d110fe5d..0000000000 Binary files a/img/compatibility/blocksettle/segwit/SegWit_default.png and /dev/null differ diff --git a/img/compatibility/blocksettle/segwit/SegWit_generate.png b/img/compatibility/blocksettle/segwit/SegWit_generate.png deleted file mode 100644 index 0a60e944e6..0000000000 Binary files a/img/compatibility/blocksettle/segwit/SegWit_generate.png and /dev/null differ diff --git a/img/compatibility/blocksettle/segwit/SegWit_send.png b/img/compatibility/blocksettle/segwit/SegWit_send.png deleted file mode 100644 index 9256f154bf..0000000000 Binary files a/img/compatibility/blocksettle/segwit/SegWit_send.png and /dev/null differ diff --git a/img/compatibility/blocksettle/segwit/SegWit_wallet_overview.png b/img/compatibility/blocksettle/segwit/SegWit_wallet_overview.png deleted file mode 100644 index b6a8674e03..0000000000 Binary files a/img/compatibility/blocksettle/segwit/SegWit_wallet_overview.png and /dev/null differ diff --git a/img/compatibility/casa/casa.png b/img/compatibility/casa/casa.png deleted file mode 100644 index 8d9a08c550..0000000000 Binary files a/img/compatibility/casa/casa.png and /dev/null differ diff --git a/img/compatibility/casa/rbf/approve-send-transaction.png b/img/compatibility/casa/rbf/approve-send-transaction.png deleted file mode 100644 index 891bd51dbb..0000000000 Binary files a/img/compatibility/casa/rbf/approve-send-transaction.png and /dev/null differ diff --git a/img/compatibility/casa/rbf/transaction-list.png b/img/compatibility/casa/rbf/transaction-list.png deleted file mode 100644 index 660f46a48d..0000000000 Binary files a/img/compatibility/casa/rbf/transaction-list.png and /dev/null differ diff --git a/img/compatibility/casa/segwit/receive-p2sh-wrapped-segwit.png b/img/compatibility/casa/segwit/receive-p2sh-wrapped-segwit.png deleted file mode 100644 index 76bdc0ae31..0000000000 Binary files a/img/compatibility/casa/segwit/receive-p2sh-wrapped-segwit.png and /dev/null differ diff --git a/img/compatibility/casa/segwit/send-to-bech32.png b/img/compatibility/casa/segwit/send-to-bech32.png deleted file mode 100644 index 34a0ae5ff8..0000000000 Binary files a/img/compatibility/casa/segwit/send-to-bech32.png and /dev/null differ diff --git a/img/compatibility/cashapp/cashapp.png b/img/compatibility/cashapp/cashapp.png deleted file mode 100644 index aa37467e5e..0000000000 Binary files a/img/compatibility/cashapp/cashapp.png and /dev/null differ diff --git a/img/compatibility/cashapp/rbf/incoming-notification.png b/img/compatibility/cashapp/rbf/incoming-notification.png deleted file mode 100644 index 8cd4e920dc..0000000000 Binary files a/img/compatibility/cashapp/rbf/incoming-notification.png and /dev/null differ diff --git a/img/compatibility/cashapp/rbf/send-confirm.png b/img/compatibility/cashapp/rbf/send-confirm.png deleted file mode 100644 index f0e8f80859..0000000000 Binary files a/img/compatibility/cashapp/rbf/send-confirm.png and /dev/null differ diff --git a/img/compatibility/cashapp/rbf/send-screen-default.png b/img/compatibility/cashapp/rbf/send-screen-default.png deleted file mode 100644 index a5d3c97b3a..0000000000 Binary files a/img/compatibility/cashapp/rbf/send-screen-default.png and /dev/null differ diff --git a/img/compatibility/cashapp/rbf/transaction-details-incoming.png b/img/compatibility/cashapp/rbf/transaction-details-incoming.png deleted file mode 100644 index 5527ffd17b..0000000000 Binary files a/img/compatibility/cashapp/rbf/transaction-details-incoming.png and /dev/null differ diff --git a/img/compatibility/cashapp/rbf/transaction-details-sent.png b/img/compatibility/cashapp/rbf/transaction-details-sent.png deleted file mode 100644 index f688c7ddb4..0000000000 Binary files a/img/compatibility/cashapp/rbf/transaction-details-sent.png and /dev/null differ diff --git a/img/compatibility/cashapp/rbf/transaction-list-incoming.png b/img/compatibility/cashapp/rbf/transaction-list-incoming.png deleted file mode 100644 index 6ddd69ff1c..0000000000 Binary files a/img/compatibility/cashapp/rbf/transaction-list-incoming.png and /dev/null differ diff --git a/img/compatibility/cashapp/rbf/transaction-list-sent.png b/img/compatibility/cashapp/rbf/transaction-list-sent.png deleted file mode 100644 index fe25d60fac..0000000000 Binary files a/img/compatibility/cashapp/rbf/transaction-list-sent.png and /dev/null differ diff --git a/img/compatibility/cashapp/segwit/receive-screen.png b/img/compatibility/cashapp/segwit/receive-screen.png deleted file mode 100644 index 17fa7c6072..0000000000 Binary files a/img/compatibility/cashapp/segwit/receive-screen.png and /dev/null differ diff --git a/img/compatibility/cashapp/segwit/send-confirm.png b/img/compatibility/cashapp/segwit/send-confirm.png deleted file mode 100644 index 36a5330051..0000000000 Binary files a/img/compatibility/cashapp/segwit/send-confirm.png and /dev/null differ diff --git a/img/compatibility/cashapp/segwit/send-screen.png b/img/compatibility/cashapp/segwit/send-screen.png deleted file mode 100644 index 121de5c235..0000000000 Binary files a/img/compatibility/cashapp/segwit/send-screen.png and /dev/null differ diff --git a/img/compatibility/coinbase/coinbase.png b/img/compatibility/coinbase/coinbase.png deleted file mode 100644 index 9c773f90ee..0000000000 Binary files a/img/compatibility/coinbase/coinbase.png and /dev/null differ diff --git a/img/compatibility/coinbase/rbf/send-confirm.png b/img/compatibility/coinbase/rbf/send-confirm.png deleted file mode 100644 index dc750ce81a..0000000000 Binary files a/img/compatibility/coinbase/rbf/send-confirm.png and /dev/null differ diff --git a/img/compatibility/coinbase/rbf/send-screen-default.png b/img/compatibility/coinbase/rbf/send-screen-default.png deleted file mode 100644 index d3e6a62dc4..0000000000 Binary files a/img/compatibility/coinbase/rbf/send-screen-default.png and /dev/null differ diff --git a/img/compatibility/coinbase/rbf/transaction-details-incoming-rbf.png b/img/compatibility/coinbase/rbf/transaction-details-incoming-rbf.png deleted file mode 100644 index d84313688e..0000000000 Binary files a/img/compatibility/coinbase/rbf/transaction-details-incoming-rbf.png and /dev/null differ diff --git a/img/compatibility/coinbase/rbf/transaction-details-sent-2.png b/img/compatibility/coinbase/rbf/transaction-details-sent-2.png deleted file mode 100644 index c05734a95e..0000000000 Binary files a/img/compatibility/coinbase/rbf/transaction-details-sent-2.png and /dev/null differ diff --git a/img/compatibility/coinbase/rbf/transaction-details-sent.png b/img/compatibility/coinbase/rbf/transaction-details-sent.png deleted file mode 100644 index 1873e8a8ce..0000000000 Binary files a/img/compatibility/coinbase/rbf/transaction-details-sent.png and /dev/null differ diff --git a/img/compatibility/coinbase/rbf/transaction-list-incoming-rbf.png b/img/compatibility/coinbase/rbf/transaction-list-incoming-rbf.png deleted file mode 100644 index 89dc629676..0000000000 Binary files a/img/compatibility/coinbase/rbf/transaction-list-incoming-rbf.png and /dev/null differ diff --git a/img/compatibility/coinbase/rbf/transaction-list-incoming-replacement.png b/img/compatibility/coinbase/rbf/transaction-list-incoming-replacement.png deleted file mode 100644 index 18156bec21..0000000000 Binary files a/img/compatibility/coinbase/rbf/transaction-list-incoming-replacement.png and /dev/null differ diff --git a/img/compatibility/coinbase/segwit/change-address.png b/img/compatibility/coinbase/segwit/change-address.png deleted file mode 100644 index 7522a02691..0000000000 Binary files a/img/compatibility/coinbase/segwit/change-address.png and /dev/null differ diff --git a/img/compatibility/coinbase/segwit/receive-screen.png b/img/compatibility/coinbase/segwit/receive-screen.png deleted file mode 100644 index 662ed339e9..0000000000 Binary files a/img/compatibility/coinbase/segwit/receive-screen.png and /dev/null differ diff --git a/img/compatibility/coinbase/segwit/send-screen.png b/img/compatibility/coinbase/segwit/send-screen.png deleted file mode 100644 index 10a2ef00f3..0000000000 Binary files a/img/compatibility/coinbase/segwit/send-screen.png and /dev/null differ diff --git a/img/compatibility/coinbase/segwit/send-segwit-v1.png b/img/compatibility/coinbase/segwit/send-segwit-v1.png deleted file mode 100644 index 78f21cca3d..0000000000 Binary files a/img/compatibility/coinbase/segwit/send-segwit-v1.png and /dev/null differ diff --git a/img/compatibility/coinbase/segwit/transaction-details-sent.png b/img/compatibility/coinbase/segwit/transaction-details-sent.png deleted file mode 100644 index 01980dff34..0000000000 Binary files a/img/compatibility/coinbase/segwit/transaction-details-sent.png and /dev/null differ diff --git a/img/compatibility/conio/conio.png b/img/compatibility/conio/conio.png deleted file mode 100644 index dce78d2289..0000000000 Binary files a/img/compatibility/conio/conio.png and /dev/null differ diff --git a/img/compatibility/conio/rbf/notification-incoming-rbf.png b/img/compatibility/conio/rbf/notification-incoming-rbf.png deleted file mode 100644 index 85c753b872..0000000000 Binary files a/img/compatibility/conio/rbf/notification-incoming-rbf.png and /dev/null differ diff --git a/img/compatibility/conio/rbf/notification-replacement.png b/img/compatibility/conio/rbf/notification-replacement.png deleted file mode 100644 index 359c695902..0000000000 Binary files a/img/compatibility/conio/rbf/notification-replacement.png and /dev/null differ diff --git a/img/compatibility/conio/rbf/send-screen-default.png b/img/compatibility/conio/rbf/send-screen-default.png deleted file mode 100644 index 8b77f62260..0000000000 Binary files a/img/compatibility/conio/rbf/send-screen-default.png and /dev/null differ diff --git a/img/compatibility/conio/rbf/transaction-details-incoming-rbf-2.png b/img/compatibility/conio/rbf/transaction-details-incoming-rbf-2.png deleted file mode 100644 index 31f42c1f43..0000000000 Binary files a/img/compatibility/conio/rbf/transaction-details-incoming-rbf-2.png and /dev/null differ diff --git a/img/compatibility/conio/rbf/transaction-details-incoming-rbf-3.png b/img/compatibility/conio/rbf/transaction-details-incoming-rbf-3.png deleted file mode 100644 index 4f672be05f..0000000000 Binary files a/img/compatibility/conio/rbf/transaction-details-incoming-rbf-3.png and /dev/null differ diff --git a/img/compatibility/conio/rbf/transaction-details-incoming-rbf-receive-faster.png b/img/compatibility/conio/rbf/transaction-details-incoming-rbf-receive-faster.png deleted file mode 100644 index dfb3420efb..0000000000 Binary files a/img/compatibility/conio/rbf/transaction-details-incoming-rbf-receive-faster.png and /dev/null differ diff --git a/img/compatibility/conio/rbf/transaction-details-incoming-rbf.png b/img/compatibility/conio/rbf/transaction-details-incoming-rbf.png deleted file mode 100644 index 60b8596bb3..0000000000 Binary files a/img/compatibility/conio/rbf/transaction-details-incoming-rbf.png and /dev/null differ diff --git a/img/compatibility/conio/rbf/transaction-details-replacement.png b/img/compatibility/conio/rbf/transaction-details-replacement.png deleted file mode 100644 index 876e2e6702..0000000000 Binary files a/img/compatibility/conio/rbf/transaction-details-replacement.png and /dev/null differ diff --git a/img/compatibility/conio/rbf/transaction-details-sent.png b/img/compatibility/conio/rbf/transaction-details-sent.png deleted file mode 100644 index 7b3fdfd271..0000000000 Binary files a/img/compatibility/conio/rbf/transaction-details-sent.png and /dev/null differ diff --git a/img/compatibility/conio/rbf/transaction-list-incoming-rbf.png b/img/compatibility/conio/rbf/transaction-list-incoming-rbf.png deleted file mode 100644 index ae7fed2ff5..0000000000 Binary files a/img/compatibility/conio/rbf/transaction-list-incoming-rbf.png and /dev/null differ diff --git a/img/compatibility/conio/rbf/transaction-list-incoming-replacement.png b/img/compatibility/conio/rbf/transaction-list-incoming-replacement.png deleted file mode 100644 index 861998e356..0000000000 Binary files a/img/compatibility/conio/rbf/transaction-list-incoming-replacement.png and /dev/null differ diff --git a/img/compatibility/conio/rbf/transaction-list-replacement-confirmed.png b/img/compatibility/conio/rbf/transaction-list-replacement-confirmed.png deleted file mode 100644 index b55854f7c0..0000000000 Binary files a/img/compatibility/conio/rbf/transaction-list-replacement-confirmed.png and /dev/null differ diff --git a/img/compatibility/conio/segwit/receive-screen.png b/img/compatibility/conio/segwit/receive-screen.png deleted file mode 100644 index 952a064edf..0000000000 Binary files a/img/compatibility/conio/segwit/receive-screen.png and /dev/null differ diff --git a/img/compatibility/conio/segwit/send-screen-segwitv1-error.png b/img/compatibility/conio/segwit/send-screen-segwitv1-error.png deleted file mode 100644 index c8fda55f03..0000000000 Binary files a/img/compatibility/conio/segwit/send-screen-segwitv1-error.png and /dev/null differ diff --git a/img/compatibility/conio/segwit/send-screen.png b/img/compatibility/conio/segwit/send-screen.png deleted file mode 100644 index 20c9360a95..0000000000 Binary files a/img/compatibility/conio/segwit/send-screen.png and /dev/null differ diff --git a/img/compatibility/copay/copay.png b/img/compatibility/copay/copay.png deleted file mode 100644 index c8d2d65d27..0000000000 Binary files a/img/compatibility/copay/copay.png and /dev/null differ diff --git a/img/compatibility/copay/rbf/default-send-screen.png b/img/compatibility/copay/rbf/default-send-screen.png deleted file mode 100644 index 16fc6f08f3..0000000000 Binary files a/img/compatibility/copay/rbf/default-send-screen.png and /dev/null differ diff --git a/img/compatibility/copay/rbf/send-dialog-custom-fee-level.png b/img/compatibility/copay/rbf/send-dialog-custom-fee-level.png deleted file mode 100644 index 44f868dcd4..0000000000 Binary files a/img/compatibility/copay/rbf/send-dialog-custom-fee-level.png and /dev/null differ diff --git a/img/compatibility/copay/rbf/send-fee-level-options.png b/img/compatibility/copay/rbf/send-fee-level-options.png deleted file mode 100644 index ee6a50d9f4..0000000000 Binary files a/img/compatibility/copay/rbf/send-fee-level-options.png and /dev/null differ diff --git a/img/compatibility/copay/rbf/send-miner-fee-options.png b/img/compatibility/copay/rbf/send-miner-fee-options.png deleted file mode 100644 index 7f9d2f829f..0000000000 Binary files a/img/compatibility/copay/rbf/send-miner-fee-options.png and /dev/null differ diff --git a/img/compatibility/copay/rbf/transaction-details-incoming-rbf.png b/img/compatibility/copay/rbf/transaction-details-incoming-rbf.png deleted file mode 100644 index 71533a9a93..0000000000 Binary files a/img/compatibility/copay/rbf/transaction-details-incoming-rbf.png and /dev/null differ diff --git a/img/compatibility/copay/rbf/transaction-details-sent-warning.png b/img/compatibility/copay/rbf/transaction-details-sent-warning.png deleted file mode 100644 index cb44d46e94..0000000000 Binary files a/img/compatibility/copay/rbf/transaction-details-sent-warning.png and /dev/null differ diff --git a/img/compatibility/copay/rbf/transaction-details-sent.png b/img/compatibility/copay/rbf/transaction-details-sent.png deleted file mode 100644 index aa4563dcb0..0000000000 Binary files a/img/compatibility/copay/rbf/transaction-details-sent.png and /dev/null differ diff --git a/img/compatibility/copay/rbf/transaction-list-incoming-rbf.png b/img/compatibility/copay/rbf/transaction-list-incoming-rbf.png deleted file mode 100644 index 802c8d607f..0000000000 Binary files a/img/compatibility/copay/rbf/transaction-list-incoming-rbf.png and /dev/null differ diff --git a/img/compatibility/copay/rbf/transaction-list-sent.png b/img/compatibility/copay/rbf/transaction-list-sent.png deleted file mode 100644 index 0a8f3ac926..0000000000 Binary files a/img/compatibility/copay/rbf/transaction-list-sent.png and /dev/null differ diff --git a/img/compatibility/copay/segwit/receive-screen.png b/img/compatibility/copay/segwit/receive-screen.png deleted file mode 100644 index 0f6b925ec3..0000000000 Binary files a/img/compatibility/copay/segwit/receive-screen.png and /dev/null differ diff --git a/img/compatibility/copay/segwit/send-screen.png b/img/compatibility/copay/segwit/send-screen.png deleted file mode 100644 index 466e3f3c99..0000000000 Binary files a/img/compatibility/copay/segwit/send-screen.png and /dev/null differ diff --git a/img/compatibility/edge/edge.png b/img/compatibility/edge/edge.png deleted file mode 100644 index 55965d4d00..0000000000 Binary files a/img/compatibility/edge/edge.png and /dev/null differ diff --git a/img/compatibility/edge/rbf/send-change-mining-fee.png b/img/compatibility/edge/rbf/send-change-mining-fee.png deleted file mode 100644 index f56abb14ae..0000000000 Binary files a/img/compatibility/edge/rbf/send-change-mining-fee.png and /dev/null differ diff --git a/img/compatibility/edge/rbf/send-context-fees-menu.png b/img/compatibility/edge/rbf/send-context-fees-menu.png deleted file mode 100644 index 799072edcb..0000000000 Binary files a/img/compatibility/edge/rbf/send-context-fees-menu.png and /dev/null differ diff --git a/img/compatibility/edge/rbf/send-custom-mining-fee.png b/img/compatibility/edge/rbf/send-custom-mining-fee.png deleted file mode 100644 index 15c2847cfe..0000000000 Binary files a/img/compatibility/edge/rbf/send-custom-mining-fee.png and /dev/null differ diff --git a/img/compatibility/edge/rbf/send-screen-default.png b/img/compatibility/edge/rbf/send-screen-default.png deleted file mode 100644 index 495c1ba2bc..0000000000 Binary files a/img/compatibility/edge/rbf/send-screen-default.png and /dev/null differ diff --git a/img/compatibility/edge/rbf/transaction-details-incoming-rbf-advanced.png b/img/compatibility/edge/rbf/transaction-details-incoming-rbf-advanced.png deleted file mode 100644 index fd0cd00f02..0000000000 Binary files a/img/compatibility/edge/rbf/transaction-details-incoming-rbf-advanced.png and /dev/null differ diff --git a/img/compatibility/edge/rbf/transaction-details-incoming-rbf.png b/img/compatibility/edge/rbf/transaction-details-incoming-rbf.png deleted file mode 100644 index 49f9f5f1df..0000000000 Binary files a/img/compatibility/edge/rbf/transaction-details-incoming-rbf.png and /dev/null differ diff --git a/img/compatibility/edge/rbf/transaction-details-sent.png b/img/compatibility/edge/rbf/transaction-details-sent.png deleted file mode 100644 index 4edbaed777..0000000000 Binary files a/img/compatibility/edge/rbf/transaction-details-sent.png and /dev/null differ diff --git a/img/compatibility/edge/rbf/transaction-list-incoming-replacement.png b/img/compatibility/edge/rbf/transaction-list-incoming-replacement.png deleted file mode 100644 index 20900b2c1b..0000000000 Binary files a/img/compatibility/edge/rbf/transaction-list-incoming-replacement.png and /dev/null differ diff --git a/img/compatibility/edge/segwit/receive-screen.png b/img/compatibility/edge/segwit/receive-screen.png deleted file mode 100644 index 1033a3adc5..0000000000 Binary files a/img/compatibility/edge/segwit/receive-screen.png and /dev/null differ diff --git a/img/compatibility/edge/segwit/send-screen.png b/img/compatibility/edge/segwit/send-screen.png deleted file mode 100644 index 337efab2d6..0000000000 Binary files a/img/compatibility/edge/segwit/send-screen.png and /dev/null differ diff --git a/img/compatibility/edge/segwit/transaction-list-segwit-v1-pending.png b/img/compatibility/edge/segwit/transaction-list-segwit-v1-pending.png deleted file mode 100644 index 61c3527fc9..0000000000 Binary files a/img/compatibility/edge/segwit/transaction-list-segwit-v1-pending.png and /dev/null differ diff --git a/img/compatibility/edge/segwit/wallet-creation-screen.png b/img/compatibility/edge/segwit/wallet-creation-screen.png deleted file mode 100644 index e74f1dea50..0000000000 Binary files a/img/compatibility/edge/segwit/wallet-creation-screen.png and /dev/null differ diff --git a/img/compatibility/electrum/electrum.png b/img/compatibility/electrum/electrum.png deleted file mode 100644 index 7b55dd4d0e..0000000000 Binary files a/img/compatibility/electrum/electrum.png and /dev/null differ diff --git a/img/compatibility/electrum/rbf/alert-incoming-replacement-tx.png b/img/compatibility/electrum/rbf/alert-incoming-replacement-tx.png deleted file mode 100644 index 16f4585966..0000000000 Binary files a/img/compatibility/electrum/rbf/alert-incoming-replacement-tx.png and /dev/null differ diff --git a/img/compatibility/electrum/rbf/default-wallet-send-screen.png b/img/compatibility/electrum/rbf/default-wallet-send-screen.png deleted file mode 100644 index 3f8dce898b..0000000000 Binary files a/img/compatibility/electrum/rbf/default-wallet-send-screen.png and /dev/null differ diff --git a/img/compatibility/electrum/rbf/dialog-bumped-fee-input.png b/img/compatibility/electrum/rbf/dialog-bumped-fee-input.png deleted file mode 100644 index 476ad2a263..0000000000 Binary files a/img/compatibility/electrum/rbf/dialog-bumped-fee-input.png and /dev/null differ diff --git a/img/compatibility/electrum/rbf/incoming-transaction-alert.png b/img/compatibility/electrum/rbf/incoming-transaction-alert.png deleted file mode 100644 index a6447b4566..0000000000 Binary files a/img/compatibility/electrum/rbf/incoming-transaction-alert.png and /dev/null differ diff --git a/img/compatibility/electrum/rbf/preference-rbf-checkbox.png b/img/compatibility/electrum/rbf/preference-rbf-checkbox.png deleted file mode 100644 index 9958f33bba..0000000000 Binary files a/img/compatibility/electrum/rbf/preference-rbf-checkbox.png and /dev/null differ diff --git a/img/compatibility/electrum/rbf/transaction-details-incoming-replacement.png b/img/compatibility/electrum/rbf/transaction-details-incoming-replacement.png deleted file mode 100644 index ad5eaab305..0000000000 Binary files a/img/compatibility/electrum/rbf/transaction-details-incoming-replacement.png and /dev/null differ diff --git a/img/compatibility/electrum/rbf/transaction-details-incoming.png b/img/compatibility/electrum/rbf/transaction-details-incoming.png deleted file mode 100644 index 5273d41ee1..0000000000 Binary files a/img/compatibility/electrum/rbf/transaction-details-incoming.png and /dev/null differ diff --git a/img/compatibility/electrum/rbf/transaction-details-outgoing-rbf-transaction.png b/img/compatibility/electrum/rbf/transaction-details-outgoing-rbf-transaction.png deleted file mode 100644 index 217a248b83..0000000000 Binary files a/img/compatibility/electrum/rbf/transaction-details-outgoing-rbf-transaction.png and /dev/null differ diff --git a/img/compatibility/electrum/rbf/transaction-details-replacement-tx.png b/img/compatibility/electrum/rbf/transaction-details-replacement-tx.png deleted file mode 100644 index 813d9114f1..0000000000 Binary files a/img/compatibility/electrum/rbf/transaction-details-replacement-tx.png and /dev/null differ diff --git a/img/compatibility/electrum/rbf/transaction-list-context-menu-increase-fee.png b/img/compatibility/electrum/rbf/transaction-list-context-menu-increase-fee.png deleted file mode 100644 index dc8ff88208..0000000000 Binary files a/img/compatibility/electrum/rbf/transaction-list-context-menu-increase-fee.png and /dev/null differ diff --git a/img/compatibility/electrum/rbf/transaction-list-outgoing-rbf-transaction.png b/img/compatibility/electrum/rbf/transaction-list-outgoing-rbf-transaction.png deleted file mode 100644 index 7231f7ad90..0000000000 Binary files a/img/compatibility/electrum/rbf/transaction-list-outgoing-rbf-transaction.png and /dev/null differ diff --git a/img/compatibility/electrum/rbf/transaction-list-rbf-noted.png b/img/compatibility/electrum/rbf/transaction-list-rbf-noted.png deleted file mode 100644 index 26ac92a8bb..0000000000 Binary files a/img/compatibility/electrum/rbf/transaction-list-rbf-noted.png and /dev/null differ diff --git a/img/compatibility/electrum/rbf/transaction-list-replacement-tx-only.png b/img/compatibility/electrum/rbf/transaction-list-replacement-tx-only.png deleted file mode 100644 index a88d7c222c..0000000000 Binary files a/img/compatibility/electrum/rbf/transaction-list-replacement-tx-only.png and /dev/null differ diff --git a/img/compatibility/electrum/rbf/transaction-list-replacement-tx.png b/img/compatibility/electrum/rbf/transaction-list-replacement-tx.png deleted file mode 100644 index 36e1b4f4c8..0000000000 Binary files a/img/compatibility/electrum/rbf/transaction-list-replacement-tx.png and /dev/null differ diff --git a/img/compatibility/electrum/segwit/address-list.png b/img/compatibility/electrum/segwit/address-list.png deleted file mode 100644 index 8dd1910b9a..0000000000 Binary files a/img/compatibility/electrum/segwit/address-list.png and /dev/null differ diff --git a/img/compatibility/electrum/segwit/create-wallet-p2sh-wrapped.png b/img/compatibility/electrum/segwit/create-wallet-p2sh-wrapped.png deleted file mode 100644 index f33df744fb..0000000000 Binary files a/img/compatibility/electrum/segwit/create-wallet-p2sh-wrapped.png and /dev/null differ diff --git a/img/compatibility/electrum/segwit/create-wallet.png b/img/compatibility/electrum/segwit/create-wallet.png deleted file mode 100644 index 3fbb037d0f..0000000000 Binary files a/img/compatibility/electrum/segwit/create-wallet.png and /dev/null differ diff --git a/img/compatibility/electrum/segwit/receive-screen.png b/img/compatibility/electrum/segwit/receive-screen.png deleted file mode 100644 index c04b72e78d..0000000000 Binary files a/img/compatibility/electrum/segwit/receive-screen.png and /dev/null differ diff --git a/img/compatibility/electrum/segwit/send-screen.png b/img/compatibility/electrum/segwit/send-screen.png deleted file mode 100644 index 75857e22b1..0000000000 Binary files a/img/compatibility/electrum/segwit/send-screen.png and /dev/null differ diff --git a/img/compatibility/electrum/segwit/send-segwit-v1-error.png b/img/compatibility/electrum/segwit/send-segwit-v1-error.png deleted file mode 100644 index aeab09eef8..0000000000 Binary files a/img/compatibility/electrum/segwit/send-segwit-v1-error.png and /dev/null differ diff --git a/img/compatibility/greenaddress/greenaddress.png b/img/compatibility/greenaddress/greenaddress.png deleted file mode 100644 index 52d19a2c56..0000000000 Binary files a/img/compatibility/greenaddress/greenaddress.png and /dev/null differ diff --git a/img/compatibility/greenaddress/rbf/2fa-prompt.png b/img/compatibility/greenaddress/rbf/2fa-prompt.png deleted file mode 100644 index 0e247020b7..0000000000 Binary files a/img/compatibility/greenaddress/rbf/2fa-prompt.png and /dev/null differ diff --git a/img/compatibility/greenaddress/rbf/default-send-transaction-screen.png b/img/compatibility/greenaddress/rbf/default-send-transaction-screen.png deleted file mode 100644 index 0d5eb30e14..0000000000 Binary files a/img/compatibility/greenaddress/rbf/default-send-transaction-screen.png and /dev/null differ diff --git a/img/compatibility/greenaddress/rbf/replacement-transaction-details.png b/img/compatibility/greenaddress/rbf/replacement-transaction-details.png deleted file mode 100644 index 93373d1a0a..0000000000 Binary files a/img/compatibility/greenaddress/rbf/replacement-transaction-details.png and /dev/null differ diff --git a/img/compatibility/greenaddress/rbf/send-transaction-screen-advanced.png b/img/compatibility/greenaddress/rbf/send-transaction-screen-advanced.png deleted file mode 100644 index 1aad391e59..0000000000 Binary files a/img/compatibility/greenaddress/rbf/send-transaction-screen-advanced.png and /dev/null differ diff --git a/img/compatibility/greenaddress/rbf/sending-relay-fee-error-message.png b/img/compatibility/greenaddress/rbf/sending-relay-fee-error-message.png deleted file mode 100644 index c0bac85ee5..0000000000 Binary files a/img/compatibility/greenaddress/rbf/sending-relay-fee-error-message.png and /dev/null differ diff --git a/img/compatibility/greenaddress/rbf/sent-transaction-details.png b/img/compatibility/greenaddress/rbf/sent-transaction-details.png deleted file mode 100644 index a00e0206df..0000000000 Binary files a/img/compatibility/greenaddress/rbf/sent-transaction-details.png and /dev/null differ diff --git a/img/compatibility/greenaddress/rbf/settings-transaction-replacement.png b/img/compatibility/greenaddress/rbf/settings-transaction-replacement.png deleted file mode 100644 index d48f62b4d3..0000000000 Binary files a/img/compatibility/greenaddress/rbf/settings-transaction-replacement.png and /dev/null differ diff --git a/img/compatibility/greenaddress/rbf/transaction-details-bumped-confirmed-tx.png b/img/compatibility/greenaddress/rbf/transaction-details-bumped-confirmed-tx.png deleted file mode 100644 index 167206fb9f..0000000000 Binary files a/img/compatibility/greenaddress/rbf/transaction-details-bumped-confirmed-tx.png and /dev/null differ diff --git a/img/compatibility/greenaddress/rbf/transaction-details-incoming-original-tx-1.png b/img/compatibility/greenaddress/rbf/transaction-details-incoming-original-tx-1.png deleted file mode 100644 index a0df8c8b5d..0000000000 Binary files a/img/compatibility/greenaddress/rbf/transaction-details-incoming-original-tx-1.png and /dev/null differ diff --git a/img/compatibility/greenaddress/rbf/transaction-details-incoming-original-tx-2.png b/img/compatibility/greenaddress/rbf/transaction-details-incoming-original-tx-2.png deleted file mode 100644 index 7890adad6b..0000000000 Binary files a/img/compatibility/greenaddress/rbf/transaction-details-incoming-original-tx-2.png and /dev/null differ diff --git a/img/compatibility/greenaddress/rbf/transaction-details-incoming-replacement-tx-1.png b/img/compatibility/greenaddress/rbf/transaction-details-incoming-replacement-tx-1.png deleted file mode 100644 index 7bb0142f40..0000000000 Binary files a/img/compatibility/greenaddress/rbf/transaction-details-incoming-replacement-tx-1.png and /dev/null differ diff --git a/img/compatibility/greenaddress/rbf/transaction-details-incoming-replacement-tx-2.png b/img/compatibility/greenaddress/rbf/transaction-details-incoming-replacement-tx-2.png deleted file mode 100644 index 631748c4ce..0000000000 Binary files a/img/compatibility/greenaddress/rbf/transaction-details-incoming-replacement-tx-2.png and /dev/null differ diff --git a/img/compatibility/greenaddress/rbf/transaction-details-original-tx.png b/img/compatibility/greenaddress/rbf/transaction-details-original-tx.png deleted file mode 100644 index 10e432fe9d..0000000000 Binary files a/img/compatibility/greenaddress/rbf/transaction-details-original-tx.png and /dev/null differ diff --git a/img/compatibility/greenaddress/rbf/transaction-details-rbf-incoming-1.png b/img/compatibility/greenaddress/rbf/transaction-details-rbf-incoming-1.png deleted file mode 100644 index 47ca3dcbab..0000000000 Binary files a/img/compatibility/greenaddress/rbf/transaction-details-rbf-incoming-1.png and /dev/null differ diff --git a/img/compatibility/greenaddress/rbf/transaction-details-rbf-incoming-2.png b/img/compatibility/greenaddress/rbf/transaction-details-rbf-incoming-2.png deleted file mode 100644 index dfb98984a2..0000000000 Binary files a/img/compatibility/greenaddress/rbf/transaction-details-rbf-incoming-2.png and /dev/null differ diff --git a/img/compatibility/greenaddress/rbf/transaction-details-replacement-tx.png b/img/compatibility/greenaddress/rbf/transaction-details-replacement-tx.png deleted file mode 100644 index c9a19eca29..0000000000 Binary files a/img/compatibility/greenaddress/rbf/transaction-details-replacement-tx.png and /dev/null differ diff --git a/img/compatibility/greenaddress/rbf/transaction-list-bump-fee-context-menu.png b/img/compatibility/greenaddress/rbf/transaction-list-bump-fee-context-menu.png deleted file mode 100644 index 95cdff433d..0000000000 Binary files a/img/compatibility/greenaddress/rbf/transaction-list-bump-fee-context-menu.png and /dev/null differ diff --git a/img/compatibility/greenaddress/rbf/transaction-list-bump-fee.png b/img/compatibility/greenaddress/rbf/transaction-list-bump-fee.png deleted file mode 100644 index 4540665a5d..0000000000 Binary files a/img/compatibility/greenaddress/rbf/transaction-list-bump-fee.png and /dev/null differ diff --git a/img/compatibility/greenaddress/rbf/transaction-list-incoming-replacement-tx.png b/img/compatibility/greenaddress/rbf/transaction-list-incoming-replacement-tx.png deleted file mode 100644 index 0fd9e0b055..0000000000 Binary files a/img/compatibility/greenaddress/rbf/transaction-list-incoming-replacement-tx.png and /dev/null differ diff --git a/img/compatibility/greenaddress/rbf/transaction-list-rbf-incoming.png b/img/compatibility/greenaddress/rbf/transaction-list-rbf-incoming.png deleted file mode 100644 index 20a2059cc9..0000000000 Binary files a/img/compatibility/greenaddress/rbf/transaction-list-rbf-incoming.png and /dev/null differ diff --git a/img/compatibility/greenaddress/rbf/transaction-list-replacement-confirmed.png b/img/compatibility/greenaddress/rbf/transaction-list-replacement-confirmed.png deleted file mode 100644 index 4022be72b8..0000000000 Binary files a/img/compatibility/greenaddress/rbf/transaction-list-replacement-confirmed.png and /dev/null differ diff --git a/img/compatibility/greenaddress/rbf/transaction-list-replacement-tx.png b/img/compatibility/greenaddress/rbf/transaction-list-replacement-tx.png deleted file mode 100644 index 6e4c0008cf..0000000000 Binary files a/img/compatibility/greenaddress/rbf/transaction-list-replacement-tx.png and /dev/null differ diff --git a/img/compatibility/greenaddress/rbf/transaction-list-show-replaced.png b/img/compatibility/greenaddress/rbf/transaction-list-show-replaced.png deleted file mode 100644 index 8da4f110f1..0000000000 Binary files a/img/compatibility/greenaddress/rbf/transaction-list-show-replaced.png and /dev/null differ diff --git a/img/compatibility/greenaddress/rbf/transaction-list-subsequent-replacement-fees.png b/img/compatibility/greenaddress/rbf/transaction-list-subsequent-replacement-fees.png deleted file mode 100644 index 2d2ca0d527..0000000000 Binary files a/img/compatibility/greenaddress/rbf/transaction-list-subsequent-replacement-fees.png and /dev/null differ diff --git a/img/compatibility/greenaddress/rbf/transaction-send-confirmation-prompt.png b/img/compatibility/greenaddress/rbf/transaction-send-confirmation-prompt.png deleted file mode 100644 index 0b09ec2c05..0000000000 Binary files a/img/compatibility/greenaddress/rbf/transaction-send-confirmation-prompt.png and /dev/null differ diff --git a/img/compatibility/greenaddress/segwit/receive-screen.png b/img/compatibility/greenaddress/segwit/receive-screen.png deleted file mode 100644 index 6f3f7e84c8..0000000000 Binary files a/img/compatibility/greenaddress/segwit/receive-screen.png and /dev/null differ diff --git a/img/compatibility/greenaddress/segwit/send-screen-segwit-v1-error.png b/img/compatibility/greenaddress/segwit/send-screen-segwit-v1-error.png deleted file mode 100644 index 94b9ee7c96..0000000000 Binary files a/img/compatibility/greenaddress/segwit/send-screen-segwit-v1-error.png and /dev/null differ diff --git a/img/compatibility/greenaddress/segwit/send-screen.png b/img/compatibility/greenaddress/segwit/send-screen.png deleted file mode 100644 index 0165524dd5..0000000000 Binary files a/img/compatibility/greenaddress/segwit/send-screen.png and /dev/null differ diff --git a/img/compatibility/jaxx/jaxx.png b/img/compatibility/jaxx/jaxx.png deleted file mode 100755 index c68d2d6122..0000000000 Binary files a/img/compatibility/jaxx/jaxx.png and /dev/null differ diff --git a/img/compatibility/jaxx/rbf/transaction-list-incoming-rbf.png b/img/compatibility/jaxx/rbf/transaction-list-incoming-rbf.png deleted file mode 100644 index 9d042e7fdf..0000000000 Binary files a/img/compatibility/jaxx/rbf/transaction-list-incoming-rbf.png and /dev/null differ diff --git a/img/compatibility/jaxx/rbf/transaction-list-incoming-replacement.png b/img/compatibility/jaxx/rbf/transaction-list-incoming-replacement.png deleted file mode 100644 index 53b794232f..0000000000 Binary files a/img/compatibility/jaxx/rbf/transaction-list-incoming-replacement.png and /dev/null differ diff --git a/img/compatibility/jaxx/segwit/receive-screen.png b/img/compatibility/jaxx/segwit/receive-screen.png deleted file mode 100644 index e586c93292..0000000000 Binary files a/img/compatibility/jaxx/segwit/receive-screen.png and /dev/null differ diff --git a/img/compatibility/jaxx/segwit/send-screen-segwit-v1-error.png b/img/compatibility/jaxx/segwit/send-screen-segwit-v1-error.png deleted file mode 100644 index ee031205fa..0000000000 Binary files a/img/compatibility/jaxx/segwit/send-screen-segwit-v1-error.png and /dev/null differ diff --git a/img/compatibility/jaxx/segwit/send-screen.png b/img/compatibility/jaxx/segwit/send-screen.png deleted file mode 100644 index 544a7bb7aa..0000000000 Binary files a/img/compatibility/jaxx/segwit/send-screen.png and /dev/null differ diff --git a/img/compatibility/kraken/kraken.png b/img/compatibility/kraken/kraken.png deleted file mode 100644 index aa4f6adfa1..0000000000 Binary files a/img/compatibility/kraken/kraken.png and /dev/null differ diff --git a/img/compatibility/kraken/rbf/send-confirm.png b/img/compatibility/kraken/rbf/send-confirm.png deleted file mode 100644 index 037bedc878..0000000000 Binary files a/img/compatibility/kraken/rbf/send-confirm.png and /dev/null differ diff --git a/img/compatibility/kraken/rbf/transaction-list.png b/img/compatibility/kraken/rbf/transaction-list.png deleted file mode 100644 index c83923bb8d..0000000000 Binary files a/img/compatibility/kraken/rbf/transaction-list.png and /dev/null differ diff --git a/img/compatibility/kraken/segwit/create-address.png b/img/compatibility/kraken/segwit/create-address.png deleted file mode 100644 index 46eca4236e..0000000000 Binary files a/img/compatibility/kraken/segwit/create-address.png and /dev/null differ diff --git a/img/compatibility/kraken/segwit/receive-screen.png b/img/compatibility/kraken/segwit/receive-screen.png deleted file mode 100644 index eeb9f4f736..0000000000 Binary files a/img/compatibility/kraken/segwit/receive-screen.png and /dev/null differ diff --git a/img/compatibility/kraken/segwit/send-screen.png b/img/compatibility/kraken/segwit/send-screen.png deleted file mode 100644 index 2709d37548..0000000000 Binary files a/img/compatibility/kraken/segwit/send-screen.png and /dev/null differ diff --git a/img/compatibility/ledger-live/ledger-live.png b/img/compatibility/ledger-live/ledger-live.png deleted file mode 100644 index e8fe3030cb..0000000000 Binary files a/img/compatibility/ledger-live/ledger-live.png and /dev/null differ diff --git a/img/compatibility/ledger-live/rbf/error-screen.png b/img/compatibility/ledger-live/rbf/error-screen.png deleted file mode 100644 index 5a4af23f36..0000000000 Binary files a/img/compatibility/ledger-live/rbf/error-screen.png and /dev/null differ diff --git a/img/compatibility/ledger-live/rbf/send-screen.png b/img/compatibility/ledger-live/rbf/send-screen.png deleted file mode 100644 index f7d7c6dcc3..0000000000 Binary files a/img/compatibility/ledger-live/rbf/send-screen.png and /dev/null differ diff --git a/img/compatibility/ledger-live/rbf/transaction-details-incoming-rbf.png b/img/compatibility/ledger-live/rbf/transaction-details-incoming-rbf.png deleted file mode 100644 index 52982e8a14..0000000000 Binary files a/img/compatibility/ledger-live/rbf/transaction-details-incoming-rbf.png and /dev/null differ diff --git a/img/compatibility/ledger-live/rbf/transaction-details-sent.png b/img/compatibility/ledger-live/rbf/transaction-details-sent.png deleted file mode 100644 index e90aa0e0c9..0000000000 Binary files a/img/compatibility/ledger-live/rbf/transaction-details-sent.png and /dev/null differ diff --git a/img/compatibility/ledger-live/rbf/transaction-list-incoming-rbf.png b/img/compatibility/ledger-live/rbf/transaction-list-incoming-rbf.png deleted file mode 100644 index d38e9e63bb..0000000000 Binary files a/img/compatibility/ledger-live/rbf/transaction-list-incoming-rbf.png and /dev/null differ diff --git a/img/compatibility/ledger-live/rbf/transaction-list-incoming-replacement.png b/img/compatibility/ledger-live/rbf/transaction-list-incoming-replacement.png deleted file mode 100644 index d38e9e63bb..0000000000 Binary files a/img/compatibility/ledger-live/rbf/transaction-list-incoming-replacement.png and /dev/null differ diff --git a/img/compatibility/ledger-live/segwit/receive-screen.png b/img/compatibility/ledger-live/segwit/receive-screen.png deleted file mode 100644 index bdcbb11e37..0000000000 Binary files a/img/compatibility/ledger-live/segwit/receive-screen.png and /dev/null differ diff --git a/img/compatibility/ledger-live/segwit/send-screen-segwit-v1-error.png b/img/compatibility/ledger-live/segwit/send-screen-segwit-v1-error.png deleted file mode 100644 index 4bdb5ca78f..0000000000 Binary files a/img/compatibility/ledger-live/segwit/send-screen-segwit-v1-error.png and /dev/null differ diff --git a/img/compatibility/ledger-live/segwit/send-screen.png b/img/compatibility/ledger-live/segwit/send-screen.png deleted file mode 100644 index 062d393051..0000000000 Binary files a/img/compatibility/ledger-live/segwit/send-screen.png and /dev/null differ diff --git a/img/compatibility/mycelium-android/mycelium-android.png b/img/compatibility/mycelium-android/mycelium-android.png deleted file mode 100755 index 4d238684dd..0000000000 Binary files a/img/compatibility/mycelium-android/mycelium-android.png and /dev/null differ diff --git a/img/compatibility/mycelium-android/rbf/transaction-list-in-out.png b/img/compatibility/mycelium-android/rbf/transaction-list-in-out.png deleted file mode 100644 index 7b868825ad..0000000000 Binary files a/img/compatibility/mycelium-android/rbf/transaction-list-in-out.png and /dev/null differ diff --git a/img/compatibility/mycelium-android/rbf/transaction-list-incoming-double-spend.png b/img/compatibility/mycelium-android/rbf/transaction-list-incoming-double-spend.png deleted file mode 100644 index a1c1d7456f..0000000000 Binary files a/img/compatibility/mycelium-android/rbf/transaction-list-incoming-double-spend.png and /dev/null differ diff --git a/img/compatibility/mycelium-android/segwit/receive-screen.png b/img/compatibility/mycelium-android/segwit/receive-screen.png deleted file mode 100644 index 24cf0feac2..0000000000 Binary files a/img/compatibility/mycelium-android/segwit/receive-screen.png and /dev/null differ diff --git a/img/compatibility/mycelium-android/segwit/send-screen-segwit-v1-error.png b/img/compatibility/mycelium-android/segwit/send-screen-segwit-v1-error.png deleted file mode 100644 index 12bff4e62d..0000000000 Binary files a/img/compatibility/mycelium-android/segwit/send-screen-segwit-v1-error.png and /dev/null differ diff --git a/img/compatibility/mycelium-android/segwit/send-screen.png b/img/compatibility/mycelium-android/segwit/send-screen.png deleted file mode 100644 index 51dc5e0370..0000000000 Binary files a/img/compatibility/mycelium-android/segwit/send-screen.png and /dev/null differ diff --git a/img/compatibility/onekey/onekey.png b/img/compatibility/onekey/onekey.png deleted file mode 100755 index 698d2a7951..0000000000 Binary files a/img/compatibility/onekey/onekey.png and /dev/null differ diff --git a/img/compatibility/onekey/rbf/history.png b/img/compatibility/onekey/rbf/history.png deleted file mode 100644 index 29ffd5ca24..0000000000 Binary files a/img/compatibility/onekey/rbf/history.png and /dev/null differ diff --git a/img/compatibility/onekey/rbf/receive.png b/img/compatibility/onekey/rbf/receive.png deleted file mode 100644 index 229bf4e0f1..0000000000 Binary files a/img/compatibility/onekey/rbf/receive.png and /dev/null differ diff --git a/img/compatibility/onekey/rbf/send-screen-1.png b/img/compatibility/onekey/rbf/send-screen-1.png deleted file mode 100644 index ac35749fd6..0000000000 Binary files a/img/compatibility/onekey/rbf/send-screen-1.png and /dev/null differ diff --git a/img/compatibility/onekey/rbf/send-screen-2.png b/img/compatibility/onekey/rbf/send-screen-2.png deleted file mode 100644 index a61707e933..0000000000 Binary files a/img/compatibility/onekey/rbf/send-screen-2.png and /dev/null differ diff --git a/img/compatibility/onekey/rbf/send-screen-3.png b/img/compatibility/onekey/rbf/send-screen-3.png deleted file mode 100644 index ef9dff1776..0000000000 Binary files a/img/compatibility/onekey/rbf/send-screen-3.png and /dev/null differ diff --git a/img/compatibility/onekey/segwit/receive-screen.png b/img/compatibility/onekey/segwit/receive-screen.png deleted file mode 100755 index 38ea8b38cf..0000000000 Binary files a/img/compatibility/onekey/segwit/receive-screen.png and /dev/null differ diff --git a/img/compatibility/opendime/opendime.png b/img/compatibility/opendime/opendime.png deleted file mode 100644 index a73b572b41..0000000000 Binary files a/img/compatibility/opendime/opendime.png and /dev/null differ diff --git a/img/compatibility/opendime/rbf/sending-instructions.png b/img/compatibility/opendime/rbf/sending-instructions.png deleted file mode 100644 index a37179030f..0000000000 Binary files a/img/compatibility/opendime/rbf/sending-instructions.png and /dev/null differ diff --git a/img/compatibility/opendime/rbf/sending-script.png b/img/compatibility/opendime/rbf/sending-script.png deleted file mode 100644 index 464488e46b..0000000000 Binary files a/img/compatibility/opendime/rbf/sending-script.png and /dev/null differ diff --git a/img/compatibility/opendime/rbf/transaction-list-incoming-rbf.png b/img/compatibility/opendime/rbf/transaction-list-incoming-rbf.png deleted file mode 100644 index aa6ca1bb9d..0000000000 Binary files a/img/compatibility/opendime/rbf/transaction-list-incoming-rbf.png and /dev/null differ diff --git a/img/compatibility/opendime/rbf/transaction-list-incoming-replacement.png b/img/compatibility/opendime/rbf/transaction-list-incoming-replacement.png deleted file mode 100644 index bd9780ebc0..0000000000 Binary files a/img/compatibility/opendime/rbf/transaction-list-incoming-replacement.png and /dev/null differ diff --git a/img/compatibility/opendime/segwit/receive-screen.png b/img/compatibility/opendime/segwit/receive-screen.png deleted file mode 100644 index 3cb9852eac..0000000000 Binary files a/img/compatibility/opendime/segwit/receive-screen.png and /dev/null differ diff --git a/img/compatibility/purse/purse.png b/img/compatibility/purse/purse.png deleted file mode 100644 index 980b68f09c..0000000000 Binary files a/img/compatibility/purse/purse.png and /dev/null differ diff --git a/img/compatibility/purse/rbf/transaction-list.png b/img/compatibility/purse/rbf/transaction-list.png deleted file mode 100644 index 501014048e..0000000000 Binary files a/img/compatibility/purse/rbf/transaction-list.png and /dev/null differ diff --git a/img/compatibility/purse/segwit/receive-screen-nested.png b/img/compatibility/purse/segwit/receive-screen-nested.png deleted file mode 100644 index 17e59aa69e..0000000000 Binary files a/img/compatibility/purse/segwit/receive-screen-nested.png and /dev/null differ diff --git a/img/compatibility/purse/segwit/receive-screen-p2wpkh.png b/img/compatibility/purse/segwit/receive-screen-p2wpkh.png deleted file mode 100644 index fc34d8eea0..0000000000 Binary files a/img/compatibility/purse/segwit/receive-screen-p2wpkh.png and /dev/null differ diff --git a/img/compatibility/purse/segwit/send-screen.png b/img/compatibility/purse/segwit/send-screen.png deleted file mode 100644 index 5d3c9faa4f..0000000000 Binary files a/img/compatibility/purse/segwit/send-screen.png and /dev/null differ diff --git a/img/compatibility/purse/segwit/send-v1.png b/img/compatibility/purse/segwit/send-v1.png deleted file mode 100644 index 5b18f50ca0..0000000000 Binary files a/img/compatibility/purse/segwit/send-v1.png and /dev/null differ diff --git a/img/compatibility/river-financial/rbf/rbf_dashboard.png b/img/compatibility/river-financial/rbf/rbf_dashboard.png deleted file mode 100644 index 140ecfec40..0000000000 Binary files a/img/compatibility/river-financial/rbf/rbf_dashboard.png and /dev/null differ diff --git a/img/compatibility/river-financial/rbf/rbf_new_onchain_deposit.png b/img/compatibility/river-financial/rbf/rbf_new_onchain_deposit.png deleted file mode 100644 index eda9245efa..0000000000 Binary files a/img/compatibility/river-financial/rbf/rbf_new_onchain_deposit.png and /dev/null differ diff --git a/img/compatibility/river-financial/rbf/rbf_onchain_deposit.png b/img/compatibility/river-financial/rbf/rbf_onchain_deposit.png deleted file mode 100644 index 4dce651292..0000000000 Binary files a/img/compatibility/river-financial/rbf/rbf_onchain_deposit.png and /dev/null differ diff --git a/img/compatibility/river-financial/river-financial.png b/img/compatibility/river-financial/river-financial.png deleted file mode 100644 index 01c3a8646f..0000000000 Binary files a/img/compatibility/river-financial/river-financial.png and /dev/null differ diff --git a/img/compatibility/river-financial/segwit/deposit_onchain.png b/img/compatibility/river-financial/segwit/deposit_onchain.png deleted file mode 100644 index c8a60b77ea..0000000000 Binary files a/img/compatibility/river-financial/segwit/deposit_onchain.png and /dev/null differ diff --git a/img/compatibility/river-financial/segwit/withdraw_onchain.png b/img/compatibility/river-financial/segwit/withdraw_onchain.png deleted file mode 100644 index 1dc756abc5..0000000000 Binary files a/img/compatibility/river-financial/segwit/withdraw_onchain.png and /dev/null differ diff --git a/img/compatibility/samourai/rbf/send-screen-default.png b/img/compatibility/samourai/rbf/send-screen-default.png deleted file mode 100644 index 78c7f9c398..0000000000 Binary files a/img/compatibility/samourai/rbf/send-screen-default.png and /dev/null differ diff --git a/img/compatibility/samourai/rbf/send-stonewall-prompt.png b/img/compatibility/samourai/rbf/send-stonewall-prompt.png deleted file mode 100644 index c5d878b6ac..0000000000 Binary files a/img/compatibility/samourai/rbf/send-stonewall-prompt.png and /dev/null differ diff --git a/img/compatibility/samourai/rbf/sent-transaction-increase-fee.png b/img/compatibility/samourai/rbf/sent-transaction-increase-fee.png deleted file mode 100644 index 7cba7b9025..0000000000 Binary files a/img/compatibility/samourai/rbf/sent-transaction-increase-fee.png and /dev/null differ diff --git a/img/compatibility/samourai/rbf/settings-rbf.png b/img/compatibility/samourai/rbf/settings-rbf.png deleted file mode 100644 index c3b8395743..0000000000 Binary files a/img/compatibility/samourai/rbf/settings-rbf.png and /dev/null differ diff --git a/img/compatibility/samourai/rbf/transaction-details-incoming-rbf-increase-fee.png b/img/compatibility/samourai/rbf/transaction-details-incoming-rbf-increase-fee.png deleted file mode 100644 index 9ab36a5665..0000000000 Binary files a/img/compatibility/samourai/rbf/transaction-details-incoming-rbf-increase-fee.png and /dev/null differ diff --git a/img/compatibility/samourai/rbf/transaction-details-incoming-rbf.png b/img/compatibility/samourai/rbf/transaction-details-incoming-rbf.png deleted file mode 100644 index 1787af19bf..0000000000 Binary files a/img/compatibility/samourai/rbf/transaction-details-incoming-rbf.png and /dev/null differ diff --git a/img/compatibility/samourai/rbf/transaction-details-sent.png b/img/compatibility/samourai/rbf/transaction-details-sent.png deleted file mode 100644 index 48f947690f..0000000000 Binary files a/img/compatibility/samourai/rbf/transaction-details-sent.png and /dev/null differ diff --git a/img/compatibility/samourai/rbf/transaction-list-incoming-rbf.png b/img/compatibility/samourai/rbf/transaction-list-incoming-rbf.png deleted file mode 100644 index d92367b135..0000000000 Binary files a/img/compatibility/samourai/rbf/transaction-list-incoming-rbf.png and /dev/null differ diff --git a/img/compatibility/samourai/rbf/transaction-list-incoming-replacement.png b/img/compatibility/samourai/rbf/transaction-list-incoming-replacement.png deleted file mode 100644 index 3211335b66..0000000000 Binary files a/img/compatibility/samourai/rbf/transaction-list-incoming-replacement.png and /dev/null differ diff --git a/img/compatibility/samourai/rbf/transaction-list-replacement-confirmed.png b/img/compatibility/samourai/rbf/transaction-list-replacement-confirmed.png deleted file mode 100644 index 105dad9538..0000000000 Binary files a/img/compatibility/samourai/rbf/transaction-list-replacement-confirmed.png and /dev/null differ diff --git a/img/compatibility/samourai/rbf/transaction-list-sent-replaced.png b/img/compatibility/samourai/rbf/transaction-list-sent-replaced.png deleted file mode 100644 index 72da77daa7..0000000000 Binary files a/img/compatibility/samourai/rbf/transaction-list-sent-replaced.png and /dev/null differ diff --git a/img/compatibility/samourai/rbf/transaction-list-sent.png b/img/compatibility/samourai/rbf/transaction-list-sent.png deleted file mode 100644 index b35d3c2f77..0000000000 Binary files a/img/compatibility/samourai/rbf/transaction-list-sent.png and /dev/null differ diff --git a/img/compatibility/samourai/samourai.png b/img/compatibility/samourai/samourai.png deleted file mode 100644 index ff262a2d3a..0000000000 Binary files a/img/compatibility/samourai/samourai.png and /dev/null differ diff --git a/img/compatibility/samourai/segwit/receive-screen-advanced.png b/img/compatibility/samourai/segwit/receive-screen-advanced.png deleted file mode 100644 index e852c13232..0000000000 Binary files a/img/compatibility/samourai/segwit/receive-screen-advanced.png and /dev/null differ diff --git a/img/compatibility/samourai/segwit/receive-screen.png b/img/compatibility/samourai/segwit/receive-screen.png deleted file mode 100644 index 62ebca6cd5..0000000000 Binary files a/img/compatibility/samourai/segwit/receive-screen.png and /dev/null differ diff --git a/img/compatibility/samourai/segwit/send-screen-segwit-v1-error.png b/img/compatibility/samourai/segwit/send-screen-segwit-v1-error.png deleted file mode 100644 index 41d31fb694..0000000000 Binary files a/img/compatibility/samourai/segwit/send-screen-segwit-v1-error.png and /dev/null differ diff --git a/img/compatibility/samourai/segwit/send-screen.png b/img/compatibility/samourai/segwit/send-screen.png deleted file mode 100644 index ddb90aa7cc..0000000000 Binary files a/img/compatibility/samourai/segwit/send-screen.png and /dev/null differ diff --git a/img/compatibility/samourai/segwit/settings-transactions.png b/img/compatibility/samourai/segwit/settings-transactions.png deleted file mode 100644 index f0a2a031ac..0000000000 Binary files a/img/compatibility/samourai/segwit/settings-transactions.png and /dev/null differ diff --git a/img/compatibility/samourai/segwit/settings-wallet.png b/img/compatibility/samourai/segwit/settings-wallet.png deleted file mode 100644 index 87906238a5..0000000000 Binary files a/img/compatibility/samourai/segwit/settings-wallet.png and /dev/null differ diff --git a/img/compatibility/trezor/rbf/send-screen.png b/img/compatibility/trezor/rbf/send-screen.png deleted file mode 100644 index 3baa174254..0000000000 Binary files a/img/compatibility/trezor/rbf/send-screen.png and /dev/null differ diff --git a/img/compatibility/trezor/rbf/transaction-details-incoming-rbf.png b/img/compatibility/trezor/rbf/transaction-details-incoming-rbf.png deleted file mode 100644 index 62d2ee5b54..0000000000 Binary files a/img/compatibility/trezor/rbf/transaction-details-incoming-rbf.png and /dev/null differ diff --git a/img/compatibility/trezor/rbf/transaction-list-incoming-rbf.png b/img/compatibility/trezor/rbf/transaction-list-incoming-rbf.png deleted file mode 100644 index 17316b3554..0000000000 Binary files a/img/compatibility/trezor/rbf/transaction-list-incoming-rbf.png and /dev/null differ diff --git a/img/compatibility/trezor/rbf/transaction-list-incoming-replacement.png b/img/compatibility/trezor/rbf/transaction-list-incoming-replacement.png deleted file mode 100644 index b9f3c848d5..0000000000 Binary files a/img/compatibility/trezor/rbf/transaction-list-incoming-replacement.png and /dev/null differ diff --git a/img/compatibility/trezor/rbf/transaction-list-sent.png b/img/compatibility/trezor/rbf/transaction-list-sent.png deleted file mode 100644 index 6ba040c4cd..0000000000 Binary files a/img/compatibility/trezor/rbf/transaction-list-sent.png and /dev/null differ diff --git a/img/compatibility/trezor/segwit/receive-screen.png b/img/compatibility/trezor/segwit/receive-screen.png deleted file mode 100644 index b839fb716b..0000000000 Binary files a/img/compatibility/trezor/segwit/receive-screen.png and /dev/null differ diff --git a/img/compatibility/trezor/segwit/send-screen-segwit-v1-error.png b/img/compatibility/trezor/segwit/send-screen-segwit-v1-error.png deleted file mode 100644 index 1274d6a10c..0000000000 Binary files a/img/compatibility/trezor/segwit/send-screen-segwit-v1-error.png and /dev/null differ diff --git a/img/compatibility/trezor/segwit/send-screen.png b/img/compatibility/trezor/segwit/send-screen.png deleted file mode 100644 index 2d620a5f7d..0000000000 Binary files a/img/compatibility/trezor/segwit/send-screen.png and /dev/null differ diff --git a/img/compatibility/trezor/trezor.png b/img/compatibility/trezor/trezor.png deleted file mode 100644 index 59e681af25..0000000000 Binary files a/img/compatibility/trezor/trezor.png and /dev/null differ diff --git a/img/compatibility/wasabi/rbf/notification-incoming-rbf.png b/img/compatibility/wasabi/rbf/notification-incoming-rbf.png deleted file mode 100644 index 8b933c28ce..0000000000 Binary files a/img/compatibility/wasabi/rbf/notification-incoming-rbf.png and /dev/null differ diff --git a/img/compatibility/wasabi/rbf/send-screen.png b/img/compatibility/wasabi/rbf/send-screen.png deleted file mode 100644 index a4e97ad417..0000000000 Binary files a/img/compatibility/wasabi/rbf/send-screen.png and /dev/null differ diff --git a/img/compatibility/wasabi/rbf/transaction-list-incoming-rbf.png b/img/compatibility/wasabi/rbf/transaction-list-incoming-rbf.png deleted file mode 100644 index 93dfe32f52..0000000000 Binary files a/img/compatibility/wasabi/rbf/transaction-list-incoming-rbf.png and /dev/null differ diff --git a/img/compatibility/wasabi/rbf/transaction-list-incoming-replacement.png b/img/compatibility/wasabi/rbf/transaction-list-incoming-replacement.png deleted file mode 100644 index b2cf67ef51..0000000000 Binary files a/img/compatibility/wasabi/rbf/transaction-list-incoming-replacement.png and /dev/null differ diff --git a/img/compatibility/wasabi/rbf/transaction-list-sent.png b/img/compatibility/wasabi/rbf/transaction-list-sent.png deleted file mode 100644 index 107e91cc16..0000000000 Binary files a/img/compatibility/wasabi/rbf/transaction-list-sent.png and /dev/null differ diff --git a/img/compatibility/wasabi/segwit/receive-screen.png b/img/compatibility/wasabi/segwit/receive-screen.png deleted file mode 100644 index 19e5bae320..0000000000 Binary files a/img/compatibility/wasabi/segwit/receive-screen.png and /dev/null differ diff --git a/img/compatibility/wasabi/segwit/send-screen-segwit-v1-error.png b/img/compatibility/wasabi/segwit/send-screen-segwit-v1-error.png deleted file mode 100644 index 5385f758b4..0000000000 Binary files a/img/compatibility/wasabi/segwit/send-screen-segwit-v1-error.png and /dev/null differ diff --git a/img/compatibility/wasabi/segwit/send-screen.png b/img/compatibility/wasabi/segwit/send-screen.png deleted file mode 100644 index 25a08dfc74..0000000000 Binary files a/img/compatibility/wasabi/segwit/send-screen.png and /dev/null differ diff --git a/img/compatibility/wasabi/wasabi.png b/img/compatibility/wasabi/wasabi.png deleted file mode 100644 index 3a9c49d957..0000000000 Binary files a/img/compatibility/wasabi/wasabi.png and /dev/null differ diff --git a/img/compatibility/xapo/rbf/dashboard-incoming-replacement.png b/img/compatibility/xapo/rbf/dashboard-incoming-replacement.png deleted file mode 100644 index 7c80830f3e..0000000000 Binary files a/img/compatibility/xapo/rbf/dashboard-incoming-replacement.png and /dev/null differ diff --git a/img/compatibility/xapo/rbf/notification-incoming-rbf.png b/img/compatibility/xapo/rbf/notification-incoming-rbf.png deleted file mode 100644 index aa90f83f11..0000000000 Binary files a/img/compatibility/xapo/rbf/notification-incoming-rbf.png and /dev/null differ diff --git a/img/compatibility/xapo/rbf/notification-incoming-replacement.png b/img/compatibility/xapo/rbf/notification-incoming-replacement.png deleted file mode 100644 index aa90f83f11..0000000000 Binary files a/img/compatibility/xapo/rbf/notification-incoming-replacement.png and /dev/null differ diff --git a/img/compatibility/xapo/rbf/send-miner-fee-options.png b/img/compatibility/xapo/rbf/send-miner-fee-options.png deleted file mode 100644 index 850024eac0..0000000000 Binary files a/img/compatibility/xapo/rbf/send-miner-fee-options.png and /dev/null differ diff --git a/img/compatibility/xapo/rbf/send-screen.png b/img/compatibility/xapo/rbf/send-screen.png deleted file mode 100644 index cf3aff5ef3..0000000000 Binary files a/img/compatibility/xapo/rbf/send-screen.png and /dev/null differ diff --git a/img/compatibility/xapo/rbf/tranasction-details-sent.png b/img/compatibility/xapo/rbf/tranasction-details-sent.png deleted file mode 100644 index 5fc1f5591b..0000000000 Binary files a/img/compatibility/xapo/rbf/tranasction-details-sent.png and /dev/null differ diff --git a/img/compatibility/xapo/rbf/transaction-details-incoming-rbf.png b/img/compatibility/xapo/rbf/transaction-details-incoming-rbf.png deleted file mode 100644 index 6edd809cf6..0000000000 Binary files a/img/compatibility/xapo/rbf/transaction-details-incoming-rbf.png and /dev/null differ diff --git a/img/compatibility/xapo/rbf/transaction-list-incoming-rbf.png b/img/compatibility/xapo/rbf/transaction-list-incoming-rbf.png deleted file mode 100644 index aca8bb616c..0000000000 Binary files a/img/compatibility/xapo/rbf/transaction-list-incoming-rbf.png and /dev/null differ diff --git a/img/compatibility/xapo/rbf/transaction-list-incoming-replacement.png b/img/compatibility/xapo/rbf/transaction-list-incoming-replacement.png deleted file mode 100644 index bd05e52a4e..0000000000 Binary files a/img/compatibility/xapo/rbf/transaction-list-incoming-replacement.png and /dev/null differ diff --git a/img/compatibility/xapo/rbf/transaction-list-replacement-confirmed.png b/img/compatibility/xapo/rbf/transaction-list-replacement-confirmed.png deleted file mode 100644 index 3d3ae1a8e9..0000000000 Binary files a/img/compatibility/xapo/rbf/transaction-list-replacement-confirmed.png and /dev/null differ diff --git a/img/compatibility/xapo/segwit/receive-screen.png b/img/compatibility/xapo/segwit/receive-screen.png deleted file mode 100644 index 8e42f58ff7..0000000000 Binary files a/img/compatibility/xapo/segwit/receive-screen.png and /dev/null differ diff --git a/img/compatibility/xapo/segwit/send-screen-segwit-v1-pending.png b/img/compatibility/xapo/segwit/send-screen-segwit-v1-pending.png deleted file mode 100644 index 97b81c01b9..0000000000 Binary files a/img/compatibility/xapo/segwit/send-screen-segwit-v1-pending.png and /dev/null differ diff --git a/img/compatibility/xapo/segwit/send-screen.png b/img/compatibility/xapo/segwit/send-screen.png deleted file mode 100644 index ac96bede85..0000000000 Binary files a/img/compatibility/xapo/segwit/send-screen.png and /dev/null differ diff --git a/img/compatibility/xapo/xapo.png b/img/compatibility/xapo/xapo.png deleted file mode 100755 index 235be0b3cf..0000000000 Binary files a/img/compatibility/xapo/xapo.png and /dev/null differ diff --git a/img/posts/2024-08-replacement-cycling.plantuml b/img/posts/2024-08-replacement-cycling.plantuml new file mode 100644 index 0000000000..4cc7df4843 --- /dev/null +++ b/img/posts/2024-08-replacement-cycling.plantuml @@ -0,0 +1,26 @@ +@startditaa ++----------+ +| Bob exit +<-------+------+ ++----------+ + CPFP + Replacement cycle + + fee + Step 1 ++----------+ + bump + Bob's broadcast +| Bob UTXO +<-------+------+ ++----------+ + +-------------------------------------------------------- + ++--------------+ +| Mallory exit +<---+------+ ++--------------+ + CPFP + Replacement cycle + + fee + Step 2 ++--------------+ + bump + Mallory's alternative +| Mallory UTXO +<---+------+ ++--------------+ + +-------------------------------------------------------- + ++--------------+ +----------+ Replacement cycle +| Mallory UTXO +<---+ Ordinary + Step 3 ++--------------+ + spend + Alternative removed + +----------+ +@endditaa diff --git a/img/posts/2024-08-replacement-cycling.png b/img/posts/2024-08-replacement-cycling.png new file mode 100644 index 0000000000..05e947ea6f Binary files /dev/null and b/img/posts/2024-08-replacement-cycling.png differ diff --git a/img/posts/2024-12-depletion-cs.dot b/img/posts/2024-12-depletion-cs.dot new file mode 100644 index 0000000000..7403c0faff --- /dev/null +++ b/img/posts/2024-12-depletion-cs.dot @@ -0,0 +1,85 @@ +graph ln { + size = "8,10" + + node [shape = circle, width = 0.2, label = "", style = filled, color = black, fixedsize = true]; + edge [penwidth = 2]; + nodesep = 0.9; + ranksep = 0.9; + + subgraph cluster_foo { + A1 -- B1; + B1 -- C1; + + A2 -- B2; + B2 -- C2; + + A3 -- B3; + + A1 -- A2; + B1 -- B2; + C1 -- C2; + A2 -- A3; + B2 -- B3; + + label = <
    Distribuovaná síť
    (stav0)>; + labelloc = b; + } + + subgraph cluster_bar { + xA1 -- xB1 [color = red]; + xB1 -- xC1; + + xA2 -- xB2 [color = red]; + xB2 -- xC2; + + xA3 -- xB3; + + xA1 -- xA2 [color = red]; + xB1 -- xB2 [color = red]; + xC1 -- xC2; + xA2 -- xA3; + xB2 -- xB3; + + label = <

    Příklad cyklu v grafu >; + labelloc = b; + } + + subgraph cluster_break { + yA1 -- yB1 [style = invis]; + yB1 -- yC1; + + yA2 -- yB2; + yB2 -- yC2; + + yA3 -- yB3; + + yA1 -- yA2; + yB1 -- yB2; + yC1 -- yC2; + yA2 -- yA3; + yB2 -- yB3; + + label = cyklus porušen
    (stav1)>; + labelloc = b; + } + + subgraph cluster_span { + zA1 -- zB1 [style = invis]; + zB1 -- zC1; + + zA2 -- zB2 [style = invis]; + zB2 -- zC2 [style = invis]; + + zA3 -- zB3; + + zA1 -- zA2; + zB1 -- zB2; + zC1 -- zC2; + zA2 -- zA3; + zB2 -- zB3; + + label = zůstává kostra grafu
    (stavN)>; + labelloc = b; + } + +} diff --git a/img/posts/2024-12-depletion-cs.png b/img/posts/2024-12-depletion-cs.png new file mode 100644 index 0000000000..4f7c6ddcf3 Binary files /dev/null and b/img/posts/2024-12-depletion-cs.png differ diff --git a/img/posts/2024-12-depletion.dot b/img/posts/2024-12-depletion.dot new file mode 100644 index 0000000000..737fd68b87 --- /dev/null +++ b/img/posts/2024-12-depletion.dot @@ -0,0 +1,85 @@ +graph ln { + size = "8,10" + + node [shape = circle, width = 0.2, label = "", style = filled, color = black, fixedsize = true]; + edge [penwidth = 2]; + nodesep = 0.9; + ranksep = 0.9; + + subgraph cluster_foo { + A1 -- B1; + B1 -- C1; + + A2 -- B2; + B2 -- C2; + + A3 -- B3; + + A1 -- A2; + B1 -- B2; + C1 -- C2; + A2 -- A3; + B2 -- B3; + + label = <
    A distributed network
    (state0)>; + labelloc = b; + } + + subgraph cluster_bar { + xA1 -- xB1 [color = red]; + xB1 -- xC1; + + xA2 -- xB2 [color = red]; + xB2 -- xC2; + + xA3 -- xB3; + + xA1 -- xA2 [color = red]; + xB1 -- xB2 [color = red]; + xC1 -- xC2; + xA2 -- xA3; + xB2 -- xB3; + + label = <
    Example cycle within
    the graph >; + labelloc = b; + } + + subgraph cluster_break { + yA1 -- yB1 [style = invis]; + yB1 -- yC1; + + yA2 -- yB2; + yB2 -- yC2; + + yA3 -- yB3; + + yA1 -- yA2; + yB1 -- yB2; + yC1 -- yC2; + yA2 -- yA3; + yB2 -- yB3; + + label = breaking the cycle
    (state1)>; + labelloc = b; + } + + subgraph cluster_span { + zA1 -- zB1 [style = invis]; + zB1 -- zC1; + + zA2 -- zB2 [style = invis]; + zB2 -- zC2 [style = invis]; + + zA3 -- zB3; + + zA1 -- zA2; + zB1 -- zB2; + zC1 -- zC2; + zA2 -- zA3; + zB2 -- zB3; + + label = a spanning tree
    remains (stateN)>; + labelloc = b; + } + +} diff --git a/img/posts/2024-12-depletion.png b/img/posts/2024-12-depletion.png new file mode 100644 index 0000000000..339f0c505b Binary files /dev/null and b/img/posts/2024-12-depletion.png differ diff --git a/img/posts/2024-time-warp/2024-08-time-warp.gnuplot b/img/posts/2024-time-warp/2024-08-time-warp.gnuplot new file mode 100644 index 0000000000..fc8d5439b6 --- /dev/null +++ b/img/posts/2024-time-warp/2024-08-time-warp.gnuplot @@ -0,0 +1,58 @@ +#!/usr/bin/gnuplot + +set style line 1 pt 5 ps 1 lc rgb "black" +set style line 2 pt 5 ps 1 lc rgb "grey" +set style line 3 pt 5 ps 1 lc rgb "blue" +set style line 4 pt 5 ps 1 lc rgb "orange" + +set style fill transparent solid 0.5 noborder + +set terminal pngcairo size 800,200 font "Sans,8" transparent +#set terminal pngcairo size 00,200 font "Sans,12" transparent + +set grid +set tics nomirror +unset border + +set xlabel "Time (block header)" +set ylabel "Difficulty\n(log scale)" +unset xtics +unset ytics +#unset key +set key box +set key bottom left + +set logscale y +set tmargin at screen 0.8 + +set output 'new-time-warp.png' +set title "New time warp\n " font "Sans Bold,8" +plot './new-time-warp.data' every ::0::4 ls 1 title "Period 1", \ + '' every ::5::9 ls 2 title "Period 2", \ + '' every ::10::14 ls 3 title "Period 3", \ + '' every ::15::19 ls 4 title "Period 4", \ + '' using 1:2:(sprintf("%d", $0+1)) with labels offset char 0,1 notitle, \ + +set output 'classic-time-warp.png' +set title "Classic time warp" +plot './classic-time-warp.data' every ::0::4 ls 1 title "Period 1", \ + '' every ::5::9 ls 2 title "Period 2", \ + '' every ::10::14 ls 3 title "Period 3", \ + '' every ::15::19 ls 4 title "Period 4", \ + '' using 1:2:(sprintf("%d", $0+1)) with labels offset char 0,1 notitle, \ + +set output '50p-attack.png' +set title "51% attack" +plot './50p-attack.data' every ::0::4 ls 1 title "Period 1", \ + '' every ::5::9 ls 2 title "Period 2", \ + '' every ::10::14 ls 3 title "Period 3", \ + '' every ::15::19 ls 4 title "Period 4", \ + '' using 1:2:(sprintf("%d", $0+1)) with labels offset char 0,1 notitle, \ + +set output 'reg-blocks.png' +set title "Honest mining\n(constant hashrate)" +plot './reg-blocks.data' every ::0::4 ls 1 title "Period 1", \ + '' every ::5::9 ls 2 title "Period 2", \ + '' every ::10::14 ls 3 title "Period 3", \ + '' every ::15::19 ls 4 title "Period 4", \ + '' using 1:2:(sprintf("%d", $0+1)) with labels offset char 0,1 notitle, \ diff --git a/img/posts/2024-time-warp/50p-attack.data b/img/posts/2024-time-warp/50p-attack.data new file mode 100644 index 0000000000..1503929b68 --- /dev/null +++ b/img/posts/2024-time-warp/50p-attack.data @@ -0,0 +1,20 @@ +1 1 +3 1 +5 1 +7 1 +9 1 +10 0.5 +11 0.5 +12 0.5 +13 0.5 +14 0.5 +15 0.5 +16 0.5 +17 0.5 +18 0.5 +19 0.5 +20 0.5 +21 0.5 +22 0.5 +23 0.5 +24 0.5 diff --git a/img/posts/2024-time-warp/50p-attack.png b/img/posts/2024-time-warp/50p-attack.png new file mode 100644 index 0000000000..883f872263 Binary files /dev/null and b/img/posts/2024-time-warp/50p-attack.png differ diff --git a/img/posts/2024-time-warp/classic-time-warp.data b/img/posts/2024-time-warp/classic-time-warp.data new file mode 100644 index 0000000000..0923881b74 --- /dev/null +++ b/img/posts/2024-time-warp/classic-time-warp.data @@ -0,0 +1,20 @@ +1 1 +2 1 +3 1 +4 1 +12 1 +6 0.5 +7 0.5 +8 0.5 +9 0.5 +24 0.5 +11 0.125 +12 0.125 +13 0.125 +14 0.125 +36 0.125 +16 0.03125 +17 0.03125 +18 0.03125 +19 0.03125 +48 0.03125 diff --git a/img/posts/2024-time-warp/classic-time-warp.png b/img/posts/2024-time-warp/classic-time-warp.png new file mode 100644 index 0000000000..1b457774be Binary files /dev/null and b/img/posts/2024-time-warp/classic-time-warp.png differ diff --git a/img/posts/2024-time-warp/new-time-warp.data b/img/posts/2024-time-warp/new-time-warp.data new file mode 100644 index 0000000000..1718356fea --- /dev/null +++ b/img/posts/2024-time-warp/new-time-warp.data @@ -0,0 +1,20 @@ +1 1 +2 1 +3 1 +4 1 +24 1 +24 0.25 +7 0.25 +8 0.25 +9 0.25 +48 0.25 +48 0.0625 +12 0.0625 +13 0.0625 +14 0.0625 +15 0.0625 +16 0.25 +17 0.25 +18 0.25 +19 0.25 +36 0.25 diff --git a/img/posts/2024-time-warp/new-time-warp.png b/img/posts/2024-time-warp/new-time-warp.png new file mode 100644 index 0000000000..65a6ff82d2 Binary files /dev/null and b/img/posts/2024-time-warp/new-time-warp.png differ diff --git a/img/posts/2024-time-warp/reg-blocks.data b/img/posts/2024-time-warp/reg-blocks.data new file mode 100644 index 0000000000..38512be67d --- /dev/null +++ b/img/posts/2024-time-warp/reg-blocks.data @@ -0,0 +1,20 @@ +1 1 +2 1 +3 1 +4 1 +5 1 +6 1 +7 1 +8 1 +9 1 +10 1 +11 1 +12 1 +13 1 +14 1 +15 1 +16 1 +17 1 +18 1 +19 1 +20 1 diff --git a/img/posts/2024-time-warp/reg-blocks.png b/img/posts/2024-time-warp/reg-blocks.png new file mode 100644 index 0000000000..fcf6927cfc Binary files /dev/null and b/img/posts/2024-time-warp/reg-blocks.png differ diff --git a/img/posts/2025-02-dag-blockchain-cs.dot b/img/posts/2025-02-dag-blockchain-cs.dot new file mode 100644 index 0000000000..7dc7eaada0 --- /dev/null +++ b/img/posts/2025-02-dag-blockchain-cs.dot @@ -0,0 +1,30 @@ +digraph G { + rankdir=LR; + size="6.5,25"; + + node [shape = "box", label = "", style = "filled", fillcolor = "black", width = 0.3, height = 0.3]; + edge [ranksep = "3", minlen = "3", dir="back", arrowsize = "0.9", arrowhead = "vee" ]; + + // First generation + A -> {B,C,D}; + + // Second generation + B -> {E, F}; + C -> {E, G}; + D -> {E, F, H}; + + // Third generation + E -> I; + F -> I; + G -> I; + // H has no children + + // Fourth generation + I -> {J, K}; + + // Fifth generation + J -> {L, M}; + K -> M; + + label = "Příklad blockchainu v podobě orientovaného acyklického grafu"; +} diff --git a/img/posts/2025-02-dag-blockchain-cs.png b/img/posts/2025-02-dag-blockchain-cs.png new file mode 100644 index 0000000000..08991c39a8 Binary files /dev/null and b/img/posts/2025-02-dag-blockchain-cs.png differ diff --git a/img/posts/2025-02-dag-blockchain.dot b/img/posts/2025-02-dag-blockchain.dot new file mode 100644 index 0000000000..197b3743ef --- /dev/null +++ b/img/posts/2025-02-dag-blockchain.dot @@ -0,0 +1,30 @@ +digraph G { + rankdir=LR; + size="6.5,25"; + + node [shape = "box", label = "", style = "filled", fillcolor = "black", width = 0.3, height = 0.3]; + edge [ranksep = "3", minlen = "3", dir="back", arrowsize = "0.9", arrowhead = "vee" ]; + + // First generation + A -> {B,C,D}; + + // Second generation + B -> {E, F}; + C -> {E, G}; + D -> {E, F, H}; + + // Third generation + E -> I; + F -> I; + G -> I; + // H has no children + + // Fourth generation + I -> {J, K}; + + // Fifth generation + J -> {L, M}; + K -> M; + + label = "Example of a DAG blockchain"; +} diff --git a/img/posts/2025-02-dag-blockchain.dot.png b/img/posts/2025-02-dag-blockchain.dot.png new file mode 100644 index 0000000000..9f6d9904a7 Binary files /dev/null and b/img/posts/2025-02-dag-blockchain.dot.png differ diff --git a/img/posts/2025-03-fork-monitor-testnet3.png b/img/posts/2025-03-fork-monitor-testnet3.png new file mode 100644 index 0000000000..46b8f2af38 Binary files /dev/null and b/img/posts/2025-03-fork-monitor-testnet3.png differ diff --git a/img/posts/2025-11-stale-rates1.png b/img/posts/2025-11-stale-rates1.png new file mode 100644 index 0000000000..71c201db26 Binary files /dev/null and b/img/posts/2025-11-stale-rates1.png differ diff --git a/img/posts/2025-11-stale-rates1.svg b/img/posts/2025-11-stale-rates1.svg new file mode 100644 index 0000000000..24fbffa3e9 --- /dev/null +++ b/img/posts/2025-11-stale-rates1.svg @@ -0,0 +1,64 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/img/posts/2025-11-stale-rates2.png b/img/posts/2025-11-stale-rates2.png new file mode 100644 index 0000000000..94a4db5f15 Binary files /dev/null and b/img/posts/2025-11-stale-rates2.png differ diff --git a/img/posts/2025-11-stale-rates2.svg b/img/posts/2025-11-stale-rates2.svg new file mode 100644 index 0000000000..1b1fa31dfc --- /dev/null +++ b/img/posts/2025-11-stale-rates2.svg @@ -0,0 +1,81 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/img/team/copinmalin.jpg b/img/team/copinmalin.jpg new file mode 100644 index 0000000000..5a83059d49 Binary files /dev/null and b/img/team/copinmalin.jpg differ diff --git a/img/team/erhardt.png b/img/team/erhardt.png index a54b3da224..4723f19657 100644 Binary files a/img/team/erhardt.png and b/img/team/erhardt.png differ diff --git a/img/team/harding.png b/img/team/harding.png index 78bb500754..58bc33e9c0 100644 Binary files a/img/team/harding.png and b/img/team/harding.png differ diff --git a/img/team/hulatown.jpg b/img/team/hulatown.jpg new file mode 100644 index 0000000000..15217a8b4b Binary files /dev/null and b/img/team/hulatown.jpg differ diff --git a/img/team/jirijakes.jpg b/img/team/jirijakes.jpg new file mode 100644 index 0000000000..38100a6b6f Binary files /dev/null and b/img/team/jirijakes.jpg differ diff --git a/index.md b/index.md index ff0ca6c1eb..6b2da059e0 100644 --- a/index.md +++ b/index.md @@ -11,23 +11,20 @@ layout: home Bitcoin Optech helps Bitcoin users and businesses integrate scaling technologies. -We provide [workshops][], [documentation][scaling book], [weekly -newsletters][], [original research][dashboard], [case studies and -announcements][blog], [analysis of Bitcoin software and -services][compatibility], a [podcast][], and help facilitate improved relations between +We provide [weekly newsletters][], a [podcast][], [case studies and +announcements][blog], [analyses of Bitcoin software and +services][matrix], [workshops][] and help to facilitate improved relations between businesses and the open source community. [Learn more about us][about]. -[scaling book]: https://github.com/bitcoinops/scaling-book -[workshops]: /workshops +[workshops]: /en/workshops [weekly newsletters]: /en/newsletters/ -[dashboard]: https://dashboard.bitcoinops.org/ [blog]: /en/blog/ [podcast]: /en/podcast/ -[about]: /about -[compatibility]: /en/compatibility/ +[about]: /en/about +[matrix]: /en/matrix/ {% assign posts_en = site.posts | where:"lang","en" %} diff --git a/internal/sources.md b/internal/sources.md deleted file mode 100644 index 0f3438dac8..0000000000 --- a/internal/sources.md +++ /dev/null @@ -1,65 +0,0 @@ ---- -layout: page -title: Sources -permalink: /internal/sources/ ---- -# Sources for the Optech Newsletter - -The _News_ section of the newsletter is currently sourced from the -following discussion groups: - -- [Bitcoin-Dev][] mailing list -- [Lightning-Dev][] mailing list -- [DLC-Dev][] mailing list -- [#bitcoin-core-dev][] IRC -- [#lightning-dev][] IRC -- [Bitcoin Transcripts][] -- [Protocol Design][] and [Implementation][] categories on the [DelvingBitcoin][] web forum - -We will include urgent and important news, such as security -announcements, from any source. Otherwise, we normally will not write -about any subject unless it has recently been discussed in one of the -above sources. - -Other parts of the newsletter are based on other sources. In most -cases, this is made clear by the section title or by the text -introducing the section; for example, the monthly "Bitcoin Core PR -Review Club Summary" and "Bitcoin Stack Exchange" sections. - -## Motivation for only using a few news sources - -Ideas for changes to Bitcoin need to be peer reviewed---that way bad -ideas can be clearly rejected and good ideas can attract people who will -put them into practice. But effective peer review is harder the more -discussion becomes spread out across multiple groups. Alice might not -be in the same group as Bob, preventing her from seeing his idea. Or, -even if she does see it, she may not be able to easily respond to it. - -Of course, not everyone is interested in every subject, so any -particular group can only scale up to handling a certain variety of -topics. After that, it's natural for it to segment into different -groups, just as LN and DLCs are now often discussed separately from -Bitcoin in general. - -But, when possible, Optech prefers to only track one discussion group -per subject. We do this to encourage anyone who wants to see their -topic appear in Optech to discuss it in the place where it's most likely -to be seen by their peers. If your idea is important or interesting -enough to earn the attention of your peers, then it's probably important -or interesting enough for Optech to write about. - -Additionally, only having a short list of sources to check for -news makes writing the newsletter each week much more manageable. It's -possible for us to read every post to a small or mid-sized discussion -group. It's not possible for us to read everything about Bitcoin on -large social media sites or hundreds of individual blogs. - -[bitcoin transcripts]: https://btctranscripts.com/ -[bitcoin-dev]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/ -[lightning-dev]: https://lists.linuxfoundation.org/pipermail/lightning-dev/ -[dlc-dev]: https://mailmanlists.org/pipermail/dlc-dev/ -[#bitcoin-core-dev]: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/ -[#lightning-dev]: https://gnusha.org/lightning-dev/ -[protocol design]: https://delvingbitcoin.org/c/protocol-design/7 -[implementation]: https://delvingbitcoin.org/c/implementation/8 -[delvingbitcoin]: https://delvingbitcoin.org/ diff --git a/ja/internal/sources.md b/ja/internal/sources.md new file mode 100644 index 0000000000..0f3052e40f --- /dev/null +++ b/ja/internal/sources.md @@ -0,0 +1,60 @@ +--- +layout: page +title: 情報源 +permalink: /ja/internal/sources/ +breadcrumbs: false +--- +# Optechニュースレターの情報源 + +ニュースレターの _ニュース_ および _コンセンサスの変更_ セクションは、 +現在、以下のディスカッショングループから情報を取得しています: + +- [Bitcoin-Dev][]メーリングリスト +- [DLC-Dev][]メーリングリスト +- [Mining-Dev][]メーリングリスト +- [#bitcoin-core-dev][] IRC +- [#lightning-dev][] IRC +- [Bitcoin Transcripts][] +- [DelvingBitcoin][]ウェブフォーラムの[プロトコル設計][Protocol Design]と[実装][Implementation]のカテゴリ + +セキュリティ関連の発表など、緊急かつ重要なニュースは、あらゆる情報源から発信されます。 +それ以外の場合、上記のいずれかの情報源で最近議論されていない限り、 +通常は特定のトピックについて記事は書きません。 + +ニュースレターの他の部分は、別の情報源に基づいています。ほとんどの場合、 +これはセクションのタイトルや紹介文で明示されています。たとえば、 +毎月の「Bitcoin Core PR Review Club Summary」や、 +「Bitcoin Stack Exchange」セクションなどがその例です。 + +## 少数の情報源のみを使用する理由 + +Bitcoinへの変更案は、ピア・レビューを受ける必要があります。 +そうすることで、悪いアイディアは明確に却下され、良いアイディアはそれを実践する人々を惹きつけます。 +しかし、議論が複数のグループに分散すると、効果的なピア・レビューは難しくなります。 +アリスはボブと同じグループに属していない可能性があり、彼のアイディアを見ることができないかもしれません。 +あるいは、たとえ見ることができても、簡単に反応できないかもしれません。 + +もちろん、すべての人がすべてのトピックに興味を持っているわけではないので、 +特定のグループが扱えるトピックの種類は限られています。 +その後、LNやDLCがBitcoin全般とは別に議論されることが多くなったように、 +異なるグループに細分化されるのは自然なことです。 + +しかし、可能な限り、Optechは1つのテーマにつき1つのグループのみを追跡することを好みます。 +これは、自分のトピックをOptechに掲載したい人が、仲間に最も見られる可能性の高い場所で議論することを推奨するためです。 +あなたのアイディアが仲間の注目を集めるほど重要で興味深いものであれば、 +それはOptechが記事にするのに十分重要で興味深いものでしょう。 + +さらに、ニュースをチェックする情報源が絞られているため、 +毎週のニュースレターの作成がはるかに容易になります。小規模または中規模のディスカッショングループであれば、 +すべての投稿を読むことは可能です。しかし、大規模なソーシャルメディアサイトや、 +数百もの個人ブログに掲載されているBitcoinに関するすべての情報を読むのは不可能です。 + +[bitcoin transcripts]: https://btctranscripts.com/ +[bitcoin-dev]: https://groups.google.com/g/bitcoindev +[dlc-dev]: https://mailmanlists.org/pipermail/dlc-dev/ +[mining-dev]: https://groups.google.com/g/bitcoinminingdev +[#bitcoin-core-dev]: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/ +[#lightning-dev]: https://gnusha.org/lightning-dev/ +[protocol design]: https://delvingbitcoin.org/c/protocol-design/7 +[implementation]: https://delvingbitcoin.org/c/implementation/8 +[delvingbitcoin]: https://delvingbitcoin.org/ diff --git a/pt/about.md b/pt/about.md new file mode 100644 index 0000000000..ad10453fdc --- /dev/null +++ b/pt/about.md @@ -0,0 +1,53 @@ +--- +layout: page +title: Sobre +permalink: /pt/about/ +--- + +O Grupo de Tecnologia de Operações Bitcoin (Optech) trabalha para trazer as +melhores tecnologias e técnicas de código aberto para empresas que utilizam +Bitcoin, a fim de reduzir custos e melhorar as experiências dos clientes. + +Um foco inicial para o grupo é trabalhar com suas organizações membros para +reduzir os tamanhos das transações e minimizar o efeito de aumentos +subsequentes nas taxas de transação. Fornecemos workshops, newsletters +semanais, estudos de caso, anúncios, um podcast, e ajudamos a facilitar +relações aprimoradas entre empresas e a comunidade de código aberto. + +[workshops]: /pt/workshops +[newsletters semanais]: /pt/newsletters/ +[blog]: /pt/blog/ +[podcast]: /pt/podcast/ + +Se você é um engenheiro ou gerente em uma empresa Bitcoin ou um contribuidor de +código aberto e gostaria de fazer parte disso, entre em contato conosco em +[info@bitcoinops.org](mailto:info@bitcoinops.org). + +## Financiamento + +A Optech não existe para obter lucro, e todos os materiais e documentação produzidos +são liberados sob a licença MIT. + +O financiamento inicial foi fornecido por Wences Casares e John Pfeffer para cobrir +contratados externos e despesas incidentais. + +Nossas generosas empresas membros pagam uma contribuição anual para cobrir despesas. + +## Contribuidores da Optech + +Todo material produzido pela Bitcoin Optech é de código aberto e liberado sob a +licença MIT. Qualquer pessoa é bem-vinda para contribuir abrindo issues e +pull requests, revisando newsletters e outros materiais, e contribuindo com traduções. +Nossos contribuidores mais regulares são: + +{% assign contributors = site.data.contributors.contributors | sort: "name" %} +{% include contributors.html id="contributors" %} + +{% include sponsors.html %} + +## Ex-Contribuidores da Optech + +Agradecemos a todos os nossos ex-contribuidores por seus esforços. + +{% assign contributors = site.data.contributors.contributors_alum | sort: "name" %} +{% include contributors.html id="contributors_alum" %} \ No newline at end of file diff --git a/pt/blog.md b/pt/blog.md new file mode 100644 index 0000000000..96f98d7491 --- /dev/null +++ b/pt/blog.md @@ -0,0 +1,9 @@ +--- +layout: blog +lang: pt +title: Blog +name: blog +permalink: /pt/blog/ +share: false +version: 1 +--- \ No newline at end of file diff --git a/pt/newsletters.md b/pt/newsletters.md new file mode 100644 index 0000000000..37f86aea8d --- /dev/null +++ b/pt/newsletters.md @@ -0,0 +1,9 @@ +--- +layout: newsletters +lang: pt +title: Newsletters +name: newsletters +permalink: /pt/newsletters/ +share: false +version: 1 +--- \ No newline at end of file diff --git a/pt/publications.md b/pt/publications.md new file mode 100644 index 0000000000..8d60502492 --- /dev/null +++ b/pt/publications.md @@ -0,0 +1,18 @@ +--- +layout: publications +lang: pt +title: Publicações +name: publicações +permalink: /pt/publications/ +share: false +version: 1 +--- +- [Newsletters][]: Um resumo semanal de notícias sobre desenvolvimento do Bitcoin e LN. + +- [Posts do Blog][]: Atualizações ocasionais e material de referência da equipe Optech. + +- [Episódios do Podcast][]: Discussões em áudio sobre nossas newsletters. + +[posts do blog]: /pt/blog/ +[newsletters]: /pt/newsletters/ +[episódios do podcast]: /en/podcast/ diff --git a/pt/workshops.md b/pt/workshops.md new file mode 100644 index 0000000000..736d0c69e0 --- /dev/null +++ b/pt/workshops.md @@ -0,0 +1,78 @@ +--- +layout: page +title: Workshops +permalink: /pt/workshops/ +--- + +A Bitcoin Optech realizará uma série de workshops para reunir engenheiros do +Bitcoin para discutir abordagens e desafios na implementação de tecnologias +para escalabilidade. Cada workshop será adaptado às empresas membros +participantes e aos desafios específicos de escalabilidade que elas estão enfrentando. + +Se você tiver alguma solicitação ou sugestão para futuros eventos de workshop, +por favor [entre em contato conosco](mailto:info@bitcoinops.org). + +## Workshops #3, #4 e #5 - Seminários Schnorr e Taproot {#taproot-workshop} + +- São Francisco, 24 de setembro de 2019 +- Nova York, 27 de setembro de 2019 +- Londres, 5 de fevereiro de 2020 + +*Assinaturas Schnorr* e *Taproot* são mudanças propostas para o protocolo Bitcoin que +prometem grandes melhorias em privacidade, fungibilidade, escalabilidade e funcionalidade. + +A Bitcoin Optech hospedou dois workshops no formato de seminário que incluíram uma +mistura de apresentações, exercícios de programação e discussões, e deram aos +engenheiros das empresas membros uma compreensão de como essas novas tecnologias +funcionam e como podem ser aplicadas aos seus produtos e serviços. Os workshops +também forneceram aos engenheiros uma oportunidade de participar do processo de +feedback enquanto essas tecnologias ainda estão na fase de proposta. + +[Todo o material dos workshops][taproot workshop blog post] +está disponível neste site, para que os engenheiros possam aprender sobre as propostas +Schnorr/Taproot em casa. + +## Workshop #2 - Paris, 12-13 de novembro de 2018 + +A Bitcoin Optech realizou nosso segundo workshop de mesa redonda em Paris nos dias +12-13 de novembro de 2018. O formato foi o mesmo do primeiro workshop em São Francisco. + +Estiveram presentes 24 engenheiros de empresas de Bitcoin e projetos de código aberto. + +#### Tópicos + +- Replace-by-Fee vs. Child-Pays-for-Parent como técnicas de substituição de taxa +- Transações Bitcoin Parcialmente Assinadas (PSBTs)([BIP 174](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki)) +- [Descritores de script de saída (Output Descriptors)](https://gist.github.com/sipa/e3d23d498c430bb601c5bca83523fa82) para interoperabilidade de carteiras +- Integração de carteiras Lightning e aplicações para exchanges +- Abordagens para seleção e consolidação de moedas + +#### Agradecimentos + +Obrigado à Ledger por hospedar o workshop e ajudar com a organização. + +## Workshop #1 - São Francisco, 17 de julho de 2018 + +A Bitcoin Optech realizou nosso primeiro workshop de mesa redonda em São Francisco no dia 17 de julho de 2018: + +- Os tópicos foram discutidos em formato de mesa redonda no qual cada participante teve uma oportunidade igual de se envolver. + +- Cada tópico teve um moderador e alguém responsável pelas anotações. O moderador foi responsável por uma breve introdução de um tópico e manter a discussão no caminho certo e no tempo. + +- Para garantir que os participantes se sentissem confortáveis para falar livremente, as notas e itens de ação foram distribuídos aos participantes, mas não além disso. Os participantes foram livres para compartilhar detalhes da discussão internamente em suas empresas e publicamente, mas não atribuíram nenhuma declaração particular a um determinado indivíduo (Regras da Casa Chatham). + +Estiveram presentes 14 engenheiros de empresas de Bitcoin da Área da Baía de São Francisco e projetos de código aberto. + +#### Tópicos + +- Seleção de moedas +- Estimativa de taxa, RBF, melhores práticas CPFP +- Comunidade e comunicação Optech + +#### Agradecimentos + +Obrigado à Square por hospedar o workshop e à Coinbase por ajudar com a organização. + +{% include references.md %} + +[taproot workshop blog post]: /en/schorr-taproot-workshop/ \ No newline at end of file diff --git a/topics.json b/topics.json index c8b3cb17fc..65f165c080 100644 --- a/topics.json +++ b/topics.json @@ -15,8 +15,8 @@ "title": {{ topic.title | jsonify }}, "slug": {{ topic_slug | jsonify }}, "optech_url": "{{ site.url }}{{ topic.url }}", - "categories": {{ topic.categories | jsonify }}, - "aliases": {{ topic.aliases | jsonify }}, + "categories": {{ topic.topic-categories | jsonify }}, + "aliases": {{ topic.title-aliases | jsonify }}, "excerpt": {{ topic.excerpt | jsonify }} }{% unless forloop.last %},{% endunless %} {% endfor %} diff --git a/workshops.md b/workshops.md deleted file mode 100644 index e811709969..0000000000 --- a/workshops.md +++ /dev/null @@ -1,87 +0,0 @@ ---- -layout: page -title: Workshops -permalink: /workshops/ ---- - -Bitcoin Optech will run a series of workshops to bring Bitcoin engineers -together to discuss approaches and challenges in implementing scaling -technologies. Each workshop will be tailored to the member companies attending -and the specific scaling challenges that they are facing. - -If you have any requests or suggestions for future workshop events, please -[contact us][optech email]. - -## Workshops #3, #4 and #5 - Schnorr and Taproot Seminars {#taproot-workshop} - -- San Francisco, September 24 2019 -- New York, September 27 2019 -- London, February 5 2020 - -*Schnorr signatures* and *Taproot* are proposed changes to the Bitcoin -protocol that promise greatly improved privacy, fungibility, scalability and -functionality. - -Bitcoin Optech hosted two seminar format workshops which included a mixture of -presentations, coding exercises and discussions, and gave engineers at -member companies an understanding of how these new technologies work and how -they can be applied to their products and services. The workshops also provided -engineers an opportunity to take part in the feedback process while these -technologies are still in the proposal stage. - -[All material from the workshops][taproot workshop blog post] is available on this website, so engineers can -learn about the schnorr/taproot proposals at home. - -## Workshop #2 - Paris, November 12-13 2018 - -Bitcoin Optech held our second roundtable workshop in Paris on November 12-13 2018. -The format was the same as the first workshop in San Francisco. - -In attendance were 24 engineers from Bitcoin companies and open source -projects. - -#### Topics - -- Replace-by-fee vs. child-pays-for-parent as fee replacement techniques -- Partially Signed Bitcoin Transactions ([BIP 174](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki)) -- [Output script descriptors](https://gist.github.com/sipa/e3d23d498c430bb601c5bca83523fa82) for wallet interoperability -- Lightning wallet integration and applications for exchanges -- Approaches to coin selection & consolidation - -#### Thanks - -Thanks to Ledger for hosting the workshop and helping with organization. - -## Workshop #1 - San Francisco, July 17 2018 - -Bitcoin Optech held our first roundtable workshop in San Francisco on July 17 2018: - -- Topics were discussed in a roundtable format in which every participant had an - equal opportunity to engage. - -- Each topic had a moderator and notetaker. The moderator was responsible for a - brief introduction of a topic and keeping discussion on track and on time. - -- To make sure that participants were comfortable to speak freely, notes and - action items were distributed to participants but not beyond. Participants - were free to share discussion details internally at their companies and - publicly, but did not attribute any particular statement to a given individual - (Chatham House Rules). - -In attendance were 14 engineers from SF Bay Area Bitcoin companies and open -source projects. - -#### Topics - -- Coin selection -- Fee estimation, RBF, CPFP best practices -- Optech community and communication - -#### Thanks - -Thanks to Square for hosting the workshop and Coinbase for helping with -organization. - -{% include references.md %} - -[taproot workshop blog post]: /en/schorr-taproot-workshop/ diff --git a/zh/about.md b/zh/about.md new file mode 100644 index 0000000000..e0d04e8922 --- /dev/null +++ b/zh/about.md @@ -0,0 +1,41 @@ +--- +layout: page +title: About +permalink: /zh/about/ +--- + +Bitcoin Operations Technology Group（简称 Optech）致力于将最好的开源技术和技术手段引入使用比特币的企业，以降低成本并改善客户体验。 + +该组织的初期重点是与其成员组织合作，减少交易大小并尽量减少随后的交易费用增加的影响。我们提供[研讨会][workshops]、[每周通讯][weekly newsletters]、[原创研究][dashboard]、[案例研究和公告][blog]、[播客][podcast]，并帮助促进企业与开源社区之间的关系。 + +[workshops]: /zh/workshops +[weekly newsletters]: /zh/newsletters/ +[dashboard]: https://dashboard.bitcoinops.org/ +[blog]: /zh/blog/ +[podcast]: /en/podcast/ + +如果你是比特币公司的工程师或经理，或者是开源贡献者，并希望成为其中的一员，请通过 [info@bitcoinops.org](mailto:info@bitcoinops.org) 联系我们。 + +## 资金 + +Optech 不以盈利为目的，所有材料和文档均以 MIT 许可证发布。 + +初始资金由 Wences Casares 和 John Pfeffer 提供，用于支付外部承包商和偶发费用。Chaincode Labs 提供了支持 Optech 的资源。 + +我们慷慨的成员公司支付年度会费以覆盖费用。 + +## Optech 贡献者 + +Optech 生产的所有材料都是开源的，并以 MIT 许可证发布。任何人都可以通过提交 issue 和拉取请求、审阅通讯和其他材料，以及贡献翻译来参与。我们最常规的贡献者包括： + +{% assign contributors = site.data.contributors.contributors | sort: "name" %} +{% include contributors.html id="contributors" %} + +{% include sponsors.html %} + +## 前 Optech 贡献者 + +我们感谢所有之前的贡献者为我们所做的努力。 + +{% assign contributors = site.data.contributors.contributors_alum | sort: "name" %} +{% include contributors.html id="contributors_alum" %} diff --git a/zh/podcast.md b/zh/podcast.md new file mode 100644 index 0000000000..718d3d69ad --- /dev/null +++ b/zh/podcast.md @@ -0,0 +1,9 @@ +--- +layout: podcast +lang: zh +title: Podcast +name: podcast +permalink: /zh/podcast/ +share: false +version: 1 +--- diff --git a/zh/workshops.md b/zh/workshops.md new file mode 100644 index 0000000000..ac98439eac --- /dev/null +++ b/zh/workshops.md @@ -0,0 +1,64 @@ +--- +layout: page +title: Workshops +permalink: /zh/workshops/ +--- +比特币 Optech 将举办一系列研讨会，将比特币工程师聚集在一起，讨论实施扩容技术的方式和挑战。每个研讨会都会根据参与的会员公司及其面临的具体扩容挑战进行定制。 + +如果您对未来的研讨会活动有任何请求或建议，请[联系我们][optech email]。 + +## 第 3、4 和 5 次研讨会 - Schnorr 和 Taproot 研讨会 {#taproot-workshop} + +- 2019 年 9 月 24 日，旧金山 +- 2019 年 9 月 27 日，纽约 +- 2020 年 2 月 5 日，伦敦 + +*Schnorr 签名*和 *Taproot* 是对比特币协议的提议更改，承诺极大地改善隐私性、可替代性、可扩展性和功能性。 + +比特币 Optech 举办了两场研讨会，采用了研讨会形式，内容包括演示、编码练习和讨论，帮助会员公司的工程师了解这些新技术的工作原理及其如何应用于他们的产品和服务。研讨会还为工程师们提供了一个机会，让他们在这些技术仍处于提案阶段时参与反馈过程。 + +[研讨会的所有材料][taproot workshop blog post]都可以在本网站上获取，工程师们可以在家中学习 Schnorr/Taproot 提案。 + +## 第 2 次研讨会 - 巴黎，2018 年 11 月 12-13 日 + +比特币 Optech 于 2018 年 11 月 12-13 日在巴黎举办了第二次圆桌研讨会。形式与第一次旧金山的研讨会相同。 + +共有 24 名来自比特币公司和开源项目的工程师出席了会议。 + +#### 主题 + +- 作为费用替换技术的 Replace-by-fee 与 Child-pays-for-parent +- 部分签名比特币交易（[BIP 174](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki)） +- 用于钱包互操作性的[输出脚本描述符](https://gist.github.com/sipa/e3d23d498c430bb601c5bca83523fa82) +- 闪电钱包集成和交易所的应用 +- 币的选择与整合的方法 + +#### 感谢 + +感谢 Ledger 为研讨会提供场地并帮助组织。 + +## 第 1 次研讨会 - 旧金山，2018 年 7 月 17 日 + +比特币 Optech 于 2018 年 7 月 17 日在旧金山举办了首次圆桌研讨会： + +- 主题以圆桌会议形式进行讨论，每个参与者都有平等的机会参与。 + +- 每个主题都有一名主持人和记录员。主持人负责简要介绍主题并确保讨论按计划和时间进行。 + +- 为了确保参与者可以自由发言，会议记录和行动项仅分发给参与者，不会传播给其他人。参与者可以在其公司内部或公开分享讨论详情，但不能将任何特定发言归因于某个个人（遵循查塔姆规则）。 + +共有 14 名来自旧金山湾区比特币公司和开源项目的工程师出席了会议。 + +#### 主题 + +- 币选择 +- 费用估算、RBF、CPFP 最佳实践 +- Optech 社区和沟通 + +#### 感谢 + +感谢 Square 为研讨会提供场地，感谢 Coinbase 帮助组织活动。 + +{% include references.md %} + +[taproot workshop blog post]: /en/schorr-taproot-workshop/