diff --git a/.travis.yml b/.travis.yml index 41677711ed..575d6102bf 100644 --- a/.travis.yml +++ b/.travis.yml @@ -13,7 +13,5 @@ env: global: - NOKOGIRI_USE_SYSTEM_LIBRARIES=true # speeds up installation of html-proofer -# xenial builds fail if you don't update bundler before_install: - - yes | gem update --system - sudo apt install optipng diff --git a/.well-known/nostr.json b/.well-known/nostr.json new file mode 100644 index 0000000000..39770fd3a9 --- /dev/null +++ b/.well-known/nostr.json @@ -0,0 +1,5 @@ +{ + "names": { + "_": "bdb96ad31ac6af123c7683c55775ee2138da0f8f011e3994d56a27270e692575" + } +} \ No newline at end of file diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index f44cb5b8a8..10b8e72624 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -95,26 +95,20 @@ JEKYLL_ENV=local make build # Do a clean build of the site to the _site directo diff -ruN _site _site.bak # Compare the generated sites (-r for recursive, -u for unified, -N for new file) ``` -## Compatibility Matrix Data +## Bitcoin Feature Matrix Data -The compatibility matrix section of the website is built from -[YAML](https://yaml.org/) files located in [_data/compatibility/](_data/compatibility/). -Each wallet also requires a markdown file in -[en/compatibility/](en/compatibility/). The compatibility images (usability -screenshots, logos) are located in [img/compatibility/](img/compatibility/) with -sub-folders for each wallet or service. Make sure to optimize any png files using -`optipng -o7 `. These files are free for anyone to repurpose/republish -elsewhere. +The data in the Bitcoin Feature Matrix section of the website is: -We welcome pull requests to the compatibility matrix, including -testing the latest versions of previously tested services/wallets, adding notable -usability screenshots, or adding new service/wallet tests. +- collected via a Google Form +- transformed into [YAML](https://yaml.org/) files via a Google script +- located in [_data/matrix/](_data/matrix/) -When contributing changes to the compatibility matrix data files, review and adhere to -the YAML schema located in [_data/schemas/compatibility.yaml](_data/schemas/compatibility.yaml). +We welcome contributions/suggestions to the Bitcoin Feature Matrix: -If you believe any of the data in the compatibility matrix is incorrect, you -can also [submit an issue](../../issues/) detailing what is wrong and how to correct it. +- Add new products/services via the [Google Form](https://forms.gle/Vd7whDTTnyV6iNMk6) +- Request data updates via [issue submission](../../issues/) +- Propose new features to test via [issue submission](../../issues/) -If you want to request a new service or wallet be evaluated, or a new test that you -think is useful, please also submit an issue. +Changes shall be integrated during regular site updates. + +Questions and requests can also be directed at [steven@bitcoinops.org](mailto:steven@bitcoinops.org). diff --git a/Dockerfile b/Dockerfile new file mode 100644 index 0000000000..044a771cf5 --- /dev/null +++ b/Dockerfile @@ -0,0 +1,30 @@ +# Use an official Ruby runtime as a parent image +FROM ruby:2.6.4 + +# Install program to configure locales +RUN apt-get update && \ + apt-get install -y locales +RUN dpkg-reconfigure locales && \ + locale-gen C.UTF-8 && \ + /usr/sbin/update-locale LANG=C.UTF-8 + +# Install needed default locale for Makefly +RUN echo 'en_US.UTF-8 UTF-8' >> /etc/locale.gen && \ + locale-gen + +# Set default locale for the environment +ENV LC_ALL C.UTF-8 +ENV LANG en_US.UTF-8 +ENV LANGUAGE en_US.UTF-8 + +# Set the working directory +WORKDIR /usr/src/app + +# Copy just the Gemfile and Gemfile.lock first to leverage Docker cache +COPY Gemfile Gemfile.lock ./ + +# Install any needed gems specified in Gemfile +RUN bundle install + +# Make port 4000 available to the world outside this container +EXPOSE 4000 diff --git a/Makefile b/Makefile index 98677173ef..90bbbb48d8 100644 --- a/Makefile +++ b/Makefile @@ -10,8 +10,6 @@ export GIT_PAGER='_contrib/kill0' JEKYLL_FLAGS = --future --drafts --unpublished --incremental ## Expected filenames in output directory -compatibility_validation = $(wildcard _data/compatibility/*.yaml) -compatibility_validation := $(patsubst _data/compatibility/%.yaml,_site/en/compatibility/%/index.html,$(compatibility_validation)) topic_validation = $(wildcard _topics/en/*.md) topic_validation := $(patsubst _topics/en/%.md,_site/en/topics/%/index.html,$(topic_validation)) @@ -27,7 +25,7 @@ preview: _site/*/topics/categories/index.html \ _site/*/topics/dates/index.html \ _site/*/topics/index.html - bundle exec jekyll serve $(JEKYLL_FLAGS) + bundle exec jekyll serve --host 0.0.0.0 $(JEKYLL_FLAGS) build: @# Tiny sleep for when running concurrently to ensure output @@ -38,13 +36,19 @@ build: bundle exec jekyll build $(JEKYLL_FLAGS) -test-before-build: $(compatibility_validation) $(topic_validation) +test-before-build: $(topic_validation) ## Check for Markdown formatting problems @ ## - MD009: trailing spaces (can lead to extraneous
tags bundle exec mdl -g -r MD009 . - ## Check that posts declare a slug, see issue #155 and PR #156 + ## Hugo will end a paragraph if a line within it starts an HTML comment; we don't want that + ! git grep -l '^ * to same line to skip this test @ ## Ignores any strings with non alphabetical characters - export LC_ALL=C ; ! git ls-files '*.md' | while read file ; do \ + export LC_ALL=C ; ! git ls-files '*.md' | grep -v /podcast/ | while read file ; do \ cat $$file \ | sed '/skip-duplicate-words-test/d' \ | sed '/^#/d' \ @@ -82,11 +86,18 @@ test-before-build: $(compatibility_validation) $(topic_validation) ## Check for mistakes typical spell checkers can't catch ! git --no-pager grep -i '[d]iscrete log contract' + ! git --no-pager grep -i '[r]eplaca' # e.g., replaceability + ! git --no-pager grep -i '[h]tlc expiry delta' # instead use: CLTV expiry delta + + ## Check for indentation that's forward incompatible with Hugo + ! git ls-files '*.md' | xargs -i _contrib/find-bad-indentation '{}' | grep . test-after-build: build ## Check for broken Markdown reference-style links that are displayed in text unchanged, e.g. [broken][broken link] ! find _site/ -name '*.html' | xargs grep ']\[' | grep -v skip-test | grep . ! find _site/ -name '*.html' | xargs grep '\[^' | grep . + ! find _site/ -name '*.html' | xargs grep '\[\]' | grep -v skip-test | grep . + ! find _site/ -name '*.html' | xargs grep 'timestamp=' | grep -v skip-test | grep . ## Check for duplicate anchors ! find _site/ -name '*.html' | while read file ; do \ @@ -116,8 +127,5 @@ email: clean $(MAKE) preview JEKYLL_ENV=email ## Path-based rules -_site/en/compatibility/%/index.html : _data/compatibility/%.yaml - bundle exec _contrib/schema-validator.rb _data/schemas/compatibility.yaml $< - _site/en/topics/%/index.html : _topics/en/%.md bundle exec _contrib/schema-validator.rb _data/schemas/topics.yaml $< diff --git a/README.md b/README.md index 16895499e5..e83bb61863 100644 --- a/README.md +++ b/README.md @@ -20,10 +20,32 @@ contact us at [info@bitcoinops.org](mailto:info@bitcoinops.org). ## Building The Site Locally -To build the site, you need to go through a one-time installation +To build the site without docker, you need to go through a one-time installation procedure that takes 15 to 30 minutes. After that you can build the site an unlimited number of times with no extra work. +**Docker** + +Using Docker eliminates the need for local Ruby installation and +simplifies the setup process. Ensure Docker and Docker Compose are +installed, then run the following command in the project directory: + + docker compose up + +This will build the Docker image if needed and start the Jekyll server. +The site preview will be available at http://localhost:4000. + +For most code changes, Jekyll's live reload will automatically update +the preview. You only need to restart the container when making changes +such as: + +- Changing dependencies in the Gemfile +- Modifying Docker configuration files + +To rebuild and restart the container: + + docker compose down && docker compose up --build + ##### Install The Dependencies **Install RVM** diff --git a/STYLE-DE.md b/STYLE-DE.md new file mode 100644 index 0000000000..1b9d3f4513 --- /dev/null +++ b/STYLE-DE.md @@ -0,0 +1,123 @@ +# Optech Style Guide für deutsche Übersetzungen + +## Referenzierung von Newslettern + +Beim Verweis auf einen einzelnen Newsletter wird die Form „[Newsletter #nnn]“ verwendet, z. B.: + +> (siehe auch [Newsletter #315][news315 cb]) + +Bei Verweisen auf mehrere Newsletter werden die Nummern mit Kommas getrennt, z. B.: + +> (siehe Newsletter [#315], [#339] und [#361]) + +Diese Konvention gilt sowohl im Fließtext als auch in Aufzählungen. Die Referenzlinks werden wie im englischen Original am Ende der Datei gepflegt. + +## Grundsätzliches + +Die deutsche Übersetzung von Optech-Inhalten sollte möglichst den Regeln des englischen [Hauptleitfaden](STYLE.md) folgen. + +--- + +## Abschnittsüberschriften (Standardübersetzungen) + +| Englisch | Deutsch | +|------------------------------------------|-----------------------------------------------------------| +| News | Nachrichten | +| Changes to services and client software | Änderungen an Diensten und Client-Software | +| Releases and release candidates | Releases und Release-Kandidaten | +| Notable code and documentation changes | Wichtige Code- und Dokumentationsänderungen | +| Selected Q&A from Bitcoin Stack Exchange | Ausgewählte Fragen & Antworten von Bitcoin Stack Exchange | +| Correction | Korrektur | +| Consensus changes | Konsensänderungen | + +--- + +## Vokabular + +### Eigennamen + +Eigennamen werden wie im Hauptleitfaden groß geschrieben. + +### Gebräuchliche Substantive + +Im Deutschen werden Substantive groß geschrieben. + +- Bech32 +- Bitcoin (die Währung) +- BIPxxx + +### Zusammengesetzte Begriffe + +Fremdwörter möglichst mit Bindestrich schreiben (siehe [Duden, D41](https://www.duden.de/sprachwissen/rechtschreibregeln/fremdwoerter#D41)). + + +## Bevorzugte Begriffe für deutsche Übersetzung + +| Englisch | Bevorzugt (DE) | Zu vermeiden | Anmerkung/Kommentar | +|-------------------------|--------------------------|----------------------|------------------------------------------| +| blinded transaction | verdeckte Zahlung | | | +| derivation path | Ableitungspfad | | | +| descriptor | Deskriptor | | | +| dual funding | beidseitige Finanzierung | | | +| fee | Gebühr | | | +| funds | Kapital | | | +| lightning network | Lightning Netzwerk | | | +| listening node | empfangender Knoten | lauschender Knoten | "lauschend" hat Konnotation des Abhörens | +| node | Knoten | Node | Full Node wird nicht übersetzt | +| relay | Weiterleitung | | | +| work | Arbeitsnachweis | Arbeit | Im Kontext von PoW | + +--- + +## Nicht übersetzte Begriffe und Ausnahmen + +| Englischer Ausdruck | Kontext / Anmerkung | Genus | +|------------------------------- |-----------------------------------------------------|----------------------------| +| BDK | Produktname | | +| BIP(mit nummer) | Protokoll-/Standardbegriff | | +| BLIP | Protokoll-/Standardbegriff | | +| BTCPay Server | Produktname | Maskulinum | +| Channel | Etablierter Fachbegriff | Maskulinum | +| coin / coins | Coin ist im Kontext ein Fachbegriff | Maskulinum | +| Core Lightning | Produktname | | +| Countersign | Eigenname des Verfahrens | Neutrum | +| Delving Bitcoin | Plattform-/Listenname | | +| DLC | Layer-2/Smart-Contract/Transaktionsbegriff | | +| DLC-Dev | Plattform-/Listenname | | +| E-Cash-Share | Korrigiert von "E-Cash-Anteil" | Maskulinum | +| Eclair | Produktname | | +| FPPS | Technischer Begriff/Auszahlungssystem | | +| Full Node / Full Nodes | Immer im Original belassen | | +| HTLC | Immer im Original belassen | | +| Human Readable Names | Produkt-/Technikname | | +| LDK | Produkt-/Technikname | | +| LN | Layer-2/Smart-Contract/Transaktionsbegriff | | +| LSPS | Produkt-/Technikname | | +| merged | Git/GitHub-Terminologie | | +| Mining | Etablierter Fachbegriff | Femininum | +| non-custodial | Immer im Original belassen, ist etabliert | | +| Offchain | Layer-2/Smart-Contract/Transaktionsbegriff | | +| On-Chain | Layer-2/Smart-Contract/Transaktionsbegriff | | +| OP_CHECKTEMPLATEVERIFY (CTV) | Protokoll-/Standardbegriff | | +| Oracle | Lightning/DLC-Technik | | +| output / input (bei UTXO) | Nur im UTXO-Kontext nicht übersetzen | Maskulinum | +| Pay-per-Last-N-Shares | Technische Begriffe/Auszahlungssysteme | | +| Pool | Etablierter Fachbegriff | Maskulinum | +| Pool-Miner | Etablierter Fachbegriff | Maskulinum | +| PR | Git/GitHub-Terminologie | Maskulinum | +| Proxy | Technischer Begriff | Maskulinum | +| PSBT | Protokoll-/Standardbegriff | | +| PPLNS | Technischer Begriff/Auszahlungssystem | | +| Release | Softwarebegriff | Neutrum | +| Reviewer | Softwarebegriff | Maskulinum | +| Rust Bitcoin | Produktname | | +| SCID | Protokoll-/Standardbegriff | | +| Silent payment | Standardbegriff | | +| Simple Taproot Channels | Lightning/DLC-Technik | | +| Splice | Protokoll-/Standardbegriff | | +| Splicing | Protokoll-/Standardbegriff | Neutrum | +| TIDES | Name des Systems | | +| UTXO | Immer im Original belassen | | +| Wallet | Produkt-/Technikname | | + +--- \ No newline at end of file diff --git a/STYLE-PT.md b/STYLE-PT.md new file mode 100644 index 0000000000..cb954f219f --- /dev/null +++ b/STYLE-PT.md @@ -0,0 +1,87 @@ +# Optech Style Guide para Traduções em português + +## Básico + +A tradução para português de conteúdos do Optech devem seguir as regres o [Guia principal](STYLE.md) sempre que possivel. + +## Títulos de seção (traduções padrão) + +| Inglês | Português | +|------------------------------------------|--------------------------------------------------------------| +| News | Notícias | +| Changes to services and client software | Alterações nos serviços e software do cliente | +| Notable code and documentation changes | Alterações importantes de código e documentação | +| Selected Q&A from Bitcoin Stack Exchange | Perguntas e respostas selecionadas do Bitcoin Stack Exchange | +| Correction | Correção | +| Consensus changes | Mudanças de consenso | + +## Vocabulário + +### nomes próprios + +Os nomes próprios devem ser capitalizados como no guia principal. + +## Termos preferidos para tradução para a lingua portuguesa + +| Inglês | Preferido (PT) | Evitar | Observações | +|-------------------------|--------------------------|----------------------|------------------------------------------| +| channel | canal | | | +| fee | taxa | | | +| funds | fundos | | | +| input/output | entrada/saida | | | +| lightning network | Rede Lightning | | | +| node | Nó | Node | Full-node não é traduzido | +| proof of work | prova de trabalho | | | +| wallet | carteira | | | + +## Termos e exceções não traduzidos + +| Inglês | Contexto / observações | +|------------------------------- |-----------------------------------------------------------| +| BDK | Nome do produto | +| BIP(número) | Protocolo/Termo técnico | +| BLIP | Protocolo/Termo técnico | +| BTCPay Server | Nome do produto | +| Channel | Termo técnico estabelecido | +| Core Lightning | Nome do produto | +| Delving Bitcoin | Plataforma / Nome de newsletter | +| DLC | Camada 2 / Contrato Inteligente / Conceito de Transação | +| DLC-Dev | Plataforma / Nome de newsletter | +| Derivation path | Termo técnico | +| Descriptor | Termo técnico | +| dual funding | Termo técnico | +| Eclair | Nome do produto | +| FPPS | Termo técnico / Sistema de pagamento | +| Full Node / Full Nodes | Sempre deixado no original | +| HTLC | Sempre deixado no original | +| Human Readable Names | Termo técnico | +| LDK | Nome do produto | +| LN | Camada 2 / Contrato Inteligente / Conceito de Transação | +| LSP | Nome do produto | +| Mining | Termo técnico estabelecido | +| On-Chain | Camada 2 / Contrato Inteligente / Conceito de Transação | +| OP_CHECKTEMPLATEVERIFY (CTV) | Termo tecnico de protocolo | +| Oracle | Lightning/Tecnologia DLC | +| Pay-per-Last-N-Shares | Termos técnicos / Sistemas de pagamento | +| Pool | Termo técnico estabelecido | +| Pool-Miner | Termo técnico estabelecido | +| PR | Terminologia do Git/GitHub | +| Proxy | Termo técnico estabelecido | +| PSBT | Termo tecnico de protocolo | +| PPLNS | Termo técnico / Sistema de pagamento | +| Release | Termo de software | +| Releases | Termo de software | +| Rust Bitcoin | Nome do produto | +| SCID | Protocolo/Termo técnico | +| Simple Taproot Channels | Lightning/Tecnologia DLC | +| Splice | Protocolo/Termo técnico | +| TIDES | Nome do sistema | +| UTXO | Termo técnico estabelecido | +| merged | Terminologia do Git/GitHub | +| Offchain | Layer-2/Smart-Contract/Conceito de Transação | + +--- + +### Unidades de medida + +Ver [Guia principal](STYLE.md). \ No newline at end of file diff --git a/STYLE.md b/STYLE.md index 7aa53fe074..26520e6f16 100644 --- a/STYLE.md +++ b/STYLE.md @@ -93,7 +93,7 @@ beginning of a sentence). | Use | Don't use | Notes | |-|-|-| | anti fee sniping | anti-fee sniping, anti-fee-sniping | | -| block chain | blockchain | | +| blockchain | block chain | "block chain" is acceptable in unmodified older documents | | chain split | chainsplit | | | CPFP or Child Pays For Parent | Child-Pays-For-Parent | | | coinjoin | Coinjoin, coinJoin or coin-join | | @@ -122,6 +122,7 @@ beginning of a sentence). | single-sig | singlesig | | | soft fork/hard fork | softfork/hardfork or soft-fork/hard-fork | soft-fork/hard-fork may be used as compound adjectives (eg "Foo proposed a soft-fork change") | | Stack Exchange | StackExchange | as the website spells itself | +| zero-conf | zeroconf, zero conf, 0-conf | unconfirmed transaction | | 2-of-3 | 2 of 3 | | ### Spelling @@ -193,3 +194,26 @@ spelled the same. for placing a space between a number and its unit of measurement, e.g. "1 sat/vB" or "20 MB" are acceptable. Exception: percentages, e.g. "50%" is acceptable. + +## Linking + +- **Separate links:** avoid placing two links immediately next to each + other as they may appear as one link. Discouraged: + [package](/en/topics/package-relay/) [replace-by-fee](/en/topics/replace-by-fee/). + Preferred: + [replace-by-fee](/en/topics/replace-by-fee/) for + [packages](/en/topics/package-relay/). + +- **Link abbreviations not expansions:** when introducing an + abbreviation and including a link at the same time, link the + abbrevation rather than the expansion. The goal is to minimize the + amount of special formatting on the page (e.g. blue links) without + reducing the information density. Discouraged: [topologically + restricted until + confirmation](/en/topics/version-3-transaction-relay/) + (TRUC). Preferred: topologically restricted until confirmation + ([TRUC](/en/topics/version-3-transaction-relay/)). + +- **Newsletter linking:** when linking to previous newsletters, prefer link text + as "[Newsletter #nnn]" when it is one newsletter being referenced and + "Newsletter [#nnn], [#nnn], [#nnn]" when more than one being referenced. diff --git a/_config.yml b/_config.yml index a23220a255..3ce8a22284 100644 --- a/_config.yml +++ b/_config.yml @@ -47,6 +47,8 @@ exclude: - README.md - CONTRIBUTING.md +include: [".well-known"] + show_excerpts: true defaults: @@ -78,5 +80,11 @@ languages: name: Hindi - code: zh name: Chinese + - code: de + name: German + - code: fr + name: French + - code: pt + name: Portuguese ## In-text aliases trb: "709,632" # TapRoot Block (activation) diff --git a/_contrib/find-bad-indentation b/_contrib/find-bad-indentation new file mode 100755 index 0000000000..5624686b51 --- /dev/null +++ b/_contrib/find-bad-indentation @@ -0,0 +1,50 @@ +#!/usr/bin/env python3 + +import sys +import re + +def check_file(filename): + try: + with open(filename, 'r') as file: + lines = file.readlines() + + # Possible values for X + X_values = [2, 4, 6, 8] + + # Maximum indentation that could reasonably be checked for (arbitrary large value or calculated based on file analysis) + max_indent = 12 + + # Check every set of three lines + for i in range(len(lines) - 2): + first_line = lines[i] + second_line = lines[i + 1] + third_line = lines[i + 2] + + # Ensure the second line is empty + if second_line == '\n': + for X in X_values: + if re.match(rf'^\s{{{X}}}(?![-\*]|[0-9]*\.)\S', first_line): + # Check Y from X+1 to max_indent to ensure it's greater + for Y in range(X + 1, max_indent + 1): + if re.match(rf'^\s{{{Y}}}\S', third_line): + print(f"Found inconsitent indentation {X} and and {Y} spaces in", filename) + print(first_line, second_line, third_line) + return 1 # Return error code 1 if a match is found + + return 0 # Return error code 0 if no match is found + + except FileNotFoundError: + print("File not found.") + return 2 # Return error code 2 if the file does not exist + +if __name__ == "__main__": + if len(sys.argv) < 2: + print("Usage: python script.py ") + sys.exit(1) # Exit with error code 1 if no filename is provided + + filename = sys.argv[1] + result = check_file(filename) + sys.exit(result) + +import sys +import re diff --git a/_contrib/new-topic b/_contrib/new-topic index d7fee23451..48f11a28d9 100755 --- a/_contrib/new-topic +++ b/_contrib/new-topic @@ -30,12 +30,12 @@ title: ${topic} # shortname: foo ## Optional. An entry will be added to the topics index for each alias -#aliases: +#title-aliases: # - Foo ## Required. At least one category to which this topic belongs. See ## schema for options -categories: +topic-categories: - TODO ## Optional. Produces a Markdown link with either "[title][]" or diff --git a/_contrib/update-newsletter-index-variables b/_contrib/update-newsletter-index-variables deleted file mode 100755 index 892243b71f..0000000000 --- a/_contrib/update-newsletter-index-variables +++ /dev/null @@ -1,46 +0,0 @@ -#!/bin/bash -eu - -## Update the list of variables that point to each newsletter. Must be -## run from the top-level directory in the repository. Update yearly to -## create variables for all that year's newsletters. Also requires -## updating for schedule changes. -# -## It's probably best if everything is done in chronolical order - -OUTPUT=_includes/linkers/newsletters.md -if ! [ -f "$OUTPUT" ] -then - echo "Error: $OUTPUT not found. You must run $0 from the top-level repository directory." - exit 1 -fi - -## Generate a list of newsletters a week apart starting from particular -## date and issue number -_seq_news() { - start_date="$1" - start_issue="$2" - count="$(( $3 - 1 ))" - for i in $( seq 0 $count ) - do - issue_number=$(( start_issue + i )) - issue_date=$( date +%Y/%m/%d -d "$start_date +$((i*7)) days") - echo '{% assign news'$issue_number' = "/en/newsletters/'$issue_date'/" %}' - echo "[Newsletter #${issue_number}]: {{news${issue_number}}}" - done -} - -## Write all stdout to the output file. stderr will still be printed to the controling console -exec > $OUTPUT -echo '''{% comment %}{% endcomment %}''' - -## Original PoC newsletter -_seq_news 2018-06-08 0 1 -## Start regular publication -_seq_news 2018-06-26 1 26 -## Christmas special -_seq_news 2018-12-28 27 1 -## Resume regular publication -_seq_news 2019-01-08 28 47 -## New Wednesday publication -_seq_news 2019-05-29 48 30 diff --git a/_data/compatibility/abra.yaml b/_data/compatibility/abra.yaml deleted file mode 100644 index 4d8f14abdd..0000000000 --- a/_data/compatibility/abra.yaml +++ /dev/null @@ -1,85 +0,0 @@ ---- -name: Abra -internal_url: /en/compatibility/abra -logo: /img/compatibility/abra/abra.png -rbf: - tested: - date: "2018-12-06" - platforms: - - iOS - version: "5.4.0" - features: - receive: - notification: "na" - list: "false" - details: "false" - shows_replaced_version: "false" - shows_original_version: "false" - send: - signals_bip125: "false" - list: "untested" - details: "untested" - shows_replaced_version: "untested" - shows_original_version: "untested" - examples: - - image: /img/compatibility/abra/rbf/send-screen-default.png - caption: > - Sending Transaction - Default send transaction screen. - - image: /img/compatibility/abra/rbf/send-confirm.png - caption: > - Sending Transaction - Send transaction confirmation screen. - - image: /img/compatibility/abra/rbf/send-fee-notice.png - caption: > - Sending Transaction - Network fee notice details. - - image: /img/compatibility/abra/rbf/transaction-list-sent.png - caption: > - Sending Transaction - Transaction list screen showing sent transaction. No RBF notice. - - image: /img/compatibility/abra/rbf/transaction-details-sent.png - caption: > - Sending Transaction - Sent transaction details. No RBF notice. Note transaction sent without RBF flag. Transaction was not sent with RBF so no bumping available. - - image: /img/compatibility/abra/rbf/transaction-list-incoming-rbf.png - caption: > - Receiving Transaction Signaling RBF - Abra does not show unconfirmed transactions. - - image: /img/compatibility/abra/rbf/notification-incoming-replacement.png - caption: > - Receiving Replacement Transaction - When the replacement transaction receives 1 confirmation it appears in wallet. No RBF notice. - - image: /img/compatibility/abra/rbf/transaction-list-incoming-replacement.png - caption: > - Receiving Replacement Transaction - Transaction list screen. No RBF flag. - - image: /img/compatibility/abra/rbf/transaction-details-replacement-confirmed.png - caption: > - Receiving Replacement Transaction - Replacement transaction details. -segwit: - tested: - date: "2019-04-11" - platforms: - - iOS - version: "5.11.1" - features: - receive: - p2sh_wrapped: "false" - bech32: "false" - default: "p2pkh" - send: - bech32: "false" - change_bech32: "untested" - segwit_v1: "Bech32 not supported." - bech32_p2wsh: "false" - examples: - - image: /img/compatibility/abra/segwit/receive-screen.png - caption: > - Abra uses P2PKH addresses for receiving. - - image: /img/compatibility/abra/segwit/send-bech32.png - caption: > - Abra allows a bech32 address to be input and does not provide a warning. - However, the review button was not enabled until a non-bech32 address - was provided. The eventually sent transaction used exact change so - change address format was not determined. - - image: /img/compatibility/abra/segwit/send-bech32-qr.png - caption: > - When using the QR code scanner, an error about address format was shown - when scanning a bech32 address. - - image: /img/compatibility/abra/segwit/send-non-bech32.png - caption: > - When using a non bech32 address, the "Review" button is enabled. Button - is disabled when using bech32 address format. \ No newline at end of file diff --git a/_data/compatibility/binance.yaml b/_data/compatibility/binance.yaml deleted file mode 100644 index 83fb0b5b5a..0000000000 --- a/_data/compatibility/binance.yaml +++ /dev/null @@ -1,71 +0,0 @@ ---- -name: Binance -internal_url: /en/compatibility/binance -logo: /img/compatibility/binance/binance.png -rbf: - tested: - date: "2018-11-06" - platforms: - - web - version: "n/a" - features: - receive: - notification: "false" - list: "false" - details: "false" - shows_replaced_version: "false" - shows_original_version: "false" - send: - signals_bip125: "false" - list: "untested" - details: "untested" - shows_replaced_version: "untested" - shows_original_version: "untested" - examples: - - image: /img/compatibility/binance/rbf/send-screen.png - caption: > - Sending Transaction - Default send (withdrawal) screen. No RBF options. - - image: /img/compatibility/binance/rbf/transaction-list-sent.png - caption: > - Attempting Transaction Replacement - Transaction not sent via RBF. No fee bump options. - - image: /img/compatibility/binance/rbf/transaction-list-incoming-rbf.png - caption: > - Receiving Transaction Signaling RBF - No unconfirmed transactions appear in transaction list. - - image: /img/compatibility/binance/rbf/transaction-list-replacement-confirmed.png - caption: > - Receiving Replacement Transaction - Replacement transaction only shows up after confirmation. Neither transaction shows before. -segwit: - tested: - date: "2019-04-11" - platforms: - - web - version: "n/a" - features: - receive: - p2sh_wrapped: "false" - bech32: "false" - default: "p2pkh" - send: - bech32: "true" - change_bech32: "untested" - segwit_v1: "Does not pass front end javascript validation" - bech32_p2wsh: "false" - examples: - - image: /img/compatibility/binance/segwit/receive-screen.png - caption: > - Binance receives via P2PKH addresses. - - image: /img/compatibility/binance/segwit/send-screen.png - caption: > - Default send screen accepts a bech32 address. - - image: /img/compatibility/binance/segwit/send-address-error.png - caption: > - While Binance allows bech32 P2WPKH withdrawals, you cannot add a bech32 address - to your address book _from the send screen_. While attempting to add a bech32 address, after - the two-factor authentication code, an address error message appears. - - image: /img/compatibility/binance/segwit/send-p2wsh-error.png - caption: > - Bech32 P2WSH addresses cause a validation error from the send screen and address - book screens. - - image: /img/compatibility/binance/segwit/address-book-add.png - caption: > - Bech32 P2WPKH addresses can be successfully added using the address book functionality. \ No newline at end of file diff --git a/_data/compatibility/bitcoin-core.yaml b/_data/compatibility/bitcoin-core.yaml deleted file mode 100644 index e0e3f9c6d7..0000000000 --- a/_data/compatibility/bitcoin-core.yaml +++ /dev/null @@ -1,106 +0,0 @@ ---- -name: Bitcoin Core Wallet -internal_url: /en/compatibility/bitcoin-core -logo: /img/compatibility/bitcoin-core/bitcoin-core.png -rbf: - tested: - date: "2018-08-28" - platforms: - - macOS - version: "0.16.2" - features: - receive: - notification: "false" - list: "false" - details: "false" - shows_replaced_version: "true" - shows_original_version: "true" - send: - signals_bip125: "true" # default in GUI, not default from CLI - list: "false" - details: "false" - shows_replaced_version: "true" - shows_original_version: "true" - examples: - - image: /img/compatibility/bitcoin-core/default-wallet-send-screen.png - caption: > - Sending Transaction - Default wallet send screen. - - image: /img/compatibility/bitcoin-core/wallet-send-screen-fee-details.png - caption: > - Sending Transaction - Wallet Send Screen (Transaction Fee details expanded). - - image: /img/compatibility/bitcoin-core/low-fee-confirmation-with-rbf-note.png - caption: > - Sending Transaction - Warning prompt for low fee. Includes RBF note at the bottom when RBF disabled. - - image: /img/compatibility/bitcoin-core/low-fee-confirmation-with-rbf-note-enabled.png - caption: > - Sending Transaction - Warning prompt for low fee. Includes RBF note at the bottom when RBF enabled. - - image: /img/compatibility/bitcoin-core/transaction-list-outgoing-rbf-transaction.png - caption: > - Sending Transaction - Transaction list screen for outgoing transaction signaling RBF. No note of RBF signaling. - - image: /img/compatibility/bitcoin-core/transaction-details-outgoing-rbf.png - caption: > - Sending Transaction - Transaction details screen for outgoing transaction signaling RBF. No note of RBF signaling. - - image: /img/compatibility/bitcoin-core/transaction-details-context-menu-increase-fee.png - caption: > - Attempting Transaction Replacement - Transaction details context menu showing “Increase transaction fee”. - - image: /img/compatibility/bitcoin-core/increase-fee-confirmation-prompt.png - caption: > - Attempting Transaction Replacement - Confirmation prompt for “Increase transaction fee”. - - image: /img/compatibility/bitcoin-core/transaction-list-post-bump.png - caption: > - Attempting Transaction Replacement - Transaction list showing an additional transaction representing the replacement transaction. The original shows up greyed out with brackets around the amount. - - image: /img/compatibility/bitcoin-core/transaction-details-bumped-transaction.png - caption: > - Attempting Transaction Replacement - Transaction details of the outgoing bumped RBF transaction. No flag for RBF. - - image: /img/compatibility/bitcoin-core/notification-incoming-transaction.png - caption: > - Receiving Transaction Signaling RBF - Notification of incoming transaction. No specific note that the transaction signals RBF. - - image: /img/compatibility/bitcoin-core/transaction-list-rbf-incoming.png - caption: > - Receiving Transaction Signaling RBF - Transaction List Screen. No RBF note. - - image: /img/compatibility/bitcoin-core/transaction-details-rbf-incoming.png - caption: > - Receiving Transaction Signaling RBF - Transaction Details screen for an transaction signaling RBF. No RBF note. - - image: /img/compatibility/bitcoin-core/notification-replacement-transaction.png - caption: > - Receiving Replacement Transaction - New transaction notification for the replacement transaction. - - image: /img/compatibility/bitcoin-core/transaction-list-replacement-incoming.png - caption: > - Receiving Replacement Transaction - Transaction List Screen. No RBF note. Both the original and replacement transaction appear with “?”/unconfirmed. - - image: /img/compatibility/bitcoin-core/transaction-details-original.png - caption: > - Receiving Replacement Transaction - Transaction Details screen for original transaction. No RBF note. - - image: /img/compatibility/bitcoin-core/transaction-details-replacement.png - caption: > - Receiving Replacement Transaction - Transaction Details screen for replacement transaction. No RBF note. -segwit: - tested: - date: "2019-03-28" - platforms: - - macOS - version: "0.17.1" - features: - receive: - p2sh_wrapped: "true" - bech32: "true" - default: "p2sh_wrapped" - send: - bech32: "true" - change_bech32: "true" - segwit_v1: "Transaction can be created and broadcast, but does not make it - to the mempool." - bech32_p2wsh: "true" - examples: - - image: /img/compatibility/bitcoin-core/segwit/receive-screen.png - caption: > - Receive - Generate a new address with tooltip. Bech32 option defaults to - unchecked. If checked, the checkbox will still be unchecked once - Bitcoin-Qt is restarted. - - image: /img/compatibility/bitcoin-core/segwit/address-screen.png - caption: > - Address Details - Showing Bech32 address as well as equivalent uri and QR code. - - image: /img/compatibility/bitcoin-core/segwit/send-screen.png - caption: > - Send - By default, the change address takes the same type as the address - being paid to. Can be overridden with change control's 'Custom change - address'. \ No newline at end of file diff --git a/_data/compatibility/bitcoin-wallet.yaml b/_data/compatibility/bitcoin-wallet.yaml deleted file mode 100644 index 62d2984540..0000000000 --- a/_data/compatibility/bitcoin-wallet.yaml +++ /dev/null @@ -1,20 +0,0 @@ ---- -# https://github.com/bitcoin-wallet/bitcoin-wallet -name: Bitcoin Wallet -internal_url: /en/compatibility/bitcoin-wallet -logo: /img/compatibility/bitcoin-wallet/bitcoin-wallet.png -segwit: - tested: - date: "2019-11-06" - platforms: - - Android - version: "7.26" - features: - receive: - p2sh_wrapped: "false" - bech32: "true" - default: "bech32" - send: - bech32: "true" - change_bech32: "true" - bech32_p2wsh: "true" diff --git a/_data/compatibility/bitgo.yaml b/_data/compatibility/bitgo.yaml deleted file mode 100644 index 902e995415..0000000000 --- a/_data/compatibility/bitgo.yaml +++ /dev/null @@ -1,73 +0,0 @@ ---- -name: BitGo -internal_url: /en/compatibility/bitgo -logo: /img/compatibility/bitgo/bitgo.png -rbf: - tested: - date: "2018-12-06" - platforms: - - web - version: "n/a" - features: - receive: - notification: "false" - list: "false" - details: "false" - shows_replaced_version: "false" - shows_original_version: "false" - send: - signals_bip125: "false" - list: "untested" - details: "untested" - shows_replaced_version: "untested" - shows_original_version: "untested" - examples: - - image: /img/compatibility/bitgo/rbf/send-screen.png - caption: > - Sending Transaction - Default send transaction screen with fee options expanded. No RBF options. - - image: /img/compatibility/bitgo/rbf/sent-confirmation.png - caption: > - Sending Transaction - Send confirmation screen. Fee noted. No RBF note. Note Transaction was not sent with RBF flag enabled. - - image: /img/compatibility/bitgo/rbf/transaction-list-sent.png - caption: > - Attempting Transaction Replacement - Transaction list screen showing sent transaction. No RBF options. Note BitGo uses the Smartbit explorer to show transaction details. - - image: /img/compatibility/bitgo/rbf/transaction-list-incoming-rbf.png - caption: > - Receiving Transaction Signaling RBF - Unconfirmed transactions do not appear in BitGo transactions list. - - image: /img/compatibility/bitgo/rbf/notification-incoming-rbf.png - caption: > - Receiving Transaction Signaling RBF - Incoming transaction email. No RBF note. - - image: /img/compatibility/bitgo/rbf/transaction-list-replacement-confirmed.png - caption: > - Receiving Replacement Transaction - Since no unconfirmed transaction - appear, neither original nor replacement show until the replacement - transactions confirms. -segwit: - tested: - date: "2021-08-17" - platforms: - - web - version: "n/a" - features: - receive: - p2sh_wrapped: "true" - bech32: "false" - default: "p2sh_wrapped" - send: - bech32: "true" - change_bech32: "true" - segwit_v1: "Error occurs during sending process, after validation." - bech32_p2wsh: "true" - examples: - - image: /img/compatibility/bitgo/segwit/receive-screen.png - caption: > - BitGo's web wallet UI defaults to P2SH-wrapped segwit addresses. - Visually, the segwit logo is displayed next to segwit addresses with a - tooltip indicating "Wrapped Segwit". While bech32 receive addresses are - not possible in the UI currently, bech32 receive addresses can be generated using the API. - - image: /img/compatibility/bitgo/segwit/send-screen.png - caption: > - BitGo's web wallet allows sending to bech32 addresses. - #- image: /img/compatibility/bitgo/segwit/send-v1.png - # caption: > - # BitGo's web wallet displays an error when attempting send to segwit v1 addresses. \ No newline at end of file diff --git a/_data/compatibility/bitmex.yaml b/_data/compatibility/bitmex.yaml deleted file mode 100644 index f6dfe856b2..0000000000 --- a/_data/compatibility/bitmex.yaml +++ /dev/null @@ -1,47 +0,0 @@ ---- -name: BitMEX -internal_url: /en/compatibility/bitmex -logo: /img/compatibility/bitmex/bitmex.png -rbf: - tested: - date: "2018-11-05" - platforms: - - web - version: "n/a" - features: - receive: - notification: "na" - list: "false" - details: "false" - shows_replaced_version: "false" - shows_original_version: "false" - send: - signals_bip125: "false" - list: "untested" - details: "untested" - shows_replaced_version: "untested" - shows_original_version: "untested" - examples: - - image: /img/compatibility/bitmex/rbf/send-screen.png - caption: > - Sending Transaction - Send Transaction screen. Transactions sent out of BitMEX are not RBF signaled. BitMEX only accepts confirmed transactions. -segwit: - tested: - date: "2021-01-27" - platforms: - - web - version: "n/a" - features: - receive: - p2sh_wrapped: "false" - bech32: "true" - default: "bech32" - send: - bech32: "true" # https://blog.bitmex.com/bitmex-enables-bech32-sending-support/ - change_bech32: "true" - segwit_v1: "Bech32m supported." # https://twitter.com/BitMEXResearch/status/1492152557044654082 - bech32_p2wsh: "true" - examples: - - image: /img/compatibility/bitmex/segwit/receive-screen.png - caption: > - BitMEX uses a static P2SH address per user account. diff --git a/_data/compatibility/bitnob.yaml b/_data/compatibility/bitnob.yaml deleted file mode 100644 index bebd2d83d7..0000000000 --- a/_data/compatibility/bitnob.yaml +++ /dev/null @@ -1,55 +0,0 @@ ---- -name: Bitnob -internal_url: /en/compatibility/bitnob -logo: /img/compatibility/bitnob/bitnob.png -rbf: - tested: - date: "2022-05-11" - platforms: - - Android - version: "10.0.0" - features: - receive: - notification: "false" - list: "false" - details: "false" - shows_replaced_version: "false" - shows_original_version: "false" - send: - signals_bip125: "false" - list: "false" - details: "false" - shows_replaced_version: "na" - shows_original_version: "na" - examples: - - image: /img/compatibility/bitnob/rbf/send-fee-notice.png - caption: > - Transaction sending confirmation screen - Bitnob does not have an option to enable RBF when sending transactions. - - image: /img/compatibility/bitnob/rbf/transaction-list-incoming-rbf.png - caption: > - Receiving Transaction Signaling RBF - Bitnob doesn't show unconfirmed transactions signaling RBF. - -segwit: - tested: - date: "2022-05-11" - platforms: - - Android - version: "10.0.0" - features: - receive: - p2sh_wrapped: "true" - bech32: "true" - default: "bech32_p2wsh" - send: - bech32: "true" - change_bech32: "untested" - segwit_v1: "true" - bech32_p2wsh: "true" - examples: - - image: /img/compatibility/bitnob/segwit/send-screen-default.png - caption: > - Bitnob supports sending to bech32 addresses - - image: /img/compatibility/bitnob/segwit/receive-screen.png - caption: > - Bitnob's default receive address type is p2wsh (native segwit) - diff --git a/_data/compatibility/bitrefill.yaml b/_data/compatibility/bitrefill.yaml deleted file mode 100644 index cbded9b5c8..0000000000 --- a/_data/compatibility/bitrefill.yaml +++ /dev/null @@ -1,65 +0,0 @@ ---- -name: Bitrefill -internal_url: /en/compatibility/bitrefill -logo: /img/compatibility/bitrefill/bitrefill.png -rbf: - tested: - date: "2018-11-06" - platforms: - - web - version: "n/a" - features: - receive: - notification: "na" - list: "false" - details: "false" - shows_replaced_version: "true" - shows_original_version: "true" - send: - signals_bip125: "true" - list: "false" - details: "false" - shows_replaced_version: "na" - shows_original_version: "na" - examples: - - image: /img/compatibility/bitrefill/rbf/send-screen.png - caption: > - Sending Transaction - Default send transaction screen. No RBF info. Transaction was sent via RBF. - - image: /img/compatibility/bitrefill/rbf/transaction-list-sent.png - caption: > - Attempting Transaction Replacement - Transaction list screen. No way to manually bump the transaction. Was sent RBF. - - image: /img/compatibility/bitrefill/rbf/transaction-list-incoming-rbf.png - caption: > - Receiving Transaction Signaling RBF - No incoming transactions show initially during original transaction. This delay could have been related to delays in relaying the transaction in the Bitcoin network. - - image: /img/compatibility/bitrefill/rbf/transaction-list-incoming-replacement.png - caption: > - Receiving Replacement Transaction - After replacement transaction was broadcast, both transactions show up as pending. Stayed as pending even after the replacement transaction had 6+ confirmations. - - image: /img/compatibility/bitrefill/rbf/transaction-list-replacement-confirmed.png - caption: > - Receiving Replacement Transaction - At some point in the next day, the original transaction was marked failed and replacement transaction was credited to account and marked complete. -segwit: - tested: - date: "2019-04-12" - platforms: - - web - version: "n/a" - features: - receive: - p2sh_wrapped: "true" - bech32: "false" - default: "p2sh_wrapped" - send: - bech32: "true" - change_bech32: "true" - segwit_v1: "Address does not pass validation." - bech32_p2wsh: "true" - examples: - - image: /img/compatibility/bitrefill/segwit/receive-screen.png - caption: > - Bitrefill allows P2SH-wrapped segwit deposits. No bech32 option available. - - image: /img/compatibility/bitrefill/segwit/send-screen.png - caption: > - Bitrefill can send to bech32 native addresses. Change address is also bech32. - #- image: /img/compatibility/bitrefill/segwit/send-v1.png - # caption: > - # Bitrefill displays an address validation error for segwit v1 addresses. \ No newline at end of file diff --git a/_data/compatibility/bitstamp.yaml b/_data/compatibility/bitstamp.yaml deleted file mode 100644 index f4bcc1b96a..0000000000 --- a/_data/compatibility/bitstamp.yaml +++ /dev/null @@ -1,59 +0,0 @@ ---- -name: Bitstamp -internal_url: /en/compatibility/bitstamp -logo: /img/compatibility/bitstamp/bitstamp.png -rbf: - tested: - date: "2018-11-06" - platforms: - - web - version: "n/a" - features: - receive: - notification: "false" - list: "false" - details: "false" - shows_replaced_version: "false" - shows_original_version: "false" - send: - signals_bip125: "false" - list: "untested" - details: "untested" - shows_replaced_version: "untested" - shows_original_version: "untested" - examples: - - image: /img/compatibility/bitstamp/rbf/send-screen.png - caption: > - Sending Transaction - Send transaction screen. No fee or RBF - options. Transaction not sent via RBF. - - image: /img/compatibility/bitstamp/rbf/transaction-list-sent.png - caption: > - Attempting Transaction Replacement - Transaction list screen with sent transaction. No bumping option since transaction was not RBF. - - image: /img/compatibility/bitstamp/rbf/transaction-list-incoming-rbf.png - caption: > - Receiving Transaction Signaling RBF - No transaction listed when original transaction broadcast. - - image: /img/compatibility/bitstamp/rbf/transaction-list-replacement-confirmed.png - caption: > - Receiving Replacement Transaction - Only saw a transaction after the - replacement transaction confirmed. Didn’t see original. -segwit: - tested: - date: "2021-01-27" - platforms: - - web - version: "n/a" - features: - receive: - p2sh_wrapped: "true" - bech32: "true" # https://www.bitstamp.net/article/weve-added-support-bech32-bitcoin-addresses-bitsta/ - default: "p2sh_wrapped_p2wsh" - send: - bech32: "true" # https://www.bitstamp.net/article/weve-added-support-bech32-bitcoin-addresses-bitsta/ - change_bech32: "untested" - segwit_v1: "Address text input doesn’t allow bech32 addresses due to - character limits." - bech32_p2wsh: "true" - examples: - - image: /img/compatibility/bitstamp/segwit/receive-screen.png - caption: > - Bitstamp receives deposits to P2SH-P2WSH addresses. diff --git a/_data/compatibility/blockchaininfo.yaml b/_data/compatibility/blockchaininfo.yaml deleted file mode 100644 index 28e6ffbf8e..0000000000 --- a/_data/compatibility/blockchaininfo.yaml +++ /dev/null @@ -1,64 +0,0 @@ ---- -name: Blockchain.info -internal_url: /en/compatibility/blockchaininfo -logo: /img/compatibility/blockchaininfo/blockchaininfo.png -rbf: - tested: - date: "2019-07-05" - platforms: - - web - version: "n/a" - features: - receive: - notification: "false" - list: "true" - details: "false" - shows_replaced_version: "true" - shows_original_version: "false" - send: - signals_bip125: "false" - list: "untested" - details: "untested" - shows_replaced_version: "untested" - shows_original_version: "untested" - examples: - - image: /img/compatibility/blockchaininfo/rbf/send-default-screen.png - caption: > - Sending Transaction - Default send transaction screen. No RBF option. - - image: /img/compatibility/blockchaininfo/rbf/send-screen-custom-fees.png - caption: > - Attempting Transaction Replacement - Sending transaction. Custom transaction - fee option expanded. No bump fee option available. - - image: /img/compatibility/blockchaininfo/rbf/transaction-list-sent.png - caption: > - Attempting Transaction Replacement - Sent transaction is shown. No option for RBF bumping. - - image: /img/compatibility/blockchaininfo/rbf/transaction-list-incoming-rbf.png - caption: > - Receiving Transaction Signaling RBF - Receiving RBF signaling transaction. RBF flag is shown. -segwit: - tested: - date: "2021-06-01" - platforms: - - web - version: "n/a" - features: - receive: - p2sh_wrapped: "false" - bech32: "true" - default: "bech32" # https://github.com/bitcoinops/bitcoinops.github.io/pull/510#issuecomment-859732513 - send: - bech32: "true" - change_bech32: "true" # https://github.com/bitcoinops/bitcoinops.github.io/pull/510#issuecomment-859732513 - segwit_v1: "Error occurs during sending process, after validation." - bech32_p2wsh: "true" - examples: - - image: /img/compatibility/blockchaininfo/segwit/receive-screen.png - caption: > - Blockchain only generates P2PKH addresses for receiving. - - image: /img/compatibility/blockchaininfo/segwit/send-screen.png - caption: > - Blockchain can send to bech32 addresses. - #- image: /img/compatibility/blockchaininfo/segwit/send-v1-error.png - # caption: > - # Blockchain initially allows to send to segwit v1 addresses but an error - # occurs after completing the send process. diff --git a/_data/compatibility/blocksettle.yaml b/_data/compatibility/blocksettle.yaml deleted file mode 100644 index 38979d9263..0000000000 --- a/_data/compatibility/blocksettle.yaml +++ /dev/null @@ -1,92 +0,0 @@ ---- -name: BlockSettle -internal_url: /en/compatibility/blocksettle -logo: /img/compatibility/blocksettle/blocksettle.png -rbf: - tested: - date: "2020-10-29" - platforms: - - Linux - version: "0.91.1" - features: - receive: - notification: "true" - list: "true" - details: "true" - shows_replaced_version: "true" - shows_original_version: "false" - send: - signals_bip125: "true" - list: "true" - details: "false" - shows_replaced_version: "true" - shows_original_version: "false" - examples: - - image: /img/compatibility/blocksettle/rbf/RBF_desktop_notification.png - caption: > - Desktop notification includes RBF signaling - - image: /img/compatibility/blocksettle/rbf/RBF_txdetail_signalling.png - caption: > - Transaction details includes RBF signaling - - image: /img/compatibility/blocksettle/rbf/RBF_txlist_signalling.png - caption: > - Transaction List includes RBF signaling - - image: /img/compatibility/blocksettle/rbf/RBF_txlist_replacement.png - caption: > - The transaction list displays the new incoming transaction, as well as the - new outgoing transaction - - image: /img/compatibility/blocksettle/rbf/RBF_txoverview.png - caption: > - The transaction overview includes RBF signaling - - image: /img/compatibility/blocksettle/rbf/RBF_txdetails_send.png - caption: > - The transactions details include RBF signaling - - image: /img/compatibility/blocksettle/rbf/RBF_default_check.png - caption: > - The create transaction dialog has RBF signaling enabled by default - - image: /img/compatibility/blocksettle/rbf/RBF_right_click.png - caption: > - The RBF function can be selected by right-clicking on an RBF eligible transaction - - image: /img/compatibility/blocksettle/rbf/RBF_default_outputs.png - caption: > - The RBF dialog pre-populates the existing output by default - - image: /img/compatibility/blocksettle/rbf/RBF_change_outputs.png - caption: > - The RBF dialog allows the user to replace/change/remove the output(s) - to create a new transaction -segwit: - tested: - date: "2020-10-29" - platforms: - - Linux - version: "0.91.1" - features: - receive: - p2sh_wrapped: "true" - bech32: "true" - default: "bech32" - send: - bech32: "true" - change_bech32: "true" - segwit_v1: "Error message during broadcasting of transaction" - bech32_p2wsh: "true" - examples: - - image: /img/compatibility/blocksettle/segwit/SegWit_wallet_overview.png - caption: > - The BlockSettle Terminal supports all address types. Users may hold/view/operate - multiple wallets and can select the address type they wish to generate. - The overview displays all wallets, address paths, and addresses. - - image: /img/compatibility/blocksettle/segwit/SegWit_default.png - caption: > - The BlockSettle Terminal defaults to native bech32 segwit when the user - generates an address. - - image: /img/compatibility/blocksettle/segwit/SegWit_generate.png - caption: > - The BlockSettle Terminal displays the generated native bech32 segwit address - - image: /img/compatibility/blocksettle/segwit/SegWit_send.png - caption: > - The BlockSettle terminal can send to native bech32 segwit addresses - - image: /img/compatibility/blocksettle/segwit/SegWit_change.png - caption: > - The change address defaults to native bech32 segwit addresses, however, - it is manually selectable by the user diff --git a/_data/compatibility/brd.yaml b/_data/compatibility/brd.yaml deleted file mode 100644 index be72b6571c..0000000000 --- a/_data/compatibility/brd.yaml +++ /dev/null @@ -1,89 +0,0 @@ ---- -name: BRD -internal_url: /en/compatibility/brd -logo: /img/compatibility/brd/brd.png -rbf: - tested: - date: "2018-10-10" - platforms: - - iOS - version: "3.3.2" - features: - receive: - notification: "false" - list: "false" - details: "false" - shows_replaced_version: "true" - shows_original_version: "true" - send: - signals_bip125: "false" - list: "untested" - details: "untested" - shows_replaced_version: "untested" - shows_original_version: "untested" - examples: - - image: /img/compatibility/brd/rbf/send-screen-default.png - caption: > - Sending Transaction - Transaction send default screen. No options for RBF here or in settings menus. - - image: /img/compatibility/brd/rbf/send-fee-options-expanded.png - caption: > - Sending Transaction - Transaction send screen with fee options expanded. No options for RBF. Toggle for fee priority. - - image: /img/compatibility/brd/rbf/send-transaction-confirmation.png - caption: > - Sending Transaction - Transaction send confirmation prompt. - - image: /img/compatibility/brd/rbf/transaction-details-sent.png - caption: > - Attempting Transaction Replacement - No ability to bump transaction fee found. Note Transaction not sent signaling RBF. - - image: /img/compatibility/brd/rbf/transaction-list-incoming-rbf.png - caption: > - Receiving Transaction Signaling RBF - No RBF flag on transaction list screen. - - image: /img/compatibility/brd/rbf/transaction-details-incoming-rbf.png - caption: > - Receiving Transaction Signaling RBF - No RBF flag on transaction details screen. - - image: /img/compatibility/brd/rbf/transaction-list-incoming-replacement.png - caption: > - Receiving Replacement Transaction - On transaction list screen, original transaction shows normal, replacement transaction shows with “Failed” message. - - image: /img/compatibility/brd/rbf/transaction-list-incoming-replacement-confirmed.png - caption: > - Receiving Transaction Signaling RBF - Transaction list screen no longer shows original transaction after the replacement transaction confirms. - - image: /img/compatibility/brd/rbf/transaction-details-incoming-replacement.png - caption: > - Receiving Transaction Signaling RBF - Transaction details of the - confirmed replacement transaction. No RBF flag or reference to original - transaction. -segwit: - tested: - date: "2019-07-23" - platforms: - - iOS - version: "3.14" - features: - receive: - p2sh_wrapped: "false" - bech32: "true" - default: "p2pkh" - send: - bech32: "true" - change_bech32: "true" - segwit_v1: "Allows sending workflow to complete in the UI. Transaction - stays as pending in the transaction list." - bech32_p2wsh: "true" - examples: - - image: /img/compatibility/brd/segwit/receive-screen.png - caption: > - BRD allows receiving to a bech32 address if you enable segwit in - settings. - - image: /img/compatibility/brd/segwit/send-screen.png - caption: > - BRD allows sending to bech32 addresses. - - image: /img/compatibility/brd/segwit/settings-enable-segwit.png - caption: > - BRD has a setting which allows bech32 receive addresses. - - image: /img/compatibility/brd/segwit/settings-enable-segwit-details.png - caption: > - BRD enable segwit details screen. - #- image: /img/compatibility/brd/segwit/sent-segwit-v1-details.png - # caption: > - # BRD allows sending to segwit v1 addresses in the UI. The transaction - # stays as pending in the transaction list. Eventually, the transaction - # disappears from the transaction list. \ No newline at end of file diff --git a/_data/compatibility/casa.yaml b/_data/compatibility/casa.yaml deleted file mode 100644 index 806b338932..0000000000 --- a/_data/compatibility/casa.yaml +++ /dev/null @@ -1,56 +0,0 @@ ---- -name: Casa -internal_url: /en/compatibility/casa -logo: /img/compatibility/casa/casa.png -rbf: - tested: - date: "2019-10-24" - platforms: - - iOS - version: "2.9.0" - features: - receive: - notification: "false" - list: "false" - details: "false" - shows_replaced_version: "false" - shows_original_version: "false" - send: - signals_bip125: "false" - list: "false" - details: "false" - shows_replaced_version: "false" - shows_original_version: "false" - examples: - - image: /img/compatibility/casa/rbf/approve-send-transaction.png - caption: > - Sending Transaction - Default send transaction screen. No RBF options. - - image: /img/compatibility/casa/rbf/transaction-list.png - caption: > - Receiving Replacement Transaction - Since no unconfirmed transaction - appears, neither original nor replacement show until the replacement - transactions confirms. -segwit: - tested: - date: "2019-10-24" - platforms: - - iOS - version: "2.9.0" - features: - receive: - p2sh_wrapped: "true" - bech32: "false" - default: "p2sh_wrapped_p2wsh" - send: - bech32: "true" - change_bech32: "false" - segwit_v1: "Fails on signing attempt." - bech32_p2wsh: "true" - examples: - - image: /img/compatibility/casa/segwit/receive-p2sh-wrapped-segwit.png - caption: > - Casa Keymaster defaults to P2SH-wrapped segwit addresses. - - image: /img/compatibility/casa/segwit/send-to-bech32.png - caption: > - Casa Keymaster allows sending to bech32 addresses. Change addresses - are not bech32 native, but P2SH-wrapped segwit addresses. diff --git a/_data/compatibility/cashapp.yaml b/_data/compatibility/cashapp.yaml deleted file mode 100644 index edad9eb27b..0000000000 --- a/_data/compatibility/cashapp.yaml +++ /dev/null @@ -1,72 +0,0 @@ ---- -name: Cash App -internal_url: /en/compatibility/cashapp -logo: /img/compatibility/cashapp/cashapp.png -rbf: - tested: - date: "2020-01-24" - platforms: - - iOS - version: "3.5.1" - features: - receive: - notification: "false" - list: "false" - details: "false" - shows_replaced_version: "false" - shows_original_version: "false" - send: - signals_bip125: "false" - list: "untested" - details: "untested" - shows_replaced_version: "untested" - shows_original_version: "untested" - examples: - - image: /img/compatibility/cashapp/rbf/send-screen-default.png - caption: > - Sending RBF Transaction - Default send transaction screen. - - image: /img/compatibility/cashapp/rbf/send-confirm.png - caption: > - Sending RBF Transaction - Send transaction confirmation screen. Transaction sent without RBF signaled. - - image: /img/compatibility/cashapp/rbf/transaction-details-sent.png - caption: > - Bumping RBF Transaction - Transaction details screen. Transaction not sent with RBF so no bumping possible. - - image: /img/compatibility/cashapp/rbf/transaction-list-sent.png - caption: > - Bumping RBF Transaction - Transaction list screen. Transaction not sent with RBF so no bumping possible. - - image: /img/compatibility/cashapp/rbf/incoming-notification.png - caption: > - Receiving RBF Transaction - Transaction email notification. No RBF notice - (email occurred after confirmation). - - image: /img/compatibility/cashapp/rbf/transaction-list-incoming.png - caption: > - Receiving RBF Transaction - Transaction list screen. Unconfirmed - incoming transactions are shown as 'Pending' unless the transaction - signals RBF in which case it only appears in the 'Completed' list after confirmation. - - image: /img/compatibility/cashapp/rbf/transaction-details-incoming.png - caption: > - Receiving RBF Transaction - Transaction details. No RBF notice. -segwit: - tested: - date: "2020-01-24" - platforms: - - iOS - version: "3.5.1" - features: - receive: - p2sh_wrapped: "true" - bech32: "false" - default: "p2sh_wrapped" - send: - bech32: "true" - change_bech32: "true" - segwit_v1: "untested" - bech32_p2wsh: "true" - examples: - - image: /img/compatibility/cashapp/segwit/receive-screen.png - caption: > - Cash App does not have an option for receiving to bech32. - Cash App uses p2sh wrapped segwit addresses for receiving. - - image: /img/compatibility/cashapp/segwit/send-screen.png - caption: > - Cash App allows sending to either wrapped or native segwit addresses. \ No newline at end of file diff --git a/_data/compatibility/coinbase.yaml b/_data/compatibility/coinbase.yaml deleted file mode 100644 index eb31ed3a4b..0000000000 --- a/_data/compatibility/coinbase.yaml +++ /dev/null @@ -1,84 +0,0 @@ ---- -name: Coinbase -internal_url: /en/compatibility/coinbase -logo: /img/compatibility/coinbase/coinbase.png -rbf: - tested: - date: "2018-11-05" - platforms: - - web - version: "n/a" - features: - receive: - notification: "false" - list: "false" - details: "false" - shows_replaced_version: "false" - shows_original_version: "true" - send: - signals_bip125: "false" - list: "untested" - details: "untested" - shows_replaced_version: "untested" - shows_original_version: "untested" - examples: - - image: /img/compatibility/coinbase/rbf/send-screen-default.png - caption: > - Sending RBF Transaction - Default send transaction screen. - - image: /img/compatibility/coinbase/rbf/send-confirm.png - caption: > - Sending RBF Transaction - Send transaction confirmation screen. Shows fees. No RBF flag. Transaction sent without RBF signaled. - - image: /img/compatibility/coinbase/rbf/transaction-details-sent.png - caption: > - Bumping RBF Transaction - Transaction not sent with RBF so no bumping possible. - - image: /img/compatibility/coinbase/rbf/transaction-details-sent-2.png - caption: > - Bumping RBF Transaction - After a period of time the View Transaction link shows up. - - image: /img/compatibility/coinbase/rbf/transaction-list-incoming-rbf.png - caption: > - Receiving RBF Transaction - Incoming RBF transaction list. No RBF label. - - image: /img/compatibility/coinbase/rbf/transaction-details-incoming-rbf.png - caption: > - Receiving RBF Transaction - Incoming RBF transaction details. No RBF label. Further transaction details are at BlockCypher explorer which does not label RBF transactions. - - image: /img/compatibility/coinbase/rbf/transaction-list-incoming-replacement.png - caption: > - Receiving Bumped RBF Transaction - After bumped transaction confirmed, the bumped transaction then shows up and is credited. Original transactions stay as pending (even after 100 confirmations). -segwit: - tested: - date: "2019-04-11" - platforms: - - web - version: "n/a" - features: - receive: - p2sh_wrapped: "true" - bech32: "false" - default: "p2sh_wrapped" - send: - bech32: "true" - change_bech32: "true" - segwit_v1: "Fails address validation client side in the UI." - bech32_p2wsh: "true" - examples: - - image: /img/compatibility/coinbase/segwit/receive-screen.png - caption: > - Coinbase does not have an explicit option for receiving to bech32. - Coinbase uses p2sh wrapped segwit addresses for receiving. - - image: /img/compatibility/coinbase/segwit/send-screen.png - caption: > - Coinbase allows sending to either wrapped or native segwit addresses. - There is also visual validation of the address format. - - image: /img/compatibility/coinbase/segwit/transaction-details-sent.png - caption: > - Transaction details screen shows the bech32 address. However, the link - for that address uses a block explorer (BlockCypher) which shows an - error as it does not support bech32 addresses. - - image: /img/compatibility/coinbase/segwit/change-address.png - caption: > - Coinbase uses bech32 for their change addresses, even when the send is - going to non bech32. - #- image: /img/compatibility/coinbase/segwit/send-segwit-v1.png - # caption: > - # Coinbase allows for sending to bech32 including P2WPKH and P2WSH for - # segwit v0. Coinbase detects segwit v1 addresses and displays a - # validation error. \ No newline at end of file diff --git a/_data/compatibility/conio.yaml b/_data/compatibility/conio.yaml deleted file mode 100644 index 34b12bb041..0000000000 --- a/_data/compatibility/conio.yaml +++ /dev/null @@ -1,87 +0,0 @@ ---- -name: Conio -internal_url: /en/compatibility/conio -logo: /img/compatibility/conio/conio.png -rbf: - tested: - date: "2018-10-31" - platforms: - - iOS - version: "2.5.6" - features: - receive: - notification: "false" - list: "false" - details: "false" - shows_replaced_version: "true" - shows_original_version: "true" - send: - signals_bip125: "true" - list: "false" - details: "false" - shows_replaced_version: "untested" - shows_original_version: "untested" - examples: - - image: /img/compatibility/conio/rbf/send-screen-default.png - caption: > - Sending RBF Transaction - Default send transaction screen. No RBF options. Transaction is sent with RBF signaled. - - image: /img/compatibility/conio/rbf/transaction-details-sent.png - caption: > - Bumping RBF Transaction - Transaction details screen for a sent and unconfirmed transaction. Cannot get Send Faster button enabled even when funds to bump are available. - - image: /img/compatibility/conio/rbf/notification-incoming-rbf.png - caption: > - Bumping RBF Transaction - Notice of incoming transaction. No RBF flag. - - image: /img/compatibility/conio/rbf/transaction-list-incoming-rbf.png - caption: > - Bumping RBF Transaction - Transaction list screen showing incoming RBF enabled transaction. No RBF flag. - - image: /img/compatibility/conio/rbf/transaction-details-incoming-rbf.png - caption: > - Bumping RBF Transaction - Transaction details of incoming transaction. No RBF signaled. "Receive Faster" for CPFP. - - image: /img/compatibility/conio/rbf/transaction-details-incoming-rbf-2.png - caption: > - Bumping RBF Transaction - More transaction details. - - image: /img/compatibility/conio/rbf/transaction-details-incoming-rbf-3.png - caption: > - Bumping RBF Transaction - More transaction details. After a period of time the Receive Faster button was now enabled. - - image: /img/compatibility/conio/rbf/transaction-details-incoming-rbf-receive-faster.png - caption: > - Bumping RBF Transaction - Transaction details showing Receive Faster options. - - image: /img/compatibility/conio/rbf/notification-replacement.png - caption: > - Receiving Bumped RBF Transaction - Receiving bumped transaction shows “Incoming” amount as the sum of the original and replacement transaction. - - image: /img/compatibility/conio/rbf/transaction-list-incoming-replacement.png - caption: > - Receiving Bumped RBF Transaction - Both original and replacement transaction show in transaction list screen. - - image: /img/compatibility/conio/rbf/transaction-list-replacement-confirmed.png - caption: > - Receiving Bumped RBF Transaction - After replacement transaction confirms, the original is removed from the list. - - image: /img/compatibility/conio/rbf/transaction-details-replacement.png - caption: > - Receiving Bumped RBF Transaction - Additional transaction details - available once transaction was confirmed. -segwit: - tested: - date: "2019-08-19" - platforms: - - iOS - version: "3.1.3" - features: - receive: - p2sh_wrapped: "true" - bech32: "false" - default: "p2sh_wrapped_p2wsh" - send: - bech32: "true" - change_bech32: "false" - segwit_v1: "Server error 500 while attemping to send." - bech32_p2wsh: "true" - examples: - - image: /img/compatibility/conio/segwit/receive-screen.png - caption: > - Coino only receives to P2SH-wrapped P2WSH addresses. - - image: /img/compatibility/conio/segwit/send-screen.png - caption: > - Conio allows sending to any segwit v0 bech32 address. - #- image: /img/compatibility/conio/segwit/send-screen.png - # caption: > - # Conio shows a server error when attempting to send to segwit v1 outputs. \ No newline at end of file diff --git a/_data/compatibility/copay.yaml b/_data/compatibility/copay.yaml deleted file mode 100644 index 3b961cf2ae..0000000000 --- a/_data/compatibility/copay.yaml +++ /dev/null @@ -1,74 +0,0 @@ ---- -name: Copay -internal_url: /en/compatibility/copay -logo: /img/compatibility/copay/copay.png -rbf: - tested: - date: "2018-10-02" - platforms: - - macOS - version: "4.7.0" - features: - receive: - notification: "false" - list: "false" - details: "false" - shows_replaced_version: "false" - shows_original_version: "false" - send: - signals_bip125: "false" - list: "untested" - details: "untested" - shows_replaced_version: "untested" - shows_original_version: "untested" - examples: - - image: /img/compatibility/copay/rbf/default-send-screen.png - caption: > - Sending RBF Transaction - Default send screen. No RBF options. - - image: /img/compatibility/copay/rbf/send-miner-fee-options.png - caption: > - Sending RBF Transaction - Miner fee detail options. - - image: /img/compatibility/copay/rbf/send-fee-level-options.png - caption: > - Sending RBF Transaction - Fee level dropdown options. - - image: /img/compatibility/copay/rbf/send-dialog-custom-fee-level.png - caption: > - Sending RBF Transaction - Dialog box for custom fee level. - - image: /img/compatibility/copay/rbf/transaction-list-sent.png - caption: > - Bumping RBF Enabled Transaction - Transactions list screen. - - image: /img/compatibility/copay/rbf/transaction-details-sent.png - caption: > - Bumping RBF Enabled Transaction - Transaction details of sent transaction. No bumping available. NOTE Transactions not sent with RBF signaled. - - image: /img/compatibility/copay/rbf/transaction-details-sent-warning.png - caption: > - Bumping RBF Enabled Transaction - Transactions details screen of sent transaction with “Amount too low to spend” warning message. Learn more link [goes here](https://support.bitpay.com/hc/en-us/articles/115004497783-What-does-the-BitPay-wallet-s-warning-amount-too-low-to-spend-mean-). Error message doesn’t make sense given a ~$7 transactions size. Note fee was 3 sat/byte. - - image: /img/compatibility/copay/rbf/transaction-list-incoming-rbf.png - caption: > - Receiving RBF Transaction - Transaction list does not show any unconfirmed transactions. - - image: /img/compatibility/copay/rbf/transaction-details-incoming-rbf.png - caption: > - Receiving RBF Transaction - Transaction details do not show that the transaction was RBF enabled. -segwit: - tested: - date: "2019-08-21" - platforms: - - iOS - version: "6.1.0" - features: - receive: - p2sh_wrapped: "false" - bech32: "false" - default: "p2pkh" - send: - bech32: "true" - change_bech32: "false" - segwit_v1: "Allows v1 address to be entered in the UI. Fails during broadcast." - bech32_p2wsh: "true" - examples: - - image: /img/compatibility/copay/segwit/receive-screen.png - caption: > - Copay generates only P2PKH addresses for receiving. - - image: /img/compatibility/copay/segwit/send-screen.png - caption: > - Copay can send to both P2WPKH and P2WSH bech32 addresses. \ No newline at end of file diff --git a/_data/compatibility/edge.yaml b/_data/compatibility/edge.yaml deleted file mode 100644 index 2ea72249fb..0000000000 --- a/_data/compatibility/edge.yaml +++ /dev/null @@ -1,83 +0,0 @@ ---- -name: Edge -internal_url: /en/compatibility/edge -logo: /img/compatibility/edge/edge.png -rbf: - tested: - date: "2018-10-17" - platforms: - - iOS - version: "1.3.4" - features: - receive: - notification: "false" - list: "false" - details: "false" - shows_replaced_version: "true" - shows_original_version: "true" - send: - signals_bip125: "false" - list: "untested" - details: "untested" - shows_replaced_version: "untested" - shows_original_version: "untested" - examples: - - image: /img/compatibility/edge/rbf/send-screen-default.png - caption: > - Sending RBF Transaction - Default Send screen. No option for RBF. - - image: /img/compatibility/edge/rbf/send-context-fees-menu.png - caption: > - Sending RBF Transaction - Context menu for send transaction show mining fee options. - - image: /img/compatibility/edge/rbf/send-change-mining-fee.png - caption: > - Sending RBF Transaction - Mining fee options dialog. - - image: /img/compatibility/edge/rbf/send-custom-mining-fee.png - caption: > - Sending RBF Transaction - Mining fee custom dialog. - - image: /img/compatibility/edge/rbf/transaction-details-sent.png - caption: > - Bumping RBF Enabled Transaction - Mining fee custom dialog. - - image: /img/compatibility/edge/rbf/transaction-details-incoming-rbf.png - caption: > - Receiving RBF Transaction - Receiving RBF enabled transaction. No RBF Flag. - - image: /img/compatibility/edge/rbf/transaction-details-incoming-rbf-advanced.png - caption: > - Receiving RBF Transaction - Transaction details for received RBF transaction. Links to blockchair.com explorer. - - image: /img/compatibility/edge/rbf/transaction-list-incoming-replacement.png - caption: > - Receiving Bumped RBF Transaction - Transaction list with top 2 transactions being the original and bumped RBF transaction. No RBF flag. Note that the balance only went up by the value of one of the transactions. -segwit: - tested: - date: "2019-07-23" - platforms: - - iOS - version: "1.8.3" - features: - receive: - p2sh_wrapped: "true" - bech32: "false" - default: "p2sh_wrapped" - send: - bech32: "true" - change_bech32: "false" - segwit_v1: "Allows sending workflow to complete. Transaction stays in - pending state. Appears to causes issues with the balance calculation as - well as ability to send subsequent transactions." - bech32_p2wsh: "true" - examples: - - image: /img/compatibility/edge/segwit/receive-screen.png - caption: > - Edge generates only - - image: /img/compatibility/edge/segwit/send-screen.png - caption: > - Edge allows sends to segwit v0 native bech32 addresses. - #- image: /img/compatibility/edge/segwit/transaction-list-segwit-v1-pending.png - # caption: > - # Balance is calculated incorrectly after segwit v1 transaction is "sent". - # Subsequent transactions out of the wallet do not seem to be broadcasted. - # Issue reported via GitHub. - - image: /img/compatibility/edge/segwit/wallet-creation-screen.png - caption: > - Edge allows the creation of "Segwit" and "no Segwit" wallets. The - "Segwit" wallets use P2SH-wrapped P2WPKH addresses. Both wallet types - can send to segwit v0 addresses. \ No newline at end of file diff --git a/_data/compatibility/electrum.yaml b/_data/compatibility/electrum.yaml deleted file mode 100644 index 2555192f91..0000000000 --- a/_data/compatibility/electrum.yaml +++ /dev/null @@ -1,115 +0,0 @@ ---- -name: Electrum -internal_url: /en/compatibility/electrum -logo: /img/compatibility/electrum/electrum.png -rbf: - tested: - date: "2018-08-28" - platforms: - - macOS - version: "3.2.2" - features: - receive: - notification: "false" - list: "true" - details: "false" - shows_replaced_version: "true" - shows_original_version: "false" - send: - signals_bip125: "true" - list: "true" - details: "false" - shows_replaced_version: "true" - shows_original_version: "false" - examples: - - image: /img/compatibility/electrum/rbf/default-wallet-send-screen.png - caption: > - Sending Transaction - Default Wallet Send Screen. - - image: /img/compatibility/electrum/rbf/preference-rbf-checkbox.png - caption: > - Sending Transaction - Preferences Pane with RBF checkbox. - - image: /img/compatibility/electrum/rbf/transaction-list-outgoing-rbf-transaction.png - caption: > - Sending Transaction - Transaction list screen for outgoing RBF signaling - transaction. RBF noted. - - image: /img/compatibility/electrum/rbf/transaction-details-outgoing-rbf-transaction.png - caption: > - Sending Transaction - Transaction details screen for outgoing RBF - signaling transaction. No note of RBF signaling. - - image: /img/compatibility/electrum/rbf/transaction-list-context-menu-increase-fee.png - caption: > - Attempting Transaction Replacement - Transaction List context menu for “Increase fee”. - - image: /img/compatibility/electrum/rbf/dialog-bumped-fee-input.png - caption: > - Attempting Transaction Replacement - Dialog for inputting replacement transaction fee. - - image: /img/compatibility/electrum/rbf/transaction-list-replacement-tx-only.png - caption: > - Attempting Transaction Replacement - Transaction list shows only one - unconfirmed transaction, the latest replacement transaction. RBF noted. - - image: /img/compatibility/electrum/rbf/transaction-details-replacement-tx.png - caption: > - Attempting Transaction Replacement - Transaction details of replacement transaction. No RBF noted. No note of original transaction. - - image: /img/compatibility/electrum/rbf/incoming-transaction-alert.png - caption: > - Receiving Transaction Signaling RBF - Notification of incoming transaction. No specific note that the transaction is RBF signaled. - - image: /img/compatibility/electrum/rbf/transaction-list-rbf-noted.png - caption: > - Receiving Transaction Signaling RBF - Transaction List Screen. Notes RBF - signaling as well as fee size. - - image: /img/compatibility/electrum/rbf/transaction-details-incoming.png - caption: > - Receiving Transaction Signaling RBF - Transaction Details screen for an - RBF signaling transaction. No RBF note. - - image: /img/compatibility/electrum/rbf/alert-incoming-replacement-tx.png - caption: > - Receiving Replacement Transaction - New transaction notification for the RBF replacement transaction. - - image: /img/compatibility/electrum/rbf/transaction-list-replacement-tx.png - caption: > - Receiving Replacement Transaction - Transaction List Screen. Notes - transaction signaling RBF as well as fee size. The replacement transaction does not - show up as a separate. The original transaction disappears. - - image: /img/compatibility/electrum/rbf/transaction-details-incoming-replacement.png - caption: > - Receiving Replacement Transaction - Transaction details of incoming - replacement transaction. RBF not noted. -segwit: - tested: - date: "2019-04-11" - platforms: - - macOS - version: "3.3.4" - features: - receive: - p2sh_wrapped: "true" - bech32: "true" - default: "bech32" - send: - bech32: "true" - change_bech32: "true" - segwit_v1: "Error message during broadcasting of transaction." - bech32_p2wsh: "true" - examples: - - image: /img/compatibility/electrum/segwit/create-wallet.png - caption: > - Electrum prompts users to choose a wallet type. Segwit or Legacy options - available with Segwit as the default option. - available. - - image: /img/compatibility/electrum/segwit/receive-screen.png - caption: > - Default receive screen when using a "Segwit" wallet uses bech32 native - addresses for receiving. - - image: /img/compatibility/electrum/segwit/create-wallet-p2sh-wrapped.png - caption: > - Electrum also [allows p2sh-wrapped segwit - addresses](https://bitcointalk.org/index.php?topic=3057784.msg31519322#msg31519322) - with a workaround. - - image: /img/compatibility/electrum/segwit/address-list.png - caption: > - Electrum uses the wallet type's address format for change addresses. - When using bech32/segwit wallet, the change addresses are bech32. - - image: /img/compatibility/electrum/segwit/send-screen.png - caption: > - Sending to bech32 addresses is possible from all Electrum wallet types. - #- image: /img/compatibility/electrum/segwit/send-segwit-v1-error.png - # caption: > - # Sending to segwit v1 addresses fails during broadcast of transaction. \ No newline at end of file diff --git a/_data/compatibility/greenaddress.yaml b/_data/compatibility/greenaddress.yaml deleted file mode 100644 index 05ee18919f..0000000000 --- a/_data/compatibility/greenaddress.yaml +++ /dev/null @@ -1,126 +0,0 @@ ---- -name: Green -internal_url: /en/compatibility/greenaddress -logo: /img/compatibility/greenaddress/greenaddress.png -rbf: - tested: - date: "2018-09-25" - platforms: - - iOS - version: "0.0.52" - features: - receive: - notification: "na" - list: "true" - details: "false" - shows_replaced_version: "true" - shows_original_version: "true" - send: - signals_bip125: "true" - list: "true" - details: "false" - shows_replaced_version: "true" - shows_original_version: "true" - examples: - - image: /img/compatibility/greenaddress/rbf/settings-transaction-replacement.png - caption: > - Sending Transaction - Sending with transaction replacement is “ON” under Settings by default. - - image: /img/compatibility/greenaddress/rbf/default-send-transaction-screen.png - caption: > - Sending Transaction - Default Send transaction screen. - - image: /img/compatibility/greenaddress/rbf/send-transaction-screen-advanced.png - caption: > - Sending Transaction - Advanced details on send transaction screen. - - image: /img/compatibility/greenaddress/rbf/transaction-send-confirmation-prompt.png - caption: > - Sending Transaction - Transaction send confirmation prompt. - - image: /img/compatibility/greenaddress/rbf/transaction-list-bump-fee.png - caption: > - Sending Transaction - Transaction list showing “bump fee” option for unconfirmed transaction. - - image: /img/compatibility/greenaddress/rbf/sent-transaction-details.png - caption: > - Sending Transaction - Transaction details. RBF replaceable not flagged. - - image: /img/compatibility/greenaddress/rbf/transaction-list-bump-fee-context-menu.png - caption: > - Attempting Transaction Replacement - Bump fee context menu options. - - image: /img/compatibility/greenaddress/rbf/replacement-transaction-details.png - caption: > - Attempting Transaction Replacement - Bump transaction details confirmation. Notes “Previous fee:” field as well as language about bumping. - - image: /img/compatibility/greenaddress/rbf/2fa-prompt.png - caption: > - Attempting Transaction Replacement - 2FA prompted for replacement transactions as well. - - image: /img/compatibility/greenaddress/rbf/transaction-list-replacement-tx.png - caption: > - Attempting Transaction Replacement - Transaction list with replacement transaction on top. Bump fee available again. Show replaced transaction button shows as well. - - image: /img/compatibility/greenaddress/rbf/transaction-list-show-replaced.png - caption: > - Attempting Transaction Replacement - Transaction list with replacement transactions “show replaced” button clicked. NOTE while testing, I inadvertently bumped twice so 2 replacement transactions appear here. - - image: /img/compatibility/greenaddress/rbf/transaction-details-original-tx.png - caption: > - Attempting Transaction Replacement - Original transaction as viewed from the “show replaced” list. “Double spend by txhash” field has “update” value. - - image: /img/compatibility/greenaddress/rbf/transaction-details-replacement-tx.png - caption: > - Attempting Transaction Replacement - Replacement “bumped” transaction. “Double spend by txhash” field has “update” value. - - image: /img/compatibility/greenaddress/rbf/transaction-list-subsequent-replacement-fees.png - caption: > - Attempting Transaction Replacement - Subsequent bumping on the same transaction has a different “bump fee” context menu options. Also the context menu notes “fee already at 1-conf-estimate level”. - - image: /img/compatibility/greenaddress/rbf/transaction-list-rbf-incoming.png - caption: > - Receiving Transaction Signaling RBF - Transaction List Screen. “Replaceable” noted. - - image: /img/compatibility/greenaddress/rbf/transaction-details-rbf-incoming-1.png - caption: > - Receiving Transaction Signaling RBF - Transaction details do not flag RBF (or unconfirmed). - - image: /img/compatibility/greenaddress/rbf/transaction-details-rbf-incoming-2.png - caption: > - Receiving Transaction Signaling RBF - Transaction details do not flag RBF (or unconfirmed). - - image: /img/compatibility/greenaddress/rbf/transaction-list-incoming-replacement-tx.png - caption: > - Receiving Replacement Transaction - Transaction List Screen. Notes RBF(“replaceable”) transaction as well as double spend transaction. The replacement transaction also shows up as separate. - - image: /img/compatibility/greenaddress/rbf/transaction-details-incoming-replacement-tx-1.png - caption: > - Receiving Replacement Transaction - Transaction details for replacement transaction. No RBF note or double spend note. Does show “double spend by txhash” field which points to original transaction. - - image: /img/compatibility/greenaddress/rbf/transaction-details-incoming-replacement-tx-2.png - caption: > - Receiving Replacement Transaction - Transaction details for replacement transaction. No RBF note or double spend note. Does show “double spend by txhash” field which points to original transaction. - - image: /img/compatibility/greenaddress/rbf/transaction-details-incoming-original-tx-1.png - caption: > - Receiving Replacement Transaction - Transaction details for original - transaction. No RBF note or double spend note. Does show “double spend - by txhash” field which points to new replacement transaction. - - image: /img/compatibility/greenaddress/rbf/transaction-details-incoming-original-tx-2.png - caption: > - Receiving Replacement Transaction - Transaction details for original - transaction. No RBF note or double spend note. Does show “double spend - by txhash” field which points to new replacement transaction. - - image: /img/compatibility/greenaddress/rbf/transaction-list-replacement-confirmed.png - caption: > - Receiving Replacement Transaction - Transaction list after the replacement transaction confirms. “Original” transaction doesn’t appear. - - image: /img/compatibility/greenaddress/rbf/transaction-details-bumped-confirmed-tx.png - caption: > - Receiving Replacement Transaction - Transaction details for confirmed, replacement transaction. No note of double spend or RBF. “double spend by txhash” field disappears. -segwit: - tested: - date: "2019-07-24" - platforms: - - iOS - version: "3.1.8" - features: - receive: - p2sh_wrapped: "true" - bech32: "false" - default: "p2sh_wrapped" - send: - bech32: "true" - change_bech32: "false" - segwit_v1: "Fails on validation of the address." - bech32_p2wsh: "true" - examples: - - image: /img/compatibility/greenaddress/segwit/receive-screen.png - caption: > - Green generates only P2SH wrapped segwit addresses. - - image: /img/compatibility/greenaddress/segwit/send-screen.png - caption: > - Green can send to all variants of bech32 addresses for v0. - #- image: /img/compatibility/greenaddress/segwit/send-screen-segwit-v1-error.png - # caption: > - # Green displays a validation error when trying to send to a segwit v1 address. \ No newline at end of file diff --git a/_data/compatibility/jaxx.yaml b/_data/compatibility/jaxx.yaml deleted file mode 100644 index b8de91b1f6..0000000000 --- a/_data/compatibility/jaxx.yaml +++ /dev/null @@ -1,57 +0,0 @@ ---- -name: Jaxx -internal_url: /en/compatibility/jaxx -logo: /img/compatibility/jaxx/jaxx.png -rbf: - tested: - date: "2018-11-07" - platforms: - - iOS - version: "2.0.5" - features: - receive: - notification: "na" - list: "false" - details: "false" - shows_replaced_version: "true" - shows_original_version: "false" - send: - signals_bip125: "false" - list: "untested" - details: "untested" - shows_replaced_version: "untested" - shows_original_version: "untested" - examples: - - image: /img/compatibility/jaxx/rbf/transaction-list-incoming-rbf.png - caption: > - Receiving Transaction Signaling RBF - Transaction list showing incoming transaction. RBF not noted. - - image: /img/compatibility/jaxx/rbf/transaction-list-incoming-replacement.png - caption: > - Receiving Replacement Transaction - Replacement transaction shown, original disappears. -segwit: - tested: - date: "2019-07-24" - platforms: - - iOS - version: "2.2.2" - features: - receive: - p2sh_wrapped: "false" - bech32: "false" - default: "p2pkh" - send: - bech32: "false" - change_bech32: "false" - segwit_v1: "Fails on validation of the address." - bech32_p2wsh: "false" - examples: - - image: /img/compatibility/jaxx/segwit/receive-screen.png - caption: > - Jaxx generates only legacy P2PKH receive addresses. - - image: /img/compatibility/jaxx/segwit/send-screen.png - caption: > - Jaxx cannot send to any bech32 addresses. - #- image: /img/compatibility/jaxx/segwit/send-screen-segwit-v1-error.png - # caption: > - # Jaxx displays a validation error when trying to send to a segwit v1 - # address (or any other bech32 address). \ No newline at end of file diff --git a/_data/compatibility/kraken.yaml b/_data/compatibility/kraken.yaml deleted file mode 100644 index 520680c519..0000000000 --- a/_data/compatibility/kraken.yaml +++ /dev/null @@ -1,58 +0,0 @@ ---- -name: Kraken -internal_url: /en/compatibility/kraken -logo: /img/compatibility/kraken/kraken.png -rbf: - tested: - date: "2020-02-21" - platforms: - - web - version: "n/a" - features: - receive: - notification: "false" - list: "false" - details: "false" - shows_replaced_version: "false" - shows_original_version: "false" - send: - signals_bip125: "false" - list: "untested" - details: "untested" - shows_replaced_version: "untested" - shows_original_version: "untested" - examples: - - image: /img/compatibility/kraken/rbf/send-confirm.png - caption: > - Sending Transaction - Send confirmation screen. No RBF options. - Transactions are not sent signaling RBF. - - image: /img/compatibility/kraken/rbf/transaction-list.png - caption: > - Receiving Transaction Signaling RBF - No unconfirmed transactions appear - in transaction list. No RBF note. -segwit: - tested: - date: "2020-02-21" - platforms: - - web - version: "n/a" - features: - receive: - p2sh_wrapped: "true" - bech32: "false" - default: "p2sh_wrapped_p2wsh" - send: - bech32: "true" - change_bech32: "false" - segwit_v1: "" - bech32_p2wsh: "true" - examples: - - image: /img/compatibility/kraken/segwit/receive-screen.png - caption: > - Kraken receives deposits to P2SH-P2WSH addresses. - - image: /img/compatibility/kraken/segwit/create-address.png - caption: > - Kraken can send to all variants of bech32 addresses for v0. - - image: /img/compatibility/kraken/segwit/send-screen.png - caption: > - Default send screen. \ No newline at end of file diff --git a/_data/compatibility/ledger-live.yaml b/_data/compatibility/ledger-live.yaml deleted file mode 100644 index ec6db90c66..0000000000 --- a/_data/compatibility/ledger-live.yaml +++ /dev/null @@ -1,72 +0,0 @@ ---- -name: Ledger Live -internal_url: /en/compatibility/ledger-live -logo: /img/compatibility/ledger-live/ledger-live.png -rbf: - tested: - date: "2018-10-11" - platforms: - - macOS - version: "1.2.0" - features: - receive: - notification: "false" - list: "false" - details: "false" - shows_replaced_version: "false" - shows_original_version: "true" - send: - signals_bip125: "false" - list: "untested" - details: "untested" - shows_replaced_version: "untested" - shows_original_version: "untested" - examples: - - image: /img/compatibility/ledger-live/rbf/send-screen.png - caption: > - Sending Transaction - Send transaction screen does not allow for RBF. Fee options are available. No RBF options in settings. - - image: /img/compatibility/ledger-live/rbf/transaction-details-sent.png - caption: > - Attempting Transaction Replacement - Transaction details screen. No RBF fee bumping supported. - - image: /img/compatibility/ledger-live/rbf/transaction-list-incoming-rbf.png - caption: > - Receiving Transaction Signaling RBF - Transaction list screen. No RBF flag. - - image: /img/compatibility/ledger-live/rbf/transaction-details-incoming-rbf.png - caption: > - Receiving Transaction Signaling RBF - Transaction details screen. No RBF flag. - - image: /img/compatibility/ledger-live/rbf/transaction-list-incoming-replacement.png - caption: > - Receiving Replacement Transaction - Transaction list screen does not show the replacement transaction. Only the original. Even after the new, replacement transaction received 6+ confirmations. - - image: /img/compatibility/ledger-live/rbf/error-screen.png - caption: > - Receiving Transaction Signaling RBF - Internal database error shows conflicting - bitcoin inputs. Original transaction remains unconfirmed. Ticket opened - with Ledger to address. Update - Solution was to clear cache in app. -segwit: - tested: - date: "2019-07-24" - platforms: - - macOS - version: "1.12.0" - features: - receive: - p2sh_wrapped: "true" - bech32: "true" - default: "bech32" - send: - bech32: "true" - change_bech32: "true" - segwit_v1: "Fails when transaction is sent to the hardwave device for signing." - bech32_p2wsh: "true" - examples: - - image: /img/compatibility/ledger-live/segwit/receive-screen.png - caption: > - Ledger Live can generate bech32 native addresses. Note this depends on - how your wallet was initial created. Bech32 support is new in Ledger Live. - - image: /img/compatibility/ledger-live/segwit/send-screen.png - caption: > - Ledger Live can send to all variants of bech32 addresses for v0. - #- image: /img/compatibility/ledger-live/segwit/send-screen-segwit-v1-error.png - # caption: > - # Ledger Live displays an error during hardware device signing when trying - # to send to a segwit v1 address. \ No newline at end of file diff --git a/_data/compatibility/mycelium.yaml b/_data/compatibility/mycelium.yaml deleted file mode 100644 index 7612a97b70..0000000000 --- a/_data/compatibility/mycelium.yaml +++ /dev/null @@ -1,66 +0,0 @@ ---- -name: Mycelium -internal_url: /en/compatibility/mycelium -logo: /img/compatibility/mycelium/mycelium.png -rbf: - tested: - date: "2018-10-30" - platforms: - - iOS - version: "1.11" - features: - receive: - notification: "na" - list: "false" - details: "false" - shows_replaced_version: "false" - shows_original_version: "false" - send: - signals_bip125: "false" - list: "untested" - details: "untested" - shows_replaced_version: "untested" - shows_original_version: "untested" - examples: - - image: /img/compatibility/mycelium/rbf/send-screen-default.png - caption: > - Sending Transaction - Default send transaction screen. No options for RBF while sending or in app settings. - - image: /img/compatibility/mycelium/rbf/send-miner-fee-options.png - caption: > - Sending Transaction - Send transaction miner fee details. No RBF options. - - image: /img/compatibility/mycelium/rbf/transaction-list-sent.png - caption: > - Attempting Transaction Replacement - Transaction list. No option to bump since transaction sent without RBF. - - image: /img/compatibility/mycelium/rbf/transaction-details-sent.png - caption: > - Attempting Transaction Replacement - Sent transaction details. No sign RBF/not or bumping. - - image: /img/compatibility/mycelium/rbf/transaction-list-incoming-rbf.png - caption: > - Receiving Transaction Signaling RBF - When receiving RBF, or any transaction, no unconfirmed transactions show. -segwit: - tested: - date: "2021-06-22" - platforms: - - Android - version: "3.10.0.1" - features: - receive: - p2sh_wrapped: "true" - bech32: "true" # https://github.com/mycelium-com/wallet-android/issues/425#issuecomment-440792004 - default: "p2sh_wrapped" - send: - bech32: "true" # https://github.com/mycelium-com/wallet-android/issues/425#issuecomment-440792004 - change_bech32: "true" - segwit_v1: "Fails during address validation." - bech32_p2wsh: "true" - examples: - - image: /img/compatibility/mycelium/segwit/receive-screen.png - caption: > - Mycelium generates P2PKH, P2SH-P2WPKH, and P2WPKH receive addresses. - - image: /img/compatibility/mycelium/segwit/send-screen.png - caption: > - Mycelium can send to any bech32 addresses. - #- image: /img/compatibility/mycelium/segwit/send-screen-segwit-v1-error.png - # caption: > - # Mycelium displays a validation error when trying to send to a segwit v1 - # address (or any other bech32 address). diff --git a/_data/compatibility/opendime.yaml b/_data/compatibility/opendime.yaml deleted file mode 100644 index bb3e82c6a1..0000000000 --- a/_data/compatibility/opendime.yaml +++ /dev/null @@ -1,59 +0,0 @@ ---- -name: Opendime -internal_url: /en/compatibility/opendime -logo: /img/compatibility/opendime/opendime.png -rbf: - tested: - date: "2018-10-18" - platforms: - - macOS - version: "2.1.0" - features: - receive: - notification: "na" - list: "false" - details: "na" - shows_replaced_version: "true" - shows_original_version: "false" - send: - signals_bip125: "false" - list: "untested" - details: "untested" - shows_replaced_version: "untested" - shows_original_version: "untested" - examples: - - image: /img/compatibility/opendime/rbf/sending-instructions.png - caption: > - Sending Transaction - Opendime does not have traditional wallet - capabilities. You can either sweep the private key to use in a regular - wallet or use the balance.py script to send all funds to an address. - - image: /img/compatibility/opendime/rbf/sending-script.png - caption: > - Sending Transaction - There is a balance.py python script which can send a transaction using pycoin but does not specify RBF when creating a transaction. - - image: /img/compatibility/opendime/rbf/transaction-list-incoming-rbf.png - caption: > - Receiving Transaction Signaling RBF - Opendime uses a simple address explorer on opendime.com. No RBF Flag. OPENDIME’s simple transaction list explorer does not provide RBF flag notice. However there are links to other explorers on the page (Blockchain.info, Blocktrail, LocalBitcoins, BitInfoCharts, a BIP122 link). - - image: /img/compatibility/opendime/rbf/transaction-list-incoming-replacement.png - caption: > - Receiving Replacement Transaction - Transaction list screen when a transaction has been replaced. Bottom transaction is the replacement transaction. Original transaction does not show up in list anymore. -segwit: - tested: - date: "2019-07-24" - platforms: - - macOS - version: "2.2.0" - features: - receive: - p2sh_wrapped: "false" - bech32: "false" - default: "p2pkh" - send: - bech32: "true" - change_bech32: "na" - segwit_v1: "Untested." - bech32_p2wsh: "true" - examples: - - image: /img/compatibility/opendime/segwit/receive-screen.png - caption: > - Opendime has a single P2PKH receive address. It can send to bech32 - addresses using the included balance.py script. \ No newline at end of file diff --git a/_data/compatibility/purse.yaml b/_data/compatibility/purse.yaml deleted file mode 100644 index 60bdcd855a..0000000000 --- a/_data/compatibility/purse.yaml +++ /dev/null @@ -1,58 +0,0 @@ ---- -name: Purse -internal_url: /en/compatibility/purse -logo: /img/compatibility/purse/purse.png -rbf: - tested: - date: "2019-12-17" - platforms: - - web - version: "n/a" - features: - receive: - notification: "false" - list: "false" - details: "false" - shows_replaced_version: "false" - shows_original_version: "false" - send: - signals_bip125: "false" - list: "untested" - details: "untested" - shows_replaced_version: "untested" - shows_original_version: "untested" - examples: - - image: /img/compatibility/purse/rbf/transaction-list.png - caption: > - Receiving Transaction Signaling RBF - No unconfirmed transactions appear in transaction list. -segwit: - tested: - date: "2019-12-17" - platforms: - - web - version: "n/a" - features: - receive: - p2sh_wrapped: "true" - bech32: "true" - default: "bech32" - send: - bech32: "true" - change_bech32: "true" - segwit_v1: "Transaction can be created and broadcast, relayed by peers - compatible with Bitcoin Core v0.19.0.1 or above." - bech32_p2wsh: "true" - examples: - - image: /img/compatibility/purse/segwit/receive-screen-p2wpkh.png - caption: > - Purse deposit addresses are bech32 P2WPKH (native segwit) by default. - - image: /img/compatibility/purse/segwit/receive-screen-nested.png - caption: > - As an option for users with legacy wallets, Purse also accepts deposits - to P2SH-wrapped P2WPKH (nested segwit) addresses. - - image: /img/compatibility/purse/segwit/send-screen.png - caption: > - Purse allows withdraws to both legacy and segwit addresses. - #- image: /img/compatibility/purse/segwit/send-v1.png - # caption: > - # Purse can send to a segwit address of any witness program version. diff --git a/_data/compatibility/river-financial.yaml b/_data/compatibility/river-financial.yaml deleted file mode 100644 index 0927e202d2..0000000000 --- a/_data/compatibility/river-financial.yaml +++ /dev/null @@ -1,57 +0,0 @@ ---- -name: River Financial -internal_url: /en/compatibility/river-financial -logo: /img/compatibility/river-financial/river-financial.png -rbf: - tested: - date: "2020-01-23" - platforms: - - web - version: "n/a" - features: - receive: - notification: "false" - list: "false" - details: "false" - shows_replaced_version: "true" - shows_original_version: "false" - send: - signals_bip125: "true" - list: "untested" - details: "untested" - shows_replaced_version: "untested" - shows_original_version: "untested" - examples: - - image: /img/compatibility/river-financial/rbf/rbf_onchain_deposit.png - caption: > - When a transaction enters River's mempool or is included in a block, River sends a notification to the user about the new deposit. There is currently no RBF notice. - - image: /img/compatibility/river-financial/rbf/rbf_new_onchain_deposit.png - caption: > - The original transaction that gets bumped with RBF will not be listed and is replaced with the new transaction. - - image: /img/compatibility/river-financial/rbf/rbf_dashboard.png - caption: > - When viewing transaction history, only the new replaced transaction is shown. -segwit: - tested: - date: "2020-01-12" - platforms: - - web - version: "n/a" - features: - receive: - p2sh_wrapped: "true" - bech32: "true" - default: "bech32_p2wsh" - send: - bech32: "true" - change_bech32: "true" - segwit_v1: "Transaction can be created and broadcast, relayed by peers - compatible with Bitcoin Core v0.19.0.1 or above." - bech32_p2wsh: "true" - examples: - - image: /img/compatibility/river-financial/segwit/deposit_onchain.png - caption: > - River deposit addresses are bech32 P2WSH (native segwit) by default. - - image: /img/compatibility/river-financial/segwit/withdraw_onchain.png - caption: > - River supports withdrawals to legacy and segwit addresses. \ No newline at end of file diff --git a/_data/compatibility/samourai.yaml b/_data/compatibility/samourai.yaml deleted file mode 100644 index 2ec64eee3d..0000000000 --- a/_data/compatibility/samourai.yaml +++ /dev/null @@ -1,99 +0,0 @@ ---- -name: Samourai -internal_url: /en/compatibility/samourai -logo: /img/compatibility/samourai/samourai.png -rbf: - tested: - date: "2018-10-25" - platforms: - - Android - version: "0.81" - features: - receive: - notification: "false" - list: "false" - details: "na" - shows_replaced_version: "true" - shows_original_version: "true" - send: - signals_bip125: "true" - list: "false" - details: "na" - shows_replaced_version: "true" - shows_original_version: "false" - examples: - - image: /img/compatibility/samourai/rbf/settings-rbf.png - caption: > - Sending Transaction - Settings for sending RBF enabled transactions. RBF disabled by default. - - image: /img/compatibility/samourai/rbf/send-screen-default.png - caption: > - Sending Transaction - Default send transaction screen. No RBF options. - - image: /img/compatibility/samourai/rbf/send-stonewall-prompt.png - caption: > - Sending Transaction - Prompt during send transaction for “STONEWALL” feature. - - image: /img/compatibility/samourai/rbf/transaction-list-sent.png - caption: > - Sending Transaction - Sent RBF enabled transaction. No RBF flag. - - image: /img/compatibility/samourai/rbf/transaction-details-sent.png - caption: > - Attempting Transaction Replacement - Transaction details for RBF enabled transaction with Increase TX Fee option. Interesting note here - If there are no additional funds to pay for the bump, Samourai just fails silently here with no message and takes the user back to the transaction list screen. - - image: /img/compatibility/samourai/rbf/sent-transaction-increase-fee.png - caption: > - Sending Transaction - Prompt when “increase tx fee” is chosen. Miner fee not customizable. - - image: /img/compatibility/samourai/rbf/transaction-list-sent-replaced.png - caption: > - Sending Transaction - Send RBF replacement transaction replaces original RBF enabled transaction. No flag. Confirmation message does say “RBF transaction sent”. - - image: /img/compatibility/samourai/rbf/transaction-list-incoming-rbf.png - caption: > - Receiving Transaction Signaling RBF - Transaction list screen for receiving RBF enabled transaction. No RBF flag. - - image: /img/compatibility/samourai/rbf/transaction-details-incoming-rbf.png - caption: > - Receiving Transaction Signaling RBF - Transaction details prompt for received transaction. “View transaction” defaults to Smartbit explorer (explorer configurable in settings). - - image: /img/compatibility/samourai/rbf/transaction-details-incoming-rbf-increase-fee.png - caption: > - Receiving Transaction Signaling RBF - Transaction details “Increase transaction - fee” dialog which uses CPFP behind the scenes to increase the effective - transaction feerate on the incoming transaction. - - image: /img/compatibility/samourai/rbf/transaction-list-incoming-replacement.png - caption: > - Receiving Replacement Transaction - Transaction list screen showing both original and replacement transactions. Total reflecting sum of both transactions. No RBF flag or warnings. - - image: /img/compatibility/samourai/rbf/transaction-list-replacement-confirmed.png - caption: > - Receiving Replacement Transaction - Transaction list screen updated to just show replacement transaction after a period of time. Even before either RBF signaling transaction was confirmed. -segwit: - tested: - date: "2019-07-25" - platforms: - - Android - version: "0.99.82" - features: - receive: - p2sh_wrapped: "true" - bech32: "true" - default: "bech32" - send: - bech32: "true" - change_bech32: "true" - segwit_v1: "Fails on broadcast of transaction to the network." - bech32_p2wsh: "true" - examples: - - image: /img/compatibility/samourai/segwit/receive-screen.png - caption: > - By default, Samourai generates bech32 receive addresses. - - image: /img/compatibility/samourai/segwit/send-screen.png - caption: > - Samourai can send to all segwit v0 addresses. - - image: /img/compatibility/samourai/segwit/receive-screen-advanced.png - caption: > - Samourai allows the user to choose the type of their receive address. - #- image: /img/compatibility/samourai/segwit/send-screen-segwit-v1-error.png - # caption: > - # Samourai wallet shows an error during broadcasting when trying to send - # to a segwit v1 address. - - image: /img/compatibility/samourai/segwit/settings-transactions.png - caption: > - Samourai has setting options for 1. receive to segwit address and 2. - receive change to like-typed outputs. Both of which are on by default. - - image: /img/compatibility/samourai/segwit/settings-wallet.png - caption: > - Samourai has options to view the wallet's X/Y/ZPUBs. \ No newline at end of file diff --git a/_data/compatibility/trezor.yaml b/_data/compatibility/trezor.yaml deleted file mode 100644 index b8ce59cb97..0000000000 --- a/_data/compatibility/trezor.yaml +++ /dev/null @@ -1,68 +0,0 @@ ---- -name: Trezor Suite -internal_url: /en/compatibility/trezor -logo: /img/compatibility/trezor/trezor.png -rbf: - tested: - date: "2021-04-13" - platforms: - - macOS - version: "21.4.1" - features: - receive: - notification: "na" - list: "true" - details: "true" - shows_replaced_version: "true" - shows_original_version: "false" - send: - signals_bip125: "true" - list: "true" - details: "true" - shows_replaced_version: "true" - shows_original_version: "false" - examples: - - image: /img/compatibility/trezor/rbf/send-screen.png - caption: > - Sending Transaction - Send transaction screen. Fee options. RBF options. By default, transaction sent as RBF. - - image: /img/compatibility/trezor/rbf/transaction-list-sent.png - caption: > - Attempting Transaction Replacement - Transaction list screen showing sent transaction. No bumping options. - - image: /img/compatibility/trezor/rbf/transaction-list-incoming-rbf.png - caption: > - Receiving Transaction Signaling RBF - Incoming transaction list. No RBF flag. - - image: /img/compatibility/trezor/rbf/transaction-details-incoming-rbf.png - caption: > - Receiving Transaction Signaling RBF - Trezor Suite's block explorer for incoming RBF - transaction. Does not note that the transaction has signaled RBF. - - image: /img/compatibility/trezor/rbf/transaction-list-incoming-replacement.png - caption: > - Receiving Replacement Transaction - replacement transaction replaces original transaction. Block explorer no longer finds original transaction. -segwit: - tested: - date: "2021-04-13" - platforms: - - macOS - version: "21.4.1" - features: - receive: - p2sh_wrapped: "true" - bech32: "true" - default: "bech32" - send: - bech32: "true" - change_bech32: "true" - segwit_v1: "Fails on validation of the address." - bech32_p2wsh: "true" - examples: - - image: /img/compatibility/trezor/segwit/receive-screen.png - caption: > - By default, Trezor generates a bech32 native P2WPKH receive addresses. - There is also an option to generate a legacy P2SH-wrapped-P2WPKH and P2PKH addresses. - - image: /img/compatibility/trezor/segwit/send-screen.png - caption: > - Trezor Suite allows for sending to any bech32 segwit v0 address. - #- image: /img/compatibility/trezor/segwit/send-screen-segwit-v1-error.png - # caption: > - # Trezor Suite displays a validation error when attempting to send to a segwit - # v1 address. diff --git a/_data/compatibility/wasabi.yaml b/_data/compatibility/wasabi.yaml deleted file mode 100644 index 6078a845a4..0000000000 --- a/_data/compatibility/wasabi.yaml +++ /dev/null @@ -1,76 +0,0 @@ ---- -name: Wasabi -internal_url: /en/compatibility/wasabi -logo: /img/compatibility/wasabi/wasabi.png -rbf: - tested: - date: "2019-12-19" - platforms: - - macOS - version: "1.1.10" - features: - receive: - notification: "true" - list: "false" - details: "false" - shows_replaced_version: "true" - shows_original_version: "false" - send: - signals_bip125: "false" - list: "false" - details: "false" - shows_replaced_version: "true" - shows_original_version: "false" - examples: - - image: /img/compatibility/wasabi/rbf/send-screen.png - caption: > - Sending Transaction - Send transaction screen. No RBF options. Wasabi - does signal for RBF randomly for 2% of transactions. - - image: /img/compatibility/wasabi/rbf/transaction-list-sent.png - caption: > - Attempting Transaction Replacement - Transaction list screen showing - sent transaction. No RBF bump options. Transaction not sent signaling - RBF. While Wasabi does not support manual sending RBF signaling transactions, - if a transaction replacement is done using the same seed in a different - wallet, Wasabi shows only the replacement transaction in the transaction - list. - - image: /img/compatibility/wasabi/rbf/transaction-list-incoming-rbf.png - caption: > - Receiving Transaction Signaling RBF - Incoming RBF signaling - transaction. No RBF flag. - - image: /img/compatibility/wasabi/rbf/notification-incoming-rbf.png - caption: > - Receiving Transaction Signaling RBF - Incoming RBF signaling - transaction notification notes that a transaction is replaceable. Wasabi - also displays whether the transaction was a replacement transaction. - - image: /img/compatibility/wasabi/rbf/transaction-list-incoming-replacement.png - caption: > - Receiving Replacement Transaction - Replacement transaction replaces - original transaction after transaction fee bump. No RBF indicator. -segwit: - tested: - date: "2019-12-19" - platforms: - - macOS - version: "1.1.10" - features: - receive: - p2sh_wrapped: "false" - bech32: "true" - default: "bech32" - send: - bech32: "true" - change_bech32: "true" - segwit_v1: "Fails on validation of the address." - bech32_p2wsh: "true" - examples: - - image: /img/compatibility/wasabi/segwit/receive-screen.png - caption: > - Wasabi only generates bech32 receive addresses. - - image: /img/compatibility/wasabi/segwit/send-screen.png - caption: > - Wasabi allows sending to any segwit v0 address. - #- image: /img/compatibility/wasabi/segwit/send-screen-segwit-v1-error.png - # caption: > - # Wasabi displays a validation error when attempting to send to a segwit - # v1 address. diff --git a/_data/compatibility/xapo.yaml b/_data/compatibility/xapo.yaml deleted file mode 100644 index 328e557320..0000000000 --- a/_data/compatibility/xapo.yaml +++ /dev/null @@ -1,82 +0,0 @@ ---- -name: Xapo -internal_url: /en/compatibility/xapo -logo: /img/compatibility/xapo/xapo.png -rbf: - tested: - date: "2018-11-05" - platforms: - - iOS - version: "4.6.1" - features: - receive: - notification: "false" - list: "false" - details: "false" - shows_replaced_version: "true" - shows_original_version: "true" - send: - signals_bip125: "false" - list: "untested" - details: "untested" - shows_replaced_version: "untested" - shows_original_version: "untested" - examples: - - image: /img/compatibility/xapo/rbf/send-screen.png - caption: > - Sending Transaction - Default wallet send screen - - image: /img/compatibility/xapo/rbf/send-miner-fee-options.png - caption: > - Sending Transaction - Send transaction, choose miner fees. No RBF options. - - image: /img/compatibility/xapo/rbf/tranasction-details-sent.png - caption: > - Attempting Transaction Replacement - Transaction not sent with RBF signaled. No bumping possible. - - image: /img/compatibility/xapo/rbf/notification-incoming-rbf.png - caption: > - Receiving Transaction Signaling RBF - Email notification. No RBF warning. - - image: /img/compatibility/xapo/rbf/transaction-list-incoming-rbf.png - caption: > - Receiving Transaction Signaling RBF - Incoming RBF signaling transaction in list. No label for RBF. - - image: /img/compatibility/xapo/rbf/transaction-details-incoming-rbf.png - caption: > - Receiving Transaction Signaling RBF - Incoming RBF signaling transaction details. No RBF flag. - - image: /img/compatibility/xapo/rbf/transaction-list-incoming-replacement.png - caption: > - Receiving Replacement Transaction - Incoming replacement transaction. Both transactions show. Balance credited twice. - - image: /img/compatibility/xapo/rbf/dashboard-incoming-replacement.png - caption: > - Receiving Replacement Transaction - Dashboard shows 2 incoming transaction. Balance includes both transactions. - - image: /img/compatibility/xapo/rbf/notification-incoming-replacement.png - caption: > - Receiving Replacement Transaction - Additional email notification for replacement transaction. - - image: /img/compatibility/xapo/rbf/transaction-list-replacement-confirmed.png - caption: > - Receiving Replacement Transaction - Even after replacement transaction has 100 confirms, original transaction stays pending. -segwit: - tested: - date: "2019-07-27" - platforms: - - iOS - version: "5.0.3" - features: - receive: - p2sh_wrapped: "true" - bech32: "false" - default: "p2sh_wrapped_p2wsh" - send: - bech32: "true" - change_bech32: "false" - segwit_v1: "Xapo allows users to create segwit v1 transactions in the UI. However, - the transaction gets stuck as pending for an indeterminate period of time." - bech32_p2wsh: "true" - examples: - - image: /img/compatibility/xapo/segwit/receive-screen.png - caption: > - Xapo only generates P2SH wrapped P2WSH receive addresses. - - image: /img/compatibility/xapo/segwit/send-screen.png - caption: > - Xappo allows sending to any segwit v0 address. - #- image: /img/compatibility/xapo/segwit/send-screen-segwit-v1-pending.png - # caption: > - # Xapo allows users to create segwit v1 transactions in the UI. However, - # the transaction gets stuck as pending. \ No newline at end of file diff --git a/_data/contributors.yml b/_data/contributors.yml index eba2542501..5732b45381 100644 --- a/_data/contributors.yml +++ b/_data/contributors.yml @@ -17,22 +17,15 @@ contributors: "Bitcoin has a pipeline of innovations flowing from the open source community. I am excited to help with the blocking and tackling needed to help roll out these innovations with the wider community of businesses, wallets, exchanges, and users." - name: Adam Jonas - other_affiliation: Special Projects, Chaincode Labs + other_affiliation: CEO, Chaincode Labs github: adamjonas avatar: jonas.png quote: >- "I am excited about the opportunity Bitcoin has before it as it grows. I hope to contribute my small part as a liaison to help businesses take advantage of all that Bitcoin has to offer as well as gather feedback for the open source community so that we can together bring this wonderfully evolving technology to the masses." - - - name: Carl Dong - other_affiliation: Developer, Chaincode Labs - github: dongcarl - avatar: dong.jpg - quote: >- - "New Bitcoin technologies, and more importantly, their rationales will always take some time to propagate from the engineers working on the bleeding-edge to the services and businesses focused on serving their customers. I'm honored to be able to help Optech accelerate this process." - name: Mark Erhardt other_affiliation: Developer, Chaincode Labs - github: Xekyo + github: murchandamus avatar: erhardt.png quote: >- "The Optech newsletter has been one of the most informative and reliable resources for any Bitcoin engineer since its inception. With its workshops, the Bitcoin Optech Group is bringing together the engineers in the space and paving the road for adoption of best practices and new protocol features." @@ -50,15 +43,39 @@ contributors: avatar: azuchi.png quote: >- "Bitcoin is a very exciting innovation, and many protocols and cryptographic improvements are still being proposed. Understanding these is important for Bitcoin services and businesses, and Optech is one of the most useful resources for that. I hope to contribute to making Bitcoin technical information available to a wide range of people." + - + name: Copinmalin + github: Copinmalin + avatar: copinmalin.jpg + quote: >- + "In an ever-changing world, the Bitcoin revolution represents a pivotal movement combining financial and social shifts. Recognizing the need to understand this, I've translated bitcoinops.org newsletters into French to democratize access to key developments. My aim is to enable broader participation in shaping the future. Proud to join esteemed contributors, I echo Antoine de Saint-Exupéry's sentiment: 'As for the future, it's not about predicting it, but making it possible.'" + - + name: Jiří Jakeš + github: jirijakes + avatar: jirijakes.jpg + quote: >- + "If you believe fixing the money can fix the world, you cannot ignore Bitcoin. If you want to understand Bitcoin, you cannot ignore Optech. Since I made it my routine going through every word of every week's newsletter, my understanding of what Bitcoin was, is and where it might be going took a big leap forward. I am happy to make the knowledge accessible to more people and thus move us a bit closer to fixing the world." + - + name: Zhiwei(Jeffrey) Hu + other_affiliation: Tech Lead, HashKey Capital + github: hulatown + avatar: hulatown.jpg + quote: >- + "One of the best ways to keep up with developments in the Bitcoin ecosystem is to subscribe to the Optech newsletter. I'm excited to be a part of Optech newsletter with a bunch of friends (Xiang YAO, Ajian, Yu ZHANG) in Primitives Lane research group, helping more people learn more about Bitcoin." contributors_alum: + - + name: Carl Dong + other_affiliation: Developer + github: dongcarl + avatar: dong.jpg - name: John Newbery github: jnewbery avatar: newbery.jpg - name: Jon Atack - other_affiliation: Sponsored Developer, Spiral + other_affiliation: Bitcoin Core Developer github: jonatack avatar: atack.jpg - diff --git a/_data/matrix/BitGo.yaml b/_data/matrix/BitGo.yaml new file mode 100644 index 0000000000..c2121fe4f9 --- /dev/null +++ b/_data/matrix/BitGo.yaml @@ -0,0 +1,36 @@ +--- +name: "BitGo" +category: "Software Wallet (L1&L2)" +keyfeatures: "Web-Based, Self-Custodial 2-of-3 Multisig Wallet and Lightning for Enterprise Customers" +homepage: "https://www.bitgo.com" + +feature: + device: "Not Applicable" + os: "Not Applicable" + web: "Yes" + hwi: "No" + default_receive: "P2WSH" + bech32: "Full Support (send & receive)" + bech32m: "Full Support (send & receive)" + segwit_change: "Yes" + full_rbf_bump_fee: "Yes" + full_rbf_cancel_txn: "No" + full_rbf_notification: "Yes" + cpfp: "Full Support (send & receive)" + descriptors: "No" + psbt_version: "V0" + psbt_export: "Yes" + psbt_update_finalize: "Yes" + musig2: "Full Support (send & receive)" + coinjoin: "No Support" + payjoin_BIP78: "No Support" + payjoin_alternate: "No Support" + payjoin_alternate_name: "" + payment_code: "No Support" + silent_payments_BIP352: "No Support" + silent_payments_dns: "No Support" + lightning_11: "Full Support (send & receive)" + lightning_12: "No Support" + lightning_12_dns: "No Support" + lightning_lnurl: "No Support" + lightning_lnurl_hrla: "No Support" diff --git a/_data/matrix/Bitcoin_Core_Wallet.yaml b/_data/matrix/Bitcoin_Core_Wallet.yaml new file mode 100644 index 0000000000..07d2877f93 --- /dev/null +++ b/_data/matrix/Bitcoin_Core_Wallet.yaml @@ -0,0 +1,36 @@ +--- +name: "Bitcoin Core Wallet" +category: "Software Wallet (L1)" +keyfeatures: "Open source project which maintains and releases Bitcoin client software called Bitcoin Core." +homepage: "https://bitcoincore.org" + +feature: + device: "Desktop" + os: "Linux, OS, Windows" + web: "No" + hwi: "Yes" + default_receive: "P2WPKH" + bech32: "Full Support (send & receive)" + bech32m: "Full Support (send & receive)" + segwit_change: "Yes" + full_rbf_bump_fee: "Yes" + full_rbf_cancel_txn: "Yes" + full_rbf_notification: "No" + cpfp: "Full Support (send & receive)" + descriptors: "Yes" + psbt_version: "V0" + psbt_export: "Yes" + psbt_update_finalize: "Yes" + musig2: "No Support" + coinjoin: "No Support" + payjoin_BIP78: "No Support" + payjoin_alternate: "No Support" + payjoin_alternate_name: "" + payment_code: "No Support" + silent_payments_BIP352: "No Support" + silent_payments_dns: "No Support" + lightning_11: "Not Applicable" + lightning_12: "Not Applicable" + lightning_12_dns: "Not Applicable" + lightning_lnurl: "Not Applicable" + lightning_lnurl_hrla: "Not Applicable" diff --git a/_data/matrix/Bitkit.yaml b/_data/matrix/Bitkit.yaml new file mode 100644 index 0000000000..802f035b8f --- /dev/null +++ b/_data/matrix/Bitkit.yaml @@ -0,0 +1,36 @@ +--- +name: "Bitkit" +category: "Software Wallet (L1&L2)" +keyfeatures: "Your ultimate Bitcoin toolkit. Self-custodial BTC and LN payments. Widgets, pay-to-contacts and more" +homepage: "https://bitkit.to/" + +feature: + device: "Mobile" + os: "Android, iOS" + web: "No" + hwi: "No" + default_receive: "P2WPKH" + bech32: "Full Support (send & receive)" + bech32m: "Full Support (send & receive)" + segwit_change: "Yes" + full_rbf_bump_fee: "Yes" + full_rbf_cancel_txn: "No" + full_rbf_notification: "No" + cpfp: "Full Support (send & receive)" + descriptors: "No" + psbt_version: "No Support" + psbt_export: "No" + psbt_update_finalize: "No" + musig2: "No Support" + coinjoin: "No Support" + payjoin_BIP78: "Not Applicable" + payjoin_alternate: "Not Applicable" + payjoin_alternate_name: "" + payment_code: "No Support" + silent_payments_BIP352: "No Support" + silent_payments_dns: "No Support" + lightning_11: "Full Support (send & receive)" + lightning_12: "No Support" + lightning_12_dns: "No Support" + lightning_lnurl: "Full Support (send & receive)" + lightning_lnurl_hrla: "Send Support" diff --git a/_data/matrix/Casa.yaml b/_data/matrix/Casa.yaml new file mode 100644 index 0000000000..8733975f59 --- /dev/null +++ b/_data/matrix/Casa.yaml @@ -0,0 +1,36 @@ +--- +name: "Casa" +category: "Software Wallet (L1)" +keyfeatures: "High security + UX via multi-vendor multisig" +homepage: "https://casa.io" + +feature: + device: "Mobile" + os: "Android, iOS" + web: "No" + hwi: "Yes" + default_receive: "P2SH-P2WSH" + bech32: "Send Support" + bech32m: "Send Support" + segwit_change: "No" + full_rbf_bump_fee: "No" + full_rbf_cancel_txn: "No" + full_rbf_notification: "No" + cpfp: "No Support" + descriptors: "Yes" + psbt_version: "V2" + psbt_export: "Yes" + psbt_update_finalize: "No" + musig2: "No Support" + coinjoin: "No Support" + payjoin_BIP78: "No Support" + payjoin_alternate: "No Support" + payjoin_alternate_name: "" + payment_code: "No Support" + silent_payments_BIP352: "No Support" + silent_payments_dns: "No Support" + lightning_11: "No Support" + lightning_12: "No Support" + lightning_12_dns: "No Support" + lightning_lnurl: "No Support" + lightning_lnurl_hrla: "No Support" diff --git a/_data/matrix/Envoy.yaml b/_data/matrix/Envoy.yaml new file mode 100644 index 0000000000..350a132560 --- /dev/null +++ b/_data/matrix/Envoy.yaml @@ -0,0 +1,36 @@ +--- +name: "Envoy" +category: "Software Wallet (L1)" +keyfeatures: "Envoy is a simple Bitcoin mobile wallet with powerful privacy features." +homepage: "https://foundation.xyz/envoy" + +feature: + device: "Mobile" + os: "Android, iOS" + web: "No" + hwi: "No" + default_receive: "P2WPKH" + bech32: "Full Support (send & receive)" + bech32m: "Full Support (send & receive)" + segwit_change: "Yes" + full_rbf_bump_fee: "Yes" + full_rbf_cancel_txn: "Yes" + full_rbf_notification: "No" + cpfp: "Full Support (send & receive)" + descriptors: "Yes" + psbt_version: "V0" + psbt_export: "Yes" + psbt_update_finalize: "No" + musig2: "No Support" + coinjoin: "No Support" + payjoin_BIP78: "No Support" + payjoin_alternate: "No Support" + payjoin_alternate_name: "" + payment_code: "Send Support" + silent_payments_BIP352: "No Support" + silent_payments_dns: "No Support" + lightning_11: "" + lightning_12: "" + lightning_12_dns: "" + lightning_lnurl: "" + lightning_lnurl_hrla: "" diff --git a/_data/matrix/Liana.yaml b/_data/matrix/Liana.yaml new file mode 100644 index 0000000000..1175a01b3d --- /dev/null +++ b/_data/matrix/Liana.yaml @@ -0,0 +1,36 @@ +--- +name: "Liana" +category: "Software Wallet (L1)" +keyfeatures: "Liana is a simple self-custody wallet with recovery and inheritance features using Miniscript." +homepage: "https://wizardsardine.com/liana/" + +feature: + device: "Desktop" + os: "Linux, OS, Windows" + web: "No" + hwi: "No" + default_receive: "P2WSH" + bech32: "Full Support (send & receive)" + bech32m: "Full Support (send & receive)" + segwit_change: "Yes" + full_rbf_bump_fee: "Yes" + full_rbf_cancel_txn: "Yes" + full_rbf_notification: "No" + cpfp: "Full Support (send & receive)" + descriptors: "Yes" + psbt_version: "V0" + psbt_export: "Yes" + psbt_update_finalize: "Yes" + musig2: "No Support" + coinjoin: "No Support" + payjoin_BIP78: "No Support" + payjoin_alternate: "No Support" + payjoin_alternate_name: "" + payment_code: "No Support" + silent_payments_BIP352: "No Support" + silent_payments_dns: "No Support" + lightning_11: "Not Applicable" + lightning_12: "Not Applicable" + lightning_12_dns: "Not Applicable" + lightning_lnurl: "Not Applicable" + lightning_lnurl_hrla: "Not Applicable" diff --git a/_data/matrix/Nunchuk.yaml b/_data/matrix/Nunchuk.yaml new file mode 100644 index 0000000000..a37664714f --- /dev/null +++ b/_data/matrix/Nunchuk.yaml @@ -0,0 +1,36 @@ +--- +name: "Nunchuk" +category: "Software Wallet (L1)" +keyfeatures: "Nunchuk is a Bitcoin wallet that specializes in multisig and collaborative multisig solutions." +homepage: "https://nunchuk.io/" + +feature: + device: "Desktop, Mobile" + os: "Android, Linux, iOS, OS, Windows" + web: "No" + hwi: "Yes" + default_receive: "P2WSH" + bech32: "Full Support (send & receive)" + bech32m: "Full Support (send & receive)" + segwit_change: "Yes" + full_rbf_bump_fee: "Yes" + full_rbf_cancel_txn: "Yes" + full_rbf_notification: "No" + cpfp: "Full Support (send & receive)" + descriptors: "Yes" + psbt_version: "V0" + psbt_export: "Yes" + psbt_update_finalize: "Yes" + musig2: "Yes" + coinjoin: "No Support" + payjoin_BIP78: "No Support" + payjoin_alternate: "No Support" + payjoin_alternate_name: "" + payment_code: "No Support" + silent_payments_BIP352: "No Support" + silent_payments_dns: "No Support" + lightning_11: "No Support" + lightning_12: "No Support" + lightning_12_dns: "No Support" + lightning_lnurl: "No Support" + lightning_lnurl_hrla: "No Support" diff --git a/_data/matrix/Passport.yaml b/_data/matrix/Passport.yaml new file mode 100644 index 0000000000..854e56de77 --- /dev/null +++ b/_data/matrix/Passport.yaml @@ -0,0 +1,36 @@ +--- +name: "Passport" +category: "Signing Device" +keyfeatures: "Open-source, intuitive, beautiful, and highly secure self-custody." +homepage: "https://foundation.xyz/passport" + +feature: + device: "Not Applicable" + os: "Not Applicable" + web: "Not Applicable" + hwi: "No" + default_receive: "P2WPKH/P2TR" + bech32: "Full Support (send & receive)" + bech32m: "Full Support (send & receive)" + segwit_change: "" + full_rbf_bump_fee: "" + full_rbf_cancel_txn: "" + full_rbf_notification: "" + cpfp: "" + descriptors: "Yes" + psbt_version: "V0" + psbt_export: "Yes" + psbt_update_finalize: "Yes" + musig2: "No Support" + coinjoin: "Not Applicable" + payjoin_BIP78: "" + payjoin_alternate: "" + payjoin_alternate_name: "" + payment_code: "Send Support" + silent_payments_BIP352: "No Support" + silent_payments_dns: "No Support" + lightning_11: "No Support" + lightning_12: "No Support" + lightning_12_dns: "No Support" + lightning_lnurl: "No Support" + lightning_lnurl_hrla: "No Support" diff --git a/_data/matrix/Phoenix.yaml b/_data/matrix/Phoenix.yaml new file mode 100644 index 0000000000..8c377842d8 --- /dev/null +++ b/_data/matrix/Phoenix.yaml @@ -0,0 +1,36 @@ +--- +name: "Phoenix" +category: "Software Wallet (L2)" +keyfeatures: "Phoenix is an easy-to-use non-custodial lightning wallet" +homepage: "https://phoenix.acinq.co/" + +feature: + device: "Mobile" + os: "Android, iOS" + web: "No" + hwi: "No" + default_receive: "P2TR via swap-in-potentiam" + bech32: "Send Support" + bech32m: "Full Support (send & receive)" + segwit_change: "Not Applicable" + full_rbf_bump_fee: "No" + full_rbf_cancel_txn: "No" + full_rbf_notification: "No" + cpfp: "Full Support (send & receive)" + descriptors: "Yes" + psbt_version: "Not Applicable" + psbt_export: "Not Applicable" + psbt_update_finalize: "Not Applicable" + musig2: "Full Support (send & receive)" + coinjoin: "Not Applicable" + payjoin_BIP78: "Not Applicable" + payjoin_alternate: "Not Applicable" + payjoin_alternate_name: "" + payment_code: "" + silent_payments_BIP352: "Not Applicable" + silent_payments_dns: "No Support" + lightning_11: "Full Support (send & receive)" + lightning_12: "Full Support (send & receive)" + lightning_12_dns: "Full Support (send & receive)" + lightning_lnurl: "Send Support" + lightning_lnurl_hrla: "Send Support" diff --git a/_data/matrix/Sparrow_Wallet.yaml b/_data/matrix/Sparrow_Wallet.yaml new file mode 100644 index 0000000000..0014c63497 --- /dev/null +++ b/_data/matrix/Sparrow_Wallet.yaml @@ -0,0 +1,36 @@ +--- +name: "Sparrow Wallet" +category: "Software Wallet (L1)" +keyfeatures: "Bitcoin desktop wallet with a focus on security, privacy and usability" +homepage: "https://sparrowwallet.com" + +feature: + device: "Desktop" + os: "Linux, OS, Windows" + web: "No" + hwi: "Yes" + default_receive: "P2WPKH" + bech32: "Full Support (send & receive)" + bech32m: "Full Support (send & receive)" + segwit_change: "Yes" + full_rbf_bump_fee: "Yes" + full_rbf_cancel_txn: "Yes" + full_rbf_notification: "Yes" + cpfp: "Full Support (send & receive)" + descriptors: "Yes" + psbt_version: "V0" + psbt_export: "Yes" + psbt_update_finalize: "Yes" + musig2: "No Support" + coinjoin: "No Support" + payjoin_BIP78: "Send Support" + payjoin_alternate: "" + payjoin_alternate_name: "" + payment_code: "Full Support (send & receive)" + silent_payments_BIP352: "No Support" + silent_payments_dns: "No Support" + lightning_11: "No Support" + lightning_12: "No Support" + lightning_12_dns: "No Support" + lightning_lnurl: "No Support" + lightning_lnurl_hrla: "No Support" diff --git a/_data/matrix/Wasabi_Wallet_.yaml b/_data/matrix/Wasabi_Wallet_.yaml new file mode 100644 index 0000000000..73b3de8ca0 --- /dev/null +++ b/_data/matrix/Wasabi_Wallet_.yaml @@ -0,0 +1,36 @@ +--- +name: "Wasabi Wallet " +category: "Software Wallet (L1)" +keyfeatures: "Privacy by default, with coinjoin, block filters, and Tor." +homepage: "https://wasabiwallet.io" + +feature: + device: "Desktop" + os: "Linux, OS, Windows" + web: "No" + hwi: "Yes" + default_receive: "P2WPKH" + bech32: "Full Support (send & receive)" + bech32m: "Full Support (send & receive)" + segwit_change: "Yes" + full_rbf_bump_fee: "Yes" + full_rbf_cancel_txn: "Yes" + full_rbf_notification: "Yes" + cpfp: "Full Support (send & receive)" + descriptors: "Yes" + psbt_version: "V2" + psbt_export: "Yes" + psbt_update_finalize: "Yes" + musig2: "No Support" + coinjoin: "Full Support (send & receive)" + payjoin_BIP78: "Send Support" + payjoin_alternate: "" + payjoin_alternate_name: "" + payment_code: "" + silent_payments_BIP352: "No Support" + silent_payments_dns: "No Support" + lightning_11: "No Support" + lightning_12: "No Support" + lightning_12_dns: "No Support" + lightning_lnurl: "No Support" + lightning_lnurl_hrla: "No Support" diff --git a/_data/scaling/toc.yaml b/_data/scaling/toc.yaml deleted file mode 100644 index cdf6262d16..0000000000 --- a/_data/scaling/toc.yaml +++ /dev/null @@ -1,6 +0,0 @@ -## Put items in the order we want people to read them -- name: Introduction - permalink: /en/scaling/introduction/ - -- name: Fee Bumping - permalink: /en/scaling/fee-bumping/ diff --git a/_data/schemas/compatibility.yaml b/_data/schemas/compatibility.yaml deleted file mode 100644 index f8ee7e1cbb..0000000000 --- a/_data/schemas/compatibility.yaml +++ /dev/null @@ -1,178 +0,0 @@ ---- -id: https://bitcoinops.org/schema/compatibility -description: The tool object -type: object -required: - - name - - internal_url - - logo -additionalProperties: false -properties: - name: - description: The name of the tool - type: string - - internal_url: - description: The path to the wallet's detailed page on our site - type: string - pattern: "^/en/compatibility/" - - logo: - description: The path to the wallet's logo on our site - type: string - pattern: &img "^/img/compatibility/.*/.*(png|svg)$" - - rbf: - description: Container for information about Replace-by-Fee (especially BIP125) - type: object - additionalProperties: false - properties: - tested: &tested - description: Data about when this part of the wallet was tested - additionalProperties: false - type: object - properties: - date: - description: "Date tested, YYYY-MM-DD" - type: string - pattern: "^20[0-9][0-9]-[01][0-9]-[0-3][0-9]$" - platforms: - description: supported platforms - type: array - additionalItems: false - items: - type: string - enum: - - Android - - Linux - - Windows - - iOS - - macOS - - web - version: - description: the version tested - type: string - features: - description: RBF features - type: object - properties: - receive: - description: Features related to receiving RBF payments - type: object - properties: - notification: - description: If there is a notification for incoming transactions, does that notification flag whether the transaction signals RBF? - type: string - enum: &feat - - "true" - - "false" - - na - - untested - list: &rbf_list - description: Is an incoming transaction flagged as signaling RBF in the list of wallet transactions? - type: string - enum: *feat - details: &rbf_details - description: Is an incoming transaction flagged as signaling RBF in the transaction details? - type: string - enum: *feat - shows_replaced_version: &rbf_shows_replaced - description: When an RBF replacement (second, higher fee) transaction arrives, does the replacement transaction show? - type: string - enum: *feat - shows_original_version: &rbf_shows_orig - description: When an RBF replacement (second, higher fee) transaction arrives, does the original transaction still show? - type: string - enum: *feat - additionalProperties: false - - send: - description: Features related to sending RBF payments - type: object - properties: - signals_bip125: - description: Does the wallet allow the sending RBF signaled transactions in the interface? - type: string - enum: *feat - list: *rbf_list - details: *rbf_details - shows_replaced_version: *rbf_shows_replaced - shows_original_version: *rbf_shows_orig - additionalProperties: false - - examples: &examples - description: Examples of this category's behavior - type: array - items: - type: object - required: - - image - - caption - additionalProperties: false - properties: - image: - description: Screenshot of behavior or video thumbnail - type: string - pattern: "^/img/compatibility/.*(png|svg)$" - link: - description: Link to a video or additional information - type: string - format: uri - caption: - description: Caption to give the image - type: string - - segwit: - description: Container for information about segwit support - type: object - additionalProperties: false - properties: - tested: *tested - examples: *examples - features: - description: Segwit receiving features - type: object - properties: - receive: - description: Features related to generating segwit receive addresses - type: object - properties: - p2sh_wrapped: - description: Does the wallet allow receiving to P2SH-wrapped segwit? - type: string - enum: *feat - bech32: - description: Does the wallet allow receiving to Bech32 native segwit addresses? - type: string - enum: *feat - default: - description: What is the default address receive type? - type: string - enum: - - "p2pkh" - - "p2sh" - - "p2sh_wrapped" - - "p2sh_wrapped_p2wsh" - - "bech32" - - "bech32_p2wsh" - additionalProperties: false - send: - description: Features related to sending to segwit addresses - type: object - properties: - bech32: - description: Does the wallet allow sending to Bech32 native segwit addresses? - type: string - enum: *feat - change_bech32: - description: Does the wallet return change to itself in a Bech32 native segwit address? - type: string - enum: *feat - segwit_v1: - description: Does the wallet allow sending to segwit v1 witnesses? - type: string - bech32_p2wsh: - description: Does the wallet allow sending to Bech32 native segwit p2wsh addresses? - type: string - enum: *feat - additionalProperties: false \ No newline at end of file diff --git a/_data/schemas/topics.yaml b/_data/schemas/topics.yaml index 8616585817..b408dc60d6 100644 --- a/_data/schemas/topics.yaml +++ b/_data/schemas/topics.yaml @@ -4,7 +4,7 @@ description: The topic object type: object required: - title - - categories + - topic-categories - excerpt - optech_mentions additionalProperties: false @@ -17,7 +17,7 @@ properties: description: Short alternative name to use for creating Markdown reference links type: string - categories: + topic-categories: description: Which categories should list this topic? type: array additionalItems: false @@ -25,12 +25,15 @@ properties: type: string enum: ## Please keep in alphabetical order. - Bandwidth Reduction + - Backup and Recovery - Consensus Enforcement - Contract Protocols - Developer Tools - Fee Management + - Invoicing - Lightning Network - Lightweight Client Support + - Liquidity Management - Mining - P2P Network Protocol - Privacy Enhancements @@ -42,7 +45,7 @@ properties: - Transaction Relay Policy - Wallet Collaboration Tools - aliases: + title-aliases: description: Other names for the topic? type: array items: diff --git a/_data/sponsors.yml b/_data/sponsors.yml index e8d7149c80..42772df9ce 100644 --- a/_data/sponsors.yml +++ b/_data/sponsors.yml @@ -139,7 +139,7 @@ supporters: logo: veriphi.png - name: Xapo - website: https://twitter.com/xapo + website: https://twitter.com/xapoprivatebank logo: xapo.png - name: XBTO diff --git a/_includes/articles/bitgo-musig2.md b/_includes/articles/bitgo-musig2.md new file mode 100644 index 0000000000..4ced0d113f --- /dev/null +++ b/_includes/articles/bitgo-musig2.md @@ -0,0 +1,186 @@ +{:.post-meta} +*by [Brandon Black][] from [BitGo][]* + +The first [MuSig paper][] was published in 2018, and the potential of +[MuSig][topic musig] on +Bitcoin was one of the selling points used to gain support for the taproot soft +fork. Work on MuSig continued with the publication of [MuSig-DN][] and [MuSig2][] in 2020. +When taproot neared activation on Bitcoin’s mainnet in 2021, excitement +about bringing MuSig signing to Bitcoin users was palpable. At BitGo, we were +hoping to launch a MuSig taproot wallet concurrent with taproot activation; but +the spec, test vectors, and reference implementation were incomplete. Instead, +BitGo [launched][bitgo blog taproot] the first tapscript multisig wallet and made the [first tapscript +multisig transaction][] on mainnet. Nearly two years later, MuSig2 is specified in +[BIP327][], and we [launched][bitgo blog musig2] the first MuSig taproot multisig wallet. + +{{include.extrah}}## Why MuSig2? + +{{include.extrah}}### Compared to Script Multisig + +There are two main +benefits of MuSig compared to script multisig. The first and most obvious +benefit is a reduced transaction size and miner fee. Onchain signatures are +64-73 bytes, 16-18.25 virtual bytes (vB), and MuSig can combine two (or more) +signatures into one. In BitGo’s 2-of-3 case, a MuSig key path input costs +57.5vB, compared to a native SegWit input at 104.5vB or depth 1 +[tapscript][topic tapscript] at +107.5vB. The second benefit of MuSig is an improvement in privacy. With a MuSig +key path on a collaboratively held output, a cooperative spend cannot be +distinguished by a third party blockchain observer from a single signature +taproot spend. + +Naturally, there are some drawbacks to MuSig2. Two important ones revolve around +[nonces](#nonces-deterministic-and-random). Unlike signers for plain ECDSA (elliptic curve digital signature +algorithm) or [schnorr signatures][topic schnorr signatures], MuSig2 signers cannot consistently use +deterministic nonces. This inability makes it more difficult to ensure +high-quality nonces and to ensure against nonce reuse. MuSig2 requires two +rounds of communication in most cases. First nonce exchange, and then signing. +In some cases, the first round can be precomputed, but this must be undertaken +cautiously. + +{{include.extrah}}### Compared to Other MPC protocols + +MPC (multi-party compute) signing protocols are growing in popularity due to the +aforementioned fee and privacy benefits. MuSig is a _simple_ multi-signature +(n-of-n) protocol, made possible by schnorr signatures’ linearity. MuSig2 can be +explained in a 30-minute presentation, and the complete reference implementation +is 461 lines of code in Python. [Threshold signature][topic threshold signature] (t-of-n) protocols, such as +[FROST][], are significantly more complex, and even [2-party multi-signatures][] based +on ECDSA rely on Paillier encryption and other techniques. + +{{include.extrah}}## Choice of Scripts + +Even before [taproot][topic taproot], choosing a specific script for a multi-signature (t-of-n) +wallet was difficult. Taproot, with its multiple spending paths further +complicates the matter, and MuSig layers in even more options. Here are some of +the considerations that went into the design of BitGo’s taproot MuSig2 wallet: + +- We use fixed key order, not lexicographic sorting. Each signing key has a +specific role stored with the key, so using those keys in the same order each +time is simple and predictable. +- Our MuSig key path includes only the most common signing quorum, “user” / +“bitgo”. Including the “backup” signing key in the key path would significantly +reduce how often it could be used. +- We do not include the “user”, “bitgo” signing pair in the Taptree. As this is +our second taproot script type and the first is a three tapscript design, users +requiring script signing can use the first type. +- For tapscripts, we do not use MuSig keys. Our wallets include a “backup” key +which is potentially difficult to access or signs with software outside of our +control, so expecting to be able to sign MuSig for the “backup” key is not +realistic. +- For tapscripts, we choose `OP_CHECKSIG` / `OP_CHECKSIGVERIFY` scripts over +`OP_CHECKSIGADD`. We know which keys will sign when we construct transactions, and +2-of-2 depth 1 scripts are slightly cheaper than 2-of-3 depth 0. + +The final structure looks like this: + +{:.center} +![BitGo's MuSig taproot structure](/img/posts/bitgo-musig/musig-taproot-tree.png) + +{{include.extrah}}## Nonces (deterministic and random) + +Elliptic curve digital signatures are produced with the help of an ephemeral +secret value known as a nonce (number used once). By sharing the public nonce (public +nonce is to secret nonce as public key is to secret key) in the signature, +verifiers can confirm the validity of the signature equation without revealing +the long-lived secret key. To protect the long-lived secret key, a nonce must +never be reused with the same (or related) secret key and message. For single +signatures, the most commonly recommended way to protect against nonce reuse is +[RFC6979][] deterministic nonce generation. A uniformly random value can also be +used safely if it is immediately discarded after use. Neither of these +techniques can be applied directly to multi-signature protocols. + +To use deterministic nonces safely in MuSig, a technique like MuSig-DN is +necessary to prove that all participants correctly generate their deterministic +nonces. Without this proof, a rogue signer can initiate two signing sessions for +the same message but provide different nonces. Another signer who generates +their nonce deterministically will generate two partial signatures for the same +nonce with different effective messages, thus revealing their secret key to the +rogue signer. + +During the development of the MuSig2 specification, [Dawid][] and I realized that +the _last_ signer to contribute a nonce could generate their nonce +deterministically. I discussed this with [Jonas Nick][], who formalized it into the +specification. For BitGo’s MuSig2 implementation, this deterministic signing +mode is used with our HSMs (Hardware Security Modules) to enable them to execute +MuSig2 signing statelessly. + +When using random nonces with multi-round signing protocols, signers must +consider how the secret nonces are stored between rounds. In single signatures, +the secret nonce can be deleted in the same execution as it is created. If an +attacker could clone a signer immediately after nonce creation but before +providing nonces from the other signers, the signer could be tricked into +producing multiple signatures for the same nonce but different effective +messages. For this reason, it is recommended that signers carefully consider how +their internal states can be accessed and exactly when secret nonces are +deleted. When BitGo users sign with MuSig2 using the BitGo SDK, secret nonces +are held within the [MuSig-JS][] library, where they are deleted on access for +signing. + +{{include.extrah}}## The Specification Process + +Our experience with implementing MuSig2 at BitGo shows that companies and +individuals working in the Bitcoin space should take the time to review and +contribute to the development of specifications that they intend to (or even +hope to) implement. When we first reviewed the draft MuSig2 specification and +started studying how best to integrate it into our signing systems, we +considered various difficult methods to introduce stateful signing on our HSMs. + +Fortunately, as I described the challenges to Dawid, he was confident that there +was a way to use a deterministic nonce, and we eventually settled on the rough +idea that one signer could be deterministic. When I later raised that idea to +Jonas and explained the specific use case we were trying to enable, he +recognized the value and formalized it into the specification. + +Now other MuSig2 implementers can also take advantage of the flexibility offered +by allowing one of their signers not to manage state. By reviewing (and +implementing) the draft specification during its development, we were able to +contribute to the specification and be ready to launch MuSig2 signing soon after +the specification was formally published as BIP327. + +{{include.extrah}}## MuSig and PSBTs + +The [PSBT (Partially Signed Bitcoin Transaction)][topic psbt] format is intended to carry all +information needed to sign a transaction between the parties (e.g., coordinator +and signers in a simple case). The more information is needed for signing, the +more valuable the format becomes. We examined the costs and benefits of +expanding our existing API format with additional fields to facilitate MuSig2 +signing vs. converting to PSBT. We settled on converting to PSBT format for +transaction data interchange, and it’s been a huge success. It’s not widely +known yet, but BitGo wallets (except those using MuSig2, see the next paragraph) +can now integrate with hardware signing devices that support PSBTs. + +There are not yet published PSBT fields for use in MuSig2 signing. For our +implementation, we used proprietary fields that were based on a draft shared +with us by [Sanket][]. This is one of the little talked about benefits of the PSBT +format - the ability to include _whatever_ additional data might be needed for +your custom transaction building or signing protocol in the same binary data +format; with global, per-input, and per-output sections already defined. The +PSBT specification separates the unsigned transaction from the scripts, +signatures, and other data needed to eventually form a complete transaction. +This separation can enable more efficient communication during the signing +process. For example, our HSM can respond with a minimal PSBT including only its +nonces or signatures, and they can be combined into the pre-signing PSBT easily. + +{{include.extrah}}## Acknowledgements + +Thanks to Jonas Nick and Sanket Kanjalkar at Blockstream; Dawid Ciężarkiewicz at +Fedi; and [Saravanan Mani][], David Kaplan, and the rest of the team at BitGo. + +{% include references.md %} +[Brandon Black]: https://twitter.com/reardencode +[BitGo]: https://www.bitgo.com/ +[MuSig paper]: https://eprint.iacr.org/2018/068 +[MuSig-DN]: https://eprint.iacr.org/2020/1057 +[MuSig2]: https://eprint.iacr.org/2020/1261 +[bitgo blog taproot]: https://blog.bitgo.com/taproot-support-for-bitgo-wallets-9ed97f412460 +[first tapscript multisig transaction]: https://mempool.space/tx/905ecdf95a84804b192f4dc221cfed4d77959b81ed66013a7e41a6e61e7ed530 +[bitgo blog musig2]: https://blog.bitgo.com/save-fees-with-musig2-at-bitgo-3248d690f573 +[FROST]: https://datatracker.ietf.org/doc/draft-irtf-cfrg-frost/ +[2-party multi-signatures]: https://duo.com/labs/tech-notes/2p-ecdsa-explained +[RFC6979]: https://datatracker.ietf.org/doc/html/rfc6979 +[Dawid]: https://twitter.com/dpc_pw +[Jonas Nick]: https://twitter.com/n1ckler +[MuSig-JS]: https://github.com/brandonblack/musig-js +[Sanket]: https://twitter.com/sanket1729 +[Saravanan Mani]: https://twitter.com/saravananmani_ diff --git a/_includes/articles/cs/bitgo-musig2.md b/_includes/articles/cs/bitgo-musig2.md new file mode 100644 index 0000000000..6c7b6eaa82 --- /dev/null +++ b/_includes/articles/cs/bitgo-musig2.md @@ -0,0 +1,185 @@ +{:.post-meta} +*napsal [Brandon Black][] z [BitGo][]* + +První [vědecký článek][MuSig paper] o [MuSig][topic musig] byl publikován v roce 2018 a +jeho potenciál pro bitcoin byl jedním z lákadel soft forku taprootu. Práce na MuSig +pokračovala publikacemi [MuSig-DN][] a [MuSig2][] v roce 2020. Když se v roce 2021 +blížila aktivace taprootu na mainnetu bitcoinu, vzrušení okolo příchodu MuSig podepisování +bylo zjevné. V BitGo jsme doufali ve vydání peněženky s podporou taprootu a MuSig zároveň +s aktivací taprootu, ale specifikace, testovací vektory a referenční implementace nebyly +kompletní. Namísto toho [vydal][bitgo blog taproot] BitGo první tapscriptovou multisig +peněženku a učinil [první tapscriptovou multisig transakci][first tapscript multisig transaction] +na mainnetu. Téměř o dva roky později je MuSig2 specifikován v [BIP327][] a my jsme +[vydali][bitgo blog musig2] první MuSig taprootovou multisig peněženku. + +## Proč MuSig2? + +### Porovnání s multisig skripty + +V porovnání s multisig skripty nabízí MuSig dvě hlavní výhody. První a nejzjevnější +výhodou je snížení velikosti transakce a poplatku za vytěžení. Onchain stopa je +64–73 bytů (16–18,25 vB, virtuálních bytů). K tomu může navíc MuSig zkombinovat dva či více +podpisů do jednoho. V případě BitGo a jeho „2 ze 3” vícenásobného podpisu stojí MuSig +cesta pro utracení klíčem 57,5 vB; pro porovnání nativní SegWit vstup stojí +104,5 vB a [tapscript][topic tapscript] hloubky 1 stojí 107,5 vB. Druhou výhodou MuSig +je zlepšení soukromí. MuSig cestu pro utracení klíčem nelze při kooperativním utracení +rozeznat od běžného taprootového utracení s jedním podpisem. + +MuSig2 však samozřejmě také má své nevýhody. Dvě důležité se týkají +[nonce](#nonce-deterministické-i-náhodné). Na rozdíl od prostého ECDSA (algoritmus digitálního +podpisu s eliptickými křivkami) nebo [Schnorrových podpisů][topic schnorr signatures] nelze v +MuSig2 používat deterministické nonce. Kvůli této vlastnosti je náročnější zajistit +kvalitní nonce a zaručit, že se nonce neopakují. MuSig2 vyžaduje ve většině případů +dvě kola komunikace. Během prvního se vyměňují nonce, ve druhém probíhá podepisování. +V některých případech lze v prvním kole použít předem vypočítaných hodnot, avšak obezřetnost +je nezbytná. + +### Porovnání s ostatními MPC protokoly + +Protokoly pro podepisování více stranami (multi-party compute, MPC) se díky zmíněným +výhodám stávají oblíbenější. MuSig je _jednoduchý_ protokol s vícenásobným „_n_ z _n_” podpisem, +který těží z linearity Schnorrových podpisů. MuSig2 lze vysvětlit během 30minutové +prezentace a jeho úplná referenční implementace v Pythonu zabírá 461 řádků. Protokoly +s [minimálním vyžadovaným počtem podpisů][topic threshold signature] („_t_ z _n_”), jako je +například [FROST][], jsou výrazně složitější a dokonce i [vícenásobné podpisy s dvěma +účastníky][2-party multi-signatures] založené na ECDSA vyžadují Paillierovo šifrování +a jiné techniky. + +## Volba skriptů + +I před [taprootem][topic taproot] byla volba konkrétního skriptu pro peněženky s +vícenásobným podpisem („_t_ z _n_”) obtížná. Taproot se svými několika různými +způsoby utrácení záležitost dále komplikuje. MuSig přidává další volby. Následují +některé úvahy, které stály za návrhem MuSig2 taprootové peněženky v BitGo: + +- Klíče neřadíme lexikograficky, ale používáme pevné pořadí klíčů. Každý klíč pro +podepisování má v sobě stanovenou konkrétní roli, řazení klíčů je tak jednoduché +a předvídatelné. +- Naše MuSig cesta pro utracení klíčem obsahuje pouze nejběžnější podpisové kvórum, +„uživatel” / „bitgo”. Začlenění zálohového podpisového klíče by výrazně snížilo, +jak často by cesta mohla být použita. +- Nezačleňujeme do taptree podpisový pár „uživatel“ a „bitgo”. Jelikož toto je náš druhý +typ taprootového skriptu a první obsahuje tři tapscripty, uživatelé vyžadující podepisování +skriptů mohou použít první druh. +- Pro tapscripty nepoužíváme MuSig klíče. Naše peněženky obsahují zálohový klíč, +ke kterému je potenciálně ztížený přístup nebo který vyžaduje k podepsání jiný software mimo +naši kontrolu. Není tedy realistické předpokládat, že bude tento +klíč schopen podepisovat MuSig. +- Pro tapscripty jsou zvolili skripty `OP_CHECKSIG` / `OP_CHECKSIGVERIFY` namísto +`OP_CHECKSIGADD`. Víme, které klíče budou podepisovat během konstrukce transakce +a 2 ze 2 skripty hloubky 1 jsou mírně levnější než 2 ze 3 skripty hloubky 0. + +Konečná struktura vypadá takto: + +{:.center} +![BitGo's MuSig taproot structure](/img/posts/bitgo-musig/musig-taproot-tree.png) + +## Nonce (deterministické i náhodné) + +Elektronické podpisy nad eliptickými křivkami jsou tvořeny za pomoci dočasné +tajné hodnoty známé jako nonce („number once”). Sdílením veřejného nonce +(veřejný nonce je soukromému nonce to stejné jako veřejný klíč soukromému klíči) +v podpisu mohou ověřovatelé potvrdit validitu podpisu, aniž by bylo nutné +odhalit soukromý klíč. Aby byl tento soukromý klíč ochráněn, nesmí být nonce +znovu použit se stejným (nebo odvozeným) soukromým klíčem a zprávou. Pro +jednoduché podpisy je nejčastěji doporučovaným způsobem ochrany proti +znovupoužití nonce deterministický generátor dle [RFC6979][]. Rovnoměrně +náhodná hodnota může být také bezpečně použita, je-li okamžitě po použití +zahozena. Ani jedna z těchto technik však nemůže být přímo použita pro +protokoly s vícenásobnými podpisy. + +Abychom mohli v MuSig bezpečně používat deterministické nonce, musí být použita +nějaká technika jako MuSig-DN, která prokáže, že všichni účastníci správně +vygenerovali svá deterministická nonce. Bez tohoto důkazu by mohl záškodník +započít dvě sezení podepisující stejnou zprávu, ale za pomoci odlišných +nonce. Druhý podepisující, který generuje nonce deterministicky, by tak v důsledku +částečně podepsal dvě odlišné zprávy shodným nonce. Tím by záškodníkovi odhalil svůj +soukromý klíč. + +Během vývoje specifikace MuSig2 jsme si já a [Dawid][] uvědomili, že _poslední_ +podepisující by mohl svůj nonce vygenerovat deterministicky. Prodiskutoval jsem +to s [Jonasem Nickem][Jonas Nick], který toto pozorování formalizoval ve +specifikaci. V rámci naší implementace MuSig2 využíváme deterministického +podepisování s našimi HMS (hardware security modules), které tak mohou podepisovat +bez držení vnitřního stavu. + +Při používání náhodných nonce v rámci vícekolových podpisových protokolů musí +podepisující zvážit, jak mezi jednotlivými koly nonce ukládat. U jednoduchých +podpisů může být tajný nonce smazán v rámci stejného procesu, který jej vytvořil. +Pokud by útočník získal klon podpisového zařízení okamžitě po vytvoření nonce, +ale ještě před jeho poskytnutím ostatním podepisujícím, mohlo by podpisové +zařízení být donuceno k vytvoření několika podpisů různých zpráv, ale se shodným +nonce. Z tohoto důvodu je doporučeno, aby podepisující uvážlivě rozhodli, +jak lze k vnitřnímu stavu přistupovat a kdy přesně je soukromý nonce smazán. +Když uživatelé BitGo podepisují pomocí MuSig2 a BitGo SDK, soukromá nonce +jsou držena v rámci knihovny [MuSig-JS][], kde jsou po podepsání smazána. + +## Proces specifikace + +Naše zkušenost s implementací MuSig2 ukazuje, že firmy i jednotlivci pracující +kolem bitcoinu by si měli vynahradit čas na revidování a přispívání vývoji +specifikací, které plánují implementovat. Když jsme poprvé zkoumali návrh +specifikace MuSig2 a začali promýšlet, jak jej nejlépe integrovat do našeho +systému, zvažovali jsme různé složité způsoby, jak provádět stavové podepisování +na našich HSM. + +Naštěstí když jsem popsal tyto potíže Dawidovi, věřil, že existuje způsob, jak +používat deterministická nonce. Nakonec jsme se shodli na představě, že jedno +podpisové zařízení by mohlo být deterministické. Když jsem později nadnesl +tuto myšlenku Jonasovi a vysvětlil mu náš konkrétní případ, rozpoznal její hodnotu +a formalizoval ji ve specifikaci. + +Nyní mohou i ostatní implementátoři využít flexibility dané tím, že jedno z +jejich podpisových zařízení nemusí držet stav. Revidováním a implementací +návrhu specifikace během vývoje jsme byli schopni do specifikace přispět a +také jsme mohli uvolnit MuSig2 podepisování krátce po formální publikaci +specifikace v rámci BIP327. + +## MuSig a PSBT + +Formát [částečně podepsaných transakcí][topic psbt] („partially signed bitcoin transaction” +neboli PSBT) je navržen tak, aby obsahoval všechny informace potřebné k podepsání +transakce mezi účastníky (kterými jsou v jednoduchých případech koordinátor a +podepisující). Čím více informací je pro podepsání potřebných, tím užitečnějším +se tento formát stává. Prozkoumali jsme náklady a výhody rozšíření našeho existujícího +API formátu o dodatečná pole pro MuSig2 v porovnání s přechodem na PSBT. Nakonec +jsme se rozhodli pro konverzi k PSBT jako formátu pro výměnu dat o transakci a byl +to obrovský úspěch. Zatím se to obecně neví, ale peněženky BitGo (kromě těch používajících +MuSig2, viz následující odstavec) mohou nyní spolupracovat s hardwarovými podpisovými +zařízeními podporujícími PSBT. + +Zatím nejsou publikována PSBT pole pro použití s MuSig2. Pro naši implementaci +jsme použili proprietární pole, která byla založena na návrhu, jež s námi sdílel +[Sanket][]. Představuje to jednu málo známou výhodu PSBT formátu: možnost do +jednoho binárního datového formátu začlenit – vedle předdefinovaných globálních +sekcí vstupů a výstupů – i _jakákoliv_ dodatečná data potřebná pro váš +vlastní proces tvorby transakcí nebo protokol elektronického podepisování. +Specifikace PSBT odděluje nepodepsané transakce od skriptů, podpisů a dalších +dat potřebných pro zkompletování transakce. Toto oddělení umožňuje efektivnější +komunikaci během procesu podepisování. Například díky tomu mohou naše HSM +poskytnout minimální PSBT obsahující pouze nonce a podpisy a ty mohou být +snadno zkombinovány do předpodpisového PSBT. + +## Poděkování + +Děkuji Jonasovi Nickovi a Sanketovi Kanjalkarovi z Blockstreamu, Dawidovi +Ciężarkiewiczovi z Fedi a [Saravananovi Manimu][Saravanan Mani], Davidovi Kaplanovi +i všem ostatním členům BitGo týmu. + +{% include references.md %} +[Brandon Black]: https://twitter.com/reardencode +[BitGo]: https://www.bitgo.com/ +[MuSig paper]: https://eprint.iacr.org/2018/068 +[MuSig-DN]: https://eprint.iacr.org/2020/1057 +[MuSig2]: https://eprint.iacr.org/2020/1261 +[bitgo blog taproot]: https://blog.bitgo.com/taproot-support-for-bitgo-wallets-9ed97f412460 +[first tapscript multisig transaction]: https://mempool.space/tx/905ecdf95a84804b192f4dc221cfed4d77959b81ed66013a7e41a6e61e7ed530 +[bitgo blog musig2]: https://blog.bitgo.com/save-fees-with-musig2-at-bitgo-3248d690f573 +[FROST]: https://datatracker.ietf.org/doc/draft-irtf-cfrg-frost/ +[2-party multi-signatures]: https://duo.com/labs/tech-notes/2p-ecdsa-explained +[RFC6979]: https://datatracker.ietf.org/doc/html/rfc6979 +[Dawid]: https://twitter.com/dpc_pw +[Jonas Nick]: https://twitter.com/n1ckler +[MuSig-JS]: https://github.com/brandonblack/musig-js +[Sanket]: https://twitter.com/sanket1729 +[Saravanan Mani]: https://twitter.com/saravananmani_ diff --git a/_includes/articles/cs/wizardsardine-miniscript.md b/_includes/articles/cs/wizardsardine-miniscript.md new file mode 100644 index 0000000000..4a9c8c9feb --- /dev/null +++ b/_includes/articles/cs/wizardsardine-miniscript.md @@ -0,0 +1,104 @@ +{:.post-meta} +*napsal [Antoine Poinsot][] z [Wizardsardine][]* + +Z praktického hlediska jsme se o miniscript začali zajímat počátkem roku 2020 +během navrhování [Revault][]. Jedná se o systém [úschovny][topic vaults] s více +účastníky využívající pouze tehdy dostupná skriptová primitiva. + +V první fázi jsme pracovali s pevně daným počtem účastníků. Když jsme se pokoušeli +o generalizaci našeho přístupu na více účastníků, narazili jsme na překážky. + +- Jsme si opravdu _jisti_, že skript, který jsme používali během předvádění, je +bezpečný? Je možné jej opravdu utratí všemi inzerovanými způsoby? Neexistuje i +jiná, nám neznámá možnost utracení? +- A i kdyby existovala, jak zaručit bezpečnost při generalizaci na různé +počty účastníků? Jak můžeme provádět optimalizace a přitom zajistit, aby se neměnila +sémantika výsledného skriptu? +- Revault používá předem podepsané transakce (by mohl vynutit pravidla utracení). +Jak můžeme dopředu vědět, jaký rozpočet v závislosti na nastavení skriptu je +potřeba alokovat na navyšování poplatků? Jak můžeme zajistit, aby _jakákoliv_ +transakce utrácející tyto skripty splňovala základní pravidla standardnosti? +- A konečně, i kdybychom předpokládali, že naše skripty fungují, jak bylo +zamýšleno, a lze je vždy utratit, jak _konkrétně_ je možné je utratit? Jak můžeme +sestavit witness, který bude uspokojovat každou možnou konfiguraci? A jak +zajistit kompatibilitu hardwarových podpisových zařízení s našimi skripty? + +Bez existence miniscriptu bychom se přes tyto otázky nedostali. Dva chlápci v garáži +by nebyli schopni napsat software, který [by za běhu vytvořil nějaký skript, doufali by, +že se nic nestane][rekt lost funds], a navrch by jej mohli označovat za bezpečnou +bitcoinovou peněženku. Naším záměrem bylo založit kolem vývoje Revault firmu, ale +bez poskytnutí nějaké záruky investorům, že jsme schopni dodat na trh bezpečný produkt, +bychom na prostředky nedosáhli. + +Pohleďte na [miniscript][sipa miniscript], „jazyk pro psaní (podmnožiny) bitcoinových +skriptů strukturovaným způsobem, umožňující analýzu, kompozici, generické podepisování + a další. […] Má strukturu umožňující kompozici. Je jednoduché staticky analyzovat +různé jeho vlastnosti (platební podmínky, správnost, bezpečnost, poddajnost atd.).” +Přesně to jsme potřebovali. S tímto mocným nástrojem jsme mohli nabídnout našim +investorům silnější garance [0], vybrat finance a začít Revault vyvíjet. + +V té době nebyl miniscript ještě zdaleka tím řešením, po kterém by se vývojáři +bitcoinových aplikací otáčeli. (Čtete-li tento text jako čerstvý bitcoinový vývojář +po roce 2023, věřte, že bývaly doby, kdy jsme psali bitcoinové skripty RUČNĚ.) Museli +jsme začlenit miniscript do Bitcoin Core (viz PR [#24147][Bitcoin Core #24147], +[#24148][Bitcoin Core #24148] a [#24149][Bitcoin Core #24149]), který jsme pro +peněženku Revault používali jako backend, a přesvědčit výrobce podpisových +zařízení, aby přidali podporu do svých firmware. To druhé se ukázalo jako +nejtěžší. + +Byl to problém slepice a vejce: malá poptávka od uživatelů nepřinášela výrobcům +k implementaci miniscriptu dostatečně silný podnět. A bez podporu podpisových +zařízení jsme Revault vydat nemohli. Naštěstí byla nakonec tato smyčka přerušena, +když v březnu 2021 [přinesl][github embit descriptors] [Stepan Snigirev][] +[podporu][github specter descriptors] pro miniscriptové deskriptory do [Specter DIY][]. +Specter DIY byl však po dlouhou dobu prezentován jako pouhý „funkční prototyp.” +Byl to v roce 2022 až [Salvatore Ingala][], který přinesl [miniscript do produkčního +podpisového zařízení][ledger miniscript blog] Ledger Nano S(+) v rámci +[nové bitcoinové aplikace][ledger bitcoin app]. Ta byla vydána v lednu 2023 +a umožnila nám zveřejnit [peněženku Liana][Liana wallet] s podporou nejpopulárnějšího +podpisového zařízení. + +Zbývá ještě pokrýt náš poslední vývoj. [Liana][github liana] je bitcoinová peněženka +zaměřená na možnosti obnovy. Umožňuje uživatelům specifikovat podmínky obnovy s +časovým zámkem (například [obnovovací klíč poskytnutý třetí stranou][blog liana 0.2 +recovery], který nemůže prostředky normálně utratit, nebo [multisig][blog liana 0.2 decaying] +měnící počet potřebných podpisů během času). Miniscript byl na počátku dostupný pouze +pro P2WSH skripty. Téměř dva roky po aktivaci [taprootu][topic taproot] je bohužel nutné +s každou platbou publikovat onchain své obnovovací skripty. Pracujeme proto na +portování miniscriptu do tapscriptu (viz [jedno][github minitapscript] PR a [druhé][Bitcoin +Core #27255] PR). + +Budoucnost je nadějná. Většina podpisových zařízení již podporu miniscriptu obsahuje, +další pracují na její implementaci (nedávno například [Bitbox][github bitbox v9.15.0] +a [Coldcard][github coldcard 227]). Tvorba bitcoinových kontraktů s bezpečnými primitivy +je dostupnější než kdykoliv předtím. + +Je zajímavé pozorovat, jak financování open source nástrojů a frameworků snižuje +inovativním společnostem vstupní bariéry. Tento trend, který v posledních letech +zrychluje, nám může v této oblasti přinést naději. + +[0] Pochopitelně stále existují rizika. Ale přinejmenším jsme věřili, že se +dostaneme přes tento onchain milník. Offchain bude, nepřekvapivě, mnohem náročnější. + +{% include references.md %} +{% include linkers/issues.md v=2 issues="24147,24148,24149,27255" %} +[Antoine Poinsot]: https://twitter.com/darosior +[Wizardsardine]: https://wizardsardine.com/ +[Revault]: https://wizardsardine.com/revault +[rekt lost funds]: https://rekt.news/leaderboard/ +[sipa miniscript]: https://bitcoin.sipa.be/miniscript +[Stepan Snigirev]: https://github.com/stepansnigirev +[github embit descriptors]: https://github.com/diybitcoinhardware/embit/pull/4 +[github specter descriptors]: https://github.com/cryptoadvance/specter-diy/pull/133 +[Specter DIY]: https://github.com/cryptoadvance/specter-diy +[Salvatore Ingala]: https://github.com/bigspider +[ledger miniscript blog]: https://www.ledger.com/blog/miniscript-is-coming +[ledger bitcoin app]: https://github.com/LedgerHQ/app-bitcoin-new +[Liana wallet]: https://wizardsardine.com/liana/ +[github liana]: https://github.com/wizardsardine/liana +[blog liana 0.2 recovery]: https://wizardsardine.com/blog/liana-0.2-release/#trust-distributed-safety-net +[blog liana 0.2 decaying]: https://wizardsardine.com/blog/liana-0.2-release/#decaying-multisig +[github minitapscript]: https://github.com/sipa/miniscript/pull/134 +[github bitbox v9.15.0]: https://github.com/digitalbitbox/bitbox02-firmware/releases/tag/firmware%2Fv9.15.0 +[github coldcard 227]: https://github.com/Coldcard/firmware/pull/227 +[github bdk]: https://github.com/bitcoindevkit/ diff --git a/_includes/articles/dong-btse-operation.md b/_includes/articles/dong-btse-operation.md index 67456e486b..2d0630b7c7 100644 --- a/_includes/articles/dong-btse-operation.md +++ b/_includes/articles/dong-btse-operation.md @@ -3,7 +3,7 @@ [BTSE](https://www.btse.com/en/home) uses segwit, BIP32 HD wallets, and multisig key management to reduce their operational burdens and improve fund safety. For this Optech field report, we interviewed BTSE staff to learn how their exchange operations have benefited from these Bitcoin technologies. -BIP32 is a widely-implemented [standard][BIP32] that describes how to deterministically derive arbitrarily-many new public keys [from a single extended public key](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Unsecure_money_receiver_NmisubHsub0), even if the corresponding private key is kept offline. Without BIP32, the burden of securely storing private keys would incentivize reuse of public keys and addresses, leading to [problems](https://en.bitcoin.it/wiki/Address_reuse) that include exchange front-running and user loss of privacy. Speaking about the operational advantages of cold wallet deposits for users, BTSE's CEO Jonathan Leong notes that "if the hot wallet keys are compromised, addresses for all users would have to be re-generated, and inevitably some users would continue to send funds to their old addresses." +BIP32 is a widely-implemented [standard][BIP32] that describes how to deterministically derive arbitrarily-many new public keys [from a single extended public key](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Unsecure_money_receiver_NmisubHsub0), even if the corresponding private key is kept offline. Without BIP32, the burden of securely storing private keys would incentivize reuse of public keys and addresses, leading to [problems](https://en.bitcoin.it/wiki/Address_reuse) that include exchange front-running and user loss of privacy. Speaking about the operational advantages of cold wallet deposits for users, BTSE's CEO notes that "if the hot wallet keys are compromised, addresses for all users would have to be re-generated, and inevitably some users would continue to send funds to their old addresses." Although exchanges using BIP32 can keep their private key offline, that private key is still a single point of failure. Happily, they can lessen the impact of compromise of any one single key by constructing a k-of-n multisig address with each of the n public keys derived from a different extended public key. What BTSE achieves with this combination is on-the-fly generation of arbitrarily-many addresses that all deposit straight into a multisig cold wallet without needing to touch the private keys. diff --git a/_includes/articles/fr/bitgo-musig2.md b/_includes/articles/fr/bitgo-musig2.md new file mode 100644 index 0000000000..116d2cfee6 --- /dev/null +++ b/_includes/articles/fr/bitgo-musig2.md @@ -0,0 +1,154 @@ +{:.post-meta} +*par [Brandon Black][] de [BitGo][]* + +Le premier [document MuSig][] a été publié en 2018, et le potentiel de [MuSig][topic musig] sur Bitcoin était l'un des arguments +de vente utilisé pour obtenir le soutien de la mise à jour logicielle taproot. Les travaux sur MuSig ont continué avec la +publication de [MuSig-DN][] et [MuSig2][] en 2020. +En 2021, alors que l'activation de taproot sur le réseau principal Bitcoin approchait, l'excitation de pouvoir apporter +la signature MuSig aux utilisateurs de Bitcoin était palpable. Chez BitGo, nous espérions lancer un portefeuille MuSig taproot +simultanément à l'activation de taproot ; mais la spécification, les vecteurs de test et la mise en œuvre de référence étaient +incomplets. À la place, BitGo a [lancé][bitgo blog taproot] le premier portefeuille multisig tapscript et a effectué la +[première transaction multisig tapscript][] sur le réseau principal. Près de deux ans plus tard, MuSig2 est spécifié dans +[BIP327][], et nous avons [lancé][bitgo blog musig2] le premier portefeuille multisig MuSig taproot. + +{{include.extrah}}## Pourquoi MuSig2 ? + +{{include.extrah}}### Comparé à Script Multisig + +Il existe deux principaux avantages à MuSig par rapport à un script multisig. Le premier et le plus évident est une +réduction de la taille de la transaction et des frais de minage. Les signatures onchain font 64-73 octets, 16-18,25 octets +virtuels (vB), et MuSig peut combiner deux (ou plus) signatures en une seule. Dans le cas de 2-sur-3 de BitGo, une entrée +de clé MuSig coûte 57,5 vB, comparé à une entrée native SegWit à 104,5 vB ou à une profondeur 1 [tapscript][topic tapscript] +à 107,5 vB. Le deuxième avantage de MuSig est une amélioration de la confidentialité. Avec un chemin de clé MuSig sur une +sortie détenue de manière collaborative, une dépense coopérative ne peut pas être distinguée par un observateur tiers de +la blockchain d'une dépense taproot à signature unique. + +Naturellement, il y a quelques inconvénients à MuSig2. Deux des plus importants tournent autour des +[nonces](#nonces-déterministes-et-aléatoires). Contrairement aux signataires pour ECDSA (algorithme de signature numérique à +courbes elliptiques) simple ou les [signautrees de schnorr][topic schnorr signatures], les signataires MuSig2 ne peuvent pas utiliser de manière cohérente des nonces déterministes. Cette incapacité rend plus difficile de garantir des nonces de haute qualité et de se prémunir contre leur réutilisation. MuSig2 nécessite deux tours de communication dans la plupart des cas. +Tout d'abord, l'échange de nonces, puis la signature. Dans certains cas, le premier tour peut être précalculé, mais cela doit +être entrepris avec prudence. + +{{include.extrah}}### Comparé à d'autres protocoles MPC + +Les protocoles de signature MPC (calcul multi-parties) gagnent en popularité en raison des avantages mentionnés précédemment +en termes de frais et de confidentialité. MuSig est un protocole de signature multi-signature (n-sur-n) _simple_, rendu possible +par la linéarité des signatures schnorr. MuSig2 peut être expliqué lors d'une présentation de 30 minutes, et la mise en œuvre +de référence complète ne compte que 461 lignes de code en Python. Les protocoles de [signature seuil][topic threshold signature] +(t-sur-n), tels que [FROST][], sont beaucoup plus complexes, et même les multi-signatures à deux parties basées sur ECDSA reposent +sur le chiffrement de Paillier et d'autres techniques. + +{{include.extrah}}## Choix des scripts + +Même avant [taproot][topic taproot], choisir un script spécifique pour un portefeuille multi-signature (t-sur-n) était difficile. +Taproot, avec ses multiples chemins de dépense, complique davantage la question, et MuSig ajoute encore plus d'options. Voici +quelques considérations qui ont été prises en compte dans la conception du portefeuille taproot MuSig2 de BitGo : + +- Nous utilisons un ordre de clé fixe, pas un tri lexicographique. Chaque clé de signature a un rôle spécifique stocké avec +la clé, donc utiliser ces clés dans le même ordre à chaque fois est simple et prévisible. +- Notre chemin de clé MuSig ne comprend que le quorum de signature le plus courant, "utilisateur" / "bitgo". Inclure la clé +de signature "backup" dans le chemin de clé réduirait considérablement sa fréquence d'utilisation. +- Nous n'incluons pas la paire de signature "utilisateur", "bitgo" dans l'arbre de Taproot. Étant donné que c'est notre +deuxième type de script taproot et que le premier est une conception de script à trois tapscripts, les utilisateurs nécessitant +une signature de script peuvent utiliser le premier type. +- Pour les tapscripts, nous n'utilisons pas de clés MuSig. Nos portefeuilles incluent une clé "backup" qui est potentiellement +difficile d'accès ou signe avec un logiciel en dehors de notre contrôle, donc s'attendre à pouvoir signer MuSig pour la clé +"backup" n'est pas réaliste. +- Pour les tapscripts, nous choisissons les scripts `OP_CHECKSIG` / `OP_CHECKSIGVERIFY` plutôt que `OP_CHECKSIGADD`. Nous savons +quelles clés signeront lorsque nous construisons des transactions, et les scripts 2-sur-2 de profondeur 1 sont légèrement moins +chers que les scripts 2-sur-3 de profondeur 0. + +La structure finale ressemble à ceci : + +{:.center} +![Structure taproot MuSig de BitGo](/img/posts/bitgo-musig/musig-taproot-tree.png) + +{{include.extrah}}## Nonces (déterministes et aléatoires) + +Les signatures numériques sur courbe elliptique sont produites à l'aide d'une valeur secrète éphémère appelée nonce (nombre +utilisé une fois). En partageant le nonce public (le nonce public est au nonce secret ce que la clé publique est à la clé secrète) +dans la signature, les vérificateurs peuvent confirmer la validité de l'équation de signature sans révéler la clé secrète à +long terme. Pour protéger la clé secrète à long terme, un nonce ne doit jamais être réutilisé avec la même clé secrète (ou une +clé secrète liée) et le même message. Pour les signatures simples, la méthode la plus couramment recommandée pour se protéger +contre la réutilisation des nonces est la génération de nonces déterministes [RFC6979][]. Une valeur uniformément aléatoire peut +également être utilisée en toute sécurité si elle est immédiatement jetée après utilisation. Aucune de ces techniques ne peut +être appliquée directement aux protocoles multi-signatures. + +Pour utiliser des nonces déterministes en toute sécurité dans MuSig, une technique comme MuSig-DN est nécessaire pour prouver +que tous les participants génèrent correctement leurs nonces déterministes. Sans cette preuve, un signataire malveillant peut +initier deux sessions de signature pour le même message mais fournir des nonces différents. Un autre signataire qui génère +son nonce de manière déterministe générera deux signatures partielles pour le même nonce avec des messages effectifs différents, +révélant ainsi sa clé secrète au signataire malveillant. + +Lors du développement de la spécification MuSig2, [Dawid][] et moi avons réalisé que le dernier signataire à contribuer à un +nonce pouvait générer son nonce de manière déterministe. J'ai discuté de cela avec [Jonas Nick][], qui l'a formalisé dans la +spécification. Pour l'implémentation MuSig2 de BitGo, ce mode de signature déterministe est utilisé avec nos HSM (modules de +sécurité matérielle) pour leur permettre d'exécuter la signature MuSig2 sans état. +Lors de l'utilisation de nonces aléatoires avec des protocoles de signature à plusieurs tours, les signataires doivent prendre +en compte la manière dont les nonces secrets sont stockés entre les tours. Dans les signatures simples, le nonce secret peut +être supprimé lors de la même exécution où il est créé. Si un attaquant pouvait cloner un signataire immédiatement après la +création du nonce mais avant de fournir les nonces des autres signataires, le signataire pourrait être trompé pour produire +plusieurs signatures pour le même nonce mais avec des messages effectifs différents. Pour cette raison, il est recommandé aux +signataires de réfléchir attentivement à la manière dont leurs états internes peuvent être accessibles et à quel moment précis +les nonces secrets sont supprimés. Lorsque les utilisateurs de BitGo signent avec MuSig2 en utilisant le SDK BitGo, les nonces +secrets sont conservés dans la bibliothèque [MuSig-JS][] où ils sont supprimés lors de l'accès pour la signature. + +{{include.extrah}}## Le processus de spécification + +Notre expérience de mise en œuvre de MuSig2 chez BitGo montre que les entreprises et les individus travaillant dans l'espace +Bitcoin devraient prendre le temps de revoir et de contribuer au développement des spécifications qu'ils ont l'intention de +mettre en œuvre (ou même espèrent mettre en œuvre). Lorsque nous avons examiné pour la première fois la spécification MuSig2 +et avons commencé à étudier la meilleure façon de l'intégrer dans nos systèmes de signature, nous avons envisagé diverses +méthodes difficiles pour introduire une signature avec état sur nos HSM. + +Heureusement, lorsque j'ai exposé les défis à Dawid, il était confiant qu'il existait un moyen d'utiliser un nonce déterministe, +et nous avons finalement opté pour l'idée approximative qu'un signataire pouvait être déterministe. Lorsque j'ai ensuite soulevé +cette idée à Jonas et expliqué le cas d'utilisation spécifique que nous essayions de permettre, il a reconnu la valeur et l'a +formalisée dans la spécification. + +Maintenant, d'autres implémenteurs de MuSig2 peuvent également profiter de la flexibilité offerte en permettant à l'un de leurs +signataires de ne pas gérer l'état. En examinant (et en mettant en œuvre) la spécification provisoire pendant son développement, +nous avons pu contribuer à la spécification et être prêts à lancer la signature MuSig2 peu de temps après que la spécification +ait été officiellement publiée en tant que BIP327. + +{{include.extrah}}## MuSig et PSBT + +Le format [PSBT (Partially Signed Bitcoin Transaction)][topic psbt] est destiné à transporter toutes les informations nécessaires +pour signer une transaction entre les parties (par exemple, le coordinateur et les signataires dans un cas simple). Plus +d'informations sont nécessaires pour la signature, plus le format devient précieux. Nous avons examiné les coûts et les avantages +de l'expansion de notre format d'API existant avec des champs supplémentaires pour faciliter la signature MuSig2 par rapport à la +conversion en PSBT. Nous avons opté pour la conversion au format PSBT pour l'interchangeabilité des données de transaction, et +cela a été un énorme succès. Ce n'est pas encore largement connu, mais les portefeuilles BitGo (sauf ceux utilisant MuSig2, voir +le paragraphe suivant) peuvent désormais s'intégrer aux dispositifs de signature matérielle prenant en charge les PSBT. + +Il n'existe pas encore de champs PSBT publiés pour une utilisation dans la signature MuSig2. Pour notre implémentation, nous avons +utilisé des champs propriétaires basés sur un brouillon partagé avec nous par [Sanket][]. C'est l'un des avantages peu discutés +du format PSBT---la possibilité d'inclure _n'importe_ quelle donnée supplémentaire pouvant être nécessaire pour votre construction +de transaction personnalisée ou votre protocole de signature dans le même format de données binaires, avec des sections globales, +par entrée et par sortie déjà définies. La spécification PSBT sépare la transaction non signée des scripts, des signatures et des +autres données nécessaires pour former finalement une transaction complète. Cette séparation peut permettre une communication plus +efficace pendant le processus de signature. Par exemple, notre HSM peut répondre avec un PSBT minimal comprenant uniquement ses +nonces ou signatures, et ils peuvent être facilement combinés dans le PSBT de pré-signature. + +{{include.extrah}}## Remerciements + +Merci à Jonas Nick et Sanket Kanjalkar chez Blockstream ; Dawid Ciężarkiewicz chez Fedi ; et [Saravanan Mani][], David Kaplan, +et le reste de l'équipe chez BitGo. + +{% include references.md %} +[Brandon Black]: https://twitter.com/reardencode +[BitGo]: https://www.bitgo.com/ +[document MuSig]: https://eprint.iacr.org/2018/068 +[MuSig-DN]: https://eprint.iacr.org/2020/1057 +[MuSig2]: https://eprint.iacr.org/2020/1261 +[bitgo blog taproot]: https://blog.bitgo.com/taproot-support-for-bitgo-wallets-9ed97f412460 +[première transaction multisig tapscript]: https://mempool.space/tx/905ecdf95a84804b192f4dc221cfed4d77959b81ed66013a7e41a6e61e7ed530 +[bitgo blog musig2]: https://blog.bitgo.com/save-fees-with-musig2-at-bitgo-3248d690f573 +[FROST]: https://datatracker.ietf.org/doc/draft-irtf-cfrg-frost/ +[2-party multi-signatures]: https://duo.com/labs/tech-notes/2p-ecdsa-explained +[RFC6979]: https://datatracker.ietf.org/doc/html/rfc6979 +[Dawid]: https://twitter.com/dpc_pw +[Jonas Nick]: https://twitter.com/n1ckler +[MuSig-JS]: https://github.com/brandonblack/musig-js +[Sanket]: https://twitter.com/sanket1729 +[Saravanan Mani]: https://twitter.com/saravananmani_ \ No newline at end of file diff --git a/_includes/articles/fr/wizardsardine-miniscript.md b/_includes/articles/fr/wizardsardine-miniscript.md new file mode 100644 index 0000000000..cdb2a95418 --- /dev/null +++ b/_includes/articles/fr/wizardsardine-miniscript.md @@ -0,0 +1,89 @@ +{:.post-meta} +*par [Antoine Poinsot][] de [Wizardsardine][]* + +Notre intérêt (pratique) pour miniscript a commencé au début de 2020 lorsque nous concevions [Revault][], une architecture de +[coffre-fort][topic vaults] multipartie utilisant uniquement les primitives de script disponibles à l'époque. + +Nous avons initialement présenté Revault en utilisant un ensemble fixe de participants. Nous avons rapidement rencontré des problèmes +lorsque nous avons essayé de le généraliser à un plus grand nombre de participants dans un environnement de production. + +- Sommes-nous vraiment _sûrs_ que le script que nous avons utilisé dans la démonstration est sécurisé ? Est-il possible de le dépenser +de toutes les manières annoncées ? N'y a-t-il aucune autre façon de le dépenser que celle annoncée ? +- Même s'il l'est, comment pouvons-nous le généraliser à un nombre variable de participants tout en le maintenant sécurisé ? +Comment pouvons-nous appliquer des optimisations et nous assurer que le script résultant a les mêmes sémantiques ? +- De plus, Revault utilise des transactions pré-signées (pour appliquer des politiques de dépenses). Comment pouvons-nous connaître à +l'avance le budget à allouer pour l'augmentation des frais en fonction de la configuration du script ? Comment pouvons-nous nous assurer +que _toute_ transaction dépensant ces scripts passera les vérifications de conformité les plus courantes ? +- Enfin, même en supposant que nos scripts correspondent aux sémantiques prévues et qu'ils sont toujours dépensables, comment pouvons-nous +les dépenser _concrètement_ ? Comment pouvons-nous produire un témoin conforme ("signer pour") à chaque configuration possible ? +Comment pouvons-nous rendre les dispositifs de signature matérielle compatibles avec nos scripts ? + +Ces questions auraient constitué des obstacles majeurs si ce n'était pas pour miniscript. Deux personnes dans un garage ne vont pas +écrire un logiciel qui [crée un script à la volée, et espère le meilleur][rekt lost funds] et se permettre d'appeler ça un portefeuille +Bitcoin améliorant la sécurité. Nous voulions créer une entreprise autour du développement de Revault, mais nous n'obtiendrions pas +de financement sans fournir une certaine assurance raisonnable à un investisseur que nous pourrions proposer un produit sûr sur le marché. +Et nous ne pourrions pas résoudre tous ces problèmes d'ingénierie sans financement. + +[Entre en jeu miniscript][sipa miniscript], "un langage pour écrire (une partie de) Scripts Bitcoin de manière structurée, permettant +l'analyse, la composition, la signature générique et plus encore. [...] Il a une structure qui permet la composition. Il est très facile +à analyser statiquement pour diverses propriétés (conditions de dépense, correction, propriétés de sécurité, malléabilité, ...)". C'est +exactement ce dont nous avions besoin. Armés de cet outil puissant, nous pourrions offrir de meilleures garanties [0] à nos investisseurs, +lever des fonds et commencer le développement de Revault. + +À l'époque, miniscript était encore loin d'être une solution clé en main pour tout développeur d'application Bitcoin. (Si vous êtes un +nouveau développeur Bitcoin lisant ceci après l'année 2023, oui, il fut un temps où nous écrivions les scripts Bitcoin À LA MAIN.) +Nous avons dû intégrer miniscript dans Bitcoin Core (voir les PR [#24147][Bitcoin Core #24147], [#24148][Bitcoin Core #24148] et +[#24149][Bitcoin Core #24149]), que nous avons utilisé comme backend du portefeuille Revault, et convaincre les fabricants de dispositifs +de signature de l'implémenter dans leur firmware. Cette dernière partie s'est avérée la plus difficile. + +C'était un problème de poule et d'œuf : les incitations étaient faibles pour les fabricants d'implémenter miniscript sans demande des +utilisateurs. Et nous ne pouvions pas sortir Revault sans avoir des dispositifs de signature compatibles avec miniscript sans prise en +charge de l'appareil de signature. Heureusement, ce cycle a finalement été brisé par [Stepan Snigirev][] en mars 2021 en +[apportant][github embit descriptors] la prise en charge des descripteurs miniscript à [Specter DIY][]. Cependant, le Specter DIY a été +pendant longtemps considéré comme un simple "prototype fonctionnel", et [Salvatore Ingala][] a apporté [miniscript à un appareil de +signature prêt pour la production][ledger miniscript blog] pour la première fois en 2022 avec la [nouvelle application +Bitcoin][ledger bitcoin app] pour le Ledger Nano S(+). L'application a été publiée en janvier 2023, ce qui nous a permis de publier le +[portefeuille Liana][] avec prise en charge de l'appareil de signature le plus populaire. + +Il ne reste plus qu'un dernier développement pour conclure notre parcours miniscript. [Liana][github liana] est un portefeuille Bitcoin +axé sur les options de récupération. Il permet de spécifier certaines conditions de récupération avec verrouillage temporel (par exemple, +une [clé de récupération tierce qui ne peut normalement pas dépenser les fonds][blog liana 0.2 recovery], ou un [multisig en déclin/ +expansion][blog liana 0.2 decaying]). Miniscript était initialement disponible uniquement pour les scripts P2WSH. Près de 2 ans après +l'activation de [taproot][topic taproot], il est regrettable que vous deviez publier vos chemins de dépense de récupération on chain +à chaque fois que vous faites une dépense. À cette fin, nous avons travaillé pour porter miniscript à tapscript (voir +[ici][github minitapscript] et [ici][Bitcoin Core #27255]). + +L'avenir est prometteur. La plupart des appareils de signature ayant déjà implémenté ou étant en cours d'implémentation +de miniscript (par exemple récemment [Bitbox][github bitbox v9.15.0] et [Coldcard][github coldcard 227]), les frameworks +natifs de [taproot et miniscript][github bdk] ayant été peaufinés, la contractualisation sur Bitcoin avec des primitives sécurisées est +plus accessible que jamais. + +Il est intéressant de noter comment le financement des outils et des frameworks Open Source réduit les barrières à l'entrée pour les +entreprises innovantes qui peuvent désormais affronter la concurrence et, plus généralement, mettre en œuvre des projets. Cette tendance, +qui s'est accélérée ces dernières années, nous permet d'être optimistes quant à l'avenir de cet espace. + +[0] Il y avait toujours un risque, bien sûr. Mais au moins, nous étions confiants de pouvoir passer à l'étape off-chain. Celle-ci s'est +avérée (comme prévu) plus difficile. + +{% include references.md %} +{% include linkers/issues.md v=2 issues="24147,24148,24149,27255" %} +[Antoine Poinsot]: https://twitter.com/darosior +[Wizardsardine]: https://wizardsardine.com/ +[Revault]: https://wizardsardine.com/revault +[rekt lost funds]: https://rekt.news/leaderboard/ +[sipa miniscript]: https://bitcoin.sipa.be/miniscript +[Stepan Snigirev]: https://github.com/stepansnigirev +[github embit descriptors]: https://github.com/diybitcoinhardware/embit/pull/4 +[github specter descriptors]: https://github.com/cryptoadvance/specter-diy/pull/133 +[Specter DIY]: https://github.com/cryptoadvance/specter-diy +[Salvatore Ingala]: https://github.com/bigspider +[ledger miniscript blog]: https://www.ledger.com/blog/miniscript-is-coming +[ledger bitcoin app]: https://github.com/LedgerHQ/app-bitcoin-new +[portefeuille Liana]: https://wizardsardine.com/liana/ +[github liana]: https://github.com/wizardsardine/liana +[blog liana 0.2 recovery]: https://wizardsardine.com/blog/liana-0.2-release/#trust-distributed-safety-net +[blog liana 0.2 decaying]: https://wizardsardine.com/blog/liana-0.2-release/#decaying-multisig +[github minitapscript]: https://github.com/sipa/miniscript/pull/134 +[github bitbox v9.15.0]: https://github.com/digitalbitbox/bitbox02-firmware/releases/tag/firmware%2Fv9.15.0 +[github coldcard 227]: https://github.com/Coldcard/firmware/pull/227 +[github bdk]: https://github.com/bitcoindevkit/bdk \ No newline at end of file diff --git a/_includes/articles/ja/bitgo-musig2.md b/_includes/articles/ja/bitgo-musig2.md new file mode 100644 index 0000000000..85fe098245 --- /dev/null +++ b/_includes/articles/ja/bitgo-musig2.md @@ -0,0 +1,162 @@ +{:.post-meta} +*[BitGo][]の[Brandon Black][]より* + +最初の[MuSigの論文][MuSig paper]は2018年に発表され、Bitcoinにおける[MuSig][topic musig]の可能性は、 +Taprootのソフトフォークの支持を得るためのセールスポイントの1つでした。 +MuSigの研究は続き、2020年に[MuSig-DN][]と[MuSig2][]が発表されました。 +2021年にBitcoinのmainnetでTaprootのアクティベートが近づくにつれ、 +MuSig署名をBitcoinユーザーに提供することに対する興奮が高まっていました。 +BitGoでは、Taprootのアクティベートと同時にMuSig Taprootウォレットをローンチしたいと考えていましたが、 +仕様や、Test Vector、参照実装が不完全でした。 +代わりに、BitGoは最初のTapscriptマルチシグウォレットを[ローンチし][bitgo blog taproot]、 +mainnet上で[最初のTapscriptマルチシグトランザクション][first tapscript multisig transaction]を作成しました。 +それから約2年後、[BIP327][]でMuSig2が定義され、BitGoは最初のTaprootマルチシグウォレットを[ローンチしました][bitgo blog musig2]。 + +{{include.extrah}}## MuSig2を使用する理由 + +{{include.extrah}}### スクリプトマルチシグとの比較 + +MuSigには、スクリプトマルチシグと比べて2つの主な利点があります。 +1つは、最も明白な利点で、トランザクションサイズとマイナー手数料の削減です。 +オンチェーンの署名は、64-73バイト（16-18.25仮想バイト（vb））で、 +MuSigは2つ（またはそれ以上の）署名を1つにまとめることができます。 +BitGoの2-of-3の場合、MuSigのキーパスのインプットのコストは57.5vBですが、 +ネイティブSegwitのインプットのコストは104.5vB、深さ1の[Tapscript][topic tapscript]のコストは107.5vBです。 +MuSigの2つめの利点は、プライバシーの向上です。 +MuSigのキーパスで協力的に保持されているアウトプットの場合、 +第三者のブロックチェーンの観察者が、その協力的な支払いと単一署名のTaprootの支払いを区別することはできません。 + +当然ながら、MuSig2には欠点もあります。2つの重要な欠点は、 +[ナンス](#決定論的およびランダムなナンス)に関連するものです。 +素のECDSA（楕円曲線デジタル署名アルゴリズム）や[Schnorr署名][topic schnorr signatures]とは異なり、 +MuSig2の署名者は一貫して決定論的なナンスを使用することができません。 +このため、高品質のナンスを保証したり、ナンスの再利用を確実に防止することがより困難になります。 +MuSig2では、ほとんどの場合、2ラウンドの通信が必要です。 +最初にナンスを交換し、次に署名します。場合によっては、最初のラウンドを事前に計算できますが、 +これは慎重に行わなければなりません。 + +{{include.extrah}}### 他のMPCプロトコルとの比較 + +MPC（マルチパーティ計算）署名プロトコルは、前述の手数料とプライバシーの利点から人気が高まっています。 +MuSigはシンプルなマルチシグ（n-of-n）プロトコルであり、これはSchnorr署名の線型性によって実現されています。 +MuSig2は30分のプレゼンテーションで説明でき、完全な参照実装はPythonで461行のコードです。 +[FROST][]のような[閾値署名][topic threshold signature]（t-of-n）プロトコルはかなり複雑で、 +ECDSAベースの[2者間のマルチシグ][2-party multi-signatures]でさえPaillier暗号やその他の技術に依存しています。 + +{{include.extrah}}## スクリプトの選択 + +[Taproot][topic taproot]以前でさえ、マルチシグ（t-of-n）ウォレット用の特定のスクリプトを選択することは困難でした。 +複数の支払いパスを持つTaprootは、さらに問題を複雑にし、MuSigはさらに多くの選択肢を重ねています。 +BitGoのTaproot Musig2ウォレットの設計に取り組む際に考慮したいいくつかの点を紹介します: + +- 辞書順のソートではなく、鍵の順序を固定します。各署名鍵には、特定の役割が鍵とともに保存されているため、 +毎回同じ順番でこれらの鍵を使用することは簡単で予測可能です。 +- 私たちのMuSigのキーパスには、最も一般的な署名の充足数“user”/“bitgo”のみが含まれています。 +”backup”の署名鍵をキーパスに含めると、その鍵の使用頻度が大幅に低下します。 +- “user”と“bitgo”の署名ペアはTaptreeには含めません。これは2つめのTaprootスクリプトタイプであり、 +1つめは3つのTapscript設計であるため、スクリプト署名が必要なユーザーは１つめのタイプを使用できます。 +- Tapscriptの場合、MuSigの鍵を使用しません。当社のウォレットには、”backup”鍵が含まれていますが、 +これは当社の管理外のソフトウェアではアクセスや署名が困難である可能性があるため、 +“backup”鍵に対してMuSigで署名できることを期待するのは現実的ではありません。 +- Tapscriptの場合、`OP_CHECKSIGADD`よりも`OP_CHECKSIG` / `OP_CHECKSIGVERIFY`スクリプトを選択します。 +トランザクションを構築する際に、どの鍵が署名するかは分かっており、2-of-2の深さ1のスクリプトは、 +2-of-3の深さ0のスクリプトよりもわずかに安価です。 + +最終的な構造は以下のようになります: + +{:.center} +![BitGo's MuSig taproot structure](/img/posts/bitgo-musig/musig-taproot-tree.png) + +{{include.extrah}}## （決定論的およびランダムな）ナンス + +楕円曲線デジタル署名は、ナンス（一度だけ使用される数値）として知られる一時的な秘密の値を使用して生成されます。 +公開ナンス（公開鍵と秘密鍵のようにシークレットナンスに対応する公開ナンス）を署名で共有することで、 +検証者に有効期間の長い秘密鍵を明らかにすることなく、署名式の正当性を検証することができます。 +有効期間の長い秘密鍵を保護するために、同じ（または関連する）秘密鍵とメッセージでナンスを再利用してはなりません。 +単一署名の場合、ナンスの再利用を防ぐ最も一般的に推奨される方法は、[RFC6979][]決定論的ナンス生成です。 +一様にランダムな値でも、使用後すぐに破棄すれば安全に使用できます。これらの手法はいずれも、 +マルチシグプロトコルに直接適用することはできません。 + +MuSigで決定論的ナンスを安全に使用するには、MuSig-DNのような手法を使用して、 +すべての参加者が決定論的ナンスを正しく生成していることを証明する必要があります。 +この証明がないと、不正な署名者は同じメッセージに対して2つの署名セッションを開始し、 +異なるナンスを提供することができます。決定論的にナンスを生成する別の署名者は、 +異なる有効なメッセージに対して同じナンスを使って2つの部分署名を生成します。 +これにより、その秘密鍵が不正な署名者に明らかになります。 + +MuSig2の仕様の開発中、[Dawid][]と私は、最後にナンスを提供する署名者は、 +決定論的にナンスを生成できることに気づきました。 +これについて[Jonas Nick][]と議論し、彼は正式にそれを仕様に取り込みました。 +BitGoのMuSig2実装では、この決定論的署名モードは私たちのHSM（ハードウェアセキュリティモジュール）で使用され、 +ステートレスにMuSig2署名を実行できるようにしています。 + +ランダムなナンスを複数ラウンドの署名プロトコルで使用する場合、 +署名者はシークレットナンスがラウンド間でどのように保存されるかを考慮する必要があります。 +単一署名の場合、シークレットナンスは作成と同じ署名実行中に削除できます。 +攻撃者がナンス作成直後に他の署名者がナンスを提供する前に署名者のクローンを作成できる場合、 +署名者は騙されて同じナンスで異なる有効なメッセージに対して複数の署名を生成する可能性があります。 +このため、署名者は内部状態にどのようにアクセスでき、いつシークレットナンスが削除されるかを慎重に考える必要があります。 +BitGoユーザーがBitGo SDKを使用してMuSig2で署名する場合、 +シークレットナンスは[MuSig-JS][]ライブラリ内に保持され、署名のためのアクセス時に削除されます。 + +{{include.extrah}}## 仕様化のプロセス + +BitGoでMuSig2を実装した経験から、Bitcoin分野に携わる企業や個人は、 +実装を予定している（または望んでいる）仕様の開発を時間をかけてレビューし、貢献する必要があることがわかります。 +私たちが最初にMuSig2の仕様をレビューし、それを私たちの署名システムに統合する最善の方法を検討し始めたとき、 +私たちのHSMにステートフル署名を導入するためのさまざまな困難な方法を検討しました。 + +幸いなことに、私が課題をDawidに説明したところ、彼は決定論的ナンスを使用する方法があると確信し、 +最終的には、1人の署名者は決定論的であるという大まかなアイデアに落ち着きました。 +その後、私がそのアイディアをJonasに提案し、実現しようとしている具体的なユースケースを説明したところ、 +彼はその価値を認め、仕様に正式に取り入れたのです。 + +これで他のMuSig2実装者も、署名者の1人が状態を管理しないことで得られる柔軟性を活用できるようになりました。 +仕様策定中にドラフト仕様をレビュー（および実装）することで、私たちは仕様に貢献し、 +仕様が正式にBIP327として公開された直後にMuSig2署名をローンチする準備ができました。 + +{{include.extrah}}## MuSigとPSBT + +[PSBT (Partially Signed Bitcoin Transaction)][topic psbt]形式は、 +参加者（たとえば、単純な場合はコーディネーターと署名者）間で +トランザクションに署名するために必要なすべての情報を伝達することを意図しています。 +署名に必要な情報が多いほど、この形式の価値は高まります。 +私たちは、MuSig2署名を容易にするために既存のAPI形式にフィールドを追加して拡張する場合と、 +PSBTに変換する場合のコストと利点を検討しました。 +私たちは、トランザクションデータのやりとりにPSBT形式を採用することに決め、それは大きな成功になりました。 +まだ広く知られていませんが、BitGoウォレット（MuSig2を使用するものを除く、次の段落を参照）は、 +PSBTをサポートするハードウェア署名デバイスと統合できるようになりました。 + +MuSig2署名で使用するPSBTフィールドはまだ公開されていません。私たちの実装では、 +[Sanket][]によって共有されたドラフトをベースにした独自フィールドを使用しています。 +これは、PSBT形式のあまり語られない利点の1つです。カスタムトランザクションの構築や、 +署名プロトコルに必要な追加データを、同じバイナリデータ形式で含めることができます。 +グローバル、インプット毎、アウトプット毎の各セクションで既に定義されています。 +PSBTの仕様では、未署名のトランザクションを、スクリプトや署名および、 +最終的に完全なトランザクションを形成するために必要なその他のデータから分離しています。 +この分離により、署名プロセス中により効率的な通信が可能になります。たとえば、 +私たちのHSMは、ナンスまたは署名のみを含む最小限のPSBTを返し、 +それを署名前のPSBTに簡単に組み込むことができます。 + +{{include.extrah}}## 謝辞 + +BlockstreamのJonas NickとSanket Kanjalkar、FediのDawid Ciężarkiewicz、 +そして[Saravanan Mani][]とDavid Kaplan、BitGoのチームの残りのメンバーに感謝します。 + +{% include references.md %} +[Brandon Black]: https://twitter.com/reardencode +[BitGo]: https://www.bitgo.com/ +[MuSig paper]: https://eprint.iacr.org/2018/068 +[MuSig-DN]: https://eprint.iacr.org/2020/1057 +[MuSig2]: https://eprint.iacr.org/2020/1261 +[bitgo blog taproot]: https://blog.bitgo.com/taproot-support-for-bitgo-wallets-9ed97f412460 +[first tapscript multisig transaction]: https://mempool.space/tx/905ecdf95a84804b192f4dc221cfed4d77959b81ed66013a7e41a6e61e7ed530 +[bitgo blog musig2]: https://blog.bitgo.com/save-fees-with-musig2-at-bitgo-3248d690f573 +[FROST]: https://datatracker.ietf.org/doc/draft-irtf-cfrg-frost/ +[2-party multi-signatures]: https://duo.com/labs/tech-notes/2p-ecdsa-explained +[RFC6979]: https://datatracker.ietf.org/doc/html/rfc6979 +[Dawid]: https://twitter.com/dpc_pw +[Jonas Nick]: https://twitter.com/n1ckler +[MuSig-JS]: https://github.com/brandonblack/musig-js +[Sanket]: https://twitter.com/sanket1729 +[Saravanan Mani]: https://twitter.com/saravananmani_ diff --git a/_includes/articles/ja/wizardsardine-miniscript.md b/_includes/articles/ja/wizardsardine-miniscript.md new file mode 100644 index 0000000000..2e4363d202 --- /dev/null +++ b/_includes/articles/ja/wizardsardine-miniscript.md @@ -0,0 +1,100 @@ +{:.post-meta} +*[Wizardsardine][]の[Antoine Poinsot][]より* + +miniscriptに対する私たちの（実用的な）興味は、2020年初頭に、 +当時利用可能なスクリプトプリミティブのみを使用するマルチパーティ[Vault][topic vaults]アーキテクチャである +[Revault][]を設計していた頃に始まりました。 + +私たちは当初、固定の参加者のセットを使用したRevaultを紹介しました。 +運用環境で、より多くの参加者に一般化しようとするとすぐに問題に遭遇しました。 + + +- 実際、デモで使用したスクリプトは安全だろうか？宣伝されているすべての方法で使用可能なのか？ +宣伝されている以外の使用方法はないのか？ +- たとえそうだとしても、それを様々な数の参加者に一般化し、安全性を保つためにはどうすればいいのか？ +いくつかの最適化を適用して、その結果のスクリプトが同じセマンティクスを持つようにするにはどうすればいいか？ +- さらに、Revaultは（支払いポリシーを強制するため）事前署名されたトランザクションを使用している。 +スクリプトの構成から、手数料の引き上げに割り当てる予算を事前に把握するにはどうしたらいいか？ +これらのスクリプトを使用するトランザクションが最も一般的な標準性チェックをパスすることをどうやって確認できるだろうか？ +- 最後に、スクリプトが意図されたセマンティクスに対応し、常に使用可能であると仮定しても、 +具体的にどのように使用できるだろうか？例えば、考えられるすべての構成について満足のいくwitness（署名）を作成するには +どうすればいいだろうか？ハードウェア署名デバイスと互換性のあるものにするにはどうすればいいか？ + +miniscriptがなかったら、これらの問いは難題になっていたでしょう。 +ガレージにいる2人の男が、[その場でスクリプトを作成する][rekt lost funds]ソフトウェアを書き、 +最善を尽くし、その上でそれをセキュリティを強化するBitcoinウォレットと呼ぶつもりはないでしょう。 +私たちはRevaultの開発を中心に会社を設立したいと考えていましたが、 +安全な製品を市場に投入できるという合理的な保証を投資家に提供しなければ、資金を得ることはできませんでした。 +また、資金がなければ、これらのエンジニアリングの課題をすべて解決することはできないでしょう。 + + +[miniscript][sipa miniscript]は、「構造化された方法でBitcoin Script（のサブセット）を記述し、 +分析、組み合わせ、汎用署名などを可能にする言語です。[...]合成を可能にする構造を持っています。 +さまざまな特性（使用条件、正当性、セキュリティ特性、マリアビリティなど）を静的に分析するのがとても簡単です。」 +これはまさに私たちが必要としていたものです。この強力なツールを手に入れたことで、 +投資家により良い保証[0]を提供することができ、資金を調達し、Revaultの開発を開始することができました。 + +当時、miniscriptはBitcoinアプリケーション開発者にとって +すぐに使用できるソリューションにはまだほど遠いものでした（もし、なたが2023年以降にこれを読んでいる新しい +Bitcoin開発者であれば、そう、私たちはBitcoin Scriptを手で書いていた時期がありました）。 +私たちは、miniscriptをBitcoin Coreに統合し（PR [#24147][Bitcoin Core #24147]、 +[#24148][Bitcoin Core #24148]、[#24149][Bitcoin Core #24149]参照）、 +Revaultウォレットのバックエンドとして使用し、署名デバイスメーカーにファームウェアを実装するよう説得する必要がありました。 +後者が最も困難でした。 + +これは鶏と卵の問題でした。ユーザーからの需要がないのに、メーカーがminiscriptを実装するインセンティブは低かったのです。 +そして私たちは、署名デバイスのサポートなしにRevaultをリリースすることはできませんでした。 +幸運なことに、このサイクルは、2021年3月に[Stepan Snigirev][]によって +[Specter DIY][]にminiscriptディスクリプターの[サポート][github specter descriptors]が +[導入された][github embit descriptors]ことで最終的に解消しました。 +しかし、Specter DIYは長い間、単なる「機能的なプロトタイプ」であるみなされ、 +[Salvatore Ingala][]は2022年にLedger Nano S(+)用の[新しいBitcoinアプリ][ledger bitcoin app]で初めて +[製品化可能な署名デバイスにminiscriptを導入しました][ledger miniscript blog]。 +このアプリは、2023年1月にリリースされ、最も人気のある署名デバイスをサポートした +[Lianaウォレット][Liana wallet]を公開することができました。 + +miniscriptの旅路を締めくくるには、最後の開発が残っています。 +[Liana][github liana]はリカバリーオプションに焦点を当てたBitcoinウォレットです。 +このウォレットでは、タイムロックされたリカバリー条件（たとえば、 +[通常は資金を使用できないサードパーティのリカバリー鍵][blog liana 0.2 recovery]や、 +[減衰/拡大するマルチシグ][blog liana 0.2 decaying]など）を指定できます。 +miniscriptは当初、P2WSHスクリプトでのみ利用可能でした。 +[Taproot][topic taproot]がアクティベートされてから2年近く経ちますが、 +資金を使用する度にリカバリーの支払い条件をオンチェーンで公開しなければならないのは残念なことです。 +このため、私たちはminiscriptをTapscriptに移植する作業を行ってきました（ +[こちら][github minitapscript]と[こちら][Bitcoin Core #27255]を参照）。 + +未来は明るいです。ほとんどの署名デバイスがminiscriptのサポートを実装しているか、 +実装中（たとえば、最近の[Bitbox][github bitbox v9.15.0]や[Coldcard][github coldcard 227]）なのに加えて、 +[Taprootとminiscriptのネイティブフレームワーク][github bdk]が洗練されているため、 +安全なプリミティブを使用したBitcoin上のコントラクトはこれまで以上にアクセスしやすくなっています。 + +オープンソースのツールやフレームワークへの資金提供によって、革新的な企業が競争し、 +より一般的にはプロジェクトを実行するための参入障壁がどう低くなるかに注目することは興味深いことです。 +ここ数年で加速しているこの傾向は、この分野の未来に希望を抱かせてくれます。 + +[0] もちろんリスクはまだありました。しかし、少なくともオンチェーンの部分は乗り越えられると確信していました。 +オフチェーンの方は（予想どおり）もっと難しいことが分かりました。 + +{% include references.md %} +{% include linkers/issues.md v=2 issues="24147,24148,24149,27255" %} +[Antoine Poinsot]: https://twitter.com/darosior +[Wizardsardine]: https://wizardsardine.com/ +[Revault]: https://wizardsardine.com/revault +[rekt lost funds]: https://rekt.news/leaderboard/ +[sipa miniscript]: https://bitcoin.sipa.be/miniscript +[Stepan Snigirev]: https://github.com/stepansnigirev +[github embit descriptors]: https://github.com/diybitcoinhardware/embit/pull/4 +[github specter descriptors]: https://github.com/cryptoadvance/specter-diy/pull/133 +[Specter DIY]: https://github.com/cryptoadvance/specter-diy +[Salvatore Ingala]: https://github.com/bigspider +[ledger miniscript blog]: https://www.ledger.com/blog/miniscript-is-coming +[ledger bitcoin app]: https://github.com/LedgerHQ/app-bitcoin-new +[Liana wallet]: https://wizardsardine.com/liana/ +[github liana]: https://github.com/wizardsardine/liana +[blog liana 0.2 recovery]: https://wizardsardine.com/blog/liana-0.2-release/#trust-distributed-safety-net +[blog liana 0.2 decaying]: https://wizardsardine.com/blog/liana-0.2-release/#decaying-multisig +[github minitapscript]: https://github.com/sipa/miniscript/pull/134 +[github bitbox v9.15.0]: https://github.com/digitalbitbox/bitbox02-firmware/releases/tag/firmware%2Fv9.15.0 +[github coldcard 227]: https://github.com/Coldcard/firmware/pull/227 +[github bdk]: https://github.com/bitcoindevkit/bdk \ No newline at end of file diff --git a/_includes/articles/wizardsardine-miniscript.md b/_includes/articles/wizardsardine-miniscript.md new file mode 100644 index 0000000000..c63a5a37e9 --- /dev/null +++ b/_includes/articles/wizardsardine-miniscript.md @@ -0,0 +1,112 @@ +{:.post-meta} +*by [Antoine Poinsot][] from [Wizardsardine][]* + +Our (practical) interest for miniscript started back in early 2020 when we were +designing [Revault][], a multiparty [vault][topic vaults] architecture only +using then available scripting primitives. + +We initially showcased Revault using a fixed set of participants. We quickly ran +into issues as we tried to generalize it to more participants in a production +setting. + +- Actually are we _sure_ the script we used in the demo is secure? Is it +possible to spend it in all the ways it's advertized to be? Is there no other +way of spending it than how it's advertized? +- Even if it is, how can we generalize it to various number of participants and +keep it secure? How can we apply some optimizations and make sure the resulting +script has the same semantics? +- In addition, Revault is using pre-signed transactions (to enforce spending +policies). How can we know in advance the budget to allocate for fee-bumping +given the configuration of the script? How can we make sure _any_ transaction +spending those scripts will pass the most common standardness checks? +- Finally, even assuming our scripts correspond to the intended semantics and +are always spendable, how can we _concretely_ spend them? As in how can we +produce a satisfying witness for ("sign for") each and every possible +configuration? How can we make hardware signing devices compatible with our +scripts? + +These questions would have been a show stopper if it was not for miniscript. Two +guys in a garage are not going to write a software that [creates some script on +the fly, hope for the best][rekt lost funds] and on top of that call it a +security enhancing Bitcoin wallet. We wanted to start a company around the +development of Revault, but we wouldn't get funding without providing some +reasonable assurance to an investor we could bring a safe product to market. And +we wouldn't be able to solve all these engineering problems without funding. + +[Enters miniscript][sipa miniscript], "a language for writing (a subset of) +Bitcoin Scripts in a structured way, enabling analysis, composition, generic +signing and more. [...] It has a structure that allows composition. It is very +easy to statically analyze for various properties (spending conditions, +correctness, security properties, malleability, ...)." This is exactly what we +needed. Armed with this powerful tool, we could give better guarantees [0] to +our investors, raise funds, and start the development of Revault. + +At the time, miniscript was still far from being a turnkey solution for any +Bitcoin application developer to use. (If you are a new Bitcoin dev reading this +after the year 2023, yes, there was a time where we used to write Bitcoin +scripts BY HAND.) We had to integrate miniscript in Bitcoin Core (see PRs +[#24147][Bitcoin Core #24147], [#24148][Bitcoin Core #24148] and +[#24149][Bitcoin Core #24149]), which we used as the backend of the Revault +wallet, and convince signing devices manufacturers to implement it in their +firmware. The latter part would turn out to be the most difficult. + +It was a chicken-and-egg problem: incentives were low for manufacturers to +implement miniscript with no demand from users. And we couldn't release Revault +without signing device support. Fortunately this cycle was eventually broken by +[Stepan Snigirev][] in March 2021 by [bringing][github embit descriptors] +[support][github specter descriptors] for miniscript descriptors to the [Specter +DIY][]. The Specter DIY was however for a long time disclaimed as being merely a +"functional prototype", and [Salvatore Ingala][] brought [miniscript to a +production-ready signing device][ledger miniscript blog] for the first time in 2022 with the [new +Bitcoin app][ledger bitcoin app] for the Ledger Nano S(+). The app was released +in January 2023, allowing us to publish the [Liana wallet][] with support for +the most popular signing device. + +One last development is left to wrap up our miniscript journey. [Liana][github +liana] is a Bitcoin wallet focused on recovery options. It lets one specify some +timelocked recovery conditions (for instance a third-party [recovery key that +cannot normally spend the funds][blog liana 0.2 recovery], or a +[decaying/expanding multisig][blog liana 0.2 decaying]). Miniscript was +initially only available for P2WSH scripts. Almost 2 years after [taproot][topic +taproot] activated, it's unfortunate that you would have to publish your +recovery spending paths onchain every time you spend. To this end, we have been +working to port miniscript to tapscript (see [here][github minitapscript] and +[here][Bitcoin Core #27255]). + +The future is bright. With most signing devices either having implemented or in +the process of implementing miniscript support (for instance recently +[Bitbox][github bitbox v9.15.0] and [Coldcard][github coldcard 227]), along with +[taproot and miniscript native frameworks][github bdk] being polished, +contracting on Bitcoin with safe primitives is more accessible than ever. + +It's interesting to note how the funding of Open Source tools and frameworks +lower the barrier to entry for innovative companies to compete and, more +generally, projects to be implemented. This trend accelerating in the past years +can make us hopeful about the future of the space. + +[0] There was still risk, of course. But at least we were confident we could get +past the onchain part. The offchain one would prove to be (as expected) more +challenging. + +{% include references.md %} +{% include linkers/issues.md v=2 issues="24147,24148,24149,27255" %} +[Antoine Poinsot]: https://twitter.com/darosior +[Wizardsardine]: https://wizardsardine.com/ +[Revault]: https://wizardsardine.com/revault +[rekt lost funds]: https://rekt.news/leaderboard/ +[sipa miniscript]: https://bitcoin.sipa.be/miniscript +[Stepan Snigirev]: https://github.com/stepansnigirev +[github embit descriptors]: https://github.com/diybitcoinhardware/embit/pull/4 +[github specter descriptors]: https://github.com/cryptoadvance/specter-diy/pull/133 +[Specter DIY]: https://github.com/cryptoadvance/specter-diy +[Salvatore Ingala]: https://github.com/bigspider +[ledger miniscript blog]: https://www.ledger.com/blog/miniscript-is-coming +[ledger bitcoin app]: https://github.com/LedgerHQ/app-bitcoin-new +[Liana wallet]: https://wizardsardine.com/liana/ +[github liana]: https://github.com/wizardsardine/liana +[blog liana 0.2 recovery]: https://wizardsardine.com/blog/liana-0.2-release/#trust-distributed-safety-net +[blog liana 0.2 decaying]: https://wizardsardine.com/blog/liana-0.2-release/#decaying-multisig +[github minitapscript]: https://github.com/sipa/miniscript/pull/134 +[github bitbox v9.15.0]: https://github.com/digitalbitbox/bitbox02-firmware/releases/tag/firmware%2Fv9.15.0 +[github coldcard 227]: https://github.com/Coldcard/firmware/pull/227 +[github bdk]: https://github.com/bitcoindevkit/ diff --git a/_includes/articles/zh/bitgo-musig2.md b/_includes/articles/zh/bitgo-musig2.md new file mode 100644 index 0000000000..6938c91b85 --- /dev/null +++ b/_includes/articles/zh/bitgo-musig2.md @@ -0,0 +1,77 @@ +{:.post-meta} +*作者：[Brandon Black][]，来自 [BitGo][]* + +第一篇[MuSig 论文][MuSig paper]出版于 2018 年，而且 [MuSig][topic musig] 在比特币上的潜能，正是用来让 taproot 软分叉获得支持的卖点之一。对 MuSig 的开发延续了下来，[MuSig-DN][] 和 [MuSig2][] 的论文在 2020 年出版。到 2021 年， taproot 在比特币主网上临近激活的时候，对 MuSig 签名即将到来的兴奋之情是真实可感的。在 BitGo，我们期待能趁着 taproot 的激活发布一款 MuSig taproot 钱包；但是当时的规范、测试节点和参考实现都是不完整的。于是，BitGo 只能先[发布][bitgo blog taproot]第一款基于 tapscript 的多签名钱包，并在主网上发起了[第一笔 tapscript 多签名交易][first tapscript multisig transaction]。接近两年以后，MuSig2 在 [BIP327][] 中得到规范，我们就[发布][bitgo blog musig2]了第一款 MuSig taproot 多签名钱包。 + +{{include.extrah}}## 为什么要使用 MuSig2？ + +{{include.extrah}}### 与脚本式多签名相比 + +相比于脚本式的多签名构造，MuSig 有两大长处。第一点，也是最明显的一点，其交易体积更小（因此矿工手续费更少）。链上的一个签名是 64 ~ 73 字节，换算过来是 16 ~ 18.25 虚拟字节（vB），而 MuSig 可以将两个（甚至更多）签名合并为一个签名。在 BitGo 的 2-of-3 多签名钱包中，使用 MuSig 密钥路径的一个输入只需 57.5 vB，而一个原生的隔离见证输入需要 104.5 vB、使用深度为 1 的脚本路径的 [tapscript][topic tapscript] 输入需要 107.5 vB。第二个好处是，MuSig 也提升了隐私性。在联合持有的输出上使用 MuSig 密钥路径时，这样的合作式花费无法被第三方区块链观察者辨别出跟单签名 taproot 花费有何区别。 + +当然，MuSig2 也有一些缺点。两种重要的缺点都围绕着签名使用需要用到的 [nonce 值](#nonce确定性的和随机的)。不像普通的 ECDSA（椭圆曲线数字签名算法）和 [schnorr 签名][topic schnorr signatures]，MuSig2 的签名者无法一贯地使用确定性的 nonce 值。这种缺点，使得保证高质量的 nonce 和避免 nonce 复用变得更加困难。MuSig2 在大部分情况下要求 2 轮通信。有些时候，第一轮可以预先计算出来，但必须谨慎进行。 + +{{include.extrah}}### 与其它 MPC 协议相比 + +因为上面提到的手续费和隐私性上的好处，“MPC（多方计算）” 签名协议越来越受欢迎。MuSig 是一种 *简单* 的多签名协议（只支持 n-of-n 模式），是因为 schnorr 签名的线性可加特性而成为可能的。MuSig2 可以用一场 30 分钟的演讲解释清楚，而完整的参考实现是 461 行的 Python 代码。[门限签名][topic threshold signature]（t-of-n）协议，例如 [FROST][]，会复杂很多；甚至基于 ECDSA 的[两方的多签名][2-party multi-signatures]，也要依赖于 Paillier 加密算法和其它技术。 + +{{include.extrah}}## 脚本类型的选择 + +即使在 [taproot][topic taproot] 激活以前，为一个多签名（t-of-n）钱包选择一种具体的脚本，也是难事。Taproot 因为有了多种花费路径，让这个问题变得更加复杂；而 MuSig 本身甚至提供了更多选项。在我们开始设计 BitGo 的 taproot MuSig2 钱包时，我们考虑了以下事项： + +- 我们使用固定的公钥顺序，而不对公钥使用字典排序。每一个签名密钥都有跟公钥一起储存的特定角色，所以每次都以相同的顺序使用这些公钥会更简单，而且更容易预测。 +- 我们的 MuSig 密钥路径仅包含最常用的签名人组合，“用户”/“bitgo”。将 “后备” 签名密钥包含在 MuSig 密钥路径中，将极大地减少可以使用密钥路径的概率。 +- 我们不在 Taptree（脚本树）上包含 “用户”/“bitgo” 签名组合。这是我们的第二种 taproot 脚本类型；第一种类型包含了 3 个 tapscript 的设计，需要脚本式签名功能的用户可以使用第一种类型。 +- 在 tapscript 中，我们不会使用 MuSig 密钥。我们的钱包包含了一个 “后备” 密钥，这个密钥被假设是难以访问的、而且会使用我们控制之外的软件来签名，所以预期这个后备密钥能够依照 MuSig 协议来签名是不现实的。 +- 在 tapscript 中，我们选择了 `OP_CHECKSIG`/`OP_CHECKSIGVERIFY` 而不是 `OP_CHECKSIGADD`。在构造交易的时候，我们知道哪一把密钥会签名，而 2-of-2 的、深度为 1 的脚本，会比 2-of-3 的、深度为 0 的脚本稍微便宜一些。 + +所以，最终的结构是这样的： + +{:.center} +![BitGo's MuSig taproot structure](/img/posts/bitgo-musig/musig-taproot-tree.png) + +{{include.extrah}}## Nonce（确定性的和随机的） + +椭圆曲线数字签名是在一个一次性秘密值（叫做 “nonce”，意思是只用一次的数字）的帮助下制作出来的。通过在签名中分享 nonce 公开值（nonce 公开值和 nonce 秘密值的关系，就像公钥与私钥的关系），验证者可以确认签名等式成立，而无需签名人揭晓自己长期使用的私钥。为了保护这个长期使用的私钥，同一个私钥（或者有关联的私钥）在签名不同的消息时绝不能使用相同的 nonce 值（nonce 不能复用）。对单签名来说，最常被推荐的避免 nonce 复用的方法就是 [RFC6979][]：确定性的 nonce 生成法。完全随机的数值也是安全的，只要它一经使用就立即被丢弃的话。但这些方法都不能直接为多签名协议所用。 + +为了在 MuSig 中安全地使用确定性 nonce 值，在 MuSig-DN 这样的技术中，必须证明所有的参与者都正确地生成了确定性 nonce 值。没有这样的证据，恶意的签名人就可以为同一条消息发起两个签名会话，然后提供不一样的 nonce 值。另一个生成确定性 nonce 值的签名人会使用相同的 nonce 值为两条实质上不同的信息生成两个碎片签名，最终导致私钥泄露给恶意签名人。 + +在 MuSig2 规范的开发期间，[Dawid][] 和我意识到，*最后一个* 贡献 nonce 值的签名人可以确定性地生成自己的 nonce 值。我跟 [Jonas Nick][] 讨论了这一点，他于是将此形式化、成为规范。在 BitGo 的 MuSig2 实现中，这种确定性的签名模式用在了我们 HSM（硬件签名模块）中，以使这些硬件可以无状态地（statelessly）执行 MuSig2 签名。 + +在多轮签名协议中使用随机 nonce 值时，签名人必须考虑这些 nonce 秘密值在轮次之间如何存储。在单签名中，nonce 秘密值在创建它的同一个执行步骤中就可以删除。如果一个攻击者可以在 nonce 值创建之后、来自其它签名器的 nonce 值到来之前立即克隆一个签名器的状态，这个签名器就可以被诱骗为实质上不同的多条消息使用同一个 nonce 值生成多个签名。因此，我们建议签名人仔细考虑自己的初始状态是否可被访问、nonce 秘密值具体在什么时候会被删除。在 BitGo 用户使用 BitGo SDK 运行 MuSig2 流程时，nonce 秘密值是使用 [MuSig-JS][] 库来保存的，并且，一旦为了签名而访问它们，就会导致它们被删除。 + +{{include.extrah}}## 形成规范的流程 + +我们在 BitGo 实现 MuSig2 的经验表明，在比特币生态里工作的公司和个人应该花时间来审核自己意图实现（甚至只是期待会出现）的东西的规范，并为这样的规范的开发作出贡献。在我们第一次审核 MuSig2 规范的草稿、并开始学习如何最好地将它整合进我们的签名系统时，为了将带状态的签名引入我们的 HSM，我们考虑过许多困难的方法。 + +幸运的是，在我向 Dawid 介绍了其中的挑战之后，他很确信有一种办法可以使用确定性的 nonce 值，而且我们最终得出了其中一个签名人可以使用确定性 nonce 值的粗糙想法。后来，我又向 Jonas 提起了这个想法，并解释了我们尝试启用的具体应用场景，他意识到了其中的价值，将它融合进了规范。 + +现在，其它的 MuSig2 实现也可以利用这样的灵活性：其中一位签名人无需管理状态。在开发过程中，通过审核（以及实现）MuSig2 规范的草稿，我们成功为规范作出了贡献，并且在这份规范作为 BIP327 正式发布之后，很快我们的 MuSig2 签名就整装待发了。 + +{{include.extrah}}## MuSig 与 PSBT + +[PSBT（部分签名的比特币交易）][topic psbt] 格式意在携带让各方（比如：签名人和协调人）可以签名一笔交易所需的所有信息。签名所需的信息越多，这种格式的价值就越大。我们试验了 使用额外的字段扩展我们现有的 API 格式以协助 MuSig2 签名 vs. 转化成 PSBT 的成本和好处。最终我们将需要交换的交易数据转化成 PSBT 格式，而且获得了巨大的成功。尚不为许多人所知的是，BitGo 钱包现在可以跟支持 PSBT 的硬件签名设备集成（除了使用 MuSig2 的 BitGo 钱包，详见下一段）。 + +但现在还没有公开为 MuSig2 签名而设的 PSBT 字段。在我们的实现中，我们基于 [Sanket][] 分享给我们的一份草案，用上了专门的字段。这是一个很少被提起的 PSBT 格式的好处 —— 你可以在同一种二进制格式中额外加入定制化的交易构造或者签名协议所需的 *无论什么* 数据；因为全局的、每个输入、每个输出的部分已经得到定义。PSBT 规范将未签名的交易跟脚本、签名以及其它最终形成一笔完整的交易所需的数据分离开来。这种分离可以在签名流程中提升通信的效率。举个例子，我们的 HSM 可以拿仅包含自己的 nonce 值和签名的最小 PSBT 作为响应，而这个 PSBT 可以很容易地组合成预签名的 PSBT。 + +{{include.extrah}}## 致谢 + +感谢在 Blockstream 工作的 Jonas Nick 和 Sanket Kanjalkar、在 Fedi 工作的 Dawid Ciężarkiewicz，以及在 BitGo 团队的 [Saravanan Mani][]、David Kaplan，和其他人。 + +{% include references.md %} +[Brandon Black]: https://twitter.com/reardencode +[BitGo]: https://www.bitgo.com/ +[MuSig paper]: https://eprint.iacr.org/2018/068 +[MuSig-DN]: https://eprint.iacr.org/2020/1057 +[MuSig2]: https://eprint.iacr.org/2020/1261 +[bitgo blog taproot]: https://blog.bitgo.com/taproot-support-for-bitgo-wallets-9ed97f412460 +[first tapscript multisig transaction]: https://mempool.space/tx/905ecdf95a84804b192f4dc221cfed4d77959b81ed66013a7e41a6e61e7ed530 +[bitgo blog musig2]: https://blog.bitgo.com/save-fees-with-musig2-at-bitgo-3248d690f573 +[FROST]: https://datatracker.ietf.org/doc/draft-irtf-cfrg-frost/ +[2-party multi-signatures]: https://duo.com/labs/tech-notes/2p-ecdsa-explained +[RFC6979]: https://datatracker.ietf.org/doc/html/rfc6979 +[Dawid]: https://twitter.com/dpc_pw +[Jonas Nick]: https://twitter.com/n1ckler +[MuSig-JS]: https://github.com/brandonblack/musig-js +[Sanket]: https://twitter.com/sanket1729 +[Saravanan Mani]: https://twitter.com/saravananmani_ diff --git a/_includes/articles/zh/cardcoins-rbf-batching.md b/_includes/articles/zh/cardcoins-rbf-batching.md new file mode 100644 index 0000000000..d1676f7a53 --- /dev/null +++ b/_includes/articles/zh/cardcoins-rbf-batching.md @@ -0,0 +1,22 @@ +{:.post-meta} +*作者：[CardCoins][]* + +_“批量添加”是一种在内存池中将额外输出添加到未确认交易的方案。本文汇报了 [CardCoins][] 在其客户提现流程中引入该方案的再组织（reorg）与 DoS 安全实现所做出的努力。_ + +[Replace By Fee][topic rbf]（RBF，BIP125）与[批量支付][payment batching]是与比特币内存池直接交互的企业不可或缺的两种工具。无论手续费上涨还是下跌，企业始终需要在手续费效率方面不断努力。 + +每种工具都十分强大，但也各有复杂性与细微之处。例如，为客户提现进行批量支付可能能为企业节省手续费，但也会让需要加速交易的客户通过 [CPFP][topic cpfp] 的方式变得不划算。同样，RBF 对于采用“低费率初始广播、逐步提高费率”策略的企业很有用，但它会让客户在看到自己的提现交易在钱包里更新时[可能产生混淆][rbf blog]。此外，如果客户想在此交易依然未确认的情况下花费它，那么企业在尝试替换其父交易时就必须承担这笔子交易的费用。更糟糕的是，客户在另一个服务那里收到的这笔提现交易可能被对方[固定][pinning]。 + +将这两种工具结合使用时，服务提供商会获得新功能，但也会面临新的复杂性。在最基本的场景下，将 RBF 与单一、固定的批量支付结合，其复杂性仅是二者分别存在的复杂性的简单叠加。然而，当你把 RBF 与“additive batching” 组合时，就会出现某些边缘案例与危险的故障情形。 + +在 “additive RBF batching” 场景下，服务提供商会在交易仍处于内存池且尚未确认时，引入新的输出（以及已确认的输入），从而把新的客户提现纳入这笔交易。这使得服务提供商能为用户带来近乎即时提现的体验，同时保留通过批量处理大量客户提现所带来的大部分手续费节省。当每位客户请求提现时，就会向内存池中的交易添加一个输出。直到该交易被确认或到达其他本地最优状态前，它都会继续被更新。 + +针对这种 “additive RBF batching”，可能存在多种策略。在 [CardCoins][]，我们采用了安全优先的方式实现（并得到了 [Matthew Zipkin][] 的协助），并在博客文章 [RBF Batching at CardCoins: Diving into the Mempool's Dark Reorg Forest][cardcoins rbf blog] 中对此实现细节进行了介绍。 + +{% include references.md %} +[CardCoins]: https://www.cardcoins.co/ +[payment batching]: /zh/payment-batching/ +[rbf blog]: /zh/rbf-in-the-wild/#一些可用性示例 +[pinning]: /en/topics/transaction-pinning/ +[Matthew Zipkin]: https://twitter.com/MatthewZipkin +[cardcoins rbf blog]: https://blog.cardcoins.co/rbf-batching-at-cardcoins-diving-into-the-mempool-s-dark-reorg-forest diff --git a/_includes/articles/zh/dong-btse-operation.md b/_includes/articles/zh/dong-btse-operation.md new file mode 100644 index 0000000000..87e8a02fbc --- /dev/null +++ b/_includes/articles/zh/dong-btse-operation.md @@ -0,0 +1,15 @@ +{:.post-meta} +*by [Carl Dong](https://twitter.com/carl_dong)
Optech 工程师* + +[BTSE](https://www.btse.com/en/home) 使用 Segwit、BIP32 分层确定性（HD）钱包和多重签名密钥管理来减少运营负担并提高资金安全性。在本次 Optech 实地报告中，我们采访了 BTSE 的员工，了解这些比特币技术如何为其交易所运营带来收益。 + +BIP32 是一个被广泛实施的[标准][BIP32]，它描述了如何[从一个扩展公钥](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Unsecure_money_receiver_NmisubHsub0)确定性地派生任意多个新的公钥，即使相应的私钥保持离线状态。如果没有 BIP32，安全存储私钥的负担将促使重复使用公钥和地址，从而导致[问题](https://en.bitcoin.it/wiki/Address_reuse)，包括交易所的抢先交易以及用户隐私的丧失。谈到用户冷钱包存款的运营优势时，BTSE 的首席执行官 Jonathan Leong 提到，“如果热钱包的密钥被泄露，所有用户的地址都必须重新生成，并且不可避免地会有一些用户继续向他们的旧地址发送资金。” + +尽管使用 BIP32 的交易所可以将其私钥保持离线，但该私钥仍是一个单点故障的风险。幸运的是，通过使用 k-of-n 多重签名地址（每个 n 公钥均来自不同的扩展公钥派生），交易所可以减轻单一密钥被泄露的影响。BTSE 通过这种组合实现了无需接触私钥即可动态生成任意数量的地址，这些地址直接存入多重签名的冷钱包。 + +除了 BIP32 和多重签名，BTSE 还使用 [P2SH-P2WSH](https://bitcoincore.org/en/segwit_wallet_dev/#complex-script-support)（P2SH 包裹的 Segwit）作为他们的存款地址。Segwit 允许 BTSE 通过减少交易的权重来降低交易费用，例如将资金转移到热钱包或 UTXO 合并时。作为一个例子，从 P2SH-P2WSH 的 2-of-3 多重签名地址花费资金比从传统的 P2SH 地址花费[节省 44% 的费用](https://en.bitcoin.it/wiki/Techniques_to_reduce_transaction_fees#P2SH-wrapped_segwit)。随着向原生 Segwit P2WSH 地址的发送支持逐步增加（可在 Optech 的[兼容性矩阵][compatibility matrix]中追踪），企业也应考虑使用这些地址来进行存款，以解锁额外 14% 的节省并为他们的多重签名脚本提高安全性（256 位而非 160 位）。您可以在我们的 [Bech32 发送支持系列][bech32 series]中了解采用速度、地址安全性及更多内容。 + +Segwit、BIP32 和多重签名相互协作，帮助 BTSE 在运营一个安全、易用且低费用的交易所时减少负担。Optech 鼓励新的交易所在设计基础设施时考虑这些技术。对于现有的交易所，正如之前的实地报告所提到的，考虑采用这些技术并减少技术债务的好时机是在您进行 UTXO 合并时。 + +{% include references.md %} +[bech32 series]: /zh/bech32-sending-support/ \ No newline at end of file diff --git a/_includes/articles/zh/payment-batching.md b/_includes/articles/zh/payment-batching.md new file mode 100644 index 0000000000..70adec10bd --- /dev/null +++ b/_includes/articles/zh/payment-batching.md @@ -0,0 +1,122 @@ +{:.post-meta} + +本文介绍了高频支付用户如何利用*批量添加*这一扩容技术，在实际使用情形下，将交易手续费与区块空间占用减少约 75%。 +截至 2021 年 1 月，已有多家主流比特币服务（主要是交易所）在使用批量添加，许多钱包（包括 Bitcoin Core）也将其作为内置功能提供，定制钱包或支付发送解决方案中实现这一功能也应当十分容易。不过需要注意的是，这项技术可能会在一段时间内导致收款人看到的行为与预期不符，并且会影响手续费提升（fee bump），同时也可能降低隐私性。 + +## 每位收款人的交易体积 + +如果使用 P2WPKH 输入和输出的一笔典型比特币交易包含来自付款方的 1 个输入（约 67 vbytes），以及 2 个输出（各约 31 vbytes，分别支付给收款人和找零支付给付款方），还需要 额外的 11 vbytes 用于交易头部字段（version、locktime 以及其他字段）。 + +![针对 P2WPKH 的最佳情形：每笔支付对应的 vbytes](/img/posts/payment-batching/p2wpkh-batching-best-case.png) + +若添加 4 个收款人，每位收款人需额外增加 1 个 31 vbytes 的输出，交易的总体大小将变为 264 vbytes。之前的交易消耗全部 140 vbytes 来支付给 1 位收款人，而现在合并后的交易则只有约 53 vbytes 用于每位收款人，相比之下省下了大约 60% 的空间占用。 + +在此最佳情形之下继续推算可见，随着支付收款人数量的增多，每位收款人的平均 vbytes 数值会逐渐接近单个输出大小，其最高可带来的节省率略高于 75%。 + +![批量添加的最佳情形与常见情形的节省率](/img/posts/payment-batching/p2wpkh-batching-cases-combined.png) + +在现实情况下，随着交易金额的增大，往往需要更多的输入。这并不会削弱批量添加的实用性，但会在一定程度上降低它的效率。举例来说，一些服务的收款金额与其发送给客户的金额相近，那么平均而言，服务每新加 1 个输出就需要额外增加 1 个输入。这样其最高节省率约为 30%。 + +如果某项服务发现自己在大多数交易中都要使用多个输入，那么可以通过两步流程来提升节省率：第一步使用费率较低但耗时较长的交易将多个小额输入整合为一个大额输入（资金依旧归属服务方）；第二步则利用合并好的大额输入进行批量添加，以实现如上所述的最佳效率。 + +如果我们假设用于整合输入的交易只需支付常规交易 20% 的手续费率，并且每次可以整合 100 个输入，那么我们就可以推算在之前“1 个输入对应 1 个输出”这一场景下，采用两步流程会带来怎样的节省，并可将其与已经拥有大额输入（最佳情形）做对比。 + +![对比经过整合后的批量添加在最佳情形与常见情形下的节省率](/img/posts/payment-batching/p2wpkh-batching-after-consolidation.png) + +在这个常见情形中，如果只发送一笔支付，整合操作的效率会变低；但若合并发送多笔支付，其效果几乎能与最佳情形相当。 + +在直接提供手续费节省的同时，批量添加还通过减少每笔支付占用的 vbytes 来提升对区块空间的利用效率。这有助于提升单位时间内可处理的支付笔数，从而在需求恒定时降低用户发送比特币交易的成本。因此，更多地采用批量添加，有望让所有比特币用户的手续费率都变得更为低廉。 + +综上所述，当服务通常有 5～20 倍于单笔 typical output 的大额输入可用时，批量添加能提供显著的手续费节省；若不满足这一条件，仅仅依靠 batching 带来的节省可能有限，但仍值得尝试。如果服务愿意事先整合自己的输入，则[节省率会非常可观][veriphi field report]。 + +注意：上述图表都基于 P2WPKH 输入与输出的假设。我们预计这一脚本类型会在未来（在出现[更优技术][topic taproot]之前）成为网络主流。不过，如果使用其他脚本类型（P2PKH，或者通过 P2SH 或 P2WSH 承载的多签），花费它们的 vbytes 更大，因此 batching 所实现的节省率也会更高。 + +## 注意事项 + +在享受批量添加带来的手续费降低的同时，也需要平衡并解决该技术本身带来的以下问题。 + +### 延迟 + +这是批量添加最大的问题所在。尽管部分情形能自然适配（如矿池在自己挖到的区块中一次性支付给算力提供者），但在许多情况下，用户需要接受：他们的支付并不会立即广播，而是被延后到一定时间后再与其他提现请求合并进行发送。 + +用户会注意到这一延迟：在你将他们的支付纳入批量交易并广播之前，他们的钱包不会出现任何未确认交易提示。此外，延迟广播交易也意味着交易得到确认的时间会顺延（若其他条件相同，如手续费率一致）。 + +为缓解这一问题，可以让用户在“即时广播”与“延期广播”两种选项中进行选择，并为每个选项提供不同的费用，例如： + + [X] 免费提现（在 6 小时内发送交易） + [ ] 立即提现（提现费 0.123 mBTC） + +### 隐私性降低 + +批量添加的另一个问题在于它可能让用户感到隐私性降低。所有与他们同在一笔交易中的收款人都能大概率推断出，交易中的其他接收输出也都是来自同一家支付方。如果这些付款被拆分为多笔交易，彼此之间的链上关联可能会更难判定，甚至不存在关联性。 + +![某笔批量交易在区块浏览器中的截图示例](/img/posts/payment-batching/batch-screenshot.png) + +需要注意的是，对于部分比特币服务来说，其交易往往在专家眼中可被识别，就算不使用批量添加也如此，因此对这类用户来说，批量支付并不一定会带来更大的隐私损失。 + +或许可以结合 [Coinjoin][topic coinjoin] 机制，通过与他人共建交易的方式来部分缓解这一问题；在某些场景下，这样做不会削弱 batching 带来的效率，同时还能大大提升隐私。然而，一些服务商之前提供的 Coinjoin 功能实现过于简单，被发现存在[缺陷][coinjoin sudoku]，结果并未真正提高隐私。截至 2021 年 1 月，尚未有任何现有的 Coinjoin 实现完全兼容此类批量支付的需求。 + +### 可能无法手续费提升 + +最后一个问题在于，batched 交易可能无法进行手续费提升。比特币核心节点（Bitcoin Core）会针对传播的交易设置一些限制，以防止攻击者滥用节点资源（带宽、CPU 等）。单独来看，你不会轻易碰到这些限制，但是收款人可能会在交易尚未确认时花费他们收到的输出，从而产生新的子交易，并一并加入到包含你交易的交易组中。 + +在 Bitcoin Core 0.20（2020 年 6 月）中，针对相关交易组的限制是[^package-limits]：一组关联的未确认交易的总大小不可超过 101,000 vbytes，未确认祖先数量不可超过 25，后代数量也不可超过 25。对于一次性包含大量收款人的批量交易，如果收款人纷纷花费其未确认输出，可能很容易触达这一后代限制。 + +当交易组越逼近这些限制时，要使用 [Child-Pays-for-Parent (CPFP)][topic cpfp] 或 [Replace-by-Fee (RBF)][topic rbf] 来给交易提高手续费便越困难。此外，若交易带有更多的未确认子交易，那么采用 RBF 提升手续费时就要额外为这些未确认子交易的可能性损失买单——矿工需要移除这组子交易以接受交易的替代版本。 + +这一问题并非批量支付所独有——分开的独立支付同样会遭遇类似情形。但差别在于，如果一笔独立支付因为收款人重花而导致无法手续费提升，只有该收款人受到影响；而若一个批量交易中的某一收款人花费了其输出并导致无法手续费提升，那么交易里其他所有收款人都会受到波及。如果他们知道你依赖这一提高手续费的能力，那么任何收款人都可以故意创建一些交易来让系统触达限制，从而实施[交易固定][topic transaction pinning]攻击。 + +## 实现方式 + +如果使用特定现有钱包（例如 Bitcoin Core 的 [sendmany][] RPC），实现批量添加非常容易。查看你所用软件的文档，寻找是否提供了发送多笔支付的功能接口。 + +```bash +bitcoin-cli sendmany "" '{ + "bc1q5c2d2ue7x38hcw2ugk5q7y4ae7nw4r6vxcptu8": 0.1, + "bc1qztjzd7hpf2xmngr7zkgkxsvdqcv2jpyfgwgtsv": 0.2, + "bc1qsul9emtnz0kks939egx2ssa6xnjpsvgwq9chrw": 0.3 +}' +``` + +如果在你自己的实现中使用，通常你已经在大部分场景下创建带有 2 个输出（收款人和找零）的交易，因此将更多收款人输出附加进去应该并不复杂。唯一需要注意的是，Bitcoin Core 节点（以及大多数其他节点）会拒绝接受或转发大小超过 100,000 vbytes 的交易，所以不应当尝试发送大于此限制的批量支付交易。 + +## 建议总结 + +1. 尽量让系统中的用户或客户不要期望马上广播交易，而是愿意等待一段时间（时间窗口越长越好）。 + +2. 使用低手续费率进行输入整合，并始终保持几个大额输入以便随时派发。 + +3. 在每个延迟窗口内，将所有待支付请求一次性发送到同一个交易中。例如，可以设置一个按小时执行的 [cronjob][]，将所有未决支付合并发送。理想情况下，之前的输入整合能保证此笔交易只需要一个输入。 + +4. 不要依赖能够对批量交易做手续费提升。这意味着应当在最初交易中就设置足以保证在预期时间内成功确认的手续费率。例如，可以使 用 Bitcoin Core 的 estimatesmartfee RPC 的 CONSERVATIVE 模式。 + +## 注释 + +[^package-limits]: + Optech 认为，几乎所有节点都采用 Bitcoin Core 对交易组限制的默认配置。不过，这些默认配置可能会随时间变化，所以下面的命令可用于检查当前限制以及对应的参数值。 + + ```text + $ bitcoind -help-debug | grep -A3 -- -limit + -limitancestorcount= + Do not accept transactions if number of in-mempool ancestors is or + more (default: 25) + + -limitancestorsize= + Do not accept transactions whose size with all in-mempool ancestors + exceeds kilobytes (default: 101) + + -limitdescendantcount= + Do not accept transactions if any ancestor would have or more + in-mempool descendants (default: 25) + + -limitdescendantsize= + Do not accept transactions if any ancestor would have more than + kilobytes of in-mempool descendants (default: 101). + ``` + +{% include references.md %} +[coinjoin sudoku]: http://www.coinjoinsudoku.com/ +[fee bumping]: ../1.fee_bumping/fee_bumping.md +[cronjob]: https://en.wikipedia.org/wiki/Cronjob +[sendmany]: https://bitcoincore.org/en/doc/0.17.0/rpc/wallet/sendmany/ +[veriphi field report]: /zh/veriphi-segwit-batching/ diff --git a/_includes/articles/zh/river-descriptors-psbt.md b/_includes/articles/zh/river-descriptors-psbt.md new file mode 100644 index 0000000000..cb0f92e104 --- /dev/null +++ b/_includes/articles/zh/river-descriptors-psbt.md @@ -0,0 +1,21 @@ +{:.post-meta} +*作者：[Philip Glazman][]，[River Financial][] 工程师* + +*River Financial 是一家专注于比特币金融服务的新兴金融机构。其旗舰产品——比特币经纪业务，为零售投资者提供了一个高接触的平台，方便他们买卖比特币。* + +River Financial 在其钱包软件中使用了两项技术：[部分签名的比特币交易（PSBT）][topic psbt] 和[输出脚本描述符][topic descriptors]。采用这些标准的决定使得 River 的钱包操作具有更大的灵活性和互操作性。 + +将 PSBT 引入钱包栈的决定受到了将密钥签名者视为接口这一理念的影响。PSBT 是由 Andrew Chow 编写的 [BIP174][] 中描述的签名者格式。在此标准之前，没有标准化格式来描述未签名交易。因此，每个签名者都使用特定于供应商的格式，这些格式无法互操作。通过遵循 PSBT 标准，钱包基础设施可以避免供应商锁定，减少签名者逻辑中的攻击面，并对钱包创建的交易有更好的保障。该标准还使得多重签名脚本更安全地使用，因此在操作成本没有显著增加的情况下，大大提高了安全性。 + +在钱包软件中实施输出脚本描述符的决定极大地减少了钱包操作的复杂性，并提高了功能集的灵活性。描述符是一种描述脚本的语言，由 Pieter Wuille 编写，并在 Bitcoin Core 中使用。在 River 的钱包软件中，描述符语言在从钱包创建到地址生成的多个环节得到了应用。在描述符之前，钱包之间没有互操作的方式来导入它们所使用的脚本的有用信息。通过使用脚本描述符，River 的钱包能够减少启动对脚本、地址或密钥集的监控所需的信息。每个钱包软件中的钱包都有一个关联的描述符，用于创建脚本。这带来了两个直接的好处： + +1. **钱包软件能够使用描述符监控冷钱包，并随后派生新地址。** 在我们的旗舰经纪产品中，River 的客户可以创建新的存款地址，将比特币直接存入安全的多重签名冷钱包中。 +2. **创建和导入新钱包非常容易，因为描述符语言可以定义所需的脚本。** River 可以管理许多具有不同脚本的钱包，从而为每个钱包制定独立的安全模型。对于冷钱包，使用 P2WSH 多重签名描述符，而对于热钱包（客户提现），使用 P2WPKH 描述符。独立的钱包使得 River 能够将热钱包中的比特币量保持在绝对最低水平（以降低风险），并更好地管理 UTXO 池以提供提现服务。 + +使用描述符和 PSBT 标准的决定迄今为止带来了显著的收益，因为它们提供了灵活性和互操作性。这一基础将有助于 River Financial 扩展其钱包基础设施。 + +{% include references.md %} +[Philip Glazman]: https://github.com/philipglazman +[River Financial]: https://river.com/ +[topic psbt]: /en/topics/psbt/ +[topic descriptors]: /en/topics/output-script-descriptors/ diff --git a/_includes/articles/zh/suredbits-enterprise-ln.md b/_includes/articles/zh/suredbits-enterprise-ln.md new file mode 100644 index 0000000000..68dd4551fb --- /dev/null +++ b/_includes/articles/zh/suredbits-enterprise-ln.md @@ -0,0 +1,25 @@ +{:.post-meta} +*作者：[Roman Taranchenko][]，[Suredbits][] 工程师* + +在第一次使用闪电网络发送支付，尤其是成功接收支付的兴奋过后，如何以安全可靠的方式操作你的节点是一个需要思考的问题。故障几乎总是出乎意料地发生。遇到可能的故障后如何恢复？如何让备份更加可靠？如何将种子保存在一个安全的地方？等等，等等…… + +在 [Suredbits][]，我们使用 Eclair 作为我们的节点软件。尽管 Eclair 本身已经相当稳健，我们仍采取了一些措施以进一步提高其可靠性——例如使用 PostgreSQL 作为数据库后端（[通过此 PR][db pr]），并使用 [AWS Secrets Manager][] 来存储私钥。 + +Eclair 内置了在线备份功能，但它需要手动设置和编写脚本来实现自动化，这在大规模操作中并不适用，而且容易出错。使用 AWS RDS 运行 PostgreSQL 使我们能够以一种 DevOps 工程师熟悉的方式来自动化备份和复制，并简化了数据库状态的恢复。 + +将 PostgreSQL 作为远程数据库后端使得实现节点故障切换更加简单，因为如果节点由于某种原因崩溃，就无需从备份中恢复数据库——你所需要做的只是将一个新的 Eclair 实例指向正确的数据库服务器。以下是一个使用两个 Eclair 实例加上 AWS 的 RDS、ELB 和 NAT Gateway 实现的自动故障切换的[快速演示][failover demo]。 + +在演示中所描述的故障切换场景中，我们需要一种安全的方式来允许 Eclair 实例之间共享其私钥种子。Eclair 将种子存储在本地文件系统中的一个文件里，这个文件应该被备份到某个地方，并在需要时恢复。目前的 Eclair 实现需要额外的步骤才能实现自动化。我们使用 AWS Secrets Manager——一个专门设计用于安全存储各种秘密信息（包括数据库密码和加密密钥）的加密键值存储。现在，只需在配置文件中将实例指向正确的密钥位置即可共享种子。一旦配置完成，实例就可以存储为 AMI 镜像，可以在无需手动配置的情况下根据需要多次重建。 + +我们采取的这些措施只是构建企业级闪电网络节点的第一步。仍然有一些问题需要解决。例如，哪些硬件安全模块（HSM）可以用于闪电网络节点，或者如何在多实例环境中实现 Bitcoin Core 节点的故障切换。但我们相信，我们的工作为扩展 Eclair 并使其更加容错奠定了坚实的基础。 + +有关此主题的更多信息，请参见我们的[演讲][enterprise ln vid]。 + +*免责声明：由于涉及私钥，在未进行彻底的风险评估前，请勿使用第三方云服务。* + +[Roman Taranchenko]: https://github.com/rorp +[Suredbits]: https://suredbits.com +[db pr]: https://github.com/ACINQ/eclair/pull/1249 +[AWS Secrets Manager]: https://github.com/rorp/eclair/tree/aws_secretsmanager +[failover demo]: https://youtu.be/L2DtolwS8ew +[enterprise ln vid]: https://www.youtube.com/watch?v=tbwy9mJIrZ \ No newline at end of file diff --git a/_includes/articles/zh/towns-xapo-consolidation.md b/_includes/articles/zh/towns-xapo-consolidation.md new file mode 100644 index 0000000000..42b5127fe3 --- /dev/null +++ b/_includes/articles/zh/towns-xapo-consolidation.md @@ -0,0 +1,39 @@ +{% comment %}{% endcomment %} + +正如在 [Newsletter #3][newsletter 3] 中提到的，过去几个月低交易费用的情况成为 UTXO 合并的极佳时机！合并是 [Xapo][Xapo] 为了准备下次费用像 2017 年最后几个月那样激增而进行的各种活动之一。 + +{% assign img1_label = "Plot of total Bitcoin UXTOs, January - July 2018" %} + +{:.center} +![{{img1_label}}](/img/posts/utxo-consolidation-2018.png)
+*{{img1_label}}, +source: [Statoshi](https://statoshi.info/dashboard/db/unspent-transaction-output-set?panelId=6&fullscreen&from=1514759562608&to=1532039707168)* + +[newsletter 3]: /zh/newsletters/2018/07/10/#仪表盘项 +[Xapo]: https://www.xapo.com/ + +UTXO 合并背后的思想本质上是这样的：当你的平均支出付款大于你的平均收入付款（或者当它们相同，但你正在批量支出付款）时，你通常需要合并许多 UTXO 以资助一个支出交易，这会增加你的交易大小，从而增加你支出的费用。通过提前合并 UTXO，你可以提前合并输入（inputs），让你更多地控制大部分费用发生的时间。如果你能在费用低时进行，这让你可以大幅减少这些成本。 + +例如，如果你将要在 100 s/B（satoshis per byte）的费率下花费 12 个 2-of-3 多签名输入，那么将会花费约360,000聪；而如果你事先在 2 s/B 的费率下合并这些输入，然后在 100 s/B 的费率下花费单一合并后的输入，两次交易的总成本只有约 41,000 聪：即在费用上节省 87%。而且如果费用没有上涨，风险并不大：如果费用一直维持在 2 s/B，如果你进行了整合，那么你会在两次交易中花费 7,900 聪，而如果你什么都不做，只进行一次交易，你将花费 7,200 聪。 + +合并还提供更新你用于 UTXO 的地址的机会，例如更换密钥、转换到多签名、或转换到 SegWit 或 bech32 地址。而且减少 UTXO 的数量使得运行一个全节点变得更加容易，从而边际性地提高了比特币的去中心化和总体安全性，这总是很好的。 + +当然，你真正不希望发生的一件事是你的合并交易以某种方式填满了区块链并立即导致费用开始上涨！有两个指标要观察以避免这种风险：一个是 [mempool][mempool] 是否已满（这会导致最低可接受费用上升），另一个是最近区块中有多少空间（这给出了矿工是否会以最低费用接受更多交易的指示）。过去几个月大多数时间这两个指标都非常有希望：mempool 经常接近空，意味着支付低至 1 s/B 的交易已被传播到矿工；许多区块没有被填满，意味着廉价的合并交易将会被合理快速地挖掘，而不是创造积压导致费用上升。 + +[mempool]: https://statoshi.info/dashboard/db/memory-pool?panelId=1&fullscreen&from=1509458400000&to=1531813659334&theme=dark + +我们实际进行合并的方法是有一个脚本，它会选择一组小型 UTXO 并创建一个以 1.01 s/B 的费率将它们支出到单个池地址的合并交易。该脚本逐渐将合并交易输入网络，因此它不会在 mempool 中引起太大的突增，更重要的是我们不会因为费用低和 mempool 已满而冒险让我们的交易被丢弃。当我们对这不会干扰我们的操作感到舒适时，以及在比特币网络总体上看来没有太大负载时，我们手动触发了这个过程。 + +总的来说，这个过程进行得相当好；我们今年通过这种方式减少了大约 [400 万个 UTXO][4 million UTXOs]，除了一些[担忧的][redditors1] [Reddit 用户][redditors2]，对整个网络的成本以及对我们的成本都非常小。 + +[4 million UTXOs]: https://www.oxt.me/entity/Xapo +[redditors1]: https://www.reddit.com/r/BitcoinDiscussion/comments/8ocyc9/massive_consolidation_currently_underway/ +[redditors2]: https://www.reddit.com/r/Bitcoin/comments/8p3y5b/does_xapo_spamming_the_blockchain/ + +{{include.hlevel | default: '##'}} 额外资源 + +- [减少交易费用的技术：合并](https://en.bitcoin.it/wiki/Techniques_to_reduce_transaction_fees#Consolidation) - Bitcoin Wiki +- [如何廉价地合并币以减少矿工费用](https://en.bitcoin.it/wiki/How_to_cheaply_consolidate_coins_to_reduce_miner_fees) - Bitcoin Wiki +- [关于使用合并和扇出的最佳实践有哪些？](https://bitgo.freshdesk.com/support/solutions/articles/27000044185-what-are-some-best-practices-regarding-the-usage-of-consolidations-and-fanouts-) - BitGo \ No newline at end of file diff --git a/_includes/articles/zh/veriphi-segwit-batching.md b/_includes/articles/zh/veriphi-segwit-batching.md new file mode 100644 index 0000000000..903c2351c7 --- /dev/null +++ b/_includes/articles/zh/veriphi-segwit-batching.md @@ -0,0 +1,30 @@ +{:.post-meta} +*作者：[Gustavo Flores Echaiz][]，[Veriphi][] 产品经理* + +手续费优化可以通过多种技术实现，从隔离见证、交易批处理、RBF（Replace By Fee）到手续费估算。对于后两种技术——RBF 和手续费估算——要精确计算节省的交易手续费是相当困难的，但由于隔离见证和批处理的改进是可测量的，因此可以将它们的收益建模到假设场景中。 + +在我们的报告中，我们想要对比目前的部分采用情况，模拟全网完全采用原生隔离见证（P2WPKH 或 P2WSH）和交易批处理的情况。我们希望确定可以节省的交易手续费总额，这一数据随时间的变化，以及其对区块空间和区块权重的影响。 + +我们对交易批处理的建模基于 David A. Harding 的[公式][harding batching formula]，用于检测交易是否花费了它在同一区块中收到的比特币。如果是这样，这些交易在理论上是可以进行批处理的，并且交易权重可以减小。在将所有潜在可批处理的交易合并后，我们将假设区块的大小与实际区块大小进行对比。从这里我们可以计算节省的字节数及其所代表的节省百分比。最后，如果我们取每个区块的大小，减去区块头和矿工的 coinbase 交易的大小，我们可以将节省的大小除以这个新数值。我们得到的百分比是完全采用情况下可能节省的手续费的近似值。我们用于分析数据和计算潜在节省的代码在[这里][veriphi batching repo]。 + +对于隔离见证，我们分析了从 2017 年 8 月 24 日隔离见证激活日（区块 481,825）到 2020 年 6 月 30 日（区块 637,090）的数据。我们的方法是遍历每笔交易的每个输入，如果该输入不是原生隔离见证，则计算它如果是原生隔离见证所节省的权重，这可以指示我们能够节省的手续费总量。最后，我们收集了每个区块的实际区块权重和区块手续费，并通过汇总每笔交易的结果收集了我们模型的潜在区块权重和潜在区块手续费。我们使用的代码库可以在[这里][veriphi segwit repo]找到。 + +__主要收获__ + +假设比特币价格为 9,250 美元（在报告发布时是正确的）： + +- 从 2012 年 1 月到 2020 年 6 月（区块 637,090），共支付了 211,000 BTC 的手续费给矿工，总金额约为 20 亿美元。 +- 在此期间的总节省量达到将近 58,000 BTC，金额约为 5.3 亿美元。这相当于交易手续费总额的约 27.36%。 +- 如果所有比特币用户都使用了交易批处理，他们可以节省超过 21,000 BTC，相当于节省 10% 或约 2 亿美元。 +- 从 2017 年 8 月 24 日到 2020 年 6 月 30 日，如果所有比特币用户都使用原生隔离见证（bech32），可以节省约 37,000 BTC，相比于实际支付的超过 97,000 BTC 的手续费，这相当于节省 38% 或约 3.4 亿美元。 +- 通过采用隔离见证和批处理等优化的手续费管理技术所带来的优势在高交易活动期间最为显著。在 8 年 6 个月的分析期间，大部分可能的节省都集中在几个关键月份内。 + +阅读[我们的完整报告][veriphi segwit batching full report]，了解手续费节省随时间的变化情况。 + +{% include references.md %} +[Gustavo Flores Echaiz]: https://twitter.com/GustavoJ_Flores +[Veriphi]: https://veriphi.io/ +[veriphi segwit batching full report]: https://veriphi.io/segwitbatchingcasestudy.pdf +[harding batching formula]: https://github.com/harding/ref-payment-batching +[veriphi batching repo]: https://github.com/Gfloresechaiz/ref-payment-batching +[veriphi segwit repo]: https://github.com/Gfloresechaiz/all_transactions_segwit diff --git a/_includes/articles/zh/wizardsardine-miniscript.md b/_includes/articles/zh/wizardsardine-miniscript.md new file mode 100644 index 0000000000..d883de2d36 --- /dev/null +++ b/_includes/articles/zh/wizardsardine-miniscript.md @@ -0,0 +1,50 @@ +{:.post-meta} +*by [Antoine Poinsot][] from [Wizardsardine][]* + +我们对 Miniscript 的（实际）兴趣始于2020年初，当时我们正在设计 [Revault][]，这是一种仅使用当时可用的脚本原语的多方（保险柜）[vault] [topic vaults] 架构。 + +在最初的演示用途中，Revault 总是使用一组固定的参与者。当我们试图将其推广到生产环境中的更多参与者时，我们很快遇到了问题。 + +- 实际上，我们 _确定_ 演示中使用的脚本是安全的吗？我们广告上的所有花费办法都一定能成功吗？除了广告上的办法，还有没有其他花费它的方法？ +- 即使是这样，我们如何将其推广到允许数量不等的参与者，并保持安全性？我们如何应用一些优化措施，并确保生成的脚本具有相同的语义？ +- 此外，Revault 使用预签名交易（以强制执行花费规则）。给定脚本的配置，我们如何提前知道为费用提升分配多少预算？我们如何确保使用这些脚本进行的 _任何_ 交易都能通过最常见的标准性检查？ +- 最后，即使我们假设我们的脚本与预期的语义相对应，并且始终可以花费，我们如何 _具体地_ 花费它们呢？就是说，我们如何为每一种可能的配置生成令人满意的见证（“签名”）？我们如何使硬件签名设备与我们的脚本兼容呢？ + +如果没有 Miniscript，这些问题本来可能成为绊脚石。两个在车库里的人不太可能编写出一款能够[即时创建某些脚本的软件、指望它可以取得最好的结果][rekt lost funds]并基于此称之为增强安全性的比特币钱包。我们想要围绕 Revault 的开发启动一家公司，但如果不能向投资者提供合理的保证，证明我们能够将安全的产品带到市场上，我们就无法获得资金支持。如果没有资金，我们也无法解决所有这些工程问题。 + +[进入 miniscript][sipa miniscript]，“这是一种用结构化方式编写比特币脚本（子集）的语言，使分析、组合、通用签名等功能成为可能[...]它具有允许组合的结构，非常容易静态分析，以验证各种属性(花费条件、正确性、安全属性、熔融性等)”。这正是我们所需要的。凭借这个强大的工具，我们可以为我们的投资者提供更好的保证[0]，筹集资金，并开始 Revault 的开发。 + +当时，miniscript 距离成为任何比特币应用程序开发人员可以使用的成套解决方案还很遥远。(如果你是 2023 年之后阅读这篇文章的新比特币开发人员，是的，曾经我们手动编写比特币脚本)。我们不得不将 miniscript 集成到 Bitcoin Core 中(见 PRs [#24147][Bitcoin Core #24147]、[#24148][Bitcoin Core #24148]和[#24149][Bitcoin Core #24149])，并将其用作 Revault 钱包的后端，且说服签名设备制造商在他们的固件中实现它。后半部分将是最困难的。 + +这是一个先有鸡还是先有蛋的问题：在没有用户需求的情况下，制造商实现 miniscript 的动机很低，并且我们无法在没有签名设备支持的情况下发布 Revault。幸运的是，这一循环最终在 2021 年 3 月被 [Stepan Snigirev][] 打破，他为 [Specter DIY][]带来[github embit descriptors]对 miniscript 描述符的[支持][github specter descriptors]。然而，Specter DIY 长时间被声明为仅仅是一个“功能原型”，是 [Salvatore Ingala][] 在 2022 年首次将 [miniscript 带到了生产就绪的签名设备上][ledger miniscript blog]，推出了适用于 Ledger Nano S（+）的[新比特币应用程序][ledger bitcoin app]。该应用程序于 2023 年 1 月发布，才使我们能够发布支持最流行签名设备的[Liana 钱包][Liana wallet]。 + +还剩下最后一个开发工作来结束我们的 Miniscript 旅程。[Liana][github liana] 是一个专注于钱包恢复选项的比特币钱包。它允许指定一些带时间锁的恢复条件 (例如第三方恢复密钥，它们[通常不能花费资金][blog liana 0.2 recovery]，或[衰减/扩张的多重签名][blog liana 0.2 decaying])。最初，Miniscript 仅适用于 P2WSH 脚本。但在 [taproot][topic taproot]激活两年后，每次花钱都必须在链上发布你的恢复花费路径是令人遗憾的。为此，我们一直在努力将 miniscript 移植到 tapscript 中(见[此处][github minitapscript]和[此处][Bitcoin Core #27255])。 + +未来是光明的。大多数签名设备已经实施或正在实施 miniscript 支持(例如最近的 [Bitbox][github bitbox v9.15.0] 和 [Coldcard][github coldcard 227])，加上 [taproot 和 miniscript 原生框架][github bdk]的完善，使用安全原语在比特币上签约比以往任何时候都更容易。 + +有趣的是，开源工具和框架的资金支持降低了创新公司竞争的门槛，更广泛地说，降低了要实施的项目的门槛。这种趋势在过去几年中加速发展，让我们对这个领域的未来充满希望。 + +[0] 当然，仍然存在风险。但至少我们有信心能够克服链上的部分。链下部分（正如预期的那样）将证明更具挑战性。 + +{% include references.md %} +{% include linkers/issues.md v=2 issues="24147,24148,24149,27255" %} +[Antoine Poinsot]: https://twitter.com/darosior +[Wizardsardine]: https://wizardsardine.com/ +[Revault]: https://wizardsardine.com/revault +[rekt lost funds]: https://rekt.news/leaderboard/ +[sipa miniscript]: https://bitcoin.sipa.be/miniscript +[Stepan Snigirev]: https://github.com/stepansnigirev +[github embit descriptors]: https://github.com/diybitcoinhardware/embit/pull/4 +[github specter descriptors]: https://github.com/cryptoadvance/specter-diy/pull/133 +[Specter DIY]: https://github.com/cryptoadvance/specter-diy +[Salvatore Ingala]: https://github.com/bigspider +[ledger miniscript blog]: https://www.ledger.com/blog/miniscript-is-coming +[ledger bitcoin app]: https://github.com/LedgerHQ/app-bitcoin-new +[Liana wallet]: https://wizardsardine.com/liana/ +[github liana]: https://github.com/wizardsardine/liana +[blog liana 0.2 recovery]: https://wizardsardine.com/blog/liana-0.2-release/#trust-distributed-safety-net +[blog liana 0.2 decaying]: https://wizardsardine.com/blog/liana-0.2-release/#decaying-multisig +[github minitapscript]: https://github.com/sipa/miniscript/pull/134 +[github bitbox v9.15.0]: https://github.com/digitalbitbox/bitbox02-firmware/releases/tag/firmware%2Fv9.15.0 +[github coldcard 227]: https://github.com/Coldcard/firmware/pull/227 +[github bdk]: https://github.com/bitcoindevkit/ diff --git a/_includes/functions/compat-cell.md b/_includes/functions/compat-cell.md deleted file mode 100644 index 9fd71ae870..0000000000 --- a/_includes/functions/compat-cell.md +++ /dev/null @@ -1,17 +0,0 @@ -{% capture /dev/null %} -{% assign cell_style = "default" %} -{% assign cell_label = "" %} -{% case include.state %} - {% when "true" %} - {% assign cell_style = "compat_yes" %} - {% assign cell_label = yes %} - {% when "false" %} - {% assign cell_style = "compat_no" %} - {% assign cell_label = no %} - {% when "na" %} - {% assign cell_label = "-" %} - {% when "untested" %} - {% assign cell_label = "?" %} - {% else %}{% include ERROR_43_unexpected_value %} -{% endcase %} -{% endcapture %}{{cell_label}} diff --git a/_includes/functions/compat-gallery.md b/_includes/functions/compat-gallery.md deleted file mode 100644 index 042bb9bcec..0000000000 --- a/_includes/functions/compat-gallery.md +++ /dev/null @@ -1,17 +0,0 @@ -*Click on a thumbnail for a larger image or to play its video.* - -{% for example in include.examples %} - {% capture /dev/null %} - {% if example.link %} - {% assign link = example.link %} - {% else %} - {% assign link = example.image %} - {% endif %} - {% endcapture %} -
-[![{{example.caption|escape_once}}]({{example.image}})]({{link}}) -
{{example.caption}} -
- {% assign break = forloop.index | modulo:2 %} - {% if break == 0 %}
{% endif %} -{% endfor %} diff --git a/_includes/functions/details-list.md b/_includes/functions/details-list.md index 3f0e84ceb3..155eb2975d 100644 --- a/_includes/functions/details-list.md +++ b/_includes/functions/details-list.md @@ -1,4 +1,5 @@ {% capture /dev/null %} + {% assign includes_size = include | size %} {% if includes_size >= 31 %}{% include ERROR143_too_many_params_passed_to_details_list %}{% endif %} + + + {% for param in include %} + {% assign parameter_name = param[0] | remove: '0' | remove: '1' | remove: '2' | remove: '3' | remove: '4' | remove: '5' | remove: '6' | remove: '7' | remove: '8' | remove: '9' %} + {% case parameter_name %} + {% when 'q' or 'a' or 'alink' %} + {% else %} + {% include ERROR12_unexpected_parameter_name %} + {% endcase %} + {% endfor %} {% endcapture %}
{% for i in (0..9) %} diff --git a/_includes/functions/get-mention-date.md b/_includes/functions/get-mention-date.md index f016674c33..b72906004f 100644 --- a/_includes/functions/get-mention-date.md +++ b/_includes/functions/get-mention-date.md @@ -1,9 +1,9 @@ -{% if mention.url contains "/en/newsletters" %} - {%- assign date = mention.url | remove_first: "/en/newsletters/" | slice: 0, 10 | replace: "/", "-" -%} -{%- else -%} - {%- if mention.date == nil -%} - {%- include ERROR_44_MISSING_DATE -%} +{%- if mention.date == nil -%} + {% if mention.url contains "/en/newsletters" %} + {%- assign date = mention.url | remove_first: "/en/newsletters/" | slice: 0, 10 | replace: "/", "-" -%} {%- else -%} - {%- assign date = mention.date -%} + {%- include ERROR_44_MISSING_DATE -%} {%- endif -%} +{%- else -%} + {%- assign date = mention.date -%} {%- endif -%} diff --git a/_includes/functions/matrix-cell-1-input.md b/_includes/functions/matrix-cell-1-input.md new file mode 100644 index 0000000000..b05cb47485 --- /dev/null +++ b/_includes/functions/matrix-cell-1-input.md @@ -0,0 +1,39 @@ +{% capture /dev/null %} + +{% if include.state == "Full Support (send & receive)" %} + {% assign cell_emoji = "✅" %} + {% assign cell_tooltip = "Full Support (send & receive)" %} +{% elsif include.state == "Send Support" %} + {% assign cell_emoji = "💸" %} + {% assign cell_tooltip = "Send Support" %} +{% elsif include.state == "No Support" %} + {% assign cell_emoji = "❌" %} + {% assign cell_tooltip = "No Support" %} +{% elsif include.state == "Unknown" %} + {% assign cell_emoji = "🤷" %} + {% assign cell_tooltip = "Unknown" %} +{% elsif include.state == "Not Applicable" %} + {% assign cell_emoji = "➖" %} + {% assign cell_tooltip = "Not Applicable" %} +{% elsif include.state == "Yes" %} + {% assign cell_emoji = "✅" %} + {% assign cell_tooltip = "Yes" %} +{% elsif include.state == "No" %} + {% assign cell_emoji = "❌" %} + {% assign cell_tooltip = "No" %} +{% elsif include.state | slice: 0, 1 == "V" %} + {% assign cell_emoji = include.state %} + {% assign cell_tooltip = include.state %} +{% elsif include.state | slice: 0, 1 == "P" %} + {% assign cell_emoji = include.state %} + {% assign cell_tooltip = include.state %} +{% endif %} + +{% endcapture %} + +
+ {{cell_emoji}} + {{cell_tooltip}} +
+ + diff --git a/_includes/functions/matrix-cell-4-input.md b/_includes/functions/matrix-cell-4-input.md new file mode 100644 index 0000000000..9f52690edf --- /dev/null +++ b/_includes/functions/matrix-cell-4-input.md @@ -0,0 +1,42 @@ +{% capture /dev/null %} + +{% assign cell_emoji = "❌" %} + +{% case include.input2 %} + {% when 'Full Support (send & receive)' %} + {% assign cell_emoji = "✅" %} + {% when 'Send Support' %} + {% assign cell_emoji = "💸" %} + {% when 'Unknown' %} + {% assign cell_emoji = "🤷" %} + {% when 'Not Applicable' %} + {% assign cell_emoji = "➖" %} +{% endcase %} + +{% if cell_emoji == "❌" %} + {% if include.input3 == "Full Support (send & receive)" or include.input3 == "Send Support" %} + {% assign cell_emoji = "✔" %} + {% endif %} +{% endif %} + +{% assign cell_tooltip = include.input %} +{% assign cell_tooltip2 = include.input2 %} +{% assign cell_tooltip3 = include.input3 %} +{% assign cell_tooltip4 = include.input4 %} + +{% endcapture %} + +
+ +{{cell_emoji}} + +{% if include.input3 == "Full Support (send & receive)" or include.input3 == "Send Support" %} + {% if cell_emoji == "✅" or cell_emoji == "💸" %} + ² + {% endif %} +{% endif %} + +{{cell_tooltip}}{{cell_tooltip2}}

Alternate - {{cell_tooltip3}} - {{cell_tooltip4}} +
+ + diff --git a/_includes/functions/matrix-cell-device.md b/_includes/functions/matrix-cell-device.md new file mode 100644 index 0000000000..a119201b31 --- /dev/null +++ b/_includes/functions/matrix-cell-device.md @@ -0,0 +1,29 @@ +{% capture /dev/null %} + + {% assign cell_emoji_original = include.state %} + + {% assign desktop_icon = "💻" %} + {% assign mobile_icon = "📱" %} + + {% assign cell_emoji = cell_emoji_original | replace: "Desktop", desktop_icon %} + {% assign cell_emoji = cell_emoji | replace: "Mobile", mobile_icon %} + {% assign cell_emoji = cell_emoji | replace: ",", "" %} + + {% if cell_emoji == "Not Applicable" %} + {% assign cell_emoji = "➖" %} + {% assign cell_emoji_original = "Not Applicable" %} + {% elsif include.state == "Unknown" %} + {% assign cell_emoji = "🤷" %} + {% assign cell_tooltip = "Unknown" %} + {% endif %} + + {% assign cell_tooltip = cell_emoji_original %} + +{% endcapture %} + +
+ {{cell_emoji}} + {{cell_tooltip}} +
+ + diff --git a/_includes/functions/matrix-cell-os.md b/_includes/functions/matrix-cell-os.md new file mode 100644 index 0000000000..eae1dac55c --- /dev/null +++ b/_includes/functions/matrix-cell-os.md @@ -0,0 +1,41 @@ +{% capture /dev/null %} + + {% assign cell_emoji_original = include.state %} + + + {% assign android_icon = "" %} + {% assign linux_icon = "" %} + {% assign windows_icon = "" %} + {% assign apple_icon = "" %} + + + {% assign cell_emoji = cell_emoji_original | replace: "Android", android_icon %} + {% assign cell_emoji = cell_emoji | replace: "Linux", linux_icon %} + {% assign cell_emoji = cell_emoji | replace: "Windows", windows_icon %} + + + {% assign cell_emoji = cell_emoji | replace: "iOS, OS", "OS" %} + {% assign cell_emoji = cell_emoji | replace: "iOS", apple_icon %} + {% assign cell_emoji = cell_emoji | replace: "OS", apple_icon %} + {% assign cell_emoji = cell_emoji | replace: ",", "" %} + + {% if cell_emoji == "Not Applicable" %} + {% assign cell_emoji = "➖" %} + {% assign cell_emoji_original = "Not Applicable" %} + {% elsif include.state == "Unknown" %} + {% assign cell_emoji = "🤷" %} + {% assign cell_tooltip = "Unknown" %} + {% endif %} + + {% assign cell_tooltip = cell_emoji_original %} + + + +{% endcapture %} + +
+ {{cell_emoji}} + {{cell_tooltip}} +
+ + diff --git a/_includes/functions/podcast-bullet.md b/_includes/functions/podcast-bullet.md new file mode 100644 index 0000000000..70fc26027c --- /dev/null +++ b/_includes/functions/podcast-bullet.md @@ -0,0 +1,7 @@ +
  • +

    + ● + {{ include.title }} + {% include functions/podcast-note.md slug=include.slug timestamp=include.timestamp reference=include.reference has_transcript_section=include.has_transcript_section %} +

    +
    • \ No newline at end of file diff --git a/_includes/functions/podcast-links.md b/_includes/functions/podcast-links.md new file mode 100644 index 0000000000..fdce2d08e6 --- /dev/null +++ b/_includes/functions/podcast-links.md @@ -0,0 +1,12 @@ + +

    The Bitcoin Optech Podcast and transcription content is licensed Creative Commons CC BY-SA 2.0

    diff --git a/_includes/functions/podcast-note.md b/_includes/functions/podcast-note.md new file mode 100644 index 0000000000..47e1e5d6eb --- /dev/null +++ b/_includes/functions/podcast-note.md @@ -0,0 +1,9 @@ +({{include.timestamp}}) +{% if include.reference %} + +{% endif %} +{% if include.has_transcript_section %} + + + +{% endif %} diff --git a/_includes/functions/podcast-player.md b/_includes/functions/podcast-player.md new file mode 100644 index 0000000000..1deb8c51b9 --- /dev/null +++ b/_includes/functions/podcast-player.md @@ -0,0 +1,5 @@ + \ No newline at end of file diff --git a/_includes/functions/sort-rename.md b/_includes/functions/sort-rename.md index b573545b81..7fcd0aecb7 100644 --- a/_includes/functions/sort-rename.md +++ b/_includes/functions/sort-rename.md @@ -1,4 +1,5 @@ {% capture /dev/null %} + {% assign _result = include.name %} {% if include.name contains "BIP" %} diff --git a/_includes/header.html b/_includes/header.html index e91a1c8c68..3c731c6e0a 100644 --- a/_includes/header.html +++ b/_includes/header.html @@ -20,12 +20,11 @@
    - About + About Publications Topics - Workshops - Compatibility - Dashboard + Workshops + Matrix
    {%- endif -%} diff --git a/_includes/linkers/github-log.md b/_includes/linkers/github-log.md deleted file mode 100644 index d38c4829ca..0000000000 --- a/_includes/linkers/github-log.md +++ /dev/null @@ -1 +0,0 @@ -[{{include.refname}}]: https://github.com/{{include.repo}}/compare/{{include.start}}...{{include.end}} diff --git a/_includes/linkers/issues.md b/_includes/linkers/issues.md index 9961042148..32af3c8939 100644 --- a/_includes/linkers/issues.md +++ b/_includes/linkers/issues.md @@ -1,4 +1,5 @@ {% capture /dev/null %} + {% endcomment %} -{% assign news0 = "/en/newsletters/2018/06/08/" %} -[Newsletter #0]: {{news0}} -{% assign news1 = "/en/newsletters/2018/06/26/" %} -[Newsletter #1]: {{news1}} -{% assign news2 = "/en/newsletters/2018/07/03/" %} -[Newsletter #2]: {{news2}} -{% assign news3 = "/en/newsletters/2018/07/10/" %} -[Newsletter #3]: {{news3}} -{% assign news4 = "/en/newsletters/2018/07/17/" %} -[Newsletter #4]: {{news4}} -{% assign news5 = "/en/newsletters/2018/07/24/" %} -[Newsletter #5]: {{news5}} -{% assign news6 = "/en/newsletters/2018/07/31/" %} -[Newsletter #6]: {{news6}} -{% assign news7 = "/en/newsletters/2018/08/07/" %} -[Newsletter #7]: {{news7}} -{% assign news8 = "/en/newsletters/2018/08/14/" %} -[Newsletter #8]: {{news8}} -{% assign news9 = "/en/newsletters/2018/08/21/" %} -[Newsletter #9]: {{news9}} -{% assign news10 = "/en/newsletters/2018/08/28/" %} -[Newsletter #10]: {{news10}} -{% assign news11 = "/en/newsletters/2018/09/04/" %} -[Newsletter #11]: {{news11}} -{% assign news12 = "/en/newsletters/2018/09/11/" %} -[Newsletter #12]: {{news12}} -{% assign news13 = "/en/newsletters/2018/09/18/" %} -[Newsletter #13]: {{news13}} -{% assign news14 = "/en/newsletters/2018/09/25/" %} -[Newsletter #14]: {{news14}} -{% assign news15 = "/en/newsletters/2018/10/02/" %} -[Newsletter #15]: {{news15}} -{% assign news16 = "/en/newsletters/2018/10/09/" %} -[Newsletter #16]: {{news16}} -{% assign news17 = "/en/newsletters/2018/10/16/" %} -[Newsletter #17]: {{news17}} -{% assign news18 = "/en/newsletters/2018/10/23/" %} -[Newsletter #18]: {{news18}} -{% assign news19 = "/en/newsletters/2018/10/30/" %} -[Newsletter #19]: {{news19}} -{% assign news20 = "/en/newsletters/2018/11/06/" %} -[Newsletter #20]: {{news20}} -{% assign news21 = "/en/newsletters/2018/11/13/" %} -[Newsletter #21]: {{news21}} -{% assign news22 = "/en/newsletters/2018/11/20/" %} -[Newsletter #22]: {{news22}} -{% assign news23 = "/en/newsletters/2018/11/27/" %} -[Newsletter #23]: {{news23}} -{% assign news24 = "/en/newsletters/2018/12/04/" %} -[Newsletter #24]: {{news24}} -{% assign news25 = "/en/newsletters/2018/12/11/" %} -[Newsletter #25]: {{news25}} -{% assign news26 = "/en/newsletters/2018/12/18/" %} -[Newsletter #26]: {{news26}} -{% assign news27 = "/en/newsletters/2018/12/28/" %} -[Newsletter #27]: {{news27}} -{% assign news28 = "/en/newsletters/2019/01/08/" %} -[Newsletter #28]: {{news28}} -{% assign news29 = "/en/newsletters/2019/01/15/" %} -[Newsletter #29]: {{news29}} -{% assign news30 = "/en/newsletters/2019/01/22/" %} -[Newsletter #30]: {{news30}} -{% assign news31 = "/en/newsletters/2019/01/29/" %} -[Newsletter #31]: {{news31}} -{% assign news32 = "/en/newsletters/2019/02/05/" %} -[Newsletter #32]: {{news32}} -{% assign news33 = "/en/newsletters/2019/02/12/" %} -[Newsletter #33]: {{news33}} -{% assign news34 = "/en/newsletters/2019/02/19/" %} -[Newsletter #34]: {{news34}} -{% assign news35 = "/en/newsletters/2019/02/26/" %} -[Newsletter #35]: {{news35}} -{% assign news36 = "/en/newsletters/2019/03/05/" %} -[Newsletter #36]: {{news36}} -{% assign news37 = "/en/newsletters/2019/03/12/" %} -[Newsletter #37]: {{news37}} -{% assign news38 = "/en/newsletters/2019/03/19/" %} -[Newsletter #38]: {{news38}} -{% assign news39 = "/en/newsletters/2019/03/26/" %} -[Newsletter #39]: {{news39}} -{% assign news40 = "/en/newsletters/2019/04/02/" %} -[Newsletter #40]: {{news40}} -{% assign news41 = "/en/newsletters/2019/04/09/" %} -[Newsletter #41]: {{news41}} -{% assign news42 = "/en/newsletters/2019/04/16/" %} -[Newsletter #42]: {{news42}} -{% assign news43 = "/en/newsletters/2019/04/23/" %} -[Newsletter #43]: {{news43}} -{% assign news44 = "/en/newsletters/2019/04/30/" %} -[Newsletter #44]: {{news44}} -{% assign news45 = "/en/newsletters/2019/05/07/" %} -[Newsletter #45]: {{news45}} -{% assign news46 = "/en/newsletters/2019/05/14/" %} -[Newsletter #46]: {{news46}} -{% assign news47 = "/en/newsletters/2019/05/21/" %} -[Newsletter #47]: {{news47}} -{% assign news48 = "/en/newsletters/2019/05/28/" %} -[Newsletter #48]: {{news48}} -{% assign news49 = "/en/newsletters/2019/06/04/" %} -[Newsletter #49]: {{news49}} -{% assign news50 = "/en/newsletters/2019/06/11/" %} -[Newsletter #50]: {{news50}} -{% assign news51 = "/en/newsletters/2019/06/18/" %} -[Newsletter #51]: {{news51}} -{% assign news52 = "/en/newsletters/2019/06/25/" %} -[Newsletter #52]: {{news52}} -{% assign news53 = "/en/newsletters/2019/07/02/" %} -[Newsletter #53]: {{news53}} -{% assign news54 = "/en/newsletters/2019/07/09/" %} -[Newsletter #54]: {{news54}} -{% assign news55 = "/en/newsletters/2019/07/16/" %} -[Newsletter #55]: {{news55}} -{% assign news56 = "/en/newsletters/2019/07/23/" %} -[Newsletter #56]: {{news56}} -{% assign news57 = "/en/newsletters/2019/07/30/" %} -[Newsletter #57]: {{news57}} -{% assign news58 = "/en/newsletters/2019/08/06/" %} -[Newsletter #58]: {{news58}} -{% assign news59 = "/en/newsletters/2019/08/13/" %} -[Newsletter #59]: {{news59}} -{% assign news60 = "/en/newsletters/2019/08/20/" %} -[Newsletter #60]: {{news60}} -{% assign news61 = "/en/newsletters/2019/08/27/" %} -[Newsletter #61]: {{news61}} -{% assign news62 = "/en/newsletters/2019/09/03/" %} -[Newsletter #62]: {{news62}} -{% assign news63 = "/en/newsletters/2019/09/10/" %} -[Newsletter #63]: {{news63}} -{% assign news64 = "/en/newsletters/2019/09/17/" %} -[Newsletter #64]: {{news64}} -{% assign news65 = "/en/newsletters/2019/09/24/" %} -[Newsletter #65]: {{news65}} -{% assign news66 = "/en/newsletters/2019/10/01/" %} -[Newsletter #66]: {{news66}} -{% assign news67 = "/en/newsletters/2019/10/08/" %} -[Newsletter #67]: {{news67}} -{% assign news68 = "/en/newsletters/2019/10/15/" %} -[Newsletter #68]: {{news68}} -{% assign news69 = "/en/newsletters/2019/10/22/" %} -[Newsletter #69]: {{news69}} -{% assign news70 = "/en/newsletters/2019/10/29/" %} -[Newsletter #70]: {{news70}} -{% assign news71 = "/en/newsletters/2019/11/05/" %} -[Newsletter #71]: {{news71}} -{% assign news72 = "/en/newsletters/2019/11/12/" %} -[Newsletter #72]: {{news72}} -{% assign news73 = "/en/newsletters/2019/11/19/" %} -[Newsletter #73]: {{news73}} -{% assign news74 = "/en/newsletters/2019/11/26/" %} -[Newsletter #74]: {{news74}} -{% assign news48 = "/en/newsletters/2019/05/29/" %} -[Newsletter #48]: {{news48}} -{% assign news49 = "/en/newsletters/2019/06/05/" %} -[Newsletter #49]: {{news49}} -{% assign news50 = "/en/newsletters/2019/06/12/" %} -[Newsletter #50]: {{news50}} -{% assign news51 = "/en/newsletters/2019/06/19/" %} -[Newsletter #51]: {{news51}} -{% assign news52 = "/en/newsletters/2019/06/26/" %} -[Newsletter #52]: {{news52}} -{% assign news53 = "/en/newsletters/2019/07/03/" %} -[Newsletter #53]: {{news53}} -{% assign news54 = "/en/newsletters/2019/07/10/" %} -[Newsletter #54]: {{news54}} -{% assign news55 = "/en/newsletters/2019/07/17/" %} -[Newsletter #55]: {{news55}} -{% assign news56 = "/en/newsletters/2019/07/24/" %} -[Newsletter #56]: {{news56}} -{% assign news57 = "/en/newsletters/2019/07/31/" %} -[Newsletter #57]: {{news57}} -{% assign news58 = "/en/newsletters/2019/08/07/" %} -[Newsletter #58]: {{news58}} -{% assign news59 = "/en/newsletters/2019/08/14/" %} -[Newsletter #59]: {{news59}} -{% assign news60 = "/en/newsletters/2019/08/21/" %} -[Newsletter #60]: {{news60}} -{% assign news61 = "/en/newsletters/2019/08/28/" %} -[Newsletter #61]: {{news61}} -{% assign news62 = "/en/newsletters/2019/09/04/" %} -[Newsletter #62]: {{news62}} -{% assign news63 = "/en/newsletters/2019/09/11/" %} -[Newsletter #63]: {{news63}} -{% assign news64 = "/en/newsletters/2019/09/18/" %} -[Newsletter #64]: {{news64}} -{% assign news65 = "/en/newsletters/2019/09/25/" %} -[Newsletter #65]: {{news65}} -{% assign news66 = "/en/newsletters/2019/10/02/" %} -[Newsletter #66]: {{news66}} -{% assign news67 = "/en/newsletters/2019/10/09/" %} -[Newsletter #67]: {{news67}} -{% assign news68 = "/en/newsletters/2019/10/16/" %} -[Newsletter #68]: {{news68}} -{% assign news69 = "/en/newsletters/2019/10/23/" %} -[Newsletter #69]: {{news69}} -{% assign news70 = "/en/newsletters/2019/10/30/" %} -[Newsletter #70]: {{news70}} -{% assign news71 = "/en/newsletters/2019/11/06/" %} -[Newsletter #71]: {{news71}} -{% assign news72 = "/en/newsletters/2019/11/13/" %} -[Newsletter #72]: {{news72}} -{% assign news73 = "/en/newsletters/2019/11/20/" %} -[Newsletter #73]: {{news73}} -{% assign news74 = "/en/newsletters/2019/11/27/" %} -[Newsletter #74]: {{news74}} -{% assign news75 = "/en/newsletters/2019/12/04/" %} -[Newsletter #75]: {{news75}} -{% assign news76 = "/en/newsletters/2019/12/11/" %} -[Newsletter #76]: {{news76}} -{% assign news77 = "/en/newsletters/2019/12/18/" %} -[Newsletter #77]: {{news77}} diff --git a/_includes/newsletter-references.md b/_includes/newsletter-references.md new file mode 100644 index 0000000000..5bec9fce6e --- /dev/null +++ b/_includes/newsletter-references.md @@ -0,0 +1,27 @@ +{% assign newsletter_sections = page.references | group_by:"header" %} +{% assign header_names = newsletter_sections | map: "name" %} +{% unless header_names contains "News" or header_names contains "January" %} +## News +*No significant news this week was found on the Bitcoin-Dev or Lightning-Dev mailing lists.* +{% endunless %} +
    +{% for section in newsletter_sections %} +

    {{ section.name }} + {% if page.special_sections contains section.name %} + + + {% assign reference = section.items | first %} + {% include functions/podcast-note.md slug=reference.slug timestamp=reference.timestamp reference=page.reference has_transcript_section=reference.has_transcript_section %} + {% endif %} +

    + {% unless page.special_sections contains section.name %} +
      + {% for reference in section.items %} + {% assign podcast_slug = reference.podcast_slug | default: reference.slug %} + {% include functions/podcast-bullet.md slug=reference.slug timestamp=reference.timestamp reference=page.reference podcast_slug=podcast_slug title=reference.title has_transcript_section=reference.has_transcript_section %} + {% endfor %} +
    + {% endunless %} +{% endfor %} +
    diff --git a/_includes/references.md b/_includes/references.md index 66490e0ac2..ae1b3a3069 100644 --- a/_includes/references.md +++ b/_includes/references.md @@ -1,12 +1,17 @@ {% comment %}{% endcomment %} [bech32 series]: /en/bech32-sending-support/ -[compatibility matrix]: /en/compatibility/ -[op_cat]: /en/topics/op_checksigfromstack/#relationship-to-op_cat +[compatibility matrix]: /en/matrix/ +[topics]: /en/topics/ +[podcast]: /en/podcast/ +[op_cat]: /en/topics/op_cat/ [optech email]: mailto:info@bitcoinops.org +[optech sources]: /en/internal/sources/ [rss feed]: /feed.xml [scaling payment batching]: /en/payment-batching/ [series preparing for taproot]: /en/preparing-for-taproot/ +[topic fpps]: /en/topics/pooled-mining/#full-pay-per-share-fpps +[topic pplns]: /en/topics/pooled-mining/#pay-per-last-n-shares-pplns {% comment %}{% endcomment %} {% for topic in site.topics %} [topic {{topic.shortname | default: topic.title}}]: {{topic.url}} @@ -14,6 +19,7 @@ {% comment %}{% endcomment %} [bdk repo]: https://github.com/bitcoindevkit/bdk +[binana repo]: https://github.com/bitcoin-inquisition/binana [bip-anyprevout]: https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0118.mediawiki [bip-cleanup]: https://github.com/TheBlueMatt/bips/blob/cleanup-softfork/bip-XXXX.mediawiki [bip-coshv]: https://github.com/JeremyRubin/bips/blob/op-checkoutputshashverify/bip-coshv.mediawiki @@ -25,9 +31,11 @@ [Bitcoin Core PR Review Club]: https://bitcoincore.reviews/ [BitcoinCore.org]: https://bitcoincore.org/ [bitcoin core repo]: https://github.com/bitcoin/bitcoin +[bitcoin inquisition repo]: https://github.com/bitcoin-inquisition/bitcoin [bitcoin transcripts]: https://twitter.com/btctranscripts [bitcoin.pdf]: https://bitcoincore.org/bitcoin.pdf [bitcoin.se]: https://bitcoin.stackexchange.com/ +[blips repo]: https://github.com/lightning/blips [bolts repo]: https://github.com/lightning/bolts [btcpay server repo]: https://github.com/btcpayserver/btcpayserver/ [c-lightning]: https://github.com/ElementsProject/lightning @@ -35,34 +43,19 @@ [core lightning repo]: https://github.com/ElementsProject/lightning [eclair repo]: https://github.com/ACINQ/eclair [elementsproject.org]: https://elementsproject.org/ +[FIXME]: https://example.com/FIXME{% comment %}{% endcomment %} [hwi repo]: https://github.com/bitcoin-core/HWI [ldk repo]: https://github.com/lightningdevkit/rust-lightning [libminisketch]: https://github.com/sipa/minisketch [libsecp256k1]: https://github.com/bitcoin-core/secp256k1 [libsecp256k1 repo]: https://github.com/bitcoin-core/secp256k1 [lnd repo]: https://github.com/lightningnetwork/lnd/ +[nostr]: https://github.com/nostr-protocol/nips +[@bitcoinoptech]: https://twitter.com/bitcoinoptech [rust bitcoin repo]: https://github.com/rust-bitcoin/rust-bitcoin [rust-lightning repo]: https://github.com/rust-bitcoin/rust-lightning -{% comment %}{% endcomment %} -{% assign pagedate_epoch = page.date | date: '%s' %} -{% assign deprecated_links_v0_epoch = '2020-09-24' | date: '%s' %} -{% if pagedate_epoch < deprecated_links_v0_epoch %} -[cve-2012-2459]: https://bitcointalk.org/?topic=102395 -[cve-2017-12842]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12842 -[cve-2018-17144]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-17144 -[eltoo]: https://blockstream.com/eltoo.pdf -[erlay]: https://arxiv.org/pdf/1905.10518.pdf -[hwi]: https://github.com/bitcoin-core/HWI -[miniscript]: /en/topics/miniscript/ -[musig]: https://eprint.iacr.org/2018/068 -{% assign _link_descriptors = 'https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md' %} -[descriptor]: {{_link_descriptors}} -[output script descriptor]: {{_link_descriptors}} -[output script descriptors]: {{_link_descriptors}} -{% endif %} - -{% comment %} {% endcomment %} -{% for i in (1..400) %} +[BIP1]: https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki +[BIP2]: https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki +[BIP3]: https://github.com/bitcoin/bips/blob/master/bip-0003.md +[BIP8]: https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki +[BIP9]: https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki +[BIP12]: https://github.com/bitcoin/bips/blob/master/bip-0012.mediawiki +[BIP13]: https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki +[BIP16]: https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki +[BIP17]: https://github.com/bitcoin/bips/blob/master/bip-0017.mediawiki +[BIP18]: https://github.com/bitcoin/bips/blob/master/bip-0018.mediawiki +[BIP19]: https://github.com/bitcoin/bips/blob/master/bip-0019.mediawiki +[BIP21]: https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki +[BIP22]: https://github.com/bitcoin/bips/blob/master/bip-0022.mediawiki +[BIP23]: https://github.com/bitcoin/bips/blob/master/bip-0023.mediawiki +[BIP32]: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki +[BIP30]: https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki +[BIP34]: https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki +[BIP35]: https://github.com/bitcoin/bips/blob/master/bip-0035.mediawiki +[BIP37]: https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki +[BIP39]: https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki +[BIP40]: https://github.com/bitcoin/bips/blob/master/bip-0040.mediawiki +[BIP41]: https://github.com/bitcoin/bips/blob/master/bip-0041.mediawiki +[BIP44]: https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki +[BIP45]: https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki +[BIP46]: https://github.com/bitcoin/bips/blob/master/bip-0046.mediawiki +[BIP47]: https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki +[BIP48]: https://github.com/bitcoin/bips/blob/master/bip-0048.mediawiki +[BIP49]: https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki +[BIP50]: https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki +[BIP52]: https://github.com/bitcoin/bips/blob/master/bip-0052.mediawiki +[BIP53]: https://github.com/bitcoin/bips/blob/master/bip-0053.mediawiki +[BIP54]: https://github.com/bitcoin/bips/blob/master/bip-0054.md +[BIP61]: https://github.com/bitcoin/bips/blob/master/bip-0061.mediawiki +[BIP62]: https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki +[BIP65]: https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki +[BIP66]: https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki +[BIP67]: https://github.com/bitcoin/bips/blob/master/bip-0067.mediawiki +[BIP68]: https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki +[BIP69]: https://github.com/bitcoin/bips/blob/master/bip-0069.mediawiki +[BIP70]: https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki +[BIP71]: https://github.com/bitcoin/bips/blob/master/bip-0071.mediawiki +[BIP72]: https://github.com/bitcoin/bips/blob/master/bip-0072.mediawiki +[BIP75]: https://github.com/bitcoin/bips/blob/master/bip-0075.mediawiki +[BIP77]: https://github.com/bitcoin/bips/blob/master/bip-0077.md +[BIP78]: https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki +[BIP79]: https://github.com/bitcoin/bips/blob/master/bip-0079.mediawiki +[BIP84]: https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki +[BIP85]: https://github.com/bitcoin/bips/blob/master/bip-0085.mediawiki +[BIP86]: https://github.com/bitcoin/bips/blob/master/bip-0086.mediawiki +[BIP87]: https://github.com/bitcoin/bips/blob/master/bip-0087.mediawiki +[BIP88]: https://github.com/bitcoin/bips/blob/master/bip-0088.mediawiki +[BIP90]: https://github.com/bitcoin/bips/blob/master/bip-0090.mediawiki +[BIP91]: https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki +[BIP93]: https://github.com/bitcoin/bips/blob/master/bip-0093.mediawiki +[BIP94]: https://github.com/bitcoin/bips/blob/master/bip-0094.mediawiki +[BIP103]: https://github.com/bitcoin/bips/blob/master/bip-0103.mediawiki +[BIP111]: https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki +[BIP112]: https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki +[BIP113]: https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki +[BIP114]: https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki +[BIP116]: https://github.com/bitcoin/bips/blob/master/bip-0116.mediawiki +[BIP117]: https://github.com/bitcoin/bips/blob/master/bip-0117.mediawiki +[BIP118]: https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki +[BIP119]: https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki +[BIP125]: https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki +[BIP127]: https://github.com/bitcoin/bips/blob/master/bip-0127.mediawiki +[BIP129]: https://github.com/bitcoin/bips/blob/master/bip-0129.mediawiki +[BIP130]: https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki +[BIP133]: https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki +[BIP136]: https://github.com/bitcoin/bips/blob/master/bip-0136.mediawiki +[BIP137]: https://github.com/bitcoin/bips/blob/master/bip-0137.mediawiki +[BIP140]: https://github.com/bitcoin/bips/blob/master/bip-0140.mediawiki +[BIP141]: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki +[BIP143]: https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki +[BIP144]: https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki +[BIP145]: https://github.com/bitcoin/bips/blob/master/bip-0145.mediawiki +[BIP146]: https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki +[BIP147]: https://github.com/bitcoin/bips/blob/master/bip-0147.mediawiki +[BIP148]: https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki +[BIP149]: https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki +[BIP150]: https://github.com/bitcoin/bips/blob/master/bip-0150.mediawiki +[BIP151]: https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki +[BIP152]: https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki +[BIP155]: https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki +[BIP156]: https://github.com/bitcoin/bips/blob/master/bip-0156.mediawiki +[BIP157]: https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki +[BIP158]: https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki +[BIP159]: https://github.com/bitcoin/bips/blob/master/bip-0159.mediawiki +[BIP172]: https://github.com/bitcoin/bips/blob/master/bip-0172.mediawiki +[BIP173]: https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki +[BIP174]: https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki +[BIP177]: https://github.com/bitcoin/bips/blob/master/bip-0177.mediawiki +[BIP179]: https://github.com/bitcoin/bips/blob/master/bip-0179.mediawiki +[BIP199]: https://github.com/bitcoin/bips/blob/master/bip-0199.mediawiki +[BIP300]: https://github.com/bitcoin/bips/blob/master/bip-0300.mediawiki +[BIP301]: https://github.com/bitcoin/bips/blob/master/bip-0301.mediawiki +[BIP320]: https://github.com/bitcoin/bips/blob/master/bip-0320.mediawiki +[BIP321]: https://github.com/bitcoin/bips/blob/master/bip-0321.mediawiki +[BIP322]: https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki +[BIP324]: https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki +[BIP325]: https://github.com/bitcoin/bips/blob/master/bip-0325.mediawiki +[BIP326]: https://github.com/bitcoin/bips/blob/master/bip-0326.mediawiki +[BIP327]: https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki +[BIP328]: https://github.com/bitcoin/bips/blob/master/bip-0328.mediawiki +[BIP329]: https://github.com/bitcoin/bips/blob/master/bip-0329.mediawiki +[BIP330]: https://github.com/bitcoin/bips/blob/master/bip-0330.mediawiki +[BIP331]: https://github.com/bitcoin/bips/blob/master/bip-0331.mediawiki +[BIP337]: https://github.com/bitcoin/bips/blob/master/bip-0337.mediawiki +[BIP338]: https://github.com/bitcoin/bips/blob/master/bip-0338.mediawiki +[BIP339]: https://github.com/bitcoin/bips/blob/master/bip-0339.mediawiki +[BIP340]: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki +[BIP341]: https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki +[BIP342]: https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki +[BIP345]: https://github.com/bitcoin/bips/blob/master/bip-0345.mediawiki +[BIP347]: https://github.com/bitcoin/bips/blob/master/bip-0347.mediawiki +[BIP348]: https://github.com/bitcoin/bips/blob/master/bip-0348.md +[BIP349]: https://github.com/bitcoin/bips/blob/master/bip-0349.md +[BIP350]: https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki +[BIP351]: https://github.com/bitcoin/bips/blob/master/bip-0351.mediawiki +[BIP352]: https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki +[BIP353]: https://github.com/bitcoin/bips/blob/master/bip-0353.mediawiki +[BIP370]: https://github.com/bitcoin/bips/blob/master/bip-0370.mediawiki +[BIP371]: https://github.com/bitcoin/bips/blob/master/bip-0371.mediawiki +[BIP372]: https://github.com/bitcoin/bips/blob/master/bip-0372.mediawiki +[BIP373]: https://github.com/bitcoin/bips/blob/master/bip-0373.mediawiki +[BIP374]: https://github.com/bitcoin/bips/blob/master/bip-0374.mediawiki +[BIP375]: https://github.com/bitcoin/bips/blob/master/bip-0375.mediawiki +[BIP379]: https://github.com/bitcoin/bips/blob/master/bip-0379.md +[BIP380]: https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki +[BIP381]: https://github.com/bitcoin/bips/blob/master/bip-0381.mediawiki +[BIP382]: https://github.com/bitcoin/bips/blob/master/bip-0382.mediawiki +[BIP383]: https://github.com/bitcoin/bips/blob/master/bip-0383.mediawiki +[BIP384]: https://github.com/bitcoin/bips/blob/master/bip-0384.mediawiki +[BIP385]: https://github.com/bitcoin/bips/blob/master/bip-0385.mediawiki +[BIP386]: https://github.com/bitcoin/bips/blob/master/bip-0386.mediawiki +[BIP387]: https://github.com/bitcoin/bips/blob/master/bip-0387.mediawiki +[BIP388]: https://github.com/bitcoin/bips/blob/master/bip-0388.mediawiki +[BIP389]: https://github.com/bitcoin/bips/blob/master/bip-0389.mediawiki +[BIP390]: https://github.com/bitcoin/bips/blob/master/bip-0390.mediawiki +[BIP431]: https://github.com/bitcoin/bips/blob/master/bip-0431.mediawiki +[BIP443]: https://github.com/bitcoin/bips/blob/master/bip-0443.mediawiki + +{% for i in (1..10) %} +{% assign i_padded = "0000" | append: i | slice: -4, 4 %} +[BIN24-{{i}}]: https://github.com/bitcoin-inquisition/binana/blob/master/2024/BIN-2024-{{i_padded}}.md +{% endfor %} + +{% for i in (1..100) %} {% assign i_padded = "0000" | append: i | slice: -4, 4 %} -[BIP{{i}}]: https://github.com/bitcoin/bips/blob/master/bip-{{i_padded}}.mediawiki +[BLIP{{i}}]: https://github.com/lightning/blips/blob/master/blip-{{i_padded}}.md {% endfor %} {% comment %}{% endcomment %} +[BIP360]: https://github.com/bitcoin/bips/pull/1670 {% comment %}{% endcomment %} [BOLT1]: https://github.com/lightningnetwork/lightning-rfc/blob/master/01-messaging.md @@ -88,15 +229,12 @@ place, put links here. -->{% endcomment %} [BOLT5]: https://github.com/lightningnetwork/lightning-rfc/blob/master/05-onchain.md [BOLT7]: https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md [BOLT8]: https://github.com/lightningnetwork/lightning-rfc/blob/master/08-transport.md +[BOLT9]: https://github.com/lightning/bolts/blob/master/09-features.md [BOLT11]: https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md +[BOLT12]: https://github.com/lightning/bolts/blob/master/12-offer-encoding.md -{% comment %}{% endcomment %} -{% include linkers/newsletters.md %} - -{% comment %} - -{% endcomment %} +{% comment %}{% endcomment %} {% assign rpc_prefix = "https://bitcoincore.org/en/doc/0.20.0/rpc" %} [rpc abandontransaction]: {{rpc_prefix}}/wallet/abandontransaction/ [rpc fundrawtransaction]: {{rpc_prefix}}/rawtransactions/fundrawtransaction/ diff --git a/_includes/snippets/msig-terms.md b/_includes/snippets/msig-terms.md index 69f5b94422..ca68a9d536 100644 --- a/_includes/snippets/msig-terms.md +++ b/_includes/snippets/msig-terms.md @@ -1,5 +1,5 @@ | Term | Private keys | Messages
    (e.g. tx inputs) | Published pubkeys | Signatures | Signers required | Notes | |-|-|-|-|-| -| Multisig | `m` | `1` | `m` | `k` where `k<=m` | `k` | Uses Bitcoin Script multisig opcodes | -| [Multisignature][topic multisignature] | `m` | `1` | `1` | `1` | `m` | Indistinguishable onchain from single-sig | +| Scripted multisig | `m` | `1` | `m` | `k` where `k<=m` | `k` | Uses Bitcoin Script multisig opcodes | +| [Scriptless multisignatures][topic multisignature] | `m` | `1` | `1` | `1` | `m` | Indistinguishable onchain from single-sig | | [Threshold signature][topic threshold signature] | `m` | `1` | `1` | `1` | `k` where `k<=m` | Indistinguishable onchain from single-sig | diff --git a/_includes/snippets/recap-ad.md b/_includes/snippets/recap-ad.md new file mode 100644 index 0000000000..f73e083405 --- /dev/null +++ b/_includes/snippets/recap-ad.md @@ -0,0 +1,82 @@ +{% capture /dev/null %} + + + + Input: + - when: UTC time of next recap in any format supported by the `date` + filter, e.g. YYYY-MM-DD HH:MM. Cannot be earlier than the + page.date + + Output: + A div with a paragraph announcing the next recap and how to + participate in it. + + Example: + Input: + % include linkers/issues.md issues="123,456" % + Output + ... at HOUR on DAY ... +--> +{% assign current_epoch_time = site.time | date: "%s" %} +{% assign when_epoch_time = include.when | date: "%s" %} +{% assign page_epoch_time = page.date | date: "%s" %} +{% if page_epoch_time > when_epoch_time %}{% include ERROR_RECAP_EARLIER_THAN_PUBLICATION_DATE %}{% endif %} +{% assign recap_formatted_date_utc = include.when | date: "%B %-d" %} +{% assign recap_formatted_time_utc = include.when | date: "%H:%M" %} +{% endcapture %}{% capture recap_ad_text %} +
    + +{% case page.lang %} +{% when "cs" %} + +{% assign recap_formatted_date_utc = include.when | date: "%-d. %-m." %} + +## Chcete víc? + +Další diskuze o tématech zmíněných v tomto zpravodaji proběhnou v týdenním +Bitcoin Optech Recap na [Riverside.fm][] dne {{recap_formatted_date_utc}} +v {{recap_formatted_time_utc}} UTC. Diskuze jsou nahrávány a zpřístupněny +na stránce našeho [podcastu][podcast]. +{% when "fr" %} + +## Vous en voulez plus? + +Pour plus de discussions sur les sujets mentionnés dans ce bulletin, +rejoignez-nous pour le récapitulatif hebdomadaire Bitcoin Optech sur +[Riverside.fm][] à {{recap_formatted_time_utc}} UTC le jeudi (le jour suivant la +publication de la newsletter). La discussion est également enregistrée et sera +disponible sur notre page de [podcasts][podcast]. +{% when "ja" %} + +## もっと知りたいですか？ + +このニュースレターで言及されたトピックについてもっと議論したい方は、 +{{recap_formatted_time_utc}} UTCに +[Riverside.fm][]で毎週配信されているBitcoin Optech Recapにご参加ください。 +この議論は録画もされ、[ポッドキャスト][podcast]ページからご覧いただけます。 + +{% when "zh" %} + +## 想了解更多？ + +想了解更多本周报中提到的内容，请加入我们每周的比特币 Optech 回顾的 +[Riverside.fm][]，时间为每周四 {{recap_formatted_time_utc}} UTC（即周报发布后的 +一天）。讨论内容会被录制下来，也将在我们的[播客][podcast]页面上提供。 + +{% else %} +## Want more? + +For more discussion about the topics mentioned in this newsletter, join us for +the weekly Bitcoin Optech Recap on [Riverside.fm][] at +{{recap_formatted_time_utc}} UTC on {{recap_formatted_date_utc}}. The +discussion is also recorded and will be available from our [podcasts][podcast] +page. +{% endcase %} + +
    +{% endcapture %} +{% if when_epoch_time > current_epoch_time %}{{recap_ad_text}}{% endif %} + +[Riverside.fm]: https://riverside.fm/studio/bitcoin-optech diff --git a/_includes/snippets/stub-topic.md b/_includes/snippets/stub-topic.md index 857b1cee61..79693f5d17 100644 --- a/_includes/snippets/stub-topic.md +++ b/_includes/snippets/stub-topic.md @@ -1,5 +1,7 @@
    + *This topic description is a stub. We would welcome a [pull request](https://github.com/{{site.github_username}}/{{site.repository_name}}/edit/master/{{page.path}}) providing more background information about the topic.* +
    diff --git a/_includes/specials/2019-exec-briefing/lightning.md b/_includes/specials/2019-exec-briefing/lightning.md index 9f73069c7d..82a35d9c54 100644 --- a/_includes/specials/2019-exec-briefing/lightning.md +++ b/_includes/specials/2019-exec-briefing/lightning.md @@ -30,9 +30,9 @@ the amount of business they do using Ethereum. expects them to be using in the near future. He then explained two of Bitrefill's services for LN users (including businesses), [Thor][] and [Thor Turbo][]. Finally, he briefly described several planned improvements to LN: - reusable addresses (see [Newsletter #30][]), splicing in and out (see - [#22][Newsletter #22]), and larger channels (also [#22][Newsletter - #22]). + reusable addresses (see [Newsletter #30][newsletter #30 spon]), splicing in and out (see + [#22][Newsletter #22 splice]), and larger channels (also [#22][Newsletter + #22 wumbo]). Overall, Kotliar made a compelling case that LN's faster speed, lower fees, and improved invoicing means businesses that expect to remain competitive @@ -41,3 +41,6 @@ the amount of business they do using Ethereum. [thor]: https://www.bitrefill.com/thor-lightning-network-channels/?hl=en [thor turbo]: https://www.bitrefill.com/thor-turbo-channels/?hl=en +[newsletter #30 spon]: /en/newsletters/2019/01/22/#pr-opened-for-spontaneous-ln-payments +[newsletter #22 splice]: /en/newsletters/2018/11/20/#splicing +[newsletter #22 wumbo]: /en/newsletters/2018/11/20/#wumbo diff --git a/_includes/specials/2019-exec-briefing/softfork.md b/_includes/specials/2019-exec-briefing/softfork.md index d1c6e8ae46..92a2f48cbf 100644 --- a/_includes/specials/2019-exec-briefing/softfork.md +++ b/_includes/specials/2019-exec-briefing/softfork.md @@ -2,10 +2,10 @@ {% capture the-next-softfork %}In his presentation, Lee describes the various phases of a soft fork from idea to proposal to implementation to activation. Using this framework, he identifies the current state of the - Schnorr/Taproot soft fork (see [Newsletter #46][]), the consensus - cleanup soft fork ([#36][Newsletter #36]), and the noinput soft fork + Schnorr/Taproot soft fork (see [Newsletter #46][newsletter #46 taproot]), the consensus + cleanup soft fork ([#36][Newsletter #36 cc]), and the noinput soft fork proposals ([BIP118][] and [bip-anyprevout], see [#47][Newsletter - #47]). Although later in the presentation he provides an overview of + #47 apo]). Although later in the presentation he provides an overview of the consensus cleanup soft fork (fixing several non-urgent problems in the protocol) and the noinput proposals (enabling new features for contract protocols such as the [Eltoo][] layer for LN), his talk---and @@ -56,3 +56,7 @@ available. Lee finishes his talk by providing a rough, and heavily caveated, timeline for when we might see the changes described in his talk.{% endcapture %} + +[newsletter #36 cc]: /en/newsletters/2019/03/05/#cleanup-soft-fork-proposal +[newsletter #46 taproot]: /en/newsletters/2019/05/14/#overview-of-the-taproot--tapscript-proposed-bips +[newsletter #47 apo]: /en/newsletters/2019/05/21/#proposed-anyprevout-sighash-modes diff --git a/_includes/specials/2019-exec-briefing/zh/fees.md b/_includes/specials/2019-exec-briefing/zh/fees.md new file mode 100644 index 0000000000..29d0e0e6eb --- /dev/null +++ b/_includes/specials/2019-exec-briefing/zh/fees.md @@ -0,0 +1,5 @@ +{% capture return-to-fees-zh %}Schmidt 以回顾最近 Bitcoin 手续费事件的统计数据开始了他的演讲，包括过去几个月的短期事件以及从 2017 年 1 月到 2018 年 1 月的长期事件，在此期间平均大小的交易的下一个区块手续费始终超过 1 美元（通常超过 2 美元）。他提醒听众高额手续费可能会卷土重来——这可能已经发生——而实施一些技术以将手续费降低哪怕是小百分比的组织，如果手续费攀升到与之前一样高（甚至更高），可能会为自己或客户节省大量资金。 + +然后，他描述了服务可以实施的几种降低手续费的技术，并大致量化了从每种技术中可以预期的改进程度。这些技术包括：更好的手续费估算、更好的币种选择、支付批处理、使用 segwit、UTXO 合并、耐心消费、Replace-by-Fee (RBF) 手续费提升、Child-Pays-For-Parent (CPFP) 手续费提升以及闪电网络（作为未来的技术）。他还指出，教育在让用户接受和采用这些技术中发挥着重要作用，并指出这也可以帮助减少用户交互成本，例如在手续费事件期间为卡住的交易提供客户支持。 + +这场 30 分钟的演讲简明扼要地涵盖了每一点，成为任何对了解 Bitcoin 手续费市场及如何缓解预期手续费增加感兴趣的人士的优秀高级概述。{% endcapture %} diff --git a/_includes/specials/2019-exec-briefing/zh/lightning.md b/_includes/specials/2019-exec-briefing/zh/lightning.md new file mode 100644 index 0000000000..545d0db852 --- /dev/null +++ b/_includes/specials/2019-exec-briefing/zh/lightning.md @@ -0,0 +1,16 @@ +{% include references.md %} +{% capture operating-on-lightning-zh %}Kotliar 开始解释说，前几年较高的交易费用对 Bitrefill 的业务产生了重大影响，因此他们特别努力在降低费用相关的支出方面表现出色。接收 LN 支付的能力支持了这一目标，他相信他们是第一个在主网上出售真实商品以接收 LN 支付的服务。如今，LN 支付约占他们销售额的 5%，这与他们使用以太坊的业务量相似。 + + 他认为企业现在开始研究 LN 是很重要的。“在比特币中，我们已经习惯于等待 [...] 但让客户等待不确定的时间，会产生客户离开的风险。”例如，当存款在交易所结算时，客户可能不再有兴趣进行本可以为交易所赚取佣金的交易。此外，Bitrefill 使用 LN 的经验表明，LN 改进的发票消除了链上比特币支付中出现的多种支付错误，包括超额支付、少付、卡住的交易、复制粘贴错误以及其他问题。通过 LN 接收支付还消除了合并 UTXO 的需要，并减少了在热钱包和冷钱包之间轮换资金的需求。消除所有这些问题有可能显著减少客户支持和后端支出。 + + 在他演讲的一个特别有趣的部分，Kotliar 显示了当前链上支付中或许有高达 70% 是用户将资金从一个交易所转移到另一个交易所（甚至在同一交易所的不同用户之间）。如果所有这些活动都可以通过 LN 支付从链上转移，交易所及其用户可以节省大量资金，并且比特币中的每个人都将受益于可用区块空间的增加。 + + Kotliar 用几个简短的片段结束了他的演讲。他描述了 Bitrefill 看到 LN 用户今天使用的软件和服务，以及他预计他们在不久的将来会使用的。他接着解释了 Bitrefill 为 LN 用户（包括企业）提供的两个服务，[Thor][] 和 [Thor Turbo][]。最后，他简要描述了对 LN 的几项计划改进：可重复使用地址（参见 [Newsletter #30][newsletter #30 spon]）、拼接进出（参见 [#22][Newsletter #22 splice]）和更大的通道（也参见 [#22][Newsletter #22 wumbo]）。 + + 总的来说，Kotliar 提出了一个令人信服的观点，即 LN 的更快速度、更低费用和改进的发票意味着希望在不久的将来保持竞争力以服务比特币客户的企业，应该立即开始研究实现 LN 支持。{% endcapture %} + +[thor]: https://www.bitrefill.com/thor-lightning-network-channels/?hl=en +[thor turbo]: https://www.bitrefill.com/thor-turbo-channels/?hl=en +[newsletter #30 spon]: /zh/newsletters/2019/01/22/#pr-opened-for-spontaneous-ln-payments +[newsletter #22 splice]: /zh/newsletters/2018/11/20/#splicing +[newsletter #22 wumbo]: /zh/newsletters/2018/11/20/#wumbo diff --git a/_includes/specials/2019-exec-briefing/zh/softfork.md b/_includes/specials/2019-exec-briefing/zh/softfork.md new file mode 100644 index 0000000000..4609c30559 --- /dev/null +++ b/_includes/specials/2019-exec-briefing/zh/softfork.md @@ -0,0 +1,12 @@ +{% include references.md %} +{% capture the-next-softfork-zh %}在他的演讲中，Lee 描述了软分叉从构想到提案再到实施和激活的各个阶段。利用这一框架，他识别了 Schnorr/Taproot 软分叉（参见 [Newsletter #46][newsletter #46 taproot]）、共识清理软分叉（[#36][Newsletter #36 cc]）和 noinput 软分叉提案（[BIP118][] 和 [bip-anyprevout]，参见 [#47][Newsletter #47 apo]）的当前状态。尽管在演讲后期，他概述了共识清理软分叉（修复协议中的几个非紧急问题）和 noinput 提案（为合同协议如闪电网络的 [Eltoo][] 层启用新功能），但他的演讲——以及本文对其的总结——主要集中在 [bip-schnorr][]、[bip-taproot][] 和 [bip-tapscript][] 的组合提案上。 + + 在提供了关于 Schnorr 签名和签名聚合的高层次概述后——这些信息可能已经为本 Newsletter 的读者所熟悉——Lee 的演讲很大一部分围绕着 2-of-3 多重签名安全性展开，这是今天许多企业使用的一项功能。他首先描述了*阈值密钥*为用户带来的节省，即聚合公钥仅需要原始各方的子集即可创建有效签名，例如由三个单独密钥创建的聚合密钥，其中任意两名参与者可以对 2-of-3 多重签名安全性进行签名。这种方法的优点是链上最大效率和隐私，但缺点是创建公钥和签名时需要互动，并且密钥持有者无法使用区块链数据进行审计以确定实际参与签名的子集。 + + 为了解决公钥互动性和签名审计问题，Lee 使用了一系列易于理解的插图幻灯片，展示了使用 Taproot 的密钥路径和脚本路径支出组合来实现的一种替代构造。创建了三个 [MuSig][] 风格的 2-of-2 聚合公钥——每个公钥对应于 2-of-3 多重签名中可能的三个签名者组合之一。由于这是 MuSig n-of-n 密钥聚合，它不需要互动。最可能的组合（例如热钱包密钥和第三方安全密钥）可以通过 Taproot 密钥路径支出，使得输出可以使用单个聚合签名进行支出，看起来像任何单一签名支出。两个替代选项（例如每个涉及一个冷备份密钥）被放置在一个 MAST 树中以进行脚本路径支出。这虽然不如密钥路径支出隐私性高或成本低，但提供了冗余性。对于这些选项中的任何一个，任何查看区块链数据的第三方只能看到一个签名，并且没有关于参与方数量的直接信息，但每个三个密钥持有者都知道哪些参与者的公钥被用于创建与支出签名匹配的特定聚合密钥，从而使他们能够进行私密审计。Lee 在总结这一部分演讲时，展示了 Schnorr 和 Taproot 对当前多重签名支出者的明确总体好处及其权衡。 + + 除了增强当前比特币的使用外，还描述了一些目前不太可行但在 Schnorr 风格签名和 MAST 风格脚本树变得可用后将变得可行的新功能。Lee 在演讲的最后提供了一个粗略的、带有很大不确定性的时间表，介绍了这些变更可能会在何时实现。{% endcapture %} + +[newsletter #36 cc]: /zh/newsletters/2019/03/05/#cleanup-soft-fork-proposal +[newsletter #46 taproot]: /zh/newsletters/2019/05/14/#taproot-和-tapscript-提案-bip-概述 +[newsletter #47 apo]: /zh/newsletters/2019/05/21/#proposed-anyprevout-sighash-modes diff --git a/_includes/specials/bech32/01-intro.md b/_includes/specials/bech32/01-intro.md index c487295b27..5ea0747183 100644 --- a/_includes/specials/bech32/01-intro.md +++ b/_includes/specials/bech32/01-intro.md @@ -98,5 +98,5 @@ addresses. For most platforms, it should be a very easy change. See set of test vectors you can use to ensure your implementation works correctly. -[bech32 proposed]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013749.html +[bech32 proposed]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013749.html [bech32 ref libs]: https://github.com/sipa/bech32/tree/master/ref diff --git a/_includes/specials/bech32/02-stats.md b/_includes/specials/bech32/02-stats.md index 8bf952c5bb..b8da8dd960 100644 --- a/_includes/specials/bech32/02-stats.md +++ b/_includes/specials/bech32/02-stats.md @@ -6,8 +6,7 @@ track various segwit adoption statistics so that you can decide whether it's popular enough that your wallet or service might become an outlier by failing to support it soon. -Optech tracks statistics about segwit use on our [dashboard][optech -dashboard]; another site tracking related statistics is [P2SH.info][]. +A site tracking related statistics is [P2SH.info][]. We see an average of about 200 outputs per block are sent to native segwit addresses (bech32). Those outputs are then spent in about 10% of all Bitcoin transactions. That makes payments involving native segwit addresses @@ -46,8 +45,7 @@ other community efforts will help convince the stragglers to catch up on bech32 sending support so that all wallets that want to take advantage of native segwit can do so in the next few months. -[bech32 easy]: {{news38}}#bech32-sending-support -[optech dashboard]: https://dashboard.bitcoinops.org/ +[bech32 easy]: /en/newsletters/2019/03/19/#bech32-sending-support [p2sh.info]: https://p2sh.info/ [bech32 adoption]: https://en.bitcoin.it/wiki/Bech32_adoption [when segwit]: https://whensegwit.com/ diff --git a/_includes/specials/bech32/03-python-ref.md b/_includes/specials/bech32/03-python-ref.md index 5397d0ad0e..5a4bee0dec 100644 --- a/_includes/specials/bech32/03-python-ref.md +++ b/_includes/specials/bech32/03-python-ref.md @@ -86,7 +86,7 @@ The Gemini exchange also [apparently][gemini reddit] added bech32 sending support this week, and users report that Gemini defaults to accepting deposits to bech32 addresses as well. -[bech32 easy]: {{news38}}#bech32-sending-support +[bech32 easy]: /en/newsletters/2019/03/19/#bech32-sending-support [bech32 reference libraries]: https://github.com/sipa/bech32/tree/master/ref [segwit addr to bytes]: https://github.com/sipa/bech32/blob/master/ref/python/tests.py#L30 [bitgo segwit]: https://blog.bitgo.com/native-segwit-addresses-via-bitgos-api-4946f2007be9 diff --git a/_includes/specials/bech32/04-ecc.md b/_includes/specials/bech32/04-ecc.md index 3a286e3418..db32ed5b46 100644 --- a/_includes/specials/bech32/04-ecc.md +++ b/_includes/specials/bech32/04-ecc.md @@ -1,4 +1,4 @@ -In [last week's newsletter][Newsletter #40], we used the Python +In [last week's newsletter][Newsletter #40 bech32], we used the Python reference library for bech32 to decode an address into a scriptPubKey that you could pay. However, sometimes the user provides an address containing a typo. The code we suggested would detect the typo and @@ -27,7 +27,7 @@ Followed by including it in our HTML: ``` For convenience, we've included that file on the [web -version][Newsletter #41] of this newsletter, so you can follow along +version][Newsletter #41 bech32] of this newsletter, so you can follow along with the rest of this example by simply opening the developer console in your web browser. Let's start by checking a valid address. Recall from last week that we provide the network identifier when checking an @@ -131,3 +131,5 @@ feature. [javascript sample code]: https://github.com/sipa/bech32/tree/master/ecc/javascript [interactive demo]: http://bitcoin.sipa.be/bech32/demo/demo.html [bech32 errors]: https://github.com/sipa/bech32/blob/master/ecc/javascript/segwit_addr_ecc.js#L54 +[newsletter #40 bech32]: /en/newsletters/2019/04/02/#bech32-sending-support +[newsletter #41 bech32]: /en/newsletters/2019/04/09/#bech32-sending-support diff --git a/_includes/specials/bech32/06-stackexchange.md b/_includes/specials/bech32/06-stackexchange.md index 0ea5bc9a20..a901ed0d96 100644 --- a/_includes/specials/bech32/06-stackexchange.md +++ b/_includes/specials/bech32/06-stackexchange.md @@ -37,7 +37,7 @@ everything since bech32 was first announced about two years ago. various block explorers should check the [bech32 adoption][] Bitcoin Wiki page. -[bech32 easy]: {{news38}}#bech32-sending-support +[bech32 easy]: /en/newsletters/2019/03/19/#bech32-sending-support [top bech32 qa]: https://bitcoin.stackexchange.com/search?tab=votes&q=bech32 [bech32 adoption]: https://en.bitcoin.it/wiki/Bech32_adoption {% endauto_anchor %} diff --git a/_includes/specials/bech32/07-altbech32.md b/_includes/specials/bech32/07-altbech32.md index 9908db7798..fea2b70295 100644 --- a/_includes/specials/bech32/07-altbech32.md +++ b/_includes/specials/bech32/07-altbech32.md @@ -49,4 +49,5 @@ probably worth your time to implement it for Bitcoin too. [blockstream liquid]: https://blockstream.com/liquid/ [confidential assets]: https://elementsproject.org/features/confidential-transactions [blech32 py]: https://github.com/ElementsProject/elements/commit/9cb2fa051fcbe0fe66f15e6b88d224d1935376f4#diff-265badc7e18059096c32a61b0eada470 +[output script descriptors]: https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md {% endauto_anchor %} diff --git a/_includes/specials/bech32/08-upgradability.md b/_includes/specials/bech32/08-upgradability.md index 9c094aa302..1c93141934 100644 --- a/_includes/specials/bech32/08-upgradability.md +++ b/_includes/specials/bech32/08-upgradability.md @@ -52,4 +52,4 @@ into providing bech32 sending support now is something you won't need to repeat when future expected changes to the Bitcoin protocol are deployed. -[news40 bech32]: {{news40}}#bech32-sending-support +[news40 bech32]: /en/newsletters/2019/04/02/#bitcoin-core-schedules-switch-to-default-bech32-receiving-addresses diff --git a/_includes/specials/bech32/09-qrcode.md b/_includes/specials/bech32/09-qrcode.md index bc7ff17f39..d2d5229d9a 100644 --- a/_includes/specials/bech32/09-qrcode.md +++ b/_includes/specials/bech32/09-qrcode.md @@ -29,6 +29,7 @@ same dimensions). {:.center}
    + Unfortunately, the `?` and `&` needed for passing additional parameters in a BIP21 URI are not part of the QR code uppercase character set, so only binary mode can be used for those characters. Additionally, BIP21 specifies that query @@ -49,6 +50,7 @@ code possible: ![BIP21/bech32 mixed character mode](/img/posts/2019-05-bip21-bech32-qr-mixed.png) {:.center} +
    In summary, when using bech32 addresses in QR codes, consider @@ -78,7 +80,9 @@ accordingly. characters are allowed in bech32 HRPs but are not part of the QR code uppercase alphanumeric set: - !"#&'()';<=>?@[\]^_`{|}~ + ``` + !"#&'()';<=>?@[\]^_`{|}~ + ``` None of the bech32 HRPs used in Bitcoin (bc, tb, bcrt) use any of these characters, and neither does any other application as far as diff --git a/_includes/specials/bech32/10-snooze-lose.md b/_includes/specials/bech32/10-snooze-lose.md index 1e32aaa592..0e77ab2e31 100644 --- a/_includes/specials/bech32/10-snooze-lose.md +++ b/_includes/specials/bech32/10-snooze-lose.md @@ -28,12 +28,14 @@ If you haven't implemented bech32 sending support yet, we suggest you try to get it implemented by 24 August 2019 (the two-year anniversary of segwit activation). Not long after that, Bitcoin Core's next release is expected to begin defaulting to bech32 receiving addresses in its GUI -and perhaps also its API methods (see Newsletters [#40][Newsletter #40] -and [#42][Newsletter #42]). We expect other wallets to do the +and perhaps also its API methods (see Newsletters [#40][Newsletter #40 bech32] +and [#42][Newsletter #42 bech32]). We expect other wallets to do the same---except for the ones that have already made bech32 their default (or even their only supported address format). [nullc bank analogy]: https://old.reddit.com/r/Bitcoin/comments/9iw1p2/hey_guys_its_time_to_make_bech32_standard_on/e6onq8t/ [over 200,000 bitcoins]: https://p2sh.info/dashboard/db/p2wpkh-statistics?orgId=1 -[news38 bech32]: {{news38}}#bech32-sending-support -[news40 bech32]: {{news40}}#bech32-sending-support +[news38 bech32]: /en/newsletters/2019/03/19/#bech32-sending-support +[news40 bech32]: /en/newsletters/2019/04/02/#bech32-sending-support +[newsletter #40 bech32]: /en/newsletters/2019/04/02/#bitcoin-core-schedules-switch-to-default-bech32-receiving-addresses +[newsletter #42 bech32]: /en/newsletters/2019/04/16/#bitcoin-core-15711 diff --git a/_includes/specials/bech32/11-only-bech32.md b/_includes/specials/bech32/11-only-bech32.md index 85596166b4..9d78209954 100644 --- a/_includes/specials/bech32/11-only-bech32.md +++ b/_includes/specials/bech32/11-only-bech32.md @@ -37,16 +37,16 @@ of this wallet in Februray 2019 --> issues this may create with software and services that haven't upgraded to bech32 sending support yet: - ![Dialog in Electrum allowing the user to choose the address type - and warning them that some services may not support bech32 - addresses](/img/posts/2019-05-electrum-choose-wallet-type.png) + ![Dialog in Electrum allowing the user to choose the address type + and warning them that some services may not support bech32 + addresses](/img/posts/2019-05-electrum-choose-wallet-type.png) - Please note that it's neither required nor recommended for wallet - authors to create a new seed in order to support a new address - format. Other wallets, such as Bitcoin Core 0.16.0 and above, can - produce legacy, p2sh-segwit, and bech32 addresses all from the same - seed---the user just needs to specify which address type they want - (if they don't want the default). + Please note that it's neither required nor recommended for wallet + authors to create a new seed in order to support a new address + format. Other wallets, such as Bitcoin Core 0.16.0 and above, can + produce legacy, p2sh-segwit, and bech32 addresses all from the same + seed---the user just needs to specify which address type they want + (if they don't want the default). As time goes on, we expect more new wallets to only implement receiving to the current best address format. Today that's v0 segwit addresses for @@ -61,5 +61,5 @@ their preferred wallet. [wasabi wallet]: https://wasabiwallet.io/ [trust wallet]: https://trustwallet.com/ [electrum]: https://electrum.org/ -[news45 bech32]: {{news45}}#bech32-sending-support +[news45 bech32]: /en/newsletters/2019/05/07/#bech32-sending-support {% endauto_anchor %} diff --git a/_includes/specials/bech32/13-adoption-speed.md b/_includes/specials/bech32/13-adoption-speed.md index 8833b4f7f5..c9c61d1e00 100644 --- a/_includes/specials/bech32/13-adoption-speed.md +++ b/_includes/specials/bech32/13-adoption-speed.md @@ -52,4 +52,4 @@ activation. With some wallets already defaulting to bech32 and several more planning to do so in the coming months, we expect to see increased adoption before the end of 2019. -[bech32 fees]: {{news42}}#bech32-sending-support +[bech32 fees]: /en/newsletters/2019/04/16/#bech32-sending-support diff --git a/_includes/specials/bech32/14-security.md b/_includes/specials/bech32/14-security.md index d4d47a693f..aaea64abda 100644 --- a/_includes/specials/bech32/14-security.md +++ b/_includes/specials/bech32/14-security.md @@ -113,5 +113,5 @@ bech32 sending support so that they can send payments to those security-conscious users. [bech32 fee savings]: /en/bech32-sending-support/#fee-savings-with-native-segwit -[sipa collision resistance]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012205.html +[sipa collision resistance]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012205.html [collision attack]: https://en.wikipedia.org/wiki/Collision_attack diff --git a/_includes/specials/bech32/17-signmessage.md b/_includes/specials/bech32/17-signmessage.md index ef093cd46e..8df78511a3 100644 --- a/_includes/specials/bech32/17-signmessage.md +++ b/_includes/specials/bech32/17-signmessage.md @@ -67,3 +67,4 @@ wallet developers to agree on a standard and then widely implement it. [trezor segwit signmessage]: https://github.com/trezor/trezor-mcu/issues/169 [electrum segwit signmessage]: https://github.com/spesmilo/electrum/issues/2977 [trezor electrum incompatible]: https://github.com/spesmilo/electrum/issues/3861 +[newsletter #13]: /en/newsletters/2018/09/18/#review-proposed-bip322-for-generic-message-signing diff --git a/_includes/specials/bech32/zh/01-intro.md b/_includes/specials/bech32/zh/01-intro.md new file mode 100644 index 0000000000..31b84db550 --- /dev/null +++ b/_includes/specials/bech32/zh/01-intro.md @@ -0,0 +1,58 @@ +Bech32 原生 segwit 地址几乎在两年前首次公开[提议][bech32 proposed]，并成为 [BIP173][] 标准。随后，segwit 软分叉于 2017 年 8 月 24 日锁定。然而，在锁定后十七个月，一些流行的钱包和服务仍然不支持向 bech32 地址发送比特币。其他钱包和服务的开发者已经厌倦了等待，希望默认接收 bech32 地址的付款，以便他们可以实现额外的费用节省和隐私改进。Newsletter 希望帮助这个过程，因此从现在到 segwit 锁定的两周年纪念，每一期的 Newsletter 都将包括一个简短的部分，提供资源以帮助全面部署 bech32 发送支持。 + +请注意，我们仅直接提倡 bech32 **发送**支持。这允许你支付的对象使用 segwit，但不要求你自己实现 segwit。（如果你想使用 segwit 来节省费用或访问其他好处，那很好！我们只是鼓励你先实现 bech32 发送支持，这样你支付的对象可以立即开始利用它，而你可以在升级其余代码和基础设施以全面支持 segwit 的同时进行。）为此，本周的部分重点展示了发送到传统地址和发送到 bech32 地址之间的差异有多小。 + +### 发送到传统地址 + +对于你已经支持的 P2PKH 传统地址，例如 1B6FkNg199ZbPJWG5zjEiDekrCc2P7MVyC，你的 base58check 库会将其解码为一个 20 字节的承诺： + + 6eafa604a503a0bb445ad1f6daa80f162b5605d6 + +这个承诺被插入到一个 scriptPubKey 模板中： + +
    OP_DUP OP_HASH160 OP_PUSH20 6eafa604a503a0bb445ad1f6daa80f162b5605d6 OP_EQUALVERIFY OP_CHECKSIG
    + +将操作码转换为十六进制，这看起来像： + + 76a9146eafa604a503a0bb445ad1f6daa80f162b5605d688ac + +这被插入到输出的 scriptPubKey 部分，该部分还包括脚本的长度（25 字节）和支付的金额： + +
         amount                           scriptPubKey
+|--------------|  |------------------------------------------------|
+00e1f505000000001976a9146eafa604a503a0bb445ad1f6daa80f162b5605d688ac
+                |
+    size: 0x19 -> 25 bytes
    + +这个输出可以添加到交易中，然后交易被签名并广播。 + +### 发送到 bech32 地址 + +对于等效的 bech32 P2WPKH 地址，例如 bc1qd6h6vp99qwstk3z668md42q0zc44vpwkk824zh，你可以使用其中一个[参考库][bech32 ref libs] 将地址解码为一对值： + + 0 6eafa604a503a0bb445ad1f6daa80f162b5605d6 + +这两个值也被插入到一个 scriptPubKey 模板中。第一个值是见证脚本版本字节，用于使用 `OP_0` 到 `OP_16` 的某个操作码将值添加到堆栈中。第二个值是也被推送到堆栈的承诺： + +
    OP_0 OP_PUSH20 6eafa604a503a0bb445ad1f6daa80f162b5605d6
    + +将操作码转换为十六进制，这看起来像： + + 00146eafa604a503a0bb445ad1f6daa80f162b5605d6 + +然后，就像之前一样，这被插入到输出的 scriptPubKey 部分： + +
         amount                        scriptPubKey
+|--------------|  |------------------------------------------|
+00e1f505000000001600146eafa604a503a0bb445ad1f6daa80f162b5605d6
+                |
+    size: 0x16 -> 22 bytes
    + +输出被添加到交易中。交易然后被签名并广播。 + +对于 bech32 P2WSH（P2SH 的 segwit 等效）或未来的 segwit 见证版本，你不需要做任何特殊的事情。见证脚本版本可能是一个不同的数字，需要你使用相应的 `OP_0` 到 `OP_16` 操作码，承诺可能是不同的长度（从 2 到 40 字节），但输出的其他部分不会改变。由于长度变化是允许的，确保你的费用估算软件考虑到 scriptPubKey 的实际大小，而不是使用以前根据 P2PKH 或 P2SH 大小计算的常数。 + +以上是你需要在软件后端进行的全部更改，以启用发送到 bech32 地址。对于大多数平台，这应该是一个非常简单的更改。参见 [BIP173][] 和[参考实现][bech32 ref libs]以获取一组测试向量，用于确保你的实现正常工作。 + +[bech32 proposed]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013749.html +[bech32 ref libs]: https://github.com/sipa/bech32/tree/master/ref diff --git a/_includes/specials/bech32/zh/02-stats.md b/_includes/specials/bech32/zh/02-stats.md new file mode 100644 index 0000000000..8f99b80428 --- /dev/null +++ b/_includes/specials/bech32/zh/02-stats.md @@ -0,0 +1,18 @@ +正如[上周所述][bech32 easy]，实现 segwit 仅花费应当是容易的。然而我们怀疑一些管理者可能会想知道是否有足够多人使用 segwit 来证明他们的团队值得在此方面花费开发精力。本周，我们查看了追踪各种 segwit 采用统计数据的网站，以便你可以决定它是否足够流行，以至于你的钱包或服务如果不支持它会成为异类。 + +Optech 在我们的仪表盘上追踪 segwit 使用的统计数据；另一个追踪相关统计数据的网站是 [P2SH.info][]。我们看到平均每个区块大约有 200 个输出被发送到原生 segwit 地址 (bech32)。这些输出随后在大约 10% 的比特币交易中被花费。使得涉及原生 segwit 地址的支付比几乎所有的山寨币都更受欢迎。 + +![Optech 仪表盘 segwit 使用统计数据的截图](/img/posts/2019-03-segwit-usage.png) + +然而，许多钱包想要使用 segwit 但仍需要处理尚未支持 bech32 发送的服务。这些钱包可以生成一个引用其 segwit 详细信息的 P2SH 地址，这比使用 bech32 效率低，但比不使用 segwit 效率高。由于这些是普通的 P2SH 地址，仅通过查看交易输出我们无法判断哪些 P2SH 地址是预 segwit 的 P2SH 输出，哪些包含嵌套 segwit 承诺，因此我们不知道支付到嵌套 segwit 地址的实际数量。然而，当这些输出之一被花费时，花费者会揭示该输出是否是 segwit。上述统计网站报告，目前大约 37% 的交易包含至少一个嵌套 segwit 输出的花费。这对应于平均每个区块大约 1,400 个输出。 + +任何支持 P2SH 嵌套 segwit 地址的钱包也可能支持 bech32 原生地址，因此当前由希望利用 bech32 发送支持的钱包进行的交易数量超过 45% 且在不断增加。 + +为了进一步评估 segwit 的流行度，你可能还想知道哪些值得注意的比特币钱包和服务支持它。为此，我们推荐社区维护的比特币 Wiki 上的 [bech32 adoption][] 页面或由 BRD 钱包维护的 [when segwit][] 页面。 + +统计数据和兼容性数据显示 segwit 已经得到了良好的支持并且经常使用，但仍有一些值得注意的迟缓者尚未提供支持。我们希望我们的活动和其他社区努力将帮助说服这些迟缓者赶上 bech32 发送支持，以便所有希望利用原生 segwit 的钱包可以在接下来的几个月中做到这一点。 + +[bech32 easy]: /zh/newsletters/2019/03/19/#bech32-发送支持 +[p2sh.info]: https://p2sh.info/ +[bech32 adoption]: https://en.bitcoin.it/wiki/Bech32_adoption +[when segwit]: https://whensegwit.com/ diff --git a/_includes/specials/bech32/zh/03-python-ref.md b/_includes/specials/bech32/zh/03-python-ref.md new file mode 100644 index 0000000000..37e4c32428 --- /dev/null +++ b/_includes/specials/bech32/zh/03-python-ref.md @@ -0,0 +1,56 @@ +在[前几周][bech32 easy]，我们讨论了创建传统地址输出与原生 segwit 地址输出之间的差异有多小。在那一部分中，我们简单地指引你参考 [bech32 参考库][bech32 reference libraries]并告诉你会得到两个值。本周，我们详细演示使用 Python 参考库的确切步骤，以便你可以看到工作量有多小。我们从导入库开始： + +```python3 +>>> import segwit_addr +``` + +Bech32 地址有一个可读部分 (HRP)，用于指示地址所属的网络。这些是地址的前几个字符，并由分隔符 `1` 与地址的数据部分分开。例如，比特币测试网使用 `tb`，一个示例测试网地址是 tb1q3w[...]g7a。我们将在代码中设置比特币主网的 HRP `bc`，以便我们可以确保解析的地址属于我们期望的网络。 + +```python3 +>>> HRP='bc' +``` + +最后，我们有几个要检查的地址——一个应该有效，两个应该无效。（参见 [BIP173][] 以获取完整的[参考测试向量][bip173 test vectors]。） + +```python3 +>>> good_address='bc1qd6h6vp99qwstk3z668md42q0zc44vpwkk824zh' +>>> typo_address='bc1qd6h6vp99qwstk3z669md42q0zc44vpwkk824zh' +>>> wrong_network_address='tb1q3wrc5yq9c300jxlfeg7ae76tk9gsx044ucyg7a' +``` + +现在我们可以尝试解码每个地址 + +```python3 +>>> segwit_addr.decode(HRP, good_address) +(0, [110, 175, 166, 4, 165, 3, 160, 187, 68, 90, 209, + 246, 218, 168, 15, 22, 43, 86, 5, 214]) + +>>> segwit_addr.decode(HRP, typo_address) +(None, None) + +>>> segwit_addr.decode(HRP, wrong_network_address) +(None, None) +``` + +如果我们得到的第一个值（见证版本）是 None，则该地址在我们选择的网络上无效。如果发生这种情况，你需要在堆栈上抛出异常，以便与用户交互的过程可以让他们提供正确的地址。如果你得到一个数字和一个数组，则解码成功，校验和有效，长度在允许范围内。 + +见证版本必须是 0 到 16 之间的数字，因此你需要检查（例如 `0 <= x <= 16`），然后将其转换为相应的操作码 `OP_0` 到 `OP_16`。对于 `OP_0`，这是 0x00；对于 `OP_1` 到 `OP_16`，这是 0x51 到 0x60。然后你需要根据数据的长度添加一个推字节（2 到 40 字节为 0x02 到 0x28），然后将数据作为字节序列附加。Pieter Wuille 的[代码][segwit addr to bytes]很简洁地完成了这一点： + +```python3 +>>> witver, witprog = segwit_addr.decode(HRP, good_address) +>>> bytes([witver + 0x50 if witver else 0, len(witprog)] + witprog).hex() +'00146eafa604a503a0bb445ad1f6daa80f162b5605d6' +``` + +这就是你的完整 scriptPubKey。你可以在交易的输出中使用它并发送它。请注意，bech32 scriptPubKeys 的大小可以从 4 到 42 vbytes 不等，因此你需要在费用估算代码中考虑 scriptPubKey 的实际大小。 + +你的代码不需要用 Python 编写。参考库也提供了 C、C++、Go、Haskell、JavaScript、Ruby 和 Rust 的版本。此外，[BIP173][] 对 bech32 的描述非常详细，以至于任何优秀的程序员都可以在他们首选的语言中从头实现它，而不需要超出大多数编程语言内置和标准库提供的功能。 + +**其他 bech32 发送支持更新：** BitGo [宣布][bitgo segwit]他们的 API 现在支持发送到 bech32 地址；请参阅他们的公告以获取有关 bech32 接收支持的更多详细信息。Gemini 交易所本周也[显然][gemini reddit]添加了 bech32 发送支持，并且用户报告称 Gemini 默认接受存款到 bech32 地址。 + +[bech32 easy]: /zh/newsletters/2019/03/19/#bech32-发送支持 +[bech32 reference libraries]: https://github.com/sipa/bech32/tree/master/ref +[segwit addr to bytes]: https://github.com/sipa/bech32/blob/master/ref/python/tests.py#L30 +[bitgo segwit]: https://blog.bitgo.com/native-segwit-addresses-via-bitgos-api-4946f2007be9 +[gemini reddit]: https://www.reddit.com/r/Bitcoin/comments/b66n0v/psa_gemini_is_full_on_with_native_segwit_and_uses/ +[bip173 test vectors]: https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#Test_vectors diff --git a/_includes/specials/bech32/zh/04-ecc.md b/_includes/specials/bech32/zh/04-ecc.md new file mode 100644 index 0000000000..aa8dddb265 --- /dev/null +++ b/_includes/specials/bech32/zh/04-ecc.md @@ -0,0 +1,98 @@ +在[上周的 Newsletter][Newsletter #40 bech32] 中，我们使用 Python 参考库对 bech32 进行了演示，将一个地址解码为一个 scriptPubKey，您可以支付给该地址。然而，有时用户提供的地址会包含一个拼写错误。我们建议的代码可以检测到拼写错误，确保您不会支付到错误的地址，但 bech32 也可以帮助检测用户拼写错误的位置。本周，我们将使用 [Javascript 示例代码][javascript sample code]来展示这种功能。 + +该代码使用 Node.js 风格的模块包含语法编写，所以第一步是将其编译为可以在浏览器中使用的代码。为此，我们需要安装一个 [browserify][] 工具： + +```bash +sudo apt install node-browserify-lite +``` + +然后将其编译为一个独立文件： + +```bash +browserify-lite ./segwit_addr_ecc.js --outfile bech32-demo.js --standalone segwit_addr_ecc +``` + +接着将其包含在我们的 HTML 中： + +```html + +``` + +为了方便，我们已在该 Newsletter 的[网页版][Newsletter #41 bech32] 中包含了该文件，因此您只需打开 Web 浏览器中的开发者控制台，就可以按照本例的其余部分操作。让我们从检查一个有效地址开始。回想一下上周，我们在检查地址时提供了网络标识符（`bc` 表示 Bitcoin 主网）： + +```text +>> segwit_addr_ecc.check('bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4', 'bc') +error: null +program: Array(20) [ 117, 30, 118, … ] +version: 0 +``` + +如上所示，就像上周一样，我们得到见证版本和见证程序。版本字段的存在，加上没有错误，表明该程序解码时没有任何校验和失败。 + +现在我们在上面的地址中替换一个字符，并尝试检查它： + +```text +>> segwit_addr_ecc.check('bc1qw508d6qejxtdg4y5r4zarvary0c5xw7kv8f3t4', 'bc') +error: "Invalid" +pos: Array [ 21 ] +``` + +这次我们得到了错误的描述（地址无效，因为它不匹配其校验和）和一个位置。如果我们将上面的地址逐个字符对齐，可以看到这个“21”标识了特定错误的位置： + +```text + 1x 2x + 0123456789012345678901 +>> good='bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4' +>> typo='bc1qw508d6qejxtdg4y5r4zarvary0c5xw7kv8f3t4' + ^ +``` + +如果我们对拼写错误的地址进行另一次替换并再次尝试会怎样？ + +```text +>> segwit_addr_ecc.check('bc1qw508d6qejxtdg4y5r4zarvary0c5yw7kv8f3t4', 'bc') +error: "Invalid" +pos: Array [ 32, 21 ] +``` + +我们得到两个位置。同样，当我们将这些地址逐个字符对齐，可以看到它识别了两个不正确的字符： + +```text + 1x 2x 3x + 012345678901234567890123456789012 +>> good='bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4' +>> typo='bc1qw508d6qejxtdg4y5r4zarvary0c5yw7kv8f3t4' + ^ ^ +``` + +Pieter Wuille 的[互动演示][interactive demo] 包含几行额外的代码（在该页面查看源代码以查看该函数），该代码使用拼写错误字符的位置将其以红色突出显示： + +![bech32 互动演示的截图，拼写错误的地址位于上方](/img/posts/2019-04-bech32-demo.png) + +`check()` 函数能够具体识别的错误数量有限。之后，它仍然可以告诉您地址包含错误，但无法识别地址中的具体位置。在这种情况下，它仍然会返回地址无效，但不会返回位置详细信息： + +```text +>> segwit_addr_ecc.check('bc1qw508z6qejxtdg4y5r4zarvary0c5yw7kv8f3t4', 'bc') +error: "Invalid" +pos: null +``` + +如果地址存在其他问题，`error` 字段将设置为更具描述性的信息，这些信息可能会也可能不会包含错误的位置。例如： + +```text +>> segwit_addr_ecc.check('bc1zw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4yolo', 'bc') +error: "Invalid character" +pos: Array [ 43 ] +``` + +您可以查看[源代码][bech32 errors]以获取完整的错误列表。 + +尽管我们在这个迷你教程中花了很多时间研究错误，但我们希望展示在基于 Web 的平台上为用户提供 bech32 地址时提供良好互动反馈是多么容易。我们鼓励您玩转[互动演示][interactive demo]，以了解如果您使用这种 bech32 地址功能，您的用户可能会看到什么。 + + +[browserify]: http://browserify.org/ +[javascript sample code]: https://github.com/sipa/bech32/tree/master/ecc/javascript +[interactive demo]: http://bitcoin.sipa.be/bech32/demo/demo.html +[bech32 errors]: https://github.com/sipa/bech32/blob/master/ecc/javascript/segwit_addr_ecc.js#L54 +[newsletter #40 bech32]: /zh/newsletters/2019/04/02/#bech32-发送支持 +[newsletter #41 bech32]: /zh/newsletters/2019/04/09/#bech32-发送支持 diff --git a/_includes/specials/bech32/zh/05-fee-savings.md b/_includes/specials/bech32/zh/05-fee-savings.md new file mode 100644 index 0000000000..e3f5e76e43 --- /dev/null +++ b/_includes/specials/bech32/zh/05-fee-savings.md @@ -0,0 +1,23 @@ +{% auto_anchor %} +你的用户和客户希望你实现 Bech32 发送支持的一个原因是它将允许那些支付接收者在重新花费这些钱时节省费用。本周，我们将看看他们能节省多少钱，并讨论他们的节省如何也能帮助你省钱。 + +对于在第一个版本的 Bitcoin 中实现的传统 P2PKH 地址格式，授权支出的 scriptSig 通常为 107 vbytes。对于 P2SH 包装的 segwit P2WPKH，相同的信息被移动到一个见证数据字段，该字段仅消耗四分之一的 vbytes（27 vbytes），但其 P2SH 开销增加了 23 vbytes，总共 50 vbytes。对于原生 segwit P2WPKH，没有 P2SH 开销，因此仅使用 27 vbytes。 + +这意味着你可以说 P2SH-P2WPKH 比 P2PKH 节省了超过 50%，而 P2WPKH 比 P2SH-P2WPKH 再节省几乎 50%，或者比 P2PKH 单独节省 75%。然而，支出交易不仅包含 scriptSigs 和见证数据，所以我们通常比较节省的方法是看原型交易。例如，我们想象一个典型的交易，包含一个输入和两个输出（一个给接收者；一个作为找零返回给支出者）。在这种情况下： + +- 支出 P2PKH 的总交易大小为 220 vbytes +- 支出 P2SH-P2WPKH 的大小为 167 vbytes（节省 24%） +- 支出 P2WPKH 输出的大小为 141 vbytes（比 P2SH-P2WPKH 节省 16% 或比 P2PKH 节省 35%） + +要比较简单的 multisig 交易（那些只使用单个 `OP_CHECKMULTSIG` 操作码的交易），事情会变得更复杂，因为 k-of-n multisig 输入的大小取决于签名的数量（k）和公钥的数量（n）。所以，为了简单起见，我们只会绘制传统 P2SH-multisig 与包装 P2SH-P2WSH multisig（最多支持 15-of-15 的传统 P2SH）的大小。我们可以看到，切换到 P2SH-P2WSH 可以节省大约 40%（1-of-2 multisig）到大约 70%（15-of-15）。 + +![多重签名交易大小图（P2SH 和 P2SH-P2WSH）](/img/posts/2019-04-segwit-multisig-size-p2sh-to-p2sh-p2wsh.png) + +然后我们可以将 P2SH-P2WSH 与原生 P2WSH 比较，看到每个交易额外节省大约 35 字节或大约 5% 到 15%。 + +![多重签名交易大小图（P2SH-P2WSH 和 P2WSH）](/img/posts/2019-04-segwit-multisig-size-p2sh-p2wsh-to-p2wsh.png) + +上述脚本描述了几乎所有未使用原生 segwit 地址的脚本。（使用更复杂脚本的用户，例如在闪电网络中使用的脚本，今天大多使用原生 segwit。）这些效率较低的脚本类型目前消耗了区块容量（总区块权重）的主要部分。切换到原生 segwit 以减少交易的权重，可以在不改变确认时间的情况下，以相同比例降低费用——其他所有条件相同。 + +但是其他所有条件并不相同。由于交易使用较少的区块权重，其他交易有更多的权重可用。如果可用区块权重的供应增加，而需求保持不变，我们预计价格会下降（除非它们已经达到默认的最低中继费用）。这意味着更多使用原生 segwit 输入的人不仅降低了那些支出者的费用，也降低了所有创建交易的人的费用——包括支持发送到 Bech32 地址的钱包和服务。 +{% endauto_anchor %} diff --git a/_includes/specials/bech32/zh/06-stackexchange.md b/_includes/specials/bech32/zh/06-stackexchange.md new file mode 100644 index 0000000000..7e2bac7056 --- /dev/null +++ b/_includes/specials/bech32/zh/06-stackexchange.md @@ -0,0 +1,21 @@ +{% auto_anchor %} +本周我们来看一些来自 Bitcoin Stack Exchange 的[最高票数 bech32 问题和答案][top bech32 qa]。这些问题和答案涵盖了自 bech32 大约两年前首次发布以来的所有内容。 + +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- ****[Schnorr 软分叉是否会引入新的地址格式？]({{bse}}82952) + 尽管升级到 bech32 发送支持应该很容易，但你可能不希望为 Bitcoin 的下一个升级或之后的升级重复这项工作。Pieter Wuille 通过解释如何在使用基于 Schnorr 的公钥和签名时仍然使用 bech32 地址来回答这个问题。（Optech 将在未来的部分中更详细地讨论这个问题。） + +- ****[将 bech32 P2WPKH 地址转换为传统 P2PKH 地址是否安全？]({{bse}}62207) + 如果你阅读了 [Newsletter #38][bech32 easy]，你会注意到对于相同的底层公钥，P2WPKH 和 P2PKH 地址之间的区别仅在于 scriptPubKey 中的几个字符，使得可以自动将一个转换为另一个。Andrew Chow 和其附带评论的答案解释了为什么这是一个糟糕的主意，可能会导致用户丢失资金。 + +- ****[为什么 bech32 解码函数需要指定地址的可读部分 (HRP) 而不是自动提取？]({{bse}}83454) + HRP 由一个 `1` 与地址的其他部分分开，所以解码器似乎可以自己忽略该部分。Pieter Wuille 解释说，使用预期的 HRP 调用解码器可以确保你不会意外地将 bitcoin 支付到一个用于测试网、莱特币或其他网络的地址。Gregory Maxwell 还纠正了提问者的另一个假设。 + +- ****[哪些区块浏览器识别 bech32 地址？]({{bse}}66458) + 在 bech32 首次提出两年多后以及该问题首次被提出一年后，几个流行的区块浏览器仍然不支持 bech32 地址的搜索或显示。这个问题的答案建议任何想了解各种区块浏览器 bech32 支持状态的人应该查看 [bech32 采用][bech32 adoption] Bitcoin Wiki 页面。 + +[bech32 easy]: /zh/newsletters/2019/03/19/#bech32-发送支持 +[top bech32 qa]: https://bitcoin.stackexchange.com/search?tab=votes&q=bech32 +[bech32 adoption]: https://en.bitcoin.it/wiki/Bech32_adoption +{% endauto_anchor %} diff --git a/_includes/specials/bech32/zh/07-altbech32.md b/_includes/specials/bech32/zh/07-altbech32.md new file mode 100644 index 0000000000..9cbf8b7027 --- /dev/null +++ b/_includes/specials/bech32/zh/07-altbech32.md @@ -0,0 +1,27 @@ +{% auto_anchor %} +常言道：“模仿是最真诚的恭维。” 在本周的部分，我们快速了解了一些使用 bech32 变体的其他系统。如果你已经需要为另一个项目实现类似 bech32 的东西，那么为 Bitcoin 实现它可能值得你花时间。 + +- ******LN 发票** 使用带有扩展的可读部分 (HRP) 的 bech32 格式，并且没有 bech32 通常的 90 字符限制。详见 [BOLT11][] 的完整规范。示例： + `lnbc2500u1pvjluezpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdq5xysxxatsyp3k7enxv4jsxqzpuaztrnwngzn3kdzw5hydlzf03qdgm2hdq27cqv3agm2awhz5se903vruatfhq77w3ls4evs3ch9zw97j25emudupq63nyw24cg27h2rspfj9srp` + +- ******Bitcoin Cash 新型地址** 使用 HRP 为 `bitcoincash` 和分隔符 `:` 的 bech32 格式。与 Bitcoin 中的版本字节编码 segwit 见证版本不同，它表示地址编码的哈希应该用于 P2PKH 还是 P2SH。详见 [spec-cashaddr][] 的完整规范。示例： + `bitcoincash:qpm2qsznhks23z7629mms6s4cwef74vcwvy22gdx6a` + +- ******备份种子：** 2018 年 6 月，Jonas Schnelli 提出了 Bech32X，一种使用 bech32 进行错误校正来编码 Bitcoin 私钥、扩展私钥 (xprivs) 和扩展公钥 (xpubs) 的方案。详见完整的[草案规范][bech32x]。示例： + `pk1lmll7u25wppjn5ghyhgm7kndgjwgphae8lez0gra436mj7ygaptggl447a4xh7` + +- ******基于 Elements 的侧链：** 基于 [ElementsProject.org][] 的侧链，如 [Blockstream Liquid][]，使用 bech32 地址和一种称为 “blech32” 地址的变体。Blech32 地址旨在与该平台的[保密资产][confidential assets]一起使用，并将很快由 Liquid 侧链的 Esplora 块浏览器支持。我们不知道 blech32 的规范文档，但[此代码][blech32 py]被标记为参考实现，并在项目其他地方被引用为 “参见 liquid_addr.py 获取与 bech32 的紧凑差异。” blech32 地址示例： + `lq1qqf8er278e6nyvuwtgf39e6ewvdcnjupn9a86rzpx655y5lhkt0walu3djf9cklkxd3ryld97hu8h3xepw7sh2rlu7q45dcew5` + +- ******输出脚本描述符：** 尽管与 bech32 的关系不那么直接，但基于 bech32 使用的 Bose-Chaudhuri-Hocquenghem (BCH) 码的校验和已被添加到 Bitcoin Core 支持的[输出脚本描述符][output script descriptors] 中。详见 Pieter Wuille 的[详细评论][descriptors checksum]。示例： + `wpkh([f6bb4c63/0'/0'/28']02bf9d38386db60191f2f785cbf7ba90d01bed5958efb7b449a552b89da7550177)#efkksxw6` + +[descriptors checksum]: https://github.com/bitcoin/bitcoin/blob/fd637be8d21a606e98c037b40b268c4a1fae2244/src/script/descriptor.cpp#L24 +[spec-cashaddr]: https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/cashaddr.md +[bech32x]: https://gist.github.com/jonasschnelli/68a2a5a5a5b796dc9992f432e794d719 +[elementsproject.org]: https://elementsproject.org/ +[blockstream liquid]: https://blockstream.com/liquid/ +[confidential assets]: https://elementsproject.org/features/confidential-transactions +[blech32 py]: https://github.com/ElementsProject/elements/commit/9cb2fa051fcbe0fe66f15e6b88d224d1935376f4#diff-265badc7e18059096c32a61b0eada470 +[output script descriptors]: https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md +{% endauto_anchor %} diff --git a/_includes/specials/bech32/zh/08-upgradability.md b/_includes/specials/bech32/zh/08-upgradability.md new file mode 100644 index 0000000000..d5c367abf1 --- /dev/null +++ b/_includes/specials/bech32/zh/08-upgradability.md @@ -0,0 +1,30 @@ +bip-taproot 和 bip-tapscript 对已经实现 Bech32 发送支持或计划实现的人员意味着什么？特别是，如果您尚未实现 Segwit 发送支持，是否应等待新功能激活后再实现？在本周的章节中，我们将展示为何您不应等待，以及现在实现发送支持将来不会增加额外工作量的原因。 + +Segwit 和 Bech32 的设计者对未来协议改进有一个大致的想法，因此他们设计了 Segwit scriptPubKeys 和 Bech32 地址格式，以便与这些预期的改进向前兼容。例如，支持 Taproot 的地址可能如下所示： + +```text +bc1pqzkqvpm76ewe20lcacq740p054at9sv7vxs0jn2u0r90af0k63332hva8pt +``` + +您会注意到它看起来就像您见过的其他 Bech32 地址——因为它确实如此。您可以使用我们在 [Newsletter #40][] 中提供的相同代码（使用 Bech32 参考库的 Python）来解码它。 + +```python +>> import segwit_addr +>> address='bc1pqzkqvpm76ewe20lcacq740p054at9sv7vxs0jn2u0r90af0k63332hva8pt' +>> witver, witprog = segwit_addr.decode('bc', address) +>> witver +1 +>> bytes(witprog).hex() +'00ac06077ed65d953ff8ee01eabc2fa57ab2c19e61a0f94d5c78cafea5f6d46315' +``` + +与我们在以前的 Newsletters 中显示的解码 Bech32 地址的区别在于，这个假设的 Taproot 地址使用 `1` 的见证版本，而不是 `0`（意味着 scriptPubKey 将以 `OP_1` 开头，而不是 `OP_0`），并且见证程序比 P2WSH 见证程序长一个字节。然而，如果您只是支出，这些对您的软件来说并不重要。我们可以使用 [Newsletter #40][news40 bech32] 中的相同示例代码来创建适合您支付的 scriptPubKey： + +```python +>> bytes([witver + 0x50 if witver else 0, len(witprog)] + witprog).hex() +'512100ac06077ed65d953ff8ee01eabc2fa57ab2c19e61a0f94d5c78cafea5f6d46315' +``` + +这意味着任何以 Newsletter #40 中描述的通用方式实现 Bech32 支持的人都不需要做任何特殊的事情来支持未来的脚本升级。简而言之，您现在提供 Bech32 发送支持的工作将来在比特币协议的预期变化部署时无需重复。 + +[news40 bech32]: /zh/newsletters/2019/04/02/#bitcoin-core-schedules-switch-to-default-bech32-receiving-addresses diff --git a/_includes/specials/bech32/zh/09-qrcode.md b/_includes/specials/bech32/zh/09-qrcode.md new file mode 100644 index 0000000000..1bd0161cfc --- /dev/null +++ b/_includes/specials/bech32/zh/09-qrcode.md @@ -0,0 +1,39 @@ +[BIP173][] 禁止 bech32 地址使用大小写混合。书写 bech32 地址的首选方式是全小写，但在某种情况下，全大写是有意义的：二维码。看看以下两个二维码，虽然它们的地址相同，但一个是小写，另一个是大写： + +![bech32 全大写](/img/posts/2019-05-bech32-qr-uc.png) +{:.center} + +这是 bech32 的一个故意设计特性。二维码可以用多种模式创建，这些模式支持不同的字符集。二进制模式字符集用于传统地址，因为它们需要混合大小写。然而，比特币的 Bech32 地址[^only-bc] 只使用数字和大写字母表示，因此它们可以使用较小的大写字母和数字字符集。因为这个字符集较小，它在二维码中对每个字符编码所使用的位更少，使得生成的二维码不那么复杂。 + +比特币地址通常在 [BIP21][] URI 中使用。BIP21 技术上要求 base58check 格式化，但至少一些支持原生 segwit 地址的钱包（如 Bitcoin Core）允许它们与 bech32 一起使用。虽然 BIP21 的方案标识符 `bitcoin:` 的首选形式是小写，但根据 BIP21 和 [RFC3986][] 的规定，它也可以大写。这也产生了一个不那么复杂的图像（尽管在这种情况下，我们的二维码编码库给了两个图像相同的尺寸）。 + +![bech32 全大写](/img/posts/2019-05-bip21-bech32-qr-uc.png) +{:.center} + +
    +不幸的是，BIP21 URI 中传递附加参数所需的 `?` 和 `&` 不属于二维码的大写字符集，因此只能为这些字符使用二进制模式。此外，BIP21 规定查询参数名称如 `amount` 和 `label` 是区分大小写的，所以它们的大写版本预计也不能正常工作。 + +{:#qrcode-edit} +然而，二维码可以支持混合字符集，当使用一个以全大写子字符串（包含 bech32 地址）开头或结尾的字符串时，这样做总是至少稍微更有效率。这是因为 bech32 地址的最小允许大小（14 个字符）与使用大写模式的效率增益（31.25%）相结合，超过了切换模式的最坏情况开销（20 个额外的比特）。我们知道的至少有两个二维码编码器 [libqrencode][]（C 语言）和 [node-qrcode][]（JS 语言），默认情况下会根据需要自动混合字符集，以生成最不复杂的二维码： + +![BIP21/bech32 混合字符模式](/img/posts/2019-05-bip21-bech32-qr-mixed.png) +{:.center} +
    + +总之，当在二维码中使用 bech32 地址时，考虑将它们和任何其他可以大写的相邻字符大写，以生成更小且不太复杂的二维码。（然而，出于其他所有目的，bech32 地址应使用全小写字符。） + +*更正：*本节的早期版本声称包含 BIP21 查询参数的二维码需要使用二进制模式。Nadav Ivgi 友好地[通知我们][ivgi tweet]，可以混合字符模式，因此我们已相应更新了本节的最后两段。 + +[rfc3986]: https://tools.ietf.org/html/rfc3986#section-3.1 +[ivgi tweet]: https://twitter.com/shesek/status/1131733590235131905 +[node-qrcode]: https://github.com/soldair/node-qrcode#mixed-modes +[libqrencode]: https://fukuchi.org/works/qrencode/ + +[^only-bc]: + Bech32 地址有三个部分，可读前缀 (HRP)，例如 `bc`，分隔符（始终为 `1`）和数据部分。分隔符和数据部分保证是二维码的*大写字母和数字*字符集的一部分，但根据 BIP173 允许在 HRP 中使用的字符范围包括不属于该大写字母和数字字符集的标点符号。具体来说，以下字符在 bech32 HRP 中是允许的，但不属于二维码大写字母和数字字符集： + + ``` + !"#&'()';<=>?@[\]^_`{|}~ + ``` + + 我们所知比特币中使用的 bech32 HRP（bc、tb、bcrt）都不使用这些字符，其他应用程序也没有使用。然而，在代码中，你可能不想假设非比特币 bech32 地址的二维码总是可以使用大写字母生成较小的二维码。 diff --git a/_includes/specials/bech32/zh/10-snooze-lose.md b/_includes/specials/bech32/zh/10-snooze-lose.md new file mode 100644 index 0000000000..a4f2b32322 --- /dev/null +++ b/_includes/specials/bech32/zh/10-snooze-lose.md @@ -0,0 +1,17 @@ +到目前为止，在我们鼓励钱包和服务支持发送到 Bech32 原生 Segwit 地址的系列文章中，我们几乎完全专注于技术信息。今天，这部分内容表达了一个观点：你延迟实现 Bech32 发送支持的时间越长，一些用户和潜在用户对你的软件或服务的评价就会越差。 + +> "他们只能支付到传统地址。"
    +> "哦。那我们找一个支持当前技术的服务吧。" + +仅支持传统地址的服务很可能会向用户传达出一个信号，即在维护其比特币集成方面付出的开发努力最少。我们预计，这会向用户传递出与2019年一个充满 Shockwave/Adobe Flash 元素并声称在 Internet Explorer 7 中最佳浏览的网站相同的信息（或参考 Gregory Maxwell 写的更具[想象力的比较][nullc bank analogy]）。 + +Bech32 发送并不是一些仍需测试的实验性新技术——原生 Segwit 未花费输出目前持有[超过 200,000 个比特币][over 200,000 bitcoins]. Bech32 发送也是易于实现的（参见 Newsletter [#38][news38 bech32] 和 [#40][news40 bech32]）。最重要的是，随着越来越多的钱包和服务默认升级为 Bech32 *接收*，不提供发送支持的服务将显得落后。 + +如果你还没有实现 Bech32 发送支持，我们建议你在 2019 年 8 月 24 日之前尝试实现（Segwit 激活的两周年）。不久之后，Bitcoin Core 的下一个版本预计将在其 GUI 和可能的 API 方法中默认使用 Bech32 接收地址（参见 Newsletter [#40][Newsletter #40 bech32] 和 [#42][Newsletter #42 bech32]）。我们预计其他钱包也会这样做——除了那些已经默认 Bech32（甚至是唯一支持的地址格式）的钱包。 + +[nullc bank analogy]: https://old.reddit.com/r/Bitcoin/comments/9iw1p2/hey_guys_its_time_to_make_bech32_standard_on/e6onq8t/ +[over 200,000 bitcoins]: https://p2sh.info/dashboard/db/p2wpkh-statistics?orgId=1 +[news38 bech32]: /zh/newsletters/2019/03/19/#bech32-发送支持 +[news40 bech32]: /zh/newsletters/2019/04/02/#bech32-发送支持 +[newsletter #40 bech32]: /zh/newsletters/2019/04/02/#bitcoin-core-schedules-switch-to-default-bech32-receiving-addresses +[newsletter #42 bech32]: /zh/newsletters/2019/04/16/#bitcoin-core-15711 diff --git a/_includes/specials/bech32/zh/11-only-bech32.md b/_includes/specials/bech32/zh/11-only-bech32.md new file mode 100644 index 0000000000..1c5714b2a7 --- /dev/null +++ b/_includes/specials/bech32/zh/11-only-bech32.md @@ -0,0 +1,26 @@ +{% auto_anchor %} +上周在 [Newsletter #47][] 中，我们描述了不升级支持 bech32 发送功能的一个成本——用户可能会认为你的服务已经过时，从而寻找替代服务。本周，我们将探讨这一论点的更强形式：那些已经**只能接收 bech32 地址**的钱包。如果这些钱包的用户想要接收付款或从你的服务中提现，而你的服务尚未支持发送到 bech32 地址，他们要么不得不使用第二个钱包，要么不得不使用你的竞争对手。 + + +- ****[Wasabi wallet][]，以其增强隐私的 coinjoin 模式和强制用户币控制而闻名，[只接受发送到 bech32 地址的付款][wasabi bech32 only]。这个相对较新的钱包是围绕类似于 [BIP158][] 中描述的致密区块过滤器设计的。然而，由于所有过滤器都是由 Wasabi 的基础设施提供的，[决定只生成与 bech32 地址相关的过滤器]["only generate filters regarding bech32 addresses"]以最小化过滤器大小，只包括 P2WPKH 输出和花费。这意味着钱包无法看到其他输出类型的付款，包括 P2SH 用于 P2SH 封装的 segwit 地址。 + + +- ****[Trust wallet][] 是一个相对较新的专有钱包，由币安加密货币交易所拥有，兼容 Android 和 iOS。作为一个新钱包，他们不需要实现旧地址接收支持，所以他们只实现了 segwit。这使得 bech32 成为发送比特币到该钱包的唯一支持方式。 + + +- ****[Electrum][] 是一个流行的桌面和移动钱包。在创建新钱包种子时，你可以选择传统钱包和 segwit 钱包，segwit 是当前默认选项。选择 segwit 钱包种子的用户将只能生成 bech32 地址以接收付款。Electrum 警告用户，这可能会导致与尚未升级到 bech32 发送支持的软件和服务的兼容性问题： + + ![Electrum 中允许用户选择地址类型并警告他们某些服务可能不支持 bech32 地址的对话框](/img/posts/2019-05-electrum-choose-wallet-type.png) + + 请注意，钱包作者既不需要也不推荐为了支持新的地址格式而创建新种子。其他钱包，如 Bitcoin Core 0.16.0 及以上版本，可以从同一个种子生成传统、p2sh-segwit 和 bech32 地址——用户只需要指定他们想要的地址类型（如果他们不想要默认的）。 + +随着时间的推移，我们预计会有更多的新钱包只实现接收当前最佳地址格式。今天，这意味着使用 bech32 的 P2WPKH 和 P2WSH 的 v0 segwit 地址，但如果 Taproot 被采用，它将使用同样使用 bech32 的 v1 segwit 地址。[news45 bech32]。你的服务延迟实现 bech32 发送支持的时间越长，你就越有可能因为客户无法使用他们喜欢的钱包请求付款而失去客户。 + +[Newsletter #47]: /zh/newsletters/2019/05/21/ +[wasabi bech32 only]: https://github.com/zkSNACKs/WalletWasabi/blob/master/WalletWasabi.Documentation/FAQ.md#my-wallet-cant-send-to-bech32-addresses---what-wallets-can-i-use-instead +["only generate filters regarding bech32 addresses"]: https://github.com/zkSNACKs/Meta/blob/master/README.md#wasabi-wallet-under-the-hood +[wasabi wallet]: https://wasabiwallet.io/ +[trust wallet]: https://trustwallet.com/ +[electrum]: https://electrum.org/ +[news45 bech32]: /zh/newsletters/2019/05/07/#bech32-发送支持 +{% endauto_anchor %} diff --git a/_includes/specials/bech32/zh/12-midway.md b/_includes/specials/bech32/zh/12-midway.md new file mode 100644 index 0000000000..fb786d8e28 --- /dev/null +++ b/_includes/specials/bech32/zh/12-midway.md @@ -0,0 +1,14 @@ +{% auto_anchor %} +这个部分标志着 Bech32 系列已过半，因此我们决定在本周介绍一些与 Bech32 相关的趣闻，这些趣闻有趣但不足以独立成段。 + +- ******Bech32 的发音是什么？** 提案的共同作者 Pieter Wuille 使用轻声的“ch”，因此这个词听起来像 [“besh thirty two”][wuille bech32]。这个名字是一个混合词，将地址的纠错编码（BCH）的字母与其数值基（base32）的名称结合起来。将其与轻声“ch”发音，使得 *bech32* 的第一个音节与比特币的传统地址格式 *base58* 相似。我们承认，这种详细解释破坏了这个笑话，但这是一个巧妙而有趣的文字游戏。 + +- ******BCH 与 Bitcoin Cash 的代码无关：** Bech32 所基于的 BCH 代码名称是 [Bose-Chaudhuri-Hocquenghem][wikipedia bch] 的缩写，Hocquenghem 于 1959 年发明了这种类型的循环码，随后 Bose 和 Ray-Chaudhuri 在 1960 年独立重新发现了它们。此外，Bech32 地址格式在 2017 年 3 月宣布，比后来被称为 Bitcoin Cash 的计划（最初计划使用代码 *BCC*）的[首次计划][first plans]早了三个月。 + +- ******消耗超过十年的 CPU 计算时间：** 使用现有的关于 BCH 代码的信息，Bech32 的作者能够找到为比特币地址提供他们所需的最低错误检测能力的代码集。然而，这个集合中有近 16 万个符合条件的代码，作者预计其中有些代码会比其他的更好。为了在其中找到最优的代码，使用了超过 200 个 CPU 核心和[超过 10 年的计算时间][cpu time]。 + +[wuille bech32]: https://youtu.be/NqiN9VFE4CU?t=1827 +[cpu time]: https://youtu.be/NqiN9VFE4CU?t=1329 +[wikipedia bch]: https://en.wikipedia.org/wiki/BCH_code +[first plans]:https://blog.bitmain.com/en/uahf-contingency-plan-uasf-bip148/ +{% endauto_anchor %} diff --git a/_includes/specials/bech32/zh/13-adoption-speed.md b/_includes/specials/bech32/zh/13-adoption-speed.md new file mode 100644 index 0000000000..73014d5a94 --- /dev/null +++ b/_includes/specials/bech32/zh/13-adoption-speed.md @@ -0,0 +1,17 @@ +Bech32 地址并不是比特币用户第一次改变地址格式。在 2012 年 4 月，P2SH 地址（以 `3` 开头）被引入，并最终在大约 25% 的交易输出中得到使用。本周，我们将查看这两种不同地址格式的相对采用速度。由于我们稍后将描述的原因，这不能算作一个完全公平的比较，但它可以为我们提供一个大致的指导，看看我们在 Bech32 采用方面迄今为止的表现如何。 + +我们首先来看一下从每个提案在主网激活的那一天起，发送到 P2SH 或原生 Segwit（Bech32）地址的每个区块的输出百分比。本节中的所有图表均以 30 天的简单移动平均值计算。我们还将 P2SH 图表中的数据点限制在 Segwit 激活前约两个月，以便几乎没有 P2SH 包裹的 Segwit 输出被误算为传统 P2SH。 + +![P2SH 采用速度与原生 Segwit 的比较。Segwit 线是 P2WPKH 和 P2WSH 的总和](/img/posts/2019-06-p2sh-vs-segwit-aggregate.png) + +上图中有一个特别不公平的方面是，P2SH 主要对高级脚本（如多重签名）有用。对于使用单签名地址（以 `1` 开头）的人来说，没有必要也没有好处升级到 P2SH。相比之下，原生 Segwit 地址既有针对单签名用户的（P2WPKH），也有针对高级脚本用户的（P2WSH）。为了使这种比较更加公平，下图在较小的日期范围内将原生 Segwit 的两种用途分开，这样您可以将 Bech32 P2WSH 的使用与其大致相当的 P2SH 进行比较。 + +![P2SH 采用速度与原生 Segwit 的比较。分别展示 P2WPKH 和 P2WSH 的数据](/img/posts/2019-06-p2sh-vs-segwit-separate.png) + +值得注意的是，到目前为止，几乎所有原生 Segwit 地址的使用都集中在单签名的 P2WPKH 上。Segwit 激活前的 P2SH 活动曾达到所有输出的 25% 的峰值，但这些活动并没有迁移到原生 P2WSH 输出。事实上，当我们考虑到所有闪电网络（LN）的存款交易（以及至少一些其他链上 LN 交易）都在使用原生 P2WSH 输出时，似乎几乎没有 2017 年末的 P2SH 活动转移到 P2WSH。 + +这也指出了使不同地址数据难以比较的另一个方面：使用传统 P2SH 所能实现的所有功能，也都可以使用 P2SH 包裹的 Segwit 地址或原生 P2WSH 地址来实现。P2SH 包裹的 Segwit 地址具有向后兼容性，并且可以[显著减少交易费用][bech32 fees]，而 Bech32 地址与旧钱包不兼容，与 P2SH 包裹的 Segwit 相比，仅能节省一小部分固定的额外费用。这可能使高级脚本用户在短期内没有足够的动力从 P2SH 包裹的 Segwit 地址切换到原生 Segwit 地址。 + +总体来看，图表似乎表明 P2SH 地址花了大约三年的时间才真正开始普及，而 Bech32 地址在 Segwit 软分叉激活后仅几个月内就已经取得了成功。随着一些钱包已经默认采用 Bech32，更多钱包计划在未来几个月内也将如此，我们预计在 2019 年底前会看到采用率的进一步提高。 + +[bech32 fees]: /zh/newsletters/2019/04/16/#bech32-发送支持 diff --git a/_includes/specials/bech32/zh/14-security.md b/_includes/specials/bech32/zh/14-security.md new file mode 100644 index 0000000000..4de971faf3 --- /dev/null +++ b/_includes/specials/bech32/zh/14-security.md @@ -0,0 +1,37 @@ +有一类多重签名用户不仅通过使用 bech32 地址来[节省费用][bech32 fee savings]，还因提高了对一种称为*哈希碰撞*的潜在攻击的安全性而受益。这类用户包括许多交易所和其他企业用户。 + +为了提供一些背景信息，目前比特币上的所有常见单签名地址都是通过将公钥转换为 160 位的 RIPEMD160 哈希摘要而生成的。理论上，攻击者可以生成第二个他们控制的公钥，对其进行哈希并生成相同的地址。然而，如果我们假设哈希函数产生的输出是完全不可预测的，那么使用像 RIPEMD160 这样的 160 位哈希函数时，每次攻击者尝试生成哈希碰撞的成功概率为 1/2160。 + + + +作为比较，当前比特币矿工大约每 5 小时执行 280 次哈希操作。虽然矿工执行的 SHA256d 哈希操作与此 RIPEMD160 碰撞攻击使用的哈希操作不同，因此他们的设备无法被重新利用来进行这种攻击，但我们可以用此作为一个参考，以了解当前真实世界系统可以执行的暴力破解操作数量（虽然代价昂贵）。按此速度，执行 2159 次操作以获得 50% 成功率的攻击将需要大约 2500 万倍于宇宙至今的估计年龄的时间。 + +然而，当使用多重签名地址时，攻击者可能是参与生成地址的一方，因此可能有能力操纵最终选择的地址。例如，Bob 将他的公钥发送给 Mallory，期望 Mallory 也将她的公钥返回给他。然后他们各自将公钥放入一个多重签名脚本模板中，哈希成一个地址，并有人将资金存入该地址。 + +然而，Mallory 采用了脚本模板和 Bob 的公钥，在没有告知 Bob 的情况下插入了她的一个公钥，并将其哈希成一个地址。这样，Mallory 可以在她承诺使用该公钥之前查看 Bob 将接受的地址。然后，Mallory 可以将该地址与她的数据库中仅支付给她的脚本生成的地址进行比较。如果两个地址匹配（碰撞），她就将公钥返回给 Bob，等待资金存入该地址，然后使用她数据库中的脚本来窃取资金。如果没有匹配，Mallory 可以一次又一次地尝试不同的公钥，直到她成功（假设她有无限的时间和资源）。 + +虽然这似乎与之前描述的具有每次尝试 1/2160 成功概率的暴力攻击类似，但我们必须考虑 Mallory 数据库的大小。如果我们假设该数据库有 100 个地址，那么她每次尝试不同的公钥时的成功概率为 100/2160，因为只要它与 Mallory 数据库中的任何一个地址匹配就可以成功。 + +这种攻击类型称为[碰撞攻击][collision attack]。碰撞攻击有几种在 CPU/内存方面进行权衡的算法，但安全研究人员遵循的通用规则是，针对完美哈希函数的碰撞攻击将其安全性降低到其组合数的平方根，即将其位数减半。这意味着我们可以大致认为 RIPEMD160 的安全性降低到 80 位——这与我们之前提到的当前技术下比特币矿工每 5 小时执行的操作次数相同。再一次，比特币挖矿设备无法用于此攻击，并且攻击者设计和构建足够的定制设备以在五小时内找到碰撞可能需要花费数十亿美元——但这是一个理论上可能的攻击，应该引起那些在 P2SH 中存储大量价值的人的关注，尤其是在定制硬件变得更快和更便宜的时候。此外，RIPEMD160 函数中可能存在的弱点也可能导致有更简单和更便宜的碰撞攻击变体。 + +可以设计多重签名设置协议，使其没有这个问题，从而保持 160 位的碰撞抵抗性。然而，segwit 的开发者[认为][sipa collision resistance]，对于 segwit 的 P2SH 类似物——P2WSH——使用稍长的哈希函数更为合适，这样用户就不需要担心这些密码学细节。因此，segwit P2WSH 使用了比特币中其他地方使用的相同的 SHA256d 函数，该函数为单方情况下提供 256 位安全性，为多方情况下提供 128 位的最差安全性。为了继续我们的粗略比较，如果我们认为 80 位相当于五小时的比特币挖矿，那么 128 位相当于 1600 亿年的挖矿。 + +在我们总结这一部分之前，我们想确保几件事情是清楚的： + +1. 我们认为目前没有人能够执行所描述的攻击（但我们不能排除这种风险）。 + +2. 该攻击只能在创建地址时使用（尽管实际盗窃可能会在很长时间后发生）。 + +3. 该攻击仅适用于多方多重签名地址。如果你是使用仅自己信任设备的 P2SH 多重签名单方用户，或者你使用的是 P2SH-P2WPKH（单签名地址），则你不会受到此攻击的威胁。 + +4. 该攻击适用于 P2SH 包装的 segwit P2WSH 地址以及常规 P2SH 地址。要消除风险，你必须使用原生 segwit（bech32）地址或安全的密钥交换协议。 + +总结来说，希望获得最高安全性的多方多重签名用户应该迁移到 bech32 P2WSH 地址，以利用其额外的碰撞抵抗性。随着用户进行这种迁移，各服务确保他们实现 bech32 发送支持以便能够向这些注重安全的用户发送支付将变得更加重要。 + +[bech32 fee savings]: /zh/bech32-sending-support/#使用原生-segwit-节省费用 +[sipa collision resistance]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012205.html +[collision attack]: https://en.wikipedia.org/wiki/Collision_attack diff --git a/_includes/specials/bech32/zh/15-data-entry.md b/_includes/specials/bech32/zh/15-data-entry.md new file mode 100644 index 0000000000..755428da6a --- /dev/null +++ b/_includes/specials/bech32/zh/15-data-entry.md @@ -0,0 +1,55 @@ +{% assign input_base58check_address = "1B6FkNg199ZbPJWG5zjEiDekrCc2P7MVyC" %} +{% assign input_bech32_address = "bc1qd6h6vp99qwstk3z668md42q0zc44vpwkk824zh" %} + +在 Segwit 激活之前，开发者讨论了使用何种格式来表示原生 Segwit 地址，有些开发者建议这是一个让地址更易于阅读和转录的机会。开发者 Gregory Maxwell 有效地表达了这一观点，他[询问][maxwell phone]其他开发者打电话给他，并尝试通过电话成功传达一个混合大小写的传统 base58check 地址。如果在传达过程中仅有一个字符出错——甚至只是那个字符是大写还是小写——双方都需要回过头来仔细查找错误。 + +[BIP173][] 的 Bech32 地址能够解决这两个问题。它们仅使用单一大小写（通常优先使用小写字母，但在使用二维码时可以使用大写字母以[提高效率][bech32 qr code section]），并且它们使用带有校验码的错误校正码，可以[帮助用户定位错误][bech32 ecc section]，同时确保在绝大多数情况下能够捕捉到输入错误。 + +然而，随着钱包和服务考虑升级以支持 Bech32 地址的发送和接收，我们认为值得提醒任何犹豫的实施者注意 Bech32 地址的这一关键用户收益功能——因此我们自动化了 Maxwell 旧电话测试的一部分，以便您私下评估转录传统地址和原生 Segwit 地址的相对难度。 + +如果您点击以下链接（在新标签页中打开），您会发现两个支付相同哈希值的地址的录音。您可以将地址输入到下面相应的框中，如果输入了错误的字符（区分大小写），框会立即变红。注意：为了提高准确性并消除特定语言环境的字母发音问题，我们在文件中使用音标字母读取每个字母，例如 `Alfa` 代表 *A*；`Bravo` 代表 *B*，等等。 + + + +[Base58check 和 Bech32 地址的朗读（1 分 33 秒）][bech32 audio] + +**传统 base58check 地址：** + + + +**原生 Segwit Bech32 地址：** + + + +如果您发现 Bech32 地址更容易准确转录，这意味着 Bech32 设计者在实现新地址格式的一个目标上取得了成功。发现 Bech32 优势的用户更可能希望在需要读取或转录地址的情况下使用 Bech32 地址，因此如果您的软件或服务支持发送到 Bech32 地址，他们将更倾向于使用它。 + +[bech32 audio]: /img/posts/2019-06-base58-vs-bech32-audio.ogg +[maxwell phone]: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-10-18.59.log.html#l-59 +[bech32 qr code section]: /zh/bech32-sending-support/#使用-bech32-地址创建更高效的二维码 +[bech32 ecc section]: /zh/bech32-sending-support/#查找-bech32-地址中的拼写错误 + + + + + diff --git a/_includes/specials/bech32/zh/16-checklist.md b/_includes/specials/bech32/zh/16-checklist.md new file mode 100644 index 0000000000..e6cbb3ff3d --- /dev/null +++ b/_includes/specials/bech32/zh/16-checklist.md @@ -0,0 +1,32 @@ +最近，一位 Optech 贡献者对许多流行的钱包和比特币交易所进行了调查，以了解它们支持哪些技术功能。对于其中一家交易所，他最初记录其支持发送到 bech32 地址，但后来发现其支持并不完全。 + +问题在于，该交易所支持 P2WPKH bech32 地址（单签名地址），但不支持 P2WSH bech32 地址（多重签名和复杂脚本地址）。另一个问题是，该交易所接受全小写的 bech32 地址，但不接受全大写的 bech32 地址。而另一家交易所则限制了地址表单字段的长度，以至于无法容纳所有有效的 bech32 地址。 + +考虑到这些问题，我们创建了一个简短的检查清单，用于测试基本的 bech32 发送支持。请仅使用少量比特币执行这些测试，以防万一出现问题时不会造成大的损失。 + +1. 生成两个自己的地址，一个用于 P2WPKH，另一个用于 P2WSH。例如，使用 Bitcoin Core、[jq][] JSON 解析器和 Bash shell，你可以运行以下命令： + + ```bash + $ p2wpkh=$( bitcoin-cli getnewaddress "bech32 test" bech32 ) + $ p2wsh=$( + bitcoin-cli addmultisigaddress 1 \[$( + bitcoin-cli getaddressinfo $p2wpkh | jq .pubkey + )\] "bech32 test" bech32 | jq -r .address + ) + $ echo $p2wpkh $p2wsh + $ echo $p2wpkh $p2wsh | tr '[a-z]' '[A-Z]' + ``` + +2. 使用你的软件或服务的常规支出或提现表单，测试向每个小写地址发送比特币。 + +3. 使用每个地址的大写形式再次测试（这些对于[二维码][bech32 qr code section]很有用）。 + +4. 通过检查你用于创建地址的钱包或区块浏览器，确保你收到了资金。如果一切正常，你的软件完全支持当前的 bech32 支付地址。 + + 如果你使用了临时的 Bitcoin Core 钱包创建了地址，可以等待交易确认后，使用以下命令将所有资金发送到你的常规钱包：`bitcoin-cli sendtoaddress YOUR_ADDRESS $( bitcoin-cli getbalance ) '' '' true` + +对于不实际尝试发送资金的单元测试，或在 testnet 或回归测试模式下发送资金的集成测试，BIP173 提供了更全面的[测试向量][bip173 test vectors]。 + +[jq]: https://stedolan.github.io/jq/ +[bech32 qr code section]: /zh/bech32-sending-support/#使用-bech32-地址创建更高效的二维码 +[bip173 test vectors]: https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#Test_vectors \ No newline at end of file diff --git a/_includes/specials/bech32/zh/17-signmessage.md b/_includes/specials/bech32/zh/17-signmessage.md new file mode 100644 index 0000000000..ffa681b9c7 --- /dev/null +++ b/_includes/specials/bech32/zh/17-signmessage.md @@ -0,0 +1,36 @@ +正如我们在本系列早前部分中展示的那样，Bech32 地址在几乎所有方面都优于传统地址——它们允许用户[节省费用][bech32 save fees]、[更容易转录][bech32 transcribe]、[可以定位地址输入错误][bech32 locate typos]，并且在 [QR 码中更高效][bech32 qr codes]。然而，有一个特性是传统 P2PKH 地址支持但原生 Segwit 钱包尚未广泛支持的——消息签名功能。为了全面披露信息，并希望能激励钱包开发者采取行动，我们将探讨 Bech32 地址支持中缺失的这一部分。 + +作为背景，许多钱包允许用户使用传统的 P2PKH 地址，通过与该地址相关联的私钥签署任意文本消息： + + $ bitcoin-cli getnewaddress "" legacy + 125DTdGU5koq3YfAnA5GNqGfC8r1AZR2eh + + $ bitcoin-cli signmessage 125DTdGU5koq3YfAnA5GNqGfC8r1AZR2eh Test + IJPKKyC/eFmYsUxaJx9yYfnZkm8aTjoN3iv19iZuWx7PUToF53pnQFP4CrMm0HtW1Nn0Jcm95Le/yJeTrxJwgxU= + +不幸的是，目前没有广泛实施的方式可以为传统 P2SH、P2SH 封装的 Segwit 或原生 Segwit 地址创建签名消息。在 Bitcoin Core 和许多其他钱包中，尝试使用除传统 P2PKH 地址以外的任何地址都会失败： + + $ bitcoin-cli getnewaddress "" bech32 + bc1qmhtn8x34yq9t7rvw9x6kqx73vutqq2wrxawjc8 + + $ bitcoin-cli signmessage bc1qmhtn8x34yq9t7rvw9x6kqx73vutqq2wrxawjc8 Test + error code: -3 + error message: + Address does not refer to key + +一些钱包确实支持 Segwit 地址的消息签名——但采用了非标准化的方法。例如，[Trezor][trezor segwit signmessage] 和 [Electrum][electrum segwit signmessage] 钱包分别提供了对 P2WPKH 和 P2SH 封装的 P2WPKH 地址的消息签名支持。然而，这两个实现是独立完成的，并且使用了略有不同的协议，因此它们[无法验证][trezor electrum incompatible]由另一个系统生成的签名。此外，我们所知的所有钱包所使用的算法都无法轻松适配用于多签名和其他高级限制的 P2SH 和 P2WSH 脚本。这意味着目前的消息签名功能普遍仅限于单签名地址的用户。 + +{:#bip322} +有一个提议的标准应允许任何地址类型或脚本用于创建签名消息，[BIP322][]. 该协议甚至应与未来的 Segwit 版本向前兼容，例如 [bip-taproot][] 和 [bip-tapscript][]（但存在一些与时间锁相关的未解决限制）。不幸的是，尽管该提议在一年多前首次提出（参见 [Newsletter #13][]），但至今仍没有任何实现——甚至没有一个正在审查中的提议实现。 + +这使得 Segwit 用户无法获得与传统地址用户相同级别的消息签名支持，这可能是某些用户不愿意迁移到 Segwit 地址的原因之一。除了钱包放弃消息签名支持外，唯一的解决方案是钱包开发者就一个标准达成一致并广泛实施该标准。 + + +[bech32 save fees]: /zh/bech32-sending-support/#使用原生-segwit-节省费用 +[bech32 transcribe]: /zh/bech32-sending-support/#读取和抄录-bech32-地址 +[bech32 locate typos]: /zh/bech32-sending-support/#查找-bech32-地址中的拼写错误 +[bech32 qr codes]: /zh/bech32-sending-support/#使用-bech32-地址创建更高效的二维码 +[trezor segwit signmessage]: https://github.com/trezor/trezor-mcu/issues/169 +[electrum segwit signmessage]: https://github.com/spesmilo/electrum/issues/2977 +[trezor electrum incompatible]: https://github.com/spesmilo/electrum/issues/3861 +[newsletter #13]: /zh/newsletters/2018/09/18/#review-proposed-bip322-for-generic-message-signing diff --git a/_includes/specials/bech32/zh/18-support-issues.md b/_includes/specials/bech32/zh/18-support-issues.md new file mode 100644 index 0000000000..0e742f77d3 --- /dev/null +++ b/_includes/specials/bech32/zh/18-support-issues.md @@ -0,0 +1,14 @@ +我们从钱包提供商那里听说，他们对默认接收 bech32 地址的犹豫原因之一是担心会显著增加客户支持请求。尽管如此，一些钱包已经默认使用 bech32 地址，其他一些钱包也计划很快开始使用，例如 [Bitcoin Core][core bech32 plan]。 + +我们向包括 BitGo、BRD、Conio、Electrum 和 Gemini 在内的多家服务商征求了关于使用 bech32 地址对客户支持负担的意见。大多数服务商报告称问题很少（“没有支持请求”和“没有太多困惑”）。 + +有一家服务商表示：“与比特币地址相关的客户支持票增加了 50%，但票数绝对数量如此之小，可能无法给出太多意义。在 Bech32 出现之前或之后，这个话题的票数从来都不多，所以不确定这是否是让交易所转换的一个重要论点。相反，我可能建议关注费用问题，如果你使用的是旧的钱包实现，费用确实可能会累积。” + +Electrum 也确实看到了一些公开的报告，例如[“奇怪的地址”]和[“Localbitcoins 不支持发送到 bech32”]。 + +尽管结论尚不明确，但令人欣慰的是，选择支持接收 bech32 地址的服务并没有对其客户支持团队产生负面影响。上面关于考虑费用节省的建议可能远远超过了这些担忧，并且与 Bitcoin Optech 的[指导][save money with bech32]一致。鉴于少数负面报告和支持接收 bech32 地址的钱包和服务可以显著节省费用，可能是时候让更多的钱包开始将 bech32 作为默认地址格式。如果这种情况发生，那么其他钱包和服务支持发送到 bech32 地址将变得更加重要。 + +[core bech32 plan]: /zh/newsletters/2019/04/02/#新闻 +["strange addresses"]: https://github.com/spesmilo/electrum/issues/5382 +["localbitcoins does not support sending to bech32"]: https://github.com/spesmilo/electrum/issues/5371 +[save money with bech32]: /zh/bech32-sending-support/#使用原生-segwit-节省费用 diff --git a/_includes/specials/bech32/zh/19-real-fees.md b/_includes/specials/bech32/zh/19-real-fees.md new file mode 100644 index 0000000000..c1dbebed40 --- /dev/null +++ b/_includes/specials/bech32/zh/19-real-fees.md @@ -0,0 +1,24 @@ +截至本文撰写时，比特币的价格在过去几个月中已迅速上涨。比特币价格的显著变化在 Bech32 的上下文中是值得注意的，因为交易费用是以比特币计价，而非美元计价。这意味着，即使费率保持不变，发送交易的实际成本也会随着比特币价格的上涨而增加。 + +我们之前讨论过[用户和服务通过切换到原生 Segwit (Bech32) 地址可以节省多少][bech32 savings segment]，但我们仅从虚拟字节（vbyte）和百分比节省的角度进行描述。在本节 Bech32 发送支持中，我们将以实际价值来探讨节省的情况。 + +最低的实用费用为 0.00000001 BTC/vbyte。到目前为止，最高的典型费用是在 2017 年 12 月和 2018 年 1 月达到的 0.00001000 BTC/vbyte。对于该范围，以下图表显示了两个常见交易模板（单签名和 2-of-3 多重签名）的用户可能节省的金额： + +![单签名传统 P2PKH 与 Segwit P2WPKH 的对比](/img/posts/2019-07-real-cost-p2pkh-p2wpkh.png) + +![2-of-3 多重签名传统 P2SH 与 Segwit P2WSH 的对比](/img/posts/2019-07-real-cost-p2sh-p2wsh.png) + +对于使用其他交易模板的传统交易用户，您可以通过将您发送的典型交易的 txid 粘贴到诸如 Esplora 区块浏览器（如 [Blockstream.info][]）之类的信息网站中，粗略了解您将节省的百分比。您可以将该百分比乘以交易的虚拟字节大小，查看您将节省多少虚拟字节。请注意，使用第三方服务会暴露您对该交易的兴趣，可能会显著降低您的隐私。您可以通过检查您的一笔典型交易来私下获取大致的虚拟字节节省量。[^measure-scriptsigs] 当您知道将节省多少虚拟字节时，您可以通过将节省的虚拟字节数乘以您的预期费率（以 BTC/vbyte 计）和您预期的比特币价格，计算出以另一种货币计的节省金额，例如 `saved_vbytes * feerate * price`。 + +如果原生 Segwit 的用户每笔交易开始节省几十到几百美元，我们预计将对高频支出者（如交易所）产生更大的竞争压力，促使他们迁移到只接受使用 Bech32 地址的存款。鉴于每日比特币交易中有很大比例是存款到交易所，我们预计不提供 Bech32 发送支持的钱包和服务将很快失去用户的青睐。 + +[bech32 savings segment]: /zh/bech32-sending-support/#使用原生-segwit-节省费用 +[transactionfee.info]: https://transactionfee.info/ +[blockstream.info]: https://blockstream.info/ + +[^measure-scriptsigs]: + 1. 使用工具解析交易。Bitcoin Core 附带了一个名为 `bitcoin-tx` 的工具可以为您完成此操作。运行 `bitcoin-tx -json `。 + + 2. 汇总所有 scriptSig 的总大小。`bitcoin-tx` 输出每个 scriptSig 的十六进制表示，将此十六进制字符串长度减半即可得出 scriptSig 的大小。 + + 3. 将 scriptSig 的大小乘以 0.75 即可得到节省的虚拟字节数。 diff --git a/_includes/specials/bech32/zh/20-percentage-loss.md b/_includes/specials/bech32/zh/20-percentage-loss.md new file mode 100644 index 0000000000..094ece9585 --- /dev/null +++ b/_includes/specials/bech32/zh/20-percentage-loss.md @@ -0,0 +1,21 @@ +在过去的一年中（大约 50,000 个区块），以百分比计算，原生 segwit 输出（即支付到 bech32 地址的交易数量）略有下降。一个明显的解释是，人们尝试了 bech32 地址，但不喜欢，随后又回到使用传统地址或 P2SH 包裹的 segwit 地址。如果情况确实如此，我们是否应该放弃 bech32 地址？ + +![支付给原生 segwit（bech32）输出的所有交易的百分比](/img/posts/2019-07-tx-types-bech32-percentage.png) + +{:.center} +*注意：本节中的所有图表都使用简单移动平均值计算，范围为 10,000 个区块。* + +或许我们应该首先调查是否存在其他解释。百分比是合成结果——通过结合多个其他来源的信息得出——所以我们首先要看的是原始数据。下图显示了过去两年中支付给各种类型脚本的输出总数： + +![支付给 P2PKH、P2SH、bech32 和 nulldata 的所有交易的总数](/img/posts/2019-07-tx-types-bech32-all-totals.png) + +与百分比数据相反，我们看到 P2WPKH 输出的数量在缓慢（但稳定）增加。我们还看到其他输出的数量也在增加。如果将总数堆叠在一起，这可能会变得更加清晰： + +![支付给 P2PKH、P2SH、bech32 和 nulldata 的所有交易总数的堆叠图](/img/posts/2019-07-tx-types-bech32-all-totals-stacked.png) + +现在我们可以看到，今天的平均输出数量略高于 2017 年底和 2018 年初比特币活动高峰时的数量。这是有道理的——使用 segwit 的交易越多，留给其他交易的区块空间就越多。然而，尽管整体增加，但支付输出（P2PKH、P2SH 和原生 segwit）的数量略有减少。剩余的输出显示出 `OP_RETURN`（nulldata）脚本数量的显著增加。 + +输出总数和 nulldata 输出数量的增长解释了为什么尽管绝对数量在增加，但 bech32 输出的百分比却在下降。这意味着我们不应该放弃 bech32。事实上，近期输出总数的激增（以及其他[可在其他地方获取的数据][return to fees]）可能是即将到来的费率上涨的信号，这将鼓励更多用户和组织通过切换到 bech32 来降低成本。 + +[return to fees]: https://www.youtube.com/watch?v=ihUQ4C42KUk + diff --git a/_includes/specials/bech32/zh/21-brd.md b/_includes/specials/bech32/zh/21-brd.md new file mode 100644 index 0000000000..60eba41070 --- /dev/null +++ b/_includes/specials/bech32/zh/21-brd.md @@ -0,0 +1,33 @@ +{% auto_anchor %} +*以下案例研究由 Optech 成员公司 [BRD][] 提供，描述了他们在为其钱包实现 bech32 和其他 segwit 技术时的经验。* + +我们于 2018 年 1 月开始在 BRD 钱包中实现 bech32 支持，在 [breadwallet-core][] 中[添加了 bech32 解码和编码支持][brd pr1]。breadwallet-core 是一个 MIT 许可的跨平台 C 库，无需外部依赖。我们所有的软件都尽可能避免第三方库的依赖，目前只使用 Pieter Wuille 的 [libsecp256k1][]. 最小化依赖是高安全性加密项目的典型做法。对于 bech32 的实现，我们发现 [BIP173][] 文档非常完善，因此没有遇到复杂的具体问题。 + +2018 年 3 月，breadwallet-core [更新][brd pr2]以自动解析作为比特币地址提供的任何内容，判断它是传统 P2PKH、传统 P2SH 还是 segwit bech32，并自动为每种情况生成相应的 scriptPubKey。这使得 BRD 开始支持向 bech32 地址发送比特币。最终在 2018 年 10 月，我们在整个库的后端和移动应用前端实现了完整的 segwit 支持，允许用户开始接收 bech32 地址，同时将所有找零地址默认设置为 bech32。 + +我们从未实现对 P2SH 封装的 segwit 地址的接收支持，而是直接使用 bech32。这是为了更好地优化 BRD 用于扫描影响用户钱包交易的布隆过滤器机制。为了允许用户跟踪他们何时收到付款，布隆过滤器会与 scriptPubKey 中的每个数据元素进行匹配。对于给定的公钥，scriptPubKey 中的数据元素在传统 P2PKH 和原生 segwit (bech32) P2WPKH 中是相同的。以下是 Optech [之前使用的][identical spk data]一个示例： + +- 地址 1B6FkNg199ZbPJWG5zjEiDekrCc2P7MVyC 的传统 P2PKH scriptPubKey： + + 
    OP_DUP OP_HASH160 OP_PUSH20 6eafa604a503a0bb445ad1f6daa80f162b5605d6 OP_EQUALVERIFY OP_CHECKSIG
    + +- 地址 bc1qd6h6vp99qwstk3z668md42q0zc44vpwkk824zh 的原生 segwit (bech32) P2WPKH scriptPubKey： + + 
    OP_0 OP_PUSH20 6eafa604a503a0bb445ad1f6daa80f162b5605d6
    + +由于针对给定元素的布隆过滤器将匹配同一公钥的 P2PKH 和 P2WPKH 地址，BRD 能够以零额外开销的方式扫描这两种支付类型。这也使得实现更加简洁，不会增加提供布隆过滤器服务的公共节点的资源使用。这对于使用其他类型扫描的钱包和服务来说，可能也是一种有价值的优化，因为这可能比 [BIP84][] 推荐的单独 HD 派生路径产生更少的开销。 + +由 bech32 地址生成的 scriptPubKey 长度各不相同，这会影响需要支付的交易费金额。比特币的手续费计算非常复杂——有时费率在 24 小时内会猛增几个数量级——但这在 segwit 之前已经是事实，所以我们以前花了很多时间在手续费计算上，并使其尽可能灵活。这意味着由 bech32 地址生成的 scriptPubKey 大小的变化不会对 BRD 造成影响。 + +我们希望今天的应用程序能够适应未来，因此代码支持发送到未来的 segwit 版本（请参阅 [Optech 的描述][bech32 future]）。这意味着，例如，如果比特币用户选择通过软分叉更改共识规则，BRD 将自动支持支付到 [taproot][bip-taproot] 地址。 + +一旦真正的势头建立起来，且大多数其他钱包和服务支持发送到 bech32 地址，BRD 的 bech32 接收支持将作为默认设置推广给我们的所有用户。为准备这一过渡，尽可能多的公司和服务自愿支持 bech32 发送能力非常重要。为了推动采用，我们创建了 [WhenSegwit][] 网站并成为 Optech 成员公司。我们希望其他钱包和服务在手续费相对较低时尽快实现完整的 segwit 支持。 + +[BRD]: https://brd.com/ +[brd pr1]: https://github.com/breadwallet/breadwallet-core/commit/2b17fe44619442c31f8a47c175f84b8992933346 +[brd pr2]: https://github.com/breadwallet/breadwallet-core/commit/fd0abb92b07e41429e1170fb56716965cc7b64ab +[breadwallet-core]: https://github.com/breadwallet/breadwallet-core/ +[identical spk data]: /zh/bech32-sending-support/#bech32-发送支持介绍 +[bech32 future]: /zh/bech32-sending-support/#自动-bech32-支持未来的软分叉 +[whensegwit]: https://whensegwit.com/ +{% endauto_anchor %} diff --git a/_includes/specials/bech32/zh/22-priority.md b/_includes/specials/bech32/zh/22-priority.md new file mode 100644 index 0000000000..75dfd76ef6 --- /dev/null +++ b/_includes/specials/bech32/zh/22-priority.md @@ -0,0 +1,13 @@ +我们经常提到使用 segwit 输入可以节省手续费，但从未提到您不必利用这些节省。如果您愿意，您可以支付与未使用 segwit 时相同的费用，从而在其他条件相同的情况下让您的交易更快得到确认。对于某些用户，例如试图在交易所间进行套利的交易员来说，省钱可能没有以相同费用更快确认交易来得重要。 + +为了研究这一想法，让我们首先生成一个使用 Bitcoin Core 手续费估算工具的图表，展示创建典型单签名、单输入、双输出交易时的潜在手续费节省： + +![按预估手续费以美元计费，Y=手续费，X=确认目标](/img/posts/2019-08-rate-over-time.png) + +我们看到，通常来说，支付的费用越少，交易的确认时间就越长——但 segwit 用户可以常常为相同的等待时间支付更少的手续费。现在让我们简单地重新排列这些数据的坐标轴： + +![按预估手续费以美元计费，Y=确认目标，X=手续费](/img/posts/2019-08-time-over-rate.png) + +对于相同的手续费，预计 segwit 用户有时会比传统用户等待更短的确认时间，其中原生 segwit 用户获得的优势最大。在这些估算中，为相同总手续费支付的不同交易类型的确认速度差异可能超过 6 个区块（平均大约一个小时）。 + +对于那些每笔交易愿意支付的手续费有固定上限的用户和组织来说，使用 segwit 可以显著减少其交易在高活动期间的确认时间。尽管这一优势仅惠及使用 bech32 和其他 segwit 地址支付的人，但这是另一个预计用户和组织将在不久的将来越来越多地要求您的软件和服务支付 bech32 地址的理由。 diff --git a/_includes/specials/bech32/zh/23-compat.md b/_includes/specials/bech32/zh/23-compat.md new file mode 100644 index 0000000000..1853979462 --- /dev/null +++ b/_includes/specials/bech32/zh/23-compat.md @@ -0,0 +1,12 @@ +{% auto_anchor %}截至撰写本文时，我们认为从创建和审核[兼容性矩阵][Compatibility Matrix]中获得了一些关于 Bech32 的重要见解。 + +- ******大多数工具支持支付到 Bech32 地址：**调查的 74% 的钱包和服务支持支付到 Segwit 地址。虽然这还不是我们希望看到的近乎普遍的支持，但这已经足够多，可能很快我们会看到更多钱包默认切换为 Bech32 接收地址。 + +- ******支持 P2WPKH 但不支持 P2WSH：**当我们开始测试各种应用时，假设“Bech32 发送支持”是一个二元问题——要么工具支持，要么不支持。然而，我们调查的一个服务支持向本地 Segwit (Bech32) P2WPKH 地址支付资金，但不支持 Bech32 P2WSH 地址。这促使我们分别追踪这两种不同的 Segwit 版本 0 地址。（如果你是开发者，请同时支持这两种地址类型。） + +- ******地址输入字段长度限制：**某些服务可能支持发送到 Bech32 地址，但当我们尝试输入 Bech32 地址时，要么被拒绝为长度过长，要么字段根本无法接受所有字符。（提醒一下，[BIP173][] 对比特币主网 Bech32 地址长度的说明是：它们“总是介于 14 到 74 个字符之间 [含 14 和 74]，并且其长度模 8 不能是 0、3 或 5。”） + +- ******输入字段的截图：**我们记录了尝试发送到 Bech32 地址的步骤，收集了大量的截图，供 UI 设计人员在实施他们自己的 Bech32 发送支持（或其他功能，如 RBF 支持）时参考最佳实践。 + +- ******缺乏 Bech32 找零地址支持：**由于支付到 Bech32 地址的支持仍然不普遍，Segwit 兼容钱包默认生成 P2SH 包裹的 Segwit 接收地址是合理的。然而，这些钱包中的许多也使用 P2SH 包裹的 Segwit 地址来接收从自己发给自己的找零。在某些情况下，这可能是出于隐私的考虑（例如，Bitcoin Core 当前尝试使找零输出类型与支付输出类型匹配），但在大多数情况下，这似乎是钱包没有充分利用将找零发送到其自己的 Bech32 地址以节省费用的机会。 +{% endauto_anchor %} diff --git a/_includes/specials/bech32/zh/24-conclusion.md b/_includes/specials/bech32/zh/24-conclusion.md new file mode 100644 index 0000000000..44808d2885 --- /dev/null +++ b/_includes/specials/bech32/zh/24-conclusion.md @@ -0,0 +1,9 @@ +在经过六个月、超过 10,000 字的发布之后，这是我们最后一篇关于 bech32 发送支持的章节。我们的目标是尽可能温和地说服尽可能多的开发者在他们的应用程序中增加对支付 bech32 地址的支持。我们希望这能使支持 segwit 的钱包更容易从默认使用 P2SH 包裹的 segwit 地址切换到更高效的原生 segwit bech32 地址。 + +通过我们的努力以及许多其他比特币爱好者的努力，我们认为成功已经近在咫尺：我们[评估][bech32 compat]的 23 个热门钱包和服务中，有 19 个已经准备好支持支付 bech32 地址，其中 4 个已经默认生成 bech32 接收地址。 + +每周，钱包切换到 bech32 的合理性看起来越来越明显，我们预计将会听到越来越多的开发者表示他们的下一个主要版本将默认使用 bech32 接收地址。这将降低这些软件用户的交易费用，并为所有比特币用户提供更多的区块空间，帮助所有人的费用保持更低的水平，哪怕只是稍微长一点时间。 + +即便这一系列文章已经结束，我们仍将继续更新[兼容性矩阵][compatibility matrix]中的 segwit 部分，并在每周的 Newsletter 的其他部分报告关于 bech32 的值得注意的进展。感谢所有阅读此系列的你们，并感谢你们通过一个钱包和服务的改进为比特币的扩展性做出贡献。 + +[bech32 compat]: /zh/bech32-sending-support/#来自-segwit-兼容性矩阵的见解 diff --git a/_includes/specials/policy/cs/01-why-mempool.md b/_includes/specials/policy/cs/01-why-mempool.md new file mode 100644 index 0000000000..78ea8d2a65 --- /dev/null +++ b/_includes/specials/policy/cs/01-why-mempool.md @@ -0,0 +1,70 @@ + + +Množství uzlů v bitcoinové síti ukládá nepotvrzené transakce v memory poolu +(tj. v předem alokovaném znovupoužitelném bloku paměti); odtud „mempool.” +Tato mezipaměť je důležitým zdrojem každého uzlu, který umožňuje +peer-to-peer přeposílání transakcí. + +Uzly, které se přeposílání transakcí účastní, stahují a validují bloky +postupně. Uzly bez mempoolu zaznamenávají každých zhruba deset minut +špičku v datovém přenosu následovanou výpočetně náročnou validací +každé transakce. Na druhou stranu uzly s mempoolem již mají pravděpodobně +v mempoolu všechny transakce z bloku uložené. Díky [přeposílání kompaktních +bloků][topic compact block relay] mohou tyto uzly stáhnout pouze hlavičku +bloku spolu se zkrácenými identifikátory a následně blok rekonstruovat +z transakcí v mempoolu. + +Množství přenášených dat je v případě používání kompaktních bloků +v porovnání s velikostí celého bloku minimální. Validace transakcí probíhá +rychleji, neboť uzel již ověřil a uchoval elektronické podpisy a skripty, +spočítal požadavky časových zámků a načetl z disku související UTXO. +Tento uzel může také okamžitě přeposlat blok svým spojením a tím dramaticky +zvýšit rychlost propagace bloku. Rychlost rozšiřování bloku po síti +snižuje riziko objevení zastaralých bloků. + +Mempooly mohou též sloužit k nezávislému odhadování poplatků. Trh s +prostorem pro bloky je aukcí založenou na poplatcích, mempool tak +dává uživatelům lepší přehled o nabídkách ostatních účastníků a +poskytuje historii nabídek. + +Neexistuje však žádný globální, sdílený mempool; každý uzel může přijímat +jiné transakce. Zaslání transakce jednomu uzlu neznamená, že se nakonec +dostane k těžařům. Někteří uživatelé považují tuto nejistotu za +frustrující a táží se, proč nelze transakce zasílat přímo těžařům. + +Představme si bitcoinovou síť, ve které jsou všechny transakce posílány +od uživatelů přímo těžařům. Bylo by snadné donutit několik malých subjektů +k logování IP adres odpovídajících jednotlivým transakcím a tím cenzurovat +transakce a sledovat finanční toky. Takový bitcoin by se možná používal +pohodlněji, ale postrádal by některé z nejdůležitějších vlastností. + +Soukromí a odolnost vůči cenzuře jsou vlastnosti vycházející z +peer-to-peer sítě. Aby mohly uzly transakce přeposílat, mohou se připojit +k anonymní množině uzlů, z nichž každý by mohl být těžař nebo někdo +k těžařovi připojený. Tento způsob pomáhá zmást stopy k uzlu, od kterého +transakce pochází a který ji potvrdil. Cenzor by mohl cílit na některé +těžaře, populární směnárny či jiné centralizované služby, ale bylo by +náročné blokovat zcela všechno. + +Přístup k nepotvrzeným transakcím dále pomáhá minimalizovat vstupní náklady +zahájení produkce bloků: kdokoliv nespokojený s výběrem transakcí (nebo +jejich vylučováním) se může okamžitě stát dalším těžařem. Považovaní všech +uzlů za rovnocenné při zveřejňování transakcí odpírá těžařům výsadní přístup +k transakcím a jejím poplatkům. + +Mempool je mimořádně užitečná mezipaměť, která umožňuje uzlům rozložit v čase +náklady na stahování a validaci bloků a která dává uživatelům přístup k +lepšímu odhadování poplatků. Na úrovni sítě podporují mempooly distribuci +transakcí a bloků. Všechny tyto výhody jsou nejvýraznější v případě, kdy +každý vidí všechny transakce před tím, než je těžaři začlení do bloků. +Jako kterákoliv jiná mezipaměť, i mempool je nejužitečnější, když je +často používaný. Musí být také omezen na velikosti, aby mohl být obsažen +v paměti. Příští týden se podíváme na slučitelnost pobídek jako metriku +držení nejužitečnějších transakcí v mempoolech. diff --git a/_includes/specials/policy/cs/02-cache-utility.md b/_includes/specials/policy/cs/02-cache-utility.md new file mode 100644 index 0000000000..64a81cd6cb --- /dev/null +++ b/_includes/specials/policy/cs/02-cache-utility.md @@ -0,0 +1,78 @@ +[Minulý příspěvek][policy01] představil mempool jako mezipaměť nepotvrzených +transakcí, která uživatelům poskytuje decentralizovaný způsob posílání +transakcí těžařům. Avšak těžaři nejsou povinni tyto transakce potvrdit, +blok obsahující pouze coinbasovou transakci je podle pravidel konsenzu +zcela validní. Uživatelé mohou těžařům poskytnout podnět k začlenění +transakcí navýšením celkové hodnoty vstupů bez navýšení celkové hodnoty +výstupů. Tento rozdíl si mohou těžaři vzít jako _poplatek_ za transakci. + +I když jsou v tradičním finančním světě transakční poplatky běžné, +noví bitcoinoví uživatelé jsou často překvapeni, že poplatky za umístění +v blockchainu nejsou úměrné hodnotě transakce, ale její váze. Namísto +likvidity je omezujícím faktorem blokový prostor. _Jednotkový poplatek_ +se obvykle uvádí v jednotkách satoshi za virtuální byte. + +Pravidla konsenzu v každém bloku omezují celkový prostor využitý transakcemi. +Díky tomuto omezení jsou časy propagace bloků nízké v porovnání s +intervalem produkce bloků a riziko zahození bloků je tak nižší. +Též napomáhá k omezení nárůstu blockchainu a množiny UTXO, tedy vlastností, +které přímo přispívají k nákladům na udržování plného uzlu. + +Mempooly díky své roli mezipaměti nepotvrzených transakcí též zprostředkovávají +veřejnou dražbu neelastického blokového prostoru. Pracuje-li správně, +funguje tato dražba na principu volného trhu, tedy priorita je stanovena +čistě jen na poplatcích a ne na vztazích s těžaři. + +Maximalizace poplatků při výběru transakcí do bloku (který je limitován +celkovou váhou a počtem operací podepisování) je [NP-těžký problém][NP-hard problem]. +Tento problém dále ztěžují vztahy mezi transakcemi. Těžba +transakce s vysokým jednotkovým poplatkem může být podmíněna těžbou jeho +rodiče s nízkým poplatkem. Nebo, vzato z jiného úhlu, výběr +transakce s nízkým jednotkovým poplatkem může otevřít příležitost +k těžbě potomka s vysokým jednotkovým poplatkem. + +Mempool v Bitcoin Core počítá jednotkový poplatek pro každou položku +a jeho předky (tzv. _jednotkový poplatek předků_, „ancestor feerate”), ukládá tento +výsledek do mezipaměti a sestrojuje šablony bloků pomocí hladového algoritmu. +Seřazuje mempool v pořadí dle _hodnocení předků_ („ancestor score”; jedná +se o minimum z jednotkového poplatku předků a vlastního jednotkového poplatku), +vybírá balíčky předků v tomto pořadí a za chodu upravuje informace o +poplatcích a váhách předků zbývajících transakcí. Tento algoritmus +nabízí rovnováhu mezi výkonností a ziskovostí, avšak nemusí poskytnout +optimální výsledky. Jeho účinnost může být zvýšena omezením velikosti +transakcí a balíčků předků; Bitcoin Core stanovuje tyto limity na +400 000, resp. 404 000 váhových jednotek. + +Podobně se počítá i _hodnocení potomků_ („descendant score”), které +se používá při výběru balíčků, které mají být z mempoolu vyhozeny. +Bylo by nevýhodné vyhodit transakce s nízkým poplatkem, které mají +potomky s vysokým poplatkem. + +Validace mempoolu též používá poplatky a jednotkové poplatky při +nakládání s transakcemi, které utrácejí shodné vstupy. Těmto případům +se též říká dvojí utrácení nebo konfliktní transakce. Uzly neakceptují +vždy jen první transakci, kterou spatří, ale aplikují soubor pravidel, +aby určily, které transakce je výhodnější ponechat. Toto chování +je známé jako [nahrazení poplatkem][topic rbf] („replace by fee”). + +Je zřejmé, že těžaři chtějí maximalizovat poplatky, avšak proč by měly +netěžící uzly též implementovat tato pravidla? Jak bylo zmíněno v minulém +příspěvku, užitečnost mempoolů netěžících uzlů je přímo navázána +na jejich podobnost s mempooly těžařů. I když se provozovatelé uzlů +nechystají produkovat bloky z obsahu svých mempolů, držení nejvýhodnějších +transakcí je i v jejich zájmu. + +I když neexistují žádná pravidla konsenzu vyžadující platbu poplatků, +hrají poplatky a jednotkové poplatky v bitcoinové síti důležitou roli +ve „spravedlivém” způsobu řešení soutěže o blokový prostor. Těžaři +využívají jednotkové poplatky k posuzování přijímání, vyhazování a +řešení konfliktů a netěžící uzly se drží tohoto chování, aby maximalizovaly +užitečnost svých mempoolů. + +Vzácnost blokového prostoru tlačí velikost transakcí směrem dolů a +ponouká vývojáře k lepší efektivitě konstrukce transakcí. Příští týden +prozkoumáme praktické strategie a techniky minimalizace transakčních +poplatků. + +[policy01]: /cs/newsletters/2023/05/17/#čekání-na-potvrzení-1-k-čemu-je-mempool +[np-hard problem]: https://en.wikipedia.org/wiki/NP-hardness diff --git a/_includes/specials/policy/cs/03-bidding-for-block-space.md b/_includes/specials/policy/cs/03-bidding-for-block-space.md new file mode 100644 index 0000000000..8c329dd966 --- /dev/null +++ b/_includes/specials/policy/cs/03-bidding-for-block-space.md @@ -0,0 +1,100 @@ + + +Minulý týden jsme zmínili, že transakce neplatí poplatky dle přenášené +hodnoty, ale za použitý prostor v bloku. Také jsme vysvětlili, že +těžaři vybírají transakce takový způsobem, aby poplatky činily co +největší částku. Vyplývá z toho, že v nově nalezeném bloku jsou potvrzeny +pouze transakce z vrcholu mempoolu. V tomto příspěvku popíšeme strategie +optimalizace poplatků. Předpokládáme, že máme vyhovující zdroj odhadu +výše jednotkového poplatku (příští týden si povíme více o odhadování +jednotkového poplatku). + +Během konstrukce transakcí jsou některé její součásti flexibilnější než jiné. +Každá transakce musí mít hlavičku, výstupy (určené jednotlivými platbami) a +výstup pro drobné. Odesílatel i příjemce by měli upřednostňovat takové typy +výstupů, které jsou efektivní z hlediska využitého prostoru, aby snížili +budoucí náklady na utracení svých výstupů. Konečnou podobu a váhu však +dává transakci [výběr vstupů][topic coin selection]. Jelikož transakce +mezi sebou soutěží jednotkovým poplatkem (poplatek / váha), lehčí transakce +vyžadují k dosažení stejného jednotkového poplatku nižší celkový poplatek. + +Některé peněženky, například Bitcoin Core, se snaží zkombinovat vstupy +takovým způsobem, aby se zcela vyhnuly nutnosti vytvářet výstup s drobnými. +To vede nejen ke snížení váhy nyní, ale také ke snížení budoucích nákladů +utracení tohoto výstupu. Bohužel takové kombinace vstupů jsou jen zřídka +možné, pokud peněženka nemá k dispozici velké množství UTXO s různorodými +částkami. + +Moderní druhy výstupů jsou prostorově efektivnější než starší typy. +Například utracení P2TR vstupu přispěje méně než dvěma pětinami váhy P2PKH +vstupu (viz [kalkulátor velikosti transakce][transaction size calculator]). +Multisig peněženky mohou těžit z nedávno dokončeného schématu [MuSig2][topic +musig] a protokolu FROST, díky kterým mohou být multisig operace kódovány +způsobem, který připomíná běžný vstup s jedním podpisem. Peněženky používající +moderní druhy výstupů mohou obzvláště v době vysoké poptávky po blokovém +prostoru dosáhnout vysokých úspor. + +{:.center} +![Přehled vah vstupů a výstupů](/img/posts/specials/input-output-weights.png) + +Chytré peněženky mění strategii výběru na základě jednotkového poplatku: +při vyšších jednotkových poplatcích dosahují použitím méně vstupů a moderních +druhů vstupů nejnižší možnou váhu pro danou množinu vstupů. Vybírat pokaždé +nejlehčí množinu vstupů by sice minimalizovalo náklady na tuto aktuální +transakci, ale také by štěpilo zásobu UTXO na malé fragmenty. To by si později +mohlo vynutit transakce s příliš velkou množinou vstupů v době s vysokým +jednotkovým poplatkem. Je tedy prozíravé, aby peněženky v dobách s nízkým +jednotkovým poplatkem také vybíraly více těžších vstupů, aby dosáhly konsolidace +prostředků do menšího množství moderních výstupů a tím se připravily +na pozdější vysokou poptávku po blokovém prostoru. + +Vysoce používané peněženky často slučují několik plateb do jediné transakce, +aby dosáhly snížení váhy transakce na platbu. Vyhnou se tak platbě +za hlavičku a výstup pro drobné za každou platbu; namísto toho všechny +platby sdílí tento náklad pouze jednou. Sloučení několika málo plateb +rychle snižuje náklady za platbu: + +![Úspory za sloučení plateb v P2WPKH](/img/posts/payment-batching/p2wpkh-batching-cases-combined.png) + +I když mnoho peněženek jednotkový poplatek nadsazuje, někdy transakce +čeká na potvrzení déle, než se plánovalo. V takových případech může odesílatel +nebo příjemce změnit transakci prioritu. + +Uživatelé mají zpravidla k dispozici dva nástroje, které jim pomohou +navýšit prioritu transakce: CPFP ([child pays for parent][topic cpfp], +potomek platí za předka) a RBF ([replace by fee][topic rbf], nahrazení +poplatkem). V případě CPFP utrácí uživatel svůj výstup, aby tím vytvořil +potomka této transakce, který bude mít vyšší jednotkový poplatek. +V minulém příspěvku jsme si vysvětlili, že je v zájmu těžařů vybrat +rodičovskou transakci do bloku, aby mohl být začleněn i její potomek +s vysokým poplatkem. CPFP je dostupné každému, komu je platba v transakci +směrována, čili buď příjemce nebo odesílatel (pokud vytvořil i výstup +pro drobné). + +V případě RBF připraví odesílatel transakci s vyšším jednotkovým poplatkem, +která nahradí transakci původní. Nahrazující transakce musí použít alespoň +jeden vstup shodný s původní transakcí; tento konflikt zaručí, že pouze +jediná z těchto dvou transakcí bude začleněna do blockchainu. Obvykle tato +nahrazující transakce obsahuje platby z původní transakce, ale odesílatel +by též mohl prostředky přesměrovat jinam či zkombinovat platby z více +transakcí do jedné. V minulém příspěvku jsme popsali, že uzly vyloučí +původní transakci z mempoolu, neboť je pro ně výhodnější začlenit nahrazující +transakci. + +I když je poptávka i produkce blokového prostoru mimo naši kontrolu, +mají peněženky k dispozici mnoho prostředků, kterými mohou dosáhnout +efektivního využití blokového prostoru. Peněženky mohou ušetřit na +poplatcích vytvářením lehčích transakcí eliminací výstupu pro drobné, +utrácením nativních segwit výstupů a defragmentací svého UTXO setu v době +nízkých poplatků. Peněženky, které podporují CPFP a RBF, mohou také začít +s konzervativnějším jednotkovým poplatkem a bude-li potřeba, mohou +transakci pomocí CPFP nebo RBF navýšit prioritu. + +[transaction size calculator]: /en/tools/calc-size diff --git a/_includes/specials/policy/cs/04-feerate-estimation.md b/_includes/specials/policy/cs/04-feerate-estimation.md new file mode 100644 index 0000000000..0ca137764f --- /dev/null +++ b/_includes/specials/policy/cs/04-feerate-estimation.md @@ -0,0 +1,87 @@ +Minulý týden jsme prozkoumali techniky minimalizace poplatků placených +za transakci při daném jednotkovém poplatku. Avšak jaký by tento +jednotkový poplatek měl být? Nejlépe co nejnižší, abychom ušetřili +peníze, ale dostatečně vysoký, aby nám zajistil místo v bloku +podle uživatelovy časové preference. + +Cílem _odhadu (jednotkového) poplatku_ je převést cílený časový +rámec pro konfirmaci na nejnižší jednotkový poplatek, který by +transakce měla zaplatit. + +Jednou z komplikací odhadu poplatku je nepravidelnost produkce +blokového prostoru. Řekněme, že aby obdržel zboží, potřebuje uživatel +obchodníkovi zaplatit během jedné hodiny. Uživatel očekává, že každých +deset minut bude vytěžený jeden blok, a tak bude cílit pozici uvnitř +příštích šesti bloků. Avšak je možné, že jeden z bloků bude nalezen +až za 45 minut. Odhady poplatků musí vzít do úvahy uživatelovu +naléhavost nebo časový rámec (ve smyslu „chci, aby byla tato transakce +potvrzena do konce pracovního dne”) a nabídku blokového prostoru (počet +bloků). Aby se s těmito obtížemi algoritmy odhadování poplatků vypořádaly, +vyjadřují cíle konfirmací v čase i počtu bloků. + +Naivní odhad poplatku lze postavit na historických údajích o výši +poplatků, které postačují na začlenění do bloků. Jelikož takový odhad +nezahrnuje transakce čekající v mempoolech na potvrzení, dosahoval +by velmi nepřesných výsledků v dobách s neočekávaně vysokou fluktuací +poptávky po blokovém prostoru a občasných dlouhých intervalech mezi +bloky. Další slabostí je závislost na informacích zcela ovládaných +těžaři, kteří by mohli dosáhnout zvyšování poplatků začleňováním +falešných transakcí s vysokými jednotkovými poplatky do svých bloků. + +Naštěstí trh blokového prostoru není aukcí naslepo. V našem [prvním +příspěvku][policy01] jsme zmínili, že vedení mempoolu a účast v P2P síti +přeposílání transakcí umožňuje uzlu vidět nabídky ostatních uživatelů. +Odhad poplatků v Bitcoin Core používá k výpočtu pravděpodobnosti začlenění +transakce s poplatkem `f` v příštích `n` blocích i historická data, avšak +zaměřuje se hlavně na výšky, ve kterých uzel transakci poprvé zaznamená +a kdy se potvrdí. Tato metoda ignoruje aktivitu, která se děje mimo +veřejný trh. Pokud těžaři začleňují do svých bloků transakce s uměle +nafouknutými poplatky, tento odhad poplatků by tím ovlivněn nebyl, neboť +používá jen data transakcí, které byly před potvrzením veřejně šířeny. + +Dále máme dobrý přehled o způsobu vybírání transakcí do bloků. V +[předchozím příspěvku][policy02] jsme zmínili, že uzly emulují +pravidla těžařů, aby ve svých mempoolech držely výhodné transakce. +Díky tomu můžeme postavit algoritmus odhadu poplatků, který simuluje chování +těžařů. Abychom nalezli jednotkový poplatek, za který by byla transakce +potvrzena během příštích `n` bloků, mohli bychom díky použití algoritmu +sestavování bloků a vlastního mempoolu navrhnout příštích `n` bloků a +spočítat, jaký poplatek by porazil poslední transakce, které by se +dostaly do bloku `n`. + +Je zřejmé, že účinnost tohoto odhadu poplatků závisí na podobnosti obsahu +našeho mempoolu a mempoolu těžařů, což nikdy nelze zaručit. Dále nemůže +zohlednit transakce, které těžař může začlenit na základě externích podnětů, +např. vlastní těžařovy transakce či transakce, jejíž poplatky +za potvrzení byly zaplaceny jiným způsobem. Algoritmus také musí zohlednit +dodatečné transakce, které se objeví. Může tak učinit snížením velikosti +navržených bloků, ale o kolik? + +Tato otázka opět vyzdvihuje užitečnost historický dat. Chytrý model může +zahrnout vzory aktivity a zohlednit vnější události ovlivňující poplatky +jako jsou pracovní doba, plánované konsolidace UTXO či reakce na změny +ceny bitcoinu. Problematika předpovídání poptávky po blokovém prostoru +je a nadále zůstane předmětem studií a zkoumání. + +Odhadování poplatků je mnohostranný a složitý problém. Špatný odhad +může přivést plýtvání prostředky, zhoršit použitelnost bitcoinu pro placení +a způsobit ztrátu peněz uživatelům vrstev nad bitcoinem, kteří kvůli +nevhodnému poplatku zmeškají okno časového zámku UTXO. Dobrý odhad poplatků +umožňuje uživatelům jasně a přesně sdělovat těžařům naléhavost transakce +a díky [CPFP][topic cpfp] a [RBF][topic rbf] mohou aktualizovat své nabídky +v případě podhodnocených původních odhadů. Díky pravidlům a politikám mempoolu +zohledňujícím výhodnost transakcí, dobře navrženým nástrojům pro odhadování +poplatků a [peněženkám][policy03] se mohou uživatelé účastnit efektivní veřejné +aukce blokového prostoru. + +Odhady poplatků obvykle nenabízí hodnoty pod 1 sat/vB, bez ohledu na +délku časového horizontu či množství transakcí čekající na potvrzení. +Mnozí považují 1 sat/vB za nejnižší jednotkový poplatek v bitcoinové síti, +neboť většina uzlů (včetně těžařů) [nikdy neakceptuje][topic default minimum +transaction relay feerates] nic pod touto hodnotou. Příští týden prozkoumáme +pravidla uzlu a další důvody pro zohledňování jednotkových poplatků +přeposílaných transakcí: ochrana před vyčerpáním zdrojů. + +[policy01]: /cs/newsletters/2023/05/17/#čekání-na-potvrzení-1-k-čemu-je-mempool +[policy02]: /cs/newsletters/2023/05/24/#čekání-na-potvrzení-2-incentivy +[policy03]: /cs/newsletters/2023/05/31/#čekání-na-potvrzení-3-aukce-blokového-prostoru diff --git a/_includes/specials/policy/cs/05-dos.md b/_includes/specials/policy/cs/05-dos.md new file mode 100644 index 0000000000..7e9b95ed5b --- /dev/null +++ b/_includes/specials/policy/cs/05-dos.md @@ -0,0 +1,86 @@ +Na [počátku][policy01] naší série jsme uvedli, že většina ochrany soukromí +a odolnost vůči cenzuře pramení z decentralizace bitcoinové sítě. Uživatelé +provozující uzly napomáhají k redukci počtu slabých míst, špehování +a cenzury. Vyplývá z toho, že jedním z hlavních cílů designu software +bitcoinového uzlu je jeho vysoká dostupnost. Pokud by byli uživatelé +nuceni pořídit si drahý hardware, používat konkrétní operační systém +nebo platit měsíčně stovky dolarů za jeho provozování, počet uzlů +v síti by nejspíš klesl. + +Navíc je takový uzel bitcoinové sítě připojen pomocí internetu k neznámým +entitám, které mohou spustit útok odepření služby (DoS) a způsobit +tím pád uzlu vyčerpáním paměti nebo plýtvání výpočetními a přenosovými +zdroji. Jelikož jsou tyto entity anonymní, nemohou naše uzly před připojením +určit, které uzly budou poctivé a které zlomyslné, a nemohou je ani +po detekci útoku účinně zakázat. Je tedy nutné, aby byla implementována pravidla, +která chrání před DoS a omezují náklady na provozování plného uzlu. + +Všeobecné ochrany proti DoS a vyčerpání zdrojů jsou vestavěné přímo do software +uzlů. Například obdrží-li Bitcoin Core od jediného spojení velké množství zpráv, +zpracuje pouze první z nich, zbytek uloží do fronty a zpracuje je pouze, +až obdrží a zpracuje zprávy od jiných spojení. Uzly také obvykle nejdříve +stáhnou pouze hlavičku bloku, ověří její Proof of Work (PoW) a teprve potom +stáhnou a ověří zbytek bloku. Útočník, který by chtěl vyčerpat zdroje uzlu +v rámci přeposílání bloků, by tak nejdříve musel věnovat nepřiměřené množství +vlastních zdrojů k výpočtu validního PoW. Tato asymetrie mezi obrovskými +náklady na výpočet PoW a minimálními náklady na jeho ověření poskytuje +přirozený způsob ochrany DoS v rámci přeposílání bloků. Tuto vlastnost však +nemá přeposílání _nepotvrzených_ transakcí. + +Všeobecné ochrany proti DoS však neposkytují dostatečné překážky proti jiným +druhům útoků. Útočník může například [zbastlit maximálně výpočetně náročnou][max cpu tx] +validní transakci, jako byla 1MB [„megatransakce”][megatx mempool space] v bloku +364292, jejíž validace trvala mimořádně dlouho dobu kvůli [ověřování podpisů +a kvadratickému sighashingu][rusty megatx]. Útočník může také za řadu +validních podpisů přidat jeden nevalidní, kvůli čemuž stráví uzel nad transakcí +několik minut, aby zjistil, že se jedná o zmetka. Během té doby uzel nepracuje +na novém bloku. Můžeme si představit, že takový druh útoku by cílil na konkurenční +těžaře, aby jim zpozdil počátek hledání nového bloku. + +Ve snaze vyhnout se práci na výpočetně velmi náročných transakcích omezují +uzly s Bitcoin Core maximální velikost a počet operací s podpisy (tzv. „sigops”) +v každé transakci více, než jsou limity konsenzu. Uzly s Bitcoin Core také +vynucují omezení na velikost balíčků předků a potomků, díky čemuž jsou produkce +šablon bloků a algoritmy vylučování účinnější a [výpočetní náročnost][se descendant +limits] přidání do a odebírání z mempoolu nižší. I když kvůli těmto pravidlům +mohou být vyloučeny některé validní transakce, očekává se, že podobné případy +budou vzácné. + +Tato pravidla jsou příklady _pravidel přeposílání transakcí_ („transaction relay +policy”), jež existují nad rámec pravidel konsenzu a týkají se nepotvrzených +transakcí. + +Ve výchozím stavu neakceptuje Bitcoin Core transakce s nižším jednotkovým poplatkem +než 1 sat/vB („minrelaytxfee”), neověřují žádné podpisy před ověřením tohoto požadavku +a nepřeposílají transakce, dokud nejsou přijaty do jejich vlastních mempoolů. Ve své +podstatě stanovuje toto pravidlo minimální „cenu” za validaci a přeposílání. +Netěžící uzly nikdy poplatky neobdrží, pouze těžař, který transakci potvrdí, dostane +zaplaceno. Poplatky však přináší náklady útočníkovi. Kdo posílá extrémní množství +transakci a „plýtvá” tak síťovými zdroji, brzy přijde platbou poplatků o všechny peníze. + +Pravidla [nahrazování poplatkem][topic rbf] („replace by fee”) [implementována v Bitcoin +Core][bitcoin core rbf docs] vyžadují, aby nahrazující transakce platila vyšší jednotkový +poplatek než kterákoliv transakce, se kterou je v přímém konfliktu, a také aby celkový +poplatek byl vyšší než poplatek za všechny transakce, které nahrazuje. Dodatečné +poplatky vydělené virtuální velikostí nahrazující transakce musí být vyšší než +1 sat/vB. Jinými slovy, bez ohledu na jednotkový poplatek původní a nahrazující transakce +musí nová transakce zaplatit „nové” poplatky, aby pokryla své vlastní přenosové náklady +za cenu 1 sat/vB. Hlavní důvod tohoto pravidla je zdražit opakované útoky plýtvající přenosovým +pásmem, např. takové, kdy každé další nahrazení přidává jediný satoshi. + +Uzel, který kompletně validuje bloky a transakce, vyžaduje zdroje včetně paměti, +výpočetních zdrojů a přenosového pásma. Musíme zajistit, aby požadavky na zdroje +byly co nejnižší a aby tak bylo provozování uzlu přístupné a odolné vůči vykořisťování. +Všeobecné DoS ochrany nejsou dostatečné, proto uzly vedle pravidel konsenzu aplikují +během validace nepotvrzených transakcí navíc i pravidla přeposílání transakcí. Jelikož +však pravidla nejsou konsenzem, dva uzly mohou mít pravidla nastavena odlišně a i tak +mohou dojít ke shodě na stavu blockchainu. Příští týden popíšeme pravidla jako +individuální volbu. + +[policy01]: /cs/newsletters/2023/05/17/#čekání-na-potvrzení-1-k-čemu-je-mempool +[max cpu tx]: https://bitcointalk.org/?topic=140078 +[megatx mempool space]: https://mempool.space/tx/bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08 +[rusty megatx]: https://rusty.ozlabs.org/?p=522 +[bitcoin core rbf docs]: https://github.com/bitcoin/bitcoin/blob/v25.0/doc/policy/mempool-replacements.md +[pr 6722]: https://github.com/bitcoin/bitcoin/pull/6722 +[se descendant limits]: https://bitcoin.stackexchange.com/questions/118160/whats-the-governing-motivation-for-the-descendent-size-limit diff --git a/_includes/specials/policy/cs/06-consistency.md b/_includes/specials/policy/cs/06-consistency.md new file mode 100644 index 0000000000..7c442fb633 --- /dev/null +++ b/_includes/specials/policy/cs/06-consistency.md @@ -0,0 +1,87 @@ +Minulý týden jsme si představili soubor pravidel pro validaci transakcí +používaných nad rámec pravidel konsenzu. Tato pravidla nejsou aplikována +na transakce v blocích, uzel tedy může zůstat v konsenzu s ostatními, +i když se jeho pravidla liší. Stejně jako se může provozovatel uzlu rozhodnout +nepodílet se na přeposílání transakcí, může si též svobodně zvolit svá +pravidla či žádná pravidla vůbec nevynucovat (a tím se vystavit riziku +DoS). Z toho vyplývá, že nemůžeme předpokládat jednotnost mempoolů v +síti. Avšak aby mohla být naše transakce přijata těžařem, musí nejdříve +projít cestou uzlů, které ji přijmou do svých mempoolů; jakákoliv +odchylka pravidel mezi těmito uzly má přímý dopad na přeposílání +transakcí. + +Hraničním příkladem odlišnosti pravidel mezi uzly budiž situace, ve +které si každý provozovatel uzlu zvolí náhodné číslo, které bude jako +jediné přijímat v `nVersion`. Jelikož by většina peer-to-peer relací +měla nekompatibilní pravidla, transakce by se k těžařům nedostávaly. + +Na druhou stranu shodná pravidla napříč sítí napomáhají sjednocování +obsahu mempoolů. Síť se shodnými mempooly nejlépe přeposílá transakce +a je též ideální pro [odhad poplatků][policy04] a [přeposílání kompaktních +bloků][policy01], jak bylo zmíněno v předchozích příspěvcích. + +Vzhledem ke složitosti validace mempoolu a obtížím spojených s +rozdílností pravidel je Bitcoin Core [konzervativní][aj mempool consistency] +v možnostech konfigurování pravidel. I když mohou uživatelé snadno +nastavit způsob počítání sigops (`bytespersigop`) či omezit množství +dat v `OP_RETURN` výstupech (`datacarriersize` a `datacarrier`), +nemohou se bez změny kódu vyvázat z maximální standardní váhy 400 000 +váhových jednotek či používat odlišný soubor pravidel pro RBF. + +Některá z nastavení pravidel v Bitcoin Core existují pro přizpůsobení +se odlišným provozním prostředím či důvodům provozování uzlu. Například +těžařovy hardwarové zdroje a důvody pro držení mempoolu jsou odlišné +od běžného uživatele provozujícího lehký uzel na laptopu nebo Raspberry Pi. +Těžař může chtít navýšit kapacitu mempoolu (`maxmempool`) nebo čas +expirace (`mempoolexpiry`), aby mohl během špičky ukládat transakce +s nízkým jednotkovým poplatkem, které by mohl těžit v čase nižšího +provozu. Webové stránky nabízející vizualizace, archívy či statistiky +mohou provozovat několik uzlů, aby sbíraly co nejvíce dat a zobrazovaly +výchozí chování mempoolu. + +Co se týče jednotlivých uzlů, nastavení kapacity mempoolu ovlivňuje +dostupnost nástrojů k navýšení poplatků. Roste-li minimální jednotkový +poplatek mempoolu kvůli vysokému počtu příchozích transakcí, nemohou +být poplatky navyšovány pomocí [CPFP][topic cpfp] transakcím vyloučeným +z mempoolu či transakcím novým majícím jednotkový poplatek pod tímto minimem. + +Na druhou stranu, jelikož vstupy odstraněných transakcí už nejsou utráceny +žádnou transakcí v mempoolu, může být nově možné navýšit poplatek pomocí +[RBF][topic rbf]. Nová transakce ve skutečnosti v mempoolu nic nenahrazuje, +nemusí tedy uvažovat běžná pravidla RBF. Avšak uzly, které původní +transakci z mempoolu neodstranily (kvůli vyšší kapacitě), považují tuto +novou transakci za možnou nahrazující transakci a vynucují pravidla RBF. +Pokud odstraněná transakce nesignalizovala možnost nahrazení (BIP125) či +poplatek nové transakce nesplňuje kritéria RBF navzdory vysokému jednotkovému +poplatku, nemusí těžař tuto novou transakci akceptovat. Peněženky musí +s odstraněnými transakcemi nakládat opatrně, neboť výstupy transakce +nemohou být pokládány za utratitelné a rovněž vstupy jsou podobně +nedostupné k dalšímu použití. + +Na první pohled se může zdát, že díky větší kapacitě mempoolu je pro uzel +CPFP užitečnější a RBF méně užitečné. Avšak přeposílání transakcí je +předmětem aktuálního chování sítě a cesta od uživatele k těžařovi, +ve které všechny uzly toto CPFP akceptují, nemusí existovat. Uzly běžně +přeposílají transakce až po akceptování do vlastního mempoolu a ignorují +oznámení o transakcích, která již ve svém mempoolu mají. Uzly, které ukládají +více transakcí, se chovají jako [černé díry][se maxmempool], když se k +nim tyto transakce dostanou. Dokud celá síť nenavýší kapacitu svých +mempoolů, což by bylo signálem pro změnu výchozí hodnoty, přinese navýšení +kapacity jednotlivým uživatelům jen málo výhod. Minimální jednotkový +poplatek mempoolu omezuje ve výchozím stavu užitečnost používání CPFP během +špiček. Uživatel, jehož CPFP transakci vlastní uzel přijme díky navýšené +kapacitě, si nemusí všimnout, že tuto transakci nikdo jiný nepřijal. + +Síť přeposílání transakcí sestává z jednotlivých uzlů, které se k síti +dynamicky připojují a odpojují. Každý z nich musí sám sebe chránit +před zneužitím. Proto nemůžeme zaručit, že se každý uzel dozví o +každé nepotvrzené transakci. Zároveň bitcoinové síti prospívá, +konvergují-li uzly ke shodné množině pravidel přeposílání transakcí, +díky které mají mempooly stejnorodý obsah. Příští článek osvětlí, +jaká pravidla byla přijata pro co nejlepší fungování celé sítě. + +[policy01]: /cs/newsletters/2023/05/17/#%C4%8Dek%C3%A1n%C3%AD-na-potvrzen%C3%AD-1-k-%C4%8Demu-je-mempool +[policy04]: /cs/newsletters/2023/06/07/#%C4%8Dek%C3%A1n%C3%AD-na-potvrzen%C3%AD-4-odhad-poplatk%C5%AF +[aj mempool consistency]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021116.html +[se maxmempool]: https://bitcoin.stackexchange.com/questions/118137/how-does-it-contribute-to-the-bitcoin-network-when-i-run-a-node-with-a-bigger-th + diff --git a/_includes/specials/policy/cs/07-network-resources.md b/_includes/specials/policy/cs/07-network-resources.md new file mode 100644 index 0000000000..1874094207 --- /dev/null +++ b/_includes/specials/policy/cs/07-network-resources.md @@ -0,0 +1,86 @@ +Předchozí článek popisoval ochrany zdrojů uzlu. Jelikož mohou být zdroje u každého +uzlu jedinečné, mohou být konfigurovatelné. Též jsme přednesli argumenty, +proč je lepší konvergovat k jednomu souboru pravidel. Co by však mělo být součástí +těchto pravidel? Tento článek vysvětlí koncept celosíťových zdrojů kritických +pro škálovatelnost, aktualizovatelnost a přístupnost nastartování a udržování +plného uzlu. + +Jak bylo popsáno v [předchozích příspěvcích][policy01], distribuovaná struktura +bitcoinové sítě je zásadní pro dosažení jeho ideologických cílů. Peer-to-peer +podstata bitcoinu umožňuje, aby pravidla sítě vyvstávala z hrubého konsenzu +voleb jednotlivých provozovatelů uzlů, a omezuje pokusy o získání nepatřičného +vlivu v síti. Tato pravidla jsou vynucována jednotlivě každým uzlem ověřujícím +každou transakci. Různorodá a zdravá populace uzlů vyžaduje, aby byly náklady +na provozování uzlů nízké. Je náročné škálovat v globálním měřítku jakýkoliv projekt, +ale činit tak bez obětování decentralizace je jako bojovat s jednou rukou za zády. +Bitcoin se snaží o udržení rovnováhy nekompromisní ochranou svých sdílených síťových +zdrojů: množiny UTXO, datové stopy na blockchainu spolu s výpočetními nároky vyžadované +na jejich zpracování a systém evoluce protokolu. + +Není nutné znovu připomínat celou válku o velikost bloků, abychom si uvědomili, +že omezení nárůstu blockchainu je nezbytné k zachování přístupnosti provozování +vlastního uzlu. Na úrovni pravidel také existuje prostředek pro omezování +růstu blockchainu v podobě `minRelayTxFee`, tedy minimálního poplatku nutného +pro přeposlání transakce ve výši 1 sat/vbyte. Toto pravidlo zajišťuje existenci +minimálních nákladů k omezení [„bezmezné poptávky po trvalém vysoce replikovaném +úložišti.”][unbounded] + + +Původně se pro sledování stavu sítě uchovávaly všechny transakce, které měly +neutracené výstupy. [Nově představená množina UTXO][ultraprune] jako prostředek +sledování prostředků přinesla významnou redukci dat. Od té doby se množina UTXO +stala ústřední datovou strukturou. Vyhledání UTXO tvoří hlavní podíl všech přístupů +do paměti, obzvláště během prvotního stahování bloků. Bitcoin Core již pro UTXO +mezipaměť používá [optimalizovanou datovou strukturu][pooled resource], avšak +velikost množiny UTXO určuje, jaká její část se do mezipaměti nevměstná. Větší +množina UTXO znamená více cache miss, což zpomaluje validaci bloků, prvotní +stahování a validaci transakcí. „Dust limit” je příkladem pravidla, které omezuje +tvorbu neutratitelných UTXO, jejichž hodnota je [nižší][topic uneconomical outputs] +než náklady na utracení. I přes to se [„prachové bouře” s tisíci transakcemi +objevily dokonce i v roce 2020][lopp storms]. + +Když se použití bare multisigu stalo populárním způsobem publikování dat na +blockchainu, upravila se definice standardní transakce, aby jako alternativu +povolovala jeden OP_RETURN výstup. Lidé si uvědomili, že by bylo nemožné +zabránit uživatelům v publikování dat na blockchainu, avšak alespoň by tato +data, uložena v neutratitelných výstupech, nemusela být navždy udržována v množině +UTXO. Bitcoin Core 0.13.0 přinesl volbu `-permitbaremultisig`, která umožňuje +uživatelům odmítnout nepotvrzené transakce obsahující výstupy s bare multisig. + +I když pravidla konsenzu povolují ve výstupech jakékoliv skripty, Bitcoin Core +přeposílá pouze několik známých vzorů skriptů. Díky tomu je snazší porozumět +dopadům na síť, včetně nákladů na validaci a upgrade protokolu. Například transakce +se vstupním skriptem obsahujícím op-kódy, P2SH vstupem s více než 15 podpisy nebo +P2WSH vstupem, jehož witness by tvořil v zásobníku více než 100 položek, by všechny +byly označeny za nestandardní. ([Přehled pravidel][instagibbs policy zoo] obsahuje +příklady a jejich motivace.) + +Bitcoinový protokol je žijícím softwarovým projektem, který se musí nadále vyvíjet, +aby odpovídal na budoucí potíže či potřeby uživatelů. Pro tento účel obsahuje +konsenzus několik nepoužívaných děr („upgrade hooks”), jako je příloha („annex”), +verze taprootových listů, verze witnessů, OP_SUCCESS a množství NOOP op-kódů. +Avšak podobně jako absence centrálních bodů selhání brání útokům, vyžadují i +celosíťové upgrady software koordinaci desítek tisíc nezávislých provozovatelů uzlů. +Uzly nepřeposílají transakce, které používají některé z rezervovaných děr, dokud nebude +jejich význam definován. Tento postup má odrazovat aplikace, aby nezávisle tvořily +konfliktní standardy, což by vedlo k nemožnosti začlenit do konsenzu standard +jedné aplikace bez zneplatnění standardu aplikace jiné. A pokud změna konsenzu +nastane, uzly, které okamžitě neupgradují a tedy neví o nových pravidlech konsenzu, +nemohou být přinuceny k akceptování zatím nevalidních transakcí do svých mempoolů. +Tento způsob odrazování vede k dopředné kompatibilitě uzlů a umožňuje síti +bezpečně upgradovat pravidla konsenzu bez nutnosti vyžadovat synchronizovanou +aktualizaci software. + +Jak můžeme vidět, používání pravidel k ochraně sdílených síťových zdrojů napomáhá +k ochraně vlastností celé sítě a zároveň ponechává otevřené dveře k budoucímu vývoji +protokolu. Také vidíme, jak třenice mezi růstem sítě a striktním omezením +váhy bloků vedla k osvojení nejlepších postupů, dobrého technického designu a inovací. +Příští týden prozkoumáme pravidla mempoolu jako vstupní brány protokolů +druhé vrstvy a systémů chytrých kontraktů. + +[policy01]: /cs/newsletters/2023/05/17/#%C4%8Dek%C3%A1n%C3%AD-na-potvrzen%C3%AD-1-k-%C4%8Demu-je-mempool +[unbounded]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html +[lopp storms]: https://blog.lopp.net/history-bitcoin-transaction-dust-spam-storms/ +[ultraprune]: https://github.com/bitcoin/bitcoin/pull/1677 +[pooled resource]: /cs/newsletters/2023/05/03/#bitcoin-core-25325 +[instagibbs policy zoo]: https://gist.github.com/instagibbs/ee32be0126ec132213205b25b80fb3e8 diff --git a/_includes/specials/policy/cs/08-interface.md b/_includes/specials/policy/cs/08-interface.md new file mode 100644 index 0000000000..93c93d0d80 --- /dev/null +++ b/_includes/specials/policy/cs/08-interface.md @@ -0,0 +1,101 @@ +V této sérii jsme zatím prozkoumali [motivace][policy01] a záludnosti +spojené s decentralizovaným přeposíláním transakcí, které vedou k +[lokální][policy05] i [globální][policy07] poptávce po přísnějších pravidlech +validace, než je konsenzus. Jelikož mohou mít změny pravidel +přeposílání transakcí v Bitcoin Core dopad na přeposílání transakcí, +vyžadují nejdříve dosažení společenského přijetí v rámci širší bitcoinové +komunity. Podobně musí být i aplikace a protokoly na druhé vrstvě +navrženy tak, aby se vyhnuly odmítání svých transakcí. + +Protokoly s kontrakty jsou ještě závislejší na pravidlech spojených s +prioritizací, protože vymahatelnost onchain závisí na možnosti mít +transakce rychle potvrzené. V nepřátelském prostředí mohou mít podvádějící +protistrany zájem na zdržení konfirmace, musíme tedy také uvažovat, jak +by mohly být drobnosti v pravidlech přeposílání transakcí použity proti +uživateli. + +Transakce v lightning network se drží pravidel standardnosti zmíněných v +předchozích článcích. Například jeho peer-to-peer protokol obsahuje ve +zprávě `open_channel` volbu `dust_limit_satoshis` určující práh neutratitelnosti. +Jelikož transakce obsahující výstup s hodnotou nižší než tento práh by nebyly +uzly přeposlány, jsou tyto platby považovány za „nevymahatelné onchain” +a jsou z commitment transakcí vyřazeny. + +Protokoly s kontrakty často používají časové zámky, aby poskytly každému +účastníkovi možnost zpochybnit stav publikovaný onchain. Pokud by transakce +dotčeného uživatele nebyla potvrzena před uplynutím doby zámku, mohl by +přijít o prostředky. Proto jsou poplatky extrémně důležitým nástrojem +pro navýšení priority konfirmace. [Odhad jednotkového poplatku][policy04] +je ztížen tím, že transakce budou zveřejněny v neznámém čase, uzly jsou +často provozovány jako lehké klienty a některé možnosti navyšování poplatků +nemusí být k dispozici. Například byl-li by jeden z účastníků LN kanálu offline, +mohl by ten druhý jednostranně zveřejnit předem podepsanou commitment transakci +a tím dosáhnout vyrovnání společných prostředků onchain. Žádná ze stran nemůže +sama utratit společné UTXO, je-li tedy jedna strana offline, podepsání +[nahrazující][topic rbf] transakce pro navýšení poplatku commitment transakce +je nemožné. Namísto toho mohou commitment transakce obsahovat [anchor výstupy][topic +anchor outputs], které pomohou účastníkům kanálu připojit v době zveřejnění +[potomka navyšujícího poplatek][topic cpfp] (CPFP). + +Tento způsob navyšování poplatků má ale také svá omezení. Jak bylo zmíněno v +[předchozím příspěvku][policy06], přidání CPFP transakce není efektivní, pokud +minimální jednotkový poplatek mempoolu přeroste poplatek commitment transakce. +Musí tedy i tak být podepsány s mírně přeceněným jednotkový poplatkem pro případ +navýšení minimálního poplatku mempoolu. Dále během vývoje anchor výstupů byly také +zohledněny případy, kdy může být v zájmu jedné strany konfirmaci pozdržet. +Například jedna strana (Alice) může zveřejnit svou commitment transakci před vypnutím +uzlu. Pokud by byl jednotkový poplatek této commitment transakce příliš nízký pro +dosažení okamžité konfirmace a pokud by Bob, Alicina protistrana, její transakci +neobdržel, mohl by být zmaten, proč zveřejnění jeho verze commitment transakce +není úspěšně propagováno v síti. Každá commitment transakce má dva anchor výstupy, +takže každá strana může použít CPFP na kteroukoliv commitment transakci, například +Bob může zkusit naslepo zveřejnit navýšení poplatku Aliciny verze commitment +transakce, i když si není jist, zda předtím ona svou verzi zveřejnila. Každý anchor +výstup disponuje malou hodnotou nad prahem neutratitelnosti. Po nějaké době ji může +nárokovat kdokoliv jako opatření před zahlcením množiny UTXO. + +Zaručit každé straně možnost navýšit poplatek transakce pomocí CPFP je však mnohem +složitější, než přiřadit každé straně anchor výstup. Jak bylo zmíněno v [předchozím +příspěvku][policy05], jako ochranu před DoS omezuje Bitcoin Core počet a celkovou +velikost potomků, kteří mohou být přiřazeni nepotvrzené transakci. Jelikož má každá +protistrana možnost přidat potomky sdíleným transakcím, mohla by jedna z nich zablokovat +CPFP transakci té druhé vyčerpáním tohoto limitu a tím jí zabránit v propagaci. +Přítomnost těchto potomků tak v mempoolech „přišpendlí” tuto commitment transakci na pozici +s nízkou prioritou. + +Na zabránění tohoto potenciálního útoku je navrhováno, aby byly všechny +ostatní výstupy omezeny relativním časovým zámkem, což by zabránilo v jejich +utracení před konfirmací. Dále byla upravena pravidla v Bitcoin Core, aby bylo možné +[přidat ještě jednoho potomka][topic cpfp carve out] (CPFP carve out), pokud je tento potomek malý +a nemá žádné další předky. Tato kombinace změn v obou protokolech zajišťuje, že alespoň +dva účastníci ve sdílené transakci by mohli v čase zveřejnění upravit jednotkový poplatek, +aniž by významně navýšili možnost DoS útoku. + +Zabránění CPFP naplněním omezení počtu potomků je příkladem [pinning útoků][topic transaction +pinning]. Tyto útoky zneužívají omezení v pravidlech mempoolu, aby transakcím zabránily v přístupu +do mempoolu nebo v potvrzení. V tomto případě představují pravidla mempoolu +kompromis mezi [odolností vůči DoS][policy05] a [incentivami][policy02]. Nějaký kompromis +musí být učiněn: uzel by měl zvažovat navýšení poplatků, ale nemůže zpracovávat +nekonečně mnoho potomků. CPFP carve out upravuje tento kompromis pro konkrétní případ +použití. + +Vedle vyčerpání limitu potomků existují i další pinning útoky, které [zabraňují použití RBF][full +rbf pinning], činí RBF [příliš drahým][rbf ml] či zneužívají RBF ke zpoždění konfirmace +ANYONECANPAY transakcí. Pinning je problémem pouze v případech, kdy více stran spolupracuje +na vytvoření společné transakce nebo kde má nedůvěryhodná strana prostor upravovat transakci. +Minimalizace přístupu transakce nedůvěryhodným stranám je obecně dobrým způsobem +vyhýbání se pinningu. + +Tyto třecí plochy zdůrazňují nejen důležitost pravidel jako rozhraní pro aplikace a protokoly +v rámci ekosystému bitcoinu, ale také ukazují místa, která potřebují vylepšit. +Příští týden se podíváme na návrhy pravidel a otevřené otázky. + +[full rbf pinning]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html +[rbf ml]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html +[n25038 notes]: https://bitcoincore.reviews/25038 +[policy01]: /cs/newsletters/2023/05/17/#čekání-na-potvrzení-1-k-čemu-je-mempool +[policy02]: /cs/newsletters/2023/05/24/#čekání-na-potvrzení-2-incentivy +[policy04]: /cs/newsletters/2023/06/07/#čekání-na-potvrzení-4-odhad-poplatků +[policy05]: /cs/newsletters/2023/06/14/#čekání-na-potvrzení-5-pravidla-pro-ochranu-zdrojů-uzlů +[policy06]: /cs/newsletters/2023/06/21/#čekání-na-potvrzení-6-konzistence-pravidel +[policy07]: /cs/newsletters/2023/06/28/#čekání-na-potvrzení-7-síťové-zdroje diff --git a/_includes/specials/policy/cs/09-proposals.md b/_includes/specials/policy/cs/09-proposals.md new file mode 100644 index 0000000000..ba90e3e596 --- /dev/null +++ b/_includes/specials/policy/cs/09-proposals.md @@ -0,0 +1,103 @@ +[Minulý příspěvek][policy08] popsal [anchor výstupy][topic anchor outputs] a [CPFP carve +out][topic cpfp carve out] zajišťující, že kterákoliv strana kanálu může +navýšit poplatek sdílené commitment transakce bez nutnosti spolupráce. +Tento přístup stále obsahuje několik nevýhod: prostředky kanálu jsou svázané, +aby mohly vytvořit anchor výstupy, jednotkový poplatek commitment transakce je +většinou o trochu vyšší, aby byl vyšší než minimální poplatek mempoolu, a +CPFP carve out povoluje pouze jednoho potomka navíc. Anchor výstupy nemohou +zajistit podobnou dostupnost navýšení poplatků transakcí sdílených mezi více +než dvěma stranami, jako je [coinjoin][topic coinjoin] nebo protokoly s více +účastníky. Tento příspěvek zkoumá současné snahy adresovat tato i jiná omezení. + +[Přeposílání balíčků][topic package relay] obsahuje P2P protokol a změny pravidel, +které umožní transport a validaci skupin transakcí. Díky tomu by mohly být +poplatky commitment transakcí navýšeny potomkem, i kdyby nesplňovaly požadavek +minimálního jednotkového poplatku mempoolu. Dále by _RBF balíčku_ umožnilo +potomkovi navyšujícímu poplatek zaplatit za [nahrazení][topic rbf] transakcí, +se kterými jsou jeho rodiče v konfliktu. Přeposílání balíčků je navrženo tak, +aby odstranilo obecná omezení na základní vrstvě protokolu. Avšak díky jeho +použití pro navyšování poplatků sdílených transakcí byly na jeho základě +představeny pokusy o eliminaci [pinningu][topic transaction pinning] +v některých konkrétních případech. Například by RBF balíčku umožnil commitment +transakcím nahrazení sebe navzájem, pokud by byly zveřejněny spolu se svými +potomky navyšujícími poplatek. Díky tomu by nebylo potřeba mít v každé +commitment transakci několik anchor výstupů. + +Drobným zádrhelem je, že existující pravidla pro RBF vyžadují, aby nahrazující +transakce platila vyšší absolutní poplatek než součet poplatků placených všemi +nahrazovanými transakcemi. Toto pravidlo napomáhá prevenci odepření služby +opakovanými nahrazeními, ale umožňuje záškodníkům zvýšit náklady na nahrazení +transakce připojením potomka, který má vysoký poplatek, ale nízký jednotkový +poplatek, což zamezuje transakci ve vytěžení. Tomuto druhu pinningu se často +říká „pinning třetího pravidla.” + +Vývojáři též navrhli zcela odlišné způsoby přidávání poplatků předem podepsaným +transakcím. Například podepsání vstupů transakce s `SIGHASH_ANYONECANPAY | SIGHASH_ALL` +by umožnilo odesílateli transakce poskytnout poplatek připojením dodatečných vstupů, +avšak se zachováním výstupů. Jelikož však nemá RBF žádná pravidla vyžadující, aby +měla nahrazující transakce vyšší „těžební skóre” (tj. byla by rychleji vybrána +do bloku), mohl by útočník „přišpendlit” tento druh transakcí vytvořením +nahrazení zatíženého předky s nízkými jednotkovými poplatky. Existující limity +předků a potomků nejsou dostatečné, aby omezily výpočetní náročnost této +kalkulace, což ztěžuje přesný odhad těžebního skóre transakcí a balíčků +transakcí. Jakékoliv připojené transakce mohou ovlivnit pořadí, ve kterém jsou +transakce vybírány do bloku. Komponenta, která je plně propojena (nazývající se +_cluster_), může mít jakoukoliv velikost danou současnými limity předků a potomků. + +Dlouhodobým řešením adresování některých nedostatků mempoolu a RBF pinning +útoků je v mempoolu [předělat strukturu dat, aby se sledovaly clustery][mempool +clustering] namísto pouhých množin předků a potomků. Tyto clustery by byly +omezeny ve velikosti. Limity clusterů by omezily způsob, kterým by mohli uživatelé +utrácet nepotvrzená UTXO, ale díky nim by mohl být celý mempool linearizován +použitím těžebního algoritmu založeném na skóre předků, tvorba šablon bloků +by byla extrémně rychlá a mohl by být přidán požadavek, aby nahrazující +transakce měly vyšší těžební skóre než transakce, které chtějí nahradit. + +I přesto je možné, že žádná jedna sada pravidel nemůže uspokojit širokou řadu +potřeb a očekávání přeposílání transakcí. Například zatímco pro příjemce dávkové +platby je výhodné, že mohou utratit své nepotvrzené výstupy, uvolněné limity +potomků vytváří prostor pro pinning RBF balíčků sdílené transakce skrz +absolutní poplatky. Návrh na [pravidla přeposílání v3 transakcí][topic v3 transaction +relay] byl vyvinut, aby umožnil protokolům s kontrakty volitelně používat +striktnější sadu limitů balíčků. V3 transakce by povolovaly pouze balíčky o velikosti +dva (jeden předek, jeden potomek) a omezovaly váhu potomka. Tyto limity by +zabraňovaly RBF pinningu skrz absolutní poplatky a nabídly by některé z výhod +mempoolu clusterů bez nutnosti restrukturovat mempool. + +[Ephemeral anchors][topic ephemeral anchors] dále vylepšují anchor výstupy na základě +vlastností přeposílání v3 transakcí a balíčků. Anchor výstupy patřící v3 transakci +s nulovým poplatkem budou mít výjimku z [limitu neutratitelnosti][topic +uneconomical outputs] („dust limit”), pokud jsou utráceny potomkem navyšujícím +poplatek. Jelikož transakce s nulovým poplatkem musí mít poplatek navýšený +právě jedním potomkem (jinak by neměl těžař motivaci ji začlenit do bloku), +je tento anchor výstup dočasný („ephemeral”) a nestane se součástí množiny UTXO. +Tento návrh na ephemeral anchors implicitně zabraňuje neanchor výstupům, aby +byly utraceny, dokud jsou nepotvrzené a nemají `1 OP_CSV` časové zámky, neboť +potomek musí tento anchor výstup utratit. Díky tomu by také byl proveditelný +[LN symmetry][topic eltoo] (eltoo), který by mohl využít [CPFP][topic cpfp] +jako mechanismu poskytování poplatků transakcím uzavírajícím kanál. Dále by +mohl být tento mechanismus použit u transakcí sdílených mezi více než dvěma +účastníky. Vývojáři používají k nasazení ephemeral anchors a navrhovaných soft +forků [bitcoin-inquisition][bitcoin inquisition repo], v jehož rámci budují +a testují tyto změny na [signetu][topic signet]. + +Problém pinningu, popsaný mimo jiné v tomto příspěvku, stál loni za [množstvím +diskuzí a návrhů vylepšení pravidel RBF][2022 rbf] v emailových skupinách, +pull requestech, sociálních médiích a při osobních setkáních. Vývojáři navrhli +a implementovali řešení v různých škálách, od malých úprav až po kompletní +předělání. Volba `-mempoolfullrbf`, jejímž účelem je potýkat se s problémem +pinningu a nesouladem v BIP125 implementacích, nám připomenula náročnost +a důležitost spolupráce v rámci pravidel přeposílání transakcí. A i když byly +upřímné snahy o zapojení komunity použitím obvyklých prostředků včetně konverzace +v emailové skupině Bitcoin-Dev rok dopředu, bylo zřejmé, že existující způsoby +komunikace a rozhodování nevyústily v zamýšlený výsledek a potřebovaly +doladit. + +Decentralizované rozhodování je náročným, ale nezbytným procesem v podpoře +různorodého ekosystému protokolů a aplikací, které používají bitcoinovou síť. +Příští týden bude náš poslední příspěvek v této sérii, ve kterém, doufáme, +se nám podaří zapojit čtenáře a zlepšit tento proces. + +[mempool clustering]: https://github.com/bitcoin/bitcoin/issues/27677 +[policy08]: /cs/newsletters/2023/07/05/#čekání-na-potvrzení-8-pravidla-jako-rozhraní +[2022 rbf]: /en/newsletters/2022/12/21/#rbf diff --git a/_includes/specials/policy/cs/10-get-involved.md b/_includes/specials/policy/cs/10-get-involved.md new file mode 100644 index 0000000000..ce2375f3f0 --- /dev/null +++ b/_includes/specials/policy/cs/10-get-involved.md @@ -0,0 +1,57 @@ +Doufáme, že tato série poskytla čtenářům lepší porozumění, co se děje +během čekání na potvrzení. Začali jsme zkoumáním, jak se ideologické +hodnoty bitcoinu [projevují][policy01] v jeho struktuře a designu. +Distribuovaná struktura peer-to-peer sítě nabízí oproti běžnému +centralizovanému modelu zvýšené soukromí a odolnost vůči cenzuře. +Otevřená síť propagace transakcí umožňuje každému dozvědět se o +transakcích ještě před jejich potvrzením, což zlepšuje [efektivitu +propagace bloků][policy01], usnadňuje počátky novým těžařům a přináší +[veřejnou aukci blokového prostoru][policy02]. Jelikož ideální síť sestává +z mnoha nezávislých anonymních entit provozujících uzly, musí být +software uzlů navržen tak, aby [ochraňoval před DoS][policy05] a +minimalizoval provozní náklady. + +Poplatky hrají v bitcoinu důležitou úlohu jako „spravedlivý” způsob +řešení soutěže o blokový prostor. Mempooly s nahrazováním transakcí +a algoritmy výběru a vyloučení využívají k měření užitku transakcí +[ekonomické incentivy][policy02] a dávají uživatelům k dispozici nástroje +k navyšování poplatků: [RBF][topic rbf] a [CPFP][topic cpfp]. Kombinace +pravidel mempoolu, peněženek se schopností [ekonomické konstrukce +transakcí][policy03] a dobrý [odhad poplatků][policy04] vytváří efektivní +trh blokového prostoru, který přináší užitek všem. + +Jednotlivé uzly dále vynucují _pravidla přeposílání transakcí_, aby +[chránily samy sebe před vyčerpáním zdrojů][policy05] a [vyjadřovaly +své osobní preference][policy06]. Na [úrovni celé sítě][policy07] +jsou aplikována pravidla standardnosti pro ochranu zdrojů nutných pro +škálování, dostupnost uzlů a schopnost měnit pravidla konsenzu. Jelikož +drtivá většina sítě tato pravidla vynucuje, jsou důležitou součástí +[rozhraní][policy08], nad nímž jsou bitcoinové aplikace a protokoly +druhé vrstvy vystavěny. Avšak nejsou dokonalá. Popsali jsme několik +[návrhů kolem pravidel][policy09], které adresují obecná omezení i +konkrétní případy jako jsou například [pinning útoky transakcí na +druhé vrstvě][policy08]. + +Též jsme zdůraznili, že probíhající evoluce pravidel sítě vyžaduje +spolupráci mezi vývojáři pracujícími na protokolech, aplikacích i +peněženkách. S růstem bitcoinového ekosystému, tedy s množstvím software, +případů užití a uživatelů, roste důležitost i náročnost procesu +decentralizovaného rozhodování. Tento systém vyvstává ze zájmů a cílů +účastníků bitcoinové sítě. Není v jejím středu žádná firma sbírající +názory zákazníků a najímající inženýry k přidávání nových funkcí. +Kdo si přeje být součástí širšího konsenzu sítě, může si vybrat +svou cestu: může se učit, ptát se, hlásit problémy, účastnit +se návrhu sítě nebo přímo přispívat ve vývoji novinek. + +Až budete příště příliš dlouho čekat na potvrzení své transakce, +budete vědět, co dělat. + +[policy01]: /cs/newsletters/2023/05/17/#čekání-na-potvrzení-1-k-čemu-je-mempool +[policy02]: /cs/newsletters/2023/05/24/#čekání-na-potvrzení-2-incentivy +[policy03]: /cs/newsletters/2023/05/31/#čekání-na-potvrzení-3-aukce-blokového-prostoru +[policy04]: /cs/newsletters/2023/06/07/#čekání-na-potvrzení-4-odhad-poplatků +[policy05]: /cs/newsletters/2023/06/14/#čekání-na-potvrzení-5-pravidla-pro-ochranu-zdrojů-uzlů +[policy06]: /cs/newsletters/2023/06/21/#čekání-na-potvrzení-6-konzistence-pravidel +[policy07]: /cs/newsletters/2023/06/28/#čekání-na-potvrzení-7-síťové-zdroje +[policy08]: /cs/newsletters/2023/07/05/#čekání-na-potvrzení-8-pravidla-jako-rozhraní +[policy09]: /cs/newsletters/2023/07/12/#čekání-na-potvrzení-9-návrhy-pravidel diff --git a/_includes/specials/policy/en/01-why-mempool.md b/_includes/specials/policy/en/01-why-mempool.md new file mode 100644 index 0000000000..08522c6477 --- /dev/null +++ b/_includes/specials/policy/en/01-why-mempool.md @@ -0,0 +1,79 @@ + + +Many nodes on the Bitcoin network store unconfirmed transactions in an +in-memory pool, or _mempool_. This cache is an important resource +for each node and enables the peer-to-peer transaction relay network. + +Nodes that participate in transaction relay +download and validate blocks gradually rather than in spikes. +Every ~10 minutes when a block is found, nodes without a mempool +experience a bandwidth spike, followed by a computation-intensive +period validating each transaction. On the other hand, nodes with a +mempool have typically already seen all of the block's transactions and +store them in their mempools. With [compact block relay][topic compact +block relay], these nodes just download a block header along with shortids, +and then reconstruct the block using transactions in their mempools. +The amount of data used to relay compact blocks is tiny compared to +the size of the block. Validating the transactions is +also much faster: the node has already verified (and cached) +signatures and scripts, calculated the timelock requirements, and +loaded relevant UTXOs from disk if necessary. The node can also +forward the block onto its other peers promptly, dramatically +increasing network-wide block propagation speed and thus reducing the +risk of stale blocks. + +Mempools can also be used to build an independent fee estimator. The +market for block space is a fee-based auction, and keeping a mempool +allows users to have a better sense of what others are bidding and +what bids have been successful in the past. + +However, there is no such thing as "the mempool"---each node may +receive different transactions. Submitting a transaction to one node +does not necessarily mean that it has made its way to miners. Some +users find this uncertainty frustrating, and wonder, "why don't we +just submit transactions directly to miners?" + +Consider a Bitcoin network in which all transactions are sent directly +from users to miners. One could censor and surveil financial activity +by requiring the small number of entities to log the IP addresses +corresponding to each transaction, and refuse to accept any +transactions matching a particular pattern. This type of Bitcoin may +be more convenient at times, but would be missing a few of Bitcoin's +most valued properties. + +Bitcoin's censorship-resistance and privacy come from its peer-to-peer +network. In order to relay a transaction, each node may connect to +some anonymous set of peers, each of which could be a miner or +somebody connected to a miner. This method helps obfuscate which node +a transaction originates from as well as which node may be responsible +for confirming it. Someone wishing to censor particular entities may +target miners, popular exchanges, or other centralized submission +services, but it would be difficult to block anything completely. + +The +general availability of unconfirmed transactions also helps minimize +the entrance cost of becoming a block producer---someone who is +dissatisfied with the transactions being selected (or excluded) +may start mining immediately. +Treating each node as an equal candidate for transaction broadcast +avoids giving any miner privileged access to transactions and their +fees. + +In summary, a mempool is an extremely useful cache that allows nodes +to distribute the costs of block download and validation over time, +and gives users access to better fee estimation. At a network level, +mempools support a distributed transaction and block relay network. +All of these benefits are most pronounced when everybody sees all +transactions before miners include them in blocks - just like any +cache, a mempool is most useful when it is "hot" and must be limited in size +to fit in memory. +Next week's section will explore the use of incentive compatibility as +a metric for keeping the most useful transactions in mempools. + diff --git a/_includes/specials/policy/en/02-cache-utility.md b/_includes/specials/policy/en/02-cache-utility.md new file mode 100644 index 0000000000..9798cb6780 --- /dev/null +++ b/_includes/specials/policy/en/02-cache-utility.md @@ -0,0 +1,82 @@ +[Last week’s post][policy01] discussed mempool as a cache of unconfirmed +transactions that provides a decentralized method for users to send +transactions to miners. However, miners are not obligated to confirm +those transactions; a block with just a coinbase transaction is valid +by consensus rules. Users can incentivize miners to include their +transactions by increasing total input value without changing total +output value, allowing miners to claim the difference as transaction +_fees_. + +Although transaction fees are common in traditional financial systems, +new Bitcoin users are often surprised to find that on-chain fees are +paid not in proportion to the transaction amount but by the weight of +the transaction. Block space, instead of liquidity, is the limiting +factor. _Feerate_ is typically denominated in satoshis per virtual +byte. + +Consensus rules limit the space used by transactions in each block. +This limit keeps block propagation times low relative to the block +interval, reducing the risk of stale blocks. It also helps restrict +the growth of the block chain and UTXO set, both of which directly +contribute to the cost of bootstrapping and maintaining a full node. + +As such, as part of their role as a cache of unconfirmed transactions, +mempools also facilitate a public auction for inelastic block space: +when functioning properly, the auction operates on free-market +principles, i.e., priority is based purely on fees rather than +relationships with miners. + +Maximizing fees when selecting transactions for a block (which has +limits on total weight and signature operations) is an [NP-hard problem][]. This problem +is further complicated by transaction relationships: mining a +high-feerate transaction may require mining its low-feerate parent. +Put another way, mining a low-feerate transaction may open up the +opportunity to mine its high-feerate child. + +The Bitcoin Core mempool computes the feerate for each entry and its +ancestors (called _ancestor feerate_), caches that result, and uses +a greedy block template building algorithm. It sorts the mempool in +_ancestor score_ order (the minimum of ancestor feerate and individual +feerate) and selects ancestor packages in that order, updating +the remaining transactions' ancestor fee and weight information as it goes. +This algorithm offers a balance between performance and profitability, +and does not necessarily produce optimal results. Its efficacy can be +boosted by restricting the size of transactions and ancestor +packages---Bitcoin Core sets those limits to 400,000 and 404,000 weight +units, respectively. + +Similarly, a _descendant score_ is calculated that is used when +selecting packages to evict from the mempool, as it would be +disadvantageous to evict a low-feerate transaction that has a +high-feerate child. + +Mempool validation also uses fees and feerate when dealing with +transactions that spend the same input(s), i.e. double-spends or +conflicting transactions. Instead of always keeping the first +transaction it sees, nodes use a set of rules to determine which +transaction is the more incentive compatible to keep. This behavior is +known as [Replace by Fee][topic rbf]. + +It is intuitive that miners would maximize fees, but why should a +non-mining node operator implement these policies? As mentioned in +last week's post, the utility of a non-mining node's mempool is +directly related to its similarity to miners' mempools. As such, even +if a node operator never intends to produce a block using the contents +of its mempool, they have an interest in keeping the most +incentive-compatible transactions. + +While there are no consensus rules requiring transactions to pay fees, +fees and feerate play an important role in the Bitcoin network as a +"fair" way to resolve competition for block space. Miners use feerate +to assess acceptance, eviction, and conflicts, while non-mining nodes +mirror those behaviors in order to maximize the utility of their +mempools. + +The scarcity of block space exerts a downward pressure on the size of +transactions and encourages developers to be more efficient in +transaction construction. Next week's post will explore practical +strategies and techniques for minimizing fees in on-chain +transactions. + +[policy01]: /en/newsletters/2023/05/17/#waiting-for-confirmation-1-why-do-we-have-a-mempool +[np-hard problem]: https://en.wikipedia.org/wiki/NP-hardness diff --git a/_includes/specials/policy/en/03-bidding-for-block-space.md b/_includes/specials/policy/en/03-bidding-for-block-space.md new file mode 100644 index 0000000000..57a554753d --- /dev/null +++ b/_includes/specials/policy/en/03-bidding-for-block-space.md @@ -0,0 +1,105 @@ + + +Last week we mentioned that transactions pay fees for the used +blockspace rather than the transferred amount, and established that +miners optimize their transaction selection to maximize collected fees. +It follows that only those transactions get confirmed that reside in the +top of the mempool when a block is found. In this post, we will discuss +practical strategies to get the most for our fees. Let’s assume we have +a decent source of feerate estimates—we will talk more about feerate +estimation in next week’s article. + +While constructing transactions, some parts of the transaction are more +flexible than others. Every transaction requires the header fields, the +recipient outputs are determined by the payments being made, and most +transactions require a change output. Both sender and receiver should +prefer blockspace-efficient output types to reduce the future cost of +spending their transaction outputs, but it’s during the [input +selection][topic coin selection] that there is the most room to change +the final composition and weight of the transaction. As transactions +compete by feerate [fee/weight], a lighter transaction requires a lower +fee to reach the same feerate. + +Some wallets, such as the Bitcoin Core wallet, try to combine inputs +such that they avoid needing a change output altogether. Avoiding change +saves the weight of an output now, but also saves the future cost of +spending the change output later. Unfortunately, such input combinations +will only seldom be available unless the wallet sports a large UTXO pool +with a broad variety of amounts. + +Modern output types are more blockspace-efficient than older output +types. E.g. spending a P2TR input incurs less than 2/5ths of a P2PKH +input’s weight. (Try it with our [transaction size +calculator][]!) For multisig wallets, the recently +finalized [MuSig2][topic musig] schema and FROST protocol chalk out huge +cost savings by permitting multisig functionality to be encoded in what +looks like a single-sig input. Especially in times when blockspace +demand goes through the roof, a wallet using modern output types by +itself translates to big cost savings. + +{:.center} +![Overview of input and output weights](/img/posts/specials/input-output-weights.png) + +Smart wallets change their selection strategy on the basis of the +feerate: at high feerates they use few inputs and modern input types to +achieve the lowest possible weight for the input set. Always selecting +the lightest input set would locally minimize the cost of the current +transaction, but also grind a wallet’s UTXO pool into small fragments. +This could set the user up for transactions with huge input sets at high +feerates later. Therefore, it is prescient for wallets to also select +more and heavier inputs at low feerates to opportunistically consolidate +funds into fewer modern outputs in anticipation of later blockspace +demand spikes. + +High-volume wallets often batch multiple payments into a single +transaction to reduce the transaction weight per payment. Instead of +incurring the overhead of the header bytes and the change output for +each payment, they only incur the overhead cost once shared across all +payments. Even just batching a few payments quickly reduces cost per +payment. + +![Savings from payment batching with +P2WPKH](/img/posts/payment-batching/p2wpkh-batching-cases-combined.png) + +Still, even while many wallets estimate feerates erring on overpayment, +on a slow block or surge in transaction submissions, transactions +sometimes sit unconfirmed longer than planned. In those cases, either +the sender or receiver may want to reprioritize the transaction. + +Users generally have two tools at their disposal to increase their +transaction’s priority, child pays for parent ([CPFP][topic cpfp]) and +replace by fee ([RBF][topic rbf]). In CPFP, a user spends their +transaction output to create a high-feerate child transaction. As +described in last week’s post, miners are incentivized to pick the +parent into the block in order to include the fee-rich child. CPFP is +available to any user that gets paid by the transaction, so either +receiver or sender (if they created a change output) can make use of it. + +In RBF, the sender authors a higher-feerate replacement of the original +transaction. The replacement transaction must reuse at least one input +from the original transaction to ensure a conflict with the original and +that only one of the two transactions can be included in the blockchain. +Usually this replacement includes the payments from the original +transaction, but the sender could also redirect the funds in the +replacement transaction, or combine multiple transactions’ payments into +one upon replacement. As described in last week’s post, nodes evict the +original transaction in favor of the more incentive-compatible +replacement transaction. + +While both demand for and production of blockspace are outside our +control, there are many techniques wallets can use to bid for blockspace +effectively. Wallets can save fees by creating lighter transactions +through eliminating the change output, spending native segwit outputs, +and defragmenting their UTXO pool during low feerate environments. +Wallets that support CPFP and RBF can also start with a conservative +feerate and then update the transaction’s priority using CPFP or RBF if +needed. + +[transaction size calculator]: /en/tools/calc-size diff --git a/_includes/specials/policy/en/04-feerate-estimation.md b/_includes/specials/policy/en/04-feerate-estimation.md new file mode 100644 index 0000000000..7084a5a394 --- /dev/null +++ b/_includes/specials/policy/en/04-feerate-estimation.md @@ -0,0 +1,94 @@ +Last week, we explored techniques for minimizing the fees paid on a +transaction given a feerate. But what should that feerate be? Ideally, +as low as possible to save money, but high enough to secure a spot in +a block suitable for the user's time preference. + +The goal of _fee(rate) estimation_ is to translate a target timeframe for +confirmation to a minimal feerate the transaction should pay. + +One complication of fee estimation is the irregularity of block space +production. Let's say a user needs to pay a merchant within one hour +to receive their goods. The user may expect a block to be mined every +10 minutes, and thus aim for a spot within the next 6 blocks. However, +it's entirely possible for one block to take 45 minutes to be found. +Fee estimators must translate between a user’s desired urgency or +timeframe (something like “I want this to confirm by the end of the +work day”) and a supply of block space (a number of blocks). Many fee +estimators address this challenge by denominating confirmation targets +in the number of blocks in addition to time. + +With no information about transactions prior to their confirmation, +one can build a naive fee estimator that uses historical data about +what transaction feerates tend to land in blocks. As this estimator is +blind to the transactions awaiting confirmation in mempools, it would +become very inaccurate during unexpected fluctuations in block space demand +and the occasional long block interval. Its other weakness is its +reliance on information controlled wholly by miners, who would be able +to drive feerates up by including fake high-feerate transactions in +their blocks. + +Fortunately, the market for block space is not a blind auction. We +mentioned in our [first post][policy01] that keeping a mempool and participating +in the peer-to-peer transaction relay network allows a node to see +what users are bidding. The Bitcoin Core fee estimator also uses +historical data to calculate the likelihood of a transaction at +feerate `f` confirming within `n` blocks, but specifically tracks the +height at which the node first sees a transaction and when it +confirms. This method works around activity that happens outside the +public fee market by ignoring it. If miners include artificially +high-feerate transactions in their own blocks, this fee estimator +isn't skewed because it only uses data from transactions that were +publicly relayed prior to confirmation. + +We also have insights into the way transactions are selected for blocks. +In a [previous post][policy02], we mentioned that nodes emulate miner +policies in order to keep incentive-compatible transactions in their +mempools. Expanding on this idea, instead of looking only at past +data, we could build a fee estimator that simulates what a miner would +do. To find out what feerate a transaction would need to confirm in +the next `n` blocks, the fee estimator could use the block assembly +algorithm to project the next `n` block templates from its mempool +and calculate the feerate that would beat the last transaction(s) that +make it into block `n`. + +Clearly, the efficacy of this fee estimator's approach depends +on the similarity between the contents of its mempool and the +miners', which can never be guaranteed. It is also blind to +transactions a miner might include due to exterior motivations, e.g. +transactions that belong to the miner or paid out-of-band fees to be +confirmed. The projection must also account for additional transaction +broadcasts between now and when the projected blocks are found. It can +do so by decreasing the size of its projected blocks to account for +other transactions – but by how much? + +This question once again highlights the utility of historical data. An +intelligent model may be able to incorporate patterns of activity and +account for external events that influence feerates such as typical +business hours, a company's scheduled UTXO consolidation, and activity +in response to changes in Bitcoin's trading price. The problem of +forecasting block space demand remains ripe for exploration, and is +likely to always have room for innovation. + +Fee estimation is a multi-faceted and difficult problem. Bad fee +estimation can waste funds by overpaying fees, add friction to the use +of Bitcoin for payments, and cause L2 users to lose money by missing a +window within which a timelocked UTXO had an alternate spending path. +Good fee estimation allows users to clearly and precisely communicate +transaction urgency to miners, and [CPFP][topic cpfp] and [RBF][topic rbf] allow users to update +their bids if initial estimates undershoot. Incentive-compatible +mempool policies, combined with well-designed fee estimation tools and [wallets][policy03], +enable users to participate in an efficient, public auction for block +space. + +Fee estimators typically never return anything below 1sat/vB, +regardless of how long the time horizon is or how few transactions are +pending confirmation. Many consider 1sat/vB as the de facto floor +feerate in the Bitcoin network, due to the fact that most nodes on the +network (including miners) [never accept][topic default minimum transaction relay feerates] anything below that feerate, +regardless of how empty their mempools are. Next week's post will +explore this node policy and another motivation for utilizing feerate +in transaction relay: protection from resource exhaustion. + +[policy01]: /en/newsletters/2023/05/17/#waiting-for-confirmation-1-why-do-we-have-a-mempool +[policy02]: /en/newsletters/2023/05/24/#waiting-for-confirmation-2-incentives +[policy03]: /en/newsletters/2023/05/31/#waiting-for-confirmation-3-bidding-for-block-space diff --git a/_includes/specials/policy/en/05-dos.md b/_includes/specials/policy/en/05-dos.md new file mode 100644 index 0000000000..0fda11f743 --- /dev/null +++ b/_includes/specials/policy/en/05-dos.md @@ -0,0 +1,110 @@ +We [started off][policy01] our series by stating that much of Bitcoin's privacy and +censorship resistance stems from the decentralized nature of the +network. The practice of users running their own nodes reduces central points of +failure, surveillance, and censorship. It follows that one +primary design goal for Bitcoin node software is high accessibility of +running a node. Requiring each Bitcoin user to purchase expensive +hardware, use a specific operating system, or spend hundreds of +dollars per month in operational costs would very likely reduce the +number of nodes on the network. + +Additionally, a node +on the Bitcoin network is a computer with internet connections to +unknown entities that may launch a Denial of Service (DoS) attack by +crafting messages that cause the node to run out of memory and crash, +or spend its computational resources and bandwidth on meaningless data +instead of accepting new blocks. As these entities are anonymous by +design, nodes cannot predetermine whether a peer will be honest or +malicious before connecting, and cannot effectively ban them even after an +attack is observed. Thus, it is not just an ideal to implement policies +that protect against DoS and limit the cost of +running a full node, but an imperative. + +General DoS protections are built into node implementations to +prevent resource exhaustion. For example, if a Bitcoin Core node +receives many messages from a single peer, it only processes the first +one and adds the rest to a work queue to be processed after other +peers' messages. A node also typically first downloads a block header +and verifies its Proof of Work (PoW) prior to downloading and validating the +rest of the block. Thus, any attacker wishing to exhaust this node's resources +through block relay must first spend a +disproportionately high amount of their own resources computing a +valid PoW. The asymmetry between the huge cost for PoW +calculation and the trivial cost of verification provides a natural way to build DoS resistance into +block relay. +This property does +not extend to _unconfirmed_ transaction relay. + +General DoS protections don't provide enough attack resistance to allow a node’s consensus +engine to be exposed to input from the peer-to-peer network. An attacker attempting +to [craft a maximally computationally-intensive][max cpu tx], consensus-valid +transaction may send one like the 1MB +[“megatransaction”][megatx mempool space] in block #364292, +which took an abnormally long time to validate due +to [signature verification and quadratic sighashing][rusty megatx]. An +attacker may also make all but the last signature valid, causing the +node to spend minutes on their transaction, only to find that it is +garbage. During that time, the node would delay processing a new +block. One can imagine this type of attack being +targeted at competing miners to gain a “head start” on the next block. + +In an effort to avoid working on very computationally expensive transactions, +Bitcoin Core nodes impose a maximum standard size and a +maximum number of signature operations (or "sigops") on each +transaction, more restrictive than the block consensus limit. Bitcoin Core nodes also +enforce limits on both ancestor and descendant package sizes, making +block template production and eviction algorithms more effective and +[restricting the computational +complexity][se descendant limits] of mempool insertion and deletion +which require updating a transaction’s ancestor and descendant sets. +While +this means some legitimate transactions may not be accepted or +relayed, those transactions are expected to be rare. + +These rules are +examples of _transaction relay policy_, a set of validation rules in +addition to consensus which nodes apply to unconfirmed transactions. + +By default, Bitcoin Core nodes do not accept transactions below the 1sat/vB minimum relay feerate +("minrelaytxfee"), do not verify any signatures before checking this requirement, and do not forward +transactions unless they are accepted to their mempools. +In a sense, this feerate rule sets a minimum "price" for network validation and relay. +A non-mining node doesn’t ever receive fees – they are +only paid to the miner who confirms the transaction. +However, fees represent a cost to the attacker. Somebody who "wastes" network resources by sending an +extremely high amount of transactions +eventually runs out of money to pay the fees. + +The [Replace by Fee][topic rbf] policy [implemented by Bitcoin Core][bitcoin core +rbf docs] requires that the replacement transaction pay a higher +feerate than each transaction it directly conflicts with, but also +requires that it pay a higher total fee than all of the transactions it displaces. The additional fees +divided by the replacement transaction's +virtual size must be at least 1sat/vB. +In other words, regardless of the feerates of the original +and replacement transactions, the new transaction must pay "new" fees +to cover the cost of its own bandwidth at 1sat/vB. +This fee policy is not +primarily concerned with incentive compatibility. Rather, this incurs +a minimum cost for repeated transaction replacements to curb +bandwidth-wasting attacks, e.g. one that adds just 1 additional +satoshi to each replacement. + +A node that fully validates blocks and transactions requires resources +including memory, computational resources, and network bandwidth. We +must keep resource requirements low in order to +make running a node accessible and to defend the node +against exploitation. General DoS protections are not enough, so +nodes apply transaction relay policies in addition to consensus rules +when validating unconfirmed transactions. However, as policy is not +consensus, two nodes may have different policies but still agree on +the current chain state. Next week’s post will discuss policy +as an individual choice. + +[policy01]: /en/newsletters/2023/05/17/#waiting-for-confirmation-1-why-do-we-have-a-mempool +[max cpu tx]: https://bitcointalk.org/?topic=140078 +[megatx mempool space]: https://mempool.space/tx/bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08 +[rusty megatx]: https://rusty.ozlabs.org/?p=522 +[bitcoin core rbf docs]: https://github.com/bitcoin/bitcoin/blob/v25.0/doc/policy/mempool-replacements.md +[pr 6722]: https://github.com/bitcoin/bitcoin/pull/6722 +[se descendant limits]: https://bitcoin.stackexchange.com/questions/118160/whats-the-governing-motivation-for-the-descendent-size-limit diff --git a/_includes/specials/policy/en/06-consistency.md b/_includes/specials/policy/en/06-consistency.md new file mode 100644 index 0000000000..cdd41c2120 --- /dev/null +++ b/_includes/specials/policy/en/06-consistency.md @@ -0,0 +1,101 @@ +Last week’s post introduced policy, a set of transaction validation +rules applied in addition to consensus rules. These rules are not +applied to transactions in blocks, so a node can still stay in +consensus even if its policy differs from that of its peers. Just like +a node operator may decide to not participate in transaction relay, +they are also free to choose any policy, up to none at all (exposing +their node to the DoS risk). This means we cannot assume complete +homogeneity of mempool policies across the network. However, in order +for a user’s transaction to be received by a miner, it must travel +through a path of nodes that all accept it into their mempool – +dissimilarity of policy between nodes directly affects transaction +relay functionality. + +As an extreme example of policy differences between nodes, imagine a +situation in which each node operator chose a random `nVersion` and +only accepted transactions with that `nVersion`. As most peer-to-peer +relationships would have incompatible policies, transactions would not +propagate to miners. + +On the other end of the spectrum, identical policies across the +network help converge mempool contents. A network with matching +mempools relays transactions the most smoothly, and is also ideal for +[fee estimation][policy04] and [compact block relay][policy01] as +mentioned in previous posts. + +Given the complexity of mempool validation and the difficulties that +arise from policy disparities, Bitcoin Core has [historically been +conservative][aj mempool consistency] with the configurability of +policies. While users are able to easily tweak the way sigops are +counted (`bytespersigop`) and limit the amount of data embedded +in `OP_RETURN` outputs (`datacarriersize` and `datacarrier`), they +cannot opt out of the 400,000 weight-unit maximum standard weight or apply a +different set of fee-related RBF rules without changing the source +code. + +Some of Bitcoin Core’s policy configuration options exist to +accommodate the difference in node operating environments and purposes +for running a node. For example, a miner’s hardware resources and +purpose for keeping a mempool differ from a day-to-day user running a +lightweight node on their laptop or Raspberry Pi. A miner may opt to +increase their mempool capacity (`maxmempool`) or expiration timeline +(`mempoolexpiry`) to store low feerate transactions during peak +traffic, and then mine them later when traffic dies down. Websites +providing visualizations, archives, and network statistics may run +multiple nodes to collect as much data as possible and also display +default mempool behavior. + +On an individual node, the choice of mempool capacity affects the +availability of fee-bumping tools. When the mempool minimum feerates +rise due to transaction submissions exceeding the default mempool +size, transactions purged from the “bottom” of the mempool and new +ones that are below this feerate can no longer be fee-bumped using +[CPFP][topic cpfp]. + +On the other hand, since the inputs used by the purged transactions +are no longer spent by any transactions in the mempool, it may be +possible to fee-bump via [RBF][topic rbf] when it wasn’t before. The new +transaction isn’t actually replacing anything in the node’s mempool, +so it doesn’t need to consider the usual RBF rules. However, nodes +that haven’t evicted the original transaction (because they have a +larger mempool capacity) treat the new transaction as a proposed +replacement and require it to abide by the RBF rules. If the purged +transaction was not signaling BIP125 replaceability, or the new +transaction’s fee does not meet RBF requirements despite being high +feerate, the miner may not accept their new transaction. Wallets must +handle purged transactions carefully: the transaction’s outputs cannot +be considered available for spending, but the inputs are similarly +unavailable to reuse. + +At quick glance, it may seem that a node with larger mempool capacity +makes CPFP more useful and RBF less useful. However, transaction relay +is subject to emergent network behavior and there might not be a path +of nodes accepting the CPFP from the user to the miner. Nodes +typically only forward transactions once upon accepting it to their +mempool and ignore announcements of transactions that already exist in +their mempools—nodes that store more transactions [act as +blackholes][se maxmempool] when those transactions are rebroadcast to +them. Unless the entire network increases their mempool capacities – +which would be a sign to change the default value – users should +expect little benefit from increasing the capacity of their own +mempools. The mempool minimum feerate set by default mempools limits +the utility of using CPFP during high-traffic times. A user who +managed to submit a CPFP transaction to their own increased-size +mempool might fail to notice that the transaction did not propagate to +anyone else. + +The transaction relay network is composed of individual nodes which +dynamically join and leave the network, each of whom must protect +themselves against exploitation. As such, transaction relay can only +be a best-effort and we cannot guarantee that every node learns about +every unconfirmed transaction. At the same time, the Bitcoin network +performs best if nodes converge on one set of transaction relay +policies that makes mempools as homogeneous as possible. The next post +will explore what policies have been adopted in order to fit the +network’s interests as a whole. + +[policy01]: /en/newsletters/2023/05/17/#waiting-for-confirmation-1-why-do-we-have-a-mempool +[policy04]: /en/newsletters/2023/06/07/#waiting-for-confirmation-4-feerate-estimation +[aj mempool consistency]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021116.html +[se maxmempool]: https://bitcoin.stackexchange.com/questions/118137/how-does-it-contribute-to-the-bitcoin-network-when-i-run-a-node-with-a-bigger-th + diff --git a/_includes/specials/policy/en/07-network-resources.md b/_includes/specials/policy/en/07-network-resources.md new file mode 100644 index 0000000000..eb27b4ff48 --- /dev/null +++ b/_includes/specials/policy/en/07-network-resources.md @@ -0,0 +1,92 @@ +A previous post discussed protecting node resources, which may be unique to +each node and thus sometimes configurable. We also made our case for why it is best +to converge on one policy, but what should be part of that policy? This post +will discuss the concept of network-wide resources, critical to things like +scalability, upgradeability and accessibility of bootstrapping and maintaining +a full node. + +As discussed in [previous posts][policy01], many of the Bitcoin network’s +ideological goals are embodied in its distributed structure. Bitcoin's peer-to-peer +nature allows the rules of the network to emerge from rough +consensus of the individual node operators’ choices and curbs attempts to +acquire undue influence in the network. Those rules are then enforced by each +node individually validating every transaction. A diverse and healthy node +population requires that the cost of operating a node is kept low. It is hard +to scale any project with a global audience, but doing so without sacrificing +decentralization is akin to fighting with one hand tied to your back. The +Bitcoin project attempts this balancing act by being fiercely protective of its +shared network resources: the UTXO set, the data footprint of the blockchain +and the computational effort required to process it, and upgrade hooks to +evolve the Bitcoin protocol. + +There is no need to reiterate the entire blocksize war to realize that a limit +on blockchain growth is necessary to keep it affordable to run your own node. +However, blockchain growth is also dissuaded at the policy level by the +`minRelayTxFee` of 1 sat/vbyte, ensuring a minimum cost to express some of the +“[unbounded demand for highly-replicated perpetual storage][unbounded]”. + +Originally, the network state was tracked by keeping all transactions that +still had unspent outputs. This much bigger portion of the blockchain got +reduced significantly with the [introduction of the UTXO set][ultraprune] as +the means of keeping track of funds. Since then, the UTXO set has been a +central data structure. Especially during IBD, but also generally, UTXO lookups +represent a major portion of all memory accesses of a node. Bitcoin Core +already uses a [manually optimized data structure for the UTXO cache][pooled +resource], but the size of the UTXO set determines how much of it cannot fit in +a node’s cache. A larger UTXO set means more cache misses which slows down +block validation, IBD, and transaction validation speed. The dust limit is an +example of a policy that restricts the creation of UTXOs, specifically curbing +UTXOs that might never get spent because their amount [falls short][topic uneconomical outputs] of the cost +for spending them. Even so, [“dust storms” with thousands of transactions +occurred as recently as 2020][lopp storms]. + +When it became popular to use bare multisig outputs to publish data onto the +blockchain, the definition of standard transactions was amended to permit a +single OP_RETURN output as an alternative. People realized that it would be +impossible to prevent users from publishing data on the blockchain, but at +least such data would not need to live in the UTXO set forever when published +in outputs that could never be spent. Bitcoin Core 0.13.0 introduced a start-up +option `-permitbaremultisig` that users may toggle to reject unconfirmed +transactions with bare multisig outputs. + +While the consensus rules allow output scripts to be freeform, only a few +well-understood patterns are relayed by Bitcoin Core nodes. This makes it +easier to reason about many concerns in the network, including validation costs +and protocol upgrade mechanisms. For example, an input script that contains +op-codes, a P2SH input with more than 15 signatures, or a P2WSH input whose +witness stack has more than 100 items each would make a transaction +non-standard. (Check out this [policy overview][instagibbs policy zoo] for more +examples of policies and their motivations.) + +Finally, the Bitcoin protocol is a living software project that will need to +keep evolving to address future challenges and user needs. To that end, there +are a number of upgrade hooks deliberately left consensus valid but unused, +such as the annex, taproot leaf versions, witness versions, OP_SUCCESS, and a +number of no-op opcodes. However, just like attacks are hindered by the lack of +central points of failure, network-wide software upgrades involve a coordinated +effort between tens of thousands of independent node operators. Nodes will not +relay transactions that make use of any reserved upgrade hooks until their +meaning has been defined. This discouragement is meant to dissuade applications +from independently creating conflicting standards, which would make it +impossible to adopt one application’s standard into consensus without +invalidating another’s. Also, when a consensus change does happen, nodes that +do not upgrade immediately—and thus do not know the new consensus rules—cannot +be “tricked” into accepting a now-invalid transaction into their mempools. The +proactive discouragement helps nodes be forward-compatible and enables the +network to safely upgrade consensus rules without requiring a completely +synchronized software update. + +We can see that using policy to protect shared network resources aids in +protecting the network’s characteristics, and keeps paths for future protocol +development open. Meanwhile, we are seeing how the friction of growing the +network against a strictly limited blockweight has been driving adoption of +best practices, good technical design, and innovation: next week’s post +will explore mempool policy as an interface for second-layer protocols and +smart contract systems. + +[policy01]: /en/newsletters/2023/05/17/#waiting-for-confirmation-1-why-do-we-have-a-mempool +[unbounded]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html +[lopp storms]: https://blog.lopp.net/history-bitcoin-transaction-dust-spam-storms/ +[ultraprune]: https://github.com/bitcoin/bitcoin/pull/1677 +[pooled resource]: /en/newsletters/2023/05/03/#bitcoin-core-25325 +[instagibbs policy zoo]: https://gist.github.com/instagibbs/ee32be0126ec132213205b25b80fb3e8 diff --git a/_includes/specials/policy/en/08-interface.md b/_includes/specials/policy/en/08-interface.md new file mode 100644 index 0000000000..8a8a9bec67 --- /dev/null +++ b/_includes/specials/policy/en/08-interface.md @@ -0,0 +1,119 @@ +So far in this series, we have explored the [motivations][policy01] +and challenges associated with decentralized transaction relay, +leading to a [local][policy05] and [global][policy07] need for +transaction validation rules more restrictive than consensus. Since +transaction relay policy changes to Bitcoin Core can impact whether an +application’s transactions relay, they require socialization with the +wider Bitcoin community prior to consideration. Similarly, +applications and second layer protocols that utilize transaction relay +must be designed with policy rules in mind to avoid creating +transactions that are rejected. + +Contracting protocols are even more intimately dependent on policies +related to prioritization because enforceability on-chain depends on +being able to get transactions confirmed quickly. In adversarial +environments, cheating counterparties may have an interest in delaying +a transaction’s confirmation, so we must also think about how quirks +in the transaction relay policy interface can be used against a user. + +Lightning Network transactions adhere to the standardness rules +mentioned in earlier posts. For example, the peer-to-peer protocol specifies a +`dust_limit_satoshis` in its +`open_channel` message to specify a dust threshold. +Since a transaction containing an output with a +value lower than the dust threshold would not relay due to nodes’ dust +limits, those payments are considered “not enforceable on-chain” and +trimmed from commitment transactions. + +Contracting protocols often use timelocked spending paths to give each +participant the opportunity to contest the state published on-chain. +If the affected user cannot get a transaction confirmed within that +frame of time, they may suffer loss of funds. This makes fees +extremely important as the primary mechanism for boosting confirmation +priority, but also more challenging. [Feerate estimation][policy04] is +complicated by the fact that transactions will be broadcast at some +unknown later time, nodes often operate as thin clients, and some +fee-bumping options are unavailable. For example, if an LN channel +participant goes offline, the other party may unilaterally broadcast a +presigned commitment transaction to settle the distribution of their +shared funds on-chain. Neither party can unilaterally spend the shared +UTXO, so when one party is offline, signing a [replacement][topic rbf] +transaction to fee-bump the commitment transaction is not possible. +Instead, LN commitment transactions may include [anchor outputs][topic +anchor outputs] for channel participants to attach a [fee-bumping child][topic cpfp] +at broadcast time. + +However, this fee-bumping method also has limitations. As mentioned in +a [previous post][policy06], adding a CPFP transaction is not +effective if mempool minimum feerates rise higher than the commitment +transaction’s feerate, so they must still be signed with a slightly +overestimated feerate in case mempool minimum feerates rise in the +future. Additionally, the development of anchor outputs included a +number of considerations for the fact that one party may have an +interest in delaying confirmation. For example, a party (Alice) may broadcast +their own commitment transaction to the network prior to going +offline. If this commitment transaction’s feerate is too low for +immediate confirmation and if Alice's counterparty (Bob) doesn't receive her transaction, +he may be confused when his broadcasts of his version of the +commitment transaction aren't successfully relayed. +Each commitment transaction has two anchor outputs so that either party +may CPFP any of the commitment transactions, e.g. Bob may try to blindly +broadcast a CPFP fee bump of Alice's version of the commitment +transaction even if he isn't sure that she previously broadcast her +version. Each anchor output is assigned a small value +above the dust threshold and claimable by anyone after some time to +avoid bloating the UTXO set. + +However, guaranteeing each party’s ability to CPFP a transaction is +more complicated than giving each party an anchor output. As mentioned +in a [previous post][policy05], Bitcoin Core limits the number and +total size of descendant transactions that can be attached to an +unconfirmed transaction as a DoS protection. Since each counterparty +has the ability to attach descendants to the shared transaction, one +could block the other’s CPFP transaction from relaying by exhausting +those limits. The presence of these descendants consequently “pins” +the commitment transaction to its low-priority status in mempools. + +To mitigate this potential attack, the LN anchor outputs proposal +locks all non-anchor outputs with a relative timelock, preventing +them from being spent while the transaction is unconfirmed, and +Bitcoin Core’s descendant limit policy was [modified to allow one +extra descendant][topic cpfp carve out] when this new descendant was +small and had no other ancestors. This combination of changes to both +protocols ensured that at least two participants in a shared transaction could make +feerate adjustments at broadcast time, while not significantly +increasing the transaction relay DoS attack surface. + +CPFP prevention through domination of the descendant limit is an +example of a [pinning attack][topic transaction pinning]. Pinning attacks take advantage of +limitations in mempool policy to prevent incentive-compatible +transactions from entering mempools or getting confirmed. In this +case, mempool policy has made a tradeoff between +[DoS-resistance][policy05] and [incentive compatibility][policy02]. +Some tradeoff must be made – a node should consider fee bumps but +cannot process infinitely many descendants. CPFP carve out refines +this tradeoff for a specific use case. + +Beyond exhausting the descendant limit, there are other pinning +attacks that [altogether prevent use of RBF][full rbf pinning], make +RBF [prohibitively expensive][rbf ml], or leverage RBF to delay +confirmation of an ANYONECANPAY transaction. Pinning is only an issue +in scenarios where multiple parties collaborate in creating a +transaction or when there is otherwise room for an untrusted party to +interact with the transaction. Minimizing a transaction’s exposure to +untrusted parties is generally a good way to avoid pinning. + +These points of friction highlight not just the importance of policy +as an interface for applications and protocols in the Bitcoin +ecosystem, but where it needs to improve. Next week’s post will +discuss policy proposals and open questions. + +[full rbf pinning]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html +[rbf ml]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html +[n25038 notes]: https://bitcoincore.reviews/25038 +[policy01]: /en/newsletters/2023/05/17/#waiting-for-confirmation-1-why-do-we-have-a-mempool +[policy02]: /en/newsletters/2023/05/24/#waiting-for-confirmation-2-incentives +[policy04]: /en/newsletters/2023/06/07/#waiting-for-confirmation-4-feerate-estimation +[policy05]: /en/newsletters/2023/06/14/#waiting-for-confirmation-5-policy-for-protection-of-node-resources +[policy06]: /en/newsletters/2023/06/21/#waiting-for-confirmation-6-policy-consistency +[policy07]: /en/newsletters/2023/06/28/#waiting-for-confirmation-7-network-resources diff --git a/_includes/specials/policy/en/09-proposals.md b/_includes/specials/policy/en/09-proposals.md new file mode 100644 index 0000000000..172fd58e69 --- /dev/null +++ b/_includes/specials/policy/en/09-proposals.md @@ -0,0 +1,118 @@ +[Last week’s post][policy08] described [anchor outputs][topic anchor outputs] and [CPFP carve +out][topic cpfp carve out], ensuring either channel party can fee-bump their shared +commitment transactions without requiring collaboration. This approach +still contains a few drawbacks: channel funds are tied up to create +anchor outputs, commitment transaction feerates typically overpay +to ensure they meet mempool minimum feerates, and CPFP carve out only +allows one extra descendant. Anchor outputs cannot ensure the same +ability to fee-bump for transactions shared between more than two +parties, such as [coinjoins][topic coinjoin] or multi-party contracting protocols. This +post explores current efforts to address these and other limitations. + +[Package relay][topic package relay] includes P2P protocol and policy +changes to enable the transport and validation of groups of +transactions. It would allow a commitment transaction to be fee-bumped +by a child even if the commitment transaction does not meet a mempool’s +minimum feerate. Additionally, _Package RBF_ would allow +the fee-bumping child to pay for [replacing][topic rbf] transactions its parent +conflicts with. Package relay is designed to remove a general limitation +at the base protocol +layer. However, due to its utility in fee-bumping of shared +transactions, it has also spawned a number of efforts to eliminate [pinning][topic transaction pinning] for +specific use cases. For example, Package RBF would allow commitment +transactions to replace each other when broadcast with their +respective fee-bumping children, removing the need for multiple anchor +outputs on each commitment transaction. + +A caveat is that existing RBF rules require the replacement +transaction to pay a higher absolute fee than the aggregate fees paid +by all to-be-replaced transactions. This rule helps prevent DoS +through repeated replacements, but allows a malicious user to increase +the cost to replace their transaction by attaching a child that is +high fee but low feerate. This hinders the transaction from being +mined by unfairly preventing its replacement by a high-feerate +package, and is often referred to as “Rule 3 pinning.” + +Developers have also proposed entirely different ways of adding fees +to presigned transactions. For example, signing inputs of the +transaction using `SIGHASH_ANYONECANPAY | SIGHASH_ALL` could allow the +transaction broadcaster to provide fees by appending additional inputs +to the transaction without changing the outputs. However, as RBF does +not have any rule requiring the replacement transaction to have a +higher “mining score” (i.e. would be selected for a block faster), an +attacker could pin these types of transactions by creating +replacements encumbered by low-feerate ancestors. What complicates +the accurate assessment of the mining score of transactions and +transaction packages is that the existing ancestor and descendant +limits are insufficient to bound the computational complexity of this +calculation. Any connected transactions can influence the +order in which transactions get picked into a block. A fully-connected +component, called a _cluster_, can be of any size given current +ancestor and descendant limits. + +A long term solution to address some mempool deficiencies and RBF +pinning attacks is to [restructure the mempool data structure to track +clusters][mempool clustering] instead of just ancestor and descendant +sets. These clusters would be limited in size. A cluster limit would +restrict the way users can spend unconfirmed UTXOs, but make it +feasible to quickly linearize the entire mempool using the ancestor +score-based mining algorithm, build block templates extremely quickly, +and add a requirement that replacement transactions have a +higher mining score than the to-be-replaced transaction(s). + +Even so, it’s possible that no single set of policies can meet the +wide range of needs and expectations for transaction relay. For +example, while recipients of a batched payment transaction benefit +from being able to spend their unconfirmed outputs, +a relaxed descendant limit leaves room for pinning package RBF of a shared +transaction through absolute fees. A proposal for [v3 transaction +relay policy][topic v3 transaction relay] was developed to allow +contracting protocols to opt in to a more restrictive set of package +limits. V3 transactions would only permit packages of size two (one +parent and one child) and limit the weight of the child. These limits +would mitigate RBF pinning through absolute fees, and offer some of +the benefits of cluster mempool without requiring a mempool +restructure. + +[Ephemeral Anchors][topic ephemeral anchors] builds upon the +properties of v3 transactions and package relay to improve anchor +outputs further. It exempts anchor outputs +belonging to a zero-fee v3 transaction from the [dust limit][topic +uneconomical outputs], provided the anchor output is +spent by a fee-bumping child. Since the zero-fee transaction must be +fee-bumped by exactly one child (otherwise a miner would not be +incentivized to include it in a block), this anchor output is +“ephemeral” and would not become a part of the UTXO set. The ephemeral +anchor proposal implicitly prevents non-anchor outputs from being +spent while unconfirmed without `1 OP_CSV` timelocks, since the only +allowed child must spend the anchor output. +It would also make [LN symmetry][topic eltoo] feasible with [CPFP][topic cpfp] as the fee +provisioning mechanism for channel closing transactions. It also makes +this mechanism available for transactions shared between more than two +participants. Developers have been using [bitcoin-inquisition][bitcoin inquisition repo] to deploy +Ephemeral Anchors and proposed soft forks to build and test these +multi-layer changes on a [signet][topic signet]. + +The pinning problems highlighted in this post, among others, spawned a +[wealth of discussions and proposals to improve RBF +policy][2022 rbf] last year across mailing lists, pull requests, +social media, and in-person meetings. Developers proposed and +implemented solutions ranging from small amendments to a complete +revamp. The `-mempoolfullrbf` option, intended to address pinning +concerns and a discrepancy in BIP125 implementations, illuminated the +difficulty and importance of collaboration in transaction relay +policy. While a genuine effort had been made to engage the community +using typical means, including starting the bitcoin-dev mailing list +conversation a year in advance, it was clear that the existing +communication and decision-making methods had not produced the +intended result and needed refinement. + +Decentralized decision-making is a challenging process, but necessary +to support the diverse ecosystem of protocols and applications that +use Bitcoin’s transaction relay network. Next week will be our final +post in this series, in which we hope to encourage our readers to +participate in and improve upon this process. + +[mempool clustering]: https://github.com/bitcoin/bitcoin/issues/27677 +[policy08]: /en/newsletters/2023/07/05/#waiting-for-confirmation-8-policy-as-an-interface +[2022 rbf]: /en/newsletters/2022/12/21/#rbf diff --git a/_includes/specials/policy/en/10-get-involved.md b/_includes/specials/policy/en/10-get-involved.md new file mode 100644 index 0000000000..c364b4cc19 --- /dev/null +++ b/_includes/specials/policy/en/10-get-involved.md @@ -0,0 +1,60 @@ +We hope this series has given readers a better idea of what’s going on +while they are waiting for confirmation. We started with a discussion +about how some of the ideological values of Bitcoin +[translate][policy01] to its structure and design goals. The +distributed structure of the peer-to-peer network offers increased +censorship resistance and privacy over a typical centralized model. An +open transaction relay network helps everybody learn about +transactions in blocks prior to confirmation, which improves [block +relay efficiency][policy01], makes joining as a new miner more +accessible, and creates a [public auction for block space][policy02]. +As the ideal network consists of many independent, anonymous entities +running nodes, node software must be designed to [protect against +DoS][policy05] and generally minimize operational costs. + +Fees play an important role in the Bitcoin network as the "fair" way +to resolve competition for block space. Mempools with transaction +replacement and package-aware selection and eviction algorithms use +[incentive compatibility][policy02] to measure the utility of storing +a transaction, and enable [RBF][topic rbf] and [CPFP][topic +cpfp] as fee-bumping mechanisms for users. The combination of these +mempool policies, wallets that [construct transactions +economically][policy03], and good [feerate estimation][policy04] +create an efficient market for block space that benefits everybody. + +Individual nodes also enforce _transaction relay policy_ to [protect +themselves against resource exhaustion][policy05] and [express +personal preference][policy06]. At a [network-wide level][policy07], +standardness rules and other policies protect resources that are +critical to scaling, accessibility of running a node, and ability to +update consensus rules. As the vast majority of the network enforces +these policies, they are an important part of the [interface][policy08] +that Bitcoin applications and L2 protocols build upon. They also aren't +perfect. We described several [policy-related proposals][policy09] +that address broad limitations and specific use cases such as [pinning +attacks on L2 settlement transactions][policy08]. + +We also highlighted that the ongoing evolution of network +policies requires collaboration between developers working on +protocols, applications, and wallets. As the Bitcoin ecosystem grows +with respect to software, use cases, and users, a decentralized +decision-making process becomes more necessary but also more +challenging. Even as Bitcoin adoption grows, the system emerges from +the concerns and efforts of its stakeholders – there is no company in +charge of gathering customer feedback and hiring engineers to build +new protocol features or remove unused features. Stakeholders who wish to be part of the rough +consensus of the network have different avenues of participating: +informing themselves, surfacing questions and issues, involving +themselves in the design of the network, or even contributing to the +implementation of improvements. Next time your transaction is taking +too long to confirm, you know what to do! + +[policy01]: /en/newsletters/2023/05/17/#waiting-for-confirmation-1-why-do-we-have-a-mempool +[policy02]: /en/newsletters/2023/05/24/#waiting-for-confirmation-2-incentives +[policy03]: /en/newsletters/2023/05/31/#waiting-for-confirmation-3-bidding-for-block-space +[policy04]: /en/newsletters/2023/06/07/#waiting-for-confirmation-4-feerate-estimation +[policy05]: /en/newsletters/2023/06/14/#waiting-for-confirmation-5-policy-for-protection-of-node-resources +[policy06]: /en/newsletters/2023/06/21/#waiting-for-confirmation-6-policy-consistency +[policy07]: /en/newsletters/2023/06/28/#waiting-for-confirmation-7-network-resources +[policy08]: /en/newsletters/2023/07/05/#waiting-for-confirmation-8-policy-as-an-interface +[policy09]: /en/newsletters/2023/07/12/#waiting-for-confirmation-9-policy-proposals diff --git a/_includes/specials/policy/fr/01-pourquoi-le-mempool.md b/_includes/specials/policy/fr/01-pourquoi-le-mempool.md new file mode 100644 index 0000000000..027407edda --- /dev/null +++ b/_includes/specials/policy/fr/01-pourquoi-le-mempool.md @@ -0,0 +1,55 @@ + + +De nombreux nœuds du réseau Bitcoin stockent les transactions non confirmées dans un réservoir de mémoire, ou _mempool_. Ce cache +est une ressource importante pour chaque nœud et permet au réseau de relais de transactions de pair à pair de fonctionner. + +Les nœuds qui participent au relais de transaction téléchargent et valident les blocs progressivement plutôt que par pics. Toutes +les 10 minutes environ, lorsqu'un bloc est trouvé, les nœuds sans mempool connaissent un pic de bande passante, suivi d'une période +de calcul intensif pour valider chaque transaction. D'un autre côté, les nœuds disposant d'un mempool ont généralement déjà vu +toutes les transactions du bloc et les stockent dans leurs mempools. Avec [compact block relay][topic compact block relay], ces +nœuds téléchargent simplement un en-tête de bloc avec des "shortids", puis reconstruisent le bloc à l'aide des transactions de leurs +mempools. +La quantité de données utilisées pour relayer les blocs compacts est minime par rapport à la taille du bloc. La validation des +transactions est également beaucoup plus rapide : le nœud a déjà vérifié (et mis en cache) les signatures et les scripts, calculé +les exigences en matière de timelock, et chargé les UTXO pertinents à partir du disque si nécessaire. Le nœud peut également +transmettre rapidement le bloc à ses autres pairs, ce qui augmente considérablement la vitesse de propagation des blocs à l'échelle +du réseau et réduit ainsi le risque de blocs périmés. + +Les mempools peuvent également être utilisés pour construire un estimateur de frais indépendant. Le marché de l'espace de blocs est +une vente aux enchères, et la tenue d'un mempool permet aux utilisateurs d'avoir une meilleure idée de ce que les autres +proposent et des offres qui ont été retenues dans le passé. + +Cependant, il n'existe pas "un" mempool unique---chaque nœud peut recevoir des transactions différentes. Le fait de soumettre une +transaction à un nœud ne signifie pas nécessairement qu'elle a été transmise aux mineurs. Certains utilisateurs sont frustrés par +cette incertitude et se demandent pourquoi ils ne soumettent pas leurs transactions directement aux mineurs. + +Considérons un réseau Bitcoin dans lequel toutes les transactions sont envoyées directement des utilisateurs aux mineurs. Il serait +possible de censurer et de surveiller l'activité financière en demandant au petit nombre d'entités d'enregistrer les adresses IP +correspondant à chaque transaction et de refuser toute transaction correspondant à un modèle particulier. Ce type de Bitcoin peut +parfois être plus pratique, mais il serait dépourvu de quelques-unes des propriétés les plus précieuses de Bitcoin. + +La résistance à la censure et la confidentialité de Bitcoin proviennent de son réseau peer-to-peer. Pour relayer une transaction, +chaque nœud peut se connecter à un ensemble anonyme de pairs, dont chacun peut être un mineur ou une personne liée à un mineur. +Cette méthode permet d'obscurcir le nœud d'où provient une transaction ainsi que le nœud qui peut être chargé de la confirmer. Une +personne souhaitant censurer des entités particulières peut cibler des mineurs, des bourses populaires ou d'autres services de +soumission centralisés, mais il serait difficile de bloquer complètement quoi que ce soit. + +La disponibilité générale des transactions non confirmées permet également de minimiser le coût d'entrée pour devenir un producteur +de blocs---une personne qui n'est pas satisfaite des transactions sélectionnées (ou exclues) peut commencer à miner immédiatement. +Le fait de traiter chaque nœud comme un candidat égal pour la diffusion des transactions évite de donner à un mineur un accès +privilégié aux transactions et à leurs frais. + +En résumé, un mempool est un cache extrêmement utile qui permet aux nœuds de répartir les coûts de téléchargement et de validation +des blocs dans le temps, et qui donne aux utilisateurs l'accès à une meilleure estimation des frais. Au niveau du réseau, les +mempools soutiennent un réseau distribué de transactions et de relais de blocs. +Tous ces avantages sont plus prononcés lorsque tout le monde voit toutes les transactions avant que les mineurs ne les incluent dans +les blocs - tout comme n'importe quel cache, un mempool est le plus utile lorsqu'il est "chaud" et doit être limité en taille pour +tenir dans la mémoire. La semaine prochaine, nous étudierons l'utilisation de la compatibilité incitative comme mesure permettant de +conserver les transactions les plus utiles dans les mempools. diff --git a/_includes/specials/policy/fr/02-utilite-du-cache.md b/_includes/specials/policy/fr/02-utilite-du-cache.md new file mode 100644 index 0000000000..774dcb27c4 --- /dev/null +++ b/_includes/specials/policy/fr/02-utilite-du-cache.md @@ -0,0 +1,57 @@ +[L'article de la semaine dernière][policy01] traitait du mempool comme d'un cache de transactions non confirmées qui fournit une +méthode décentralisée permettant aux utilisateurs d'envoyer des transactions aux mineurs. Cependant, les mineurs ne sont pas obligés +de confirmer ces transactions ; un bloc contenant uniquement une transaction coinbase est valide selon les règles du consensus. Les +utilisateurs peuvent inciter les mineurs à inclure leurs transactions en augmentant la valeur totale d'entrée sans modifier la +valeur totale de sortie, ce qui permet aux mineurs de réclamer la différence en tant que frais de transaction. + +Bien que les frais de transaction soient courants dans les systèmes financiers traditionnels, les nouveaux utilisateurs de Bitcoin +sont souvent surpris de constater que les frais sur la chaîne sont payés non pas en proportion du montant de la transaction, mais en +fonction du poids de la transaction. C'est l'espace disponible sur les blocs, et non la liquidité, qui est le facteur limitant. Le +taux de change est généralement libellé en satoshis par octet virtuel. + +Les règles de consensus limitent l'espace utilisé par les transactions dans chaque bloc. Cette limite permet de maintenir des temps +de propagation des blocs faibles par rapport à l'intervalle entre les blocs, ce qui réduit le risque de blocs périmés. Elle permet +également de limiter la croissance de la chaîne de blocs et de l'ensemble d'UTXO, qui contribuent directement au coût de démarrage +et de maintenance d'un nœud complet. + +Ainsi, dans le cadre de leur rôle de cache de transactions non confirmées, les mempools facilitent également une vente aux enchères +publique pour l'espace de bloc inélastique : lorsqu'elle fonctionne correctement, la vente aux enchères fonctionne selon les +principes du marché libre, c'est-à-dire que la priorité est basée uniquement sur les frais plutôt que sur les relations avec les +mineurs. + +La maximisation des frais lors de la sélection des transactions pour un bloc (dont le poids total et les opérations de signature +sont limités) est un problème [NP-hard][]. Ce problème est encore compliqué par les relations entre les transactions : l'extraction +d'une transaction à taux élevé peut nécessiter l'extraction de son parent à taux faible. En d'autres termes, l'extraction d'une +transaction à faible taux de falsification peut ouvrir la possibilité d'extraire son enfant à taux de falsification élevé. + +Le mempool de Bitcoin Core calcule le taux de frais de chaque entrée et de ses ascendants (appelé _ancestor feerate_), met en cache ce +résultat et utilise un algorithme de construction de modèle de bloc avide. Il trie le mempool dans l'ordre du _score d'ancêtre_ (le +minimum du taux de frais de l'ascendant et du taux de frais individuel) et sélectionne les paquets d'ascendants dans cet ordre, en mettant à jour les informations sur les frais et le poids des ascendants des transactions restantes au fur et à mesure. Cet algorithme offre un équilibre +entre performance et rentabilité et ne produit pas nécessairement des résultats optimaux. Son efficacité peut être améliorée en +limitant la taille des transactions et des paquets ascendants---Bitcoin Core fixe ces limites à 400 000 et 404 000 unités de poids, +respectivement. + +De même, un _descendant score_ est calculé et utilisé lors de la sélection des paquets à expulser du mempool, car il serait +désavantageux d'expulser une transaction à faible taux de frais qui a un descendant à fort taux de frais. + +La validation du Mempool fait également appel à des frais et à des tarifs lorsqu'il s'agit de transactions qui dépensent les mêmes +intrants, c'est-à-dire des transactions à double dépense ou des transactions conflictuelles. Au lieu de toujours conserver la +première transaction qu'ils voient, les nœuds utilisent un ensemble de règles pour déterminer quelle transaction est la plus +incitative à conserver. Ce comportement est connu sous le nom de [Replace by Fee][topic rbf]. + +Il est intuitif que les mineurs maximisent les frais, mais pourquoi un opérateur de nœud non-mineur devrait-il mettre en œuvre ces +politiques ? Comme indiqué dans le billet de la semaine dernière, l'utilité du pool de mémoire d'un nœud non-mineur est directement +liée à sa similarité avec les pools de mémoire des mineurs. Ainsi, même si un opérateur de nœud n'a jamais l'intention de produire +un bloc en utilisant le contenu de son mempool, il a intérêt à conserver les transactions les plus compatibles avec les incitations. + +Bien qu'il n'y ait pas de règles consensuelles exigeant que les transactions paient des frais, les frais et le taux de frais jouent un +rôle important dans le réseau Bitcoin en tant que moyen "équitable" de résoudre la concurrence pour l'espace des blocs. Les mineurs +utilisent le taux de frais pour évaluer l'acceptation, l'expulsion et les conflits, tandis que les nœuds non mineurs suivent ces +comportements afin de maximiser l'utilité de leurs mempools. + +La rareté de l'espace des blocs exerce une pression à la baisse sur la taille des transactions et encourage les développeurs à être +plus efficaces dans la construction des transactions. Le billet de la semaine prochaine explorera des stratégies et des techniques +pratiques pour minimiser les frais dans les transactions sur la chaîne. + +[policy01]: /fr/newsletters/2023/05/17/#en-attente-de-confirmation-1--pourquoi-avons-nous-un-mempool- +[NP-hard]: https://en.wikipedia.org/wiki/NP-hardness diff --git a/_includes/specials/policy/fr/03-encheres-pour-l-achat-d-un-bloc-d-espace.md b/_includes/specials/policy/fr/03-encheres-pour-l-achat-d-un-bloc-d-espace.md new file mode 100644 index 0000000000..5f2e9dbde7 --- /dev/null +++ b/_includes/specials/policy/fr/03-encheres-pour-l-achat-d-un-bloc-d-espace.md @@ -0,0 +1,80 @@ + + +La semaine dernière, nous avons indiqué que les transactions payaient des frais pour l'espace de blocs utilisé plutôt que pour le +montant transféré, et nous avons établi que les mineurs optimisent leur sélection de transactions pour maximiser les frais perçus. +Il s'ensuit que seules sont confirmées les transactions qui se trouvent en tête du pool de mémoire lorsqu'un bloc est trouvé. +Dans ce billet, nous discuterons de stratégies pratiques pour tirer le meilleur parti de nos frais. Supposons que nous disposons +d'une source décente d'estimations de taux de change---nous parlerons plus en détail de l'estimation des taux de change dans +l'article de la semaine prochaine. + +Lors de l'élaboration des transactions, certaines parties de la transaction sont plus flexibles que d'autres. Chaque transaction +nécessite les champs d'en-tête, les sorties du destinataire sont déterminées par les paiements effectués, et la plupart des +transactions nécessitent une sortie de changement. L'expéditeur et le destinataire doivent privilégier les types de sorties +efficaces en termes d'espace de blocs afin de réduire le coût futur de la dépense de leurs sorties de transaction, mais c'est au +cours de la [sélection des entrées][topic coin selection] qu'il est le plus possible de modifier la composition et le poids finaux +de la transaction. Comme les transactions se concurrencent par taux [frais/poids], une transaction plus légère nécessite des frais +moins élevés pour atteindre le même taux. + +Certains portefeuilles, comme le portefeuille Bitcoin Core, essaient de combiner les entrées de manière à éviter d'avoir besoin de +changer les sorties. Éviter le changement permet d'économiser le poids d'une sortie maintenant, mais aussi le coût futur de la +dépense de la sortie de changement plus tard. Malheureusement, de telles combinaisons d'entrées ne seront que rarement disponibles, +à moins que le portefeuille ne dispose d'un grand pool d'UTXO avec une grande variété de montants. + +Les types de sortie modernes sont plus efficaces en termes d'espace de blocs que les types de sortie plus anciens. Par exemple, +dépenser une entrée P2TR coûte moins de 2/5e du poids d'une entrée P2PKH (essayez-le avec notre [calculateur de taille de transaction][]). Pour les portefeuilles à plusieurs signatures, le schéma [MuSig2][topic musig] et le protocole FROST récemment finalisés +permettent de réaliser d'énormes économies en autorisant l'encodage d'une fonctionnalité à plusieurs signatures dans ce qui +ressemble à une entrée à une seule signature. En particulier à une époque où la demande d'espace de blocs explose, un portefeuille +utilisant des types de sortie modernes se traduit à lui seul par d'importantes économies. + +{:.center} +![Overview of input and output weights](/img/posts/specials/input-output-weights.png) + +Les portefeuilles intelligents modifient leur stratégie de sélection en fonction du taux : lorsque le taux est élevé, ils utilisent +peu d'entrées et des types d'entrées modernes afin d'obtenir le poids le plus faible possible pour l'ensemble d'entrées. Le fait de +toujours sélectionner l'ensemble d'entrées le plus léger minimiserait localement le coût de la transaction en cours, mais réduirait +également le pool d'UTXO d'un portefeuille en petits fragments. Cela pourrait préparer l'utilisateur à effectuer plus tard des +transactions avec des ensembles d'entrées énormes à des taux élevés. Par conséquent, il est judicieux que les portefeuilles +sélectionnent également des entrées plus nombreuses et plus lourdes à des taux faibles afin de consolider de manière opportuniste +les fonds dans des sorties modernes moins nombreuses en prévision de pics de demande ultérieurs dans l'espace de blocs. + +Les portefeuilles à fort volume regroupent souvent plusieurs paiements en une seule transaction afin de réduire le poids de la +transaction par paiement. Au lieu de supporter les frais généraux liés aux octets d'en-tête et à la sortie des modifications pour +chaque paiement, ils ne supportent les frais généraux qu'une seule fois, pour tous les paiements. Le simple fait de regrouper +quelques paiements permet de réduire rapidement le coût par paiement. + +![Savings from payment batching with +P2WPKH](/img/posts/payment-batching/p2wpkh-batching-cases-combined.png) + +Néanmoins, même si de nombreux portefeuilles estiment que les taux se trompent sur les paiements excessifs, en cas de bloc lent ou +d'augmentation des soumissions de transactions, les transactions restent parfois non confirmées plus longtemps que prévu. Dans ce +cas, l'expéditeur ou le destinataire peuvent souhaiter redéfinir les priorités de la transaction. + +Les utilisateurs disposent généralement de deux outils pour accroître la priorité de leur transaction : l'enfant paie pour le parent +([CPFP][topic cpfp]) et le remplacement par des frais ([RBF][topic rbf]). Dans CPFP, un utilisateur dépense le résultat de sa +transaction pour créer une transaction enfant à haut degré de priorité. Comme décrit dans l'article de la semaine dernière, les +mineurs sont incités à choisir le parent dans le bloc afin d'inclure l'enfant riche en frais. Le CPFP est accessible à tout +utilisateur rémunéré par la transaction, de sorte que le destinataire ou l'expéditeur (s'il a créé une sortie de changement) peut +l'utiliser. + +Dans le cas du RBF, l'expéditeur est l'auteur d'un remplacement de la transaction d'origine à un taux plus élevé. La transaction de +remplacement doit réutiliser au moins une entrée de la transaction originale pour garantir un conflit avec l'original et pour qu'une +seule des deux transactions puisse être incluse dans la blockchain. En général, ce remplacement inclut les paiements de la +transaction originale, mais l'expéditeur peut également rediriger les fonds dans la transaction de remplacement ou combiner les +paiements de plusieurs transactions en une seule lors du remplacement. Comme décrit dans l'article de la semaine dernière, les nœuds +évincent la transaction initiale en faveur de la transaction de remplacement, plus compatible avec les incitations. + +Bien que la demande et la production d'espace de blocs soient hors de notre contrôle, il existe de nombreuses techniques que les +portefeuilles peuvent utiliser pour faire des offres d'espace de blocs de manière efficace. Les portefeuilles peuvent économiser des +frais en créant des transactions plus légères en éliminant la sortie de changement, en dépensant les sorties segwit natives et en +défragmentant leur pool UTXO dans les environnements à faible taux de feerate. Les portefeuilles qui prennent en charge CPFP et RBF +peuvent également commencer avec un taux de rafraîchissement conservateur, puis mettre à jour la priorité de la transaction à l'aide +de CPFP ou de RBF si nécessaire. + +[calculateur de taille de transaction]: /en/tools/calc-size \ No newline at end of file diff --git a/_includes/specials/policy/fr/04-estimation-taux-de-frais.md b/_includes/specials/policy/fr/04-estimation-taux-de-frais.md new file mode 100644 index 0000000000..3b419bd58a --- /dev/null +++ b/_includes/specials/policy/fr/04-estimation-taux-de-frais.md @@ -0,0 +1,73 @@ +La semaine dernière, nous avons exploré les techniques permettant de minimiser les frais payés sur une transaction donnée. +Mais quel doit être ce taux ? Idéalement, le plus bas possible pour économiser de l'argent, mais suffisamment élevé pour +garantir une place dans un bloc correspondant aux préférences temporelles de l'utilisateur. + +L'objectif de l'estimation des frais (taux) est de traduire un délai de confirmation cible en un taux minimal que la +transaction devrait payer. + +L'estimation des frais est compliquée par l'irrégularité de la production d'espace de bloc. Supposons qu'un utilisateur doive +payer un commerçant dans un délai d'une heure pour recevoir ses marchandises. L'utilisateur peut s'attendre à ce qu'un bloc soit +extrait toutes les 10 minutes, et donc viser un emplacement dans les 6 blocs suivants. Cependant, il est tout à fait possible +qu'il faille 45 minutes pour trouver un bloc. Les évaluateurs de frais doivent faire le lien entre l'urgence ou le délai souhaité +par l'utilisateur (quelque chose comme "Je veux que cela soit confirmé avant la fin de la journée") et l'offre d'espace +de blocs (un certain nombre de blocs). De nombreux estimateurs de frais relèvent ce défi en exprimant les objectifs de confirmation +en nombre de blocs, en plus du temps. + +En l'absence d'informations sur les transactions avant leur confirmation, il est possible de construire un estimateur de frais naïf +qui utilise des données historiques sur les taux des transactions qui ont tendance à intégrer les blocs. Comme cet estimateur ne +tient pas compte des transactions en attente de confirmation dans les pools de mémoire, il deviendrait très imprécis en cas de +fluctuations inattendues de la demande d'espace de bloc et d'intervalles de bloc occasionnellement longs. Son autre faiblesse réside +dans le fait qu'il s'appuie sur des informations contrôlées entièrement par les mineurs, qui seraient en mesure de faire grimper les +taux de frais en incluant de fausses transactions à taux de frais élevé dans leurs blocs. + +Heureusement, le marché de l'espace de blocs n'est pas une vente aux enchères à l'aveugle. Nous avons mentionné dans notre +[premier article][policy01] que le fait de conserver un mempool et de participer au réseau de relais de transactions de pair à pair +permet à un nœud de voir les offres des utilisateurs. L'estimateur de frais de Bitcoin Core utilise également des données +historiques pour calculer la probabilité qu'une transaction à un taux `t` soit confirmée. L'estimateur de frais de Bitcoin Core +utilise également des données historiques pour calculer la probabilité qu'une transaction à la fréquence `t` soit confirmée dans un +délai de `n` blocs, mais il suit spécifiquement la hauteur à laquelle le nœud voit une transaction pour la première fois et le +moment où elle est confirmée. Cette méthode permet de contourner les activités qui se déroulent en dehors du marché public en les +ignorant. Si les mineurs incluent dans leurs propres blocs des transactions dont le taux de confirmation est artificiellement élevé, +cet estimateur de frais n'est pas faussé car il n'utilise que les données des transactions qui ont été relayées publiquement avant +la confirmation. + +Nous avons également des informations sur la manière dont les transactions sont sélectionnées pour les blocs. Dans un +[précédent article][policy02], nous avons mentionné que les nœuds simulent les politiques des mineurs afin de conserver les +transactions compatibles avec les incitations dans leurs mempools. En développant cette idée, au lieu de regarder uniquement les +données passées, nous pourrions construire un estimateur de frais qui simule ce qu'un mineur ferait. Pour déterminer le taux de +frais qu'une transaction devrait confirmer dans les `n` blocs suivants, l'estimateur de frais pourrait utiliser l'algorithme +d'assemblage de blocs pour projeter les modèles des `n` blocs suivants à partir de son mempool et calculer le taux de frais qui +battrait la (les) dernière(s) transaction(s) parvenue(s) dans le bloc `n`. + +Il est clair que l'efficacité de l'approche de cet estimateur de frais dépend de la similitude entre le contenu de son mempool et +celui des mineurs, ce qui ne peut jamais être garanti. Elle ne tient pas compte non plus des transactions qu'un mineur pourrait +inclure pour des raisons extérieures, par exemple des transactions qui appartiennent au mineur ou qui ont payé des frais externes +pour être confirmées. La projection doit également tenir compte des diffusions de transactions supplémentaires entre maintenant et +le moment où les blocs projetés sont trouvés. Elle peut le faire en diminuant la taille des blocs projetés pour tenir compte des +autres transactions - mais de combien ? + +Cette question souligne une fois de plus l'utilité des données historiques. Un modèle intelligent pourrait être en mesure +d'intégrer des modèles d'activité et de tenir compte d'événements externes qui influencent les taux de frais, tels que les heures +d'ouverture habituelles, la consolidation UTXO programmée d'une entreprise et l'activité en réponse aux changements du prix +d'échange du bitcoin. Le problème de la prévision de la demande d'espace de blocs reste mûr pour l'exploration, et il est probable +qu'il y aura toujours de la place pour l'innovation. + +L'estimation des frais est un problème difficile aux multiples facettes. Une mauvaise estimation des frais peut entraîner un +gaspillage de fonds par un paiement excessif des frais, ajouter des frictions à l'utilisation de Bitcoin pour les paiements et +faire perdre de l'argent aux utilisateurs de L2 en manquant une fenêtre dans laquelle une UTXO bloquée dans le temps disposait +d'un autre chemin de dépense. Une bonne estimation des frais permet aux utilisateurs de communiquer clairement et précisément +l'urgence de la transaction aux mineurs, et [CPFP][topic cpfp] et [RBF][topic rbf] permettent aux utilisateurs de mettre à jour +leurs offres si les estimations initiales sont inférieures à la réalité. Les politiques de mempool compatibles avec les incitations, +associées à des outils d'estimation des frais bien conçus et aux [wallets] [policy03], permettent aux utilisateurs de participer à +une vente aux enchères publique efficace pour l'espace des blocs. + +Les estimateurs de frais ne renvoient généralement jamais moins que 1sat/vB, quelle que soit la durée de l'horizon temporel ou le +nombre de transactions en attente de confirmation. Beaucoup considèrent que 1sat/vB est le taux plancher de facto dans le réseau +Bitcoin, en raison du fait que la plupart des nœuds du réseau (y compris les mineurs) [n'acceptent jamais][topic default minimum +transaction relay feerates] tout ce qui est en dessous de ce taux, indépendamment du fait que leurs mempools soient vides. Le billet +de la semaine prochaine explorera cette politique des nœuds et une autre motivation pour l'utilisation du taux de frais dans le +relais de transaction : la protection contre l'épuisement des ressources. + +[policy01]: /fr/newsletters/2023/05/17/#en-attente-de-confirmation-1--pourquoi-avons-nous-un-mempool- +[policy02]: /fr/newsletters/2023/05/24/#en-attente-de-confirmation-2--mesures-dincitation +[policy03]: /fr/newsletters/2023/05/31/#attente-de-la-confirmation-3--enchères-pour-lachat-dun-bloc-despace diff --git a/_includes/specials/policy/fr/05-dos.md b/_includes/specials/policy/fr/05-dos.md new file mode 100644 index 0000000000..f31cf2eaca --- /dev/null +++ b/_includes/specials/policy/fr/05-dos.md @@ -0,0 +1,79 @@ +Nous avons [commencé][policy01] notre série en affirmant qu'une grande partie de la résistance de Bitcoin à la vie privée +et à la censure découle de la nature décentralisée du réseau. La pratique selon laquelle les utilisateurs gèrent leurs propres +nœuds réduit les points centraux de défaillance, de surveillance et de censure. Il s'ensuit que l'un des principaux objectifs +de conception du logiciel de nœud Bitcoin est l'accessibilité élevée de l'exploitation d'un nœud. Exiger de chaque utilisateur +de Bitcoin qu'il achète du matériel coûteux, qu'il utilise un système d'exploitation spécifique ou qu'il dépense des centaines +de dollars par mois en frais d'exploitation réduirait très probablement le nombre de nœuds sur le réseau. + +Par ailleurs, un nœud du réseau Bitcoin est un ordinateur connecté à des entités inconnues qui peuvent lancer une attaque par +déni de service (DoS) en créant des messages qui font que le nœud manque de mémoire et tombe en panne, ou qu'il dépense ses +ressources informatiques et sa bande passante pour des données sans intérêt au lieu d'accepter de nouveaux blocs. Comme ces +entités sont anonymes de par leur conception, les nœuds ne peuvent pas déterminer à l'avance si un pair sera honnête ou +malveillant avant de se connecter, et ne peuvent pas l'interdire efficacement même après qu'une attaque a été observée. La mise +en œuvre de politiques de protection contre les attaques par déni de service et de limitation du coût de fonctionnement d'un +nœud complet n'est donc pas seulement un idéal, c'est un impératif. + +Des protections générales contre les attaques par déni de service sont intégrées dans les implémentations des nœuds afin d'éviter +l'épuisement des ressources. Par exemple, si un nœud de Bitcoin Core reçoit de nombreux messages d'un seul pair, il ne traite que +le premier et ajoute le reste à une file d'attente pour qu'il soit traité après les messages des autres pairs. En règle générale, +un nœud télécharge d'abord l'en-tête d'un bloc et vérifie sa preuve de travail (PoW) avant de télécharger et de valider le reste +du bloc. Ainsi, tout attaquant souhaitant épuiser les ressources de ce nœud par le biais d'un relais de bloc doit d'abord dépenser +une quantité disproportionnée de ses propres ressources pour calculer une preuve de travail valide. L'asymétrie entre le coût énorme +du calcul du PoW et le coût trivial de la vérification fournit un moyen naturel d'intégrer la résistance aux attaques par déni de +service dans le relais de bloc. +Cette propriété ne s'étend pas au relais de transactions _non confirmées_. + +Les protections générales contre les attaques par déni de service n'offrent pas une résistance suffisante pour permettre au +moteur de consensus d'un nœud d'être exposé à des données provenant du réseau pair-à-pair. Un attaquant tentant de [fabriquer +une transaction à forte intensité de calcul][max cpu tx], validée par consensus, peut envoyer une transaction comme la +["mégatransaction"][megatx mempool space] de 1 Mo dans le bloc #364292, dont la validation a pris un temps anormalement long en +raison de [la vérification de la signature et de l'ajustement quadratique][rusty megatx]. Un attaquant peut également rendre +toutes les signatures valides, sauf la dernière, ce qui amène le nœud à passer plusieurs minutes sur sa transaction, pour +finalement découvrir qu'elle est inutile. Pendant ce temps, le nœud retarderait le traitement d'un nouveau bloc. On peut +imaginer que ce type d'attaque vise des mineurs concurrents afin de prendre de l'avance sur le bloc suivant. + +Afin d'éviter de travailler sur des transactions très coûteuses en termes de calcul, les nœuds de Bitcoin Core imposent une +taille standard maximale et un nombre maximal d'opérations de signature (ou "sigops") pour chaque transaction, ce qui est plus +restrictif que la limite de consensus par bloc. Les nœuds de Bitcoin Core imposent également des limites sur la taille des +paquets d'ancêtres et de descendants, ce qui rend les algorithmes de production et d'éviction de modèles de blocs plus efficaces +et [limite la complexité de calcul][se descendant limits] de l'insertion et de la suppression du mempool, qui nécessitent la mise +à jour des ensembles d'ancêtres et de descendants d'une transaction. +Bien que cela signifie que certaines transactions légitimes peuvent ne pas être acceptées ou relayées, ces transactions devraient +être rares. + +Ces règles sont des exemples de _politique de relais de transaction_, un ensemble de règles de validation en plus du consensus +que les nœuds appliquent aux transactions non confirmées. + +Par défaut, les nœuds de Bitcoin Core n'acceptent pas les transactions inférieures au taux de relais minimum de 1sat/vB +("minrelaytxfee"), ne vérifient pas les signatures avant de contrôler cette exigence et ne transmettent pas les transactions à +leurs mempools à moins qu'elles ne soient acceptées. +D'une certaine manière, cette règle de taux de frais fixe un "prix" minimum pour la validation et le relais du réseau. Un nœud +non-mineur ne reçoit jamais de frais - ils sont uniquement payés au mineur qui confirme la transaction. +Cependant, les frais représentent un coût pour l'attaquant. Quelqu'un qui "gaspille" les ressources du réseau en envoyant un +nombre extrêmement élevé de transactions finit par manquer d'argent pour payer les frais. + +La politique [Replace by Fee][topic rbf] [mise en œuvre par Bitcoin Core] [bitcoin core rbf docs] exige que la transaction de +remplacement paie des frais plus élevés que chaque transaction avec laquelle elle entre directement en conflit, mais aussi +qu'elle paie des frais totaux plus élevés que toutes les transactions qu'elle remplace. Les frais supplémentaires divisés par +la taille virtuelle de la transaction de remplacement doivent être d'au moins 1sat/vB. +En d'autres termes, quels que soient les taux des transactions d'origine et de remplacement, la nouvelle transaction doit payer +de "nouveaux" frais pour couvrir le coût de sa propre bande passante à 1sat/vB. +Cette politique tarifaire n'est pas principalement axée sur la compatibilité des incitations. Il s'agit plutôt d'un coût minimum +pour les remplacements répétés de transactions afin de limiter les attaques qui gaspillent la bande passante, par exemple en +ajoutant seulement 1 satoshi supplémentaire à chaque remplacement. + +Un nœud qui valide entièrement les blocs et les transactions nécessite des ressources, notamment de la mémoire, des ressources +informatiques et de la bande passante. Les exigences en matière de ressources doivent rester faibles afin de rendre l'exploitation +d'un nœud accessible et de défendre le nœud contre l'exploitation. Les protections générales contre les attaques par déni de +service n'étant pas suffisantes, les nœuds appliquent des politiques de relais de transaction en plus des règles de consensus +lorsqu'ils valident des transactions non confirmées. Toutefois, la politique n'étant pas un consensus, deux nœuds peuvent avoir +des politiques différentes mais être d'accord sur l'état actuel de la chaîne. Le billet de la semaine prochaine traitera de la +politique en tant que choix individuel. + +[policy01]: /fr/newsletters/2023/05/17/#en-attente-de-confirmation-1--pourquoi-avons-nous-un-mempool- +[max cpu tx]: https://bitcointalk.org/?topic=140078 +[megatx mempool space]: https://mempool.space/tx/bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08 +[rusty megatx]: https://rusty.ozlabs.org/?p=522 +[bitcoin core rbf docs]: https://github.com/bitcoin/bitcoin/blob/v25.0/doc/policy/mempool-replacements.md +[pr 6722]: https://github.com/bitcoin/bitcoin/pull/6722 +[se descendant limits]: https://bitcoin.stackexchange.com/questions/118160/whats-the-governing-motivation-for-the-descendent-size-limit diff --git a/_includes/specials/policy/fr/06-consistence.md b/_includes/specials/policy/fr/06-consistence.md new file mode 100644 index 0000000000..30f8cba913 --- /dev/null +++ b/_includes/specials/policy/fr/06-consistence.md @@ -0,0 +1,72 @@ +Le billet de la semaine dernière présentait la politique, un ensemble de règles de validation des transactions appliquées en plus +des règles de consensus. Ces règles ne s'appliquent pas aux transactions dans les blocs, de sorte qu'un nœud peut rester dans le +consensus même si sa politique diffère de celle de ses pairs. Tout comme un opérateur de nœud peut décider de ne pas participer +au relais de transaction, il est également libre de choisir n'importe quelle politique, voire aucune (exposant son nœud au risque +de déni de service). Cela signifie que nous ne pouvons pas supposer une homogénéité totale des politiques de mempool dans le réseau. +Cependant, pour que la transaction d'un utilisateur soit reçue par un mineur, elle doit passer par un chemin de nœuds qui +l'acceptent tous dans leur mempool---la divergence de politique entre les nœuds affecte directement la fonctionnalité du relais +de transaction. + +Pour donner un exemple extrême des différences de politique entre les nœuds, imaginons une situation dans laquelle chaque +opérateur de nœud choisirait une `nVersion` aléatoire et n'accepterait que les transactions avec cette `nVersion`. Comme +la plupart des relations d'égal à égal auraient des politiques incompatibles, les transactions ne se propageraient pas aux mineurs. + +De l'autre côté du spectre, des politiques identiques à travers le réseau aident à faire converger les contenus des mempools. +Un réseau avec des mempools correspondants relaie les transactions le plus facilement, et est également idéal pour +[l'estimation des frais][policy04] et [le relais de bloc compact][policy01] comme mentionné dans les posts précédents. + +Étant donné la complexité de la validation des mempools et les difficultés qui découlent des disparités entre les politiques, +Bitcoin Core a [historiquement été conservateur][aj mempool consistency] avec la configurabilité des politiques. Alors que les +utilisateurs peuvent facilement modifier la façon dont les sigops sont comptés (`bytespersigop`) et limiter la quantité de +données intégrées dans les sorties `OP_RETURN` (`datacarriersize` et `datacarrier`), ils ne peuvent pas renoncer au poids +standard maximum de 400 000 unités de poids ou appliquer un ensemble différent de règles RBF liées aux frais sans modifier +le code source. + +Certaines options de configuration de la politique de Bitcoin Core existent pour tenir compte des différences entre les +environnements d'exploitation des nœuds et les objectifs d'exploitation d'un nœud. Par exemple, les ressources matérielles +d'un mineur et la raison pour laquelle il conserve un mempool diffèrent de celles d'un utilisateur quotidien qui fait +fonctionner un nœud léger sur son ordinateur portable ou son Raspberry Pi. Un mineur peut choisir d'augmenter la capacité +de son mempool (`maxmempool`) ou son délai d'expiration (`mempoolexpiry`) pour stocker des transactions à faible taux d'échange +pendant les pics de trafic, puis les exploiter plus tard lorsque le trafic diminue. Les sites web fournissant des visualisations, +des archives et des statistiques sur le réseau peuvent utiliser plusieurs noeuds pour collecter autant de données que possible +et afficher le comportement par défaut du mempool. + +Sur un nœud individuel, le choix de la capacité du mempool affecte la disponibilité des outils de substitution de frais. +Lorsque les taux minimums du mempool augmentent en raison de soumissions de transactions dépassant la taille par défaut du +mempool, les transactions purgées du "bas" du mempool et les nouvelles qui sont en dessous de ce taux ne peuvent plus être +surtaxées en utilisant [CPFP][topic cpfp]. + +D'un autre côté, puisque les entrées utilisées par les transactions purgées ne sont plus dépensées par aucune transaction +dans le mempool, il peut être possible de faire du fee-bump via [RBF][topic rbf] alors que ce n'était pas le cas auparavant. +La nouvelle transaction ne remplace rien dans le mempool du noeud, donc elle n'a pas besoin de prendre en compte les règles +habituelles de RBF. Cependant, les nœuds qui n'ont pas expulsé la transaction originale (parce qu'ils ont une plus grande +capacité de mempool) traitent la nouvelle transaction comme un remplacement proposé et exigent qu'elle respecte les règles RBF. +Si la transaction purgée ne signalait pas la remplaçabilité BIP125, ou si les frais de la nouvelle transaction ne répondent +pas aux exigences RBF en dépit d'un taux élevé, le mineur peut refuser la nouvelle transaction. Les portefeuilles doivent +traiter les transactions purgées avec précaution : les résultats de la transaction ne peuvent pas être considérés comme +disponibles pour la dépense, mais les entrées sont également indisponibles pour la réutilisation. + +À première vue, il peut sembler qu'un nœud ayant une plus grande capacité de mempool rend le CPFP plus utile et le RBF moins utile. +Cependant, le relais des transactions est soumis au comportement émergent du réseau et il se peut qu'il n'y ait pas de chemin +de nœuds acceptant le CPFP depuis l'utilisateur jusqu'au mineur. Les nœuds ne transmettent généralement les transactions +qu'une fois qu'ils les ont acceptées dans leur mempool et ignorent les annonces de transactions qui existent déjà dans leur +mempool - les nœuds qui stockent davantage de transactions [agissent comme des trous noirs][se maxmempool] lorsque ces +transactions leur sont rediffusées. À moins que l'ensemble du réseau n'augmente la capacité de ses mempools - ce qui serait +un signe de changement de la valeur par défaut - les utilisateurs ne doivent pas s'attendre à ce que l'augmentation de la +capacité de leurs propres mempools leur apporte beaucoup d'avantages. Le taux de frais minimum fixé par les mempools par +défaut limite l'utilité de CPFP pendant les périodes de fort trafic. Un utilisateur ayant réussi à soumettre +une transaction CPFP à son propre mempool, dont la taille a été augmentée, pourrait ne pas remarquer que la transaction ne +s'est pas propagée à d'autres utilisateurs. + +Le réseau de relais de transactions est composé de nœuds individuels qui rejoignent et quittent dynamiquement le réseau, +chacun d'entre eux devant se protéger contre l'exploitation. En tant que tel, le relais de transaction ne peut être que le +fruit d'un effort et nous ne pouvons pas garantir que chaque nœud est informé de chaque transaction non confirmée. En même +temps, le réseau Bitcoin est plus performant si les nœuds convergent vers un ensemble de politiques de relais de transactions +qui rend les mempools aussi homogènes que possible. Le prochain article examinera les mesures qui ont été adoptées afin de +répondre aux intérêts du réseau dans son ensemble. + +[policy01]: /fr/newsletters/2023/05/17/#en-attente-de-confirmation-1--pourquoi-avons-nous-un-mempool- +[policy04]: /fr/newsletters/2023/06/07/#en-attente-de-confirmation-4--estimation-du-taux-de-frais +[aj mempool consistency]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021116.html +[se maxmempool]: https://bitcoin.stackexchange.com/questions/118137/how-does-it-contribute-to-the-bitcoin-network-when-i-run-a-node-with-a-bigger-th + diff --git a/_includes/specials/policy/fr/07-ressources-du-reseau.md b/_includes/specials/policy/fr/07-ressources-du-reseau.md new file mode 100644 index 0000000000..68133c8704 --- /dev/null +++ b/_includes/specials/policy/fr/07-ressources-du-reseau.md @@ -0,0 +1,81 @@ +Un article précédent traitait de la protection des ressources des nœuds, qui peut être unique +à chaque nœud et donc parfois configurable. Nous avons également expliqué pourquoi il est préférable +de converger vers une seule politique, mais qu'est-ce qui doit faire partie de cette politique ? +Ce billet aborde le concept de ressources à l'échelle du réseau, essentielles pour des aspects tels +que l'évolutivité, la mise à niveau et l'accessibilité du démarrage et de la maintenance d'un nœud complet. + +Comme nous l'avons vu dans les [articles précédents][policy01], de nombreux objectifs idéologiques +du réseau Bitcoin sont incarnés par sa structure distribuée. La nature pair-à-pair de Bitcoin permet +aux règles du réseau d'émerger d'un consensus approximatif des choix des opérateurs de nœuds individuels +et limite les tentatives d'acquisition d'une influence indue sur le réseau. Ces règles sont ensuite +appliquées par chaque nœud qui valide individuellement chaque transaction. Une population de nœuds +diversifiée et saine exige que le coût d'exploitation d'un nœud soit maintenu à un niveau bas. Il est +difficile de faire évoluer un projet avec une audience mondiale, mais le faire sans sacrifier la +décentralisation revient à se battre avec une main attachée dans le dos. Le projet Bitcoin tente +de trouver cet équilibre en protégeant farouchement les ressources partagées du réseau : le stock +d'UTXO, l'empreinte des données de la blockchain et l'effort de calcul nécessaire pour les traiter, +ainsi que les mises à jour permettant de faire évoluer le protocole Bitcoin. + +Il n'est pas nécessaire de revenir sur la guerre des tailles de blocs pour comprendre qu'une limite à +la croissance de la blockchain est nécessaire pour que l'exploitation de son propre nœud reste abordable. +Cependant, la croissance de la blockchain est également dissuadée au niveau politique par le `minRelayTxFee` +de 1 sat/vbyte, assurant un coût minimum pour exprimer une partie de la " [demande illimitée de stockage +perpétuel hautement répliqué][unbounded] ". + +À l'origine, l'état du réseau était déterminé en conservant toutes les transactions dont les résultats +n'avaient pas encore été dépensés. Cette partie beaucoup plus importante de la blockchain a été réduite de +manière significative avec l'[introduction du jeu d'UTXO][ultraprune] comme moyen de suivre les fonds. +Depuis lors, le jeu d'UTXO est une structure de données centrale. En particulier pendant les IBD, mais +aussi de manière générale, les consultations d'UTXO représentent une part importante de tous les accès +à la mémoire d'un nœud. Bitcoin Core utilise déjà une [structure de données optimisée manuellement pour +le cache UTXO][pooled resource], mais la taille du jeu d'UTXO détermine la quantité qu'il ne peut pas +contenir dans le cache d'un nœud. Un ensemble d'UTXO plus important se traduit par un plus grand nombre +d'échec du cache, ce qui ralentit la vitesse de validation des blocs, de l'IBD et de la transaction. +La limite des poussières (dust limit) est un exemple de politique qui restreint la création d'UTXO, en particulier les +UTXO qui pourraient ne jamais être dépensés parce que leur montant [n'est pas à la hauteur][topic uneconomical outputs] +du coût de leur dépense. Malgré cela, des ["tempêtes de poussière" avec des milliers de transactions se +sont produites pas plus tard qu'en 2020][lopp storms]. + +Lorsqu'il est devenu populaire d'utiliser des sorties multisig brutes pour publier des données sur la +blockchain, la définition des transactions standards a été modifiée pour permettre une sortie OP_RETURN +unique en tant qu'alternative. Les gens ont réalisé qu'il serait impossible d'empêcher les utilisateurs +de publier des données sur la blockchain, mais qu'au moins ces données n'auraient pas besoin de vivre dans +le jeu d'UTXO pour toujours lorsqu'elles sont publiées dans des sorties qui ne peuvent jamais être dépensées. +Bitcoin Core 0.13.0 a introduit une option de démarrage `-permitbaremultisig` que les utilisateurs peuvent +activer pour rejeter les transactions non confirmées avec des sorties multisig brutes. + +Bien que les règles de consensus permettent aux scripts de sortie d'être libres, seuls quelques modèles bien +compris sont relayés par les nœuds de Bitcoin Core. Il est ainsi plus facile de comprendre les nombreuses +préoccupations du réseau, notamment les coûts de validation et les mécanismes de mise à jour du protocole. +Par exemple, un script d'entrée qui contient des op-codes, une entrée P2SH avec plus de 15 signatures, ou une +entrée P2WSH dont la pile de témoins contient plus de 100 éléments chacun, rendrait une transaction non standard. +(Consultez cette [vue d'ensemble des politiques][instagibbs policy zoo] pour plus d'exemples de politiques et leurs motivations). + +Finalement, le protocole Bitcoin est un projet logiciel vivant qui devra continuer à évoluer pour répondre aux +défis futurs et aux besoins des utilisateurs. À cette fin, il existe un certain nombre de mécanismes de mise à +jour qui ont délibérément laissé le consensus valide mais inutilisé, tels que l'annexe, les versions des leaf +taproots, les versions des témoins, OP_SUCCESS et un certain nombre d'opcodes no-op. Cependant, tout comme les +attaques sont entravées par l'absence de points centraux de défaillance, les mises à jour logicielles à l'échelle +du réseau impliquent un effort coordonné entre des dizaines de milliers d'opérateurs de nœuds indépendants. +Les nœuds ne relaieront pas les transactions qui utilisent les hooks de mise à niveau réservés tant que leur +signification n'aura pas été définie. Cette mesure vise à dissuader les applications de créer indépendamment des +normes contradictoires, ce qui rendrait impossible l'adoption de la norme d'une application dans le consensus sans +invalider celle d'une autre application. En outre, lorsqu'un changement de consensus se produit, les nœuds qui ne +sont pas mis à niveau immédiatement---et qui ne connaissent donc pas les nouvelles règles de consensus---ne peuvent +pas être "trompés" en acceptant une transaction désormais invalide dans leur pool de mémoires. Ce découragement +proactif aide les nœuds à être compatibles avec l'avenir et permet au réseau de mettre à jour les règles de +consensus en toute sécurité sans nécessiter une mise à jour logicielle entièrement synchronisée. + +Nous pouvons voir que l'utilisation d'une politique pour protéger les ressources partagées du réseau aide à protéger +les caractéristiques du réseau, et maintient ouvertes les voies pour le développement de protocoles futurs. Pendant +ce temps, nous voyons comment la friction de la croissance du réseau contre une blockchain strictement limitée a +conduit à l'adoption de meilleures pratiques, d'une bonne conception technique et de l'innovation : le billet de +la semaine prochaine explorera la politique de mempool comme une interface pour les protocoles de deuxième couche +et les systèmes de contrats intelligents. + +[policy01]: /fr/newsletters/2023/05/17/#en-attente-de-confirmation-1--pourquoi-avons-nous-un-mempool- +[unbounded]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html +[lopp storms]: https://blog.lopp.net/history-bitcoin-transaction-dust-spam-storms/ +[ultraprune]: https://github.com/bitcoin/bitcoin/pull/1677 +[pooled resource]: /fr/newsletters/2023/05/03/#bitcoin-core-25325 +[instagibbs policy zoo]: https://gist.github.com/instagibbs/ee32be0126ec132213205b25b80fb3e8 diff --git a/_includes/specials/policy/fr/08-interface.md b/_includes/specials/policy/fr/08-interface.md new file mode 100644 index 0000000000..ff8f1368d5 --- /dev/null +++ b/_includes/specials/policy/fr/08-interface.md @@ -0,0 +1,89 @@ +Jusqu'à présent dans cette série, nous avons exploré les [motivations][policy01] et les défis associés à la transmission +décentralisée des transactions, ce qui conduit à un besoin [local][policy05] et [global][policy07] de règles de validation +des transactions plus restrictives que le consensus. Étant donné que les modifications de la politique de transmission des +transactions dans Bitcoin Core peuvent avoir un impact sur la transmission des transactions d'une application, elles nécessitent +une socialisation préalable avec la communauté Bitcoin plus large avant d'être prises en compte. De même, les applications +et les protocoles de deuxième couche qui utilisent la transmission des transactions doivent être conçus en tenant compte des +règles de politique afin d'éviter de créer des transactions qui seraient rejetées. + +Les protocoles de contrat dépendent encore plus étroitement des politiques liées à la priorisation, car la possibilité de les +exécuter on chain dépend de la capacité à faire confirmer rapidement les transactions. Dans des environnements adverses, +les contreparties malveillantes peuvent avoir intérêt à retarder la confirmation d'une transaction, il faut donc également +réfléchir à la manière dont les particularités de l'interface de la politique de transmission des transactions peuvent être +utilisées contre un utilisateur. + +Les transactions du Lightning Network respectent les règles de standardité mentionnées dans les publications précédentes. Par +exemple, le protocole pair-à-pair spécifie une `dust_limit_satoshis` dans son message `open_channel` pour spécifier un seuil +de poussière. Étant donné qu'une transaction contenant une sortie d'une valeur inférieure au seuil de poussière ne sera pas +transmise en raison des limites de poussière des nœuds, ces paiements sont considérés comme "non exécutoires sur la chaîne" et +sont supprimés des transactions d'engagement. + +Les protocoles de contrat utilisent souvent des chemins de dépense avec verrouillage temporel pour donner à chaque participant +la possibilité de contester l'état publié on chain. Si l'utilisateur concerné ne parvient pas à faire confirmer une +transaction dans ce laps de temps, il peut subir une perte de fonds. Cela rend les frais extrêmement importants en tant que +mécanisme principal pour augmenter la priorité de confirmation, mais aussi plus difficiles à estimer. L'[estimation des frais][policy04] est +compliquée par le fait que les transactions seront diffusées à un moment ultérieur inconnu, que les nœuds fonctionnent souvent +en tant que clients légers et que certaines options d'augmentation des frais ne sont pas disponibles. Par exemple, si un +participant à un canal LN se déconnecte, l'autre partie peut diffuser unilatéralement une transaction d'engagement pré-signée +pour régler la répartition de leurs fonds partagés on chain. Aucune des parties ne peut dépenser unilatéralement l'UTXO +partagé, donc lorsque l'une des parties est déconnectée, il n'est pas possible de signer une transaction de [remplacement][topic rbf] +pour augmenter les frais de la transaction d'engagement. À la place, les transactions d'engagement LN peuvent inclure des +[sorties d'ancrage][topic anchor outputs] pour que les participants au canal puissent attacher un [enfant d'augmentation des +frais][topic cpfp] au moment de la diffusion. + +Cependant, cette méthode d'augmentation des frais a également des limites. Comme mentionné dans un [message précédent][policy06], +l'ajout d'une transaction CPFP n'est pas efficace si les taux de frais minimum du mempool augmentent au-dessus du taux de frais +de la transaction d'engagement, il est donc nécessaire de les signer avec un taux de frais légèrement surestimé au cas où les +taux de frais minimum du mempool augmenteraient à l'avenir. De plus, le développement des sorties d'ancrage a pris en compte un +certain nombre de considérations liées au fait qu'une partie peut avoir intérêt à retarder la confirmation. Par exemple, une +partie (Alice) peut diffuser sa propre transaction d'engagement sur le réseau avant de se déconnecter. Si le taux de frais de +cette transaction d'engagement est trop faible pour une confirmation immédiate et si le cocontractant d'Alice (Bob) ne reçoit pas +sa transaction, il peut être confus lorsque ses diffusions de sa version de la transaction d'engagement ne sont pas transmises +avec succès. Chaque transaction d'engagement comporte deux sorties d'ancrage de sorte que chaque partie puisse utiliser CPFP sur +l'une des transactions d'engagement, par exemple, Bob peut essayer de diffuser aveuglément une augmentation des frais CPFP de la +version d'Alice de la transaction d'engagement même s'il n'est pas sûr qu'elle ait précédemment diffusé sa version. Chaque sortie +d'ancrage se voit attribuer une petite valeur supérieure au seuil de poussière et peut être réclamée par n'importe qui après un +certain temps pour éviter d'encombrer l'ensemble des UTXO. + +Cependant, garantir la capacité de chaque partie à utiliser CPFP sur une transaction est plus compliqué que de donner à chaque +partie une sortie d'ancrage. Comme mentionné dans un [message précédent][policy05], Bitcoin Core limite le nombre et la taille +totale des transactions descendantes qui peuvent être attachées à une transaction non confirmée en tant que protection contre +les attaques de déni de service. Étant donné que chaque cocontractant a la possibilité d'attacher des transactions descendantes +à la transaction partagée, l'un pourrait bloquer la transaction CPFP de l'autre en épuisant ces limites. La présence de ces +transactions descendantes "épingle" par conséquent la transaction d'engagement à son statut de basse priorité dans les mempools. + +Pour atténuer cette attaque potentielle, la proposition des sorties d'ancrage LN verrouille toutes les sorties sans ancrage avec +un verrouillage temporel relatif, les empêchant d'être dépensées tant que la transaction n'est pas confirmée, et la politique +de limite des transactions descendantes de Bitcoin Core a été [modifiée pour permettre une transaction descendante +supplémentaire][topic cpfp carve out] lorsque cette nouvelle transaction descendante était de petite taille et n'avait pas d'autres +ancêtres. Cette combinaison de modifications des deux protocoles garantit qu'au moins deux participants à une transaction partagée +peuvent ajuster les frais au moment de la diffusion, sans augmenter de manière significative la surface d'attaque de déni de +service de la transmission des transactions. + +La prévention du CPFP par domination de la limite des transactions descendantes est un exemple d'une [attaque +d'épinglage][topic transaction pinning]. Les attaques d'épinglage exploitent les limitations de la politique des mempools pour +empêcher les transactions compatibles avec les incitations d'entrer dans les mempools ou d'être confirmées. Dans ce cas, la +politique des mempools a fait un compromis entre la [résistance aux attaques de déni de service][policy05] et la [compatibilité des +incitations][policy02]. Un compromis doit être fait---un nœud doit prendre en compte les augmentations de frais mais ne peut pas +traiter un nombre infini de transactions descendantes. Le découpage du CPFP permet d'affiner ce compromis pour un cas d'usage +spécifique. + +Outre l'épuisement de la limite des transactions descendantes, il existe d'autres attaques d'épinglage qui [empêchent totalement +l'utilisation de RBF][full rbf pinning], rendent RBF [prohibitivement coûteux][rbf ml] ou utilisent RBF pour retarder la +confirmation d'une transaction ANYONECANPAY. L'épinglage n'est un problème que dans les scénarios où plusieurs parties collaborent +à la création d'une transaction ou lorsqu'il y a par ailleurs une possibilité pour une partie non fiable d'interagir avec la +transaction. Minimiser l'exposition d'une transaction à des parties non fiables est généralement un bon moyen d'éviter l'épinglage. + +Ces points de friction mettent en évidence non seulement l'importance de la politique en tant qu'interface pour les applications +et les protocoles dans l'écosystème Bitcoin, mais aussi les domaines dans lesquels elle doit s'améliorer. Le prochain article de la +semaine prochaine abordera les propositions de politique et les questions ouvertes. + +[full rbf pinning]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html +[rbf ml]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html +[n25038 notes]: https://bitcoincore.reviews/25038 +[policy01]: /fr/newsletters/2023/05/17/#en-attente-de-confirmation-1--pourquoi-avons-nous-un-mempool- +[policy02]: /fr/newsletters/2023/05/24/#en-attente-de-confirmation-2--mesures-dincitation +[policy04]: /fr/newsletters/2023/06/07/#en-attente-de-confirmation-4--estimation-du-taux-de-frais +[policy05]: /fr/newsletters/2023/06/14/#en-attente-de-confirmation-5--politique-de-protection-des-ressources-des-nœuds +[policy06]: /fr/newsletters/2023/06/21/#en-attente-de-confirmation-6--cohérence-des-politiques +[policy07]: /fr/newsletters/2023/06/28/#en-attente-de-confirmation-7--ressources-du-réseau diff --git a/_includes/specials/policy/fr/09-propositions.md b/_includes/specials/policy/fr/09-propositions.md new file mode 100644 index 0000000000..b124a732ee --- /dev/null +++ b/_includes/specials/policy/fr/09-propositions.md @@ -0,0 +1,80 @@ +[Le post de la semaine dernière][policy08] a décrit les [sorties d'ancrage][topic anchor outputs] et [l'exclusion +CPFP][topic cpfp carve out], garantissant à chaque partie du canal la possibilité d'augmenter les frais de leurs transactions +d'engagement partagées sans nécessiter de collaboration. Cette approche présente encore quelques inconvénients : les fonds du +canal sont bloqués pour créer des sorties d'ancrage, les frais des transactions d'engagement sont généralement surestimés pour +s'assurer qu'ils atteignent les frais minimaux du mempool, et l'exclusion CPFP ne permet qu'un seul descendant supplémentaire. +Les sorties d'ancrage ne peuvent pas garantir la même capacité d'augmentation des frais pour les transactions partagées entre +plus de deux parties, telles que les [coinjoins][topic coinjoin] ou les protocoles de contrat multi-parties. Ce post explore +les efforts actuels pour remédier à ces limitations et à d'autres. + +[Package relay][topic package relay] comprend un protocole P2P et des modifications de politique pour permettre le transport et +la validation de groupes de transactions. Cela permettrait à une transaction d'engagement d'augmenter les frais même si la +transaction d'engagement ne respecte pas le taux de frais minimal du mempool. De plus, _Package RBF_ permettrait au descendant +qui augmente les frais de payer pour remplacer les transactions en conflit avec son parent. Package relay est conçu pour éliminer +une limitation générale au niveau du protocole de base. Cependant, en raison de son utilité pour l'augmentation des frais des +transactions partagées, il a également donné lieu à plusieurs efforts pour éliminer [l'épinglage][topic transaction pinning] pour +des cas d'utilisation spécifiques. Par exemple, Package RBF permettrait aux transactions d'engagement de se remplacer mutuellement +lorsqu'elles sont diffusées avec leurs descendants qui augmentent les frais, éliminant ainsi le besoin de plusieurs sorties +d'ancrage sur chaque transaction d'engagement. + +Un inconvénient est que les règles RBF existantes exigent que la transaction de remplacement paie des frais absolus plus élevés +que les frais totaux payés par toutes les transactions à remplacer. Cette règle aide à prévenir les attaques de type DoS par des +remplacements répétés, mais permet à un utilisateur malveillant d'augmenter le coût de remplacement de sa transaction en attachant +un descendant avec des frais élevés mais un taux de frais faible. Cela empêche la transaction d'être extraite en empêchant +injustement son remplacement par un package à frais élevés, et est souvent appelé "épinglage de la règle 3". + +Les développeurs ont également proposé des moyens totalement différents d'ajouter des frais aux transactions pré-signées. +Par exemple, la signature des entrées de la transaction en utilisant `SIGHASH_ANYONECANPAY | SIGHASH_ALL` pourrait permettre au +diffuseur de la transaction de fournir des frais en ajoutant des entrées supplémentaires à la transaction sans modifier les sorties. +Cependant, comme RBF n'a aucune règle exigeant que la transaction de remplacement ait un "score minier" plus élevé (c'est-à-dire +qu'elle serait sélectionnée plus rapidement pour un bloc), un attaquant pourrait épingler ces types de transactions en créant des +remplacements encombrés par des ancêtres à faible taux de frais. Ce qui complique l'évaluation précise du score de minage des +transactions et des packages de transactions, c'est que les limites existantes des ascendants et des descendants sont insuffisantes +pour limiter la complexité computationnelle de ce calcul. Toutes les transactions connectées peuvent influencer l'ordre dans lequel +les transactions sont sélectionnées pour être incluses dans un bloc. Un composant entièrement connecté, appelé un _cluster_, peut +avoir n'importe quelle taille compte tenu des limites actuelles des ascendants et des descendants. + +Une solution à long terme pour remédier à certaines lacunes du mempool et aux attaques d'épinglage RBF consiste à [restructurer la +structure de données du mempool pour suivre les clusters][mempool clustering] au lieu de simplement les ensembles d'ancêtres et de +descendants. Ces clusters seraient limités en taille. Une limite de cluster restreindrait la manière dont les utilisateurs peuvent +dépenser des UTXO non confirmés, mais permettrait de linéariser rapidement l'ensemble du mempool en utilisant l'algorithme de minage +basé sur le score des ascendants, de construire des modèles de bloc extrêmement rapidement, et d'exiger que les transactions de +remplacement aient un score de minage plus élevé que la ou les transactions à remplacer. + +Même ainsi, il est possible qu'aucun ensemble unique de politiques ne puisse répondre à la large gamme de besoins et d'attentes en +matière de relais de transactions. Par exemple, bien que les destinataires d'une transaction de paiement groupé bénéficient de la +possibilité de dépenser leurs sorties non confirmées, une limite de descendant plus souple laisse place à l'épinglage du package RBF +d'une transaction partagée par des frais absolus. Une proposition pour [la politique de relais de transactions +v3][topic v3 transaction relay] a été développée pour permettre aux protocoles de contrat d'opter pour un ensemble plus restrictif +de limites de package. Les transactions V3 ne permettraient que des packages de taille deux (un parent et un enfant) et limiteraient +le poids de l'enfant. Ces limites atténueraient l'épinglage RBF par des frais absolus et offriraient certains avantages du mempool +en cluster sans nécessiter une restructuration du mempool. + +[Les Ancres Éphémères][topic ephemeral anchors] s'appuient sur les propriétés des transactions V3 et du relais de packages pour +améliorer davantage les sorties d'ancrage. Elles exemptent les sorties d'ancrage appartenant à une transaction V3 à frais nuls de la +[limite de poussière][topic uneconomical outputs], à condition que la sortie d'ancrage soit dépensée par un descendant qui augmente +les frais. Étant donné que la transaction sans frais doit être augmentée de frais par exactement un descendant (sinon un mineur ne +serait pas incité à l'inclure dans un bloc), cette sortie d'ancrage est "éphémère" et ne fera pas partie de l'ensemble UTXO. La +proposition d'ancres éphémères empêche implicitement les sorties autres que les sorties d'ancrage d'être dépensées lorsqu'elles ne +sont pas confirmées sans verrouillages temporels `1 OP_CSV`, puisque le seul descendant autorisé doit dépenser la sortie d'ancrage. +Cela rendrait également [la symétrie LN][topic eltoo] réalisable avec [CPFP][topic cpfp] en tant que mécanisme de provisionnement +des frais pour les transactions de fermeture de canal. Cela rend également ce mécanisme disponible pour les transactions partagées +entre plus de deux participants. Les développeurs ont utilisé [bitcoin-inquisition][bitcoin inquisition repo] pour déployer les +Ancres Éphémères et ont proposé des soft forks pour construire et tester ces changements multi-couches sur un [signet][topic signet]. + +Les problèmes d'épinglage mis en évidence dans ce post, entre autres, ont donné lieu à une [multitude de discussions et de +propositions pour améliorer la politique RBF][2022 rbf] l'année dernière, sur les listes de diffusion, les PR, les +réseaux sociaux et les réunions en personne. Les développeurs ont proposé et mis en œuvre des solutions allant de petites +modifications à une refonte complète. L'option `-mempoolfullrbf`, destinée à résoudre les problèmes d'épinglage et les divergences +dans les implémentations de BIP125, a mis en évidence la difficulté et l'importance de la collaboration dans la politique de relais +de transactions. Bien qu'un véritable effort ait été fait pour impliquer la communauté en utilisant des moyens habituels, notamment +en lançant la conversation sur la liste de diffusion bitcoin-dev un an à l'avance, il était clair que les méthodes de communication +et de prise de décision existantes n'avaient pas produit le résultat escompté et nécessitaient des améliorations. + +La prise de décision décentralisée est un processus complexe, mais nécessaire pour soutenir l'écosystème diversifié des protocoles +et des applications qui utilisent le réseau de relais de transactions de Bitcoin. La semaine prochaine, nous publierons notre +dernier post de cette série, dans lequel nous espérons encourager nos lecteurs à participer et à améliorer ce processus. + +[mempool clustering]: https://github.com/bitcoin/bitcoin/issues/27677 +[policy08]: /fr/newsletters/2023/07/05/#en-attente-de-confirmation-8--la-politique-comme-interface +[2022 rbf]: /fr/newsletters/2022/12/21/#rbf diff --git a/_includes/specials/policy/fr/10-impliquez-vous.md b/_includes/specials/policy/fr/10-impliquez-vous.md new file mode 100644 index 0000000000..571f910e6c --- /dev/null +++ b/_includes/specials/policy/fr/10-impliquez-vous.md @@ -0,0 +1,43 @@ +Nous espérons que cette série a donné aux lecteurs une meilleure idée de ce qui se passe pendant qu'ils attendent une confirmation. +Nous avons commencé par une discussion sur la façon dont certaines valeurs idéologiques de Bitcoin se traduisent dans sa structure +et ses objectifs de conception. La structure distribuée du réseau pair à pair offre une résistance accrue à la censure et à la +confidentialité par rapport à un modèle centralisé typique. Un réseau de relais de transactions ouvert permet à tout le monde +d'apprendre les transactions dans les blocs avant la confirmation, ce qui améliore l'efficacité de la transmission des blocs, +facilite l'adhésion en tant que nouveau mineur et crée une enchère publique pour l'espace des blocs. Comme le réseau idéal est +composé de nombreuses entités indépendantes et anonymes exécutant des nœuds, le logiciel des nœuds doit être conçu pour se protéger +contre les attaques par déni de service et minimiser les coûts opérationnels. + +Les frais jouent un rôle important dans le réseau Bitcoin en tant que moyen "équitable" de résoudre la concurrence pour l'espace +des blocs. Les pools de mémoire avec des algorithmes de remplacement de transactions et de sélection et d'éviction sensibles aux +paquets utilisent la compatibilité des incitations pour mesurer l'utilité de stocker une transaction et permettent aux utilisateurs +de bénéficier de mécanismes d'augmentation des frais tels que RBF et CPFP. La combinaison de ces politiques de pool de mémoire, de +portefeuilles qui construisent des transactions de manière économique et d'une bonne estimation des frais crée un marché efficace +pour l'espace des blocs qui profite à tous. + +Les nœuds individuels appliquent également une politique de relais de transactions pour se protéger contre l'épuisement des +ressources et exprimer leurs préférences personnelles. À l'échelle du réseau, les règles de normalité et d'autres politiques +protègent les ressources essentielles à l'évolutivité, à l'accessibilité de l'exécution d'un nœud et à la capacité de mettre à jour +les règles de consensus. Comme la grande majorité du réseau applique ces politiques, elles sont une partie importante de l'interface +sur laquelle les applications Bitcoin et les protocoles L2 se basent. Elles ne sont cependant pas parfaites. Nous avons décrit +plusieurs propositions liées aux politiques qui abordent des limitations générales et des cas d'utilisation spécifiques tels que +les attaques d'épinglage sur les transactions de règlement L2. + +Nous avons également souligné que l'évolution continue des politiques du réseau nécessite une collaboration entre les développeurs +travaillant sur les protocoles, les applications et les portefeuilles. À mesure que l'écosystème Bitcoin se développe en termes de +logiciels, de cas d'utilisation et d'utilisateurs, un processus de prise de décision décentralisé devient de plus en plus nécessaire +mais aussi plus difficile. Même si l'adoption de Bitcoin augmente, le système émerge des préoccupations et des efforts de ses +parties prenantes---il n'y a pas d'entreprise chargée de recueillir les commentaires des clients et d'embaucher des ingénieurs pour +développer de nouvelles fonctionnalités de protocole ou supprimer les fonctionnalités inutilisées. Les parties prenantes qui +souhaitent faire partie du consensus approximatif du réseau ont différentes façons de participer : s'informer, soulever des +questions et des problèmes, s'impliquer dans la conception du réseau, voire contribuer à la mise en œuvre d'améliorations. +La prochaine fois que votre transaction prendra trop de temps à se confirmer, vous saurez quoi faire ! + +[policy01]: /fr/newsletters/2023/05/17/#en-attente-de-confirmation-1--pourquoi-avons-nous-un-mempool- +[policy02]: /fr/newsletters/2023/05/24/#en-attente-de-confirmation-2--mesures-dincitation +[policy03]: /fr/newsletters/2023/05/31/#attente-de-la-confirmation-3--enchères-pour-lachat-dun-bloc-despace +[policy04]: /fr/newsletters/2023/06/07/#en-attente-de-confirmation-4--estimation-du-taux-de-frais +[policy05]: /fr/newsletters/2023/06/14/#en-attente-de-confirmation-5--politique-de-protection-des-ressources-des-nœuds +[policy06]: /fr/newsletters/2023/06/21/#en-attente-de-confirmation-6--cohérence-des-politiques +[policy07]: /fr/newsletters/2023/06/28/#en-attente-de-confirmation-7--ressources-du-réseau +[policy08]: /fr/newsletters/2023/07/05/#en-attente-de-confirmation-8--la-politique-comme-interface +[policy09]: /fr/newsletters/2023/07/12/#en-attente-de-confirmation-9--propositions-de-politique diff --git a/_includes/specials/policy/ja/01-why-mempool.md b/_includes/specials/policy/ja/01-why-mempool.md new file mode 100644 index 0000000000..48ce13e7ef --- /dev/null +++ b/_includes/specials/policy/ja/01-why-mempool.md @@ -0,0 +1,64 @@ + + +Bitcoinネットワークの多くのノードは、未承認のトランザクションをインメモリのプール、 +つまり _mempool_ に保存しています。このキャッシュは、各ノードにとって重要なリソースであり、 +ピアツーピアのトランザクションリレーネットワークを可能にしています。 + +トランザクションリレーに参加するノードは、ブロックを急激にではなく徐々にダウンロードし検証します。 +ブロックが見つかる約10分ごとに、mempoolを持たないノードは帯域幅のスパイクが発生し、 +その後、各トランザクションを検証するための計算負荷の高い期間が続きます。 +一方、mempoolを持つノードは、通常、ブロック内のすべてのトランザクションをすでに確認しており、 +それらをmempoolに保存しています。 +[コンパクトブロックリレー][topic compact block relay]を使用すると、 +これらのノードは、ブロックヘッダーとショートIDをダウンロードするだけで、 +あとは自分のmempool内のトランザクションを使用してブロックを再構築します。 +コンパクトブロックのリレーに使用されるデータ量は、ブロックのサイズに比べればごくわずかです。 +ノードはすでに署名とスクリプトを検証し（かつキャッシュし）、タイムロックの要件を計算し、 +必要に応じてディスクから関連するUTXOをロードしているため、トランザクションの検証もはるかに高速化されています。 +また、ノードはブロックを他のピアに迅速に転送できるため、ネットワーク全体の +ブロック伝播速度が劇的に向上し、ブロックが古くなるリスクも低減します。 + +また、mempoolは独立した手数料推定器を構築するためにも使用できます。 +ブロックスペースの市場は手数料ベースのオークションであり、 +mempoolを保持することで、ユーザーは他の人がどんな入札をしているか、 +過去にどのような入札が成功したかをより正確に把握することができます。 + +しかし、すべての人にとって共通のmempoolというものは存在しません。 +各ノードは異なるトランザクションを受信する可能性があります。 +あるノードにトランザクションを送信したとしても、それが必ずマイナーにも届くとは限りません。 +このような不確実性をもどかしく思うユーザーもいます。 +「なぜ、マイナーに直接トランザクションを送信しないのか？」と疑問に思う人もいます。 + +すべてのトランザクションがユーザーから直接マイナーに送信されるBitcoinネットワークを考えてみましょう。 +少数の事業者に対して、各トランザクションに対応するIPアドレスを記録し、 +特定のパターンに一致するトランザクションの受け入れを拒否するよう要求することで、 +金融活動を検閲し監視することができます。このようなBitcoinは、 +ときにはより便利かもしれませんが、Bitcoinの最も重要な特性のいくつかが失われてしまいます。 + +Bitcoinの検閲耐性とプライバシーは、ピアツーピアのネットワークに由来します。 +トランザクションをリレーするために、各ノードは匿名のピアのセットに接続します。 +これらのピアは、マイナーである可能性もあれば、マイナーに接続されている誰かかもしれません。 +この方法は、トランザクションがどのノードから発信され、 +どのノードがそのトランザクションの承認を担当しているのかを難読化するのに役立ちます。 +特定のエンティティを検閲したいと思う人は、マイナーや人気のある取引所、 +または他の中央集権型の送信サービスを標的にするかもしれませんが、なにかを完全にブロックするのは難しいでしょう。 + +未承認トランザクションの一般的な可用性は、ブロックプロデューサーになるための参入コストを最小限に抑えるのにも役立ちます。 +選択された（または除外された）トランザクションに不満を持つ人は、すぐにマイニングを開始することができます。 +各ノードをトランザクションのブロードキャスト候補として平等に扱うことで、 +トランザクションとその手数料への特権的なアクセスをどのマイナーにも与えないようにすることができます。 + +まとめると、mempoolは、ノードがブロックのダウンロードと検証のコストを時間的に分散させ、 +ユーザーがより良い手数料の見積もりにアクセスできるようにする非常に有用なキャッシュです。 +ネットワークレベルでは、mempoolは分散トランザクションとブロックのリレーネットワークをサポートします。 +これらの利点はすべて、マイナーがブロックに含める前にすべてのトランザクションを誰でも確認することができる時に最も顕著になります。 +他のキャッシュと同様に、mempoolは「ホット」なときに最も有用で、メモリに収めるためにサイズを制限する必要があります。 +来週のセクションでは、最も有用なトランザクションをmempoolに保持するための指標として、 +インセンティブの互換性の使用について検討します。 diff --git a/_includes/specials/policy/ja/02-cache-utility.md b/_includes/specials/policy/ja/02-cache-utility.md new file mode 100644 index 0000000000..aacbdfd694 --- /dev/null +++ b/_includes/specials/policy/ja/02-cache-utility.md @@ -0,0 +1,67 @@ +[先週の記事][policy01]では、mempoolについて、未承認トランザクションのキャッシュとして、 +ユーザーがトランザクションをマイナーに送信するための分散化された方法を提供するものであると説明しました。 +しかし、マイナーはそのトランザクションを承認する義務はなく、 +コインベーストランザクションだけを含むブロックはコンセンサスルールにおいて有効です。 +ユーザーは、トランザクションの総アウトプット額を変更せずに、総インプット額を増やすことで、 +マイナーに自分のトランザクションを承認するインセンティブを与え、 +マイナーはその差額をトランザクション _手数料_ として請求することができます。 + +トランザクション手数料は、従来の金融システムでは一般的ですが、 +新規のBitcoinユーザーは、オンチェーン手数料が取引額に比例するのではなく、 +トランザクションのweightによって支払われることに驚くことがよくあります。 +流動性ではなくブロックスペースが制限要因になります。 +_手数料率_ は通常、仮想バイト（virtual byte）あたりのsatoshiで表されます。 + +コンセンサスルールにより、各ブロックでトランザクションが使用するスペースが制限されています。 +この制限により、ブロックの伝播時間がブロック間隔に対して低く保たれ、 +ブロックが古くなってしまう（ステイルブロック）リスクが軽減されます。 +また、ブロックチェーンとUTXOセットの増加を抑制することができ、 +これらはフルノードの立ち上げと維持にかかるコストに直接貢献します。 + +このように、未承認トランザクションのキャッシュとしての役割の他に、 +mempoolはブロックスペースの公開オークションを促進します。 +正常に機能している場合、オークションは自由市場の原則に従います。 +つまり、優先順位はマイナーとの関係でははなく、純粋に手数料に基づきます。 + +ブロックのトランザクションを選択する際に手数料を最大化することは（総weightと署名操作の数の制限あり）、 +[NP困難な問題][NP-hard problem]です。 +この問題は、トランザクションの関係性によってさらに複雑になります。 +高手数料率のトランザクションをマイニングするには、その低手数料率の親をマイニングする必要があるかもしれません。 +別の言い方をすると、低手数料率のトランザクションをマイニングすることで、 +高手数料率のその子をマイニングする機会が生まれるかもしれません。 + +Bitcoin Coreのmempoolは、各エントリとその祖先の手数料率を計算し（_祖先手数料率_ と呼ばれる）、 +その結果をキャッシュし、貪欲ブロックテンプレート構築アルゴリズムを使用します。 +mempoolを _祖先スコア_ （祖先手数料率と個別手数料率の最小値）順にソートし、 +その順番で祖先パッケージを選択し、残りのトランザクションの祖先手数料とweight情報を随時更新していきます。 +このアルゴリズムは、性能と収益性のバランスを取るものであり、必ずしも最適な結果が得られるとは限りません。 +その有効性は、トランザクションと祖先パッケージのサイズを制限することで向上させることができます。 +Bitcoin Coreでは、その制限がそれぞれ400,000 weightと404,000 weightに設定されています。 + +同様に、高手数料率の子を持つ低手数料率のトランザクションを退去させるのは不利になるため、 +mempoolから退去させるパッケージを選択する際に使用される _子孫スコア_ が計算されます。 + +mempoolの検証では、同じインプットを使用するトランザクション（つまり二重支払いや、競合するトランザクション）を処理する際も、 +手数料と手数料率が使用されます。ノードは最初に確認したトランザクションを常に保持するのではなく、 +一連のルールを使用して、どのトランザクションを保持するインセンティブがより高いかを決定します。 +この動作は[Replace by Fee][topic rbf]として知られています。 + +マイナーが手数料を最大化するのは直感的に理解できますが、 +なぜマイニングを行わないノードのオペレーターがこのようなポリシーを実行しなければならないのでしょうか？ +先週の記事で説明したように、マイニングを行わないノードのmempoolの効用は、 +マイナーのmempoolとの類似性に直接関係しています。 +そのため、ノードオペレーターがmempoolの内容を使ってブロックを生成するつもりがなくても、 +最もインセンティブに適合したトランザクションを維持することに関心があります。 + +トランザクションに手数料の支払いを要求するコンセンサスルールはありませんが、 +手数料と手数料率は、ブロックスペースをめぐる競争を解決するための「公平な」方法として、 +Bitcoinネットワークで重要な役割を果たしています。 +マイナーは手数料率を使用して、受け入れ、退去および競合を評価し、 +マイニングを行わないノードは、自分のmempoolの効用を最大化するためにその動作を反映します。 + +ブロックスペースの希少性は、トランザクションのサイズに低下圧力をかけ、 +開発者がトランザクションをより効率的に構築するよう促します。 +来週の記事では、オンチェーントランザクションの手数料を最小化するための実践的な戦略と技術を探ります。 + +[policy01]: /ja/newsletters/2023/05/17/#承認を待つ-1-なぜmempoolがあるのか +[np-hard problem]: https://ja.wikipedia.org/wiki/NP困難 diff --git a/_includes/specials/policy/ja/03-bidding-for-block-space.md b/_includes/specials/policy/ja/03-bidding-for-block-space.md new file mode 100644 index 0000000000..bf22074c5e --- /dev/null +++ b/_includes/specials/policy/ja/03-bidding-for-block-space.md @@ -0,0 +1,90 @@ + +先週、トランザクションは送金した額ではなく使用するブロックスペースに対して手数料を支払うと述べ、 +マイナーは収集できる手数料を最大化するためにトランザクションの選択を最適化することを確認しました。 +その結果、ブロックが見つかったときにmempoolの最上位に存在するトランザクションのみが承認されることになります。 +この記事では、手数料を最大限に活用するための実践的な戦略について説明します。 +手数料率の見積もりの適切な情報源があると仮定します。手数料率の見積もりについては、来週の記事で詳しく説明します。 + +トランザクションを構築する際、トランザクションのいくつかの部分は、他の部分よりも柔軟性があります。 +すべてのトランザクションにはヘッダーフィールドが必要で、受信者のアウトプットは行われる支払いによって決まり、 +ほとんどのトランザクションにはお釣りのアウトプットが必要です。 +送信者と受信者の両方が、将来のトランザクションアウトプットの支払いコストを削減するために、 +ブロックスペース効率の良いアウトプットタイプを優先すべきですが、 +トランザクションの最終構成とweightを変更する余地が最も大きいのは、 +[インプットの選択][topic coin selection]時です。 +トランザクションは、手数料率[fee/weight]で競争するため、 +軽いトランザクションは同じ手数料率に達するのにより低い手数料ですみます。 + +Bitcoin Coreウォレットなど一部のウォレトは、お釣りのアウトプットが必要ないように、 +インプットを組み合わせようとします。お釣りを避けることは、 +現在のアウトプットのweightを節約するだけでなく、後でお釣りのアウトプットを使用するという将来のコストも削減します。 +しかし、ウォレットがさまざまな額を持つ大きなUTXOプールを持っていない限り、 +このようなインプットの組み合わせはめったにありません。 + +最新のアウトプットタイプは、古いアウトプットタイプよりもブロックスペース効率が高くなっています。 +たとえば、P2TRインプットを使用すると、P2PKHインプットの2/5以下のweightしか発生しません。 +（[トランザクションサイズ計算ツール][transaction size calculator]で試してみてください） +マルチシグウォレットの場合、最近完成した[MuSig2][topic musig]方式やFROSTプロトコルによって、 +マルチシグ機能をシングルシグインプットのように見えるものにエンコードすることができ、 +大幅なコスト削減が可能になります。特にブロックスペースの需要が急増した時には、 +最新のアウトプットタイプを使用するウォレットは、それだけで大きなコスト削減につながります。 + +{:.center} +![Overview of input and output weights](/img/posts/specials/input-output-weights.png) + +スマートウォレットは、手数料率に応じて選択の戦略を変更します。 +手数料率が高い場合は、インプットのセットのweightをできるだけ小さくするために、 +少ないインプットと最新のインプットタイプを使用します。 +常に最も軽いインプットのセットを選択することで、現在のトランザクションのコストを局所的に最小化することができますが、 +同時にウォレットのUTXOプールを小さな断片にすることになります。 +このため、ユーザーはその後、高い手数料率で巨大なインプットのセットを持つトランザクションを作ることになります。 +したがって、ウォレットが低手数料率でより多くの重いインプットを選択し、 +その後のブロックスペース需要の急増を見越して、 +より少ない最新のアウトプットに資金を集約することは先見の明があると言えます。 + +大量の支払いをするウォレットは、1回あたりの支払いのトランザクションweightを減らすために、 +複数の支払いを1つのトランザクションにまとめることがよくあります。 +支払い毎にヘッダーバイトとお釣り用のアウトプットのオーバーヘッドを負担するのではなく、 +すべての支払いで共有されるオーバーヘッドコストだけを負担します。 +いくつかの支払いをまとめるだけでも、支払い毎のコストはすぐに削減されます。 + +![Savings from payment batching with +P2WPKH](/img/posts/payment-batching/p2wpkh-batching-cases-combined.png) + +しかし、多くのウォレットが過払いな手数料率を推定しているにもかかわらず、 +ブロックが遅くなったり、トランザクションの送信が急増すると、 +トランザクションが予定よりも長く未承認のままになることがあります。 +このような場合、送信者または受信者のどちらかがトランザクションの優先順位を変更したいと思うかもしれません。 + +一般に、ユーザーは自分のトランザクションの優先順位を上げるために、 +[CPFP][topic cpfp]（Child Pays For Parent）と[RBF][topic rbf]（Replace By Fee）の2つのツールを使うことができます。 +CPFPでは、ユーザーは自分のトランザクションのアウトプットを使用して、高手数料率の子トランザクションを作成します。 +先週の記事で説明したように、マイナーには手数料の高い子を含めるために親をブロックに含めるインセンティブがあります。 +CPFPはトランザクションによて支払いを受けるユーザーなら誰でも利用できるため、 +受信者または送信者（お釣り用のアウトプットを作成した場合）のどちらでも利用できます。 + +RBFでは、送信者は元のトランザクションより高い手数料率の置換トランザクションを作成します。 +置換トランザクションは、元のトランザクションとの競合を確実にするため、 +元のトランザクションから少なくとも１つのインプットを再利用しなければならず、 +2つのトランザクションの内、1つだけがブロックチェーンに含まれます。 +通常、この置換には元のトランザクションの支払いが含まれますが、 +送信者は置換トランザクションの資金をリダイレクトしたり、 +複数のトランザクションの支払いを置換トランザクションに統合したりすることもできます。 +先週の記事で説明したように、ノードは元のトランザクションを退去させ、 +よりインセンティブの高い置換トランザクションを採用します。 + +ブロックスペースの需要と生産は、どちらも私たちのコントロールが及ばないものですが、 +ウォレットがブロックスペースを効果的に競り落とすために使えるテクニックはたくさんあります。 +ウォレットは、お釣り用のアウトプットを排除したり、ネイティブsegwitアウトプット使用したり、 +低手数料率の環境でUTXOプールをデフラグしたりすることで、より軽いトランザクションを作成して手数料を節約できます。 +CPFPとRBFをサポートするウォレットは、控えめな手数料率から始めて、 +必要に応じてCPFPまたはRBFを使ってトランザクションの優先順位を更新することもできます。 + +[transaction size calculator]: /en/tools/calc-size \ No newline at end of file diff --git a/_includes/specials/policy/ja/04-feerate-estimation.md b/_includes/specials/policy/ja/04-feerate-estimation.md new file mode 100644 index 0000000000..433c8b5b82 --- /dev/null +++ b/_includes/specials/policy/ja/04-feerate-estimation.md @@ -0,0 +1,77 @@ +先週は、手数料率を考慮したトランザクションで支払われる手数料を最小限に抑えるための手法を紹介しました。 +しかし、その手数料率はどうあるべきなのでしょうか？理想的には、お金を節約するためにできるだけ低く、 +ユーザーの時間的な優先順位に応じたブロックのスポットを確保するのに十分な額であることです。 + +_手数料（率）推定_ の目標は、承認のための目標時間枠を、 +トランザクションが支払うべき最小手数料率に変換することです。 + +手数料の推定を複雑にする１つは、ブロックスペースの生産が不規則であることです。 +たとえば、ユーザーが１時間以内に販売者に支払いを行う必要があるとします。 +この場合、ユーザーは10分毎にブロックがマイニングされることを期待しているため、 +次の6ブロック以内のスポットを狙うでしょう。しかし、1つのブロックがマイニングされるのに +45分かかることも十分あり得ます。手数料の推定では、ユーザーが希望する緊急性や時間枠 +（「仕事終わりまでに承認してほしい」など）と、ブロックスペースの供給量（ブロック数）を調整する必要があります。 +多くの手数料推定は、時間に加えてブロック数で承認目標を表すことで、この課題に対処しています。 + +承認前ののトランザクションに関する情報がない場合は、 +どのような手数料率のトランザクションがブロックに入る傾向があるかについて過去のデータを使用する単純な手数料推定を構築できます。 +この推定ツールは、mempoolで承認を待っているトランザクションを認識しないため、 +ブロックスペース需要の予期せぬ変動や、時折発生する長めのブロック間隔に対して非常に不正確になります。 +もう１つの弱点は、マイナーが完全に管理する情報に依存していることです。 +マイナーは、ブロックに偽の高手数料率のトランザクションを含めることで、手数料率を上げることができます。 + +幸いなことに、ブロックスペースの市場はブラインドオークションではありません。 +[最初の記事][policy01]で、mempoolを保持し、ピアーツーピアのトランザクションリレーネットワークに参加することで、 +ノードがユーザーの入札を確認することができることを紹介しました。 +Bitcoin Coreの手数料推定ツールも、履歴データを使用して、 +`n`ブロック以内に手数料率`f`でトランザクションが承認される確率を計算しますが、 +特にノードが最初にトランザクションを発見した高さと承認された高さを追跡します。 +この方法は、公開手数料市場の外で発生する活動を無視することで機能します。 +マイナーが人為的に高い手数料率のトランザクションを自分のブロックに含めても、 +承認される前に公にリレーされたトランザクションのデータのみを使用するため、 +この手数料推定ツールが歪められることはありません。 + +また、トランザクションがブロックに選択される方法についての洞察もあります。 +[以前の記事で][policy02]、ノードはインセンティブに適合するトランザクションを自分のmempoolに保持するために、 +マイナーのポリシーをエミュレートすることを紹介しました。 +このアイディアを発展させると、過去のデータだけを見るのではなく、 +マイナーが行うであることをシミュレートする手数料推定ツールを構築することができます。 +次の`n`ブロック以内にトランザクションを承認するために必要な手数料率を見つけるために、 +手数料推定ツールは、ブロック構築アルゴリズムを使用して、 +mempoolから次の`n`個のブロックテンプレートを予測し、 +ブロック`n`に入る最後のトランザクションに勝つ手数料率を計算することができます。 + +明らかに、この手数料推定ツールのアプローチの有効性は、 +自分のmempoolのコンテンツとマイナーのコンテンツの類似性に依存し、これは決して保証されるものではありません。 +また、承認のために帯域外で手数料を支払うトランザクションなど、 +マイナーが外的な動機によって含める可能性のあるトランザクションも認識できません。 +また予測では、現時点から予測されたブロックが見つかるまでの間に +ブロードキャストされた追加のトランザクションも考慮する必要があります。 +他のトランザクションを考慮し、予測されるブロックのサイズを減らすことでこれを実現できますが、 +どれくらいでしょうか？ + +この質問は、履歴データの有用性を再び浮き彫りにします。 +高度なモデルであれば、活動のパターンを組み込んで、典型的な営業時間や、 +企業でスケージュールされたUTXOの統合、Bitcoinの取引価格の変化に応じた活動など、 +手数料率に影響を与える外部イベントを考慮することができるかもしれません。 +ブロックスペースの需要予測という問題は、まだ探求の余地があり、常にイノベーションの余地があると思われます。 + +手数料推定は多面的で難しい問題です。悪い手数料推定は、 +手数料を過剰に支払うことで資金を浪費し、支払いにBitcoinを使用することに摩擦をもたらし、 +別の使用条件を持つタイムロックされたUTXOがある期間を逃すことでL2ユーザーが損失を被る可能性があります。 +良い手数料推定は、ユーザーがマイナーにトランザクションの緊急度を明確かつ正確に伝えることを可能にし、 +[CPFP][topic cpfp]や[RBF][topic rbf]により、初期の見積もりが甘かった場合に入札の更新を可能にします。 +インセンティブに適合するmempoolポリシーと、よく設計された手数料推定ツールと[ウォレット][policy03]を組み合わせることで、 +ユーザーはブロックスペースの効率的な公開オークションに参加することができます。 + +手数料推定ツールは、時間軸がどれくらい長くても、承認待ちのトランザクションがどれくらい少なくても、 +通常1sat/vBを下回る値を返すことはありません。 +多くの人が1sat/vBをBitcoinネットワークの事実上の下限手数料率と考えています。 +これは、（マイナーを含む）ネットワーク上のほとんどのノードが、 +mempoolがどれだけ空いていても、この手数料率以下のものを[決して受け入れない][topic default minimum transaction relay feerates]という +事実があるためです。来週の記事では、このノードポリシーと、 +トランザクションリレーで手数料率を利用するもう1つの動機であるリソースの枯渇からの保護について説明する予定です。 + +[policy01]: /ja/newsletters/2023/05/17/#承認を待つ-1-なぜmempoolがあるのか +[policy02]: /ja/newsletters/2023/05/24/#承認を待つ-2-インセンティブ +[policy03]: /ja/newsletters/2023/05/31/#承認を待つ-3-ブロックスペースの入札 diff --git a/_includes/specials/policy/ja/05-dos.md b/_includes/specials/policy/ja/05-dos.md new file mode 100644 index 0000000000..92ea5a93f5 --- /dev/null +++ b/_includes/specials/policy/ja/05-dos.md @@ -0,0 +1,81 @@ +私たちは、Bitcoinのプライバシーと検閲耐性の多くはネットワークの分散化された性質に起因していると述べて、 +このシリーズを[始めました][policy01]。ユーザーが自分のノードを実行することで、 +障害、監視、検閲の中心点を削減することができます。そのため、 +Bitcoinノードソフトウェアの主な設計目標の１つは、ノードを実行するための高いアクセシビリティです。 +各Bitcoinユーザーに、高価なハードウェアを購入したり、特定のオペレーティングシステムを使用したり、 +また運用コストとして毎月数百ドルを費やすことを要求すると、ネットワーク上のノード数が減少する可能性が非常に高くなります。 + +さらに、Bitcoinネットワーク上のノードは、未知のエンティティへのインターネット接続を持つコンピュータであり、 +ノードがメモリ不足に陥りクラッシュするようなメッセージを作成したり、 +新しいブロックを受け入れるために意味のないデータに計算リソースや帯域幅を費やしたりすることで、 +サービス拒否（DoS）攻撃を行う可能性があります。 +これらのエンティティは設計上匿名であるため、ノードは接続前にそのピアが正直か悪意があるかを事前に判断することはできず、 +攻撃が観測された後でも効果的に禁止することができません。したがって、 +DoSから保護し、フルノードの実行コストを制限するポリシーを実装することは、単なる理想ではなく、必須なことです。 + +リソースの枯渇を防ぐために一般的なDoS保護がノードの実装に組み込まれています。 +たとえば、Bitcoin Coreノードが１つのピアから多くのメッセージを受信した場合、 +最初の１つだけを処理し、残りは他のピアのメッセージの後に処理されるようにワークキューに追加されます。 +また、ノードは通常、ブロックをダウンロードして検証する前に、まずブロックヘッダーを最初にダウンロードし、 +そのProof of Work（PoW）を検証します。したがって、ブロックリレーによってノードのリソースを枯渇させようとする攻撃者は、 +まず有効なPoWを計算するために不釣り合いなほど膨大なリソースを費やす必要があります。 +PoWの計算にかかる膨大なコストと検証にかかる些細なコストの非対称性により、 +ブロックリレーにDoS耐性を組み込む自然な方法が提供されます。 +この特性は、_未承認_ トランザクションのリレーには適用されません。 + +一般的なDoS保護では、ノードのコンセンサスエンジンがピアツーピアネットワークからの入力にさらされることを許容するだけの +十分な攻撃耐性を提供しません。[最大限の計算量を必要とする][max cpu tx]コンセンサスが有効なトランザクションを作ろうとする攻撃者は、 +#364292 ブロックにあった1MBの[“メガトランザクション”][megatx mempool space]のようなものを送信するかもしれません。 +このトランザクションは、[署名検証と二乗的なsighash計算][rusty megatx]によって検証に異常に長い時間を要しました。 +攻撃者は、最後の署名以外はすべて有効な署名を作成し、ノードにトランザクションの検証に数分をかけさせ、 +最後にそれがゴミであることがわかるようなものを作ることもできます。 +その間、ノードは新しいブロックの処理を遅らせます。この種の攻撃は、 +次のブロックで先手を打つために、競合するマイナーを標的にしていると想像できます。 + +非常に計算量の多いトランザクションの作業を回避するために、 +Bitcoin Coreノードは、各トランザクションに対して、最大標準サイズと +最大署名操作数（または「sigops」）を課し、ブロックのコンセンサス制限よりも厳しく制限しています。 +また、Bitcoin Coreノードは、祖先と子孫の両方のパッケージサイズに制限をかけることで、 +ブロックテンプレートの作成と退去のアルゴリズムをより効果的にし、 +トランザクションの祖先と子孫のセットを更新する必要があるmempoolの挿入と削除の +[計算量を制限しています][se descendant limits]。 +これは、一部の正当なトランザクションが受理またはリレーされないことを意味しますが、 +そのようなトランザクションは稀であることが予想されます。 + +これらは _トランザクションリレーポリシー_ の例で、 +ノードが未承認トランザクションに適用する、コンセンサスに加えて行う一連の検証ルールです。 + +デフォルトでは、Bitcoin Coreノードは、1sat/vBの最小リレー手数料率（「minrelaytxfee」）を +下回るトランザクションを受け入れず、この要件を受け入れる前にいかなる署名も検証せず、 +自分のmempoolに受け入れられない限りトランザクションをリレーしません。 +ある意味、この手数料率ルールは、ネットワークの検証とリレーの最小「価格」を設定します。 +マイニングを行わないノードは手数料を受け取ることはなく、 +手数料はトランザクションを承認したマイナーにのみ支払われれます。 +手数料が確認されるまでにネットワーク帯域幅の一部は既に使用されていますが、手数料は攻撃者にとってのコストになります。 +検証とリレーを必要とするトランザクションを極端に多く送信する人は、やがて手数料を支払うお金がなくなります。 + +[Bitcoin Coreに][bitcoin core rbf docs]実装されている[Replace by Fee][topic rbf]ポリシーは、 +置換トランザクションは直接競合する各トランザクションよりも高い手数料率を支払う必要があり、 +置き換えられるすべてのトランザクションよりも高い総手数料を支払う必要があります。 +追加の手数料を置換トランザクションの仮想サイズで割った値は、少なくとも1sat/vBでなければなりません。 +言い換えれば、元のトランザクションと置換トランザクションの手数料率に関係なく、 +新しいトランザクションは1sat/vBで独自の帯域幅のコストをカバーするために「新しい」手数料を支払わなければなりません。 +この手数料ポリシーは、インセンティブの互換性に主眼を置いたものではありません。 +むしろ、これにより、帯域幅を浪費する攻撃を抑制するために、 +トランザクションを繰り返し置換する最小限のコストを発生させます +（たとえば、置換の度に1 satoshiだけ追加するようなもの）。 + +ブロックとトランザクションを完全に検証するノードは、メモリや計算リソース、ネットワーク帯域幅を含むリソースを必要とします。 +ノードの実行を容易にし、ノードを攻撃から守るためには、必要なリソースを低く抑える必要があります。 +一般的なDoS保護だけでは不十分なため、ノードは未承認トランザクションを検証する際に、 +コンセンサスルールに加えてトランザクションリレーポリシーを適用します。 +しかし、ポリシーはコンセンサスではないため、2つのノードが異なるポリシーを持っていても、 +現在のチェーンの状態について合意することは可能です。来週の記事では、個人の選択としてのポリシーについて説明します。 + +[policy01]: /ja/newsletters/2023/05/17/#承認を待つ-1-なぜmempoolがあるのか +[max cpu tx]: https://bitcointalk.org/?topic=140078 +[megatx mempool space]: https://mempool.space/tx/bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08 +[rusty megatx]: https://rusty.ozlabs.org/?p=522 +[bitcoin core rbf docs]: https://github.com/bitcoin/bitcoin/blob/v25.0/doc/policy/mempool-replacements.md +[pr 6722]: https://github.com/bitcoin/bitcoin/pull/6722 +[se descendant limits]: https://bitcoin.stackexchange.com/questions/118160/whats-the-governing-motivation-for-the-descendent-size-limit diff --git a/_includes/specials/policy/ja/06-consistency.md b/_includes/specials/policy/ja/06-consistency.md new file mode 100644 index 0000000000..a3db2dde3a --- /dev/null +++ b/_includes/specials/policy/ja/06-consistency.md @@ -0,0 +1,78 @@ +先週の記事では、コンセンサスルールに加えて適用されるトランザクションの検証ルールのセットである +ポリシーについて紹介しました。これらのルールは、ブロック内のトランザクションには適用されないため、 +ノードのポリシーがピアと異なっていても、コンセンサスを維持することができます。 +ノードオペレーターがトランザクションリレーに参加しないことを選択できるように、 +どのようなポリシーを選択するかも自由で、全く選択しない（ノードがDoSのリスクにさらされる）ことも可能です。 +つまり、ネットワーク全体でmempoolポリシーが完全に同一であるとは仮定できません。 +しかし、ユーザーのトランザクションがマイナーに受信されるためには、 +すべてのノードがそのトランザクションを自身のmempoolに受け入れる経路を通過する必要があり、 +ノード間のポリシーの不一致はトランザクションリレーの機能に直接影響します。 + +ノード間のポリシーの違いの極端な例として、各ノードオペレーターがランダムな`nVersion`を選択し、 +その`nVersion`のトランザクションのみを受け入れるという状況を想像してみてください。 +ほとんどのピアツーピアの関係は互換性のないポリシーを持つことになるので、 +トランザクションはマイナーまで伝播しません。 + +一方、ネットワーク全体で同一のポリシーがあれば、mempoolの内容を収束させることができます。 +mempoolが一致するネットワークは、トランザクションを最もスムーズにリレーし、 +これまでの記事で説明したように、[手数料の推定][policy04]や[コンパクトブロックリレー][policy01]にも最適です。 + +mempoolの検証の複雑さとポリシーの不一致から生じる困難を考慮し、 +Bitcoin Coreは歴史的にポリシーの設定可能性に関して[保守的][aj mempool consistency]でした。 +ユーザーは、sigopsのカウント方法（`bytespersigop`）を簡単に微調整したり、 +`OP_RETURN`アウトプットに埋め込めるデータ量を制限したり（`datacarriersize`および`datacarrier`）できる一方で、 +ソースコードを変更することなく、400,000 weight-unitの最大標準weightをオプトアウトしたり、 +手数料関連のRBFルールに異なるセットを適用したりすることはできません。 + +Bitcoin Coreのポリシー設定オプションの中には、ノードの動作環境の違いや、 +運用目的の違いに対応するためのものが存在します。たとえば、 +マイナーのハードウェアリソースやmempoolを維持する目的は、 +ラップトップやRaspberry Piで軽量ノードを実行する日常的なユーザーとは異なります。 +マイナーはmempoolの容量（`maxmempool`）や有効期限のタイムライン（`mempoolexpiry`）を増やして +トラフィックピーク時の低手数料率のトランザクションを保存し、 +トラフィックが落ち着いたときにそれらをマイニングするかもしれません。 +可視化やアーカイブ、ネットワーク統計を提供するウェブサイトでは、 +できるだけ多くのデータを収集するために複数のノードを実行し、 +デフォルトのmempoolの動作を表示することもあります。 + +個々のノードでは、mempoolの容量の選択が手数料引き上げツールの可用性に影響します。 +デフォルトのmempoolサイズを超えるトランザクションの送信により、 +mempoolの最小手数料率が上昇すると、mempoolの「底」からパージされたトランザクションと、 +この手数料率を下回る新しいトランザクションは、[CPFP][topic cpfp]を使って手数料を引き上げられなくなります。 + +一方、パージされたトランザクションによって使用されていたインプットは、 +mempool内のどのトランザクションも使用していないので、 +以前はできなかった [RBF][topic rbf]による手数料の引き上げが可能になるかもしれません。 +新しいトランザクションは、ノードのmempool内の何かを実際に置き換えているわけではないので、 +通常のRBFルールを考慮する必要はありません。しかし、（より大きなmempool容量を持つため） +元のトランザクションをパージしていないノードは、新しいトランザクションを提案された置換トランザクションとして扱い、 +RBFルールへの準拠を要求します。パージされたトランザクションがBIP125の置換可能性をシグナルしていなかったり、 +新しいトランザクションの手数料が高い手数料率にも関わらずRBFの要件を満たしていない場合、 +マイナーはその新しいトランザクションを受け入れない可能性があります。 +ウォレットはパージされたトランザクションを注意深く扱う必要があります。 +トランザクションのアウトプットは使用可能とは見なせませんが、インプットは同様に再利用することはできません。 + +一見すると、より大きなmempool容量を持つノードは、CPFPの有用性が高くRBFの有用性が低いように見えるかもしれません。 +しかし、トランザクションのリレーは、ネットワークの創発的な挙動に左右され、 +ユーザーからマイナーまでCPFPを受け入れるノードの経路が存在しないかもしれません。 +ノードは通常、トランザクションをmempoolに受け入れた時に一度だけそれをリレーし、 +自分のmempoolに既に存在するトランザクションの通知を無視します。 +より多くのトランザクションを格納するノードは、それらのトランザクションが再度ブロードキャストされたときに +[ブラックホールとして機能します][se maxmempool]。 +ネットワーク全体がmempoolの容量を増やさない限り（デフォルト値を変更する変調）、 +自分自身のmempoolの容量を増やすことで利益を得ることはほとんど期待できないでしょう。 +デフォルトのmempoolの最小手数料率は、トラフィックピーク時にCPFPを使用することの有用性を制限しています。 +サイズを拡大した自分のmempoolにCPFPトランザクションを送信できたユーザーは、 +そのトランザクションが他の誰にも伝播していないことに気づかないかもしれません。 + +トランザクションリレーネットワークは、ネットワークに動的に参加および離脱する個々のノードで構成されており、 +それぞれが悪用から身を守る必要があります。そのため、トランザクションリレーはベストエフォート型でしかなく、 +すべてのノードがすべての未承認トランザクションを学習することを保証することはできません。 +同時に、Bitcoinネットワークは、mempoolを可能な限り均質にするトランザクションリレーポリシーの1セットに収束すれば、 +最高のパフォーマンスを発揮します。次の記事では、ネットワーク全体の利益に適合するために、 +どのようなポリシーが採用されているかを探ります。 + +[policy01]: /ja/newsletters/2023/05/17/#承認を待つ-1-なぜmempoolがあるのか +[policy04]: /ja/newsletters/2023/06/07/#承認を待つ-4-手数料率の推定 +[aj mempool consistency]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021116.html +[se maxmempool]: https://bitcoin.stackexchange.com/questions/118137/how-does-it-contribute-to-the-bitcoin-network-when-i-run-a-node-with-a-bigger-th diff --git a/_includes/specials/policy/ja/07-network-resources.md b/_includes/specials/policy/ja/07-network-resources.md new file mode 100644 index 0000000000..0dcb381628 --- /dev/null +++ b/_includes/specials/policy/ja/07-network-resources.md @@ -0,0 +1,79 @@ +前回の記事では、ノードリソースの保護について説明しました。 +ノードリソースはノード毎に固有であり、設定可能な場合もあります。 +また、1つポリシーに収束することが最善である理由についても説明しましたが、 +そのポリシーの一部として何が含まれるべきでしょうか？ +この記事では、スケーラビリティ、アップグレード性、ブートストラップやフルノードの維持のし易さなどにとって重要な、 +ネットワーク全体のリソースの概念について説明します。 + +[以前の記事][policy01]で説明したように、Bitcoinネットワークの思想的目標の多くは、 +その分散構造に具現化されています。Bitcoinのピア・ツー・ピアの性質により、 +ネットワークのルールは個々のノードオペレーターの選択の大まかな合意から生まれ、 +ネットワーク内で不当な影響力を獲得しようとする試みを抑制します。 +これらのルールは、すべてのトランザクションを個別に検証する各ノードによって適用されます。 +多様で健全なノード群を実現するには、ノードの運用コストを低く抑える必要があります。 +世界中のユーザーを対象にプロジェクトを拡大するのは困難ですが、 +分散化を犠牲にすることなくそれを行うことは、片手を背中に縛られて戦うようなものです。 +Bitcoinプロジェクトは、共有ネットワークのリソース、つまりUTXOセットや、 +ブロックチェーンのデータフットプリントとその処理に必要な計算量、 +Bitcoinプロトコルを進化させるためのフックのアップグレードを厳重に保護することで、 +このバランスをとろうとしています。 + +ブロックチェーンの成長に制限を設けることが自分自身のノードを運営するために手頃な価格を維持するのに必要であることを理解するために、 +再度ブロックサイズ戦争を繰り返す必要はありません。ただし、ブロックチェーンの成長は、 +「[高度に複製された永久的なストレージに対する無制限の需要][unbounded]」の一部を表現するために必要な最小コストを確保する +1 sat/vbyteの`minRelayTxFee`によってポリシーレベルでも抑制されています。 + +当初、ネットワークの状態は、未使用のアウトプットをまだ持つすべてのトランザクションを保持することで追跡されていました。 +ブロックチェーンのこのより大きな部分は、資金を追跡する手段として[UTXOセットの導入][ultraprune]により大幅に削減されました。 +それ以来、UTXOセットは中心的なデータ構造となっています。特にIBD中だけでなく一般的にも、 +UTXOのルックアップは、ノードのすべてのメモリアクセスの大部分を占めています。 +Bitcoin Coreは、既に[UTXOキャッシュ用に手動で最適化されたデータ構造][pooled resource]を使用していますが、 +UTXOセットのサイズはノードのキャッシュに収まらない量を決定します。 +UTXOセットが大きいほどキャッシュミスが多くなり、ブロックの検証やIBD、トランザクションの検証速度が遅くなります。 +ダスト・リミットは、UTXOの作成を制限するポリシーの例であり、 +具体的には、その額が支払いに必要なコストを[下回る][topic uneconomical outputs]ため、 +決して使用されない可能性のあるUTXOを抑制します。それでも、 +[数千件のトランザクションを伴う「ダスト・ストーム」は2020年にも発生しました][lopp storms]。 + +データをブロックチェーン上に公開するためにベア・マルチシグアウトプットを使用するのが一般的になったとき、 +標準トランザクションの定義が修正され、代わりに単一のOP_RETURNアウトプットを許可するようになりました。 +人々は、ユーザーがブロックチェーン上にデータを公開するのを防ぐことは不可能であることに気づきましたが、 +少なくともそのようなデータは決して使用されないアウトプットで公開される場合、 +UTXOセットに永久に存在する必要はありません。 +Bitcoin Core 0.13.0では、ユーザーがベア・マルチシグアウトプットを含む未承認トランザクションを +拒否するように切り替えることができる起動オプション`-permitbaremultisig`が導入されました。 + +コンセンサスルールでは、アウトプットスクリプトを自由な形式にすることができますが、 +Bitcoin Coreノードによってリレーされるのはわずかなパターンだけです。 +これにより、検証コストやプロトコルアップグレードメカニズムなど、 +ネットワーク内の多くの懸念を理解しやすくなります。 +たとえば、opcodeを含むインプットスクリプトや、15個以上の署名を持つP2SHインプット、 +witnessスタックに100を超える項目を持つP2WSHインプットは、非標準トランザクションになります。 +（ポリシーの例やその動機については、この[ポリシーの概要][instagibbs policy zoo]をご覧ください。） + +最後に、Bitcoinプロトコルは、活動中のソフトウェアプロジェクトであり、 +将来の課題やユーザーのニーズに対応するために進化し続ける必要があります。 +そのため、annexやTaprootのリーフバージョン、witnessバージョン、OP_SUCCESSおよび +多数のno-op opcodeなど、コンセンサスが有効であるにもかかわらず未使用のまま意図的に残された多数のアップグレードフックがあります。 +ただし、攻撃が中央集権的な障害点の欠如によって妨げられるのと同様に、 +ネットワーク全体のソフトウェアのアップグレードには、数万もの独立したノードオペレーターの協調した取り組みが必要です。 +ノードは、その意味が定義されるまで、予約されたアップグレードフックを利用するトランザクションをリレーしません。 +この抑制は、アプリケーションが矛盾する標準を独自に作成することを思いとどまらせることを目的としています。 +これにより、あるアプリケーションの標準を、別のアプリケーションの標準を無効にすることなくコンセンサスに採用することは不可能になります。 +また、コンセンサスの変更が発生した場合、すぐにアップグレードしないノード、 +つまり新しいコンセンサスを知らないノードは、「騙されて」無効なトランザクションを自分のmempoolに受け入れることはできません。 +積極的な抑制により、ノードの前方互換性が維持され、完全に同期したソフトウェアアップデートを必要とせずに、 +ネットワークがコンセンサスルールを安全にアップグレードできるようになります。 + +ポリシーを使用して共有ネットワークリソースを保護することで、 +ネットワークの特性を保護し、将来のプロトコル開発のための道を開いておくことができます。 +一方、厳しく制限されたblockweightに対してネットワークを成長させる摩擦が、 +ベストプラクティの採用、優れた技術設計、イノベーションの採用をどのように推進しているかが分かります。 +来週の記事では、2ndレイヤープロトコルやスマートコントラクトシステムのインターフェースとしてのmempoolについて説明します。 + +[policy01]: /ja/newsletters/2023/05/17/#承認を待つ-1-なぜmempoolがあるのか +[unbounded]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html +[lopp storms]: https://blog.lopp.net/history-bitcoin-transaction-dust-spam-storms/ +[ultraprune]: https://github.com/bitcoin/bitcoin/pull/1677 +[pooled resource]: /ja/newsletters/2023/05/03/#bitcoin-core-25325 +[instagibbs policy zoo]: https://gist.github.com/instagibbs/ee32be0126ec132213205b25b80fb3e8 diff --git a/_includes/specials/policy/ja/08-interface.md b/_includes/specials/policy/ja/08-interface.md new file mode 100644 index 0000000000..619f4d6f70 --- /dev/null +++ b/_includes/specials/policy/ja/08-interface.md @@ -0,0 +1,91 @@ +本連載ではこれまで、分散型トランザクションリレーの[動機][policy01]と課題を探り、 +コンセンサスよりも厳しいトランザクション検証ルールの[ローカル][policy05]および +[グローバル][policy07]な必要性を示しました。 +トランザクションリレーポリシーの変更は、アプリケーションのトランザクションがリレーされるかどうかに影響を与えるため、 +検討する前に、より広範なBitcoinコミュニティとの交流が必要です。同様に、 +トランザクションリレーを利用するアプリケーションやセカンドレイヤープロトコルは、 +拒否されるトランザクションを作成しないように、ポリシールールを考慮して設計する必要があります。 + +オンチェーンでの強制力はトランザクションを迅速に承認できるかどうかに依存するため、 +コントラクトプロトコルは優先順位付けに関連するポリシーにさらに密接に依存します。 +敵対的な環境では、不正な取引相手はトランザクションの承認を遅らせることに関心を持っている可能性があるため、 +トランザクションリレーポリシーのインターフェースの癖がユーザーに対してどのように利用されるかについても考えなければなりません。 + +ライトニングネットワークのトランザクションは、以前の記事で説明した標準ルールに従います。 +たとえば、ピアツーピアプロトコルは、`open_channel`メッセージで`dust_limit_satoshis`を指定し、 +ダストの閾値を指定します。ダストの閾値より低い金額のアウトプットを含むトランザクションは、 +ノードのダスト制限によりリレーされないため、それらの支払いは「オンチェーンで強制力がない」と見なされ、 +コミットメントトランザクションから削除されます。 + +コントラクトプロトコルは、多くの場合、タイムロックされた支払いパスを使用して、 +各参加者にオンチェーンで公開されたステートに異議を唱える機会を与えます。 +影響を受けるユーザーがその時間内にトランザクションを承認できなければ、資金の損失を被る可能性があります。 +このため、手数料は承認の優先度を高めるための主要なメカニズムとして非常に重要ですが、同時により難しくもあります。 +[手数料率の推定][policy04]は、トランザクションが後でいつブロードキャストされるかわからず、 +ノードがシンクライアントとして動作することが多く、一部の手数料引き上げオプションが利用できないという事実により、複雑になります。 +どちらの参加者も共有されたUTXOを一方的に使用することはできないため、 +どちらかがオフラインになった場合、コミットメントトランザクションの手数料を引き上げる +[置換][topic rbf]トランザクションに署名することはできません。 +代わりに、LNのコミットメントトランザクションには、 +チャネル参加者がブロードキャスト時に[手数料引き上げの子トランザクション][topic cpfp]をアタッチするための +[アンカーアウトプット][topic anchor outputs]を含めることができます。 + +しかし、この手数料の引き上げ方法にも制限があります。[以前の記事][policy06]で説明したように、 +mempoolの最小手数料率がコミットメントトランザクションの手数料率よりも高くなると、 +CPFPトランザクションを追加しても効果がないため、将来mempoolの最小手数料率が上昇した場合に備えて、 +若干多めに見積もった手数料率で署名する必要があります。 +さらに、アンカーアウトプットの開発には、一方の参加者が承認を遅らせることに関心を持っている可能性があるという事実に対する +多くの考慮事項が含まれていました。たとえば、一方の参加者（アリス）は、 +オフラインになる前に自分のコミットメントトランザクションをネットワークにブロードキャストすることができます。 +このコミットメントトランザクションの手数料率が即時承認されるには低すぎ、 +アリスの取引相手（ボブ）が彼女のトランザクションを受け取っていない場合、 +ボブは自分のコミットメントトランザクションをブロードキャストしても正常にリレーされないため、混乱するかもしれません。 +各コミットメントトランザクションには、2つのアンカーアウトプットがあり、 +どちらの参加者もコミットメントトランザクションをCPFPすることができます。 +たとえば、ボブはアリスが以前コミットメントトランザクションをブロードキャストしているか確信を持てない場合でも、 +アリスのコミットメントトランザクションのCPFPによる手数料の引き上げトランザクションを +やみくもにブロードキャストしようとするかもしれません。 +各アンカーアウトプットには、ダストの閾値を超える少額が割り当てられ、 +UTXOセットの肥大化を防ぐために、しばらくすると誰でもそれを請求できるようになります。 + +しかし、各参加者がトランザクションをCPFPできることを保証することは、 +各参加者にアンカーアウトプットを与えるよりも複雑です。 +[以前の記事][policy05]で説明したように、Bitcoin Coreは +DoS対策として未承認トランザクションにアタッチできる子孫トランザクションの数と合計サイズを制限しています。 +各取引相手は、共有トランザクションに子孫をアタッチする能力を持っているため、 +一方がこの制限を使い果たすことで、他方のCPFPトランザクションのリレーをブロックすることができます。 +このような子孫の存在は、結果的にコミットメントトランザクションをmempool内で低優先度の状態に「固定」します。 + +この潜在的な攻撃を緩和するために、LNアンカーアウトプットの提案では、 +すべてのアンカーアウト以外のアウトプットを相対的なタイムロックでロックし、 +それらがトランザクションが未承認の間に使用されるのを防ぎます。 +また、Bitcoin Coreの子孫制限ポリシーは、新しい子孫が小さく、他に祖先がない場合にのみ、 +[1つの追加の子孫を許可するよう変更されました][topic cpfp carve out]（CPFP carve out）。 +これら2つのプロトコルの変更の組み合わせにより、トランザクションリレーのDoS攻撃面を大幅に増加させることなく、 +共有トランザクションの少なくとも2人の参加者がブロードキャスト時に手数料率の調整を行うことができるようになりました。 + +子孫制限の支配によるCPFPの防止は、[Pinning攻撃][topic transaction pinning]の一例です。 +Pinning攻撃は、mempoolポリシーの制限を利用して、インセンティブに適合するトランザクションが +mempoolに入ったり承認されるのを阻止します。この場合、mempoolポリシーは、 +[DoS耐性][policy05]と[インセンティブ適合性][policy02]の間のトレードオフを行っています。 +ノードは手数料の引き上げを考慮すべきですが、無制限に多くの子孫を処理することはできません。 +CPFP carve outは、特定のユースケースのためにこのトレードオフを洗練させています。 + +子孫制限を使い果たす以外にも、[RBFの使用を完全に阻止したり][full rbf pinning]、 +RBFを[法外に高価にしたり][rbf ml]、RBFを活用してANYONECANPAYトランザクションの承認を遅らせたりするPinning攻撃があります。 +Pinningが問題になるのは、複数の参加者が共同でトランザクションを作成するシナリオや、 +信頼できない参加者がトランザクションとやりとりする余地がある場合のみです。 +一般的に、信頼できない参加者へのトランザクションの露出を最小限に抑えることが、Pinningを回避する良い方法です。 + +これらの摩擦点は、Bitcoinエコシステムにおけるアプリケーションとプロトコルのインターフェースとしてポリシーの重要性だけでなく、 +改善が必要な部分を浮き彫りにしています。来週の記事では、ポリシーの提案と未解決の問題について説明します。 + +[full rbf pinning]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html +[rbf ml]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html +[n25038 notes]: https://bitcoincore.reviews/25038 +[policy01]: /ja/newsletters/2023/05/17/#承認を待つ-1-なぜmempoolがあるのか +[policy02]: /ja/newsletters/2023/05/24/#承認を待つ-2-インセンティブ +[policy04]: /ja/newsletters/2023/06/07/#承認を待つ-4-手数料率の推定 +[policy05]: /ja/newsletters/2023/06/14/#承認を待つ-5-ノードリソースの保護に関するポリシー +[policy06]: /ja/newsletters/2023/06/21/#承認を待つ-6-ポリシーの一貫性 +[policy07]: /ja/newsletters/2023/06/28/#承認を待つ-7-ネットワークリソース diff --git a/_includes/specials/policy/ja/09-proposals.md b/_includes/specials/policy/ja/09-proposals.md new file mode 100644 index 0000000000..f7051e721b --- /dev/null +++ b/_includes/specials/policy/ja/09-proposals.md @@ -0,0 +1,88 @@ +[先週の記事][policy08]では、[アンカーアウトプット][topic anchor outputs]と +[CPFP carve out][topic cpfp carve out]について説明しました。 +これにより、どちらのチャネル参加者も、協力することなく共有されたコミットメントトランザクションの手数料を +引き上げることができます。このアプローチには、まだいくつかの欠点があります。 +アンカーアウトプットを作成するためにチャネル資金が拘束され、 +コミットメントトランザクションの手数料率は、mempoolの最小手数料率を満たすことを保証するために、 +通常過大に支払われ、CPFP carve outでは追加の子孫は１つしか認められません。 +アンカーアウトプットでは、[Coinjoin][topic coinjoin]やマルチパーティコントラクトプロトコルなど、 +２人よりも多い参加者間で共有されるトランザクションの手数料の引き上げを保証することはできません。 +この記事では、これらの制限やその他の制限に対処するための現在の取り組みについて説明します。 + +[パッケージリレー][topic package relay]には、トランザクショングループの転送と検証を可能にする +P2Pプロトコルとポリシーの変更が含まれています。 +これは、コミットメントトランザクションがmempoolの最小手数料率を満たしていない場合でも、 +子によるコミットメントトランザクションの手数料の引き上げを可能にします。 +さらに、_パッケージRBF_ は、子トランザクションによる +競合する親トランザクションの[置換][topic rbf]のための手数料の引き上げを可能にします。 +パッケージリレーは、ベースプロトコルレイヤーにおける一般的な制限を取り除くように設計されています。 +しかし、共有トランザクションの手数料の引き上げにおけるその有用性から、 +特定のユースケースにおける[Pinning][topic transaction pinning]を排除するための多くの取り組みも生まれています。 +たとえば、パッケージRBFは、コミットメントトランザクションがそれぞれの手数料引き上げの子トランザクションと一緒にブロードキャストされる際に、 +相互に置換できるため、各コミットメントトランザクションに複数のアンカーアウトプットは必要なくなります。 + +注意すべき点は、既存のRBFルールでは、置換トランザクションには、 +置換されるすべてのトランザクションによって支払われる合計手数料よりも高い手数料を支払う必要があるという点です。 +このルールは、置換の繰り返しによるDoSを防ぐのに役立ちますが、 +悪意あるユーザーが、低手数料率であるものの手数料額は高い子トランザクションをアタッチすることで、 +トランザクションを置換する際のコストを増加させることを可能にします。 +これは、高手数料率パッケージによるトランザクションの置換を不当に阻止することで、 +トランザクションがマイニングされるのを妨げるものであり、よく「ルール３Pinning」と呼ばれています。 + +開発者はまた、署名済みトランザクションに手数料を追加する全く異なる方法を提案しています。 +たとえば、`SIGHASH_ANYONECANPAY | SIGHASH_ALL`を使用してトランザクションのインプットに署名することで、 +トランザクションブロードキャスターは、アウトプットを変更することなく、トランザクションにインプットを追加して手数料を提供できます。 +しかしながら、RBFには置換トランザクションがより高い「マイニングスコア」を持つこと（つまり、より速くブロックに選択される）を +要求するルールがないため、攻撃者は低手数料率の祖先に邪魔される置換トランザクションを作成することで、 +この種のトランザクションをPinning可能です。 +トランザクションおよびトランザクションパッケージのマイニングスコアの正確な評価を複雑にしているのは、 +既存の祖先と子孫の制限が、この計算の計算量を制限するには不十分であることです。 +接続されているトランザクションは、トランザクションがブロックに選択される順序に影響を与える可能性があります。 +_クラスター_ とよばれる完全に接続されたコンポーネントは、現在の祖先と子孫の制限があれば、 +任意のサイズにすることができます。 + +一部のmempoolの欠陥とRBFのPinning攻撃に対処するための長期的な解決策は、 +[mempoolのデータ構造を再構築して][mempool clustering]、 +祖先と子孫のセットだけでなくクラスターを追跡することです。これらのクラスターのサイズは制限されます。 +クラスターの制限により、ユーザーが未承認のUTXOを使用できる方法が制限されますが、 +祖先スコアベースのマイニングアルゴリズムを使用してmempool全体を線形化し、 +ブロックテンプレートを極めて迅速に構築し、置換トランザクションのマイニングスコアが +置換されるトランザクションよりも高いという要件を追加することは可能になります。 + +それでも、トランザクションリレーの幅広いニーズと期待に応えるための単一のポリシーセットは存在しない可能性があります。 +たとえば、バッチ処理された支払いは、多数の未承認の子孫を必要とするかもしれませんが、 +これは総手数料を通じて共有トランザクションのパッケージRBFをPinningする余地を残します。 +[v3トランザクションリレーポリシー][topic v3 transaction relay]の提案は、 +コントラクトプロトコルがより制限的なパッケージ制限のセットをオプトインできるようにするために開発されました。 +v3トランザクションは、サイズ2（親1つ子1つ）のパッケージのみを許可し、子のweightを制限します。 +これらの制限は、総手数料を通じたRBF Pinningを緩和し、 +mempoolの再構築を必要とせずにクラスターmempoolのメリットの一部を提供します。 + +[エフェメラルアンカー][topic ephemeral anchors]は、v3トランザクションとパッケージリレーの特性をベースに、 +アンカーアウトプットをさらに改善するための提案です。これは、手数料ゼロのv3トランザクションに属するアンカーアウトプットが、 +手数料を引き上げる子トランザクションによって使用される場合に限り、[ダスト制限][topic uneconomical outputs]から免除されます。 +手数料ゼロのトランザクションは、正確に1つの子トランザクションによって手数料を引き上げる必要があるため +（そうしないと、マイナーはそれをブロックに含めるインセンティブを得られません）、 +このアンカーアウトプットは「エフェメラル」であり、UTXOセットの一部にはなりません。 +エフェメラルアンカーの提案により、チャネルクローズトランザクションの手数料供給メカニズムとして +[CPFP][topic cpfp]を使用した[LN symmetry][topic eltoo]が実現可能になります。 +また、このメカニズムは、3人以上の参加者で共有されるトランザクションにも利用可能です。 +開発者は、[bitcoin-inquisition][bitcoin inquisition repo]を使用してエフェメラルアンカーをデプロイし、 +[signet][topic signet]上でこれらのマルチレイヤーの変更を構築してテストするためのソフトフォークを提案しています。 + +この記事で強調されたPinningの問題は、昨年、メーリングリストやプルリクエスト、 +ソーシャルメディア、直接の会議を通じて[RBFポリシーを改善するための豊富な議論や提案][2022 rbf]を生み出しました。 +開発者は、小さな修正から完全な刷新に至るまで、さまざまな解決策を提案し、実装しました。 +`-mempoolfullrbf`オプションは、Pinningの懸念とBIP125実装の不一致に対処することを意図したもので、 +トランザクションリレーポリシーにおけるコラボレーションの難しさと重要性を浮き彫りにしました。 +1年前にbitcoin-devメーリングリストで会話を始めるなど、一般的な手段を使って +コミュニティを巻き込もうとする真摯な努力がされましたが、 +既存のコミュニケーションや意思決定の方法が意図した結果を生んでおらず、改善が必要であることは明らかでした。 + +非中央集権的な意思決定は困難なプロセスですが、Bitcoinのトランザクションリレーネットワークを利用する +プロトコルやアプリケーションの多様なエコシステムをサポートするためには必要です。 +来週は、このシリーズの最終回で、読者の皆さんにこのプロセスへの参加と改善を奨励していただきたいと考えています。 + +[mempool clustering]: https://github.com/bitcoin/bitcoin/issues/27677 +[policy08]: /ja/newsletters/2023/07/05/#承認を待つ-8-インターフェースとしてのポリシー +[2022 rbf]: /ja/newsletters/2022/12/21/#rbf diff --git a/_includes/specials/policy/ja/10-get-involved.md b/_includes/specials/policy/ja/10-get-involved.md new file mode 100644 index 0000000000..da7f06a87c --- /dev/null +++ b/_includes/specials/policy/ja/10-get-involved.md @@ -0,0 +1,48 @@ +このシリーズが読者の皆様に、承認を待っている間に何が起こっているのかについて、 +より良く理解する助けになっていれば幸いです。私たちは、Bitcoinのイデオロギー的な価値のいくつかが、 +その構造や設計目標にどのように[反映されているか][policy01]という議論から始めました。 +ピアツーピアネットワークの分散構造は、典型的な中央集権的モデルよりも、 +検閲への耐性とプライバシーを高めています。オープンなトランザクションリレーネットワークは、 +承認前にブロック内のトランザクションを誰もが知るのを助け、[ブロックリレーの効率][policy01]を向上させ、 +新しくマイナーとして参加しやすくし、[ブロックスペースの公開オークション][policy02]を作り出します。 +理想的なネットワークは、ノードを実行する多くの独立した匿名のエンティティで構成されるため、 +ノードソフトウェアは[DoSから保護し][policy05]、一般的に運用コストを最小限に抑えるよう設計されなければなりません。 + +手数料は、ブロックスペースの競争を解決するための「公正な」方法として、Bitcoinネットワークで重要な役割を果たしています。 +トランザクションの置換やパッケージに対応した選択および排除アルゴリズムを備えるmempoolでは、 +トランザクションを保存する有用性を測定するために[インセンティブ互換性][policy02]が使用され、 +ユーザーに対して[RBF][topic rbf]や[CPFP][topic cpfp]を使用した手数料の引き上げを可能にします。 +このようなmempoolポリシーや、[経済的にトランザクションを構成する][policy03]ウォレット、 +そして優れた[手数料の推定][policy04]が組み合わさることで、 +ブロックスペースの効率的な市場が形成され、すべての人に利益をもたらします。 + +また、個々のノードは、[リソースの枯渇から自らを守り][policy05]、 +[個人的な好みを表明するために][policy06]、_トランザクションリレーポリシー_ を適用します。 +[ネットワーク全体のレベル][policy07]では、標準ルールとその他のポリシーが、 +スケーリングやノードの実行しやすさ、コンセンサスルールを更新する能力にとって重要なリソースを保護します。 +ネットワークの大多数がこれらのポリシーを適用しているため、 +BitcoinのアプリケーションやL2プロトコルが構築される[インターフェース][policy08]の重要な部分でもあります。 +そしてまた、完璧ではありません。私たちは、広範な制限や[L2決済トランザクションに対するPinning攻撃][policy08]など +特定のユースケースに対処する、いくつかの[ポリシー関連の提案][policy09]について説明しました。 + +また、ネットワークポリシーの継続的な進化には、プロトコル、アプリケーション、 +ウォレットに携わる開発者間の協力が必要であることも協調しました。 +Bitcoinエコシステムがソフトウェア、ユースケース、ユーザーに関して成長するにつれて、 +分散型の意思決定プロセスはより必要とされるようになりますが、同時により困難にもなります。 +Bitcoinの普及が拡大しても、このシステムはステークホルダーの懸念や努力から生まれています。 +顧客からのフィードバックを集め、新しいプロトコル機能を構築したり +使用されなくなった機能を削除したりするためのエンジニアを雇用する責任を負う企業はありません。 +ネットワークのラフコンセンサスに参加したいステークホルダーには、 +さまざまな参加方法があります。情報を提供したり、質問や問題を提起したり、 +ネットワークの設計に参加したり、あるいは改善の実装に貢献したりすることです。 +この次、あなたのトランザクションの承認に時間がかかっている場合は、何をすればいいか分かりますね！ + +[policy01]: /ja/newsletters/2023/05/17/#承認を待つ-1-なぜmempoolがあるのか +[policy02]: /ja/newsletters/2023/05/24/#承認を待つ-2-インセンティブ +[policy03]: /ja/newsletters/2023/05/31/#承認を待つ-3-ブロックスペースの入札 +[policy04]: /ja/newsletters/2023/06/07/#承認を待つ-4-手数料率の推定 +[policy05]: /ja/newsletters/2023/06/14/#承認を待つ-5-ノードリソースの保護に関するポリシー +[policy06]: /ja/newsletters/2023/06/21/#承認を待つ-6-ポリシーの一貫性 +[policy07]: /ja/newsletters/2023/06/28/#承認を待つ-7-ネットワークリソース +[policy08]: /ja/newsletters/2023/07/05/#承認を待つ-8-インターフェースとしてのポリシー +[policy09]: /ja/newsletters/2023/07/12/#承認を待つ-9-ポリシーの提案 diff --git a/_includes/specials/policy/zh/01-why-mempool.md b/_includes/specials/policy/zh/01-why-mempool.md new file mode 100644 index 0000000000..b03be10246 --- /dev/null +++ b/_includes/specials/policy/zh/01-why-mempool.md @@ -0,0 +1,26 @@ + + +比特币网络上的许多节点将未确认的交易存储在一个内存池或称之为 _交易池（mempool）_。该缓存是每个节点的重要资源，使得点对点的交易中继网络成为可能。 + +参与交易中继的节点稳步而非陡然地下载和验证区块。每隔约 10 分钟发现一个区块时，没有交易池的节点就会出现带宽峰值，随之而来的是验证每笔交易的计算密集期；另一方面，具有交易池的节点通常已经看到了区块的所有交易并将它们存储在它们的内存池中。使用“[致密区块中继][topic compact block relay]，这些节点只需下载一个区块头和 shortid，就可以使用其交易池中的交易来重建区块。与区块的大小相比，用于中继致密区块的数据量很小。验证交易也快得多：节点已经验证（并缓存）了签名和脚本，计算了时间锁要求，并已经出于必要、从磁盘加载了相关的 UTXO。该节点还可以迅速将区块转发给其他节点，从而显着提高网络范围内的区块传播速度、降低出现陈旧区块的风险。 + +交易池也可用于构建独立的费用估算器。区块空间市场是收费拍卖，保留交易池可以让用户更好地了解其他人在竞标什么以及过去哪些竞标成功了。 + +然而，没有“唯一交易池”这样的东西——每个节点可能会收到不同的交易。向一个节点提交交易并不一定意味着它已经到达矿工手中。一些用户发现这种不确定性令人沮丧，并想知道，“我们为什么不直接向矿工提交交易呢？” + +设想一种比特币网络，其中所有交易都直接从用户发送到矿工。人们可以通过要求少数实体记录与每笔交易对应的 IP 地址来审查和监视金融活动，并拒绝接受任何符合特定模式的交易。这种类型的比特币有时可能更方便，但会缺少一些比特币最有价值的特性。 + +比特币的抗审查性和隐私性来自于它的点对点网络。为了中继交易，每个节点都可以连接到一些匿名的对手节点集，每个对手节点都可以是矿工或与矿工有联系的人。此方法有助于混淆交易源自哪个节点，以及哪个节点可能负责确认它。希望审查特定实体的人可能会针对矿工、热门交易所或其他中心化提交服务，但很难完全阻止任何事情。 + +未确认交易的普遍可用性也有助于最大限度地降低成为区块生产者的进入成本——对被选择（或被排除）的交易不满意的人可能会立即开始挖矿。将每个节点视为交易广播的平等候选者，可避免给予任何矿工获取交易及其费用的特权。 + +总之，交易池是一种非常有用的缓存，它允许节点随时间分配区块下载和验证的成本，并让用户获得更好的费用估算。在网络层面，交易池支持交易分发和区块中继网络。当每个人都在矿工将它们包含在区块中之前看到所有交易时，所有这些好处最为明显——就像任何缓存一样，交易池在“火热”时最有用，并且必须限制其大小以适应内存。 + +下周本节将探讨使用激励相容性作为判断哪些交易将保留在交易池中的最有用的指标。 \ No newline at end of file diff --git a/_includes/specials/policy/zh/02-cache-utility.md b/_includes/specials/policy/zh/02-cache-utility.md new file mode 100644 index 0000000000..b6ed0f30a1 --- /dev/null +++ b/_includes/specials/policy/zh/02-cache-utility.md @@ -0,0 +1,24 @@ +[本栏目在上周][policy01]提到，交易池（mempool）是未确认交易的缓存空间，它为用户提供了一种去中心化的、向矿工发送交易数据的方法。但是，矿工没有义务确认这些交易；只包含了一笔 coinbase 交易的区块也是共识上有效的区块。用户可以通过提高输入的价值而不改变输出的总价值 —— 矿工能够获取两端的差额作为交易 *手续费* —— 来吸引矿工打包自己的交易。 + +虽然交易手续费在传统的金融系统中很常见，但刚接触比特币的用户可能经常觉得惊讶，这些手续费不是按支付额的比例收取的，而是根据交易的重量（weight）收取的。也就是说，区块空间才是限制因素，流动性并不是。*手续费率* 通常以 聪/vB（虚拟字节）来衡量。 + +共识规则限制了每个区块可用于打包交易的空间。这个限制使得区块广播到整个网络的时间低于出现区块的间隔，从而降低了出现 “过时区块（stale blocks）” 的风险。它也帮助限制了区块链和 UTXO 集的体积增长，这两者都直接构成了启动和维护一个全节点的成本。 + +因此，作为这个未确认交易的缓存的角色的一部分，交易池也协助了无弹性的区块空间的公开拍卖：在正常运行的时候，拍卖会遵循自由市场的原理，即，完全基于手续费，而非跟矿工的个人关系，来决定交易打包的优先级。 + +为一个区块（有自身的总重量限制和签名操作数量限制）选择交易、同时最大化手续费，是一个 “[NP 困难问题][NP-hard problem]”。这个问题会因为交易之间的关联而变得更加复杂：打包一笔高费率的交易，可能需要同时打包一笔低费率的父交易。反过来说，打包一笔低费率的交易，可能会开启打包高费率子交易的机会。 + +Bitcoin Core 客户端的交易池会为每一笔交易及其祖先交易计算手续费率（称为 “*祖先手续费率*”），缓存这个结果，然后使用一种 “贪婪区块模板建构算法”。它会按 “*祖先分数*”（在祖先手续费率和单体交易手续费率两者间取小值）为交易池排序，然后按顺序选出祖先交易包、更新剩余交易的祖先手续费，并对信息加权。这套算法在性能和获利能力之间取得了一个平衡，但并不一定能产生最优的结果。它的效力可以通过限制单体交易和祖先交易包的体积来提高 —— Bitcoin Core 将它们分别限制在 40 0000 重量单位和 40 4000 重量单位。 + +类似地，可以计算出一个 *后代分数* 并用来选择要逐出交易池的交易包，因为逐出自身低手续费率但具有高手续费率后代的交易可能会错失好处。 + +交易池验证在处理花费相同输入的交易（即，重复花费或者说冲突交易）时也会用到手续费和手续费率。节点不会按先到先得的规则保留先收到的那一笔交易，而是会根据一组规则来确定哪一笔交易更加激励兼容，然后保留下来。这个行为叫做 “手续费替换（[Replace by Fee][topic rbf]）”。 + +矿工会最大化手续费，这符合直觉，但为什么一个不挖矿的节点也要实现这些规则呢？就像上周本栏目所说的，不挖矿节点的交易池的效用，是由它跟矿工的交易池的相似性决定的。因此，即使一个节点从不尝试使用其交易池中的内容产生区块，他们也愿意保存最为激励兼容的交易。 + +虽然没有共识规则要求交易支付手续费，但手续费和手续费率在为比特币网络中扮演着重要角色，它是一种 “公平的” 解决区块空间竞争的办法。矿工使用手续费率来评估可取程度、处理驱逐和冲突，而不挖矿的节点也参照这种行为，以尽可能提高自己的交易池的效用。 + +区块空间的稀缺性，产生了降低交易体积的压力，并鼓励开发者构造更有效率的交易。下周的专栏中，我们会探索链上交易节约手续费的实用策略和技术。 + +[policy01]: /zh/newsletters/2023/05/17/#等待确认-1-我们为什么需要一个交易池 +[np-hard problem]: https://en.wikipedia.org/wiki/NP-hardness diff --git a/_includes/specials/policy/zh/03-bidding-for-block-space.md b/_includes/specials/policy/zh/03-bidding-for-block-space.md new file mode 100644 index 0000000000..a2bd5aa173 --- /dev/null +++ b/_includes/specials/policy/zh/03-bidding-for-block-space.md @@ -0,0 +1,36 @@ + + +上周我们提到交易为所用的区块空间支付费用，而不是按照所转移的金额支付费用，并确定矿工将优化他们的交易选择以最大化收取费用。因此，当找到一个块时，只有那些位于交易池头部的交易才会得到确认。在这篇文章中，我们将讨论让手续费花得最值的实用策略。让我们假设我们有一个不错的费率估算来源——我们将在下周的文章中更多地讨论费率估算。 + +在构建交易时，交易的某些部分比其他部分更灵活。每笔交易都需要头部字段，收款人输出由正在进行的付款决定，并且大多数交易都需要找零输出。发送方和接收方都应该更喜欢区块空间高效的输出类型，以减少未来花费交易输出的成本，但在[输入/钱币选择][topic coin selection]期间，更改交易的最终组成和重量的空间最大。由于交易按费率[费率/重量]竞争，较轻的交易只需更低的费用就能达到相同的费率。 + +一些钱包，例如 Bitcoin Core 钱包，尝试组合输入以避免设置找零输出。避免找零可以节省现在输出的重量，还可以节省以后花费找零输出的未来成本。不幸的是，除非钱包拥有大量不同金额的大型 UTXO 池，否则这种输入组合几乎不存在。 + +较新的输出类型比旧输出类型更节省区块空间。例如，花费 P2TR 输入产生的重量不到 P2PKH 输入的 2/5。(使用我们的[交易规模计算器][transaction size calculator]试试吧！)对于多重签名钱包，最近定稿的 [MuSig2][topic musig] 方案和 FROST 协议通过允许多重签名功能以看起来像单签名输入的方式编码，节省了许多费用。特别是在区块空间需求飙升的时代，使用较新的输出类型的钱包本身就可以节省大量费用。 + +{:.center} +![Overview of input and output weights](/img/posts/specials/input-output-weights.png) + +聪明的钱包根据费率调整其选择策略：在高费率下，它们使用很少的输入和较新的输入类型来让输入集的重量尽可能低。始终选择最轻的输入集将局部地最小化当前交易的成本，但也会将钱包的 UTXO 池磨成小碎片。这可能会让用户在日后的高手续费率环境下也不得不选择较重的输入集。因此，对钱包来说，具有先见之明的做法是，如果预期日后会出现区块空间的需求高峰，就趁手续费率的低谷选择更多和更重的输入、将资金整合进数量更少的新型输出。 + +大容量钱包通常会将多个付款批处理到单个交易中，以减少每一笔支付的交易重量。批处理避免了头字节的开销和每次付款的找零输出，所有支付共同分摊同一份固定开销。即使只是批量处理几笔付款，也可以快速降低每次付款的成本。 + +![Savings from payment batching with +P2WPKH](/img/posts/payment-batching/p2wpkh-batching-cases-combined.png) + +但是，即便许多钱包会错误估计手续费(因此超额支付(overpayment))，在出块缓慢或交易提交量激增的时候，有时交易也会迟迟得不到确认。在这些情况下，发送方或接收方可能希望再次提高交易的确认优先级。 + +用户通常有两种工具可以提高交易的优先级，即“子为父偿([CPFP][topic cpfp])”和“手续费替换([RBF][topic rbf])”。在 CPFP 中，用户花费其交易输出来创建高费率的子交易。正如上周的帖子所描述的那样，矿工被激励将父交易选入区块，以便包括手续费高的子交易。一笔交易的任何收款者均可利用 CPFP，因此接收方和发送方（如果他们创建了找零输出）都可以利用它。 + +在 RBF 中，发送者制作更高手续费的交易以替换原版交易。替换交易必须重用原版交易中的至少一个输入，以确保与原版交易冲突，并且区块链中只能包含两个交易中的一个。通常，这样的替换交易会保留原版交易的付款，但发送者也可以将替换交易中的资金重新定向，或者在替换时将多个交易的付款合并为一个。正如上周的帖子所述，节点驱逐原版交易，以支持更具激励相容的替换交易。 + +虽然区块空间的需求和生产都不在我们的控制范围内，但钱包可以使用许多技术来有效地竞标区块空间。钱包可以通过消除找零输出、花费原生的隔离见证输出以及在低费率环境中对其 UTXO 池进行碎片整理，来创建更轻的交易，以节省费用。支持 CPFP 和 RBF 的钱包也可以从保守的费率开始，然后在需要时使用 CPFP 或 RBF 更新交易的优先级。 + +[transaction size calculator]: /en/tools/calc-size \ No newline at end of file diff --git a/_includes/specials/policy/zh/04-feerate-estimation.md b/_includes/specials/policy/zh/04-feerate-estimation.md new file mode 100644 index 0000000000..5333b407dd --- /dev/null +++ b/_includes/specials/policy/zh/04-feerate-estimation.md @@ -0,0 +1,23 @@ +上周，我们探讨了在给定费率的情况下，最小化交易手续费的技巧。但是，费率应该是多少呢？理想情况下，它应该尽可能低（为了省钱），同时又高到足以保证交易在适合用户时间偏好的区块中获得一个位置。 + +_费（率）估算_ 的目标是将确认的目标时间转化为交易应支付的最低费率。 + +费率估算的一个复杂之处在于区块空间生产的不规律。假设一个用户需要在一小时内支付给商家，以收到商品。用户可能期望每 10 分钟挖出一个区块，因此目标是在接下来的 6 个区块中找到一个位置。然而，完全有可能一个区块需要 45 分钟才能被挖出。费率估算器必须在用户期望的紧急程度或者时间窗口（类似于“我希望在工作日结束之前确认这笔交易”）和区块空间供应（一定数量的区块）之间进行转换。许多费用估算器通过将确认目标以区块数量和时间的形式表示来解决这个挑战。 + +如果没有正在等待确认的交易的信息，人们可以依据历史数据（已经入块的交易的费率）构建一个简单的费用估算器。由于这样的估算器没有考虑交易池中待确认的交易，在区块空间需求出现意外波动和偶尔的长区块间隔时，它会变得非常不准确。它的另一个弱点是它完全依赖矿工控制的信息，矿工可以通过在他们的区块中包含虚假的高费率交易来推高（估算）费率。 + +幸运的是，区块空间的市场并不是暗标拍卖。我们在[第一篇文章][policy01]中提到，保留交易池并参与点对点交易中继网络允许节点查看用户的出价。Bitcoin Core 费用估算器还使用历史数据来计算交易在 `n` 个区块内以费率 `f` 确认的可能性，但具体跟踪节点首次看到交易的高度以及交易确认的时间。这种方法通过忽略公开费用市场之外发生的活动来避免被它们影响。如果矿工在自己的区块中人为地包含高费率交易，则该费用估算器不会出现偏差，因为它仅使用在确认之前被公开转发的交易的数据。 + +我们还深入了解了为区块选择交易的方式。在[上一篇文章][policy02]中，我们提到节点模拟矿工策略，以便在其交易池中保留激励兼容的交易。扩展这个想法，我们可以构建一个费用估算器来模拟矿工会做什么，而不只是查看过去的数据。为了找出交易在接下来的 `n` 个区块中为确认所需要的费率，费用估算器可以使用区块组装算法从其交易池中预测接下来的 `n` 个区块模板，并计算出击败费率最低一笔交易、从而可以进入到区块 `n` 中的费率。 + +显然，该费用估算器方法的有效性取决于其交易池内容与矿工内容之间的相似性，而这一点永远无法得到保证。它还忽视了矿工由于外部动机而可能包含的交易，例如，矿工自己的交易、在系统外给矿工支付费用的交易。预测还必须考虑从现在到预测区块被挖出之间新出现的交易。可以通过减少预计区块的大小，来容纳其它交易所带来的影响——但减少多少呢？ + +这个问题再次凸显了历史数据的效用。智能模型可能能够整合活动模式并考虑影响费率的外部事件，例如典型的营业时间、公司定期的 UTXO 合并以及针对比特币交易价格变化的活动。预测区块空间需求的问题仍然有待探索，并且可能永远有创新的空间。 + +费用估计是一个多方面且困难的问题。糟糕的费用估计可能会超付费用（也即浪费资金）、增加比特币在支付方面的摩擦、导致 L2 用户因错过一个时间锁定的 UTXO 的备用花费路径而损失资金。良好的费用估计可以让用户清楚而准确地向矿工传达交易的紧急程度，而 [CPFP][topic cpfp] 和 [RBF][topic rbf] 允许用户在初始估计不足时更新出价。激励兼容的交易池策略，与良好设计的费用估计工具和[钱包][policy03]相结合，使用户能够参与高效的公共拍卖以获取区块空间。 + +费用估算器通常不会返回低于 1sat/vB 的任何值，无论时间范围有多长，待确认的交易有多少。许多人认为 1sat/vB 是事实上的最低费率。这是因为在比特币网络中，网络上的大多数节点（包括矿工）[从不接受][topic default minimum transaction relay feerates]低于该费率的任何交易，无论他们的交易池有多空。下周的文章将探讨这种节点策略以及利用费率在交易中继中的另一个动机：防止资源耗尽。 + +[policy01]: /zh/newsletters/2023/05/17/#等待确认-1-我们为什么需要一个交易池 +[policy02]: /zh/newsletters/2023/05/24/#等待确认-2激励 +[policy03]: /zh/newsletters/2023/05/31/#等待确认3竞价区块空间 diff --git a/_includes/specials/policy/zh/05-dos.md b/_includes/specials/policy/zh/05-dos.md new file mode 100644 index 0000000000..0e93373d79 --- /dev/null +++ b/_includes/specials/policy/zh/05-dos.md @@ -0,0 +1,25 @@ +在本系列文章的[开篇][policy01]，我们提到，比特币的隐私和抗审查特性，都来自于网络的去中心化。用户运行自己的节点的习惯，减少了单点故障、监视和审查。这又来自于比特币节点软件的首要设计目标：运行节点是非常轻松的。如果每个比特币用户都需要购买昂贵的硬件、使用特定的操作系统、每个月支出数百美元的运营成本，那网络中的节点数量可能会大大减少。 + +此外，比特币网络中的节点就是一台计算机，它使用互联网跟陌生人的节点相互连接；这些陌生人可能会对这个节点发送 “拒绝服务式（DoS）” 攻击：发送会导致这个节点耗尽内存然后宕机的消息、使用无意义的数据耗费这个节点的运算资源和贷款从而使之不能接收新区块。因为这些陌生人都是匿名的（系统本身就是这样设计的），节点无法在连接之前预先断定哪个对等节点是诚实的、恶意的；而且在观察到攻击之后也无法有效地绝交。所以，实现保护节点免受 DoS 攻击的交易池规则，不仅是一种理想，更是一种现实需要。 + +节点实现中内置了通用的 DoS 保护措施，以防止资源耗尽。举例来说，如果一个 Bitcoin Core 节点从单个对等节点处收到许多消息，那么它会仅处理第一条收到的消息、将其余的消息放到一个待处理队列中，等其他对等节点的消息到达之后再处理。类似地，节点一般会先下载一个区块头，待验证完这个区块头的 “工作量证明（PoW）” 之后，才下载和验证完整的区块。因此，任何希望通过区块转发来耗尽这个节点的资源的攻击者，都必须先花费不成比例的大量资源计算出一个有效的 PoW ，然后才能施行攻击。PoW 的高昂计算成本和微不足道的验证成本，提供了一种应对区块转发 DoS 的天然方法。但这种特性无法延伸到 *未确认的* 交易的转发中。 + +通用的 DoS 保护措施并不能提供足够多的抗性，让一个节点的共识引擎可以放心地暴露在点对点网络中接收输入。攻击者可以尝试[制作一个计算任务极为繁重][max cpu tx]、但在共识上有效的交易，就像区块 #364292 处出现的这笔 1MB 的 “[巨型交易][megatx mempool space]” 一样，因为[签名验证中的哈希运算量呈平方级膨胀][rusty megatx]的问题，它需要反常的长时间来验证。攻击者也可以制作一个只有最后一个签名无效的交易，让节点在这笔交易的验证上花费大量的时间，直到最后才发现它是个垃圾。在这样浪费时间的时候，节点会推迟处理新的区块。你可以想象，某个矿工可以针对自己的对手发起这样的攻击，从而在下一个区块的挖掘中获得 “起跑优势”。 + +为避免处理计算量非常繁重的交易，Bitcoin Core 节点为每一笔交易施加了一个体积限制和签名操作（“sigop”）数量限制，这个限制比共识规则在区块层面实施的限制更为严格。Bitcoin Core 节点也对祖先交易包和后代交易包的体积施加限制、让区块模板的生产和驱逐算法更加高效，同时还会约束交易池插入和删除操作的[计算复杂度][se descendant limits]（更新一笔交易的祖先和后代集合就涉及这样的操作）。虽然这意味着一些合法的交易可能不会被接受和转发，但预计这样的交易是罕见的。 + +这些规则都是 “*交易转发规则*” 的案例 —— 节点在共识规则要求之上，对未确认的交易施加的额外验证规则。 + +默认情况下，Bitcoin Core 节点不会接受手续费率低于 1 聪/vb 的交易（“minrelaytxfee”），也不会在检查完这个要求之前验证任何签名，也不会在交易池接受一笔交易之前转发这笔交易。从某种意义上说，这个手续费率的规则，是在为网络验证和转发的工作设置一个 “价格” 的下限。不挖矿的节点不能收到手续费 —— 交易只会给确认它的矿工支付手续费。但是，手续费代表了攻击者的成本。如果有人要通过发送大量的交易来 “浪费” 网络的资源，那么 TA 最终将因为手续费而耗尽资金。 + +[Bitcoin Core 所实现的][bitcoin core rbf docs] “[手续费替换（Replace by Fee）][topic rbf]” 规则要求替换交易支付比跟它直接冲突的任一笔交易更高的手续费率，同时还要求它所支付的手续费总额也要比任一笔竞争交易更高。而且，额外支付的手续费除以替代交易的虚拟体积，必须至少是 1 聪/vb 。换句话说，无论原版交易和替代交易的手续费率的绝对水平如何，新交易都必须为自身所耗费的网络带宽支付至少 1 聪/vb 的 “新” 手续费。这个手续费规则的首要顾虑不是激励兼容性。相反，它是为重复的交易替换施加一个成本下限，以阻止浪费带宽的攻击，比如，每笔替换交易只多付 1 聪手续费的攻击。 + +完全验证区块和交易的节点，需要包括内存、运算力、网络带宽在内的资源。我们必须保证资源要求处于较低水平，从而让节点容易运行，并保护节点免受轰炸。通用的 DoS 保护措施是不够的，所以节点需要在验证未确认交易时，在共识规则之上应用交易转发规则。但是，因为这样的规则不是共识的一部分，两个节点可能会使用完全不同的规则，但依然能对链的最新状态达成共识。下周，我们会讨论作为个人选择的交易池规则。 + +[policy01]: /zh/newsletters/2023/05/17/#等待确认-1-我们为什么需要一个交易池 +[max cpu tx]: https://bitcointalk.org/?topic=140078 +[megatx mempool space]: https://mempool.space/tx/bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08 +[rusty megatx]: https://rusty.ozlabs.org/?p=522 +[bitcoin core rbf docs]: https://github.com/bitcoin/bitcoin/blob/v25.0/doc/policy/mempool-replacements.md +[pr 6722]: https://github.com/bitcoin/bitcoin/pull/6722 +[se descendant limits]: https://bitcoin.stackexchange.com/questions/118160/whats-the-governing-motivation-for-the-descendent-size-limit diff --git a/_includes/specials/policy/zh/06-consistency.md b/_includes/specials/policy/zh/06-consistency.md new file mode 100644 index 0000000000..6886e0fd17 --- /dev/null +++ b/_includes/specials/policy/zh/06-consistency.md @@ -0,0 +1,23 @@ +上周的文章介绍了 “规则（policy）”，这是一组在共识规则之外应用的交易验证规则。这些规则不适用于已入块的交易，因此即使节点的规则与其对等节点不同，它仍然可以保持一致性。就像节点操作员可以决定不参与交易中继一样，他们也可以自由选择任何规则，甚至不选择任何规则（将其节点暴露于 DoS 风险之下）。这意味着我们不能假设整个网络的交易池规则完全相同。然而，为了让用户的交易被矿工接收，愿意接纳这笔交易到自己的交易池的节点必须形成一条通向矿工的路径——节点之间的规则差异直接影响交易中继功能。 + +作为节点规则差异的极端例子，想象一种情况，每个节点操作员选择一个随机的`nVersion`，并仅接受具有该`nVersion`的交易。由于大多数点对点关系具有不兼容的规则，交易将无法传播到矿工。 + +另一方面，网络中相同的规则有助于聚合交易池的内容。具有一致交易池的网络可以最顺畅地中继交易，并且也非常适合[费用估算][policy04]和[致密区块中继][policy01]，正如之前的帖子中所提到的。 + +考虑到交易池验证的复杂性和规则不一致带来的困难，Bitcoin Core 在规则可配置性方面[一直保守][aj mempool consistency]。虽然用户可以轻松地调整 sigops 计数的方式(`bytespersigop`)以及嵌入在`OP_RETURN`输出中的数据量限制(`datacarriersize`和`datacarrier`)，但他们不能选择违背 400,000 个重量单位的最大标准重量，也不能应用别的一套与手续费相关的 RBF 规则，除非改变源代码。 + +Bitcoin Core 的一些规则配置选项存在是为了适应节点操作环境和运行节点的目的的差异。例如，矿工的硬件资源和保持交易池的目的与日常用户在笔记本电脑或树莓派上运行轻量级节点的目的不同。矿工可以选择增加他们的交易池容量(`maxmempool`)或过期时间线(`mempoolexpiry`)以在高峰期存储低费率交易，然后在流量减少时进行挖掘。提供可视化、存档和网络统计的网站可能运行多个节点，以收集尽可能多的数据，并显示默认的交易池行为。 + +在单个节点上，交易池容量的选择会影响费用提升工具的可用性。当交易池最低费率因交易提交超过默认交易池大小而上升时，从交易池的“底部”清除的交易和低于此费率的新交易不能再使用 [CPFP][topic cpfp]进行 费用提升。 + +另一方面，由于被清除的交易所用的输入不再为交易池中的任何交易所用，此前无法进行的 [RBF][topic rbf] 手续费追加也许又变成可能了。新交易实际上并没有替换这个节点的交易池中的任何内容，因此不需要考虑通常的 RBF 规则。但是，（因为具有更大的交易池容量而）没有逐出原版交易的节点将新交易视为拟议的替换，并要求其遵守 RBF 规则。如果被清除的交易没有发出 BIP125 可替换信号，或者新交易的费用即使费率很高但不符合 RBF 要求，矿工可能收不到他们的新交易。钱包必须小心处理被清除的交易：交易的输出不能被视为可以花费，但输入同样不能被重复使用。 + +乍一看，具有更大的交易池容量的节点似乎使 CPFP 更有用、使 RBF 更无用。然而，交易中继受紧急的网络行为的影响，可能不存在接受用户 CPFP 并将其转发到矿工的节点路径。节点通常只在接受交易并将其放入交易池后转发一次，并忽略已存在于其交易池中的交易的通知——存储更多交易的节点在这些交易被重新广播到它们时[充当黑洞][se maxmempool]。除非整个网络增加其交易池容量（这将是更改默认值的迹象），否则用户不应该指望从增加自己的交易池容量中获得太多好处。交易池默认设置的最低费率限制了在高流量时使用 CPFP 的效用。成功地将 CPFP 交易提交到自己增大了的交易池的用户可能无法注意到该交易未传播给其他人。 + +交易中继网络由动态加入和离开网络的个体节点组成，每个节点必须保护自己不被爆破。因此，交易中继只能尽力而为，我们不能保证每个节点都了解每个未确认的交易。同时，如果节点收敛在一组使得交易池尽可能同质化的中继规则上，那么比特币网络的表现就会最佳。下一篇文章将探讨采取了哪些规则来符合整个网络的利益。 + +[policy01]: /zh/newsletters/2023/05/17/#等待确认-1-我们为什么需要一个交易池 +[policy04]: /zh/newsletters/2023/06/07/#等待确认-4费率估算 +[aj mempool consistency]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021116.html +[se maxmempool]: https://bitcoin.stackexchange.com/questions/118137/how-does-it-contribute-to-the-bitcoin-network-when-i-run-a-node-with-a-bigger-th + diff --git a/_includes/specials/policy/zh/07-network-resources.md b/_includes/specials/policy/zh/07-network-resources.md new file mode 100644 index 0000000000..da357115f4 --- /dev/null +++ b/_includes/specials/policy/zh/07-network-resources.md @@ -0,0 +1,23 @@ +前一篇文章讨论了保护节点资源的问题。由于各个节点的资源不同，因此有些规则是可配置的。我们还提出了为什么最好统一规则的理由，但是哪些内容应该包含在这个规则里呢？本文将讨论网络范围的资源概念，这对于可扩展性、可升级性、启动和维护全节点的可访问性等方面至关重要。 + +正如在[之前的文章][policy01]中讨论的那样，比特币网络的许多意识形态目标体现在其分布式结构中。比特币的点对点性质允许网络规则从各个节点运营者所选择的粗略共识中产生，同时抑制在网络中获取不当影响力的企图。然后这些规则由每个节点通过对每个交易进行独立验证来强制执行。一个多样化和健康的节点群体需要保持节点运营成本低廉。不论什么项目，扩展到全球规模都很困难；如果还不想牺牲去中心化，就如同反绑一只手跟人打架。比特币项目通过严格保护其共享的网络资源（UTXO 集、区块链的数据足迹、处理数据所需的计算工作量，以及演化比特币协议的升级钩子）来尝试实现这种平衡。 + +我们无需重述整个区块体积战争来认识到限制区块链增长是必要的、我们以此来保证个人运行得起自己的节点。但是，区块链的增长在交易池规则层面上也会得到抑制：`minRelayTxFee` 的值为 1 sat/vbyte，表示了“[对超多副本的永久存储的无限需求][unbounded]”的最低成本。 + +最初，网络状态是通过保留所有仍有未花费输出的交易来跟踪的。随着 [UTXO 集][ultraprune]作为跟踪资金的手段引入，区块链的这一部分大大减少了。自那时以来，UTXO 集一直是一个核心数据结构。普遍情况下，UTXO 查找占据了节点所有内存访问的主要部分（在初始化区块下载（IBD）期间尤其如此）。Bitcoin Core 已经使用了一个[手动优化的 UTXO 缓存的数据结构][pooled resource]，但 UTXO 集的大小也决定了集合中有多少交易无法进入节点的缓存。较大的 UTXO 集意味着更多的缓存未命中，这会降低区块验证、IBD 和交易验证的速度。粉尘限制是一种限制 UTXO 创建的策略，特别是限制那些可能永远不会被花费的 UTXO，因为它们的金额[不足][topic uneconomical outputs]以支付它们的成本。即便如此，[规模达数千笔交易的“粉尘风暴”近在 2020 年仍发生过][lopp storms]。 + +当使用裸多签输出将数据发布到区块链上变得流行起来时，标准交易的定义被修改，允许使用单个 OP_RETURN 输出作为替代方案。人们意识到，无法阻止用户在区块链上发布数据，但至少这些数据不需要永远存在于 UTXO 集中。Bitcoin Core 0.13.0 引入了一个启动选项 `-permitbaremultisig`，用户可以切换以拒绝带有裸多签输出的未确认交易。 + +尽管共识规则允许自由格式的输出脚本，但 Bitcoin Core 节点只会中继少数一些被较好理解了的模式。这样更容易推理网络中的许多问题，包括验证成本和协议升级机制等。例如，输入脚本中包含了操作码、P2SH输入中的签名超过 15 个、P2WSH 输入的见证堆栈超过 100 个项，任何一个都将使该交易成为非标准交易（请查看此[交易池规则概述][instagibbs policy zoo]以获取更多规则示例及其动机）。 + +最后，比特币协议是一个不断发展的软件项目，需要不断演进以应对未来的挑战和用户需求。为此，有一些升级钩子被故意保留为共识有效但未使用，例如附录、taproot 叶子版本、见证版本、OP_SUCCESS 以及一些 no-op 操作码。然而，就像因为没有单点故障而阻碍了攻击一样，网络范围下的软件升级要涉及到协调数以万计的独立节点运营者。在其含义被明确定义前，节点不会转发使用了保留的升级钩子的交易。这种阻碍旨在防止应用程序各自独立地创建相互冲突的标准。这种冲突使得共识无法在采用一个应用程序的标准的同时避免另一个标准无效。 +此外，当共识真的发生变更时，没有立即升级的节点（因此不了解新的共识规则）无法“被骗”去接受一个现在无效的交易进入他们的交易池中。这种主动阻碍方式可以帮助节点具备向前兼容性，并使网络能够安全升级共识规则而不需要完全同步地进行软件升级。 + +我们可以看到，使用交易池规则来保护共享网络资源有助于保护网络的特性，并使未来协议的开发路径保持开放。与此同时，我们正在看到，如何在严格限制区块重量的情况下来扩展网络的矛盾正在推动着最佳实践、良好的技术设计和创新的采用：下周的文章将探讨交易池规则作为二层协议和智能合约系统的接口。 + +[policy01]: /zh/newsletters/2023/05/17/#等待确认-1-我们为什么需要一个交易池 +[unbounded]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html +[lopp storms]: https://blog.lopp.net/history-bitcoin-transaction-dust-spam-storms/ +[ultraprune]: https://github.com/bitcoin/bitcoin/pull/1677 +[pooled resource]: /zh/newsletters/2023/05/03/#bitcoin-core-25325 +[instagibbs policy zoo]: https://gist.github.com/instagibbs/ee32be0126ec132213205b25b80fb3e8 diff --git a/_includes/specials/policy/zh/08-interface.md b/_includes/specials/policy/zh/08-interface.md new file mode 100644 index 0000000000..b530db6750 --- /dev/null +++ b/_includes/specials/policy/zh/08-interface.md @@ -0,0 +1,29 @@ +到目前为止，我们已经探讨了关于去中心交易转发的[目的][policy01]和挑战，这些因素使得[节点本地][policy05]和[整个网络][policy07]都要使用比共识规则更严格的交易验证规则。因为 Bitcoin Core 软件的交易转发规则变更可能影响一个应用的交易是否能被转发，所以在提出之前，需要整个比特币社区的社会合作。类似地，使用了交易转发的应用和二层协议也必须跟交易池规则一起设计，以避免创建会被拒绝的交易。 + +合约式协议甚至更密切地依赖于跟打包优先级相关的交易池规则，因为其强制执行能力依赖于能够让交易快速得到确认。在对抗环境中，通过推迟交易的确认欺骗对手可能会有利可图，所以我们必须思考交易转发规则（作为一种接口）的 “怪癖” 如何可以用来攻击用户。 + +闪电网络的交易遵循前面的文章提到的标准化规则。举例来说，这种点对点协议在其 `open_chennel` 消息中指定了一个 `dust_limit_satoshis` 参数，用来明确粉尘输出的门槛。因为一笔包含了价值低于粉尘门槛的输出的交易不会被转发（因为节点的粉尘输出限制），这些支付会被认为是 “不可在链上强制执行的”，然后从承诺交易中剔除。 + +合约式协议经常使用带有时间锁的花费路径，让每一个参与者都有机会竞争将状态发布到链上。如果受影响的用户没有办法在这个时间窗口内让自己的交易得到确认，他们就有可能损失资金。这让手续费变得极为重要，因为它是提高确认优先级的首要机制，但也产生了更多难点。交易需要在未来的某个时候广播，或者受影响的用户只拥有轻节点，或者一些追加手续费的方法不可用，都导致[费率估计][policy04]很难。比如说，如果闪电通道的一个参与者离线了，另一方可能会单方面广播一笔预签名的承诺交易，来结算他们在链上共享的资金。没有任何一方可以独自花费他们共享的 UTXO，所以当其中一方离线的时候，就无法签名一笔[替换][topic rbf]交易来为承诺交易追加手续费。反过来，闪电通道的承诺交易可能会为通道参与者包含 “[锚点输出][topic anchor outputs]”，让他们可以在广播交易的时候附上[用于追加手续费的子交易][topic cpfp]。 + +但是，这些手续费追加方法都有局限性。如[之前的文章][policy06]文章所述，如果交易池的最低手续费率已经比承诺交易的手续费率要高，那么添加一个子交易是不会奏效的，所以闪电通道的用户依然必须使用稍微高估的费率来签名交易，以应对未来交易池的最低费率上涨的情形。此外，锚点输出的开发综合了一系列的考量，因为某一方可能从推迟交易确认中获利。举个例子，一方（Alice）可能会在离线之前广播自己的承诺交易。如果这笔承诺交易的费率太低、无法立即得到确认，而且 Alice 的对手（Bob）没有看到这笔交易，那么，他可能会很困惑 —— 当他想把自己的承诺交易广播出去的时候，会发现自己这笔交易无法转发。每一笔承诺交易都有两个锚点输出，所以任何一方都可以加速任意版本的承诺交易的确认，例如，Bob 可以盲目地尝试广播一笔基于 Alice 版本的承诺交易的 CPFP 子交易，即使他不确定 Alice 之前有没有广播过这个版本。每一个锚点输出都带有高于粉尘门槛的价值，而且在一段时间后就可被任何人领走，从而避免让 UTXO 集膨胀。 + +但是，保证每一方的 CPFP 能力，光凭给每一方一个锚点输出可不够。如[之前的文章][policy05]所述，Bitcoin Core 会限制可以附加到一笔未确认交易上的后代交易的数量和总体积，这是一种 DoS 保护措施。因为每一方都可以为共享的一笔交易附加后代，那么，其中一方就可以阻止别人的 CPFP 交易得到转发 —— TA 可以用自己的 CPFP 交易用尽这个可附加的容量。结果是，这些后代交易会让承诺交易以低优先级的状态 “钉死” 在交易池中。 + +为了缓解这种可能的攻击，闪电网络的锚点输出提议使用一个相对时间锁锁定了所有的非锚点输出，从而阻止它们在承诺交易未得确认的时候就被花费，而且 Bitcoin Core 的后代限制规则也[修改][topic cpfp carve out]了，允许附加额外的一个子交易，条件是这笔交易的体积较小而且没有其它祖先交易。这些变更的组合保证了一笔共享交易的两个参与者都可以在交易广播的时候调整交易费率，同时不会显著增加交易转发的 DoS 攻击界面。 + +通过耗尽后代交易的容量来阻止 CPFP，是 “[钉死攻击][topic transaction pinning]” 的一个例子。钉死攻击利用交易池规则的限制来阻止激励兼容的交易进入交易池以及得到确认。在这个案例中，交易池的规则在 [DoS 抗性][policy05]和[激励兼容性][policy02]之间做了取舍。你必须取舍 —— 节点需要考虑追加手续费的机制，但无法处理无限数量的交易。CPFP 的 carve out 为一个具体的应用场景细化了这种取舍。 + +除了耗尽后代交易的容量限制，还有别的钉死攻击[可以同时阻止 RBF 的使用][full rbf pinning]、或让 RBF [贵得离谱][rbf ml]、或者利用 RBF 来推迟一笔 ANYONECANPAY 交易的确认。钉死攻击仅在多方合作创建一笔交易的时候，或者一个不受信任的参与者可以干预交易的时候是个问题。尽量不将交易暴露给不受信任的参与者，总的来说是一种避免钉死的好方法。 + +这些摩擦点不仅显示了交易池作为比特币生态系统中的应用和协议的接口的重要性，还指明了需要提升的地方。下周，我们会讨论交易池规则的变更提议以及悬而未决的问题。 + +[full rbf pinning]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html +[rbf ml]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html +[n25038 notes]: https://bitcoincore.reviews/25038 +[policy01]: /zh/newsletters/2023/05/17/#等待确认-1-我们为什么需要一个交易池 +[policy02]: /zh/newsletters/2023/05/24/#等待确认-2激励 +[policy04]: /zh/newsletters/2023/06/07/#等待确认-4费率估算 +[policy05]: /zh/newsletters/2023/06/14/#等待确认-5用于保护节点资源的规则 +[policy06]: /zh/newsletters/2023/06/21/#等待确认-6规则一致性 +[policy07]: /zh/newsletters/2023/06/28/#等待确认-7网络资源 diff --git a/_includes/specials/policy/zh/09-proposals.md b/_includes/specials/policy/zh/09-proposals.md new file mode 100644 index 0000000000..f2bfa18528 --- /dev/null +++ b/_includes/specials/policy/zh/09-proposals.md @@ -0,0 +1,21 @@ +[上周的文章][policy08]介绍了[锚点输出][topic anchor outputs]和 [CPFP 分拆][topic cpfp carve out]，以确保通道双方任意一方都可以在不需要协作的情况下为他们共同的承诺交易追加手续费。这种方法仍然有一些不足之处：通道资金被绑定以创建锚点输出；承诺交易费率通常高于交易池最低费率以确保其能够被尽快打包。而且，CPFP 分拆只允许一个额外的后代。锚点输出也不能为三方或更多方共享的交易如 [coinjoins][topic coinjoin] 或多方合作协议提供相同的手续费提升能力。本篇文章探讨了目前为解决这些和其他限制所做的努力。 + +[包中继][topic package relay]包括点对点协议和规则变更，以使得交易组的传输和验证得以实现。这将允许承诺交易即使未达到交易池的最低费率，也可通过子交易进行费用提升。此外，*包 RBF* 可让追加手续费的子交易[替换][topic rbf]掉与其父交易发生冲突的交易。包中继旨在消除基础协议层的一般限制。然而，由于它在共享交易费用提高方面的实用性，它也催生了一些旨在消除特定情况下交易[钉死攻击][topic transaction pinning]的尝试和努力。例如，包 RBF 允许承诺交易在广播其各自的费用提升子交易时互相替换，从而消除了每个承诺交易上需要多个锚点输出的需要。 + +需要注意的是，现有的 RBF 规则要求替换交易支付的绝对费用高于所有待替换交易支付的累计费用。此规则有助于防止通过重复替换来发起的 DoS，但允许恶意用户通过附加高费用但低费率的子交易来增加替换其交易的成本。这种通过阻止善意用户发起高手续费率的替代交易包、从而阻碍交易被挖出的不公平情形，通常被称为，“针对规则 3 的交易钉死”。 + +开发人员还提出了完全不同的给预签名交易增加费用的方式。例如，使用 `SIGHASH_ANYONECANPAY | SIGHASH_ALL` 签署交易输入，可以允许交易广播者通过在交易中附加额外的输入（而不改变输出）来提供费用。然而，由于 RBF 没有任何规则要求替代交易具有更高的“挖矿分数”（即会更快地入选一个区块），攻击者可以通过创建来自低手续费率祖先交易的替换交易，来钉死这些类型的交易。难以准确评估交易和交易包“挖矿分数”的原因在于，现有的祖先和后代限制不能限定该计算的计算复杂性。任何关联的交易都会影响交易被挑选到区块中的顺序。一个完全连接的组合（称为_集群_）可以是给定的当前祖先和后代限制的任何大小。 + +解决一些交易池不足和 RBF 钉死攻击的长期解决方案是[重构交易池数据结构，以跟踪集群][mempool clustering]而不仅仅是祖先和子孙集合。这些集群的大小将受到限制。限制集群的大小会限制用户使用未确认的UTXO的方式，但可以使用基于祖先分数的挖矿算法快速线性化整个交易池，极快地构建区块模板，并添加条件：要求替换交易需要具有比待替换交易更高的挖矿分数。 + +即便如此，可能没有一套规则能够满足交易中继的广泛需求和期望。例如，尽管批量付款交易的收款方受益于能够花费未确认的输出，但相对宽松的后代限制会给共享交易的绝对费用留下包 RBF 钉死攻击的空间。为此，针对[v3 交易中继规则][topic v3 transaction relay]的一个提议被制定出来，以允许合约协议选择更严格的一套包限制要求。V3交易仅允许大小为二的包（父级与子级），并限制子交易的重量。这些限制将减轻通过绝对费用钉死 RBF 的攻击，并为集群交易池提供一些好处，而无需重构交易池。 + +[临时锚点][topic ephemeral anchors]建立在v3交易和数据包中继属性之上，以进一步改进锚点输出。它使得零费用v3交易所属的锚点输出免于[粉尘限制][topic uneconomical outputs]，但前提是该锚点输出被费用提升的子级花费。由于零费用交易必须由一个子交易进行费用提升（否则矿工不会被激励将其包含在区块中），因此此锚点输出是“临时的”，不会成为 UTXO 集的一部分。临时锚点提案隐含地阻止了在未确认时花费非锚点输出，而不需要设立 `1 OP_CSV` 时间锁，因为唯一允许的子级必须花费锚点输出。这也使得使用 [CPFP][topic cpfp] 作为通道关闭交易的费用提供机制的 [LN symmetry][topic eltoo] 协议成为可能。它还使得这种机制可用于多于两个参与者共享的交易。开发者一直在 [signet][topic signet] 上使用 [bitcoin-inquisition][bitcoin inquisition repo] 来部署临时锚点以及各种软分叉提议，以构建和测试这些多层次的变化。 + +在本文中提到的钉死问题，以及其他问题，在去年引起了[许多讨论和关于改进 RBF 规则][2022 rbf]的建议，这些讨论和建议的平台包括邮件列表、PR、社交媒体和面对面会议。开发人员提出并实施了各种解决方案，从小的修改到完全改版的方案都有。`-mempoolfullrbf` 选项旨在解决钉死问题和 BIP125 实现中的差异，突显了交易中继规则中合作的重要性和困难。虽然已经做出了真正的努力并使用了常规的方式让社区参与进来，包括提前一年开始 bitcoin-dev mailing 对话，但很明显，现有的沟通和决策方法并没有产生预期的结果，需要改进。 + +去中心化的决策过程具有挑战性，但是它对于支持使用比特币交易中继网络的协议和应用程序的多样化生态系统来说是必要的。下周将是我们系列文章的最后一篇，我们希望鼓励我们的读者参与并改进这个过程。 + +[mempool clustering]: https://github.com/bitcoin/bitcoin/issues/27677 +[policy08]: /zh/newsletters/2023/07/05/#等待确认-8交易池规则是个接口 +[2022 rbf]: /zh/newsletters/2022/12/21/#rbf diff --git a/_includes/specials/policy/zh/10-get-involved.md b/_includes/specials/policy/zh/10-get-involved.md new file mode 100644 index 0000000000..917d029b9b --- /dev/null +++ b/_includes/specials/policy/zh/10-get-involved.md @@ -0,0 +1,17 @@ +我们希望这个系列可以让读者更好地了解在等待确认时发生了什么。我们从讨论比特币的一些意识形态价值开始，将其[转化][policy01]为比特币的结构和设计目标。对等网络的分布式结构提供了比典型的集中式模型更高的抗审查性和隐私保护。一个开放的交易中继网络有助于每个人知晓即将进入区块的交易。这提高了[区块中继的效率][policy01]，使得作为一个新矿工加入比特币网络更可行，同时也创造了一个[对区块空间的公开拍卖][policy02]。作为一个由许多独立的、匿名的实体运行节点组成的理想网络，节点软件必须被设计成[可防 DoS 攻击][policy05]并尽量减少运营成本。 + +手续费在比特币网络中扮演着重要的角色，作为解决区块空间竞争的“公平”方式。在交易池中，允许交易替换、可以感知交易包的选择和驱逐算法，使用[激励兼容性][policy02]来衡量存储一个交易的效用，并为用户启用 [RBF][topic rbf] 和 [CPFP][topic cpfp] 作为追加手续费的机制。这些交易池策略的组合、能[经济地构造交易][policy03]的钱包和良好的[费率估计][policy04]，可以为区块空间创造一个高效的市场，从而使每个人受益。 + +个别节点还会执行 _交易中继策略_，以[保护自己避免资源耗尽][policy05]和[表达个人偏好][policy06]。在[网络范围内][policy07]，标准规则和其他策略保护着可扩展性、节点运行的可访问性以及更新共识规则的能力等至关重要的资源。由于网络中的绝大多数都遵守这些策略，它们是比特币应用程序和 L2 协议所依赖的[接口][policy08]的重要组成部分。然而，它们并不完美。我们描述了几个[与交易池策略相关的提案][policy09]，这些提案致力于解决广泛的局限性以及特定用例，比如[对 L2 结算交易的钉死攻击][policy08]。 + +我们还强调，网络策略的持续演进需要协议、应用和钱包开发者之间的合作。随着比特币生态系统在软件、使用案例和用户方面的增长，去中心化的决策过程变得更加必要，但也更具挑战性。即使比特币的采用率增长，系统也是由利益相关者的关注和努力而形成的——没有一家公司负责收集客户反馈并雇佣工程师来构建新的协议功能或删除未使用的功能。对希望成为网络的粗略共识的一部分的利益相关者而言，有多种参与途径：自主了解情况、提出疑问和问题、参与网络设计，甚至贡献改进的实现。下次当你的交易确认时间过长时，就知道该怎么做了！ + +[policy01]: /zh/newsletters/2023/05/17/#等待确认-1-我们为什么需要一个交易池 +[policy02]: /zh/newsletters/2023/05/24/#等待确认-2激励 +[policy03]: /zh/newsletters/2023/05/31/#等待确认3竞价区块空间 +[policy04]: /zh/newsletters/2023/06/07/#等待确认-4费率估算 +[policy05]: /zh/newsletters/2023/06/14/#等待确认-5用于保护节点资源的规则 +[policy06]: /zh/newsletters/2023/06/21/#等待确认-6规则一致性 +[policy07]: /zh/newsletters/2023/06/28/#等待确认-7网络资源 +[policy08]: /zh/newsletters/2023/07/05/#等待确认-8交易池规则是个接口 +[policy09]: /zh/newsletters/2023/07/12/#等待确认-9规则提案 diff --git a/_includes/specials/taproot/en/01-single-sig.md b/_includes/specials/taproot/en/01-single-sig.md index 931c29afc2..609dbb6c10 100644 --- a/_includes/specials/taproot/en/01-single-sig.md +++ b/_includes/specials/taproot/en/01-single-sig.md @@ -32,11 +32,11 @@ for single-sigs, both for wallet users and for the network as a whole. multisignature], various clever wallet backup recovery schemes, or a hundred other pioneering developments. - Using P2TR for single-sig now also allows your wallet to upgrade to - multisignatures, tapscripts, LN support, or other features later on - without affecting the privacy of your existing users. It won't - matter whether a UTXO was received to an old version or a new - version of your software---both UTXOs will look the same onchain. + Using P2TR for single-sig now also allows your wallet to upgrade to + multisignatures, tapscripts, LN support, or other features later on + without affecting the privacy of your existing users. It won't + matter whether a UTXO was received to an old version or a new + version of your software---both UTXOs will look the same onchain. - **More convenient for hardware signing devices:** since the rediscovery of the [fee overpayment attack][news101 fee overpayment diff --git a/_includes/specials/taproot/en/03-p2wpkh-to-p2tr.md b/_includes/specials/taproot/en/03-p2wpkh-to-p2tr.md index 01063c5078..67b66b69e6 100644 --- a/_includes/specials/taproot/en/03-p2wpkh-to-p2tr.md +++ b/_includes/specials/taproot/en/03-p2wpkh-to-p2tr.md @@ -76,38 +76,46 @@ pages of the Bitcoin Wiki so other developers can learn from your code. by both wallets and still in common use among most other wallets. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Script managementInitial backupIntroducing new scriptsScanning (bandwidth/CPU cost)Deprecating scripts
    Implicit scripts (e.g. [BIP44][])Seed wordsAutomatic (no user action required)Must scan for all supported scripts, O(n)No way to warn users that they're using unsupported scripts
    Explicit scripts (versioned seeds)Seed words (includes version bits)User must backup new seed; funds are either partitioned into two - separate wallets or user must send funds from the old wallet to the newOnly scans for a single script template, O(1)Users warned about unsupported scripts
    Explicit scripts ([descriptors][topic descriptors])Seed words and descriptorUser must back up the new descriptorOnly scans for the script templates that were actually used, O(n); n=1 for a new walletUsers warned about unsupported scripts
    Script managementInitial backupIntroducing new scriptsScanning (bandwidth/CPU cost)Deprecating scripts
    + + Implicit scripts (e.g. [BIP44][]) + + Seed wordsAutomatic (no user action required)Must scan for all supported scripts, O(n)No way to warn users that they're using unsupported scripts
    Explicit scripts (versioned seeds)Seed words (includes version bits)User must backup new seed; funds are either partitioned into two + separate wallets or user must send funds from the old wallet to the newOnly scans for a single script template, O(1)Users warned about unsupported scripts
    + + Explicit scripts ([descriptors][topic descriptors]) + + Seed words and descriptorUser must back up the new descriptorOnly scans for the script templates that were actually used, O(n); n=1 for a new walletUsers warned about unsupported scripts
    {% include linkers/issues.md issues="" %} diff --git a/_includes/specials/taproot/en/04-why-wait.md b/_includes/specials/taproot/en/04-why-wait.md index d526f99a09..d294f739fd 100644 --- a/_includes/specials/taproot/en/04-why-wait.md +++ b/_includes/specials/taproot/en/04-why-wait.md @@ -1,4 +1,5 @@ {% capture /dev/null %} + {% assign ante_trb = "709,631" %} + {% assign safe_trb = "709,776" %} {% endcapture %} diff --git a/_includes/specials/taproot/en/05-taproot-notebooks.md b/_includes/specials/taproot/en/05-taproot-notebooks.md index 225f105138..7c8ad1bbab 100644 --- a/_includes/specials/taproot/en/05-taproot-notebooks.md +++ b/_includes/specials/taproot/en/05-taproot-notebooks.md @@ -51,7 +51,7 @@ taken the time to learn from them earlier. {% include references.md %} [taproot-workshop]: https://github.com/bitcoinops/taproot-workshop -[workshops]: /en/schorr-taproot-workshop/ +[workshops]: /en/schnorr-taproot-workshop/ [notebooks #168]: https://github.com/bitcoinops/taproot-workshop/pull/168 [mouton tweet]: https://twitter.com/ElleMouton/status/1418108253096095745 {% endauto_anchor %} diff --git a/_includes/specials/taproot/en/06-multisignatures.md b/_includes/specials/taproot/en/06-multisignatures.md index ba03993148..b9ea9c9f93 100644 --- a/_includes/specials/taproot/en/06-multisignatures.md +++ b/_includes/specials/taproot/en/06-multisignatures.md @@ -1,8 +1,8 @@ {% comment %}{% endcomment %} In the 1,000 blocks received prior to this writing, 11% of all transaction inputs contained a multisig opcode. Two of the largest and diff --git a/_includes/specials/taproot/en/12-backups.md b/_includes/specials/taproot/en/12-backups.md index bb74aac12f..e64ed1d00f 100644 --- a/_includes/specials/taproot/en/12-backups.md +++ b/_includes/specials/taproot/en/12-backups.md @@ -13,9 +13,9 @@ converting to taproot. This makes taproot great for upgrading your security from a single-signer wallet to a multi-signer policy. - We expect future techniques for [threshold signatures][topic - threshold signature] to further improve 2-of-3 and other k-of-n - cases. + We expect future techniques for [threshold signatures][topic + threshold signature] to further improve 2-of-3 and other k-of-n + cases. - **Degrading multisignatures:** one of the exercises in the [Optech Taproot Workshop][taproot workshop] allows you to experiment with @@ -26,17 +26,17 @@ converting to taproot. the time parameters and the key settings provides you with a flexible and powerful backup construct. - For example, imagine you can normally spend using a combination of - your laptop, mobile phone, and a hardware signing device. If one of - those becomes unavailable, you can wait a month to be able to spend - with the remaining two devices. If two devices become unavailable, - you can spend using just one after six months. + For example, imagine you can normally spend using a combination of + your laptop, mobile phone, and a hardware signing device. If one of + those becomes unavailable, you can wait a month to be able to spend + with the remaining two devices. If two devices become unavailable, + you can spend using just one after six months. - In the normal case of using all three devices, your onchain script - is maximally efficient and private. In the other cases, it's a bit - less efficient but may still be reasonably private (your script and - its tree depth will look similar to the scripts and depths used in - many other contracts). + In the normal case of using all three devices, your onchain script + is maximally efficient and private. In the other cases, it's a bit + less efficient but may still be reasonably private (your script and + its tree depth will look similar to the scripts and depths used in + many other contracts). - **Social recovery for backups and security:** the example above is great at protecting you if one of your devices gets stolen by an @@ -44,14 +44,14 @@ converting to taproot. if you frequently use your wallet, do you really want to wait even a month before you can start spending again after losing a device? - Taproot makes it easy, cheap, and private to add a social element to - your backups. In addition to the scripts in the previous example, - you can also allow immediate spending of your bitcoins with two of - your devices plus signatures from two of your friends or family - members. Or immediate spending with only a single one of your keys - plus signatures from five people you trust. (A similar non-social - version of this would simply be using extra devices or seed phrases - you have stored in secure locations.) + Taproot makes it easy, cheap, and private to add a social element to + your backups. In addition to the scripts in the previous example, + you can also allow immediate spending of your bitcoins with two of + your devices plus signatures from two of your friends or family + members. Or immediate spending with only a single one of your keys + plus signatures from five people you trust. (A similar non-social + version of this would simply be using extra devices or seed phrases + you have stored in secure locations.) - **Combining time and social thresholds for inheritance:** combining the techniques above, you can allow someone or a group of people to @@ -66,13 +66,13 @@ converting to taproot. for them to learn your wallet's extended public key (xpub) after your death. - Please note that making it possible for your heirs' to spend your - bitcoins doesn't mean that they'll be able to spend those coins - legally. We recommend that anyone planning to pass on Bitcoins read - *Cryptoasset Inheritance Planning* by Pamela Morgan ([physical book - and DRM'd ebook][cip amazon] or [DRM-free ebook][cip aantonop]) and - use its information to discuss details with a local expert in estate - planning. + Please note that making it possible for your heirs' to spend your + bitcoins doesn't mean that they'll be able to spend those coins + legally. We recommend that anyone planning to pass on Bitcoins read + *Cryptoasset Inheritance Planning* by Pamela Morgan ([physical book + and DRM'd ebook][cip amazon] or [DRM-free ebook][cip aantonop]) and + use its information to discuss details with a local expert in estate + planning. - **Compromise detection:** an idea [proposed][tree signatures] prior to the invention of taproot is to put a key controlling some amount of @@ -82,16 +82,16 @@ converting to taproot. the immediate gain rather than wait to use their illicit access in a long-term attack that might cause you more overall harm. - A problem with this approach is that you want to make the amount of - bitcoin offered large enough to entice the attacker but you don't - want to put large amounts of bitcoin on every one of your - devices---you'd prefer to offer only one large bounty. However, if - you were to put the same key on every device, the attacker - transaction spending the bitcoin wouldn't reveal which device was - compromised. Taproot makes it easy to put a different key with a - different scriptpath on every device. Any one of those keys - will be able to spend all the funds controlled by that address, but - it can also uniquely identify to you which device was compromised. + A problem with this approach is that you want to make the amount of + bitcoin offered large enough to entice the attacker but you don't + want to put large amounts of bitcoin on every one of your + devices---you'd prefer to offer only one large bounty. However, if + you were to put the same key on every device, the attacker + transaction spending the bitcoin wouldn't reveal which device was + compromised. Taproot makes it easy to put a different key with a + different scriptpath on every device. Any one of those keys + will be able to spend all the funds controlled by that address, but + it can also uniquely identify to you which device was compromised. [taproot series vaults]: /en/preparing-for-taproot/#vaults-with-taproot [cip amazon]: https://amazon.com/Cryptoasset-Inheritance-Planning-Simple-Owners/dp/1947910116 diff --git a/_includes/specials/taproot/en/15-output-linking.md b/_includes/specials/taproot/en/15-output-linking.md index 95cb44f60e..7b47951254 100644 --- a/_includes/specials/taproot/en/15-output-linking.md +++ b/_includes/specials/taproot/en/15-output-linking.md @@ -50,9 +50,10 @@ a few additional counterpoints to consider: also get all of taproot's other amazing privacy benefits. {% include linkers/issues.md issues="12119" %} + {% endauto_anchor %} + [p4tr benefits]: /en/preparing-for-taproot/#multisignature-overview [p4tr safety]: /en/preparing-for-taproot/#why-are-we-waiting [coindesk experts]: https://www.coindesk.com/tech/2020/12/01/privacy-concerns-over-bitcoin-upgrade-taproot-are-a-non-issue-experts-say/ -[compat bcc]: /en/compatibility/bitcoin-core/ [news155 bcc22154]: /en/newsletters/2021/06/30/#bitcoin-core-22154 diff --git a/_includes/specials/taproot/en/17-keypath-universality.md b/_includes/specials/taproot/en/17-keypath-universality.md index 7c835949bd..d8d6a3f4d4 100644 --- a/_includes/specials/taproot/en/17-keypath-universality.md +++ b/_includes/specials/taproot/en/17-keypath-universality.md @@ -22,18 +22,18 @@ of being focused on timelocks: suggest that more than a signature is required, but a few criticisms have been raised: - - Someone truly desperate to spend their timelocked bitcoins can take - out a loan, perhaps secured by some other asset. This undermines - the utility of this self contract. + - Someone truly desperate to spend their timelocked bitcoins can take + out a loan, perhaps secured by some other asset. This undermines + the utility of this self contract. - - In addition to the consensus-enforced scriptpath timelock, the user - can allow keypath spending between their key and the key of a - third party who only signs when the timelock has expired. This is - not only more efficient, but it also allows implementing a more - flexible spending policy such as providing the user the ability to - sell any forkcoins they receive or to work with a third party who - will allow them to spend early in case of major life changes or - price appreciations. + - In addition to the consensus-enforced scriptpath timelock, the user + can allow keypath spending between their key and the key of a + third party who only signs when the timelock has expired. This is + not only more efficient, but it also allows implementing a more + flexible spending policy such as providing the user the ability to + sell any forkcoins they receive or to work with a third party who + will allow them to spend early in case of major life changes or + price appreciations. - **Vaults:** as mentioned in Antoine Poinsot's [column][p4tr vaults] here a few weeks ago, [vaults][topic vaults] also use timelocks @@ -68,6 +68,6 @@ contract even when it doesn't seem like an option. {% endauto_anchor %} [p4tr vaults]: /en/preparing-for-taproot/#vaults-with-taproot -[maxwell taproot]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html +[maxwell taproot]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html [irc log1]: https://gnusha.org/taproot-bip-review/2020-02-09.log [irc log2]: https://gnusha.org/taproot-bip-review/2020-02-10.log diff --git a/_includes/specials/taproot/en/18-trivia.md b/_includes/specials/taproot/en/18-trivia.md index b575da062b..06536977d3 100644 --- a/_includes/specials/taproot/en/18-trivia.md +++ b/_includes/specials/taproot/en/18-trivia.md @@ -7,33 +7,33 @@ as the carrot, the taproot is a storage organ so well developed that it has been cultivated as a vegetable." - How does this apply to Bitcoin? - - - "I always assumed the origin of the name was 'taps into the Merkle - root', but I don't actually know what Gregory Maxwell's thinking - was." ---Pieter Wuille ([source][wuille taproot name]) - - - "I originally had to look the word up; but I took it as the key - path being the 'taproot' because that's the tasty one that you - make carrot soup out of, and the merklized scripts would be the - other lesser roots that you hope to ignore." ---Anthony Towns - ([source][towns taproot name]) - - - "The name originated in a visualization of a tree with a thick - central truck like a dandelion taproot---the technique is mostly - useful because of the assumption that there is one high - probability path and the rest is fuzzy stragglers, and I thought - it was a good one because of the punny fact that it verifies - script-path spends by tapping into the hidden commitment in the - root. - - [...] Alas, calling the hash tree with the sorted interior nodes a - 'myrtle tree' didn't catch on. (Myrtle tree because the set of - policies with an equal hash root are ones whos ordering differs by - a permutation which can be defined by a t-function, and Myrtle is - the family which includes melaleuca, the tea-tree, and it sounds - like 'merkle'. :p )" ---Gregory Maxwell ([source][maxwell taproot - name]) + How does this apply to Bitcoin? + + - "I always assumed the origin of the name was 'taps into the Merkle + root', but I don't actually know what Gregory Maxwell's thinking + was." ---Pieter Wuille ([source][wuille taproot name]) + + - "I originally had to look the word up; but I took it as the key + path being the 'taproot' because that's the tasty one that you + make carrot soup out of, and the merklized scripts would be the + other lesser roots that you hope to ignore." ---Anthony Towns + ([source][towns taproot name]) + + - "The name originated in a visualization of a tree with a thick + central truck like a dandelion taproot---the technique is mostly + useful because of the assumption that there is one high + probability path and the rest is fuzzy stragglers, and I thought + it was a good one because of the punny fact that it verifies + script-path spends by tapping into the hidden commitment in the + root. + + [...] Alas, calling the hash tree with the sorted interior nodes a + 'myrtle tree' didn't catch on. (Myrtle tree because the set of + policies with an equal hash root are ones whos ordering differs by + a permutation which can be defined by a t-function, and Myrtle is + the family which includes melaleuca, the tea-tree, and it sounds + like 'merkle'. :p )" ---Gregory Maxwell ([source][maxwell taproot + name]) - **Schnorr signatures predate ECDSA:** we talk about [schnorr signatures][topic schnorr signatures] as an upgrade on Bitcoin's original ECDSA @@ -63,6 +63,7 @@ [EdDSA][], is now the basis of several standards. Although not used in Bitcoin consensus, references to it in the context of other systems can be found in many of the Bitcoin repositories tracked by Optech. + - **Pay to contract:** Ilja Gerhardt and Timo Hanke created a @@ -73,20 +74,21 @@ attacks, can verify the commitment---but to anyone else the payment looks like any other Bitcoin payment. - A slight improvement to this *pay-to-contract* (P2C) protocol was - included in the [2014 paper][sidechains.pdf] about - [sidechains][topic sidechains], where the commitment also includes the - original public key to pay. Taproot uses this same construction - but, instead of committing to the terms of an offchain contract, the - output creator commits to consensus-enforced terms chosen by the - receiver for how they can spend the received bitcoins onchain. + A slight improvement to this *pay-to-contract* (P2C) protocol was + included in the [2014 paper][sidechains.pdf] about + [sidechains][topic sidechains], where the commitment also includes the + original public key to pay. Taproot uses this same construction + but, instead of committing to the terms of an offchain contract, the + output creator commits to consensus-enforced terms chosen by the + receiver for how they can spend the received bitcoins onchain. - **A Good Morning:** the idea to use P2C so that payments to scripts can look identical onchain to paying public keys was invented in Los Altos, California, at the diner "A Good Morning" on 22 January 2018. Pieter Wuille writes that the idea was developed by Andrew Poelstra and Gregory Maxwell "while I briefly left the table... !$%@" [sic]. + diff --git a/_includes/specials/taproot/en/19-future.md b/_includes/specials/taproot/en/19-future.md index 0c8e588eff..1ba8a4600f 100644 --- a/_includes/specials/taproot/en/19-future.md +++ b/_includes/specials/taproot/en/19-future.md @@ -28,24 +28,24 @@ expressed the desire to build on top of taproot. either commit to the txids in the prevouts or don't commit to the prevouts at all. - That's a problem for multiuser protocols that don't want to use a - precise pre-arranged series of transactions. If any user can skip a - particular transaction, or change any detail of any transaction - besides its witness data, that will change any later transaction's - txid. Changing the txid invalidates any signatures previously - created for later transactions. This forces offchain protocols to - implement mechanisms (such as LN-penalty) that penalize any user who - submits an older transaction. - - [SIGHASH_ANYPREVOUT][topic sighash_anyprevout] can eliminate this - problem by allowing a signature to skip committing to the prevout - txid. Depending on other flags used, it will still commit to other - details about the prevout and the transaction (such as amount and - script), but it will no longer matter what txid is used for the - previous transaction. This will make it possible to implement both the - [eltoo][topic eltoo] layer for LN and - [improvements][p4tr vaults] in [vaults][topic vaults] and other - contract protocols. + That's a problem for multiuser protocols that don't want to use a + precise pre-arranged series of transactions. If any user can skip a + particular transaction, or change any detail of any transaction + besides its witness data, that will change any later transaction's + txid. Changing the txid invalidates any signatures previously + created for later transactions. This forces offchain protocols to + implement mechanisms (such as LN-penalty) that penalize any user who + submits an older transaction. + + [SIGHASH_ANYPREVOUT][topic sighash_anyprevout] can eliminate this + problem by allowing a signature to skip committing to the prevout + txid. Depending on other flags used, it will still commit to other + details about the prevout and the transaction (such as amount and + script), but it will no longer matter what txid is used for the + previous transaction. This will make it possible to implement both the + [eltoo][topic eltoo] layer for LN and + [improvements][p4tr vaults] in [vaults][topic vaults] and other + contract protocols. - **Delegation and generalization:** after you create a script (taproot or otherwise), there's [almost][rubin delegation] no way for you to @@ -57,34 +57,34 @@ expressed the desire to build on top of taproot. enhancing taproot by generalizing it and providing [signer delegation][topic signer delegation] have been proposed: - - **Graftroot:** [proposed][maxwell graftroot] shortly after the - introduction of the idea for taproot, graftroot would give an - extra feature to anyone capable of making a taproot keypath - spend. Instead of directly spending their funds, the keypath - signers could instead sign a script that described new conditions - under which the funds could be spent, delegating spending - authority to anyone capable of satisfying the script. The - signature, the script, and whatever data was needed to satisfy the - script would be provided in the spending transaction. The keypath - signers could delegate to an unlimited number of scripts in this - way without creating any onchain data until an actual spend - occurred. - - - **Generalized taproot (g'root):** a few months later, Anthony - Towns [suggested][towns groot] a way to use public key points to - commit to multiple different spending conditions without - necessarily using a [MAST][topic mast]-like construction. This - *generalized taproot* (g'root) construction is "potentially more - efficient for cases [where the taproot assumption doesn't - hold][p4tr taproot assumption]". It also "[offers][sipa groot - agg] an easy way to construct a softfork-safe cross-input - aggregation system". - - - **Entroot:** a [more recent][wuille entroot] synthesis of - graftroot and g'root that simplifies many cases and makes them more - bandwidth efficient. It can support signer delegation from anyone - able to satisfy any of the entroot branches, not just those able - to create a top-level keypath spend. + - **Graftroot:** [proposed][maxwell graftroot] shortly after the + introduction of the idea for taproot, graftroot would give an + extra feature to anyone capable of making a taproot keypath + spend. Instead of directly spending their funds, the keypath + signers could instead sign a script that described new conditions + under which the funds could be spent, delegating spending + authority to anyone capable of satisfying the script. The + signature, the script, and whatever data was needed to satisfy the + script would be provided in the spending transaction. The keypath + signers could delegate to an unlimited number of scripts in this + way without creating any onchain data until an actual spend + occurred. + + - **Generalized taproot (g'root):** a few months later, Anthony + Towns [suggested][towns groot] a way to use public key points to + commit to multiple different spending conditions without + necessarily using a [MAST][topic mast]-like construction. This + *generalized taproot* (g'root) construction is "potentially more + efficient for cases [where the taproot assumption doesn't + hold][p4tr taproot assumption]". It also "[offers][sipa groot + agg] an easy way to construct a softfork-safe cross-input + aggregation system". + + - **Entroot:** a [more recent][wuille entroot] synthesis of + graftroot and g'root that simplifies many cases and makes them more + bandwidth efficient. It can support signer delegation from anyone + able to satisfy any of the entroot branches, not just those able + to create a top-level keypath spend. - **New and old opcodes:** the taproot soft fork includes support for [tapscript][topic tapscript] which provides an improved way to add new @@ -93,26 +93,26 @@ expressed the desire to build on top of taproot. opcodes are designed to be replaced with opcodes that don't always return success. Some proposed new opcodes include: - - **Restore old opcodes:** a number of opcodes for math and string - operations were disabled in 2010 due to concerns about security - vulnerabilities. Many developers would like to see these opcodes - re-enabled after a security review, and (in some cases) perhaps - extended to handle larger numbers. - - - **OP_CAT:** one of the previously-disabled opcodes that deserves - special mention is [OP_CAT][op_cat subtopic], which researchers - have since discovered can [enable][keytrees] all [sorts][rubin - pqc] of [interesting][poelstra cat] behavior on Bitcoin by itself, - or which can be [combined][topic op_checksigfromstack] with other - new opcodes in interesting ways. - - - **OP_TAPLEAF_UPDATE_VERIFY:** as described in [Newsletter #166][news166 tluv], - an `OP_TLUV` opcode can enable [covenants][topic covenants] in a way that's - particularly efficient and powerful when used with taproot's - keypath and scriptpath capabilities. This can be used to - implement [joinpools][topic joinpools], [vaults][topic vaults], and other security - and privacy improvements. It may also combine well with - [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify]. + - **Restore old opcodes:** a number of opcodes for math and string + operations were disabled in 2010 due to concerns about security + vulnerabilities. Many developers would like to see these opcodes + re-enabled after a security review, and (in some cases) perhaps + extended to handle larger numbers. + + - **OP_CAT:** one of the previously-disabled opcodes that deserves + special mention is [OP_CAT][], which researchers + have since discovered can [enable][keytrees] all [sorts][rubin + pqc] of [interesting][poelstra cat] behavior on Bitcoin by itself, + or which can be [combined][topic op_checksigfromstack] with other + new opcodes in interesting ways. + + - **OP_TAPLEAF_UPDATE_VERIFY:** as described in [Newsletter #166][news166 tluv], + an `OP_TLUV` opcode can enable [covenants][topic covenants] in a way that's + particularly efficient and powerful when used with taproot's + keypath and scriptpath capabilities. This can be used to + implement [joinpools][topic joinpools], [vaults][topic vaults], and other security + and privacy improvements. It may also combine well with + [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify]. All of the ideas above are still only proposals. None is guaranteed to be successful. It'll be up to researchers and developers to bring each @@ -124,15 +124,14 @@ rules. [news166 tluv]: /en/newsletters/2021/09/15/#covenant-opcode-proposal [wuille entroot]: https://gist.github.com/sipa/ca1502f8465d0d5032d9dd2465f32603 -[towns groot]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016249.html -[maxwell graftroot]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015700.html +[towns groot]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016249.html +[maxwell graftroot]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015700.html [p4tr multisignatures]: /en/preparing-for-taproot/#multisignature-overview [p4tr vaults]: /en/preparing-for-taproot/#vaults-with-taproot [rubin delegation]: /en/newsletters/2021/03/24/#signing-delegation-under-existing-consensus-rules [p4tr taproot assumption]: /en/preparing-for-taproot/#is-cooperation-always-an-option -[op_cat subtopic]: /en/topics/op_checksigfromstack/#relationship-to-op_cat [keytrees]: https://blockstream.com/2015/08/24/en-treesignatures/#h.2lysjsnoo7jd [rubin pqc]: https://rubin.io/blog/2021/07/06/quantum-bitcoin/ [poelstra cat]: https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html [bip32 reverse derivation]: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#implications -[sipa groot agg]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-October/016461.html +[sipa groot agg]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-October/016461.html diff --git a/_includes/specials/taproot/en/21-thanks.md b/_includes/specials/taproot/en/21-thanks.md index 4eaeb77f5d..5b9d8e73cc 100644 --- a/_includes/specials/taproot/en/21-thanks.md +++ b/_includes/specials/taproot/en/21-thanks.md @@ -501,6 +501,6 @@ accept taproot-compliant blocks, making it safe for everyone to use taproot's features. {% include linkers/issues.md issues="17977,19953" %} -[maxwell taproot post]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html +[maxwell taproot post]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html [good morning]: /en/preparing-for-taproot/#a-good-morning [news69 review]: /en/newsletters/2019/10/23/#taproot-review diff --git a/_includes/specials/taproot/ja/01-single-sig.md b/_includes/specials/taproot/ja/01-single-sig.md index 8dd1d814f6..05340decbc 100644 --- a/_includes/specials/taproot/ja/01-single-sig.md +++ b/_includes/specials/taproot/ja/01-single-sig.md @@ -28,10 +28,10 @@ P2PKHのインプットとアウトプットを使用したトランザクショ 安全な[マルチシグ][topic multisignature]、さまざまな賢いウォレットバックアップリカバリー方式、 その他の100の先駆的な開発に取り組んでいる人たちと見分けがつかなくなります。 - P2TRをシングルシグに使用することで、既存のユーザーのプライバシーに影響を与えることなく、 - ウォレットをマルチシグやTapscript、LNサポート、またはその他の機能に後でアップグレードすることも可能です。 - UTXOがソフトウェアの旧バージョンと新バージョンのどちらで受信されたかは問題になりません。 - どちらのUTXOもオンチェーンでは同じように見えます。 + P2TRをシングルシグに使用することで、既存のユーザーのプライバシーに影響を与えることなく、 + ウォレットをマルチシグやTapscript、LNサポート、またはその他の機能に後でアップグレードすることも可能です。 + UTXOがソフトウェアの旧バージョンと新バージョンのどちらで受信されたかは問題になりません。 + どちらのUTXOもオンチェーンでは同じように見えます。 - **ハードウェア署名デバイスの利便性の向上:** [手数料の過払い攻撃][news101 fee overpayment attack]が再発見されてから、 diff --git a/_includes/specials/taproot/ja/03-p2wpkh-to-p2tr.md b/_includes/specials/taproot/ja/03-p2wpkh-to-p2tr.md index 961f540b90..0e4b3adf6e 100644 --- a/_includes/specials/taproot/ja/03-p2wpkh-to-p2tr.md +++ b/_includes/specials/taproot/ja/03-p2wpkh-to-p2tr.md @@ -64,38 +64,46 @@ Bitcoin Wikiの[taproot uses][wiki taproot uses]ページや 現在も多くの他のウォレットで一般的に使用されている*implicit scripts*方式と比較したものです。 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    スクリプト管理初期バックアップ新しいスクリプトの導入スキャン（帯域幅/CPUコスト）非推奨スクリプト
    Implicit scripts (例：[BIP44][])シードワード自動（ユーザー操作は不要）サポートされているすべてのスクリプトをスキャン、O(n)サポートされていないスクリプトを使用していることをユーザーに警告する方法はありません
    Explicit scripts（バージョン付きシード）シードワード（バージョンビットを含む）ユーザーは新しいシードのバックアップが必要。 - 資金は2つの別々のウォレットに分割されるか、ユーザーは旧ウォレットから新しいウォレットに資金を送信する必要があります単一のスクリプトテンプレートのみをスキャン、O(1)サポートされていないスクリプトに関するユーザーへの警告
    Explicit scripts ([descriptor][topic descriptors])シードワードとdescriptorユーザーは新しいdescriptorのバックアップが必要実際に使用されたスクリプトテンプレートのみをスキャン、O(n); 新しいウォレットの場合はn=1サポートされていないスクリプトに関するユーザーへの警告
    スクリプト管理初期バックアップ新しいスクリプトの導入スキャン（帯域幅/CPUコスト）非推奨スクリプト
    + + Implicit scripts (例：[BIP44][]) + + シードワード自動（ユーザー操作は不要）サポートされているすべてのスクリプトをスキャン、O(n)サポートされていないスクリプトを使用していることをユーザーに警告する方法はありません
    Explicit scripts（バージョン付きシード）シードワード（バージョンビットを含む）ユーザーは新しいシードのバックアップが必要。 + 資金は2つの別々のウォレットに分割されるか、ユーザーは旧ウォレットから新しいウォレットに資金を送信する必要があります単一のスクリプトテンプレートのみをスキャン、O(1)サポートされていないスクリプトに関するユーザーへの警告
    + + Explicit scripts ([descriptor][topic descriptors]) + + シードワードとdescriptorユーザーは新しいdescriptorのバックアップが必要実際に使用されたスクリプトテンプレートのみをスキャン、O(n); 新しいウォレットの場合はn=1サポートされていないスクリプトに関するユーザーへの警告
    {% include linkers/issues.md issues="" %} diff --git a/_includes/specials/taproot/ja/04-why-wait.md b/_includes/specials/taproot/ja/04-why-wait.md index d4875c5580..b4dd62893c 100644 --- a/_includes/specials/taproot/ja/04-why-wait.md +++ b/_includes/specials/taproot/ja/04-why-wait.md @@ -1,4 +1,5 @@ {% capture /dev/null %} + {% assign ante_trb = "709,631" %} + {% assign safe_trb = "709,776" %} {% endcapture %} diff --git a/_includes/specials/taproot/ja/06-multisignatures.md b/_includes/specials/taproot/ja/06-multisignatures.md index fe1278c420..2f7364f725 100644 --- a/_includes/specials/taproot/ja/06-multisignatures.md +++ b/_includes/specials/taproot/ja/06-multisignatures.md @@ -1,8 +1,8 @@ {% comment %}{% endcomment %} この記事を書く前に受信した1,000ブロックでは、全トランザクションインプットの11%がマルチシグopcodeを含んでいました。 このようなトランザクションを作成するユーザーやサービスの多くが、 @@ -58,6 +58,7 @@ Bitcoin用に設計された3つのSchnorrベースのマルチシグスキー すべての署名者は使用するプロトコルに同意しなければならないため、 多くの実装が同じプロトコルを選択するというネットワーク効果が発生する可能性があります。 MuSigの提案の著者は、比較的シンプルで実用性の高いMuSig2の選択を[提案しています][nick ruffing blog]。 + diff --git a/_includes/specials/taproot/ja/12-backups.md b/_includes/specials/taproot/ja/12-backups.md index 93c4e96373..f68a455453 100644 --- a/_includes/specials/taproot/ja/12-backups.md +++ b/_includes/specials/taproot/ja/12-backups.md @@ -10,8 +10,8 @@ Taprootによって、よりプライベートで手数料を効率化する方 例外ケースでも、かなり効率的でプライベートです。このように、Taprootは、 単一署名者のウォレットから複数の署名者のポリシーにセキュリティをアップグレードするのに適しています。 - 今後の[閾値署名][topic threshold signature]の技術により、 - 2-of-3や他のk-of-nのケースがさらに改善されることを期待しています。 + 今後の[閾値署名][topic threshold signature]の技術により、 + 2-of-3や他のk-of-nのケースがさらに改善されることを期待しています。 - **マルチシグのデグレード:** [Optech Taproot Workshop][taproot workshop]の演習問題の1つでは、 3つの鍵ではいつでも支払いが可能、もしくは3日後に元の鍵の内2つで支払いが可能、 @@ -19,22 +19,22 @@ Taprootによって、よりプライベートで手数料を効率化する方 （この実験では、バックアップの鍵も使用しますが、それは次のポイントで別途取り上げます。） このように、時間パラメーターと鍵の設定を調整することで、柔軟かつ強力なバックアップを構築することができます。 - 例えば、普段はノートパソコンや携帯電話、ハードウェア署名デバイスを組み合わせて支払いをできるとします。 - そのうちの1つが使えなくなった場合、1ヶ月待てば残りの2つのデバイスを使って支払いができます。 - 2つのデバイスが使えなくなった場合は、6ヶ月後に1つのデバイスだけで支払いができます。 + 例えば、普段はノートパソコンや携帯電話、ハードウェア署名デバイスを組み合わせて支払いをできるとします。 + そのうちの1つが使えなくなった場合、1ヶ月待てば残りの2つのデバイスを使って支払いができます。 + 2つのデバイスが使えなくなった場合は、6ヶ月後に1つのデバイスだけで支払いができます。 - 3つのデバイスをすべて使用する通常のケースでは、あなたのオンチェーンScriptは最大限に効率的でプライベートなものになります。 - その他のケースでは、少し効率は低下しますが、それでもかなりプライベートである可能性があります - （あなたのScriptとそのツリーの深さは、他の多くのコントラクトで使用されているScriptと深さと似ています）。 + 3つのデバイスをすべて使用する通常のケースでは、あなたのオンチェーンScriptは最大限に効率的でプライベートなものになります。 + その他のケースでは、少し効率は低下しますが、それでもかなりプライベートである可能性があります + （あなたのScriptとそのツリーの深さは、他の多くのコントラクトで使用されているScriptと深さと似ています）。 - **バックアップのためのソーシャルリカバリーとセキュリティ:** 上記の例は、 デバイスの1つが攻撃者に盗まれた場合の保護に優れていますが、2つのデバイスが盗まれた場合はどうなるでしょう？ また、ウォレットを頻繁に使用する場合、デバイスを失った後に再び支払いを開始できるようになるまで本当に1ヶ月待ちたいと思いますか？ - Taprootを使うと、バックアップにソーシャル要素を簡単かつ安価、プライベートに追加できます。 - 前の例のScriptに加えて、2つのデバイスに加えて友人または家族からの署名があればビットコインをすぐに使用できるようにすることもできます。 - または、鍵の1つと信頼できる5人の署名があればすぐに使用できます。 - （これと同様の非ソーシャルバージョンは、安全な場所に保管してある追加のデバイスやシードフレーズを使用するだけです。） + Taprootを使うと、バックアップにソーシャル要素を簡単かつ安価、プライベートに追加できます。 + 前の例のScriptに加えて、2つのデバイスに加えて友人または家族からの署名があればビットコインをすぐに使用できるようにすることもできます。 + または、鍵の1つと信頼できる5人の署名があればすぐに使用できます。 + （これと同様の非ソーシャルバージョンは、安全な場所に保管してある追加のデバイスやシードフレーズを使用するだけです。） - **相続のための時間的および社会的閾値の組み合わせ:** 上記の技術を組み合わせることで、 あなたが突然死亡したりだめになってしまった場合に、誰かまたは複数人の人があなたの資金を回収できるようにすることができます。 @@ -45,12 +45,12 @@ Taprootによって、よりプライベートで手数料を効率化する方 あなたの死後、弁護士や家族があなたのウォレットの拡張公開鍵（xpub）を知ることができる確実な方法を用意しておけば、 トランザクションを弁護士や家族に秘密にしたままにすることも可能です。 - なお相続人があなたのビットコインを使用できるようにすることは、 - そのビットコインを合法的に使用できることを意味するわけではないことに注意してください。 - ビットコインの相続を計画されている方は、Pamela Morgan著 - *Cryptoasset Inheritance Planning*（[物理的な書籍およびDRM付き電子書籍][cip amazon]、 - または[DRMフリーの電子書籍][cip aantonop]）をお読みになり、 - その情報をもとに、地元の相続計画の専門家に詳細を相談されることをお勧めします。 + なお相続人があなたのビットコインを使用できるようにすることは、 + そのビットコインを合法的に使用できることを意味するわけではないことに注意してください。 + ビットコインの相続を計画されている方は、Pamela Morgan著 + *Cryptoasset Inheritance Planning*（[物理的な書籍およびDRM付き電子書籍][cip amazon]、 + または[DRMフリーの電子書籍][cip aantonop]）をお読みになり、 + その情報をもとに、地元の相続計画の専門家に詳細を相談されることをお勧めします。 - **侵害の検出:** Taprootの発明以前に[提案された][tree signatures]アイディアは、 デバイスが侵害されたことを検出する方法として、いくつかの量のビットコインを管理する鍵を、 @@ -58,13 +58,13 @@ Taprootによって、よりプライベートで手数料を効率化する方 攻撃者はおそらく、不正アクセスを長期的な攻撃に利用して全体的な被害が広がるのを待つのではなく、 目先の利益のためにそのコインを使用するでしょう。 - このアプローチの問題は、提供するビットコインの量を攻撃者を誘うのに十分な大きさにしたいものの、 - 大量のビットコインをすべてのデバイスに配置したくはなく、どちらかというと大きな報奨金を1つだけ提供したいという点です。 - しかし、すべてのデバイスに同じ鍵を配置すると、攻撃者がビットコインを使用するトランザクションからは、 - どのデバイスが侵害されたかはわかりません。 - Taprootでは、すべてのデバイスに異なるscriptpathの異なる鍵を簡単に配置することができます。 - これらの鍵のいずれかが、そのアドレスで管理されているすべての資金を使用することができますが、 - どのデバイスが侵害されたか一意に特定することができます。 + このアプローチの問題は、提供するビットコインの量を攻撃者を誘うのに十分な大きさにしたいものの、 + 大量のビットコインをすべてのデバイスに配置したくはなく、どちらかというと大きな報奨金を1つだけ提供したいという点です。 + しかし、すべてのデバイスに同じ鍵を配置すると、攻撃者がビットコインを使用するトランザクションからは、 + どのデバイスが侵害されたかはわかりません。 + Taprootでは、すべてのデバイスに異なるscriptpathの異なる鍵を簡単に配置することができます。 + これらの鍵のいずれかが、そのアドレスで管理されているすべての資金を使用することができますが、 + どのデバイスが侵害されたか一意に特定することができます。 [taproot series vaults]: /ja/preparing-for-taproot/#vaultとtaproot [cip amazon]: https://amazon.com/Cryptoasset-Inheritance-Planning-Simple-Owners/dp/1947910116 diff --git a/_includes/specials/taproot/ja/15-output-linking.md b/_includes/specials/taproot/ja/15-output-linking.md index 7857a80ac5..bc89976d38 100644 --- a/_includes/specials/taproot/ja/15-output-linking.md +++ b/_includes/specials/taproot/ja/15-output-linking.md @@ -45,9 +45,10 @@ Taprootの[プライバシー上の利点][p4tr benefits]を無視すべきだ Taprootの他の驚くべきプライバシー上の利点もすべて得られます。 {% include linkers/issues.md issues="12119" %} + {% endauto_anchor %} + [p4tr benefits]: /ja/preparing-for-taproot/#マルチシグの概要 [p4tr safety]: /ja/preparing-for-taproot/#なぜ待つ必要があるのか？ [coindesk experts]: https://www.coindesk.com/tech/2020/12/01/privacy-concerns-over-bitcoin-upgrade-taproot-are-a-non-issue-experts-say/ -[compat bcc]: /en/compatibility/bitcoin-core/ [news155 bcc22154]: /ja/newsletters/2021/06/30/#bitcoin-core-22154 diff --git a/_includes/specials/taproot/ja/17-keypath-universality.md b/_includes/specials/taproot/ja/17-keypath-universality.md index ce2c88e270..caa20badb0 100644 --- a/_includes/specials/taproot/ja/17-keypath-universality.md +++ b/_includes/specials/taproot/ja/17-keypath-universality.md @@ -18,15 +18,15 @@ Gregory Maxwellによる最初の[最初のTaprootの提案][maxwell taproot]は タイムロックの要件は、署名以上のものが必要であることを示唆ししているように思えますが、 いくつかの批判があります: - - タイムロックされたビットコインをどうしても使いたい人は、 - おそらく他の資産を担保にしてローンを組むことができます。 - これは、このセルフコントラクトの有用性を損ないます。 + - タイムロックされたビットコインをどうしても使いたい人は、 + おそらく他の資産を担保にしてローンを組むことができます。 + これは、このセルフコントラクトの有用性を損ないます。 - - コンセンサスによるscriptpathのタイムロックに加えて、 - ユーザーは自分の鍵とタイムロックの期限が切れた時にのみ署名する第三者の鍵とでkeypathによる支払いを可能にできます。 - これは、より効率的なだけでなく、受け取ったフォークコインを販売したり、 - 人生の大きな変化や価格上昇などにより早期の使用を許可する第三者と協力するなど、 - より柔軟な支払いポリシーを実装することができます。 + - コンセンサスによるscriptpathのタイムロックに加えて、 + ユーザーは自分の鍵とタイムロックの期限が切れた時にのみ署名する第三者の鍵とでkeypathによる支払いを可能にできます。 + これは、より効率的なだけでなく、受け取ったフォークコインを販売したり、 + 人生の大きな変化や価格上昇などにより早期の使用を許可する第三者と協力するなど、 + より柔軟な支払いポリシーを実装することができます。 - **Vault:** 数週間前の本サイトのAntoine Poinsotの[コラム][p4tr vaults]で言及されているように、 [Vault][topic vaults]も資金保護のためにタイムロックを多用していますが、 @@ -52,6 +52,6 @@ Taprootベースのコントラクトでkeypathを使用する機会があるか {% endauto_anchor %} [p4tr vaults]: /ja/preparing-for-taproot/#vaultとtaproot -[maxwell taproot]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html +[maxwell taproot]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html [irc log1]: https://gnusha.org/taproot-bip-review/2020-02-09.log [irc log2]: https://gnusha.org/taproot-bip-review/2020-02-10.log diff --git a/_includes/specials/taproot/ja/18-trivia.md b/_includes/specials/taproot/ja/18-trivia.md index dea52839b8..1fedc041fa 100644 --- a/_includes/specials/taproot/ja/18-trivia.md +++ b/_includes/specials/taproot/ja/18-trivia.md @@ -5,25 +5,25 @@ 一般的には、やや直線的で非常に太く、先細りの形状をしており、真下に向かって伸びています。 人参などの一部の植物では、Taprootは非常によく発達した貯蔵器官であるため、野菜として栽培されます。」 - これはBitcoinにどう当てはまるでしょう？ + これはBitcoinにどう当てはまるでしょう？ - - 「名前の由来は'taps into the Merkle root'だと思っていましたが、 - Gregory Maxwellの考えがどうだったかは実は知りません。」 ---Pieter Wuille ([出典][wuille taproot name]) + - 「名前の由来は'taps into the Merkle root'だと思っていましたが、 + Gregory Maxwellの考えがどうだったかは実は知りません。」 ---Pieter Wuille ([出典][wuille taproot name]) - - 「"私はもともと言葉を調べる必要がありました。しかし、 - key pathが'taproot'になるのは、それが人参スープを作る美味しいものであるためで、 - マークル化されたScriptは、無視したいと願う他の少ない根だろうと受け取りました。」 - ---Anthony Towns ([出典][towns taproot name]) + - 「"私はもともと言葉を調べる必要がありました。しかし、 + key pathが'taproot'になるのは、それが人参スープを作る美味しいものであるためで、 + マークル化されたScriptは、無視したいと願う他の少ない根だろうと受け取りました。」 + ---Anthony Towns ([出典][towns taproot name]) - - 「名前の由来は、タンポポの根っこのような太い中心部を持つ木を視覚化したものです。 - この技術は、高確率のパスが１つあり、残りはファジーなはぐれ者であるという仮定から、 - ほとんどの場合役に立ちます。そして、 - 根っこに隠されたコミットメントを利用してscript-pathの支払いを検証するという面白い事実も良いと考えました。 + - 「名前の由来は、タンポポの根っこのような太い中心部を持つ木を視覚化したものです。 + この技術は、高確率のパスが１つあり、残りはファジーなはぐれ者であるという仮定から、 + ほとんどの場合役に立ちます。そして、 + 根っこに隠されたコミットメントを利用してscript-pathの支払いを検証するという面白い事実も良いと考えました。 - [...]残念ながら、ソートされた内部ノードを持つハッシュツリーを'Myrtle tree'と呼んでも流行りませんでした。 - （ハッシュルートが等しいポリシーのセットは、T-functionで定義できる順列によって順序の異なるものであるため、 - Myrtle treeです。そして、Myrtleとは、お茶の木であるメラレウカを含む科であること、 - そして'merkle'に聞こえることからきてます。:p）」 ---Gregory Maxwell ([出典][maxwell taproot name]) + [...]残念ながら、ソートされた内部ノードを持つハッシュツリーを'Myrtle tree'と呼んでも流行りませんでした。 + （ハッシュルートが等しいポリシーのセットは、T-functionで定義できる順列によって順序の異なるものであるため、 + Myrtle treeです。そして、Myrtleとは、お茶の木であるメラレウカを含む科であること、 + そして'merkle'に聞こえることからきてます。:p）」 ---Gregory Maxwell ([出典][maxwell taproot name]) - **Schnorr署名はECDSAより前から存在:** [Schnorr署名][topic schnorr signatures]について、さまざまな暗号トリックの実装が簡単になるため、 @@ -46,26 +46,26 @@ スキーム[EdDSA][]は、現在いくつかの標準の基礎となっています。 Bitcoinのコンセンサスでは使用されていませんが、他のシステムのコンテキストでの参照は、 Optechが追跡している多くのBitcoinリポジトリで見られます。 + - **Pay to contract:** Ilja GerhardtとTimo Hankeは、支払いがその契約のハッシュにコミットすることを可能する、 - 2013年のSan JoseのBitcoinカンファレンスでHankeによって紹介された[プロトコル][gh p2c]を作成しました。 - + 2013年のSan JoseのBitcoinカンファレンスでHankeによって紹介された[プロトコル][gh p2c]を作成しました。 契約のコピーと、特定の攻撃を回避するために使用されるnonceを持っている人であればコミットメントを検証できますが、 それ以外の人にとってはその支払いは他のBitcoinの支払いと同じように見えます。 - この*pay-to-contract* (P2C)プロトコルを少し改良したものが、 - [サイドチェーン][topic sidechains]に関する[2014年の論文][sidechains.pdf]に含まれており、 - - コミットメントには支払いのための元の公開鍵も含まれるようになっています。 - Taprootはこれと同じ構造を採用していますが、オフチェーン契約の条項にコミットする代わりに、 - アウトプットの作成者は、受信したビットコインをオンチェーンで使用する方法について、 - 受信者が選んだコンセンサス適用条件にコミットします。 + この*pay-to-contract* (P2C)プロトコルを少し改良したものが、 + [サイドチェーン][topic sidechains]に関する[2014年の論文][sidechains.pdf]に含まれており、 + コミットメントには支払いのための元の公開鍵も含まれるようになっています。 + Taprootはこれと同じ構造を採用していますが、オフチェーン契約の条項にコミットする代わりに、 + アウトプットの作成者は、受信したビットコインをオンチェーンで使用する方法について、 + 受信者が選んだコンセンサス適用条件にコミットします。 - **A Good Morning:** P2Cを利用することで、Scriptへの支払いが公開鍵への支払いとチェーン上で同一に見えるようにするアイディアは、 2018年1月22日にカリフォルニア州ロス・アルトスのダイナー「A Good Morning」で考案されました。 Pieter Wuilleは、このアイディアは「私が短時間テーブルを離れている間に… !$%@」[sic] Andrew PoelstraとGregory Maxwellによって開発されたと書いています。 + diff --git a/_includes/specials/taproot/ja/19-future.md b/_includes/specials/taproot/ja/19-future.md index ea4a203791..90e40c235c 100644 --- a/_includes/specials/taproot/ja/19-future.md +++ b/_includes/specials/taproot/ja/19-future.md @@ -7,13 +7,13 @@ [Schnorr署名][topic schnorr signatures]は、複数の異なる公開鍵と秘密鍵のペアの所有者が、 協力して署名を作成したことを証明する単一の署名を簡単に作成することができます。 - 将来のコンセンサスの変更により、 - トランザクションで使用されているすべてのUTXOの所有者がその支払いを承認したことを証明する - 単一の署名をトランザクションに含めることができるようになる可能性があります。 - これにより、最初のインプットの後は、keypathでの支払い毎に約16 vbyteが節約され、 - 統合や[CoinJoin][topic coinjoin]での大幅な節約につながります。 - これにより、CoinJoinベースによる支払いの方が、自分単独の支払いよりも安くなり、 - より多くのプライベートな支払いを行う緩やかなインセンティブを提供します。 + 将来のコンセンサスの変更により、 + トランザクションで使用されているすべてのUTXOの所有者がその支払いを承認したことを証明する + 単一の署名をトランザクションに含めることができるようになる可能性があります。 + これにより、最初のインプットの後は、keypathでの支払い毎に約16 vbyteが節約され、 + 統合や[CoinJoin][topic coinjoin]での大幅な節約につながります。 + これにより、CoinJoinベースによる支払いの方が、自分単独の支払いよりも安くなり、 + より多くのプライベートな支払いを行う緩やかなインセンティブを提供します。 - **SIGHASH_ANYPREVOUT:** 通常のBitcoinのトランザクションには、1つ以上のインプットが含まれており、 そのインプットのそれぞれがtxidを使って以前のトランザクションアウトプットを参照しています。 @@ -22,20 +22,20 @@ Bitcoinトランザクションの署名を生成するすべての方法は、Taprootを使用する場合も使用しない場合も、 prevoutのtxidにコミットするか、prevoutにまったくコミットしないかのいずれかです。 - これは事前に準備された正確な一連のトランザクションを使用したくないマルチユーザー・プロトコルにとって問題となります。 - ユーザーが特定のトランザクションをスキップしたり、witnessデータ以外のトランザクションの詳細を変更したりすると、 - 後続のトランザクションのtxidが変更されます。 - txidを変更すると後続のトランザクション用に事前に作成されていた署名が無効になります。 - これによりオフチェーンプロトコルは古いトランザクションを送信したユーザーにペナルティを与える - （LN-penaltyなど）を実装しなければなりません。 - - [SIGHASH_ANYPREVOUT][topic sighash_anyprevout]は、 - 署名がprevout txidへのコミットをスキップすることを許可することで、 - この問題を解消することができます。使用される他のフラグによっては、 - prevoutやトランザクションに関する他の詳細（金額やScriptなど）にコミットしますが、 - 以前のトランザクションで使用されていたtxidは関係なくなります。 - これにより、LNの[eltoo][topic eltoo]レイヤーの実装や、 - [Vault][topic vaults]や他のコントラクトプロトコルの[改善][p4tr vaults]の両方が可能になります。 + これは事前に準備された正確な一連のトランザクションを使用したくないマルチユーザー・プロトコルにとって問題となります。 + ユーザーが特定のトランザクションをスキップしたり、witnessデータ以外のトランザクションの詳細を変更したりすると、 + 後続のトランザクションのtxidが変更されます。 + txidを変更すると後続のトランザクション用に事前に作成されていた署名が無効になります。 + これによりオフチェーンプロトコルは古いトランザクションを送信したユーザーにペナルティを与える + （LN-penaltyなど）を実装しなければなりません。 + + [SIGHASH_ANYPREVOUT][topic sighash_anyprevout]は、 + 署名がprevout txidへのコミットをスキップすることを許可することで、 + この問題を解消することができます。使用される他のフラグによっては、 + prevoutやトランザクションに関する他の詳細（金額やScriptなど）にコミットしますが、 + 以前のトランザクションで使用されていたtxidは関係なくなります。 + これにより、LNの[eltoo][topic eltoo]レイヤーの実装や、 + [Vault][topic vaults]や他のコントラクトプロトコルの[改善][p4tr vaults]の両方が可能になります。 - **委譲と一般化:** （Taprootまたはそれ以外の）Scriptを作成した後は、 @@ -45,26 +45,26 @@ より手軽な価格を提供します。Taprootを一般化し、[署名者の委譲][topic signer delegation]を行うことで、 Taprootを強化する方法がいくつか提案されています: - - **Graftroot:** Taprootのアイディアが紹介された直後に[提案された][maxwell graftroot]Graftrootは、 - 誰もがTaprootのkeypath支払いをできるようにする追加機能を与えるものです。 - keypathの署名者は資金を直接使用する代わりに、資金を使用できる新しい条件を記述したScriptに署名し、 - そのScriptの条件を満たすことができる人に使用権限を委譲することができます。 - 署名およびScript、そのScriptを満たすために必要なデータが、支払いトランザクションで提供されます。 - keypathの署名者は、実際に支払いが発生するまで、オンチェーンデータを作成することなく、 - この方法で無制限の数のScriptに委譲することができます。 - - - **一般化されたTaproot (g'root):** - その数ヶ月後、Anthony Townsは、公開鍵ポイントを使って、 - 必ずしも[MAST][topic mast]のような構造を使わずに、 - 複数の異なる支払い条件にコミットする方法を[提案しました][towns groot]。 - この*一般化されたTaproot* (g'root) 構造は、「[Taprootの仮定が成立しない][p4tr taproot assumption]場合に、 - より効率的になる可能性がある」としています。 - また、「ソフトフォーク・セーフなインプットをまたぐ集約システムを簡単に構築する方法を[提供する][sipa groot agg]」 - としています。 - - - **Entroot:** Graftrootとg'rootを[最近][wuille entroot]合成したもので、 - 多くのケースを単純化し、より帯域幅を効率化しています。これは、トップレベルのkeypath支払いを作成できる人だけでなく、 - entrootブランチのいずれかを満たすことができる誰からでも署名者の委譲をサポートすることができます。 + - **Graftroot:** Taprootのアイディアが紹介された直後に[提案された][maxwell graftroot]Graftrootは、 + 誰もがTaprootのkeypath支払いをできるようにする追加機能を与えるものです。 + keypathの署名者は資金を直接使用する代わりに、資金を使用できる新しい条件を記述したScriptに署名し、 + そのScriptの条件を満たすことができる人に使用権限を委譲することができます。 + 署名およびScript、そのScriptを満たすために必要なデータが、支払いトランザクションで提供されます。 + keypathの署名者は、実際に支払いが発生するまで、オンチェーンデータを作成することなく、 + この方法で無制限の数のScriptに委譲することができます。 + + - **一般化されたTaproot (g'root):** + その数ヶ月後、Anthony Townsは、公開鍵ポイントを使って、 + 必ずしも[MAST][topic mast]のような構造を使わずに、 + 複数の異なる支払い条件にコミットする方法を[提案しました][towns groot]。 + この*一般化されたTaproot* (g'root) 構造は、「[Taprootの仮定が成立しない][p4tr taproot assumption]場合に、 + より効率的になる可能性がある」としています。 + また、「ソフトフォーク・セーフなインプットをまたぐ集約システムを簡単に構築する方法を[提供する][sipa groot agg]」 + としています。 + + - **Entroot:** Graftrootとg'rootを[最近][wuille entroot]合成したもので、 + 多くのケースを単純化し、より帯域幅を効率化しています。これは、トップレベルのkeypath支払いを作成できる人だけでなく、 + entrootブランチのいずれかを満たすことができる誰からでも署名者の委譲をサポートすることができます。 - **新旧opcode:** Taprootのソフトフォークには、 Bitcoinに新しいopcodeを追加するための改良された方法（`OP_SUCCESSx` opcode）を提供する @@ -73,20 +73,20 @@ `OP_SUCCESSx` opcodeは、常にsuccessを返すことのないopcodeに置き換えられるよう設計されています。 提案されている新しいopcodeには次のようなものがあります: - - **旧opcodeの復活:** - 数式や文字列操作のための多くのopcodeが、セキュリティの脆弱性への懸念から2010年に無効化されました。 - 多くの開発者は、これらのopcodeがセキュリティレビューを経て再び有効になること、 - そして（場合によっては）より大きな数値が扱えるよう拡張されることを期待しています。 + - **旧opcodeの復活:** + 数式や文字列操作のための多くのopcodeが、セキュリティの脆弱性への懸念から2010年に無効化されました。 + 多くの開発者は、これらのopcodeがセキュリティレビューを経て再び有効になること、 + そして（場合によっては）より大きな数値が扱えるよう拡張されることを期待しています。 - - **OP_CAT:** 以前無効化されたopcodeの内の１つで、特筆すべきは[OP_CAT][op_cat subtopic]です。 - 研究者が、OP_CAT自体でBitcoinのあらゆる[種類][rubin pqc]の[興味深い][poelstra cat]動作を[可能に][keytrees]したり、 - 興味深い方法で他の新しいopcodeと[組み合わせる][topic op_checksigfromstack]ことができることを発見しています。 + - **OP_CAT:** 以前無効化されたopcodeの内の１つで、特筆すべきは[OP_CAT][op_cat subtopic]です。 + 研究者が、OP_CAT自体でBitcoinのあらゆる[種類][rubin pqc]の[興味深い][poelstra cat]動作を[可能に][keytrees]したり、 + 興味深い方法で他の新しいopcodeと[組み合わせる][topic op_checksigfromstack]ことができることを発見しています。 - - **OP_TAPLEAF_UPDATE_VERIFY:** [ニュースレター #166][news166 tluv]に掲載したように、`OP_TLUV` opcodeは、 - Taprootのkeypathとscriptpathの機能を使って特に効率的かつ強力な[Covenants][topic covenants]を可能にします。 - これは、[JoinPool][topic joinpools]や[Vault][topic vaults]および、 - その他のセキュリティやプライバシーの改善を実装するために使用できます。 - また、[OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify]とうまく組み合わせることができます。 + - **OP_TAPLEAF_UPDATE_VERIFY:** [ニュースレター #166][news166 tluv]に掲載したように、`OP_TLUV` opcodeは、 + Taprootのkeypathとscriptpathの機能を使って特に効率的かつ強力な[Covenants][topic covenants]を可能にします。 + これは、[JoinPool][topic joinpools]や[Vault][topic vaults]および、 + その他のセキュリティやプライバシーの改善を実装するために使用できます。 + また、[OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify]とうまく組み合わせることができます。 上記のアイディアはすべて、まだ提案に過ぎません。どれも成功するとは限りません。 各提案を成熟させるのは研究者や開発者であり、その後Bitcoinに各機能を追加することが、 @@ -96,8 +96,8 @@ Bitcoinのコンセンサスルールを変更する労力に値するかどう [news166 tluv]: /ja/newsletters/2021/09/15/#covenant-opcode-proposal-covenant-opcode [wuille entroot]: https://gist.github.com/sipa/ca1502f8465d0d5032d9dd2465f32603 -[towns groot]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016249.html -[maxwell graftroot]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015700.html +[towns groot]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016249.html +[maxwell graftroot]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015700.html [p4tr multisignatures]: /ja/preparing-for-taproot/#マルチシグの概要 [p4tr vaults]: /ja/preparing-for-taproot/#vaultとtaproot [rubin delegation]: /ja/newsletters/2021/03/24/#signing-delegation-under-existing-consensus-rules @@ -107,4 +107,4 @@ Bitcoinのコンセンサスルールを変更する労力に値するかどう [rubin pqc]: https://rubin.io/blog/2021/07/06/quantum-bitcoin/ [poelstra cat]: https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html [bip32 reverse derivation]: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#implications -[sipa groot agg]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-October/016461.html +[sipa groot agg]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-October/016461.html diff --git a/_includes/specials/taproot/ja/21-thanks.md b/_includes/specials/taproot/ja/21-thanks.md index f988939e91..e1cfe10a7f 100644 --- a/_includes/specials/taproot/ja/21-thanks.md +++ b/_includes/specials/taproot/ja/21-thanks.md @@ -486,6 +486,6 @@ Taprootのアクティベーションは始まりに過ぎません。 誰もがTaprootの機能を安全に利用できるようになります。 {% include linkers/issues.md issues="17977,19953" %} -[maxwell taproot post]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html +[maxwell taproot post]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html [good morning]: /ja/preparing-for-taproot/#a-good-morning [news69 review]: /ja/newsletters/2019/10/23/#taproot diff --git a/_includes/specials/taproot/zh/00-bech32m.md b/_includes/specials/taproot/zh/00-bech32m.md new file mode 100644 index 0000000000..48744dfa89 --- /dev/null +++ b/_includes/specials/taproot/zh/00-bech32m.md @@ -0,0 +1,9 @@ +从预计在 11 月到来的区块高度 {{site.trb}} 开始，比特币用户将能够安全地接收发送到 taproot 地址的付款。考虑到用户对 taproot 的期待，以及钱包开发者有 5 个月的时间来实现对 taproot 的支持，Optech 预计到时会有数个流行的钱包允许用户在第一时间生成 taproot 地址。 + +这意味着任何会向用户提供的地址发送比特币的钱包或服务，都需要在区块高度 {{site.trb}} 前支持发送至 taproot 地址，否则可能会让用户感到困惑并失望。Pay to TapRoot（P2TR）地址使用了 [bech32m][topic bech32]（参见 [BIP350][]），它与 [BIP173][] 用于 segwit v0 P2WPKH 和 P2WSH 地址的 bech32 算法略有不同。bech32m 在校验和函数中使用 `0x2bc830a3` 常量，而传统 bech32 则使用 `0x01`。 + +只需改变这一常量即可为校验 bech32m 校验和提供支持，但在处理现有 P2WPKH 和 P2WSH 地址时仍要使用原始常量。也就是说，代码需要先在不验证校验和的情况下解析地址，判断它是 v0 segwit（bech32）还是 v1+ segwit（bech32m），然后再使用对应的常量来验证校验和。更多示例可参考 [bech32#56][bech32#56]，它更新了 C、C++、JS 和 Python 的 bech32 参考实现。如果代码已经使用了参考库，可以更新至该仓库的最新版本，但要注意其中部分 API 发生了小幅更改。BIP350 和参考实现提供的测试向量，所有 bech32m 实现都应当进行使用以验证正确性。 + +虽然在区块高度 {{site.trb}} 之前向 taproot 地址*接收*付款并不安全，但向这些地址*发送*付款对于付款方而言并不会造成任何问题。自 Bitcoin Core 0.19（2019 年 11 月发布）起，Bitcoin Core 就开始支持传播和挖矿包含 taproot 输出的交易。Optech 鼓励各钱包和服务的开发者现在就着手实现对 bech32m taproot 地址付款的支持，而不要等到 taproot 激活后再做准备。 + +[bech32#56]: https://github.com/sipa/bech32/pull/56 diff --git a/_includes/specials/taproot/zh/01-single-sig.md b/_includes/specials/taproot/zh/01-single-sig.md new file mode 100644 index 0000000000..8c0dadd8bc --- /dev/null +++ b/_includes/specials/taproot/zh/01-single-sig.md @@ -0,0 +1,28 @@ +{% auto_anchor %} +使用 Optech 的 [交易大小计算器][transaction size calculator]，我们可以比较不同类型单签名交易的大小。正如预期，使用 P2WPKH 输入和输出的交易远小于使用 P2PKH 输入和输出的交易——但或许令人惊讶的是，P2TR 交易比同等的 P2WPKH 交易略大。 + +| | P2PKH (legacy) | P2WPKH (segwit v0) | P2TR (taproot/segwit v1) | +|--------------------|----------------|--------------------|--------------------------| +| **Output** | 34 | 31 | 43 | +| **Input** | 148 | 68 | 57.5 | +| **2-in, 2-out tx** | 374 | 208.5 | 211.5 | + +这可能会让人觉得，为了迎接在区块 {{site.trb}} 激活的 taproot 而在单签名钱包中实现 taproot 花费是得不偿失的，但当我们进一步研究时会发现，对于钱包用户和整个网络而言，使用 P2TR 进行单签名仍然有许多好处。 + +- ******花费更便宜：** 与花费 P2WPKH UTXO 相比，花费单签名 P2TR UTXO 在输入层面上节约了大约 15% 的成本。上表这样过于简单的分析掩盖了一个细节，即花费者无法选择他们被要求支付的地址，所以如果你还停留在 P2WPKH，而其他人都升级到了 P2TR，那么你的 2 入、2 出交易的实际常见大小将会达到 232.5 vbytes——而全部使用 P2TR 的交易仍然只有 211.5 vbytes。 + +- ******隐私：** 虽然当早期采用者切换到新的脚本格式时会失去一些隐私，但用户切换到 taproot 也能立刻获得隐私增强。你的交易在链上可能与正在使用新 LN 通道、更高效的 [DLCs][topic dlc]、安全的[多签][topic multisignature]、各种巧妙的钱包备份恢复方案或其他上百种全新发展场景的人看起来毫无区别。 + + 现在就对单签名采用 P2TR 还能让你的钱包在之后升级到多签名、tapscript、LN 支持或其他功能时，不会影响你的现有用户的隐私。UTXO 是在你旧版或新版软件中接收的都无关紧要——这两种 UTXO 在链上看起来没有差别。 + +- ******更方便硬件签名设备：** 自从重新发现了[手续费超额支付攻击][news101 fee overpayment attack]以来，一些硬件签名设备在没有为该交易输入的每个 UTXO 提供元数据（包含创建该 UTXO 的完整交易中重要部分的副本）的情况下，拒绝为交易签名。这样会极大增加硬件签名器需要执行的最糟糕情况处理量，对主要通过尺寸有限的二维码进行交互的硬件签名器来说尤其棘手。taproot 消除了导致手续费超额支付攻击的漏洞，从而能够显著提高硬件签名器的性能。 + +- ******更可预测的费率：** 适用于 P2PKH 和 P2WPKH UTXO 的 ECDSA 签名大小具有灵活性（参见 [Newsletter #3][news3 sig size]）。由于钱包需要在创建签名前先决定交易的费率，大多数钱包只是默认假设最糟糕的签名大小，并接受在实际生成更小签名时稍微超额支付费率。对于 P2TR，则可以预先明确签名的确切大小，钱包就能可靠地选择精准的费率。 + +- ******帮助全节点：** 比特币系统的整体安全性依赖于有相当比例的比特币用户使用自己的节点验证所有已确认的交易，包括验证你的钱包所创建的交易。taproot 的 [schnorr 签名][topic schnorr signatures]可以被高效地批量验证，在节点赶上之前区块的过程中，[CPU 耗时大约可以减少一半][batch graph]。即使你对上面提到的其他优势都不感兴趣，也可以考虑为了那些运行全节点的人而做好使用 taproot 的准备。 + +[transaction size calculator]: /en/tools/calc-size/ +[news3 sig size]: /zh/newsletters/2018/07/10/#unrelayable-transactions +[news101 fee overpayment attack]: /zh/newsletters/2020/06/10/#fee-overpayment-attack-on-multi-input-segwit-transactions +[batch graph]: https://github.com/jonasnick/secp256k1/blob/schnorrsig-batch-verify/doc/speedup-batch.md +{% endauto_anchor %} diff --git a/_includes/specials/taproot/zh/02-descriptors.md b/_includes/specials/taproot/zh/02-descriptors.md new file mode 100644 index 0000000000..ce7e266c0b --- /dev/null +++ b/_includes/specials/taproot/zh/02-descriptors.md @@ -0,0 +1,46 @@ +{% auto_anchor %} +[输出脚本描述符][topic descriptors] 为钱包提供了一种通用方式，用来存储生成地址所需的信息、有效扫描付款给这些地址的输出，以及之后从这些地址花费。此外，描述符相对紧凑且包含一个基础校验和，这使其在备份地址信息、在不同钱包之间复制或在合作提供多签的多个钱包之间共享时都非常方便。 + +尽管当前只有少数项目在使用描述符，但它们和相关的 [miniscript][topic miniscript] 项目有潜力显著提升不同钱包和工具之间的互操作性。随着越来越多的用户利用 taproot 带来的好处，通过[多签][topic multisignature]来加强安全性，以及通过备份花费条件来提高恢复能力，这一点将变得愈加重要。 + +在此之前，需要先对描述符进行更新以适配 taproot。最近合并的 [Bitcoin Core #22051][] 拉取请求正是针对这一需求。该语法设计允许使用单一描述符模板，同时提供使用 P2TR 密钥路径花费和脚本路径花费所需的全部信息。对于简单的单签名，以下描述符就足够了： + +``` +tr() +``` + +相同的语法也适用于多签和[阈值签名][topic threshold signature]。例如，Alice、Bob 和 Carol 使用 [MuSig][topic musig] 聚合它们的密钥，然后支付给 `tr()`。 + +出人意料的是，“`tr()` 中的 key” 并不会直接是地址中所编码的那个密钥。`tr()` 描述符遵循了 BIP341 中的[安全性建议][bip341 safety]，使用一个承诺于不可花费脚本树的内部密钥，这就消除了对简单密钥聚合方案（像 [MuSig][topic musig] 和 MuSig2 这类更先进的方案不受影响）的一个攻击。 + +对于脚本路径花费，新增了一种可指定二叉树内容的语法。例如，`{ {B,C} , {D,E} }` 描述了这样一棵树： + +``` +Internal key + / \ + / \ + / \ / \ + B C D E +``` + +可以将这棵树作为可选的第二个参数传入之前使用的描述符模板。例如，如果 Alice 希望能够通过密钥路径花费，但也允许 Bob、Carol、Dan 和 Edmond 以能够为她生成审计轨迹的脚本路径花费（但不对第三方链上监控暴露），她可以使用如下描述符： + +``` +tr( , { {pk(),pk()} , {pk(),pk()} ) +``` + +上述功能足以让描述符用于 taproot，但拉取请求 #22051 中提到仍有一些可能被添加的功能，用于让描述符更好地完整描述预期的策略： + +- *******无效化密钥路径：** 某些用户可能希望禁止通过密钥路径花费，从而强制使用脚本路径花费。现在可以在 `tr()` 第一个参数中使用不可花费的密钥来实现，但能够在描述符本身中记录这一偏好并让它计算出一个保护隐私的不可花费密钥路径将更好。 + +- *******Tapscript 多签：** 对于传统和 v0 segwit，`multi()` 和 `sortedmulti()` 描述符支持 `OP_CHECKMULTISIG` 操作码。为了在 taproot 中实现批量验证，基于脚本的多签在 tapscript 中的处理方式有所不同，因此 `tr()` 描述符目前需要通过 `raw()` 脚本来指定任何必需的多签操作码。对 tapscript 版本的 `multi()` 和 `sortedmulti()` 进行更新将非常有用。 + +- *******基于 MuSig 的多签：** 在本文前面，我们描述了 Alice、Bob 和 Carol 手动聚合它们的密钥，以使用一个 `tr()` 描述符。理想情况下，应当能有一个函数允许像 `tr(musig(, , ))` 这样指定，这样他们就能保留全部初始密钥信息并用它来填充它们协同签名所用 [PSBT][topic psbt] 中的各字段。 + +- *******时间锁、哈希锁和点锁：** 这些在闪电网络、[DLCs][topic dlc]、[coinswaps][topic coinswap] 以及许多其他协议中使用的强大结构，目前只能通过 `raw()` 函数来描述。可将它们直接加入描述符是可行的，但也可能会在描述符的姊妹项目 [miniscript][topic miniscript] 中添加对它们的支持。miniscript 整合到 Bitcoin Core 仍在进行中，但我们预期它的创新将和 PSBT、描述符等工具一样，推广到其他钱包中。 + +钱包并不需要实现描述符就能开始使用 taproot，但那些实现了描述符的，将为自己使用更高级的 taproot 功能奠定更好的基础。 + +{% include linkers/issues.md issues="22051" %} +[bip341 safety]: https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-22 +{% endauto_anchor %} diff --git a/_includes/specials/taproot/zh/03-p2wpkh-to-p2tr.md b/_includes/specials/taproot/zh/03-p2wpkh-to-p2tr.md new file mode 100644 index 0000000000..2658b3cd4d --- /dev/null +++ b/_includes/specials/taproot/zh/03-p2wpkh-to-p2tr.md @@ -0,0 +1,73 @@ +{% auto_anchor %} +对于已经支持接收和使用 v0 segwit P2WPKH 输出的钱包来说，将其升级到用于单签的 v1 segwit P2TR 应该相对容易。以下是主要步骤： + +- ******使用新的 BIP32 密钥推导路径：** 你不需要修改你的 [BIP32][] 分层确定性 (HD) 代码，并且你的用户也不需要更换种子。[^electrum-segwit] 然而，我们强烈建议你为你的 P2TR 公钥使用新的推导路径（例如由 [BIP86][] 定义）；如果你不这样做，当你在 ECDSA 和 [schnorr 签名][topic schnorr signatures]两者中都使用相同密钥时，可能会导致[潜在攻击][bip340 alt signing]。 + +- ******通过其哈希值调整你的公钥：** 尽管在单签场景中技术上并非必须，尤其当你的所有密钥都来自随机选定的 BIP32 种子时，BIP341 [建议][bip341 cite22]让你的密钥承诺到一个不可花费的脚本哈希树中。其操作很简单，只需要使用椭圆曲线加法操作，将你的公钥与该公钥哈希得到的曲线点相加即可。遵循这一建议的好处在于，如果你日后添加无脚本的[多签][topic multisignature]支持，或者为 [`tr()` 描述符][`tr()` descriptors]添加支持，你也可以使用相同的代码。 + +- ******创建你的地址并进行监控：** 使用 [bech32m][topic bech32] 来创建你的地址。付款将发送到脚本 `OP_1 `。你可以使用与扫描 v0 segwit 地址（如 P2WPKH）相同的方法来扫描支付到该脚本的交易。 + +- ******创建支出交易：** 对于 taproot 来说，所有的非见证字段都与 P2WPKH 相同，因此你无需担心交易序列化的改变。 + +- ******创建签名消息：** 这是对支出交易数据的承诺。大部分数据与为 P2WPKH 交易所签名的内容相同，但字段的顺序[已改变][BIP341 sigmsg]，并且有一些额外内容需要签名。实现这一点只需要对各种数据进行序列化和哈希处理，所以编写这部分代码应该相对容易。 + +- ******对签名消息的哈希进行签名：** 生成 schnorr 签名有多种方法。最好的方式是不“自己动手写加密”而是使用你信任的、经过充分审阅的库提供的函数。但如果因某些原因你无法这样做，[BIP340][] 提供了一种算法，如果你已经有可用于制作 ECDSA 签名的原语，那么实现它应该相当简单。当你获得签名后，将其放入输入的见证数据中，然后发送你的支出交易。 + +即使在 taproot 于区块 {{site.trb}} 激活之前，你也可以使用 testnet、公用默认 [signet][topic signet] 或者 Bitcoin Core 的私有 regtest 模式来测试你的代码。如果你为开源钱包添加了 taproot 支持，我们鼓励你将实现它的拉取请求链接添加到 Bitcoin Wiki 上的 [taproot 用法][wiki taproot uses]和 [bech32m 采用][wiki bech32 adoption]页面，以便其他开发者可以从你的代码中学习。 + +[^electrum-segwit]: + 当 Electrum 升级到 segwit v0 时，要求任何希望使用 bech32 地址接收资金的用户都生成新的种子。虽然这在技术上并非必要，但它使 Electrum 的作者能够在其自定义种子推导方法中引入一些新的[功能][electrum seeds]。其中一个功能是允许通过种子版本号来指定一个种子应当使用的脚本。这使得旧脚本可以被安全地逐步弃用（例如，未来某个版本的 Electrum 可能会发布，它将不再支持接收到传统的 P2PKH 地址）。 + + 大约在 Electrum 开发者部署其版本化种子同期，Bitcoin Core 的开发者开始使用 [输出脚本描述符][topic descriptors] 来解决相同的问题——允许逐步弃用脚本（同时也解决了其他问题）。下表对比了 Electrum 的版本化种子和 Bitcoin Core 的描述符与此前两者都使用的 *隐式脚本* 方法（目前在大多数其他钱包中仍普遍使用）。 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    脚本管理初始备份引入新脚本扫描（带宽/CPU 成本）弃用脚本
    + + 隐式脚本（例如 [BIP44][]） + + 种子词自动（无需用户操作）必须扫描所有受支持的脚本，O(n)无法警告用户他们使用了不受支持的脚本
    显式脚本（版本化种子）种子词（包含版本位）用户必须备份新的种子；资金要么被拆分到两个独立钱包中，要么需要用户将旧钱包的资金转移到新钱包只扫描单一脚本模板，O(1)警告用户有关不受支持的脚本
    + + 显式脚本（[描述符][topic descriptors]） + + 种子词和描述符用户必须备份新的描述符仅扫描实际使用过的脚本模板，O(n)；对于新钱包而言 n=1警告用户有关不受支持的脚本
    + +{% include linkers/issues.md issues="" %} +[electrum seeds]: https://electrum.readthedocs.io/en/latest/seedphrase.html#motivation +[bip340 alt signing]: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#alternative-signing +[bip341 cite22]: https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-22 +[`tr()` descriptors]: /zh/preparing-for-taproot/#taproot-描述符 +[bip341 sigmsg]: https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#common-signature-message +[wiki bech32 adoption]: https://en.bitcoin.it/wiki/Bech32_adoption +[wiki taproot uses]: https://en.bitcoin.it/wiki/Taproot_Uses +{% endauto_anchor %} diff --git a/_includes/specials/taproot/zh/04-why-wait.md b/_includes/specials/taproot/zh/04-why-wait.md new file mode 100644 index 0000000000..4da6ccbb66 --- /dev/null +++ b/_includes/specials/taproot/zh/04-why-wait.md @@ -0,0 +1,33 @@ +{% capture /dev/null %} + + +{% assign ante_trb = "709,631" %} + +{% assign safe_trb = "709,776" %} +{% endcapture %} +{% auto_anchor %} + +本系列之前的文章鼓励钱包和服务开发者立即开始实施 [Taproot][topic taproot] 升级，以便在 Taproot 激活时准备就绪。但我们也警告不要在区块 {{site.trb}} 前生成任何 P2TR 地址，否则可能导致服务或用户资金损失。 + +不建议提前生成地址的原因是，在区块 {{site.trb}} 之前，任何发送至 P2TR 式输出的资金均可被*任何人*花费。这些资金将完全无安全保障。但从该区块开始，数千个全节点将开始强制执行 [BIP341][] 和 [BIP342][]（以及关联的 [BIP340][]）的规则。 + +如果区块链重组能被完全排除，那么在看到最后一个 Taproot 前区块（区块 {{ante_trb}}）后立即生成 P2TR 地址是安全的。但存在对区块链重组的担忧——不仅是意外重组，还包括蓄意制造以窃取早期 P2TR 支付的资金。 + +设想大量用户希望成为首批接收 P2TR 支付的人。他们在看到区块 {{ante_trb}} 后立即天真地向自己发送资金。[^timelocked-trb] 这些资金在区块 {{site.trb}} 中是安全的，但可能被创建替代 {{ante_trb}} 区块的矿工窃取。如果发送至 P2TR 输出的资金价值足够大，尝试挖两个区块而非一个可能变得更为有利可图（详见[手续费狙击][topic fee sniping]主题）。 + +因此，在重组风险有效消除前，我们不建议软件或服务生成 P2TR 地址。我们认为等待激活后 144 个区块（约一天）是较为保守的安全边际，可在最小化风险的同时避免显著延迟用户享受 Taproot 优势。 + +简言之： + +- {{ante_trb}}: 最后一个允许任何人花费 P2TR 式输出资金的区块 +- {{site.trb}}: 首个要求 P2TR 输出必须满足 [BIP341][] 和 [BIP342][] 规则才能被花费的区块 +- {{safe_trb}}: 钱包可开始为用户提供 P2TR 输出的 [Bech32m][topic bech32] 接收地址的合理区块 + +以上均不影响本系列[首篇文章][taproot series 1]的建议——应尽快支持向 Bech32m 地址付款。若有人在您认为安全前请求向 P2TR 地址付款，风险由其自行承担。 + +[^timelocked-trb]: + 若用户希望在首个 Taproot 区块接收 P2TR 支付，应生成一个不与他人共享的地址，并创建 nLockTime 设为 {{ante_trb}} 的交易。该交易可在收到区块 {{ante_trb}} 后立即广播。nLockTime 将确保交易无法在 Taproot 规则生效的 {{site.trb}} 前被包含。若未充分理解新脚本类型和自定义锁定时间，此类操作可能存在风险，请谨慎处理。 + +[news139 st]: /zh/newsletters/2021/03/10/#taproot-activation-discussion +[taproot series 1]: /zh/preparing-for-taproot/#bech32m-发送支持 +{% endauto_anchor %} diff --git a/_includes/specials/taproot/zh/05-taproot-notebooks.md b/_includes/specials/taproot/zh/05-taproot-notebooks.md new file mode 100644 index 0000000000..54f1bb7cf7 --- /dev/null +++ b/_includes/specials/taproot/zh/05-taproot-notebooks.md @@ -0,0 +1,23 @@ +{% auto_anchor %} +将近两年前，James Chiang 和 Elichai Turkel 创建了一个[开源仓库][taproot-workshop]，其中包含一系列 Jupyter 笔记本，旨在为 Optech 组织的开发者培训提供 [Taproot][topic taproot] 技术相关内容。在旧金山、纽约和伦敦[举办][workshops]的研讨会收到了积极的反馈，但由于旅行限制，后续的线下研讨会未能如期进行。 + +自 Jupyter 笔记本发布以来，Taproot 发生了多项变更。然而，Taproot 支持已合并到 Bitcoin Core，这使得这些笔记本可以不再依赖于 Bitcoin Core 的自定义分支。开发者 Elle Mouton 友善地[更新了][mouton tweet]这些[笔记本][notebooks #168]，使其适应所有的更改，使其再次成为快速掌握 Taproot 算法和数据类型的绝佳实践工具。 + +这些笔记本分为四个部分： + +- ******第 0 部分** 包含一个帮助您设置环境的笔记本，涵盖椭圆曲线密码学的基础知识，并介绍 BIPs [340][BIP340]、[341][BIP341] 和 [342][BIP342] 中广泛使用的标签哈希。 + +- ******第 1 部分** 指导您创建 [Schnorr 签名][topic schnorr signatures]。掌握这些知识后，您将学习如何使用 [MuSig][topic musig] 协议创建[多重签名][topic multisignature]。 + +- ******第 2 部分** 带您全面了解 Taproot。首先回顾 Segwit v0 交易的基本原理，然后帮助您创建和发送 Segwit v1（Taproot）交易。在掌握第 1 部分知识后，您将学习如何使用 MuSig 创建并花费 Taproot 输出。随后，您将接触密钥调整（key tweaking）概念，并学习如何利用 Taproot 公钥承载数据承诺。掌握承诺创建后，您将了解 [Tapscript][topic tapscript]——其与传统及 Segwit v0 脚本的区别，以及如何创建 Tapscript 树的承诺。最后，一个简短的笔记本将介绍如何使用 Huffman 编码来创建最优的脚本树。 + +- ******第 3 部分** 提供了一个可选练习，内容是创建一个 Taproot 输出，该输出会随着未花费时间的增加而改变所需的签名数量——在正常情况下提供高效的花费方式，同时在出现问题时提供强大的备份方案。 + +这些笔记本包含众多相对简单的编程练习，确保您真正掌握所学内容。本专栏作者并非优秀的程序员，但能够在六小时内完成所有笔记本练习，并遗憾没有更早学习这些内容。 + +{% include references.md %} +[taproot-workshop]: https://github.com/bitcoinops/taproot-workshop +[workshops]: /zh/schnorr-taproot-workshop/ +[notebooks #168]: https://github.com/bitcoinops/taproot-workshop/pull/168 +[mouton tweet]: https://twitter.com/ElleMouton/status/1418108253096095745 +{% endauto_anchor %} diff --git a/_includes/specials/taproot/zh/06-multisignatures.md b/_includes/specials/taproot/zh/06-multisignatures.md new file mode 100644 index 0000000000..1be1c70a40 --- /dev/null +++ b/_includes/specials/taproot/zh/06-multisignatures.md @@ -0,0 +1,65 @@ +{% comment %}{% endcomment %} + +在撰写本文之前的 1,000 个区块中，11% 的交易输入包含了多签操作码。如果许多创建这些交易的用户和服务将多签操作码切换为无脚本的[多签][topic multisignature]，Taproot 的两个最大和最直接的好处将会显现。 + +第一个主要好处是交易大小的减少。基于脚本的多签随着更多密钥和签名的需求而增大，但多签则保持为一个恒定的小尺寸。最小的有效多签策略（1-对-2）所需的空间比一个可以涉及成千上万签署者的多签策略还要大。尺寸的减少直接导致了多签用户的手续费减少，同时也间接减少了所有用户的手续费，因为相同数量的已确认交易需求可以通过更小的区块空间得到满足。 + +{:.center} +![展示多签与多签操作码节省的图表](/img/posts/2021-07-multisignature-savings.png) + +第二个主要好处是隐私的提高。每次使用多签的交易都会在区块链上有明显的记录，观察者可以通过这些记录推测出个别用户的钱包历史和当前余额。例如，在区块 692,039 中，我们不仅可以区分多签交易和单签名交易，还可以区分不同的签名集合大小和多签的阈值。 + +{:.center} +![展示当前区块中见证不可替代性的插图](/img/posts/2021-07-multisig-unfungible.png) + +相比之下，第三方仅查看区块链数据时，无法知道支出者是否使用了多签。当多签用于密钥路径支出时，它与单签名支出无法区分。如果上述区块中的所有单签名和多签都切换为 P2TR 密钥路径支出，只有少数特殊的支出会因其脚本而被区分出来（即便是这些支出，也可能在最好的情况下使用密钥路径支出）。 + +{:.center} +![展示理想情况下可替代的见证如何呈现的插图](/img/posts/2021-07-multisignature-fungible.png) + +### 使用多签 + +我们知道有三种专为比特币设计的基于 Schnorr 的多签方案，它们都是 [MuSig][topic musig] 系列的一部分： + +- **MuSig**（也称为 MuSig1），实现起来相对简单，但在签名过程中需要三轮通信。 + +- **MuSig2**，同样实现起来较为简单。它消除了一个通信轮次，并将另一个通信轮次与密钥交换结合。这样可以使用与当前基于脚本的多签类似的签名过程。这确实需要存储额外数据，并且非常小心，确保你的签名软件或硬件不会被误导重复进行某部分签名会话。我们将在下周的 *为 Taproot 做准备* 栏目中更详细地探讨这种权衡。 + +- **MuSig-DN**（确定性随机数），实现起来复杂得多。参与者之间的通信无法与密钥交换结合，但它的优势在于不会受到重复会话攻击的影响。 + +所有签名者必须就使用哪种协议达成一致，因此可能会出现网络效应，许多实现选择使用相同的协议。MuSig 提案的作者 [建议][nick ruffing blog] 由于其相对简单性和高效性，MuSig2 将成为大多数实现的选择。 + +目前有一个开放的并正在积极开发的 [PR][-zkp 131]，用于向 libsecp256k1-zkp 项目添加 MuSig2 支持。我们预计大多数软件的基本多签工作流将如下所示： + +1. 每个参与者的钱包生成一个 [BIP32][] xpub，并通过[输出脚本描述符][topic descriptors]或其他方式与所有其他参与者共享（这与当前多签使用的方式相同）。 + +2. 任何一个钱包都可以通过将其在某个 BIP32 深度上的公钥与所有其他钱包在同一深度的公钥相结合，生成一个聚合公钥。这个聚合公钥可以用于接收 P2TR 支付。 + +4. 当其中一个钱包想要支出资金时，它使用基于 [PSBT][topic psbt] 的工作流，类似于当前使用基于脚本的多签的流程，但现在需要签署者之间进行两轮通信。在第一轮中，提议者创建未签名交易并包含一对随机生成的随机数。必须确保随机数的生成不是完全确定性的，以避免为不同的签名使用相同的随机数。提议者将包含随机数的 PSBT 发送给其他钱包。 + +5. 其他钱包接收 PSBT 并更新其中的随机数，然后将更新后的 PSBT 发送给其他钱包，或发送给为钱包提供信任的协调员。 + +6. 当所有钱包都获得所有随机数对后，它们将它们合并为一个单一的随机数。协调员也可以为它们执行此操作。然后，所有钱包更新它们的 PSBT 版本并添加各自的部分签名，将 PSBT 发送给其他钱包或协调员。最后，所有部分签名将合并生成最终签名，并将交易广播。 + +### 阈值签名 + +仅凭 MuSig 系列的多签方案，你只能实现 n 对 n 的签名——每个贡献密钥的参与者必须也贡献一个部分签名以形成最终签名。这在一些当前使用的基于脚本的多签用例中运行良好，例如支出 2-对-2 的闪电网络资金输出，但它与其他流行的策略有所不同，例如许多交易所使用的 2-对-3 多签脚本。 + +目前，几位开发者正在研究[阈值签名][topic threshold signature]方案，它将为 k-对-n 场景带来与多签相同的效率和隐私好处，但在这些方案可用之前，有一个简单的技巧可以使用。 + +在许多阈值情况下，事先知道哪些参与者最有可能签名。例如，在一个 2-对-3 的场景中，可能已经知道通常 Alice 和 Bob 会共同签名，而 Carol 只有在其他两人都无法签名时才会签名。对于这种情况，主密钥可以使用多签进行 Taproot 密钥路径支出（例如 Alice 和 Bob 之间），而额外的结果（如 Alice 和 Carol，或 Bob 和 Carol）可以使用 `OP_CHECKSIG` 操作码在 [tapscripts][topic tapscript] 的树状结构中单独分支。 + +在正常情况下，以上方案与单签名或多签交易具有相同的效率和隐私。在异常情况下，支出仍然按预期工作，并且比在链上发布多签参数更高效和隐私。 + +尽管希望最小化费用并实现最大隐私的用户最终可能会切换到纯阈值签名方案，但上述[方案][erhardt post]可能仍会继续使用，因为它为审计员（如果他们知道所有参与者的公钥）提供了关于哪些相应的私钥被用来签名的链上证明。 + +**编辑：**关于 MuSig2 的部分文字已更新，以澄清在预共享随机数时需要格外小心，因此预计大多数使用 MuSig2 的常规钱包将在需要时生成新的随机数。我们感谢 #secp256k1 IRC 频道成员分享他们的担忧。 + +[nick ruffing blog]: https://medium.com/blockstream/musig2-simple-two-round-schnorr-multisignatures-bf9582e99295 +[-zkp 131]: https://github.com/ElementsProject/secp256k1-zkp/pull/131 +[erhardt post]: https://murchandamus.medium.com/2-of-3-multisig-inputs-using-pay-to-taproot-d5faf2312ba3 diff --git a/_includes/specials/taproot/zh/07-nonces.md b/_includes/specials/taproot/zh/07-nonces.md new file mode 100644 index 0000000000..e59da8dc8b --- /dev/null +++ b/_includes/specials/taproot/zh/07-nonces.md @@ -0,0 +1,30 @@ +在上周的专栏中，我们讨论了[多签][topic multisignature]并通过 [MuSig2][topic musig] 举例进行说明。我们所做的描述在技术上是正确的，但有几位参与 MuSig2 的密码学家[担心][secp256k1 log]我们建议的使用方法是危险的。我们[更新][optech #622]了我们的描述，以解决他们的直接担忧，并开始更深入地研究这一问题。在本文中，我们将探讨我们所学到的，可能是安全实施多重签名的最大挑战：避免重用 nonce。 + +为了验证比特币中的签名，您需要通过签名、签名的消息（例如交易）、您的公钥和公有 nonce 来填充一个公开已知的方程式。只有在您知道私钥和私有nonce的情况下，才能平衡这个方程式。因此，任何看到该方程式的人都可以认为这个消息和公钥的签名是有效的。 + +将签名和消息包括在方程式中的动机是显而易见的。公钥是私钥的代替，那么公有 nonce 的作用是什么呢？如果它不存在，方程式中除了您的私钥以外的所有值都是已知的，这意味着我们可以使用基础代数来求解唯一的未知值。但代数无法求解两个未知数，因此 nonce 的私有形式能够保持您的私钥的秘密。正如公钥在签名方程式中是私钥的代替一样，nonce 的公有形式则代替其私有形式。 + +在这个背景下，nonce 不仅是*一次性使用的数字*，而且**必须**仅使用一次。如果您使用相同的 nonce 进行两次不同的签名，那么这两个签名方程式可以合并，nonce 可以被消除，从而有人可以解决唯一剩下的未知数——您的私钥。如果您使用[BIP32][] +标准派生（非硬化派生），这可能是几乎所有多重签名钱包都会使用的方式，那么一旦暴露一个私钥，就意味着该BIP32路径下的所有其他私钥都会被暴露（甚至可能在其他路径中也是如此）。这意味着一个已经收到了比特币的多重签名钱包，如果其中一个签名者重用了一个 nonce，那么该签名者在这个钱包下的所有地址都会被泄露。 + +单签名钱包，或者使用基于脚本的多重签名的钱包，可以通过一个简单的技巧来避免重用 nonce：他们使得 nonce 依赖于他们签署的消息。如果消息发生任何变化，nonce 也会变化，因此它们不会重用 nonce。 + +但多重签名不能使用这个技巧。它们要求每个共同签名者不仅贡献一个部分签名，还要贡献一个部分公有 nonce。多个部分公有 nonce 被组合起来生成一个聚合公有 nonce，该 nonce 将与签名的消息一起使用。 + +这意味着，即使交易保持不变，也不应该多次使用相同的部分 nonce。如果第二次签署时，某个共同签名者改变了他们的部分 nonce（改变了聚合 nonce），您的第二个部分签名实际上就是为一个不同的消息签署的，这会暴露您的私钥。由于对于每个参与方来说，让他们的私有 nonce 依赖于所有其他方的部分公有 nonce 是完全不可能的，因此在多重签名中没有简单的方法来避免nonce重用。 + +乍一看，这似乎不是一个大问题。只需要让签名者每次签署时生成一个新的随机 nonce。实现起来比听起来要难得多——自 [2012 年][tcatm post]以来，人们一直在发现依赖生成随机 nonce 的钱包中的比特币丢失漏洞。 + +但即便钱包能够生成高质量的随机 nonce，它仍然需要确保每个 nonce 只使用一次。这是一个真正的挑战。在我们上周专栏的原始版本中，我们描述了一个MuSig2兼容的冷钱包或硬件签名设备，它会在首次运行时生成大量的 nonce。然后，钱包或设备需要确保每个nonce 从未与多个部分签名一起使用。虽然这听起来简单——每次使用 nonce 时递增计数器——但当软件和硬件可能因偶然原因出现故障，或者受到外部甚至恶意干预时，这可能会变得非常复杂。 + +也许钱包减少 nonce 重用风险的最简单方法是尽可能缩短 nonce 的存储时间。我们上周的示例建议将 nonce 存储几个月或几年，这不仅为出错提供了大量机会，而且还需要将 nonce 记录到持久化存储介质中，这些介质可能会被备份并恢复，或以其他方式被置于意外状态。使用MuSig2的另一种替代方式是仅在需要时创建 nonce ，例如在接收到 [PSBT][topic psbt] 时。 nonce 可以存储在易失性内存中，仅在需要时使用，因此在发生意外情况（例如软件崩溃或断电）时，它们会被自动销毁（使其无法重用）。 + +然而，致力于解决这个问题的密码学家们似乎对原始 MuSig 协议（MuSig1）和 MuSig2 中缺乏万无一失的方法来防止 nonce 重用感到非常担忧。MuSig-DN（确定性 nonce ）确实提供了解决方案，但它复杂且速度较慢（一个 alpha 版本在 2.9 GHz 的 Intel i7 处理器上生成 nonce 证明几乎需要一秒钟；我们不知道在16 MHz硬件签名设备上，使用一个处理器不那么先进的设备需要多长时间）。 + +我们给所有实施多重签名签署的人提供的建议是，在进行任何重大时间或资源投入之前，考虑前往 [#secp256k1][] IRC 聊天室或比特币密码学家聚集的其他地方，描述您的计划。 + +[secp256k1 log]: https://gnusha.org/secp256k1/2021-08-04.log +[tcatm post]: https://web.archive.org/web/20160308014317/http://www.nilsschneider.net/2013/01/28/recovering-bitcoin-private-keys.html +[#secp256k1]: https://web.libera.chat/?channels=#secp256k1 +[p4tr multisignatures]: /zh/preparing-for-taproot/#多签 +[optech #622]: https://github.com/bitcoinops/bitcoinops.github.io/pull/622 diff --git a/_includes/specials/taproot/zh/08-signature-adaptors.md b/_includes/specials/taproot/zh/08-signature-adaptors.md new file mode 100644 index 0000000000..24a125f6b7 --- /dev/null +++ b/_includes/specials/taproot/zh/08-signature-adaptors.md @@ -0,0 +1,31 @@ +想象有人提出，如果有人能猜出他最喜欢的一个非常大的数字，他将向某个特定的慈善机构捐赠 1,000 BTC。捐赠者可以通过以下简单的方法实现这一目标：创建一笔支付 1,000 BTC 的未签名交易，然后发布该交易的签名的加密版本，其中最喜欢的数字作为解密密钥。 + +理论上，任何人只要猜对了这个数字，就可以解密签名并广播交易，从而支付给慈善机构。然而，如果捐赠者使用 AES 等标准加密方案，在解密之前，第三方无法轻松验证该签名是否对该交易有效。因此，任何想投入精力猜测数字的人都必须信任捐赠者的诚意，而不是一个恶作剧者。 + +让我们把这个问题再扩展一点。第三方 Alice 和 Bob 想要就签名是否会被公布进行下注。他们或许可以要求签名者提供签名的哈希值，并将其用作 [HTLC][topic htlc] 的哈希值，但这仍然要求信任捐赠者的诚实行为。即使签名最终被公布，捐赠者仍可以通过提供错误的哈希值来破坏 Alice 和 Bob 的合约。 + +### 适配器签名的魔法 + +[适配器签名][topic adaptor signatures]（也常被称为 *adaptor signatures* 或 *一次性可验证加密签名*）可以解决这些问题——事实上，它还能解决当今比特币系统中许多实际遇到的问题。虽然适配器签名可以与比特币当前的 ECDSA 签名方案一起使用，但在 [BIP340][] 定义的 [Schnorr 签名][topic schnorr signatures]（用于 Taproot）的实现中，适配器签名的使用会更加私密且无需额外成本。让我们看看，如果使用适配器签名，上述示例会发生怎样的变化。 + +与之前一样，捐赠者准备了一笔 1,000 BTC 的交易。他们的签名过程与通常方式几乎相同，唯一的不同点是，他们会以两部分生成随机数（nonce）：一个真正的随机数（将永远保密），以及他们最喜欢的数字（起初也是保密的，但其他人发现它是安全的）。捐赠者使用这两个值生成一个完整的有效签名，将它们相加作为单个随机数。 + +BIP340 签名承诺使用随机数的两种形式：一个数值表示（称为 *标量*），通常只有签名者知道；以及一个椭圆曲线（EC）上的 *点*，用于公示以支持验证。 + +捐赠者从其有效签名的承诺部分中减去隐藏的标量。这使得签名变得不完整（因此无效），但允许捐赠者共享（无效的）签名承诺、（有效的）完整随机数的椭圆曲线点，以及（有效的）隐藏数字的椭圆曲线点。这三部分信息共同构成了一个*适配器签名*。 + +使用 BIP340 签名验证算法的一个小变种，任何人都可以验证该适配器签名是否能通过简单地将隐藏的标量加回当前无效的签名承诺来提供一个有效签名。即使不知道隐藏的数字是什么，这也是可以验证的。简而言之，现在用户可以无需信任地开始猜测隐藏标量的值，确保他们只要猜对，就能获得签名并发送交易。 + +像所有收到捐赠者适配器签名的人一样，Alice 和 Bob 现在也得到了隐藏数字的椭圆曲线点。同样，他们不知道实际的标量。但请记住，捐赠者只是通过从签名承诺中减去隐藏数字来使签名变得无效，同时仍然让签名承诺包含隐藏数字的椭圆曲线点。Alice 也可以通过类似的方式创建一个无效签名：她可以创建自己的随机数对，在生成（无效的）签名时使用其私有部分，但在签名中承诺使用她的公有随机数与捐赠者适配器签名中的椭圆曲线点的聚合。这将生成一个支付给 Bob 的适配器签名。如果 Bob 知道隐藏的标量，他可以将该适配器签名转换为有效签名，并发送交易，从而赢得赌注。 + +那么，Bob 如何得知中奖数字？他是否必须等待某个猜对的人发布新闻稿？不需要。请再次回忆，捐赠者发布的适配器签名是他们的实际签名减去标量。当隐藏数字被发现，有人发送 1,000 BTC 交易时，他们必须发布原始（有效的）签名承诺。Bob 可以取该（有效的）签名承诺，并从中减去原始适配器签名中的（无效）签名承诺，以得出标量。然后，他可以使用该标量将 Alice 的适配器签名转换为有效签名。 + +### 多签适配器 + +前一节展示了个体用户如何调整其签名方式以生成适配器签名。此外，多方[多签][topic multisignature]也可以使用相同的技巧。这一点极为重要，因为许多使用适配器签名的场景都需要两方的协作。 + +例如，在 Alice 和 Bob 进行上述赌注时，他们可以首先将资金存入一个只能由他们两人联合签名的脚本地址。然后，Alice 可以以适配器签名的形式生成她的部分签名；如果 Bob 发现隐藏的数字，他可以将 Alice 的适配器转换为她的有效部分签名，并再提供他的部分签名，以生成完整的签名来花费这些资金。 + +这使得适配器签名继承了多签的所有优势：它们看起来与单个签名相同，占用的空间也相同，从而最小化手续费并最大化隐私性和可替代性。 + +在下周的 *为 Taproot 做准备* 专栏中，我们将探讨适配器签名的一种主要应用场景：点时间锁合约（[PTLCs][topic ptlc]），这是一种对广泛用于闪电网络、币交换以及其他协议中的哈希时间锁合约（[HTLCs][topic htlc]）的升级改进。 \ No newline at end of file diff --git a/_includes/specials/taproot/zh/09-ptlcs.md b/_includes/specials/taproot/zh/09-ptlcs.md new file mode 100644 index 0000000000..ca10ade71e --- /dev/null +++ b/_includes/specials/taproot/zh/09-ptlcs.md @@ -0,0 +1,70 @@ +在[上周的专栏][p4tr sig adaptors]中，我们探讨了[签名适配器][topic adaptor signatures]，以及 [Taproot][topic taproot] 与 [Schnorr 签名][topic schnorr signatures]的激活将如何使适配器的使用更加私密和高效。签名适配器可以在比特币上以多种方式应用，其中最直接受益的用例之一是点时间锁定合约（Point Time Locked Contracts，简称 [PTLCs][topic ptlc]），它可以替代多年来使用的[哈希时间锁定合约（HTLCs）][topic htlc]。这将带来多个优势，但也伴随着一些挑战。为了理解两者，我们首先从一个简化的 HTLC 示例开始，该示例适用于链下 LN 支付、链上 CoinSwap，或像 Lightning Loop 这样结合链上和链下的混合系统——正是这种灵活性，使得 HTLC 被广泛使用。 + +Alice 想通过 Bob 向 Carol 支付，但 Alice 和 Carol 都不想信任 Bob。Carol 生成一个随机的前镜像（preimage），并使用 SHA256 算法对其进行哈希。然后，Carol 将哈希值提供给 Alice，并保留前镜像的秘密。Alice 发起支付给 Bob，Bob 可以使用自己的公钥签名加上前镜像来领取资金；或者，在 10 个区块后，Alice 可以使用自己的公钥签名将交易退还给自己。以下是用 Minsc 语言描述的[该 HTLC 逻辑][htlc1 minsc]： + +```hack +(pk($bob) && sha256($preimage)) || (pk($alice) && older(10)) +``` + +随后，Bob 可以使用几乎相同的脚本向 Carol 发起支付（可能扣除一些费用），但角色[相应调整][htlc2 minsc]，并且退款超时更短： + +```hack +(pk($carol) && sha256($preimage)) || (pk($bob) && older(5)) +``` + +现在，Carol 可以在 5 个区块内使用前镜像领取来自 Bob 的付款，这会将前镜像暴露给 Bob，使得 Bob 也能在 5 个区块内使用它向 Alice 领取付款。 + +### HTLC 的隐私问题 + +如果上述脚本在链上发布，由于相同的哈希和前镜像被重复使用，观察者可以立即看出 A 通过 B 向 C 付款。这对于同链和跨链的 CoinSwap 可能是个重大问题。不那么明显的是，这对 LN 等链下路由协议也是个问题。如果一个路径较长的支付中，有人控制多个跳数，他们可以通过检测相同的哈希和前镜像的重复使用来识别哪些节点是路由节点，从而推测出其余节点很可能是支付方或接收方。这是 可链接性问题（linkability problem）的一个组成部分，而这可能是 LN 目前最大的隐私弱点。 + +![HTLC 可链接性问题示意图](/img/posts/2021-07-ln-linkability1.dot.png) + +虽然[多路径支付（MPP）][topic multipath payments]在一定程度上缓解了 LN 付款金额的可链接性问题，但它可能会加剧哈希可链接性问题，因为它给了监听节点更多机会来关联哈希值。 + +HTLC 的另一个问题是，任何需要链上执行的脚本都会与普通的支付脚本明显不同。这使得监测者更容易识别使用模式，并可能有效推测特定用户的信息。 + +### PTLC 解决方案 + +在前面的 Minsc 脚本中，我们使用了一个函数，只有在传入一个预先选择的特定值（前镜像）时，该函数才会返回 true。而[签名适配器（signature adaptors）][topic adaptor signatures] 也有类似的特性——它们只有在传入一个特定值（标量）时，才能转换成有效签名。如果暂时忽略[多重签名][topic multisignature]，我们可以将 HTLC 脚本转换为以下 PTLC 形式： + +```hack +(pk($bob) && pk($alice_adaptor)) || (pk($alice) && older(10)) +``` + +```hack +(pk($carol) && pk($bob_adaptor)) || (pk($bob) && older(5)) +``` + +简单来说，Carol 给 Alice 一个椭圆曲线（EC）点，它对应一个隐藏的标量。Alice 使用该点和她选择的公钥创建一个签名适配器并交给 Bob；Bob 再使用相同的点和自己选择的公钥创建另一个适配器交给 Carol。Carol 通过转换 Bob 的适配器为有效签名来揭示标量，从而领取 Bob 的资金。随后，Bob 从 Carol 的有效签名中恢复该标量，并使用它转换 Alice 的适配器为有效签名，以领取 Alice 的资金。 + +这解决了链上监测的可链接性问题，因为区块链上展示的只是不同公钥对应的有效签名。第三方无法知道是否使用了适配器签名，更无法得知适配器的标量值。 + +然而，上述流程并不能防止参与路由的监听节点关联支付。如果所有支付都基于相同的标量，它们的可链接性就与使用哈希锁和前镜像一样高。为了解决这个问题，每个路由节点可以选择自己的标量，并在支付通过该节点时移除相应的点。我们修改示例如下： + +和之前一样，Carol 给 Alice 一个点，但这次 Alice 还向 Bob 请求一个点。Alice 构造的适配器包含 Carol 的点和 Bob 的点的聚合。Bob 知道自己的点，因此可以从 Alice 传来的适配器中移除它。这样，Bob 得到的结果（他不知道的是，这实际上只是 Alice 从 Carol 那里获得的点），用于创建他给 Carol 的适配器。Carol 知道最终的标量，所以可以转换 Bob 的适配器为有效签名。Bob 从 Carol 的签名中恢复 Carol 的标量，并结合自己的标量转换 Alice 的适配器为有效签名。 + +在 Alice→Bob 和 Bob→Carol 这两个跳数中，使用了不同的 EC 点和标量，消除了可链接性。扩展到更长的路径后，我们可以看到隐私性的改进： + +![PTLC 取消可链接性示意图](/img/posts/2021-07-ln-linkability2.dot.png) + +正如上周提到的，Schnorr 签名使得将适配器签名与多重签名结合变得简单。对于一般的 PTLC，这使得链上的脚本可以进一步简化为： + +```hack +pk($bob_with_alice_adaptor) || (pk($alice) && older(10)) +``` + +```hack +pk($carol_with_bob_adaptor) || (pk($bob) && older(5) ) +``` + +在 Taproot 方案下，左分支可以成为密钥路径（keypath），右分支可以成为 Tapleaf。如果支付成功路由，Bob 和 Carol 可以在链上结算，而无需对手方进一步配合，从而使此类路由支付与单签支付、普通多重签名支付和合作解决的合约难以区分，同时还能最大化节省区块空间。如果需要执行退款条件，这种方式仍然相当高效，并具有良好的隐私性——pk(x) && older(n) 代码与[降级多签][degrading multisig]、[强制持币][enforced hodling]等多种可能的脚本难以区分。 + +在下周的专栏中，我们将邀请一位我们最喜爱的 LN 开发者撰写客座文章，讨论 LN 采用密钥路径支付、多重签名、PTLCs 以及 Taproot 启用的其他特性的必要变更。 + +[p4tr sig adaptors]: /zh/preparing-for-taproot/#签名适配器 +[htlc history]: /en/topics/htlc/#history +[htlc1 minsc]: https://min.sc/#c=%2F%2F%20Traditional%20preimage-based%20HTLC%0A%24alice%20%3D%20A%3B%0A%24bob%20%3D%20B%3B%0A%24carol%20%3D%20C%3B%0A%24preimage%20%3D%20H%3B%0A%0A%28pk%28%24bob%29%20%26%26%20sha256%28%24preimage%29%29%20%7C%7C%20%28pk%28%24alice%29%20%26%26%20older%2810%29%29 +[htlc2 minsc]: https://min.sc/#c=%2F%2F%20Traditional%20preimage-based%20HTLC%0A%24alice%20%3D%20A%3B%0A%24bob%20%3D%20B%3B%0A%24carol%20%3D%20C%3B%0A%24preimage%20%3D%20H%3B%0A%0A%28pk%28%24carol%29%20%26%26%20sha256%28%24preimage%29%29%20%7C%7C%20%28pk%28%24bob%29%20%26%26%20older%285%29%29 +[degrading multisig]: https://github.com/bitcoinops/taproot-workshop/blob/master/3.1-degrading-multisig-case-study.ipynb +[enforced hodling]: https://bitcoin.stackexchange.com/questions/69809/op-checklocktimeverify-op-hodl-script diff --git a/_includes/specials/taproot/zh/10-ln-with-taproot.md b/_includes/specials/taproot/zh/10-ln-with-taproot.md new file mode 100644 index 0000000000..b43acccff3 --- /dev/null +++ b/_includes/specials/taproot/zh/10-ln-with-taproot.md @@ -0,0 +1,65 @@ +*[ZmnSCPxj][]，闪电网络协议开发者* + +本文将探讨 Taproot 为闪电网络带来的两大隐私特性: + +* 闪电网络上的 [PTLCs][topic ptlc] +* P2TR 通道 + +### 闪电网络上的 PTLCs + +PTLC 可实现[多项功能][suredbits payment points]，其中对闪电网络而言，最大优势在于无需路径随机化即可实现[支付解关联][p4tr ptlcs]。[^route-randomization]在单路径或[多路径支付][topic multipath payments]中，每个节点均可获得用于调整转发 PTLC 的特定参数，实现**支付解关联**，此举可消除各转发节点通过唯一哈希值[关联][news163 htlc problems]具体支付的可能性。 + +需明确，**PTLC 并非隐私万能解**。若监控节点观察到特定时间锁和金额的支付转发后，短期内发现另一节点转发具有*更短时间锁*及*稍小金额*的支付，这些事件*极可能*为同一支付路径的组成部分(即便无法通过哈希值唯一标识进行关联)。然而，变更带来以下优势: + +* 分析难度提升：监控节点依据的关联概率降低，其信息价值相应减少。 +* 多路径支付的解关联增强：不同路径间的时间锁与金额关联性大幅减弱，且若闪电网络持续发展，海量支付将削弱时序关联的有效性。 +* 成本未增加：相较于 [HTLC][topic htlc]，PTLC 无需额外开销(甚至可能因[多签效率优化][p4tr multisignatures]稍有节约)。 + +理论而言，无需关闭现有通道即可通过链下交易将预-Taproot 通道升级至支持 PTLC。现有通道可通过将非 Taproot 资金输出转移至含 PTLC 的 Taproot 输出实现兼容。因此，用户无需承担额外成本，仅需节点及其通道对端升级软件即可支持 PTLC。 + +但 PTLC 的实际使用需支付路径中**所有**节点均支持该协议。这意味着需足够多节点完成升级后方可广泛采用。这些节点未必需支持同一 PTLC 协议(允许存在多个协议)，但均须至少支持一种。协议多样化将增加维护负担，开发者*期望*尽量减少协议数量(理想状态为单一协议)。 + +### P2TR 通道 + +提升基础层与闪电网络层解关联的方案之一是[未公开通道][topic unannounced channels]——此类通道不在闪电网络的 gossip 协议中广播。 + +但当前预-Taproot 的比特币网络中，所有 2-2 多签脚本均需明示编写。闪电网络作为 2-2 多签的最大用户，其通道的关闭交易极易被区块浏览器识别为闪电网络的链上活动，进而被追溯资金流向。任何新生成的 P2WSH 输出极可能为另一未公开通道。因此，未公开通道一旦关闭，仍存在链上识别的可能(伴随误判率)。 + +Taproot 借助 [schnorr 签名][topic schnorr signatures]使 n-of-n 多签交易与 1-of-1 单签交易在链上表现无异。经技术优化后，[k-of-n][topic threshold signature] 多签交易亦可实现等价匿名性。因此，我们可采用 Taproot 地址(即 P2TR 通道)作为闪电通道的链上基础，提升未公开通道的**链上隐私**。[^two-to-tango] + +此(微小)隐私提升同样惠及公开通道。公开通道仅在存续期广播，监控者无法获取历史通道信息。若需追踪所有公开通道，需自行存储全部数据，无法依赖"归档"节点。 + +此外，Taproot 密钥路径交易比现有闪电网络 P2WSH 交易体积减少 38.5 vbytes(40%)。但需注意，**现有 pre-taproot 通道无法升级至 P2TR 通道**，因现有通道采用 P2WSH 2-2 模式，必须关闭后重新开启 P2TR 通道。 + +理论上，资金输出形式仅关乎通道双方节点。其他节点无需关心通道保证金的技术细节。但公开通道需通过 gossip 网络广播。节点收到通道信息后，将查询其信任的比特币全节点验证资金 UTXO 的存在性及**地址正确性**。地址验证机制可抵御垃圾通道的传播——需真实资金支撑才能发布通道信息。因此实践中，P2TR 通道仍需一定程度的远程兼容性，否则发送方将因无法验证存在性而忽略此类通道。 + +### 时间预估 + +在去中心化开源项目中，最佳时间预测法为参考历史类似功能的开发周期。近期重大特性中，与闪电网络 PTLC 复杂度相当的是 [dual funding][topic dual funding] 协议。Lisa Neigut 在 [BOLTs #524][] 中提出初始方案后，历时两年半完成首个主网 [dual funding 通道][first dual funded tx]。鉴于 PTLC 需全网路径节点兼容(包括接收方)，预估在具体协议提案后需三年零九个月实现广泛采用。 + +P2TR 通道虽仅需两节点支持，但其收益较低，故开发优先级受限。多数开发者将优先实现 PTLC 支持，预计 P2TR 通道的开发将在 [SIGHASH_ANYPREVOUT][topic sighash_anyprevout] 或 Decker-Russell-Osuntokun([Eltoo][topic eltoo])方案落地后展开。 + +[^route-randomization]: + 付款方可选择复杂路径(路径随机化)弱化 HTLC 关联分析，然存在弊端: + + * 复杂路径不仅成本更高且可靠性下降(需要支付更多转发节点费用,同时依赖更多节点*成功*完成转发)。 + * 路径延伸导致支付信息被暴露于*更多*节点,大幅增加遭遇*监控节点*的可能性。 + 因此路径随机化非完美隐私解决方案。 + +[^planning-details]: + 是的，细节很重要，但也不重要：从足够高的视角来看，开发中某些方面的意外困难和其他方面的意外顺利会相互抵消，我们最终会发现每个主要功能大致都在某个平均时间范围内。如果我们想要做出**准确**的估计，而不是**让人感觉良好**的估计，我们应该采用避免[规划谬误][WIKIPEDIAPLANNINGFALLACY]的方法。因此，我们应该只关注一个类似的、已完成的功能，*故意忽略*其细节，仅仅看它实现所花费的时间。 + +[^two-to-tango]: + 在考虑未公开通道时，记住需要“二人共舞”，如果一个未公开通道被关闭，那么其中一个参与者（例如，一个闪电网络服务提供商）将剩余的资金用于一个*公开*通道，区块链浏览器可以推测这些资金的来源有一定概率是曾经关闭的未公开通道。 + +{% include references.md %} +{% include linkers/issues.md issues="524" %} +[zmnscpxj]: https://zmnscpxj.github.io/about.html +[suredbits payment points]: https://suredbits.com/payment-points-monotone-access-structures/ +[WIKIPEDIAPLANNINGFALLACY]: https://en.wikipedia.org/wiki/Planning_fallacy +[neigut first dual funded]: https://medium.com/blockstream/c-lightning-opens-first-dual-funded-mainnet-lightning-channel-ada6b32a527c +[first dual funded tx]: https://blockstream.info/tx/91538cbc4aca767cb77aa0690c2a6e710e095c8eb6d8f73d53a3a29682cb7581 +[russell deployable ln]: https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf +[p4tr ptlcs]: /zh/newsletters/2021/08/25/#准备-taproot-10ptlcs +[p4tr multisignatures]: /zh/newsletters/2021/08/04/#准备-taproot-7多签 +[news163 htlc problems]: /zh/newsletters/2021/08/25/#htlc-的隐私问题 diff --git a/_includes/specials/taproot/zh/11-vaults-with-taproot.md b/_includes/specials/taproot/zh/11-vaults-with-taproot.md new file mode 100644 index 0000000000..1c1a3acc9f --- /dev/null +++ b/_includes/specials/taproot/zh/11-vaults-with-taproot.md @@ -0,0 +1,43 @@ +*由 [Antoine Poinsot][darosior]，[Revault][] 开发者* + +比特币[保险库][topic vaults]是一种需要两笔连续交易才能使用户从钱包中支出资金的合约。已经提出了许多此类协议（单方或多方，有或没有[契约][topic covenants]），因此我们将重点讨论它们的共同点。 + +与通过单一链上交易执行多次支付的[批量支付][topic payment batching]相反，保险库使用多笔交易来执行一次支付。第一笔交易，即 *unvault*，支付给： + +1. 在相对时间锁后的一组公钥，或 +2. 没有任何时间锁的单个公钥。 + +第一种支出路径是主路径，预计将与“热”密钥一起使用。第二种支出路径允许进行*取消*交易（有时称为*回收*、*恢复*或*重新保险库化*交易）。 + +因此，比特币保险库与 [Taproot][topic taproot] 的洞察相反，后者认为大多数合约都有一个合作签名的“顺利路径”（争议路径通常包含时间锁）。比特币保险库恰恰相反。*支出* 交易必须使用 Taproot 脚本发送路径，因为它受到相对时间锁的限制[^0]，而 *取消* 交易理论上可以使用密钥支出路径。 + +由于多方保险库在实践中已经需要大量交互，它们理论上可以受益于通过 [BIP340][] 实现的交互式[多签名][topic multisignature]和 [门限签名][topic threshold signature]方案，例如 [Musig2][topic musig]。然而，这些方案也带来了新的安全挑战。由于保险库协议旨在用于冷存储，设计选择更为保守，因此保险库可能会是最后一个使用这些新技术的协议。 + +通过切换到 Taproot，保险库还可以受益于隐私和效率的轻微改进，得益于使用梅尔克分支和更短的 BIP340 签名（尤其是对于多方签名）。例如，在一个包含 6 个“冷”密钥和 3 个“活跃”密钥（门限为 2）的多方设置中，*unvault* 输出脚本可以表示为深度为 2 的 Taproot，叶子如下： + +- ` CSV DROP CHECKSIG CHECKSIGADD 2 EQUAL` +- ` CSV DROP CHECKSIG CHECKSIGADD 2 EQUAL` +- ` CSV DROP CHECKSIG CHECKSIGADD 2 EQUAL` +- ` CHECKSIG CHECKSIGADD CHECKSIGADD CHECKSIGADD CHECKSIGADD CHECKSIGADD 6 EQUAL` + +在 Taproot 中，只需要揭示用于支出输出的叶子，因此交易的重量显著小于等效的 P2WSH 脚本： + +```text +IF + 6 6 CHECKMULTISIG +ELSE + CSV DROP + 2 3 CHECKMULTISIG +ENDIF +``` + +尽管在成功支出时撤销分支可以被隐藏（如果使用多签门限，它的存在和参与者的数量也会被模糊化），但隐私提升是有限的，因为保险库的使用模式在链上将是显而易见的。 + +最后，像大多数预签名交易协议一样，保险库协议将极大受益于基于 Taproot 的进一步比特币升级，例如 [BIP118][] 的 [SIGHASH_ANYPREVOUT][topic sighash_anyprevout]。尽管这需要进一步的谨慎和协议调整，`ANYPREVOUT`和`ANYPREVOUTANYSCRIPT`将使*取消*签名可重新绑定，这将大大减少交互性并允许 0(1) 的签名存储。这对 [Revault 协议][revault protocol] 中的*紧急*签名尤为有趣，因为它将大大减少 DoS 攻击面。通过在输出中使用`ANYPREVOUTANYSCRIPT`签名，您实际上是在创建一个契约，通过限制该交易支出此币时如何创建其输出。未来更具可定制性的签名哈希将允许更灵活的限制。 + +[^0]: + 如果已知，您可以预签 支出 交易并指定 nSequence，但这样您就不再需要“活跃”密钥的备用支出路径。而且，通常您在收到比特币时并不知道如何花费它们。 + +[darosior]: https://github.com/darosior +[revault]: https://github.com/revault +[revault protocol]: https://github.com/revault/practical-revault diff --git a/_includes/specials/taproot/zh/12-backups.md b/_includes/specials/taproot/zh/12-backups.md new file mode 100644 index 0000000000..2aad16b484 --- /dev/null +++ b/_includes/specials/taproot/zh/12-backups.md @@ -0,0 +1,30 @@ +[上周专栏][taproot series vaults]中，Antoine Poinsot 描述了 taproot 如何提升[保险库][topic vaults]式资金备份与安全方案的隐私性和手续费效率。本周我们将探讨其他几种可通过迁移至 taproot 获得改进的备份与安全方案。 + +- ******简单 2-of-3：** 如[前文][threshold signing]所述，结合[多签][topic multisignature]和脚本路径支出，可轻松创建 2-of-3 支出策略。正常情况下其链上效率与单签支出相当，且比当前 P2SH 和 P2WSH 多签方案更隐私。异常情况下的效率和隐私性也表现良好。这使 taproot 成为从单签钱包升级到多签策略的理想选择。 + + 我们预计未来的[门限签名][topic threshold signature]技术将进一步优化 2-of-3 及其他 k-of-n 场景。 + +- ******降级多签：** [Optech Taproot 研讨会][taproot workshop]中的练习可体验创建支持以下规则的 taproot 脚本：随时由三个密钥支出；三天后由原密钥中的两个支出；十天后仅需一个原密钥（该练习还涉及备份密钥，我们将在下一点单独讨论）。调整时间参数和密钥设置可构建灵活强大的备份方案。 + + 例如，假设正常支出需笔记本电脑、手机和硬件签名设备三者协同。若其中一设备不可用，等待一个月后可用剩余两设备支出。若两设备不可用，六个月后仅需一设备即可支出。 + + 正常三设备协同使用时，链上脚本实现最高效和隐私。其他情况下效率略降但仍保持合理隐私性（脚本及其树深与其他合约相似）。 + +- ******社交恢复备份与安全：** 上述示例在设备被盗时提供良好保护，但若两设备同时被盗呢？若钱包使用频繁，设备丢失后需等待一个月才能恢复支出是否合理？ + + taproot 可便捷、低成本且隐私地添加社交元素。除上述脚本外，还可允许：两设备加两位亲友签名即时支出；或单一密钥加五位信任者签名即时支出（非社交版本可使用额外设备或备份助记词）。 + +- ******时间与社交阈值结合的继承方案：** 综合上述技术，可设置在你突发意外时允许指定个人或群体恢复资金。例如，若比特币六个月未移动，允许律师和五位亲属中的三位支出。若你本就每六个月操作资金，该继承方案在你生前无额外链上成本且对外完全隐私。甚至可让律师和亲属在你生前无法知晓交易详情（只需确保他们能在你离世后获取钱包的扩展公钥 xpub）。 + + 请注意，继承人具备技术能力支出比特币不等同于合法继承。建议计划比特币继承者阅读 Pamela Morgan 的《加密资产继承规划》（[实体书/DRM 电子书][cip amazon] 或 [DRM-free 电子书][cip aantonop]），并与本地遗产规划专家讨论细节。 + +- ******入侵检测：** taproot 诞生前提出的[树签名][tree signatures]方案建议在所有设备上放置控制少量比特币的密钥作为入侵检测。若金额足够诱人，攻击者可能选择立即盗取而非长期潜伏造成更大损失。 + + 该方案的挑战在于：需设置足够吸引攻击者的金额，但又不愿在每台设备存放大量比特币（希望仅提供一份高额赏金）。若所有设备使用相同密钥，攻击交易无法定位被入侵设备。taproot 允许为每台设备设置不同密钥和脚本路径。任一密钥均可支出全部资金，同时精确定位被入侵设备。 + +[taproot series vaults]: /zh/preparing-for-taproot/#使用-taproot-的保险库 +[cip amazon]: https://amazon.com/Cryptoasset-Inheritance-Planning-Simple-Owners/dp/1947910116 +[cip aantonop]: https://aantonop.com/product/cryptoasset-inheritance-planning-a-simple-guide-for-owners/ +[tree signatures]: https://blockstream.com/2015/08/24/en-treesignatures/#h.2lysjsnoo7jd +[threshold signing]: /zh/preparing-for-taproot/#多签 +[taproot workshop]: https://github.com/bitcoinops/taproot-workshop diff --git a/_includes/specials/taproot/zh/13-signet.md b/_includes/specials/taproot/zh/13-signet.md new file mode 100644 index 0000000000..7f1c41edfa --- /dev/null +++ b/_includes/specials/taproot/zh/13-signet.md @@ -0,0 +1,77 @@ +尽管你[无法在主网区块 {{site.trb}} 前安全使用 Taproot][taproot safety]，但你现在可以通过 testnet 或 signet 使用 Taproot。与使用 Bitcoin Core 的 regtest 模式创建本地测试网络（如 [Optech Taproot 工作手册][Optech taproot workbooks] 所示）相比，使用 testnet 或 signet 能更方便地测试你的钱包与其他用户钱包的交互。 + +本文将演示如何在 [signet][topic signet] 上使用 Bitcoin Core 内置钱包接收和花费 Taproot 交易。你可以根据这些指令调整，以测试你的钱包与 Bitcoin Core 之间的收发功能。 + +虽然 Bitcoin Core 22.0 的内置钱包技术上支持收发 Taproot 交易，但我们建议你编译 Bitcoin Core 的拉取请求 [#22364][bitcoin core #22364]，该请求将 Taproot 设为[描述符][topic descriptors]钱包的默认选项。编译完成后，启动 signet： + +```text +$ bitcoind -signet -daemon +``` + +如果是首次使用 signet，需同步其区块链。当前数据量不足 200 MB，可在约一分钟内完成同步。可通过 `getblockchaininfo` RPC 监控同步进度。同步完成后，创建描述符钱包： + +```text +$ bitcoin-cli -signet -named createwallet wallet_name=p4tr descriptors=true load_on_startup=true +{ + "name": "p4tr", + "warning": "此钱包为实验性描述符钱包" +} +``` + +现在可生成 bech32m 地址： + +``` +$ bitcoin-cli -named -signet getnewaddress address_type=bech32m +tb1p6h5fuzmnvpdthf5shf0qqjzwy7wsqc5rhmgq2ks9xrak4ry6mtrscsqvzp +``` + +使用该地址可从 [signet faucet][] 获取测试币。需等待交易确认，时间与主网类似（通常 30 分钟内，有时更长）。查看交易详情时，会注意到创建的 P2TR 脚本： + +```text +$ bitcoin-cli -signet getrawtransaction 688f8c792a7b3d9cb46b95bfa5b10fe458617b758fe4100c5a1b9536bedae4cd true | jq .vout[0] +{ + "value": 0.001, + "n": 0, + "scriptPubKey": { + "asm": "1 d5e89e0b73605abba690ba5e00484e279d006283bed0055a0530fb6a8c9adac7", + "hex": "5120d5e89e0b73605abba690ba5e00484e279d006283bed0055a0530fb6a8c9adac7", + "address": "tb1p6h5fuzmnvpdthf5shf0qqjzwy7wsqc5rhmgq2ks9xrak4ry6mtrscsqvzp", + "type": "witness_v1_taproot" + } +} +``` + +接下来可生成第二个 bech32m 地址并发送资金以测试花费功能： + +```text +$ bitcoin-cli -named -signet getnewaddress address_type=bech32m +tb1p53qvqxja52ge4a7dlcng6qsqggdd85fydxs4f5s3s4ndd2yrn6ns0r6uhx +$ bitcoin-cli -named -signet sendtoaddress address=tb1p53qvqxja52ge4a7dlcng6qsqggdd85fydxs4f5s3s4ndd2yrn6ns0r6uhx amount=0.00099 +24083fdac05edc9dbe0bb836272601c8893e705a2b046f97193550a30d880a0c +``` + +查看该花费交易的输入部分，可见其见证数据仅包含一个 64 字节的签名。这比 P2WPKH 或其他传统比特币交易所需的见证数据[更精简][p2tr vs p2wpkh]（以虚拟字节计）。 + +```text +$ bitcoin-cli -signet getrawtransaction 24083fdac05edc9dbe0bb836272601c8893e705a2b046f97193550a30d880a0c true | jq .vin[0] +{ + "txid": "bd6dbd2271a95bce8a806288a751a33fc4cf2c336e52a5b98a5ded432229b6f8", + "vout": 0, + "scriptSig": { + "asm": "", + "hex": "" + }, + "txinwitness": [ + "2a926abbc29fba46e0ba9bca45e1e747486dec748df1e07ee8d887e2532eb48e0b0bff511005eeccfe770c0c1bf880d0d06cb42861212832c5f01f7e6c40c3ce" + ], + "sequence": 4294967294 +} +``` + +通过实践上述指令，你将能轻松在任何支持 signet 的钱包中测试 Taproot 的收发功能。 + +{% include linkers/issues.md issues="22364" %} +[taproot safety]: /zh/preparing-for-taproot/#我们为什么要等待 +[optech taproot workbooks]: /zh/preparing-for-taproot/#通过使用学习-taproot +[p2tr vs p2wpkh]: /zh/preparing-for-taproot/#taproot-对单签名是否有意义 +[signet faucet]: https://signetfaucet.com/ diff --git a/_includes/specials/taproot/zh/14-signmessage.md b/_includes/specials/taproot/zh/14-signmessage.md new file mode 100644 index 0000000000..402e32fa0b --- /dev/null +++ b/_includes/specials/taproot/zh/14-signmessage.md @@ -0,0 +1,17 @@ +自四年前隔离见证（segwit）激活以来，尚未形成被广泛接受的为 [Bech32 或 Bech32m][topic bech32] 地址创建签名消息的方式。可以说，我们现在可以认为广泛的消息签名支持对用户或开发者而言并不十分重要，否则会有更多工作投入其中。但相较于过去使用传统地址时用户可便捷交换签名消息的情况，比特币钱包软件的功能似乎有所倒退。 + +我们在两年前关于 [Bech32 消费支持][bech32ss signmessage] 系列文章中提到的[通用 Signmessage][topic generic signmessage] 方案进展甚微，即便其协议文档 [BIP322][] 偶有更新（参见 Newsletter [#118][news118 virttx] 和 [#130][news130 inconclusive]），也未被 Bitcoin Core 采用。尽管如此，我们尚未发现更优替代方案，因此任何希望在 P2TR 钱包中添加 Signmessage 功能的开发者仍应将 BIP322 作为首选。 + +若得以实现，通用 Signmessage 协议将支持为以下类型的 P2TR 输出签名：纯单签、使用[多签][topic multisignature]或任何 [Tapscript][topic tapscript] 脚本。该协议还将向后兼容所有传统及 Bech32 地址，并向前兼容目前规划的近期变更类型（部分内容将在后续*为 Taproot 激活做准备*专栏中预告）。能够访问完整 UTXO 集的应用（例如通过全节点）还可利用 BIP322 生成和验证[储备证明][bip322 reserve proofs]，以证明签名者在特定时间点控制特定数量的比特币。 + +实现通用签名消息功能的创建相对简单。BIP322 采用称为*虚拟交易*的技术：首笔虚拟交易通过尝试花费不存在的先前交易（txid 全为零）构造为无效交易，该交易支付至用户需签名的地址（脚本）并包含对目标消息的哈希承诺；第二笔交易花费首笔交易的输出——若该花费的签名及其他数据构成有效交易，则视为消息已签名（尽管第二笔虚拟交易仍无法上链，因其源自无效的前序交易）。 + +对多数钱包而言，验证通用签名消息更为复杂。要完全验证*任意* BIP322 消息需实现比特币几乎所有的共识规则。多数钱包不具备此能力，因此 BIP322 允许其在无法完整验证脚本时返回"不确定"状态。实践中，尤其是 Taproot 鼓励密钥路径花费的背景下，这种情况可能较少。任何仅实现几种常用脚本类型的钱包将能验证超过 99% UTXO 的签名消息。 + +通用 Signmessage 支持将是比特币的一项有益补充。尽管过去数年其受关注度不足，我们仍鼓励阅读本文的钱包开发者考虑为您的程序添加实验性支持。这是为用户恢复已缺失数年的功能的便捷途径。若您是参与 BIP322 或相关储备证明实现的开发者，或认为此类功能有价值的服务提供商，欢迎联系 [info@bitcoinops.org][optech email] 以协调合作。 + +[reserve proofs]: https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki#full-proof-of-funds +[bech32ss signmessage]: /zh/bech32-sending-support/#消息签名支持 +[bip322 reserve proofs]: https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki#full-proof-of-funds +[news118 virttx]: /zh/newsletters/2020/10/07/#alternative-to-bip322-generic-signmessage +[news130 inconclusive]: /zh/newsletters/2021/01/06/#proposed-updates-to-generic-signmessage diff --git a/_includes/specials/taproot/zh/15-output-linking.md b/_includes/specials/taproot/zh/15-output-linking.md new file mode 100644 index 0000000000..4f08fb02f4 --- /dev/null +++ b/_includes/specials/taproot/zh/15-output-linking.md @@ -0,0 +1,25 @@ +{% auto_anchor %} + +在 taproot 激活后，用户将开始接收支付至 P2TR 输出的交易。随后，他们将花费这些输出。某些情况下，用户可能向非 P2TR 输出支付，但仍会使用 P2TR 找零输出将剩余资金返还给自己。 + +{:.center} +![示例交易 P2TR -> {P2WPKH、P2TR}](/img/posts/2021-10-p2tr-to-p2tr_p2wpkh.png) + +对于观察此类交易的专家或算法而言，可以合理推断 P2TR 输出是用户自身的找零输出，而其他输出则为支付输出。虽然这并非绝对成立，但属于最可能的解释。 + +有观点认为，由于钱包向 P2TR 过渡期间可能出现的隐私暂时下降，应当忽略 taproot 的诸多[隐私优势][p4tr benefits]。多位专家[指出][coindesk experts]这种担忧属于过度反应。我们认同此观点，并补充以下考量： + +- ​****​**其他元数据：​**​ 交易可能包含其他揭示找零与支付输出的元数据。最令人担忧的是当前大量存在的[地址复用][topic output linking]现象，严重损害交易双方的隐私。只要这些问题存在，拒绝为遵循最佳实践的钱包和服务用户实施重大隐私升级便显失明智。 + +- ​****​**输出脚本匹配：​**​ Bitcoin Core 内置钱包默认在支付输出包含隔离见证类型时[使用隔离见证找零输出][bitcoin core #12119]，否则使用默认找零地址类型。例如支付至 P2PKH 输出时可能使用 P2PKH 找零，支付至 P2WPKH 输出时使用 P2WPKH 找零。如[周报 #155][news155 bcc22154]所述，taproot 激活后 Bitcoin Core 将在交易包含其他 P2TR 输出时优先使用 P2TR 找零输出，最大程度减少过渡期找零可识别性的增加。 + +- ​****​**请求升级：​**​ P2TR 为比特币历史首次提供了机会，让所有用户无论安全需求如何均使用相同类型的输出脚本，并频繁使用不可区分的输入，显著提升隐私。若期望提升比特币隐私，可要求收款方和服务提供商支持 taproot（并停止地址复用）。若双方均完成升级，找零输出将更难以识别，同时还能获得 taproot 的其他卓越隐私优势。 +{% include linkers/issues.md issues="12119" %} + +{% endauto_anchor %} + +[p4tr benefits]: /zh/preparing-for-taproot/#多签 +[p4tr safety]: /zh/preparing-for-taproot/#我们为什么要等待 +[coindesk experts]: https://www.coindesk.com/tech/2020/12/01/privacy-concerns-over-bitcoin-upgrade-taproot-are-a-non-issue-experts-say/ +[compat bcc]: /en/compatibility/bitcoin-core/ +[news155 bcc22154]: /zh/newsletters/2021/06/30/#bitcoin-core-22154 diff --git a/_includes/specials/taproot/zh/17-keypath-universality.md b/_includes/specials/taproot/zh/17-keypath-universality.md new file mode 100644 index 0000000000..93cafb5071 --- /dev/null +++ b/_includes/specials/taproot/zh/17-keypath-universality.md @@ -0,0 +1,28 @@ +{% auto_anchor %} + +Gregory Maxwell 在[最初的 taproot 提案][maxwell taproot]中提出了一个有趣的合约设计原则： + +> "几乎所有有趣的脚本都有一个逻辑顶层分支，允许所有参与者仅通过签名即可完成合约执行。其他分支仅在部分参与者不配合时使用。更加强调地说，我认为任何预先确定固定有限参与者的合约都应该表示为 N-of-N 签名与其他复杂合约条件的 OR 组合。"（原文强调） + +此后，[专家][irc log1]们就此原则的[普适性][irc log2]展开辩论，目前已知的两个例外情况均与时间锁相关： + +- ​****​**共识强化的自我控制：​**​ 部分用户使用[时间锁][topic timelocks]阻止自己在特定期限内花费比特币。时间锁要求看似需要除签名外的额外条件，但存在以下争议： + + - 极度渴求资金的用户可通过其他资产担保获得贷款，这削弱了此类自控合约的效用。 + + - 除共识强制的脚本路径时间锁外，用户可设置密钥路径支出，允许自身密钥与第三方密钥（仅在时间锁到期后签名）共同签署。这种方式不仅更高效，还能实现更灵活的支出策略，例如允许用户出售分叉币，或在重大生活变故或价格波动时通过第三方提前支取。 + +- ​****​**保险库：​**​ 如 Antoine Poinsot 几周前在本站的[专栏][p4tr vaults]所述，[保险库][topic vaults]也广泛使用时间锁保护资金，这似乎"与 taproot 的核心洞见（即多数合约存在参与者协同签名的理想路径）相悖"。但有观点认为，保险库用户始终需要密钥路径作为逃生通道，且为脚本路径合约添加密钥路径选项无需额外成本，因此具备绝对优势。 + +反对始终提供密钥路径的观点认为，即使所有签名者共同行动，仍存在不信任自身的情况。他们转而信任其他主体——执行比特币共识规则的经济全节点运营者——来强制执行签名者不愿自我施加的支出限制。 + +反驳观点指出，至少在理论上，可以通过在常规签名者与所有经济全节点运营者之间创建密钥路径多签来获得同等安全性。更实际地说，或许存在某个节点运营者子集可加入密钥路径多签集来执行所需策略（若不可行，用户仍可通过脚本路径支出，因此并无损失）。 + +抛开理论探讨，我们建议在设计基于 taproot 的合约时，即使看似无需密钥路径，也应额外考量是否存有利用密钥路径的机会。 + +{% endauto_anchor %} + +[p4tr vaults]: /zh/preparing-for-taproot/#使用-taproot-的保险库 +[maxwell taproot]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html +[irc log1]: https://gnusha.org/taproot-bip-review/2020-02-09.log +[irc log2]: https://gnusha.org/taproot-bip-review/2020-02-10.log diff --git a/_includes/specials/taproot/zh/18-trivia.md b/_includes/specials/taproot/zh/18-trivia.md new file mode 100644 index 0000000000..6cd0c0528a --- /dev/null +++ b/_includes/specials/taproot/zh/18-trivia.md @@ -0,0 +1,47 @@ +{% auto_anchor %} + +- ​****​**什么是 Taproot？** 维基百科[解释][wikipedia taproot]："主根（taproot）是一种大型、中心化且占主导地位的根系，其他根须从其侧面生长。典型的主根较为笔直粗壮、呈锥形且垂直向下生长。某些植物（如胡萝卜）的主根作为储存器官高度发达，已被培育为蔬菜。" + + 这与比特币有何关联？ + + - ​****"我一直认为这个名字源于'接入默克尔根（taps into the Merkle root）'，但实际并不清楚 Gregory Maxwell 的命名思路。" ——Pieter Wuille（[来源][wuille taproot name]） + + - ​****"我最初不得不查阅这个词的含义；但将其理解为密钥路径是'主根'，因为这是可食用的部分（用于制作胡萝卜汤），而默克尔化的脚本则是其他次要根须（希望被忽略）。" ——Anthony Towns（[来源][towns taproot name]） + + - "该名称源自对蒲公英主根般粗壮中心树干的视觉化想象——该技术的主要价值在于假设存在一条高概率路径（其他为杂乱次要路径）。此外，'taproot' 的双关含义也贴切，因为其通过根部的隐藏承诺来验证脚本路径支付。 + + [...] 可惜，将带有排序内部节点的哈希树称为'myrtle 树'（取自桃金娘科，含茶树等）并未流行，尽管其发音类似'merkle'且有数学排列特性。" ——Gregory Maxwell（[来源][maxwell taproot name]） + +- ​****​**Schnorr 签名早于 ECDSA：​** 尽管我们将 [schnorr 签名][topic schnorr signatures] 视为比特币原始 ECDSA 签名的升级（因其更易实现密码学技巧），但 schnorr 签名算法其实早于 ECDSA 所基于的 DSA 算法。事实上，DSA 的创建部分是为了规避 Claus Peter Schnorr 的 [schnorr 签名专利][schnorr patent]，但 Schnorr 仍[声称][schnorr letter]"我的专利适用于各类离散对数签名实现，包括 Nyberg-Rueppel 和 DSA"。目前无法院支持此主张，且其专利已于 2011 年过期。 + +- ​****​**命名争议：​** 在比特币采用 schnorr 签名的早期，曾有[建议][dryja bn sigs]避免使用 Schnorr 之名，因其专利阻碍了该密码学技术的普及。Pieter Wuille [解释][wuille dls]："我们曾考虑将 [BIP340][] 命名为'DLS'（离散对数签名），但最终因 Schnorr 之名已被广泛讨论而未采纳。" + +- ​****​**扭曲爱德华曲线的 Schnorr 签名：​** 2011 年发布的 [EdDSA][] 方案将 schnorr 签名应用于椭圆曲线，现已成为多项标准的基础。虽然未用于比特币共识层，但 Optech 追踪的多个比特币代码库中可见其相关引用。 + + +- ​****​**支付到合约：​** Ilja Gerhardt 和 Timo Hanke 在 2013 年圣何塞比特币大会上提出的[协议][gh p2c]， 允许支付承诺至合约哈希。持有合约和防攻击随机数的任何人都可验证该承诺，但对他人而言该支付与普通比特币支付无异。 + + 2014 年[侧链论文][sidechains.pdf]中的改进版 P2C 额外承诺原始公钥。Taproot 采用相同结构，但其承诺对象为接收方设定的链上花费条件（而非链下合约条款）。 + +- ​****​**灵感诞生地：​** 使脚本支付与公钥支付在链上表现相同的 P2C 创意，由 Andrew Poelstra 和 Gregory Maxwell 于 2018 年 1 月 22 日在加利福尼亚州洛斯阿尔托斯的 "A Good Morning" 餐厅构思。Pieter Wuille 回忆："这个想法在我暂时离开餐桌时诞生... !$%@" [原文如此] + +- ​****​**2.5 年浓缩至 1.5 天：​** 确定 [bech32m][topic bech32] 的最佳常数消耗了[约][wuille matrix elimination] 2.5 年 CPU 时间，最终借 Gregory Maxwell 的 CPU 集群在 1.5 天内完成计算。 + +*感谢 Anthony Towns、Gregory Maxwell、Jonas Nick、Pieter Wuille 和 Tim Ruffing 为本栏目提供的见解。文中错误由作者负责。* + +{% endauto_anchor %} + +[wikipedia taproot]: https://en.wikipedia.org/wiki/Taproot +[dryja bn sigs]: https://diyhpl.us/wiki/transcripts/discreet-log-contracts/ +[bitcoin.pdf]: https://www.opencrypto.org/bitcoin.pdf +[schnorr patent]: https://patents.google.com/patent/US4995082 +[ed25519]: https://ed25519.cr.yp.to/ed25519-20110926.pdf +[eddsa]: https://en.wikipedia.org/wiki/EdDSA +[gh p2c]: https://arxiv.org/abs/1212.3257 +[sidechains.pdf]: https://www.blockstream.com/sidechains.pdf +[wuille matrix elimination]: https://twitter.com/pwuille/status/1335761447884713985 +[wuille dls]: https://github.com/bitcoinops/bitcoinops.github.io/pull/667#discussion_r731372937 +[wuille taproot name]: https://github.com/bitcoinops/bitcoinops.github.io/pull/667#discussion_r731371163 +[towns taproot name]: https://github.com/bitcoinops/bitcoinops.github.io/pull/667#discussion_r731523855 +[schnorr letter]: https://web.archive.org/web/19991117143502/http://grouper.ieee.org/groups/1363/letters/SchnorrMar98.html +[maxwell taproot name]: https://github.com/bitcoinops/bitcoinops.github.io/pull/667#discussion_r732189216 diff --git a/_includes/specials/taproot/zh/19-future.md b/_includes/specials/taproot/zh/19-future.md new file mode 100644 index 0000000000..350f776f04 --- /dev/null +++ b/_includes/specials/taproot/zh/19-future.md @@ -0,0 +1,46 @@ +{% auto_anchor %} + +随着 Taproot 在区块高度 {{site.trb}} 临近激活，我们可以开始展望开发者们此前希望在 Taproot 基础上构建的部分共识变更。 + +- ​****​**跨输入签名聚合：​** [schnorr 签名][topic schnorr signatures]使得多个独立公私钥对的持有者能够轻松创建单个签名来证明所有密钥持有者的协作授权。 + 通过未来的共识变更，这将允许交易包含单个签名来证明该交易中所有被花费的 UTXO 所有者均已授权支出。这将为每个密钥路径花费（首个输入之后）节省约 16 vbytes，为资金整合和 [coinjoins][topic coinjoin] 带来显著空间节省。它甚至可能使得基于 coinjoin 的支出比个人单独支出更经济，为使用更隐私的支出方式提供温和激励。 + +- ​****​**SIGHASH_ANYPREVOUT：​** 每笔比特币交易都包含一个或多个输入，每个输入通过 txid 引用前序交易的输出。这个引用告知 Bitcoin Core 等全验证节点该交易可支出的金额及验证授权所需的条件。所有比特币交易签名生成方式（无论是否使用 Taproot）要么承诺 prevouts 中的 txid，要么完全不承诺 prevouts。 + + 这对不希望使用预先安排交易序列的多用户协议构成挑战。如果任何用户可以跳过特定交易，或更改除见证数据外的任何交易细节，将导致后续交易的 txid 改变。txid 的变更会使之前为后续交易创建的签名失效。这迫使链下协议实施惩罚机制（如 LN 惩罚机制）来惩戒提交旧交易的用户。 + + [SIGHASH_ANYPREVOUT][topic sighash_anyprevout] 通过允许签名跳过对 prevout txid 的承诺来解决此问题。根据使用的其他标志，它仍会承诺关于 prevout 和交易的其他细节（如金额和脚本），但不再关心前序交易使用的 txid。这将使实现 [eltoo][topic eltoo] 闪电网络层以及[保险库][topic vaults]和其他合约协议的[改进][p4tr vaults]成为可能。 + +- ​****​**委托与通用化：​** 创建脚本（Taproot 或其他类型）后，[几乎][rubin delegation] 无法在不泄露私钥的情况下委托他人使用该脚本（使用 [BIP32][] 钱包时[逆向推导][bip32 reverse derivation]可能[极其危险][bip32 reverse derivation]）。此外，对于希望使用密钥路径支出加少量脚本条件的用户，Taproot 可变得更具成本效益。目前已提出多种通过通用化和提供[签名者委托][topic signer delegation]来增强 Taproot 的方法： + + - ​****​**Graftroot：​** 在 Taproot 概念提出后不久[提出][maxwell graftroot]，Graftroot 将为任何能够进行 Taproot 密钥路径支出的用户提供额外功能。密钥路径签名者可以不直接支出资金，而是签署描述新支出条件的脚本，将支出权限委托给能够满足该脚本的任何人。支出交易中需提供签名、脚本及满足脚本所需的任何数据。密钥路径签名者可以通过这种方式委托无限数量的脚本，且在实际支出发生前不会产生任何链上数据。 + + - ​****​**通用化 Taproot（g'root）：​** 数月后，Anthony Towns [提出][towns groot]使用公钥点承诺多种支出条件的方法，无需使用类似 [MAST][topic mast] 的结构。这种 *通用化 Taproot*（g'root）构造在 "[Taproot 假设不成立][p4tr taproot assumption]" 时可能更高效，同时 "[提供][sipa groot agg]构建软分叉安全的跨输入聚合系统的简便方法"。 + + - ​****​**Entroot：​** [近期][wuille entroot]综合 Graftroot 和 g'root 的方案，简化多数场景并提升带宽效率。它支持来自任何能够满足 Entroot 分支的签名者委托，而不仅限于能够创建顶层密钥路径支出的用户。 + +- ​****​**新旧操作码：​** Taproot 软分叉包含对 [Tapscript][topic tapscript] 的支持，通过 `OP_SUCCESSx` 操作码提供了改进的比特币新操作码添加方式。与比特币早期添加的 `OP_NOPx`（无操作）操作码类似，`OP_SUCCESSx` 操作码设计为可替换为不总是返回成功的操作码。部分提议的新操作码包括： + + - ​****​**恢复旧操作码：​** 2010 年因安全漏洞担忧而禁用的多个数学和字符串操作码。许多开发者希望在进行安全审查后重新启用这些操作码，并在某些情况下扩展其处理更大数值的能力。 + + - ​****​**OP_CAT：​** 这个曾被禁用的操作码值得特别关注，研究人员发现其单独使用即可通过[密钥树][keytrees]、[后量子密码][rubin pqc]或与 [OP_CHECKSIGFROMSTACK][topic op_checksigfromstack] 等新操作码[结合][poelstra cat]实现[各类][rubin pqc]有趣功能。 + + - ​****​**OP_TAPLEAF_UPDATE_VERIFY：​** 如[第 166 期周报][news166 tluv]所述，`OP_TLUV` 操作码在配合 Taproot 密钥路径和脚本路径功能时，能高效实现强大的[契约][topic covenants]，可用于构建[联合质押池][topic joinpools]、[保险库][topic vaults]等安全与隐私改进方案，也可能与 [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] 良好结合。 + +以上所有设想仍仅为提案，无法保证最终实现。需要研究人员和开发者推动每个提案走向成熟，最终由用户决定是否值得通过改变比特币共识规则来添加这些功能。 + +{% endauto_anchor %} + +[news166 tluv]: /zh/newsletters/2021/09/15/#covenant-opcode-proposal +[wuille entroot]: https://gist.github.com/sipa/ca1502f8465d0d5032d9dd2465f32603 +[towns groot]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016249.html +[maxwell graftroot]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015700.html +[p4tr multisignatures]: /zh/preparing-for-taproot/#多签 +[p4tr vaults]: /zh/preparing-for-taproot/#使用-taproot-的保险库 +[rubin delegation]: /zh/newsletters/2021/03/24/#signing-delegation-under-existing-consensus-rules +[p4tr taproot assumption]: /zh/preparing-for-taproot/#合作永远是可行选项吗 +[keytrees]: https://blockstream.com/2015/08/24/en-treesignatures/#h.2lysjsnoo7jd +[rubin pqc]: https://rubin.io/blog/2021/07/06/quantum-bitcoin/ +[poelstra cat]: https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html +[bip32 reverse derivation]: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#implications +[sipa groot agg]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-October/016461.html diff --git a/_includes/specials/taproot/zh/20-activation.md b/_includes/specials/taproot/zh/20-activation.md new file mode 100644 index 0000000000..c4fd9d7594 --- /dev/null +++ b/_includes/specials/taproot/zh/20-activation.md @@ -0,0 +1,20 @@ +在本文发布后不到两周时间，taproot 预计将在区块 {{site.trb}} 激活。我们了解预期会发生的情况，同时也意识到几种可能的故障模式。 + +最理想且最可能的结果是一切顺利。普通用户不会感知到任何变化，只有那些密切监控节点或尝试创建 taproot 交易的用户会注意到差异。在区块 709,631 时，我们所知几乎所有全节点都将执行相同的共识规则。随后的区块中，运行 Bitcoin Core 0.21.1、22.0 或相关版本的节点将开始执行早期版本未包含的 [taproot][topic taproot] 规则。 + +这存在不同版本节点软件接受不同区块的风险。类似情况曾发生在 2015 年 [BIP66][] 软分叉激活期间，导致六区块的链分叉及多次短暂分叉。开发团队已投入大量精力防止此类问题重演。只有在矿工故意挖出违反 taproot 规则的区块，或禁用了 Bitcoin Core 等节点软件内置的安全机制时，才可能出现类似问题。 + +具体而言，要制造链分叉，矿工需创建或接受未遵守 taproot 规则的花费 segwit v1 输出的交易。若发生这种情况，当比特币节点运营者的经济共识拒绝这些无效区块时，相关矿工将至少损失 6.25 BTC（约合 40 万美元）。 + +我们无法在未实际创建无效区块的情况下断言节点运营者的行为（节点可完全私有运行），但通过[代理指标][bitnodes]观测显示，超过 50% 的节点运营者正在运行支持 taproot 的 Bitcoin Core 版本。这足以确保任何 taproot 无效区块将被网络拒绝。 + +尽管可能性极低，理论上仍存在临时链分叉风险。可通过 [ForkMonitor.info][] 等监控服务或 Bitcoin Core 的 `getchaintips` RPC 进行监测。若分叉发生，轻客户端可能收到错误确认。虽然理论上可能出现 6 次确认（如 2015 年分叉），但这意味着矿工将损失近 250 万美元（2015 年损失约 5 万美元）。在如此高昂代价下，我们有理由相信矿工会切实执行半年前就发出支持信号的 taproot 规则。 + +在几乎所有可预见的故障场景中，简单有效的临时应对措施是提高确认要求。若常规需 6 次确认接收支付，可临时提升至 30 次确认并持续数小时，直至问题解决或确认需进一步上调。 + +对于确信全节点运营者经济共识将执行 taproot 规则的用户和服务，更简单的解决方案是仅从 Bitcoin Core 0.21.1 或更新版本（或兼容替代实现）获取交易确认信息。 + +Optech 预计 taproot 激活将平稳完成，但仍建议交易所在区块 {{site.trb}} 前后处理大额交易时升级节点，或准备好在出现异常迹象时临时提高确认要求。 + +[forkmonitor.info]: https://forkmonitor.info/nodes/btc +[bitnodes]: https://bitnodes.io/nodes/ diff --git a/_includes/specials/taproot/zh/21-thanks.md b/_includes/specials/taproot/zh/21-thanks.md new file mode 100644 index 0000000000..113437c0dd --- /dev/null +++ b/_includes/specials/taproot/zh/21-thanks.md @@ -0,0 +1,454 @@ +Taproot 将在区块 {{site.trb}} 激活，预计于本文发布后数日内完成。作为本系列的终篇，我们谨向众多参与开发与激活 Taproot 的人士致谢——他们即将开始执行这一升级。未提及的诸多贡献者同样值得感谢，我们为所有疏漏致歉。 + +{:#mailing_list_discussion} +**Bitcoin-Dev 邮件列表讨论** + +Taproot 的核心构想[萌芽][good morning]于 2019 年 1 月 22 日早晨几位密码学家的会议，并于当日通过邮件列表[发布][maxwell taproot post]。以下人士参与了主题含 "taproot" 的讨论： + + +Adam Back、 +Andrea Barontini、 +Andreas Schildbach、 +Andrew Chow、 +Andrew Poelstra、 +Anthony Towns、 +Antoine Riard、 +Ariel Lorenzo-Luaces、 +Aymeric Vitte、 +Ben Carman、 +Ben Woosley、 +Billy Tetrud、 +BitcoinMechanic、 +Bryan Bishop、 +Carlo Spiller、 +Chris Belcher、 +Christopher Allen、 +Clark Moody、 +Claus Ehrenberg、 +Craig Raw、 +Damian Mee、 +Daniel Edgecumbe、 +David A. Harding、 +DA Williamson、 +Elichai Turkel、 +Emil Pfeffer、 +Eoin McQuinn、 +Eric Voskuil、 +Erik Aronesty、 +Felipe Micaroni Lalli、 +Giacomo Caironi、 +Gregory Maxwell、 +Greg Sanders、 +Jay Berg、 +Jeremy Rubin、 +John Newbery、 +Johnson Lau、 +Jonas Nick、 +Karl-Johan Alm、 +Keagan McClelland、 +Lloyd Fournier、 +Luke Dashjr、 +Luke Kenneth Casson Leighton、 +Mark Friedenbach、 +Martin Schwarz、 +Matt Corallo、 +Matt Hill、 +Michael Folkson、 +Natanael、 +Oleg Andreev、 +Pavol Rusnak、 +Pieter Wuille、 +Prayank、 +R E Broadley、 +Riccardo Casatta、 +Robert Spigler、 +Ruben Somsen、 +Russell O'Connor、 +Rusty Russell、 +Ryan Grant、 +Salvatore Ingala、 +Samson Mow、 +Sjors Provoost、 +Steve Lee、 +Tamas Blummer、 +Thomas Hartman、 +Tim Ruffing、 +Vincent Truong、 +vjudeu、 +yancy、 +yanmaani—— +以及 +ZmnSCPxj。 + + +Taproot 整合的 [schnorr 签名][topic schnorr signatures] 和 [MAST][topic mast] 等概念源起更早，我们同样感谢相关贡献者。 + +{:#taproot-bip-review} +**Taproot BIP 审查** + +自 2019 年 11 月起，大量用户和开发者参与了 Taproot 的[系统化审查][news69 review]： + + +achow101、 +afk11、 +aj、 +alec、 +amiti、 +_andrewtoth、 +andytoshi、 +ariard、 +arik、 +b10c、 +belcher、 +bjarnem、 +BlueMatt、 +bsm1175321、 +cdecker、 +chm-diederichs、 +Chris_Stewart_5、 +cle1408、 +CubicEarth、 +Day、 +ddustin、 +devrandom、 +digi_james、 +dr-orlovsky、 +dustinwinski、 +elichai2、 +evoskuil、 +fanquake、 +felixweis、 +fjahr、 +ghost43、 +ghosthell、 +gmaxwell、 +harding、 +hebasto、 +instagibbs、 +jeremyrubin、 +jnewbery、 +jonatack、 +justinmoon、 +kabaum、 +kanzure、 +luke-jr、 +maaku、 +mattleon、 +michaelfolkson、 +midnight、 +mol、 +Moller40、 +moneyball、 +murch、 +nickler、 +nothingmuch、 +orfeas、 +pinheadmz、 +pizzafrank13、 +potatoe_face、 +pyskell、 +pyskl、 +queip、 +r251d、 +raj_149、 +real_or_random、 +robert_spigler、 +roconnor、 +sanket1729、 +schmidty、 +sipa、 +soju、 +sosthene、 +stortz、 +taky、 +t-bast、 +theStack、 +Tibo、 +waxwing、 +xoyi—— +以及 +ZmnSCPxj。 + + +{:#github-prs} +**GitHub 拉取请求** + +Taproot 在 Bitcoin Core 中的主要实现于 2020 年 1 月通过[两个][bitcoin core #17977]拉取[请求][bitcoin core #19953]提交审查。以下人士参与了代码审查： + + +Andrew Chow (achow101)、 +Anthony Towns (ajtowns)、 +Antoine Riard (ariard)、 +Ben Carman (benthecarman)、 +Ben Woosley (Empact)、 +Bram (brmdbr)、 +Cory Fields (theuni)、 +Dmitry Petukhov (dgpv)、 +Elichai Turkel (elichai)、 +Fabian Jahr (fjahr)、 +Andreas Flack (flack)、 +Gregory Maxwell (gmaxwell)、 +Gregory Sanders (instagibbs)、 +James O'Beirne (jamesob)、 +Janus Troelsen (ysangkok)、 +Jeremy Rubin (JeremyRubin)、 +João Barbosa (promag)、 +John Newbery (jnewbery)、 +Jon Atack (jonatack)、 +Jonathan Underwood (junderw)、 +Kalle Alm (kallewoof)、 +Kanon (decryp2kanon)、 +kiminuo、 +Luke Dashjr (luke-jr)、 +Marco Falke (MarcoFalke)、 +Martin Habovštiak (Kixunil)、 +Matthew Zipkin (pinheadmz)、 +Max Hillebrand (MaxHillebrand)、 +Michael Folkson (michaelfolkson)、 +Michael Ford (fanquake)、 +Adam Ficsor (nopara73)、 +Pieter Wuille (sipa)、 +Sjors Provoost (Sjors)、 +Steve Huguenin-Elie (StEvUgnIn)、 +Tim Ruffing (real-or-random)、 +以及 +Yan Pritzker (skwp)。 + + +{:#taproot-activation-discussion} +**Taproot 激活讨论** + +社区围绕激活方式展开了数月讨论，主要参与者包括： + + +_6102bitcoin、 +AaronvanW、 +achow101、 +aj、 +alec、 +Alexandre_Chery、 +Alistair_Mann、 +amiti、 +andrewtoth、 +andytoshi、 +AnthonyRonning、 +ariel25、 +arturogoosnargh、 +AsILayHodling、 +averagepleb、 +bcman、 +belcher、 +benthecarman、 +Billy、 +bitcoinaire、 +bitentrepreneur、 +bitsharp、 +bjarnem、 +blk014、 +BlueMatt、 +bobazY、 +brg444、 +btcactivator、 +btcbb、 +cato、 +catwith1hat、 +cguida、 +CodeShark___、 +conman、 +copumpkin、 +Crash78、 +criley、 +CriptoLuis、 +CubicEarth、 +darbsllim、 +darosior、 +Day、 +DeanGuss、 +DeanWeen、 +debit、 +Decentralizedb、 +devrandom、 +DigDug、 +dome、 +dr_orlovsky、 +duringo、 +dustinwinski、 +eeb77f71f26eee、 +eidnrf、 +elector、 +elichai2、 +Emcy、 +emzy、 +entropy5000、 +eoin、 +epson121、 +erijon、 +eris、 +evankaloudis、 +faketoshi、 +fanquake、 +fedorafan、 +felixweis、 +fiach_dubh、 +fjahr、 +friendly_arthrop、 +GeraldineG、 +gevs、 +gg34、 +ghost43、 +ghosthell、 +giaki3003、 +gloved、 +gmaxwell、 +graeme1、 +GreenmanPGI、 +gr-g、 +GVac、 +gwillen、 +gwj、 +gz12、 +gz77、 +h4shcash、 +harding、 +hebasto、 +hiro8、 +Hotmetal、 +hsjoberg、 +huesal、 +instagibbs、 +Ironhelix、 +IT4Crypto、 +ja、 +jaenu、 +JanB、 +jeremyrubin、 +jimmy53、 +jnewbery、 +jonatack、 +jonny100051、 +jtimon、 +kallewoof、 +kanon、 +kanzure、 +Kappa、 +keblek、 +ksedgwic、 +landeau、 +lucasmoten、 +luke-jr、 +maaku、 +Majes、 +maybehuman、 +mblackmblack、 +mcm-mike、 +Memesan、 +michaelfolkson、 +midnight、 +MikeMarzig、 +mips、 +mol、 +molz、 +moneyball、 +mrb07r0、 +MrHodl、 +murch、 +naribia、 +newNickName、 +nickler、 +nikitis、 +NoDeal、 +norisgOG、 +nothingmuch、 +occupier、 +OP_NOP、 +OtahMachi、 +p0x、 +pinheadmz、 +PinkElephant、 +pox、 +prayank、 +prepaid、 +proofofkeags、 +provoostenator、 +prusnak、 +qubenix、 +queip、 +r251d、 +rabidus、 +Raincloud、 +raj、 +RamiDz94、 +real_or_random、 +rgrant、 +riclas、 +roasbeef、 +robert_spigler、 +rocket_fuel、 +roconnor、 +rovdi、 +rubikputer、 +RusAlex、 +rusty、 +sanket1729、 +satosaurian、 +schmidty、 +sdaftuar、 +setpill、 +shesek、 +shinobiusmonk、 +snash779、 +solairis、 +somethinsomethin、 +stortz、 +sturles、 +sugarpuff、 +taPrOOteD、 +TechMiX、 +TheDiktator、 +thomasb06、 +tiagocs、 +tomados、 +tonysanak、 +TristanLamonica、 +UltrA1、 +V1Technology、 +vanity、 +viaj3ro、 +Victorsueca、 +virtu、 +walletscrutiny、 +wangchun、 +warren、 +waxwing、 +Whatisthis、 +whuha、 +willcl_ark、 +WilliamSantiago、 +windsok、 +wumpus、 +xxxxbtcking、 +yanmaani、 +yevaud、 +ygrtiugf、 +Yoghurt11411、 +zmnscpxj、 +以及 +zndtoshi。 + + +**矿工信号** + +我们感谢自区块 681,408 以来所有发出 Taproot 准备就绪信号的矿工。 + +**生态项目** + +Taproot 激活仅是起点，开发者与用户将开始运用其新特性。我们感谢多年筹备 [MuSig][topic musig] 等生态项目的贡献者。 + +**全节点运营者** + +最关键的致谢致予数千名 Bitcoin Core 0.21.1 及以上版本（或兼容软件）的运营者。他们通过升级节点确保从区块 {{site.trb}} 开始仅接受符合 Taproot 规则的交易，为全网的升级安全提供经济保障。 + +{% include linkers/issues.md issues="17977,19953" %} +[maxwell taproot post]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html +[good morning]: /zh/preparing-for-taproot/#a-good-morning +[news69 review]: /zh/newsletters/2019/10/23/#taproot-review diff --git a/_includes/templates/compatibility-page.md b/_includes/templates/compatibility-page.md deleted file mode 100644 index 7fb83d60a5..0000000000 --- a/_includes/templates/compatibility-page.md +++ /dev/null @@ -1,8 +0,0 @@ -![{{tool.name|escape_once}}]({{tool.logo}}){:.third-party-logo}{:title="{{tool.name}}"} - -{:.center} -[Segwit](#segwit) \| [Replace-by-Fee](#rbf) - -{% include templates/compatibility/segwit.md %} - -{% include templates/compatibility/rbf.md %} diff --git a/_includes/templates/compatibility/rbf.md b/_includes/templates/compatibility/rbf.md deleted file mode 100644 index b1198b5f20..0000000000 --- a/_includes/templates/compatibility/rbf.md +++ /dev/null @@ -1,209 +0,0 @@ -## Replace-by-Fee (RBF) {#rbf} - -**What is Replace-by-Fee (RBF)?** An unconfirmed transaction can be replaced by another version of the -same transaction that spends the same inputs. Most full nodes support -this if the earlier transaction enables [BIP125](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki) signaling and the -replacement transaction increases the amount of fee paid. In terms of -block chain space used, this is the most efficient form of fee bumping. - -{% if tool.rbf %} - -{% assign tested = tool.rbf.tested. %} -**Tested**: {% if tested.version != "n/a" %} *version {{tested.version}}* {% endif %} on *{{tested.platforms}}* - -**Tested on**: *{{tested.date}}* - -### Receiving support - -
    - -{:id="receive-notification"} -{% assign rbf = tool.rbf.features. %} -{% case rbf.receive.notification %} - {% when "true" %}{:.feature-yes} - - **Notification notes RBF**
    - Notification of incoming transaction notes that the transaction signals RBF. - {% when "false" %}{:.feature-no} - - **Notification does not note RBF**
    - Notification of incoming transaction does not note that the transaction signals RBF. - {% when "na" %}{:.feature-neutral} - - **No notification**
    - There are no incoming transaction notifications for this service. - {% when "untested" %}{:.feature-neutral} - - **Not tested: Does transaction notification show whether transaction signals RBF?**
    - We either didn’t test this or could not appropriately determine the results. - {% else %}{% include ERROR_42_UNEXPECTED_VALUE %} -{% endcase %} - -{:id="receive-list"} -{% case rbf.receive.list %} - {% when "true" %}{:.feature-yes} - - **Received transaction labeled replaceable in list**
    - Visually indicates that an incoming transaction has signaled RBF. - {% when "false" %}{:.feature-no} - - **Received transaction not labeled replaceable in list**
    - Does not visually indicate that an incoming transaction has signaled RBF. - {% when "na" %}{:.feature-neutral} - - **This services does not handle incoming transactions**
    - Does not support incoming transactions. - {% when "untested" %}{:.feature-neutral} - - **Not tested: Does transaction list show whether received transactions signal RBF?**
    - We either didn’t test this or could not appropriately determine the results. - {% else %}{% include ERROR_42_UNEXPECTED_VALUE %} -{% endcase %} - -{:id="receive-details"} -{% case rbf.receive.details %} - {% when "true" %}{:.feature-yes} - - **Received transaction labeled replaceable in transaction details**
    - Visually indicates that a received transaction has signaled RBF when viewing the transaction details. - {% when "false" %}{:.feature-no} - - **Received transaction not labeled replaceable in transaction details**
    - Does not visually indicate that a received transaction has signaled RBF when viewing the transaction details. - {% when "na" %}{:.feature-neutral} - - **Does not show transaction details**
    - Does not show transaction details natively. Usually this means the service links to a block explorer for transaction details. - {% when "untested" %}{:.feature-neutral} - - **Not tested: Does transaction details page show whether received transaction signals RBF?**
    - We either didn’t test this or could not appropriately determine the results. - {% else %}{% include ERROR_42_UNEXPECTED_VALUE %} -{% endcase %} - -{:id="receive-replaced"} -{% if rbf.receive.shows_replaced_version == "true" and rbf.receive.shows_original_version == "true" %} - {:.feature-yes} - - **Shows replacement and original transactions**
    - Both the original transaction and replacement transaction(s) are shown in the - transaction list. -{% elsif rbf.receive.shows_replaced_version == "na" or - rbf.receive.shows_original_version == "na" %} - {:.feature-neutral} - - **No transaction list**
    - Does not support listing of transactions. -{% elsif rbf.receive.shows_replaced_version == "untested" or - rbf.receive.shows_original_version == "untested" %} - {:.feature-neutral} - - **Not tested: Are replacement and original received transactions displayed?**
    - We either didn’t test this or could not appropriately determine the results. -{% elsif rbf.receive.shows_replaced_version == "true" %} - {:.feature-yes} - - **Shows replacement transaction only**
    - Only the replacement transaction is shown in the transaction list. No original - transaction is shown. -{% elsif rbf.receive.shows_original_version == "true" %} - {:.feature-no} - - **Shows original transaction only**
    - Only the original transaction is shown in transaction list. Replacement transactions - are not shown. -{% elsif rbf.receive.shows_original_version == "false" and rbf.receive.shows_replaced_version == "false" %} - {:.feature-no} - - **No unconfirmed transactions**
    - Neither the original nor replacement transactions are shown in the - transaction list. Unconfirmed transactions are probably not supported. -{% else %} {% include ERROR_42_UNEXPECTED_VALUE %} -{% endif %} - -
    {% comment %}{% endcomment %} - -### Sending support - -
    - -{:id="send-signals_bip125"} -{% case rbf.send.signals_bip125 %} - {% when "true" %}{:.feature-yes} - - **Signals BIP125 replacability when sending transactions**
    - Allows sending of BIP125 opt-in-RBF transactions in the interface. - {% when "false" %}{:.feature-no} - - **Does not signal BIP125 replacability when sending transactions**
    - Does not allow sending of BIP125 opt-in-RBF transactions in the interface. - {% when "na" %}{:.feature-neutral} - - **Does not send transactions**
    - Does not support sending of any transactions. - {% when "untested" %}{:.feature-neutral} - - **Not tested: Can sent transactions signal RBF?**
    - We either didn’t test this or could not appropriately determine the results. - {% else %}{% include ERROR_42_UNEXPECTED_VALUE %} -{% endcase %} - -{:id="send-list"} -{% case rbf.send.list %} - {% when "true" %}{:.feature-yes} - - **Sent transaction labeled replaceable in list**
    - Visually indicates that an outgoing transaction has signaled RBF. - {% when "false" %}{:.feature-no} - - **Sent transaction not labeled replaceable in list**
    - Does not visually indicate that an outgoing transaction has signaled RBF. - {% when "na" %}{:.feature-neutral} - - **No transaction list**
    - Does not show a transaction list natively. - {% when "untested" %}{:.feature-neutral} - - **Not tested: Does transaction list show whether sent transactions signal RBF?**
    - We were not able to test this because sending a BIP125 signaling transaction - is not supported. - {% else %}{% include ERROR_42_UNEXPECTED_VALUE %} -{% endcase %} - -{:id="send-details"} -{% case rbf.send.details %} - {% when "true" %}{:.feature-yes} - - **Sent transaction labeled replaceable in transaction details**
    - Visually indicates that a sent transaction has signaled RBF when viewing the transaction details. - {% when "false" %}{:.feature-no} - - **Sent transaction not labeled replaceable in transaction details**
    - Does not visually indicate that a sent transaction has signaled RBF when viewing the transaction details. - {% when "na" %}{:.feature-neutral} - - **Does not show transaction details**
    - Does not show transaction details natively. Usually this means the service links to a block explorer for transaction details. - {% when "untested" %}{:.feature-neutral} - - **Not tested: Does transaction details page show whether received transaction signals RBF?**
    - We were not able to test this because sending a BIP125 signaling transaction - is not supported. - {% else %}{% include ERROR_42_UNEXPECTED_VALUE %} -{% endcase %} - -{:id="send-replaced"} -{% if rbf.send.shows_replaced_version == "true" and rbf.send.shows_original_version == "true" %} - {:.feature-yes} - - **Shows replacement and original transactions**
    - Both the original transaction and replacement transactions are shown in the - transaction list. -{% elsif rbf.send.shows_replaced_version == "na" or - rbf.send.shows_original_version == "na" %} - {:.feature-neutral} - - **No replacements in transaction list**
    - Because no transaction replacement is possible in the user interface, we could not test whether - original or replacement sent transactions are shown after replacement. -{% elsif rbf.send.shows_replaced_version == "untested" or - rbf.send.shows_original_version == "untested" %} - {:.feature-neutral} - - **Not tested: Are replacement and original sent transactions displayed?**
    - We were not able to test this because sending a BIP125 signaling transaction - is not supported. -{% elsif rbf.send.shows_replaced_version == "true" %} - {:.feature-yes} - - **Shows replacement transaction only**
    - Only the replacement transaction is shown in the transaction list. No original - transaction is shown. -{% elsif rbf.send.shows_original_version == "true" %} - {:.feature-no} - - **Shows original transaction only**
    - Only the original transaction shown in transaction list. Replacement transactions are - not shown. -{% elsif rbf.send.shows_original_version == "false" and rbf.send.shows_replaced_version == "false" %} - {:.feature-no} - - **No unconfirmed transactions**
    - Neither the original nor replacement transactions are shown in the - transaction list. Unconfirmed transactions are probably not supported. -{% else %} {% include ERROR_42_UNEXPECTED_VALUE %} -{% endif %} - -
    {% comment %}{% endcomment %} - -### Usability - -{% include functions/compat-gallery.md examples=tool.rbf.examples %} - -{% else %} -*We have not yet tested {{tool.name}} for RBF capabilities.* -{% endif %} \ No newline at end of file diff --git a/_includes/templates/compatibility/segwit.md b/_includes/templates/compatibility/segwit.md deleted file mode 100644 index 36a1c9dfd0..0000000000 --- a/_includes/templates/compatibility/segwit.md +++ /dev/null @@ -1,150 +0,0 @@ -## Segwit Addresses {#segwit} - -**What are segwit addresses?** Transactions that spend bitcoins secured by segregated witness (segwit) use less -block weight than equivalent non-segwit (legacy) transactions, allowing -segwit transactions to pay less total fee to achieve the same feerate as legacy transactions. - -{% if tool.segwit %} - -{% assign tested = tool.segwit.tested. %} -**Tested**: {% if tested.version != "n/a" %} *version {{tested.version}}* {% endif %} on *{{tested.platforms}}* - -**Tested on**: *{{tested.date}}* - -### Receive support - -
    - -{% assign segwit = tool.segwit.features. %} -{:id="segwit-receive-p2sh_wrapped"} -{% case segwit.receive.p2sh_wrapped %} - {% when "true" %}{:.feature-yes} - - **Allows receiving to P2SH-wrapped segwit**
    - Allows the generation of P2SH-wrapped (either P2WPKH or P2WSH) segwit receiving addresses. - {% when "false" %}{:.feature-no} - - **Does not allow receiving to P2SH-wrapped segwit**
    - Does not allow the generation of P2SH-wrapped (either P2WPKH or P2WSH) segwit receiving addresses. - {% when "na" %}{:.feature-neutral} - - **No receiving capabilities**
    - There are no receiving capabilities for this service. - {% when "untested" %}{:.feature-neutral} - - **Not tested: Can P2SH-wrapped segwit transaction outputs be received?**
    - We either didn’t test this or could not appropriately determine the results. - {% else %}{% include ERROR_42_UNEXPECTED_VALUE %} -{% endcase %} - -{:id="segwit-receive-bech32"} -{% case segwit.receive.bech32 %} - {% when "true" %}{:.feature-yes} - - **Allows receiving to bech32 segwit addresses**
    - Allows the generation of bech32 native (either P2WPKH or P2WSH) segwit receiving addresses. - {% when "false" %}{:.feature-no} - - **Does not allow receiving to bech32 segwit addresses**
    - Does not allow the generation of bech32 native (either P2WPKH or P2WSH) segwit receiving addresses. - {% when "na" %}{:.feature-neutral} - - **No receiving capabilities**
    - There are no receiving capabilities for this service. - {% when "untested" %}{:.feature-neutral} - - **Not tested: Can bech32 segwit transaction outputs be received?**
    - We either didn’t test this or could not appropriately determine the results. - {% else %}{% include ERROR_42_UNEXPECTED_VALUE %} -{% endcase %} - -{:id="segwit-receive-default"} -{% case segwit.receive.default %} - {% when "p2pkh" %}{:.feature-no} - - **Default receiving address is P2PKH**
    - This service generates legacy P2PKH receiving addresses by default. - {% when "p2sh" %}{:.feature-no} - - **Default receiving address is P2SH**
    - This service generates P2SH (not P2SH-wrapped segwit) receiving addresses by - default. - {% when "p2sh_wrapped" %}{:.feature-yes} - - **Default receiving address is P2SH-wrapped P2WPKH**
    - This service generates P2SH-wrapped P2WPKH segwit receiving addresses by - default. - {% when "p2sh_wrapped_p2wsh" %}{:.feature-yes} - - **Default receiving address is P2SH-wrapped P2WSH**
    - This service generates P2SH-wrapped P2WSH segwit receiving addresses by default. - {% when "bech32" %}{:.feature-yes} - - **Default receiving address is bech32 P2WPKH**
    - This service generates bech32 P2WPKH segwit receiving addresses by default. - {% when "bech32_p2wsh" %}{:.feature-yes} - - **Default receiving address is bech32 P2WSH**
    - This service generates bech32 P2WSH segwit receiving addresses by default. - {% when "na" %}{:.feature-neutral} - - **No receiving capabilities**
    - There are no receiving capabilities for this service. - {% when "untested" %}{:.feature-neutral} - - **Not tested: What is the default receiving address type?**
    - We either didn’t test this or could not appropriately determine the results. - {% else %}{% include ERROR_42_UNEXPECTED_VALUE %} -{% endcase %} - -
    {% comment %}{% endcomment %} - -### Send support - -
    - -{:id="segwit-send-bech32"} -{% case segwit.send.bech32 %} - {% when "true" %}{:.feature-yes} - - **Allows sending to bech32 P2WPKH addresses**
    - Allows sending to bech32 P2WPKH native segwit addresses. - {% when "false" %}{:.feature-no} - - **Does not allow sending to bech32 P2WPKH addresses**
    - Does not allow sending to bech32 P2WPKH native segwit addresses. - {% when "na" %}{:.feature-neutral} - - **No sending capabilities**
    - There are no sending capabilities for this service. - {% when "untested" %}{:.feature-neutral} - - **Not tested: Can transaction outputs be sent to bech32 P2WPKH addresses?**
    - We either didn’t test this or could not appropriately determine the results. - {% else %}{% include ERROR_42_UNEXPECTED_VALUE %} -{% endcase %} - -{:id="segwit-send-bech32_p2wsh"} -{% case segwit.send.bech32_p2wsh %} - {% when "true" %}{:.feature-yes} - - **Allows sending to bech32 P2WSH addresses**
    - Allows sending to bech32 P2WSH native segwit addresses. - {% when "false" %}{:.feature-no} - - **Does not allow sending to bech32 P2WSH addresses**
    - Does not allow sending to bech32 P2WSH native segwit addresses. - {% when "na" %}{:.feature-neutral} - - **No sending capabilities**
    - There are no sending capabilities for this service. - {% when "untested" %}{:.feature-neutral} - - **Not tested: Can transaction outputs be sent to bech32 P2WSH addresses?**
    - We either didn’t test this or could not appropriately determine the results. - {% else %}{% include ERROR_42_UNEXPECTED_VALUE %} -{% endcase %} - -{:id="segwit-send-change_bech32"} -{% case segwit.send.change_bech32 %} - {% when "true" %}{:.feature-yes} - - **Creates bech32 change addresses**
    - When sending, generates bech32 (either P2WPKH or P2WSH) segwit change addresses. - {% when "false" %}{:.feature-no} - - **Does not create bech32 change addresses**
    - When sending, does not generate bech32 (either P2WPKH or P2WSH) segwit change addresses. - {% when "na" %}{:.feature-neutral} - - **No sending or change capabilities**
    - There are no sending capabilities for this service or sending does not - generate change. - {% when "untested" %}{:.feature-neutral} - - **Not tested: Can bech32 addresses be used for change?**
    - We either didn’t test this or could not appropriately determine the results. - {% else %}{% include ERROR_42_UNEXPECTED_VALUE %} -{% endcase %} - -
    {% comment %}{% endcomment %} - -### Usability - -{% include functions/compat-gallery.md examples=tool.segwit.examples %} - -{% else %} -*We have not yet tested {{tool.name}} for segwit capabilities.* -{% endif %} diff --git a/_layouts/chapter.html b/_layouts/chapter.html deleted file mode 100644 index 95d8d93266..0000000000 --- a/_layouts/chapter.html +++ /dev/null @@ -1,29 +0,0 @@ ---- -layout: page ---- -{{ content }} - -{% capture /dev/null %} - {% capture _previous_chapter %}[Table of contents](../){% endcapture %} - {% for chapter in site.data.scaling.toc %} - {% if chapter.permalink == page.url %} - {% assign _chapter_match = true %} - {% unless forloop.first %} - {% assign _prev_index = forloop.index0 | minus: 1 %} - {% capture _previous_chapter %}[{{site.data.scaling.toc[_prev_index].name}}]({{site.data.scaling.toc[_prev_index].permalink}}){% endcapture %} - {% endunless %} - {% unless forloop.last %} - {% assign _next_index = forloop.index0 | plus: 1 %} - {% capture _next_chapter %}[{{site.data.scaling.toc[_next_index].name}}]({{site.data.scaling.toc[_next_index].permalink}}){% endcapture %} - {% endunless %} - {% break %} - {% endif %} - {% endfor %} - {% unless _chapter_match %}{% include ERROR72_no_matching_chapter %}{% endunless %} - {% unless _next_chapter %}{% capture _next_chapter %}[Return to table of contents](../){% endcapture %}{% endunless %} - {%- capture _links -%} - **Previous:**
    {{_previous_chapter}}     - **Next:**
    {{_next_chapter}}     - {%- endcapture %} -{% endcapture %}

    {{_links | markdownify}} - diff --git a/_layouts/page.html b/_layouts/page.html index 54c8a08454..8166d86d46 100644 --- a/_layouts/page.html +++ b/_layouts/page.html @@ -8,7 +8,7 @@
    {% include linkers/breadcrumbs.md path=page.url %} - {% if page.title %} + {% if page.title and page.title != "" %}

    {{ page.title | escape }}

    diff --git a/_layouts/podcast-episode.html b/_layouts/podcast-episode.html new file mode 100644 index 0000000000..71b2dce457 --- /dev/null +++ b/_layouts/podcast-episode.html @@ -0,0 +1,39 @@ +--- +layout: default +--- + + + diff --git a/_layouts/podcast.md b/_layouts/podcast.md new file mode 100644 index 0000000000..0fe070ab16 --- /dev/null +++ b/_layouts/podcast.md @@ -0,0 +1,44 @@ +--- +type: pages +layout: default +--- + + + + +

    Podcast

    + +Join us for the weekly Bitcoin Optech Recap on Riverside at 16:30 UTC as we discuss Bitcoin and Lightning technology and review our newsletters. + +{% include functions/podcast-links.md %} + +{% if content != ""%} +
    + {{ content }} +
    +{%- endif -%} + +{% assign posts_podcast = site.posts | where:"lang", page.lang | where:"type","podcast" %} + +
      + {%- for post in posts_podcast -%} +
    • + {%- assign date_format = site.minima.date_format | default: "%b %-d, %Y" -%} + {{ post.date | date: date_format }} +

      + + {{ post.title | escape }} + +

      + {%- if site.show_excerpts -%} + {{ post.excerpt }} + {%- endif -%} +
      • + {%- endfor -%} +
    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/_plugins/auto-anchor.rb b/_plugins/auto-anchor.rb index 445aafc471..9d51dc21c6 100644 --- a/_plugins/auto-anchor.rb +++ b/_plugins/auto-anchor.rb @@ -16,10 +16,7 @@ def auto_anchor(content) ## No match, pass item through unchanged string else - ## Remove double-quotes from titles before attempting to slugify - title.gsub!('"', '') - ## Use Liquid/Jekyll slugify filter to choose our id - slug = "\#{{ \"#{title}\" | slugify: 'latin' }}" + slug = generate_slug(title) id_prefix = "- {:#{slug} .anchor-list} ●" string.sub!(/-/, id_prefix) end diff --git a/_plugins/common_utils.rb b/_plugins/common_utils.rb new file mode 100644 index 0000000000..67adf06802 --- /dev/null +++ b/_plugins/common_utils.rb @@ -0,0 +1,10 @@ +def generate_slug(title) + ## Remove double-quotes from titles before attempting to slugify + title.gsub!('"', '') + ## Use Liquid/Jekyll slugify filter to choose our id + liquid_string = "\#{{ \"#{title}\" | slugify: 'latin' }}" + slug = Liquid::Template.parse(liquid_string) + # An empty context is used here because we only need to parse the liquid + # string and don't require any additional variables or data. + slug.render(Liquid::Context.new) +end \ No newline at end of file diff --git a/_plugins/recap_references_generator.rb b/_plugins/recap_references_generator.rb new file mode 100644 index 0000000000..a08f2b650c --- /dev/null +++ b/_plugins/recap_references_generator.rb @@ -0,0 +1,147 @@ +# frozen_string_literal: true + +# Regex pattern to match "{% assign timestamp="xx:xx:xx" %}" +$podcast_reference_mark = /\{%\s*assign\s+timestamp\s*=\s*"([^"]+)"\s*%\}/ + +# Create the podcast recap references by parsing the referenced newsletter for +# podcast reference marks (timestamps) +class RecapReferencesGenerator < Jekyll::Generator + def generate(site) + podcast_pages = site.documents.select { |doc| doc.data["type"] == "podcast"} + podcast_pages.each do |podcast| + # podcast episodes have a "reference" field that indicates the related newsletter page + unless podcast.data["reference"].nil? + reference_page = site.documents.detect { |page| page.url == podcast.data["reference"] } + + # override the content of the reference page (newsletter) to now include + # the links to the related podcast items + reference_page.content, + # keep all the references in a podcast page variable to use them later + # during the podcast page creation + podcast.data["references"] = get_podcast_references(reference_page.content, podcast.url) + + # we use this in `newsletter-references.md` to be easier to identify + # special sections when iterating through the sections of the newsletter + podcast.data["special_sections"] = [] + + podcast.data["references"].each do |reference| + if reference["title"].nil? + # the title of a reference derives from the nested list items + # under a header/section (News, Releases and release candidates, etc.) + # if there are no list items, we end up with a missing title + # we use this assumption to identify special sections + podcast.data["special_sections"] << reference["header"] + # use the header as the title of the section + reference["title"] = reference["header"] + reference["slug"] = generate_slug(reference["header"]) + end + # Each podcast transcript splits into segements using the paragraph title + # as the title of the segment. These segment splits must be added manually but + # we can avoid the need to also manually add their anchors by doing that here, + # where we effectivily search for the segment splits and prefix them with the anchor + reference["has_transcript_section"] = + podcast.content.sub!( + /^(_.*?#{Regexp.escape(reference["title"])}.*?_)/, + "{:#{reference["slug"]}-transcript}\n \\1" + ) + end + end + end + end + + def find_title(string, in_list=true) + # this conditional prefix is for the special case of the review club section + # which is not a list item (no dash (-) at the start of the line) + prefix = in_list ? / *- / : // + + # Find shortest match for **bold**, or [markdown][links] + # note: when we are matching the title in `auto-anchor.rb` we also match *italics* + # but on the newsletter sections nested bullets have *italics* titles therefore + # by ignoring *italics* we are able to easier link to the outer title + title = string.match(/^#{prefix}(?:\*\*(.*?):?\*\*|\[(.*?):?\][(\[])/)&.captures&.compact&.[](0) || "" + if title.empty? + {} + else + result = {"title"=> title} + slug = {"slug"=> generate_slug(title)} + result.merge!(slug) + end + end + + # This method searches the content for paragraphs that indicate that they are + # part of a podcast recap. When a paragraph is part of a recap we: + # - postfix with a link to the related podcast item + # - get the header, title and title slug of the paragraph to create + # the references for the podcast + def get_podcast_references(content, target_page_url) + # The logic here assumes that: + # - paragraphs have headers + # - each block of text (paragraph) is seperated by an empty line + + # Split the content into paragraphs + paragraphs = content.split(/\n\n+/) + # Find all the headers in the content + headers = content.scan(/^#+\s+(.*)$/).flatten + + # Create an array of hashes containing: + # - the paragraph's title + # - the paragraph's title slug + # - the associated header + # - the timestamp of the podcast in which this paragraph is discussed + podcast_references = [] + current_header = 0 + current_title = {} + in_review_club_section = false + + # Iterate over all paragraphs to find those with a podcast reference mark + paragraphs.each do |p| + # a title might have multiple paragraphs associated with it + # the podcast reference mark might be at the end of an isolated + # paragraph snippet that cannot access the title, therefore + # we keep this information to be used in the link to the podcast recap + title = find_title(p, !in_review_club_section) + if !title.empty? + # paragraph has title + current_title = title + end + + # If the current paragraph contains the podcast reference mark, + # capture the timestamp, add paragraph to references and replace + # the mark with link to the related podcast item + p.gsub!($podcast_reference_mark) do |match| + if in_review_club_section + # the newsletter's review club section is the only section that does + # not have a list item to use as anchor so we use the header + current_title["podcast_slug"] = "#pr-review-club" # to avoid duplicate anchor + current_title["slug"] = "#bitcoin-core-pr-review-club" + end + podcast_reference = {"header"=> headers[current_header], "timestamp"=> $1} + podcast_reference.merge!(current_title) + podcast_references << podcast_reference + + if current_title.empty? + # this is needed for the podcast reference mark to link to the header + # of the special section + current_title["slug"] = generate_slug(headers[current_header]) + end + # Replace the whole match with the link + headphones_link = "[]" + replacement_link_to_podcast_item = "#{headphones_link}(#{target_page_url}#{current_title["podcast_slug"] || current_title["slug"]})" + end + + # update to the next header when parse through it + if p.sub(/^#+\s*/, "") == headers[(current_header + 1) % headers.length()] + current_header += 1 + in_review_club_section = headers[current_header] == "Bitcoin Core PR Review Club" + # reset header-specific variables + current_title = {} + end + + end + + # Join the paragraphs back together to return the modified content + updated_content = paragraphs.join("\n\n") + + [updated_content, podcast_references] + end +end \ No newline at end of file diff --git a/_posts/cs/2023-03-08-podcast.md b/_posts/cs/2023-03-08-podcast.md new file mode 100644 index 0000000000..b0b605afa8 --- /dev/null +++ b/_posts/cs/2023-03-08-podcast.md @@ -0,0 +1,60 @@ +--- +title: "Nový podcast Optechu" +permalink: /cs/podcast-announcement/ +name: 2023-03-08-podcast-announcement-cs +type: posts +layout: post +lang: cs +slug: 2023-03-08-podcast-announcement-cs + +excerpt: > + Oznámení o novém Optech podcastu založeném na týdenních Optech Audio + Recap na Twitter Spaces. + +--- +Od července 2022 se na Twitter Spaces scházejí přispěvatelé Optechu +Mike Schmidt a Mark „Murch” Erhardt se členy komunity a významnými +vývojáři bitcoinových a LN protokolů, aby probrali události popsané +každý týden ve zpravodaji. Každá z těchto diskuzí bude nyní přístupná +ve formě jednotlivých epizod na [všech hlavních podcastových platformách][podcast +index]. + +Každá epizoda bude mít také svou stránku na webu Optechu se souhrnem obsahu +epizody a kompletním přepisem. Věříme, že toto je významný krok +v naší misi za vylepšením komunikace mezi open source projekty +a jejich uživateli a byznysem. + +Kdo si chce udržet přehled o vývoji bitcoinových a LN protokoků, může +se přihlásit buď k odběru zpravodaje (čte-li rád) nebo podcastu (preferuje-li +poslech). Pokud čtenář zpravodaje zatouží po více informacích o nějakém tématu, +může poslechem podcastu nebo četbou jeho přepisu zjistit, co o tématu říkají +zkušení bitcoinoví přispěvatelé. Nebo pokud o zajímavém tématu uslyší nejdříve +v podcastu, může následně díky zpravodají nalézt původní diskuzi v emailové +skupině nebo pull requestu. + +Pro snadnou orientaci na sebe navzájem podcast i zpravodaj odkazují. Jediným +kliknutím na konci odstavce ve zpravodaji budete přesměrováni na odpovídající +sekci v podcastu. Odtud můžete okamžitě skočit do zvukové stopy nebo přepisu. +Souhrn každé epizody podcastu odkazuje přímo na odstavec v původním zpravodaji, +kterým se zabývá. + +V budoucnosti budou moci uživatelé, vývojáři i badatelé vyhledat bod zájmu +v rozsáhlém [rejstříku témat][topic index], přečíst krátký souhrn o události ve zpravodaji +a poté poslechnout nebo přečíst o tomto tématu dobovou diskuzi, které se často +účastní odborníci, kteří sami největším dílem k tématu přispěli, a uživatelé, +kterých se nejvíce dotýká. + +Pochopitelně jsou audio i přepisy dostupné pod open source licencí jako +veškerý obsah Optechu. + +Nové epizody budou uvolňovány několik dní po ukončení vysílání na Twitter +Spaces a po profesionálním zpracování zvukové stopy. Přepisy budou zveřejněny +pár dní nato. Postupně budou také přidávány zvukové stopy a přepisy +starších epizod. + +Máte-li zájem o technologii kolem bitcoinu, doporučujeme přihlásit se k +odběru podcastu a zvážit účast na každotýdenním přehledu na Twitter Spaces. + +{% include references.md %} +[topic index]: /en/topics/ +[podcast index]: /en/podcast/ diff --git a/_posts/cs/2023-05-17-policy.md b/_posts/cs/2023-05-17-policy.md new file mode 100644 index 0000000000..19a635590c --- /dev/null +++ b/_posts/cs/2023-05-17-policy.md @@ -0,0 +1,100 @@ +--- +title: "Čekání na potvrzení: série o mempoolu a pravidlech přeposílání" +permalink: /cs/blog/waiting-for-confirmation/ +name: 2023-05-17-waiting-for-confirmation-cs +slug: 2023-05-17-waiting-for-confirmation-cs +type: posts +layout: post +lang: cs + +excerpt: > + Všechny publikované části naší týdenní série o přeposílání transakcí, + začleňování do mempoolu, výběru transakcí k vytěžení a o důvodech, + proč má Bitcoin Core přísnější pravidla než jaká stanoví konsenzus a jak + těchto pravidel mohou peněženky efektivně využít. + +--- + + +{% include references.md %} + +{:.post-meta} +*napsali [Gloria Zhao][] a [Murch][]* + +{{page.excerpt}} + +1. toc +{:toc} + +## K čemu je mempool? + +*Původně vyšlo ve [zpravodaji č. 251](/cs/newsletters/2023/05/17/#čekání-na-potvrzení-1-k-čemu-je-mempool)* + +{% include specials/policy/cs/01-why-mempool.md %} + +## Incentivy + +*Původně vyšlo ve [zpravodaji č. 252](/cs/newsletters/2023/05/24/#čekání-na-potvrzení-2-incentivy)* + +{% include specials/policy/cs/02-cache-utility.md %} + +## Aukce blokového prostoru + +*Původně vyšlo ve [zpravodaji č. 253](/cs/newsletters/2023/05/31/#čekání-na-potvrzení-3-aukce-blokového-prostoru)* + +{% include specials/policy/cs/03-bidding-for-block-space.md %} + +## Odhad poplatků + +*Původně vyšlo ve [zpravodaji č. 254](/cs/newsletters/2023/06/07/#čekání-na-potvrzení-4-odhad-poplatků)* + +{% include specials/policy/cs/04-feerate-estimation.md %} + +## Pravidla pro ochranu zdrojů uzlů + +*Původně vyšlo ve [zpravodaji č. 255](/cs/newsletters/2023/06/14/#čekání-na-potvrzení-5-pravidla-pro-ochranu-zdrojů-uzlů)* + +{% include specials/policy/cs/05-dos.md %} + +## Konzistence pravidel + +*Původně vyšlo ve [zpravodaji č. 256](/cs/newsletters/2023/06/21/#čekání-na-potvrzení-6-konzistence-pravidel)* + +{% include specials/policy/cs/06-consistency.md %} + +## Síťové zdroje + +*Původně vyšlo ve [zpravodaji č. 257](/cs/newsletters/2023/06/28/#čekání-na-potvrzení-7-síťové-zdroje)* + +{% include specials/policy/cs/07-network-resources.md %} + +## Pravidla jako rozhraní + +*Původně vyšlo ve [zpravodaji č. 258](/cs/newsletters/2023/07/05/#čekání-na-potvrzení-8-pravidla-jako-rozhraní)* + +{% include specials/policy/cs/08-interface.md %} + +## Návrhy pravidel + +*Původně vyšlo ve [zpravodaji č. 259](/cs/newsletters/2023/07/12/#čekání-na-potvrzení-9-návrhy-pravidel)* + +{% include specials/policy/cs/09-proposals.md %} + +## Zapojte se + +*Původně vyšlo ve [zpravodaji č. 260](/cs/newsletters/2023/07/19/#čekání-na-potvrzení-10-zapojte-se)* + +{% include specials/policy/cs/10-get-involved.md %} + +{% comment %}{% endcomment %} + +[Gloria Zhao]: https://github.com/glozow +[Murch]: https://github.com/murchandamus diff --git a/_posts/cs/2023-08-16-bitgo-musig2.md b/_posts/cs/2023-08-16-bitgo-musig2.md new file mode 100644 index 0000000000..25e1178a9c --- /dev/null +++ b/_posts/cs/2023-08-16-bitgo-musig2.md @@ -0,0 +1,15 @@ +--- +title: 'Terénní zpráva o implementaci MuSig2' +permalink: /cs/bitgo-musig2/ +name: 2023-08-16-bitgo-musig2-cs +slug: 2023-08-16-bitgo-musig2-cs +type: posts +layout: post +lang: cs +version: 1 +excerpt: > + Tato terénní zpráva nastiňuje způsob, kterým BitGo zkoumalo, implementovalo + a nasadilo možnost provádět na své platformě MuSig2 podepisování. + +--- +{% include articles/cs/bitgo-musig2.md %} diff --git a/_posts/cs/2023-11-15-wizardsardine-miniscript.md b/_posts/cs/2023-11-15-wizardsardine-miniscript.md new file mode 100644 index 0000000000..02ec855b87 --- /dev/null +++ b/_posts/cs/2023-11-15-wizardsardine-miniscript.md @@ -0,0 +1,14 @@ +--- +title: 'Terénní zpráva: Cesta k miniscriptu' +permalink: /cs/wizardsardine-miniscript/ +name: 2023-11-15-wizardsardine-miniscript-cs +slug: 2023-11-15-wizardsardine-miniscript-cs +type: posts +layout: post +lang: cs +version: 1 +excerpt: > + Tato terénní zpráva nastiňuje osvojení miniscriptového ekosystému z pohledu Wizardsardine. + +--- +{% include articles/cs/wizardsardine-miniscript.md %} 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/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 b40dc008e0..37ed2feba8 100644 --- a/_posts/cs/newsletters/2022-05-18-newsletter.md +++ b/_posts/cs/newsletters/2022-05-18-newsletter.md @@ -137,7 +137,7 @@ praise: - url: https://twitter.com/RobertSpigler/status/1058780917685239810 author: Robert Spigler - text: OpSec consultant + title: OpSec consultant text: "@bitcoinoptech je komunitní projekt neuvěřitelné hodnoty a čím větší součást ekosystému se na něm podílí a osvojuje si nejlepší praktiky, tím lépe." - url: https://twitter.com/carl_dong/status/1057721562449633280 @@ -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-23-newsletter.md b/_posts/cs/newsletters/2022-11-23-newsletter.md new file mode 100644 index 0000000000..889f99e7d9 --- /dev/null +++ b/_posts/cs/newsletters/2022-11-23-newsletter.md @@ -0,0 +1,117 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 227' +permalink: /cs/newsletters/2022/11/23/ +name: 2022-11-23-newsletter-cs +slug: 2022-11-23-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme naše pravidelné rubriky s výběrem otázek a odpovědí z +Bitcoin Stack Exchange, oznámeními nových vydání a popisem významných změn +oblíbených páteřních bitcoinových projektů. + +## Novinky + +*Tento týden jsme nenalezli v emailových skupinách Bitcoin-Dev a Lightning-Dev žádné významné novinky.* + +## 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/" %} + +- [Jsou kvůli BIP-16 (P2SH) některé bitcoiny neutratitelné?]({{bse}}115803) + Uživatel bca-0353f40e ukazuje šest výstupů, které obsahovaly skript v P2SH formátu + `OP_HASH160 OP_DATA_20 [hash] OP_EQUAL` ještě před aktivací [BIP16][]. + Jeden z nich byl utracen podle starých pravidel před aktivací a v aktivačním kódu + byla [zanesena výjimka][p2sh activation exception] pro tento jediný blok. Zbývající + UTXO budou v případě utracení podléhat pravidlům BIP16. + +- [Jaký software byl používán ke generování P2PK transakcí?]({{bse}}115962) + Pieter Wuille poznamenává, že původní bitcoinový program vytvářel P2PK výstupy + nejen v coinbase transakcích, ale také při posílání IP transakcí ([pay-to-IP + adresy][wiki p2ip]). + +- [Proč jsou spojením posílány zároveň txid i wtxid?]({{bse}}115907) + Pieter Wuille odkazuje na [BIP339][] a vysvětluje, že zatímco wtxid jsou + vhodnější pro přeposílání – mimo jiné kvůli poddajnosti („malleability”), některé + uzly novější identifikátory wtxid nepodporují. Txid jsou tedy podporovány z důvodu + zpětné kompatibility se staršími uzly. + +- [Jak mohu vytvořit taprootovou adresu s vícenásobným podpisem?]({{bse}}115700) + Pieter Wuille poznamenává, že současná RPC volání pro [vícenásobné podpisy][topic multisignature] + (multisig), jako jsou např. `createmultisig` či `addmultisigaddress`, budou podporovat + pouze staré peněženky, a nastiňuje, že s Bitcoin Core 24.0 budou moci uživatelé + k vytváření [taprootových][topic taproot] skriptů s vícenásobným podpisem + použít [deskriptory][topic descriptors] a RPC volání (např. `deriveaddresses` nebo + `importdescriptors`) spolu s novým deskriptorem `multi_a`. + +- [Je možné na novém ořezaném (pruned) uzlu přeskočit stahování bloků?]({{bse}}116030) + Ač v současnosti není v Bitcoin Core tato možnost podporována, Pieter Wuille odkazuje + na projekt [assumeutxo][topic assumeutxo]. Ten by umožnil nastartovat nové uzly + stažením množiny UTXO, která by byla ověřena pomocí pevně zakódovaného hashe bez nutnosti + důvěřovat zdroji. + +## 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 0.15.5-beta.rc2][] je kandidátem na údržbové vydání LND. Podle plánovaných poznámek + vydání obsahuje pouze opravy drobných chyb. + +- [Core Lightning 22.11rc2][] je kandidátem na vydání příští hlavní verze CLN. Tímto vydáním + přejde CLN na nový model číslování verzí, avšak nadále bude používat [sémantické verzování][semantic + versioning]. + +## Významné změny v kódu a dokumentaci + +*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] a [Lightning BOLTs][bolts repo].* + +- [Bitcoin Core #25730][] přidává k RPC volání `listunspent` nový argument, + který mezi výsledky volání začlení též coinbase výstupy, které nemohou + být ještě utraceny, neboť od jejich začlenění těžařem nebylo ještě nalezeno + více než 100 bloků. + +- [LND #7082][] upravuje způsob vytváření faktur bez požadované částky tak, aby mohly + obsahovat doporučené trasy, jež by pomohly odesílateli najít cestu k příjemci. + +- [LDK #1413][] odstraňuje podporu pro původní formát onion dat s pevnou délkou. + Nový format s proměnlivou délkou byl do specifikace přidán před více než třemi lety + a podpora původní verze byla již odstraněna ze specifikace (viz [zpravodaj + č. 220][news220 bolts962], *angl.*), z Core Lightning ([zpravodaj č. 193][news193 + cln5058], *angl.*), LND ([zpravodaj č. 196][news196 lnd6385], *angl.*) a Eclair + ([zpravodaj č. 217][news217 eclair2190], *angl.*). + +- [HWI #637][] přidává podporu pro velký plánovaný upgrade bitcoinového firmwaru + v zařízeních Ledger. Úprava nakládání s pravidly utrácení, jak byla zmíněna ve + [zpravodaji č. 200][news200 policy], nebyla do této změny začleněna; je však zmíněna + jako plánovaná do budoucna. + +{% include references.md %} +{% include linkers/issues.md v=2 issues="25730,7082,1413,637" %} +[bitcoin core 24.0]: https://bitcoincore.org/bin/bitcoin-core-24.0/ +[bcc 24.0 rn]: https://github.com/bitcoin/bitcoin/blob/0ee1cfe94a1b735edc2581a05c4b12f8340ff609/doc/release-notes.md +[news222 rbf]: /en/newsletters/2022/10/19/#transaction-replacement-option +[news223 rbf]: /en/newsletters/2022/10/26/#continued-discussion-about-full-rbf +[news224 rbf]: /en/newsletters/2022/11/02/#mempool-consistency +[lnd 0.15.5-beta.rc2]: https://github.com/lightningnetwork/lnd/releases/tag/v0.15.5-beta.rc2 +[core lightning 22.11rc2]: https://github.com/ElementsProject/lightning/releases/tag/v22.11rc2 +[news220 bolts962]: /en/newsletters/2022/10/05/#bolts-962 +[news217 eclair2190]: /en/newsletters/2022/09/14/#eclair-2190 +[news193 cln5058]: /en/newsletters/2022/03/30/#c-lightning-5058 +[news196 lnd6385]: /en/newsletters/2022/04/20/#lnd-6385 +[news200 policy]: /cs/newsletters/2022/05/18/#prizpusobeni-miniscriptu-miniscript-a-deskriptoru-descriptors-podpisovym-zarizenim-signingdevices +[semantic versioning]: https://semver.org/spec/v2.0.0.html +[wiki p2ip]: https://en.bitcoin.it/wiki/IP_transaction +[p2sh activation exception]: https://github.com/bitcoin/bitcoin/commit/ce650182f4d9847423202789856e6e5f499151f8 diff --git a/_posts/cs/newsletters/2022-11-30-newsletter.md b/_posts/cs/newsletters/2022-11-30-newsletter.md new file mode 100644 index 0000000000..fed7599e69 --- /dev/null +++ b/_posts/cs/newsletters/2022-11-30-newsletter.md @@ -0,0 +1,146 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 228' +permalink: /cs/newsletters/2022/11/30/ +name: 2022-11-30-newsletter-cs +slug: 2022-11-30-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +V tomto čísle našeho zpravodaje popisujeme návrh k zamezení útoku +zahlcením kanálu v Lightning Network pomocí osvědčení o reputaci. Dále +přinášíme naše pravidelné rubriky s oznámeními o nových vydáních a významných +změnách oblíbeného bitcoinového páteřního software. + +## Novinky + +- **Návrh na použití osvědčení o reputaci k zamezení zahlcování LN:** + Antoine Riard [poslal][riard credentials] do emailové skupiny Lightning-Dev + [návrh][riard proposal] na systém osvědčení o reputaci jako prostředku + k předcházení tzv. [útoků zahlcením kanálu][topic channel jamming attacks] + („channel jamming attacks”). Tento typ útoku způsobuje dočasné zablokování + platebních slotů ([HTLC][topic htlc]), a znemožňuje tak poctivým uživatelům + posílat platby. + + V rámci Lightning Network volí odesílatel trasu ze svého uzlu do + uzlu příjemce za použití několika kanálů provozovaných nezávislými + prostředníky. Odesílatel generuje sadu instrukcí, které popisují, + kam má každý prostředník platbu dále přeposlat. Tyto instrukce jsou + zašifrovány tak, aby se každý z prostředníků dozvěděl pouze informace + nezbytně nutné k provedení úkolu. + + Riard navrhuje, aby každý prostředník akceptoval pouze takové žádosti + o přeposlání, které obsahují osvědčení vydané tímto prostředníkem. Tato + osvědčení sestávají ze [zaslepených elektronických podpisů][blind signature], + které nedovolují prostředníkům napřímo určit jejich držitele. Identita + odesílatele tak zůstane před prostředníky utajena. Každý uzel si může stanovit + 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ř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. + + 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.*), + [se dotázala][shikelman credentials], zda by tato osvědčení byla přenositelná + mezi uživateli a zda by to mohlo vést k vytvoření trhu s osvědčeními. Též se + ptala, jak by Riardův návrh fungoval se [zaslepenými trasami][topic rv routing], + kde odesílatel nezná kompletní trasu k příjemci. + + Riard [odpověděl][riard double spend], že by bylo složité redistribuovat + osvědčení a vytvořit pro ně trh, neboť by každý přenos vyžadoval důvěru. + Napříkad chtěla-li by Alice prodat Carol osvědčení vydané Bobovým uzlem, + neexistuje žádný způsob, kterým by Alice mohla dokázat Carol, že se nebude + po prodeji snažit osvědčení sama používat. + + Co se týče zaslepených tras, [jeví se][harding paths], že by příjemce mohl + poskytnout veškerá potřebná osvědčení v zašifrované podobě. + + V příslušném [pull requestu][bolts #1043] obdržel tento návrh další zpětnou vazbu. + +## 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 0.15.5-beta.rc2][] je kandidátem na údržbové vydání LND. Podle plánovaných poznámek + vydání obsahuje pouze opravy drobných chyb. + +- [Core Lightning 22.11rc3][] je kandidátem na vydání příští hlavní verze CLN. Tímto vydáním + přejde CLN na nový model číslování verzí, avšak nadále bude používat [sémantické verzování][semantic + versioning]. + +## Významné změny v kódu a dokumentaci + +*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] a [Lightning BOLTs][bolts repo].* + +- [Core Lightning #5727][] začíná v JSON prosazovat textové identifikátory + namísto zastaralých číselných. Do [dokumentace][cln json ids] byly přidány + informace o výhodách textových identifikátorů a o jejich správném vytváření + a interpretování. + +- [Eclair #2499][] umožňuje v žádostech o platbu v rámci [BOLT12 nabídek][topic offers] + nastavit zaslepenou trasu („blinded route”). Ta spočívá v přidání dodatečných uzlů za + adresátův uzel, které však nebudou použity. Jejich účelem je ztížení odesílateli + určit, jak daleko je adresát od posledního nezaslepeného uzlu v trase. + +- [LND #7122][] přidává do `lncli` podporu pro zpracování binárních [PSBT][topic + psbt] souborů. [BIP174][] určuje, že PSBT, neboli *částečně podepsané transakce*, + mohou být zakódovány buď jako binární soubor nebo pomocí Base64 jako text. + LND již dříve umožňovalo import PSBT zakódovaných pomocí Base64 ze souboru + nebo přímo z textu. + +- [LDK #1852][] akceptuje navýšení jednotkového poplatku („feerate”) navržené + jedním z účastníků kanálu, i když není tento poplatek dostatečně vysoký, aby + v dané chvíli bezpečně udržel kanál otevřený. I když nový jednotkový poplatek + není zcela bezpečný, jeho vyšší hodnota v porovnání s předchozí hodnotou + znamená, že je bezpečnější oproti stávající situaci. Je tedy lepší jej akceptovat, + než pokoušet se zavřít kanál s jeho stávajícím (nižším) jednotkovým poplatkem. Budoucí + změny LDK mohou zavírat i kanály, které mají poplatky příliš nízké. Navíc díky práci na + návrzích jako je [přeposílání balíčků][topic package relay] (viz též překlad zpravodaje + [č. 201][news201 package relay] a [č. 204][news204 package relay]) mohou být + [anchor výstupy][topic anchor outputs] a podobné techniky dostatečně flexibilní, + aby zcela odstranily obavy o výši poplatků. + +- [Libsecp256k1 #993][] přidává do výchozího nastavení sestavení moduly pro práci s + extrakeys (funkce pro práci s x-only veřejnými klíči), [ECDH][] a [Schnorrovými + podpisy][topic schnorr signatures]. Modul pro rekonstrukci veřejného + klíče z elektronického podpisu není nadále součástí výchozího nastavení, + „neboť nedoporučujeme, aby nově vznikající protokoly obsahovaly ECDSA obnovu + kvůli náchylnosti API ke zneužití. Ponouká totiž volajícího, aby přeskočil + kontrolu veřejného klíče a automaticky jej pokládal za platný.” + +{% include references.md %} +{% include linkers/issues.md v=2 issues="5727,2499,7122,1852,993,1043" %} +[news222 rbf]: /en/newsletters/2022/10/19/#transaction-replacement-option +[news223 rbf]: /en/newsletters/2022/10/26/#continued-discussion-about-full-rbf +[news224 rbf]: /en/newsletters/2022/11/02/#mempool-consistency +[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://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://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 +[news204 package relay]: /cs/newsletters/2022/06/15/#pokracuje-debata-o-preposilani-balicku diff --git a/_posts/cs/newsletters/2022-12-07-newsletter.md b/_posts/cs/newsletters/2022-12-07-newsletter.md new file mode 100644 index 0000000000..8a11e3dd13 --- /dev/null +++ b/_posts/cs/newsletters/2022-12-07-newsletter.md @@ -0,0 +1,226 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 229' +permalink: /cs/newsletters/2022/12/07/ +name: 2022-12-07-newsletter-cs +slug: 2022-12-07-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden popisujeme implementaci dočasných anchor výstupů a přinášíme +naše pravidelné rubriky se souhrnem sezení Bitcoin Core PR Review Club, +oznámeními o nových vydáních a popisem významných změn populárních páteřních +bitcoinových projektů. + +## Novinky + +- **Implementace dočasných anchor výstupů:** Greg Sanders v emailové skupině + Bitcoin-Dev [oznámil][sanders ephemeral], že vytvořil implementaci + svého nápadu na dočasné („ephemeral”) anchor výstupy (viz [zpravodaj č. #223][news223 + anchors], *angl.*). [Anchor výstupy][topic anchor outputs] jsou existující + technika dostupná díky [CPFP carve out][topic cpfp carve out] a používaná + v LN protokolu k zajištění, aby obě strany kontraktu mohly pomocí [CPFP][topic + cpfp] navýšit poplatek transakcí spojených s tímto kontraktem. Anchor výstupy + mají několik nevýhod; některé principální (viz [zpravodaj č. #224][news224 anchors], + *angl.*), avšak jiné mohou být řešeny. + + Dočasné anchor výstupy staví na návrhu [přeposílání v3 transakcí][topic + v3 transaction relay]. Díky němu mohou v3 transakce obsahovat výstup + s nulovou hodnotou platící skriptu, který je v podstatě jen `OP_TRUE`. Kdokoliv + s utratitelným UTXO může takové transakci navýšit poplatek pomocí CPFP. + Potomek transakce, který navýšení provádí, může sám mít poplatek navýšen pomocí + RBF kýmkoliv jiným s utratitelným UTXO. To by v kombinaci s dalšími částmi návrhu + přeposílání v3 transakcí mělo odstranit veškeré obavy o [transaction pinning útoky][topic + transaction pinning], tedy útoky na transakce protokolů chytrých kontraktů citlivých na + načasování. + + Protože poplatek transakce s dočasným anchor výstupem může být navýšen kýmkoliv, + mohou být použity na protokoly chytrých kontraktů s více než dvěma účastníky. + Existující pravidlo carve out v Bitcoin Core funguje spolehlivě pouze pro dva + účastníky a [předchozí pokusy][bitcoin core #18725] tento počet navýšit vyžadovaly + stanovení maximálního počtu účastníků. + + Sandersova [implementace][bitcoin core #26403] dočasných anchor výstupů umožňuje + začít tento nápad testovat spolu s dalšími funkcemi přeposílání v3 transakcí + dříve implementovanými autorem tohoto návrhu. + +## 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í.* + +[Navyš poplatky nepotvrzených rodičů na úroveň cílového poplatku][review club 26152] +je PR autorů Xekyo (Murch) a glozow, který zvyšuje přesnost kalkulace poplatku +v případě, kdy jsou jako vstupy zvoleny nepotvrzená UTXO. Bez této změny dochází +k nastavení příliš nízkého poplatku, je-li některá nepotvrzená transakce použita +jako vstup a je-li její jednotkový poplatek nižší než poplatek právě vytvářené +transakce. PR řeší tento problém přidáním dostatečného poplatku, aby tato +zdrojová transakce s nízkým poplatkem dosáhla stejného cílového jednotkového +poplatku jako nová transakce. + +I bez tohoto PR se proces výběru mincí snaží vyvarovat utrácení nepotvrzených +transakcí s nízkým jednotkovým poplatkem. Změna přinese výhody v případech, +kdy není zbytí. + +Úprava poplatku na základě těchto rodičovských transakcí se ukázala být podobná +výběru transakcí, které budou začleněny do bloku; proto tato změna přináší novou +třídu nazvanou `MiniMiner`. + +Sezení se [událo][review club 26152] během dvou [týdnů][review club +26152-2]. + +{% include functions/details-list.md + q0="Jaký problém tento PR řeší?" + a0="Odhad poplatku peněženkou nebere v potaz potřebu platit také všechny nepotvrzené + rodičovské transakce, které mají nastavený nižší poplatek, než je cílový." + a0link="https://bitcoincore.reviews/26152#l-30" + + q1="Z čeho se skládá cluster transakce?" + a1="Množina transakcí obsahuje samotnou transakci a všechny „připojené” + transakce. Zahrnují všechny předky i potomky, ale též sourozence a + sestřenice, tedy potomky rodičů, kteří nemusí být ani předky, ani potomky + dané transakce." + a1link="https://bitcoincore.reviews/26152#l-72" + + q2="Tento PR přináší `MiniMiner`, který duplikuje některé algoritmy + skutečné těžby. Nebylo by lepší spojit tyto dvě implementace?" + a2="Potřebujeme pracovat pouze s clusterem, nikoliv s kompletním mempoolem. + Též nepotřebujeme provádět žádné kontroly jako `BlockAssembler`. + Někdo dokonce navrhl učinit všechny výpočty bez zámku mempoolu. + Museli bychom také změnit block assembler, aby spíše sledoval navýšení + poplatků než konstrukci šablony bloku. Množství práce potřebné pro + refaktorování by bylo stejné jako přepsání." + a2link="https://bitcoincore.reviews/26152#l-94" + + q3="Proč vyžaduje `MiniMiner` kompletní cluster? Nestačil by jen výčet + všech předků každé transakce?" + a3="Někteří předci mohou mít již poplatek navýšený jiným potomkem, a není + tedy třeba dalšího navyšování. Proto potřebujeme ve výpočtech zahrnout + i tyto potomky." + a3link="https://bitcoincore.reviews/26152#l-129" + + q4="Má-li transakce X vyšší jednotkový poplatek předků než nezávislá transakce + Y, je možné, že by těžař upřednostnil Y před X (tj. zařadil Y do bloku dříve + než X)?" + a4="Ano. Má-li některý z předků transakce Y, které mají nízké poplatky, i jiné potomky + s vysokým poplatkem, Y za předky platit nemusí. Množina předků transakce Y + je aktualizována, aby byly vyloučeny transakce, které v důsledku navyšují poplatky + předků transakce Y." + a4link="https://bitcoincore.reviews/26152#l-169" + + q5="`CalculateBumpFees()` může nadhodnotit, podhodnotit, obé či ani jedno? O kolik?" + a5="K nadhodnocení dojde, jsou-li vybrány dva výstupy s překrývajícími se předky, + neboť každé navýšení bere v potaz své předky nezávisle a neuvažuje se možnost + společných předků. Účastníci došli k závěru, že podhodnocení navýšení poplatků + možné není." + a5link="https://bitcoincore.reviews/26152#l-194" + + q6="`MiniMiner`obdrží seznam UTXO (výstupů), které by peněženka chtěla utratit. + Jakých pěti možných stavů může daný výstup nabývat?" + a6="Může být (1) potvrzený a neutracený, (2) potvrzený a právě utrácený existující + transakcí v mempoolu, (3) nepotvrzený (v mempoolu) a neutracený, (4) nepotvrzený, + ale již utracený existující transakcí v mempoolu nebo (5) to může být výstup, + o kterém jsme nikdy neslyšeli." + a6link="https://bitcoincore.reviews/26152-2#l-21" + + q7="Jaký přístup zaujímá commit \"Navyš poplatky nepotvrzených rodičů na úroveň cílového + poplatku\"?" + a7="Tento commit je hlavní změnou chování tohoto PR. `MiniMiner` provádí výpočet navýšení + poplatků (tak, aby příslušní předci nabyli cílového jednotkového poplatku) každého + UTXO a odečítá je od jejich efektivní hodnoty. Poté následuje běžný výběr mincí." + a7link="https://bitcoincore.reviews/26152-2#l-100" + + q8="Jak tento PR řeší utrácení nepotvrzených UTXO s překrývajícími se předky?" + a8="Po výběru mincí spustíme nad jeho výsledkem variantu algoritmu `MiniMiner`u. + Tím obdržíme přesnou hodnotu navýšení poplatku. Pokud je kvůli společným + předkům navýšení příliš velké, můžeme poplatek snížit navýšením zbytku + po platbě (pokud existuje) nebo přidáním zbytku (pokud neexistuje)." + a8link="https://bitcoincore.reviews/26152-2#l-111" +%} + +## 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.* + +- [BTCPay Server 1.7.1][] je nejnovějším vydáním nejrozšířenějšího serveru + pro zpracování bitcoinových plateb. + +- [Core Lightning 22.11][] je příští hlavní verzí CLN. Je také první verzí, + která bude používat nový systém číslování verzí.[^semver] Součástí vydání + je několik nových funkcí včetně nového správce rozšíření a opravy několika + chyb. + +- [LND 0.15.5-beta][] je údržbové vydání LND. Dle poznámek k vydání obsahuje + pouze opravy drobných chyb. + +- [BDK 0.25.0][] je novým vydáním této knihovny pro tvorbu peněženek. + +## Významné změny v kódu a dokumentaci + +*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] a [Lightning BOLTs][bolts repo].* + +- [Bitcoin Core #19762][] upravuje rozhraní RPC (a potažmo i `bitcoin-cli`) + přidáním možnosti použít poziční i jmenné argumenty dohromady. Tato + změna usnadňuje použití jmenných parametrů bez nutnosti jmenovat je + všechny. + +- [Core Lightning #5722][] přidává [dokumentaci][grpc doc] o používání rozšíření + GRPC rozhraní. + +- [Eclair #2513][] upravuje způsob používání peněženek Bitcoin Core, + aby zajistil, že vždy používají [bech32][topic bech32] adresy. Je to + důsledkem změny [Bitcoin Core #23789][] (viz [zpravodaj č. 181][news181 + bcc23789], *angl.*), ve které byl adresovány obavy o ztrátu soukromí + uživateli nových typů výstupů (např. [taproot][topic taproot]). Nastavil-li + uživatel v předchozích verzích ve své peněžence taproot jako výchozí typ + adresy, byly automaticky nastaveny na taproot také adresy pro zaslání zbytku + po platbě („drobné”). Poslal-li platbu někomu, kdo taproot nepoužíval, + mohly třetí strany snadno odhadnout, který výstup byla platba (netaproot) + a co byly drobné (taproot). Po zmíněné změně se Bitcoin Core snaží použít + pro zbytek stejný druh výstupu jako pro platbu. Zbytek po platbě na nativní + segwit adresu by tak byl poslán též na nativní segwit výstup. + + LN protokol však vyžaduje určité druhy výstupů. Například P2PKH výstup nemůže + být použit na otevření LN kanálu. Z tohoto důvodu musí uživatelé Eclair s + Bitcoin Core zajistit, aby negenerovali adresy pro zaslání zbytku nekompatibilní + s LN. + +- [Rust Bitcoin #1415][] začíná používat [Kani Rust Verifier][], který umožní + dokázat některé vlastnosti kódu. Doplňuje tak další testy prováděné v rámci + průběžné integrace, jako je např. fuzzing. + +- [BTCPay Server #4238][] přidává možnost refundovat fakturu pomocí Greenfield API, + což je novější API odlišné od původního API inspirovaného BitPayem. + +## Poznámky + +[^semver]: + Předchozí vydání našeho zpravodaje tvrdila, že Core Lightning používá + [sémantické verzování][semantic versioning] a že nové verze jej budou + používat i nadále. Rusty Russell [vysvětlil][rusty semver], proč se nemůže + CLN zcela držet tohoto systému. Děkujeme Mattovi Whitlockovi za upozornění + na naši chybu. + +{% include references.md %} +{% include linkers/issues.md v=2 issues="19762,5722,2513,1415,4238,18725,26403,23789" %} +[lnd 0.15.5-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.15.5-beta +[core lightning 22.11]: https://github.com/ElementsProject/lightning/releases/tag/v22.11 +[btcpay server 1.7.1]: https://github.com/btcpayserver/btcpayserver/releases/tag/v1.7.1 +[bdk 0.25.0]: https://github.com/bitcoindevkit/bdk/releases/tag/v0.25.0 +[semantic versioning]: https://semver.org/lang/cs/spec/v2.0.0.html +[grpc doc]: https://github.com/cdecker/lightning/blob/20bc743840bf5d948efbf62d32a21a00ed233e31/plugins/grpc-plugin/README.md +[news181 bcc23789]: /en/newsletters/2022/01/05/#bitcoin-core-23789 +[kani rust verifier]: https://github.com/model-checking/kani +[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://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 new file mode 100644 index 0000000000..123160d328 --- /dev/null +++ b/_posts/cs/newsletters/2022-12-14-newsletter.md @@ -0,0 +1,315 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 230' +permalink: /cs/newsletters/2022/12/14/ +name: 2022-12-14-newsletter-cs +slug: 2022-12-14-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme souhrn návrhu na změnu protokolu LN, která může +zlepšit kompatibilitu s továrnami kanálů, popisujeme program na zamezení +některých důsledků útoků zahlcení kanálu bez nutnosti měnit LN protokol +a nabízíme odkaz na webovou stránku monitorující nahrazené transakce +bez signalizace. Též nechybí naše pravidelné rubriky s oznámeními o vydání +software, souhrnem oblíbených otázek a odpovědí Bitcoin Stack Exchange a +popisem významných změn populárních páteřních bitcoinových projektů. + +## Novinky + +- **Návrh na LN protokol pro továrny:** John Law [zaslal][law factory] + do emailové skupiny Lightning-Dev popis protokolu optimalizovaného + na vytváření [továren kanálů][topic channel factories] („channel + factory”). Továrny kanálů umožňují více uživatelům mezi sebou otevřít + (bez nutnosti navzájem si důvěřovat) množství kanálů v rámci + jediné transakce. Například 20 uživatelů může dohromady vytvořit + jedinou transakci, která sice bude desektrát větší než obvyklá otevírací + transakce, ale která otevře dohromady 190 kanálů. + + 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. + +- **Lokální zahlcení k zamezení vzdáleného zahlcení:** Joost Jager + [zaslal][jager jam] do emailové skupiny Lightning-Dev odkaz a vysvětlení + svého projektu [CircuitBreaker][]. Tento program, navržený tak, aby byl + kompatibilní s LND, hlídá maximální počet nevyřízených plateb ([HTLC][topic + htlc]), které uzel přeposílá jménem svých spojení. Uvažme například + nejhorší možných scénář útoku zahlcením HTLC: + + ![Ilustrace dvou různých utoků zahlcením](/img/posts/2020-12-ln-jamming-attacks.png) + + V současném LN protokolu má Alice principiální omezení [483 nevyřízených HTLC][483 + pending htlcs], které může současně přeposílat. Pokud by však používala + CircuitBreaker k omezení kanálu s Mallorym na 10 současných nevyřízených HTLC, + její kanál s Bobem (není na obrázku) a všechny další kanály v tomto okruhu + by byly chráněny před všemi kromě prvních deseti HTLC, které Mallory udržuje + v nevyřízeném stavu. To by významně snížilo efektivitu Malloryho útoku, + protože by to po něm vyžadovalo otevření mnohem většího počtu kanálů (a tedy + zvýšení nákladů), aby zasáhl stejný počet HTLC slotů. + + I když byl původně CircuitBreaker navržen tak, aby jednoduše odmítl + přijmout HTLC nad rámec svého omezení, Jager poznamenal, že nedávno + přidal volitelnou možnost přidání jakéhokoliv HTLC do fronty namísto + okamžitého odmítnutí nebo přeposlání. Jakmile spadne počet nevyřízených + HTLC v kanálu pod jeho limit, CircuitBreaker přepošle nejstarší + 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. + +- **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] + monitoring nahrazených transakcí bez signalizace BIP125 v mempoolu jeho uzlu. + Jeho uzel umožňuje full-RBF nahrazování pomocí konfigurační volby `mempoolfullrbf` + (viz [zpravodaj č. 208][news208 rbf], *angl.*). + + Uživatelé a služby mohou používat stránku jako indikátor, nakolik + velcí těžaři potvrzují nahrazené transakce bez signalizace. Připomínáme + však čtenářům, že nepotvrzené transakce jsou zcela bez záruky, i když + těžaři, zdá se, zatím nahrazené transakce bez signalizace netěží. + +## 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.* + +- **Lily Wallet přidává výběr mincí:** + Lily Wallet [v1.2.0][lily v1.2.0] přidává algoritmy [výběru mincí][topic coin selection]. + +- **Vortex vytváří LN kanály z coinjoinu:** + Uživatelé [Vortexu][vortex github] [otevřeli LN kanály][vortex tweet] na bitcoinovém mainnetu + za pomoci [taprootu][topic taproot] a [coinjoinových][topic coinjoin] transakcí. + +- **Mutiny předvádí možnost LN uzlu v prohlížeči:** + Vývojáři [předvedli][mutiny tweet] [ukázku][mutiny github] implementace LN uzlu + běžícího v mobilním prohlížeči pomocí WASM a LDK. + +- **Coinkite spouští BinaryWatch.org:** + Webová stránka [BinaryWatch.org][] ověřuje binárky bitcoinových projektů a + monitoruje jejich změny. Společnost též provozuje [bitcoinbinary.org][], službu, + která archivuje [reprodukovatelná sestavení][topic reproducible builds] bitcoinových + projektů. + +## 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/" %} + +- [Proč je připojení k bitcoinové síti výhradně přes Tor považováno za špatnou praxi?]({{bse}}116146) + Několik odpovědí vysvětluje, že kvůli nižším nákladům na vytváření Tor adres v porovnání + s IPv4 nebo IPv6 adresami může být uzel používající pouze Tor snadněji vystaven + [eclipse útokům][topic eclipse attacks] než uzel vystavený pouze clearnetu nebo kombinaci + [anonymizačních sítí][topic anonymity networks]. + +- [Proč dnes nejsou realisticky možné LN kanály s třemi či více účastníky?]({{bse}}116257) + Murch vysvětluje, že jelikož LN kanály v současnosti používají systém penalizací, + který v případě nedodržení pravidel pošle *všechny* prostředky poškozené straně, + bylo by příliš komplikované rozšířit tento systém trestů na více účastníků. Také + objasňuje fungování [eltoo][topic eltoo] a jeho možnost nakládání s kanály s více + účastníky. + +- [Bude Bitcoin Core moci podepisovat zprávy i se zastaralými peněženkami?]({{bse}}116187) + Pieter Wuille rozlišuje mezi [odstraněním zastaralých peněženek][news125 legacy + descriptor wallets] v Bitcoin Core a pokračující podporou pro starší typy adres + jako P2PKH i v nových peněženkách založených na [deskriptorech][topic descriptors]. + I když je v současnosti podepisování zpráv možné pouze pro P2PKH adresy, práce na + [BIP322][topic generic signmessage] by měla umožnit podepisování i jinými typy adres. + +- [Jak nastavím multisig s časovým úpadkem?]({{bse}}116035) + Uživatel Yoda se ptá, jak lze nastavit vícenásobný podpis s časovým úpadkem, tedy + UTXO, které je během času utratitelné s nižším počtem podpisů. Michael Folkson + poskytuje příklad s použitím [pravidel][news74 policy miniscript] a [miniscriptu][topic + miniscript], odkazuje na relevantní zdroje a upozorňuje na chybějící jednoduché + nástroje. + +- [Kdy je miniscriptové řešení poddajné?]({{bse}}116275) + Antoine Poinsot definuje, co poddajnost („malleability”) znamená v kontextu + miniscriptu, popisuje statickou analýzu poddajnosti v miniscriptu a prochází + krok za krokem příkladem z původní otázky. + +## 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 24.0.1][] je hlavním vydáním nejpoužívanější implementace + plného uzlu. Přináší volbu pro konfiguraci RBF ([Replace-By-Fee][topic rbf]) + pravidel uzlu, nové RPC volání `sendall` pro snadné utracení všech prostředků + v peněžence v jediné transakci (nebo pro vytváření transakcí bez zbytku), + volání `simulaterawtransaction`, které ověří efekty transakce na peněženku (např. + se lze ujistit, že coinjoinová transakce pouze sníží celkovou hodnotu peněženky + o poplatky), možnost vytvářet [deskriptory][topic descriptors] pouze pro sledování, + které obsahují [miniscriptové][topic miniscript] výrazy s vylepšenou kompatibilitou + s jiným software, a automatickou aplikaci změn některých nastavení RPC volání + provedených v GUI. Viz [poznámky k vydání][bcc rn] s úplným výčtem novinek a oprav + chyb. + + Poznámka: verze 24.0 byla označena a binárky byly vydané, avšak správci projektu + nikdy tuto verzi neoznámili. Namísto toho pracovali s ostatními přispěvateli + na řešení [nenadálých chyb][bcc milestone 24.0.1]. Verze 24.0.1 tak byla první + oznámenou verzí větve 24.x. + +- [libsecp256k1 0.2.0][] je prvním tagovaným vydáním této široce používané + knihovny pro bitcoinové kryptografické operace. [Oznámení][libsecp256k1 + announce] o vydání uvádí: „Po dlouhou dobu probíhal vývoj libsecp256k1 + pouze v master větvi, což vytvářelo nejistotu ohledně kompatibility API + a stability. Od této doby budeme vytvářet tagovaná vydání po vzoru sémantického + verzování, kdykoliv budou začleněna relevantní zlepšení. […] Přeskakujeme + verzi 0.1.0, protože toto číslo bylo po léta nastaveno v našich skriptech + a nepoukazuje na žádnou jedinečnou množinu zdrojových kódů. Nebudeme vytvářet + binární vydání, ale budeme v poznámkách o vydání a číslech verzí zohledňovat + očekávané problémy s kompatibilitou ABI.” + +- [Core Lightning 22.11.1][] je menší vydání, které dle požadavku vývojářů dočasně + vrací některé funkce odstraněné ve verzi 22.11. + +## Významné změny v kódu a dokumentaci + +*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] a [Lightning BOLTs][bolts repo].* + +- [Bitcoin Core #25934][] přidává do RPC volání `listsinceblock` volitelný argument `label`. + Je-li specifikován, volání vrátí pouze transakce odpovídající tomuto štítku. + +- [LND #7159][] upravuje RPC volání `ListInvoiceRequest` a `ListPaymentsRequest` přidáním + parametrů `creation_date_start` a `creation_date_end`, které umožňují filtrovat faktury + a platby podle data a času. + +- [LDK #1835][] přidává zachyceným HTLC jmenný prostor falešných krátkých identifikátorů + kanálu („short channel identifier”, SCID), což umožní poskytovatelům lightningových služeb + („lightning service providers”, LSP) vytvářet koncovým uživatelům [just-in-time][topic jit + routing] (JIT) kanály pro přijímání lightningových plateb. To lze učinit přidáním falešných + doporučených tras do faktury, které LDK rozpozná podobně jako [phantom platby][LDK phantom + payments] (viz [zpravodaj č.188][news188 phantom], *angl.*). LDK poté generuje událost, + která dává LSP možnost otevřít JIT kanál. LSP potom může přeposlat platbu přes právě otevřený + kanál či ji stornovat. + +- [BOLTs #1021][] umožňuje chybovým zprávám routování připojit [TLV][] stream, který + může v budoucích verzích obsahovat dodatečné informace o chybě. Jedná se o první + krok v cestě za [detailními chybovými hláškami][news224 fat] podle návrhu [BOLTs #1044][]. + +## Krásné svátky! + +Toto je letošní poslední pravidelné číslo našeho zpravodaje. Ve středu 21. +prosince uveřejníme páté vydání roku ve zkratce. Pravidelná vydání +budou pokračovat ve středu 4. ledna. + +{% include references.md %} +{% include linkers/issues.md v=2 issues="25934,7159,1835,1021,1044" %} +[bitcoin core 24.0.1]: https://bitcoincore.org/bin/bitcoin-core-24.0.1/ +[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://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://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://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://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 +[483 pending htlcs]: https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#rationale-7 +[news188 phantom]: /en/newsletters/2022/02/23/#ldk-1199 +[LDK phantom payments]: https://lightningdevkit.org/blog/introducing-phantom-node-payments/ +[news125 legacy descriptor wallets]: /en/newsletters/2020/11/25/#how-will-the-migration-tool-from-a-bitcoin-core-legacy-wallet-to-a-descriptor-wallet-work +[news74 policy miniscript]: /en/newsletters/2019/11/27/#what-is-the-difference-between-bitcoin-policy-language-and-miniscript +[lily v1.2.0]: https://github.com/Lily-Technologies/lily-wallet/releases/tag/v1.2.0 +[vortex tweet]: https://twitter.com/benthecarman/status/1590886577940889600 +[vortex github]: https://github.com/ln-vortex/ln-vortex +[mutiny tweet]: https://twitter.com/benthecarman/status/1595395624010190850 +[mutiny github]: https://github.com/BitcoinDevShop/mutiny-web-poc +[BinaryWatch.org]: https://binarywatch.org/ +[bitcoinbinary.org]: https://bitcoinbinary.org/ diff --git a/_posts/cs/newsletters/2023-01-04-newsletter.md b/_posts/cs/newsletters/2023-01-04-newsletter.md new file mode 100644 index 0000000000..5940087492 --- /dev/null +++ b/_posts/cs/newsletters/2023-01-04-newsletter.md @@ -0,0 +1,189 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 232' +permalink: /cs/newsletters/2023/01/04/ +name: 2023-01-04-newsletter-cs +slug: 2023-01-04-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme varování o kompromitaci podepisovacích klíčů Bitcoin Knots, +oznámení o vydání dvou softwarových forků Bitcoin Core a souhrn pokračující diskuze +o pravidlech nahrazování transakcí. Též nechybí naše pravidelné rubriky s oznámeními +o softwarových vydáních a popisem významných změn populárního bitcoinového páteřního +software. + +## Novinky + +- **Klíče podepisující Bitcoin Knots kompromitovány:** vývojář implementace + plného uzlu Bitcoin Knots oznámil, že PGP klíč, který používá k podepisování + vydání Knots, byl kompromitován. Dále řekl: „Nestahujte Bitcoin Knots a + nedůvěřujte mu, dokud se to nevyřeší. Pokud jste tak již v minulých několika + měsících učinili, zvažte dočasné vypnutí.” Jiné implementace plného uzlu + nejsou poznamenány. + +- **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]. + +- **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. + +## 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.* + +- [Eclair 0.8.0][] je hlavním vydáním této oblíbené implementace LN uzlu. + Přidává podporu pro [zero-conf kanály][topic zero-conf channels] a aliasy + pro krátké identifikátory kanálu (SCID). Pro více informací o těchto + funkcích a dalších změnách viz [poznámky k vydání][eclair 0.8 rn]. + +- [LDK 0.0.113][] je novou verzí této knihovny pro tvorbu peněženek a aplikací + s Lightning Network. + +- [BDK 0.26.0-rc.2][] je kandidátem na vydání této knihovny pro tvorbu peněženek. + +## Významné změny v kódu a dokumentaci + +*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] a [Lightning BOLTs][bolts repo].* + +- [Bitcoin Core #26265][] snižuje požadavky na minimální povolenou velikost + serializované transakce bez witnessů v rámci pravidel přeposílání transakcí + z 82 bytů na 65 bytů. Například transakce s jedním vstupem a jedním výstupem + se 4 byty OP_RETURN, která byla v předchozích verzích odmítáná z důvodu + příliš malé velikosti, by nyní byla do mempoolu přijata a přeposílána dále. + Pro informace o pozadí a motivaci viz [zpravodaj č. 222][min relay size ml] + (*angl.*). + +- [Bitcoin Core #21576][] umožňuje peněženkám používajícím externí podpisová zařízení + navýšit poplatek pomocí [RBF][topic rbf], a to v GUI i RPC volání `bumpfee`. + +- [Bitcoin Core #24865][] umožňuje, aby byla peněženka obnovena ze zálohy + též na ořezaných uzlech. Je však nutné, aby byly k dispozici bloky + vzniklé po vytvoření peneženky. Bloky jsou potřebné při hledání všech + transakcí, které mají vliv na stav peněženky. Záloha peněženky vytvořená + z Bitcoin Core obsahuje datum vytvoření peněženky. + +- [Bitcoin Core #23319][] přidavá do odpovědi RPC volání `getrawtransaction` + dodatečné informace, je-li parametr `verbose` nastaven na `2`. Tyto + nové informace obsahují poplatek za transakci a detaily o každém z + předchozích výstupů, které jsou utráceny v této transakci. Pro podrobnosti + o metodě získání těchto informací viz [zpravodaj č. 172][news172 prevout] + (*angl.*). + +- [Bitcoin Core #26628][] odmítne RPC požadavky, obsahují-li opakovaný název + parametru. Dříve byl v takovém případě uvažován pouze poslední z opakovaných + parametrů, např. z `{"foo"="bar", "foo"="baz"}` byl použit pouze `{"foo"="baz"}`. + Takový požadavek bude nově odmítnut a bude vrácena chybová hláška. `bitcoin-cli` + používání opakovaných paramterů nemění; požadavek odmítnut nebude, avšak bude + odeslán pouze poslední výskyt opakovaného parametru. + +- [Eclair #2464][] přidává možnost spustit událost, jakmile je spojení uzlu + připravené přijímat platby. To je obzvláště užitečné v případě [asynchronních + plateb][topic async payments], kdy uzel dočasně zadržuje platbu pro vzdálené + spojení, čeká, až se připojí, a pak platbu doručí. + +- [Eclair #2482][] umožňuje posílání platby pomocí [zaslepených tras][topic + rv routing], což jsou cesty, jejichž několik posledních uzlů je + zvoleno příjemcem. Příjemce zakryje informace o uzlech pomocí onion šifrování + a pošle tato zašifrovaná data plátci spolu s identitou prvního uzlu + zaslepené trasy. Plátce poté vytvoří cestu k tomuto prvnímu uzlu a + připojí zašifrované údaje pro operátory posledních několika uzlů. + Tento způsob umožňuje příjemci obdržet platbu, aniž by odhalil identitu + svého uzlu nebo kanálů vedoucích k plátci, čímž zvušuje své soukromí. + +- [LND #2208][] počíná volit odlišné cesty podle poměru kapacity + kanálu a částky platby. S částkou blížící se kapacitě kanálu klesá + pravděpodobnost zařažení kanálu do cesty. Tento přístup je podobný + hledání cesty v Core Lightning a LDK. + +- [LDK #1738][] a [#1908][ldk #1908] přidávají nové funkce pro nakládání s + [nabídkami][topic offers]. + +- [Rust Bitcoin #1467][] přidává vstupům a výstupům metody pro výpočet + velikosti ve [váhových jednotkách][weight units]. + +- [Rust Bitcoin #1330][] odstraňuje datový typ `PackedLockTime`, jehož + náhradou je téměř shodný typ `absolute::LockTime`. Rozdíl mezi těmito + dvěma typy, který může mít vliv na použití, je, že `PackedLockTime` + poskytoval implementaci traitu `Ord`, avšak `absolute::LockTime` ji + neposkytuje. Locktime však bude i tak při řazení transakcí brán do úvahy. + +- [BTCPay Server #4411][] aktualizuje verzi závislosti Core Lightning na + 22.11 (viz [zpravodaj č. 229][news229 cln]). Uživatelé, kteří chtějí + do [BOLT11][] faktury zahrnout hash popisky objednávky, již nemusí k tomuto + účelu používat plugin `invoiceWithDescriptionHash`, ale postačí nastavit + pole `description` a volbu `descriptionHashOnly`. + +{% include references.md %} +{% 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://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://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 +[eclair 0.8 rn]: https://github.com/ACINQ/eclair/blob/master/docs/release-notes/eclair-v0.8.0.md +[ldk 0.0.113]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.0.113 +[bdk 0.26.0-rc.2]: https://github.com/bitcoindevkit/bdk/releases/tag/v0.26.0-rc.2 +[min relay size ml]: /en/newsletters/2022/10/19/#minimum-relayable-transaction-size diff --git a/_posts/cs/newsletters/2023-01-11-newsletter.md b/_posts/cs/newsletters/2023-01-11-newsletter.md new file mode 100644 index 0000000000..15d359f62f --- /dev/null +++ b/_posts/cs/newsletters/2023-01-11-newsletter.md @@ -0,0 +1,127 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 233' +permalink: /cs/newsletters/2023/01/11/ +name: 2023-01-11-newsletter-cs +slug: 2023-01-11-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme popis nápadu umožňujícího offline LN uzlům přijímat +platby na blockchainu, které mohou později být použity i v LN bez dalšího +zdržení. Nechybí také naše pravidelné rubriky se souhrnem nových +softwarových vydání a popisem významných změn v populárních bitcoinových +páteřních projektech. + +## Novinky + +- **Neinteraktivní otvírání LN kanálů:** vývojáři ZmnSCPxj + a Jesse Posner [zaslali][zp potentiam] do emailové skupiny Lightning-Dev + návrh na nový způsob otvírání LN kanálů, který nazývají *swap-in-potentiam*. + Existující metody vyžadují, aby každý z účastníků + podepsal refundační transakci ještě před tím, než jsou do kanálu vloženy + jakékoliv prostředky. Tyto metody vyžadují interakci, neboť pro + vytvoření refundace musí být známy detaily o vkládaných prostředcích: + strana, která kanál otvírá, musí protistraně sdělit, jaké prostředky + se chystá poskytnout; protistrana musí vytvořit a podepsat refundační + transakci; poté musí otvírající strana podepsat a odeslat otvírací + transakci. + + Autoři upozorňují, že tento způsob je pro některé peněženky problematický, + obzvlástě pro mobilní peněženky, které mohou být offline nebo nemusí být + schopny fungovat nepřetržitě. Bylo by rozumné, aby takové peněženky + vygenerovaly záložní adresu na blockchainu, kam by mohly být prostředky + zaslány v případě nedostupného LN uzlu. Při následném připojení by mohla + peněžka použít tyto prostředky na blockchainu k otevření LN kanálu. + Avšak nové LN kanály potřebují získat dostatečné množství konfirmací + (např. šest), aby mohla protistrana bezpečně přeposílat platby + otvírajícímu uzlu. Znamená to, že by uživatel mobilní peněženky, který + v offline stavu obdrží platbu, musel po připojení čekat šest bloků, + než by mohl použít tyto prostředky k posílání nových plateb přes LN. + + Autoři navrhují jinou možnost: uživatelka Alice si předem vybere + takovou protistranu (Bob), jejíž uzel by měl být stále dostupný + (např. poskytovatel lightningových služeb, LSP). Alice a Bob spolu + vytvoří adresu na blockchainu pro skript, který umožní utrácení + 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)) + ``` + + 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 + podepsat každý pokus o utracení. Rozhodne-li se Bob podepsat jen jeden + pokus o utracení, který Alice též podepíše, může si Bob být jist, + že Alice nemůže prostředky před expirací podruhé utratit (a tím platbu + zneplatnit). Jediným způsobem zneplatnění Aliciny platby by bylo + zneplatnění předchozí platby Alici. Obdrží-li platba dostatečné + množství konfirmací před tím, než se Alice připojí online a zahájí + utrácení, dvojí utracení by mělo být nepravděpodobné. + + Toto schéma umožňuje Alici obdržet platbu, zatímco je její peněženka offline, + připojit se po získání nejméně šest konfirmací (ale výrazně + méně než 6 000) a okamžitě se podílet na otevření LN kanálu podepsáním + transakce, o které Bob ví, že nemůže být podruhé utracena. Bob může bezpečně + přeposílat Alici platby ještě před tím, než je otvírací transakce + potvrzena. Nebo mají-li Alice i Bob již své LN kanály (spolu či s jinými + uzly), může Bob poslat Alici LN platbu, kterou může Alice uplatnit utracením + svých onchain postředků Bobovi. Alicina peněženka se také může po připojení + rozhodnout odeslat platbu běžným způsobem na blockchainu. V takovém případě musí + Alice jen požádat Bobovu peněženku o podepsání. V nejhorším případě, pokud by Bob + nespolupracoval, musela by Alice počkat pár týdnů. + + Vedle možnosti přijímat LN platby offline popisují dále autoři, jak by tato + myšlenka mohla dobře fungovat s [asynchronními platbami][topic async payments]. + LSP by mohly dopředu připravit rebalancování, které by se provedlo bez + jakéhokoliv zdržení (z pohledu uživatele) v okamžiku připojení se + offline klienta k síti. Například kdyby Carol poslala asynchronní LN + platbu Alici s částkou převyšující kapacitu Alicina kanálu, mohl by Bob + poslat platbu skriptu `pk(B) && (pk(A) || older(6000))`. Tato alternativní + verze skriptu převrací role Alice a Boba. Obdrží-li Bobova platba + dostatečné množství konfirmací před následujícím připojením Aliciny + peněženky, může Alice okamžitě povýšit tuto platbu na nový LN kanál + a požádat Bob o přesměrování asynchronní platby přes tento nový kanál. + Obvyklé garance týkající se bezpečnosti a důvěry v LN zůstavají + zachovány. + + V době psaní tohoto zpravodaje obdržel návrh střední množství reakcí. + Několik žádalo vysvětlení různých hledisek tohoto nápadu a přinejmenším + jeden [příspěvek][fournier potentiam] vyjádřil konceptu silnou podporu. + +## 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.* + +- [BDK 0.26.0][] je novým vydáním této knihovny pro tvorbu peněženek. + +- [HWI 2.2.0-rc1][] je kandidátem na vydání této aplikace umožňující + softwarovým peněženkám přístup k podpisovým hardwarovým zařízením. + + +## Významné změny v kódu a dokumentaci + +*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] a [Lightning BOLTs][bolts repo].* + +- [Eclair #2455][] implementuje podporu pro volitelný TLV stream + („Type-Length-Value“ čili „typ-délka-hodnota”) v onionových + chybových zprávách [nedávno představených][bolts #1021] v BOLT #4. + TLV stream umožňuje uzlům přidat dodatečné informace o selháních + trasování a může být použit i pro navrhovaný systém [fat errors][news224 + fat], který odstraní další nedostatky v přisuzování chyb. + +{% include references.md %} +{% 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://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://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 new file mode 100644 index 0000000000..250f1dae53 --- /dev/null +++ b/_posts/cs/newsletters/2023-01-18-newsletter.md @@ -0,0 +1,203 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 234' +permalink: /cs/newsletters/2023/01/18/ +name: 2023-01-18-newsletter-cs +slug: 2023-01-18-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden popisujeme návrh na nové opkódy související s úschovnami +a přinášíme naše pravidelné rubriky se souhrnem zajímavých změn +v klientech a službách, oznámeními o nových vydáních a kandidátech +na vydání a popisem významných změn oblíbeného bitcoinového +páteřního software. + +## Novinky + +- **Návrh na nové opkódy pro úschovny:** James O'Beirne [zaslal][obeirne + 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. + +## 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.* + +- **Kraken oznamuje posílání na taprootové adresy:** + V nedávném [blogovém příspěvku][kraken bech32m] oznámil Kraken podporu + pro zasílání prostředků na [bech32m][topic bech32] adresy. + +- **Ohlášena rustová klientská knihovna pro Whirlpool coinjoin:** + [Samourai Whirlpool Client][whirlpool rust client] je rustová knihovna + pro nakládání s Whirlpool [coinjoinem][topic coinjoin]. + +- **Podpora miniscriptu v Ledgeru:** + Jak bylo dříve [ohlášeno][ledger miniscript], bitcoinovým firmwarem + v2.1.0 přináší Ledger podporu [miniscriptu][topic miniscript] pro svá + zařízení. + +- **Vydána peněženka Liana:** + Byla [ohlášena][liana blog] první verze peněženky Liana. Podporuje peněženky + s jednoduchým podpisem a klíčem pro obnovu s [časovým zámkem][topic timelocks]. + Mezi plány do budoucna patří podpora [taprootu][topic taproot], multisig + peněženky a multisig s časovým úpadkem. + +- **Vydán Electrum 4.3.3:** + [Electrum 4.3.3][electrum 4.3.3] obsahuje vylepšení Lightningu, [PSBT][topic + psbt], podpory podpisových zařízení a sestavovacího systému. + +## 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 2.2.0][] je vydáním této aplikace umožňující softwarovým peněženkám + přístup k hardwarovým podpisovým zařízením. Přináší opravy chyb a mimo jiné + novinky přidává podporu pro [P2TR][topic taproot] platby klíčem podpisovým + zařízením BitBox02. + +## Významné změny v kódu a dokumentaci + +*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] a [Lightning BOLTs][bolts repo].* + +- [Core Lightning #5751][] zavrhuje podporu pro tvorbu nových segwitových P2SH adres. + +- [BIPs #1378][] přidává [BIP324][] pro [P2P protokol verze 2][topic v2 p2p transport]. + +{% 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://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021318.html +[obeirne paper]: https://jameso.be/vaults.pdf +[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://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/ +[liana blog]: https://wizardsardine.com/blog/liana-announcement/ +[electrum 4.3.3]: https://github.com/spesmilo/electrum/blob/4.3.3/RELEASE-NOTES diff --git a/_posts/cs/newsletters/2023-01-25-newsletter.md b/_posts/cs/newsletters/2023-01-25-newsletter.md new file mode 100644 index 0000000000..10a4ce65a6 --- /dev/null +++ b/_posts/cs/newsletters/2023-01-25-newsletter.md @@ -0,0 +1,161 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 235' +permalink: /cs/newsletters/2023/01/25/ +name: 2023-01-25-newsletter-cs +slug: 2023-01-25-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme souhrn analýzy porovnávající návrh dočasných +anchor výstupů a `SIGHASH_GROUP` a přeposíláme požadavek na výzkum +možností vytváření důkazu úspěchu asynchronní LN platby. Nechybí také +naše pravidelné rubriky se souhrnem zajímavých otázek a odpovědí +z Bitcoin Stack Exchange a popisem významných změn oblíbených +páteřních bitcoinových projektů. + +## Novinky + +- **Dočasné anchor výstupy v porovnání s `SIGHASH_GROUP`:** Anthony Towns + [zaslal][towns e-vs-shg] do emailové skupiny Bitcoin-Dev analýzu porovnávající + nedávný návrh na [dočasné anchor výstupy][topic ephemeral anchors] se + starším návrhem na [`SIGHASH_GROUP`][`SIGHASH_GROUP` proposal]. + `SIGHASH_GROUP` umožňuje vstupům určit, které výstupy autorizují. Každý vstup + může autorizovat jinou skupinu výstupů, které se ale nesmí prolínat. Obzvláště + užitečné je to v případě navýšení poplatků u protokolů, kde dva a více + vstupů jsou použity s dopředu podepsanou transakcí. Z této vlastnosti + vyplývá, že poplatky mohou být navýšeny v době, kdy je známa aktuální + výše. Existující `SIGHASH_ANYONECANPAY` a `SIGHASH_SINGLE` nejsou dostatečně + flexibilní, protože se týkají pouze jediného vstupu či výstupu. + + Dočasné anchor výstupy, které jsou podobné [sponzorství poplatků][topic fee + sponsorship], umožňují komukoliv navýšit poplatky pomocí [CPFP][topic cpfp]. + Transakce, jejíž poplatky jsou navyšovány, může obsahovat nulové poplatky. + Protože může kdokoliv navýšit poplatek pomocí dočasných anchor výstupů, + může být tento mechanismus použit také k platbě poplatků předem + podepsané transakce s více vstupy, což řeší právě `SIGHASH_GROUP`. + + `SIGHASH_GROUP` by i nadále nabízel dvě výhody: zaprvé, umožňoval by + [dávkové zpracování][topic payment batching] vícero nesouvisejících + předem podepsaných transakcí, což by mohlo snížit velikost transakce a + náklady a zvýšit kapacitu sítě. Zadruhé nevyžaduje, aby transakce + měla potomka, což by dále snížilo náklady a zvýšilo kapacitu. + + Towns svůj email uzavírá poznámkou, že dočasné anchor výstupy, díky + závislosti na [přeposílání transakcí verze 3][topic v3 transaction relay], + obsahují většinu benefitů `SIGHASH_GROUP` a nabízí velkou výhodu + ve snadnosti nasazení do produkce oproti `SIGHASH_GROUP`, který + by vyžadoval soft fork. + +- **Požadavek důkazu, že asynchronní platba byla přijata:** Valentine + Wallace [zaslala][wallace pop] do emailové skupiny Lightning-Dev požadavek + na vývojáře k nalezení způsobu, kterým by mohl autor [asynchronní + platby][topic async payments] obdržet důkaz, že platba byla přijata. + V tradičních LN platbách generuje příjemce tajná data, která jsou + zahashována. Tento hash je předán plátci v podepsané faktuře. Plátce + poté pomocí [HTLC][topic htlc] zaplatí komukoliv, kdo odhalí původní + tajná data. Ta jsou důkazem, že plátce zaplatil za hash z podepsané + faktury. + + Oproti tomu jsou asynchronní platby přijaty, když je příjemce offline, + a proto tajná data nemohou být odhalena, což v současném modelu + znemožňuje vytvoření důkazu platby. Wallace po vývojářích žádá, aby + vymysleli způsob, kterým by bylo možné důkaz asynchronní platby vytvořit + ať již v současném modelu založeném na HTLC nebo budoucím [PTLC][topic ptlc]. + +## 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/" %} + +- [Klíče pro podepisování Bitcoin Core byly z repozitáře odstraněny. Jak nově postupovat?]({{bse}}116649) + Andrew Chow vysvětluje, že ač byly klíče pro podepisování [odstraněny][remove builder + keys] z repozitáře Bitcoin Core, seznam klíčů lze nově nalézt v [repozitáři + guix.sigs][guix.sigs repo], kde sídlí atestace sestavení [guix][topic reproducible + builds]. + +- [Proč signet nepoužívá jedinečný bech32 prefix?]({{bse}}116630) + Casey Rodarmor se ptá, proč adresy na testnetu i [signetu][topic signet] používají + shodný prefix `tb1`. Jeden z autorů [BIP325][] Kalle vysvětluje, že i když + signet původně odlišný prefix používal, věřilo se, že používání stejného + prefixu zjednoduší práci s touto alternativní testovací sítí. + +- [Ukládání libovolných dat ve witnessu?]({{bse}}116875) + RedGrittyBrick poukazuje na [jednu z několika][large witness tx] nedávných + P2TR transakcí obsahující velké množství dat ve witnessu. Jiní uživatelé + vysvětlují, že projekt Ordinals poskytuje službu na začleňování libovolných + dat, jako je [obrázek][ordinals example] v uvedené transakci, do bitcoinových + transakcí pomocí witnessu. + +- [Proč se locktime nastavuje na úrovni transakce, ale sequence na úrovni vstupu?]({{bse}}116706) + RedGrittyBrick poskytuje historický kontext za `nSequence` a `nLockTime` a + Pieter Wuille vysvětluje evoluci významu [časových zámků][topic timelocks]. + +- [BLS podpisy vs Schnorr]({{bse}}116551). + Pieter Wuille porovnává kryptografické předpoklady mezi BLS a [Schnorrovými][topic schnorr signatures] + podpisy, časy ověřování a vysvětluje potíže s BLS [vícenásobnými podpisy][topic + multisignature] a chybějící podporu [adaptor podpisů][topic adaptor signatures]. + +- [Proč přesně by přidání dělitelnosti bitcoinu vyžadovalo hard fork?]({{bse}}116584) + Pieter Wuille vysvětluje čtyři možnosti soft forku, které by umožnily dělitelnost + mincí pod úroveň satoshi: + + 1. [Vynucený soft fork][forced soft fork] se změnou pravidel vyžadující, + aby všechny nové transakce následovaly nová pravidla + 2. Jednosměrné rozšíření bloků, které odděluje transakce následující nová + pravidla, podobné bodu 1, ale též povoluje zastaralé transakce + 3. Obousměrné rozšíření bloků, podobné bodu 2, avšak umožňující mincím + následující nová pravidla vrátit se zpět + 4. Metoda, která používá současná pravidla, ale ukládá hodnoty menší než + satoshi na jiné místo v transakci + +## Významné změny v kódu a dokumentaci + +*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] a [Lightning BOLTs][bolts repo].* + +- [Bitcoin Core #26325][] vylepšuje výsledek RPC volání `scanblocks` odstraněním + falešně pozitivních výsledků ve druhém běhu. `scanblocks` lze použít k vyhledání bloků + obsahujících transakce vztažené k poskytnutému seznamu deskriptorů. Jelikož + může filtrování nesprávně vybrat bloky, které ve skutečnosti neobsahují žádné + relevantní transakce, přináší tato změna druhý běh s validací každého výsledku, + která ověří, zda bloky ve výsledku skutečně odpovídají zadaným deskriptorům. + Kvůli dopadu na výkonnost musí být tato validace aktivována argumentem + `filter_false_positives`. + +- [Libsecp256k1 #1192][] aktualizuje testy v knihovně. Změnou parametru `B` + křivky secp256k1 ze `7` na jiné číslo lze nalézt jiné grupy, které + jsou kompatibilní s libsecp256k1, ale které jsou mnohem menší než řád + křivky secp256k1, tedy přibližně 2256. S těmito malými + grupami, které jsou pro bezpečnou kryptografii nepoužitelné, lze provádět + testování logiky libsecp256k1 nad každým možným podpisem. Tato změna + přidává grupu velikosti 7 k již existujícím velikostem 13 a 199. Vývojáři + však nejdříve museli vyřešit zvláštní algebraické vlastnosti, kvůli kterým + jednoduchý vyhledávací algoritmus ne vždy uspěl. Velikost 13 zůstává jako + výchozí. + +- [BIPs #1383][] přiřazuje [BIP329][] návrhu na standardní formát exportu + štítků peněženek. Oproti původnímu návrhu (viz [zpravodaj č. 215][news215 labels], + *angl.*) je hlavní změnou přechod z CSV na JSON. + +{% 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://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 +[wiki address prefixes]: https://en.bitcoin.it/wiki/List_of_address_prefixes +[large witness tx]: https://blockstream.info/tx/a6628f32a5b41b359cfe4ab038ff7c4279118ff601b9eca85eca8a64763db40c?expand +[ordinals example]: https://ordinals.com/tx/a6628f32a5b41b359cfe4ab038ff7c4279118ff601b9eca85eca8a64763db40c diff --git a/_posts/cs/newsletters/2023-02-01-newsletter.md b/_posts/cs/newsletters/2023-02-01-newsletter.md new file mode 100644 index 0000000000..de1f5c61e1 --- /dev/null +++ b/_posts/cs/newsletters/2023-02-01-newsletter.md @@ -0,0 +1,185 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 236' +permalink: /cs/newsletters/2023/02/01/ +name: 2023-02-01-newsletter-cs +slug: 2023-02-01-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme popis návrhu na bezserverový payjoin a nápadu na +posílání důkazu asynchronních LN plateb. Také nechybí naše pravidelná +rubrika s výčtem významných změn v populárních bitcoinových páteřních +projektech. + +## Novinky + +- **Návrh na bezserverový payjoin:** Dan Gould [poslal][gould payjoin] do + emailové skupiny Bitcoin-Dev návrh a [implementaci na ověření konceptu][payjoin + impl] bezserverové verze [BIP78][], protokolu pro [payjoin][topic payjoin]. + + Bez použití payjoinu obsahuje typická bitcoinová platba pouze vstupy + utrácející strany, což umožňuje slídilským organizacím použití [heuristiky + na základě společného vlastnictví vstupů][common input ownership heuristic], + která předpokládá, že všechny vstupy transakce patří stejné peněžence. + Payjoin tuto heuristiku prolamuje tím, že umožňuje příjemci přispět + platbě svými vstupy. Tato technika nabízí okamžité zlepšení soukromí + uživatelům payjoinu i obecně všem uživatelům bitcoinu snížením + spolehlivosti zmíněné heuristiky. + + Avšak flexibilita payjoinu nedosahuje flexibility typické bitcoinové platby. + Většina běžných plateb může být odeslána, i když je příjemce offline, + ale payjoin vyžaduje, aby byl příjemce online a podepsal své vstupy. + Existující protokol payjoinu také vyžaduje, aby byl příjemce schopný + akceptovat HTTP požadavky na síťové adrese přístupné odesílateli, + čehož příjemce většinou dosáhne provozováním webového serveru na veřejné + IP adrese, na které poslouchá příslušný software. Jak bylo zmíněno ve + [zpravodaji č. 132][news132 payjoin] (*angl.*), jednou z možností + pro navýšení použití payjoinu by bylo provozovat jej více P2P mezi + běžnými peněženkami. + + Gould navrhuje přidat do peněženek se schopností payjoinu lehký HTTP + server se šifrováním pomocí [protokolu Noise][noise protocol] a možností + použít [protokol TURN][TURN protocol] k překonání [NATu][NAT]. + To by umožnilo dvěma peněženkám interaktivně komunikovat během krátké + doby, která je potřeba pro vytvoření payjoinové platby, bez nutnosti + dlouhodobě provozovat webový server. To by však stále neumožnilo + vytvářet payjoin, když je příjemce offline. Gould navrhuje prozkoumat + možnosti [protokolu NOSTR][nostr protocol] pro případné použití s + asynchronním payjoinem. + + V době psaní neobdržel návrh v emailové skupině žádné odpovědi. + +- **Důkaz asynchronní LN platby:** jak bylo zmíněno [v minulém čísle + zpravodaje][news235 async], vývojáři LN hledají způsob posílání + [asynchronních plateb][topic async payments], které poskytují plátci + důkaz o přijetí platby. Asynchronní platba umožňuje plátci (Alici) + poslat LN platby příjemci (Bobovi) běžným způsobem přeposíláním + mezi uzly, mezi kterými je i LSP (poskytovatel lightningové služby), + který platbu Bobovi pozdrží, je-li zrovna offline. Jakmile Bob + LSP oznámí, že je opět online, LSP přepošle platbu dále na cestu + směrem k Bobovi. + + Jelikož je Bob offline, nemůže tímto způsobem v současném LN + (založeném na [HTLC][topic htlc]) poskytnout Alici fakturu obsahující + tajný kód podle svého výběru. Namísto toho může Alice použít jí zvolený + tajný kód a začlenit ho do asynchronní platby, kterou odešle Bobovi + (tento způsob se nazývá [keysend][topic spontaneous payments] platba). + Ale jelikož zná Alice tento tajný kód, nemůže jeho znalost použít jako + důkaz platby Bobovi. Jinou možností je, že Bob dopředu vygeneruje několik + standardních faktur a poskytne je svému LSP, který by je mohl doručit + případným plátcům, jako je Alice. Platba takových faktur by vygenerovala + důkaz, že Bob platbu přijal. Avšak tento způsob by nezabránil LSP + odeslat stejnou fakturu několika plátcům, což by vyústilo v několik plateb + za stejný tajný kód. V okamžiku, kdy se LSP dozví tajný kód v důsledku + provedení první platby, mohl by LSP ukrást prostředky zbývajících plateb + za přepoužité faktury. To by bylo bezpečné pouze v případě, že by Bob + mohl zcela důvěřovat svému LSP. + + Tento týden [navrhl][towns async] Anthony Towns řešení založené na + [signature adaptors][topic adaptor signatures]. To by záviselo na + plánovaném upgradu LN pro používání [PTLC][topic ptlc]. Bob by dopředu + vygeneroval sérii nonce čísel pro podepisování a předal je svému LSP. + Ten by poslal nonce číslo Alici, Alice by zvolila zprávu pro potvrzení platby + (např. „Alice zaplatila Bobovi 1 000 sat 2023-02-01 12:34:56Z”) a použila + by Bobovo nonce číslo a tuto zprávu k vygenerování signature adaptor pro + svůj PTLC. Až bude Bob opět online, LSP mu přepošle platbu a Bob ověří, + že nonce nebylo nikdy předtím použito, že souhlasí se zprávou, že platba + je validní a že výpočet signature adaptor je správný. Poté platbu přijme + a až Alice obdrží dokončené PTLC, obdrží tím svou zprávu podepsanou Bobem. + + Townsovo řešení také vyžaduje, aby LSP obdržel od Boba dopředu vygenerované + faktury, avšak je oproti HTLC bezpečné a nevyžaduje důvěru, protože každá + platba od různých plátců (jako je např. Alice) používá odlišný bod + veřejného klíče PTLC a Bob má možnost zabránit znovupoužití nonce. Každý bod + PTLC je odlišný, protože je odvozen od jedinečné zprávy zvolené každým + plátcem. Bob může zabránit znovupoužití nonce jeho zkontrolováním před + přijmutím platby. + + Ve svém příspěvku [odkazuje][towns sa1] Towns na dva [předešlé][towns sa2] + příspěvky, které napsal o důkazech LN platby pomocí signature adaptors. + V době psaní nebyly do emailové skupiny poslány žádné odpovědi. + +## Významné změny v kódu a dokumentaci + +*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] a [Lightning BOLTs][bolts repo].* + +- [Bitcoin Core #26471][] snižuje výchozí kapacitu mempoolu z 300 MB na 5 MB, + aktivuje-li uživatel režim `-blocksonly`. Jelikož je nepoužitá paměť + mempoolu sdílena s dbcache, snižuje tato změna také výchozí velikost + dbcache v `-blocksonly` režimu. Uživatelé mohou i nadále zvolit větší + kapacitu mempoolu pomocí volby `-maxmempool`. + +- [Bitcoin Core #23395][] přidává do `bitcoind` volbu `-shutdownnotify`, + která spustí volitelný příkaz, když se `bitcoind` ukončuje. + +- [Eclair #2573][] přináší přijímání [keysend][topic spontaneous + payments] plateb, které neobsahují [skrytá data][topic payment + secrets], ani když je Eclair obecně požaduje. Dle popisu změny + posílají LND i Core Lightning keysend platby bez těchto skrytých dat. + Skrytá data („payment secrets”) byla navržena na podporu [plateb s více + cestami][topic multipath payments], Eclair tedy očekává, že ostatní + implementace budou posílat keysend platby pouze s jedinou cestou. + +- [Eclair #2574][] v souvislosti s předchozí změnou přestává posílat + skrytá data v keysend platbách. Dle popisu LND odmítá keysend platby, + které skrytá data obsahují, i přesto, že toto není specifikováno + v [BLIP3][]. + +- [Eclair #2540][] mění způsob ukládání dat o otevíracích a commitment + transakcích v přípravě na pozdější přidání podpory pro [splicing][topic + splicing]. Viz změnu [#2584][eclair #2584], která obsahuje návrh podpory + splicingu. + +- [LND #7231][] přidává RPC volání a volbu `lncli` pro podepisování + a ověřování zpráv. Formát pro P2PKH je kompatibilní s RPC voláním + `signmessage`, které bylo přidáno do Bitcoin Core v roce 2011. + Pro P2WPKH a P2SH-P2WPKH (též zvaný vnořený či nested P2PKH) je + použit shodný formát. Tento formát očekává, že podpis bude + ve formátu ECDSA, a ověření vyžaduje možnost odvození veřejného + klíče z podpisu. V případě P2TR, které by byly použity s [Schnorrovými + podpisy][topic schnorr signatures], není možné odvodit veřejný + klíč z podpisu. Namísto toho jsou pro P2TR adresy generovány a + ověřovány ECDSA podpisy. + + Poznámka: Optech obecně [doporučuje nepoužívat][p4tr new hd] ECDSA + podpisy s klíči určenými pro použití se Schnorrovými podpisy, avšak + aby se vyhnuli potížím, učinili vývojáři LND [mimořádné kroky][osuntokun + sigs]. + +- [LDK #1878][] přidává vedle globálního nastavení možnost stanovit + `min_final_cltv_expiry` i za jednotlivé platby. Tato hodnota určuje + nejvyšší počet bloků, během kterého musí příjemce platbu nárokovat, + než expiruje. Standardní výchozí volba je 18 bloků, avšak příjemci + mohou nastavením parametru v [BOLT11][] faktuře požádat o prodloužení. + + Aby mohl LDK v kombinaci se svou unikátní implementací [bezestavových + faktur][topic stateless invoices] tuto schopnost podporovat, kóduje hodnotu + do [skrytých dat][topic payment secrets], která musí odesílatel začlenit. + Poskytuje pro tuto volbu 12 bitů, což umožňuje nastavit až 4 096 bloků + (zhruba čtyři týdny). + +- [LDK #1860][] přidává podporu pro kanály používající [anchor výstupy][topic + anchor outputs]. + +{% include references.md %} +{% 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://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://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 new file mode 100644 index 0000000000..dda9a0886f --- /dev/null +++ b/_posts/cs/newsletters/2023-02-08-newsletter.md @@ -0,0 +1,203 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 237' +permalink: /cs/newsletters/2023/02/08/ +name: 2023-02-08-newsletter-cs +slug: 2023-02-08-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme souhrn diskuze o ukládání dat ve witnessech +transakcí a poukazujeme na hovor o opatřeních proti zahlcování LN. +Též nechybí naše pravidelné rubriky se souhrnem sezení Bitcoin Core +PR Review Club a popisem významných změn v oblíbených bitcoinových +páteřních projektech. + +## Novinky + +- **Diskuze o ukládání dat v blockchainu:** uživatelé nového projektu nedávno + začali ukládat velké množství dat ve witnessech transakcí obsahujících segwit + vstupy verze 1 ([taproot][topic taproot]). Robert Dickinson [zaslal][dickinson + ordinal] do emailové skupiny Bitcoin-Dev dotaz, zda by měl být zaveden + velikostní limit, aby odradil od podobného ukládání dat. + + Andrew Poelstra [odpověděl][poelstra ordinal], že neexistuje žádný účinný + způsob, který by ukládání dat zabránil. Přidání nových omezení za účelem + zabránění ukládání nechtěných dat ve witnessech by podlomilo přednosti + designu taprootu (viz [zpravodaj č. 65][news65 tapscript], *angl.*) + a pravděpodobně by vyústilo v ukládání dat jinými způsoby. Tyto způsoby + by mohly zvýšit náklady těm, kteří data generují, ale pravděpodobně ne + dostatečně na to, aby je ve velké míře od tohoto chování odradily. + Alternativní metody ukládání dat by také mohly vytvořit nové problémy + běžným uživatelům bitcoinu. + + V době psaní stále probíhala o tomto tématu živá debata. Příští týden + poskytneme ve zpravodaji aktualizaci. + +- **Souhrn hovoru o opatřeních proti zahlcování LN:** Carla Kirk-Cohen a + Clara Shikhelman [zaslaly][ckccs jamming] do emailové skupiny Lightning-Dev + souhrn nedávného videohovoru o snahách adresovat [útoky zahlcením kanálu][topic + channel jamming attacks]. Mezi probraná témata patří kompromisy během + upgradu, jednoduchý návrh na předplácení podle nedávného článku (viz + [zpravodaj č. 226][news226 jam], *angl.*), software CircuitBreaker + (viz [zpravodaj č. 230][news230 jam]), aktualizace osvědčení o + reputaci (viz [zpravodaj č. 228][news228 jam]) a související pokrok + pracovní skupiny pro specifikaci poskytovatelů lightningových služeb (LSP). + Pro více podrobností a [transkript][jam xs] viz zmíněný příspěvek do + emailové skupiny. + + Budoucí videohovory jsou plánovány na každé dva týdny. Sledujte + emailovou skupinu Lightning-Dev, kde budou setkání oznámena. + +## Bitcoin Core PR Review Club + +[Nechť AddrMan sleduje celkové hodnoty podle sítě a tabulky, zlepšení +přesnosti přidávání fixních seedů][review club 26847] je PR od Martina +Zumsandeho a jeho spoluautora Amitiho Uttarwara, které klientovi Bitcoin +Core umožňuje v určitých situacích spolehlivěji nalézt odchozí spojení. +Činí tak rozšířením komponenty `AddrMan` (správce adres spojení) +sledováním počtu adres podle sítě a typu („vyzkoušená" vs. „nová”), což +v důsledku vylepšuje použití fixních seedů. Tato změna je prvním krokem +v dlouhé cestě za vylepšením výběru odchozích spojení. + +{% include functions/details-list.md + q0="Kdy se síť považuje za dosažitelnou?" + a0="Síť se považuje za dosažitelnou, dokud si nejsme jisti, že k ní + nemáme žádný přístup, či dokud naše konfigurace nespecifikuje + jednu či více _jiných_ sítí pomocí parametru `-onlynet` (poté + se považují za dosažitelné pouze tyto sítě, i když jsou ve + skutečnosti dostupné i sítě jiné)." + a0link="https://bitcoincore.reviews/26847#l-22" + + q1="Jak je nakládáno s adresou obdrženou přes P2P v závislosti + na tom, je-li síť dosažitelná či nedosažitelná? Ukládáme ji + (přidáním do `AddrMan`) a/nebo ji přeposíláme dalším spojením?" + a1="Je-li síť na adrese dosažitelná, přepošleme adresu dvěma + náhodně vybraným spojením, jinak ji přepošleme jednomu či + dvěma spojením (jestli jednomu nebo dvěma zvolíme náhodně). + Ukládáme adresy pouze dosažitelných sítí." + a1link="https://bitcoincore.reviews/26847#l-51" + + q2="Jak se v současnosti může přihodit, že se uzel zasekne, protože má + v `AddrMan` pouze nedosažitelné adresy, a tedy nemůže nalézt žádné + odchozí spojení? Nabízí toto PR řešení?" + a2="Změnou volby `-onlynet`. Předpokládejme například, že byl uzel + neustále provozován s volbou `-onlynet=onion`, a tedy nemá žádné I2P + adresy. Poté je uzel restartován s volbou `-onlynet=i2p`. Fixní + seedy mají nějaké I2P adresy, avšak před tímto PR je uzel nepoužil, + neboť `AddrMan` nebyl _zcela_ prázdný (obsahoval nějaké onion + adresy). S tímto PR je během spouštění několik I2P fixních seedů + přidáno, jelikož `AddrMan` neobsahuje žádné adresy _tohoto_ typu sítě." + a2link="https://bitcoincore.reviews/26847#l-98" + + q3="Co se děje s adresou během přidávání do `AddrMan`, pokud + koliduje s adresou již existující? Je existující adresa vždy nahrazena + novou?" + a3="Ne, obecně je uchována pouze existující adresa (a nikoliv adresa nová), + pokud se však existující adresa nepovažuje za „příšernou” (viz metoda + `AddrInfo::IsTerrible()`)." + a3link="https://bitcoincore.reviews/26847#l-100" + + q4="Proč je výhodné být neustále připojen ke každé dostupné síti?" + a4="Sobeckým důvodem je, že je tak těžší vystavit uzel [útoku zastínením][topic + eclipse attacks] („eclipse attack”), jelikož by útočník musel provozovat + uzly na více sítích. Nesobeckým důvodem je, že to pomáhá udržovat + celou síť propojenou, což pomáhá vyvarovat se štěpení blockchainu + v důsledku dělení sítě. Pokud by polovina uzlů (včetně těžařů) + běžela s `-onlynet=x` a druhá polovina (včetně těžařů) s `-onlynet=y`, + mohly by vyvstat dva blockchainy. I bez tohoto PR mohli provozovatelé + uzlů manuálně přidat spojení pro každý dostupný typ sítě pomocí + volby `-addnode` nebo RPC volání `addnode`." + a4link="https://bitcoincore.reviews/26847#l-114" + + q5="Proč současná logika v metodě `ThreadOpenConnections()` ani s tímto + PR dostatečně nezaručuje existenci trvalých odchozích spojení do každé + dostupné sítě?" + a5="Nic v PR _nezaručuje_ distribuci spojení mezi dostupnými sítěmi. + Například pokud máme v `AddrMan` 10 000 clearnetových adres a pouze + 50 I2P adres, je velmi pravděpodobné, že všechna naše spojení + budou do clearnetu (IPv4 nebo IPv6)." + a5link="https://bitcoincore.reviews/26847#l-123" + + q6="Jaké další kroky by bylo potřeba učinit k dosažení cíle z předchozí + otázky?" + a6="Dalším plánovaným krokem je přidání logiky do procesu vytváření + spojení, která by se pokoušela mít alespoň jedno spojení do každé + dosažitelné sítě. Toto PR přináší přípravu k tomuto kroku." + a6link="https://bitcoincore.reviews/26847#l-144" +%} + +## Významné změny v kódu a dokumentaci + +*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] a [Lightning BOLTs][bolts repo].* + +- [Bitcoin Core #25880][] přináší adaptivní timeout zaseknutí během úvodní + synchronizace. Bitcoin Core posílá požadavky na bloky několika spojením + najednou. Je-li jedno spojení natolik pomalejší oproti ostatním spojením, + že se uzel zasekne během čekání na další blok, odpojíme po určité době + toto zaseknuté spojení. V některých případech to mohlo způsobit, že + uzel s pomalým připojením odpojil několik spojení v řadě, když + se pokoušel stáhnout velký blok, který nemohl být stažen před vypršením + timeoutu. Tato změna přináší dynamické přizpůsobení timeoutu: pokud nepřichází + bloky, je timeout s každým dalším odpojením navýšen. Jakmile bloky opět + začnou přicházet, timeout se blok po bloku opět sníží. + +- [Core Lightning #5679][] poskytuje plugin pro spouštění SQL dotazů + nad různými seznamy v rámci CLN. Tento patch také lépe zachází se zastaráváním + funkcí, neboť může ignorovat všechny funkce, které byly označeny za + zastaralé před jeho vydáním (viz [Core Lightning #5867][]). + +- [Core Lightning #5821][] přidává RPC volání `preapproveinvoice` (předschválit + fakturu) a `preapprovekeysend` (předschválit keysend), která volajícímu umožní + odeslat podepisujícímu modulu (`hsmd`) [BOLT11][] fakturu nebo detaily o [keysend][topic spontaneous + payments] platbě. Podepisující modul tak může ověřit, zda + platbu může podepsat. Pro některé aplikace, např. takové, kde jsou částky + rychlostně limitovány, může být snazší požádat o předschválení než + pokusit se o platbu a poté řešit selhání. + +- [Core Lightning #5849][] provádí na backendu změny, které uzlu umožní + zvládnout přes 100 000 spojení s jedním kanálem. I když tato situace + není v blízké budoucnosti pravděpodobná (jen k otevření tolika kanálů + by bylo potřeba přes tucet kompletních bloků), testování chování + umožnilo vývojářům provést několik výkonnostních vylepšení. + +- [Core Lightning #5892][] aktualizuje implementaci protokolu [nabídek][topic + offers] na základě testování kompatibility provedeném vývojářem + pracujícím na implementaci Eclair. + +- [Eclair #2565][] nyní vyžaduje, aby byly prostředky ze zavřeného kanálu + zaslány na novou adresu namísto adresy určené během otevírání kanálu. + To může zvýšit soukromí narušením [vazeb mezi výstupy][topic output linking]. + Výjimkou z tohoto pravidla je situace, kdy uživatel aktivuje volbu + `upfront-shutdown-script`, což je požadavek druhé straně kanálu + provedený během jeho otevírání, aby byla použita jen adresa stanovená + v té době (podrobnosti viz [zpravodaj č. 158][news158 upfront], *angl.*). + +- [LND #7252][] přidává podporu pro používání SQLite jako databáze + pro LND. V současnosti je SQLite podporován pouze pro nové instalace + LND, jelikož neexistuje žádný migrační kód ze stávající databáze. + +- [LND #6527][] přidává možnost zašifrovat TLS klíč, který server + ukládá na disku. LND používá TLS pro autentikaci vzdálených připojení + ke svému ovládacímu kanálu, tedy k přístupu k API. TLS klíč bude + zašifrován pomocí dat z peněženky uzlu, takže odemčení peněženky + též odemkne TLS klíč. Odemčení peněženky je již nyní vyžadováno + k posílání a přijímání plateb. + +{% 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://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://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 +[jam xs]: https://github.com/ClaraShk/LNJamming/blob/main/meeting-transcripts/23-01-23-transcript.md +[review club 26847]: https://bitcoincore.reviews/26847 diff --git a/_posts/cs/newsletters/2023-02-15-newsletter.md b/_posts/cs/newsletters/2023-02-15-newsletter.md new file mode 100644 index 0000000000..d515022d83 --- /dev/null +++ b/_posts/cs/newsletters/2023-02-15-newsletter.md @@ -0,0 +1,263 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 238' +permalink: /cs/newsletters/2023/02/15/ +name: 2023-02-15-newsletter-cs +slug: 2023-02-15-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme souhrn pokračující diskuze o ukládání dat v +bitcoinovém blockchainu, popisujeme hypotetický útok ředění poplatků +napadající některé protokoly s více účastníky a popisujeme, jak mohou +být taprootové podpisy použity s různými částmi stejného stromu. +Též nechybí naše pravidelné rubriky se souhrnem změn ve službách a +klientech, oznámeními o nových vydáních a popisem významných změn +oblíbených bitcoinových páteřních projektů. Navíc poskytujeme +jedno z našich vzácných doporučení na nový vyhledávač zaměřený +na bitcoinovou technickou dokumentaci a diskuze. + +## Novinky + +- **Pokračující debata o ukládání dat v blockchainu:** v několika + 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. + +- **Ředění poplatků v protokolech s více účastníky:** Yuval Kogman + [zaslal][kogman dilution] do emailové skupiny Bitcoin-Dev popis + útoku proti protokolům s více stranami. I když byl tento útok + již [dříve popsán][riard dilution], Kogmanův příspěvek mu přinesl + novou pozornost. Představte si, že Mallory a Bob přispějí každý + jedním vstupem do společné transakce s očekávanou velikostí a + poplatkem (tj. s očekávaným jednotkovým poplatkem). Bob pro svůj + vstup poskytne witness očekávané velikosti, ale Mallory poskytne + 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. + + 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á, + že neví o žádném v současnosti zavedeném zranitelném protokolu. + +- **Poddajnost tapscriptových podpisů:** během diskuze zmíněné výše + [poznamenal][o'connor tsm] vývojář Russell O'Connor, že podpisy pro + [tapscript][topic tapscript] mohou být aplikovány na tapscript + umístěný jinde v taprootovém stromu. Například totožný tapscript *A* + se ve stromu objevuje na dvou různých místech. Použití hlubší + alternativy by vyžadovalo přidání dodatečného 32bytového hashe do + witnessu utrácející transakce. + + ```text + * + / \ + 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. + +## 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.* + +- **Peněženka Liana přidává multisig:** + [Vydání verze 0.2][liana 0.2] peněženky [Liana][news234 liana] přidává podporu pro + vícenásobné podpisy s použitím [deskriptorů][topic descriptors]. + +- **Vydána peněženka Sparrow 1.7.2:** + [Vydání 1.7.2][sparrow 1.7.2] peněženky Sparrow přidává podporu pro [taproot][topic + taproot], export a import podle [BIP329][] (viz [zpravodaj č. 235][news235 + bip329]) a dodatečnou podporu pro hardwarová podpisová zařízení. + +- **Knihovna Bitcoinex přidává podporu pro schnorr:** + [Bitcoinex][bitcoinex github] je knihovna pro funkcionální programovací jazyk Elixir. + +- **Vydána Libwally 0.8.8:** + [Libwally 0.8.8][] přidává podporu pro tagované hashe podle [BIP340][], podporu + pro další sighash včetně [BIP118][] ([SIGHASH_ANYPREVOUT][topic SIGHASH_ANYPREVOUT]) + a nové funkce pro [miniscript][topic miniscript], deskriptory a [PSBT][topic psbt]. + +## Optech doporučuje + +[BitcoinSearch.xyz][] je nedávno uvolněný vyhledávač v rámci bitcoinové +technické dokumentace a diskuzí. Byl použit během psaní tohoto zpravodaje +pro rychlé nalezení několika zdrojů, což značí obrovské zlepšení oproti +jiným, pracnějším metodám, které jsme dříve používali. Vítány jsou +příspěvky do jeho [vývoje][bitcoinsearch repos]. + +## 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.* + +- [Core Lightning 23.02rc2][] je kandidát na vydání údržbové verze této + oblíbené implementace LN. + +- [BTCPay Server 1.7.11][] je nové vydání. Od posledního vydání, o kterém + jsme informovali (1.7.1), bylo přidáno několik novinek, oprav chyb + a vylepšení. Za pozornost zvláště stojí změna systému pluginů a + integrace služeb třetích stran. Dále byla přidána možnost migrovat + mimo MySQL a SQLite. + +- [BDK 0.27.0][] je aktualizace této knihovny pro tvorbu bitcoinových peněženek + a aplikací. + +## Významné změny v kódu a dokumentaci + +*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] a [Lightning BOLTs][bolts repo].* + +- [Core Lightning #5361][] přidává experimentální podporu pro ukládání + záloh pro svá spojení. Jak bylo naposledy zmíněno ve [zpravodaji č. 147][news147 + backups] (*angl.*), toto umožňuje, aby uzel ukládal malé zašifrované + zálohy pro svá spojení. Pokud se spojení později potřebuje znovu + připojit nebo ztratí-li data, může o zálohu požádat. Spojení může + pro dešifrování použít klíč derivovaný ze své peněženky a obnovit + se podle posledního stavu svých kanálů. Může to být považováno za + vylepšenou formu [statických záloh kanálu][topic static channel backups]. + Toto PR přidává podporu pro vytváření, ukládání a stahování zašifrovaných + záloh. Jak je poznamenáno v commitech, tato schopnost nebyla ještě plně + specifikována ani převzata jinými implementacemi LN. + +- [Core Lightning #5670][] a [#5956][core lightning #5956] přináší několik + aktualizací své implementace [duálního financování][topic dual funding] + založených na nedávných změnách [specifikace][bolts #851] a výsledcích + testů interoperability. Dále bylo přidáno RPC volán `upgradewallet`, + které přesune všechny prostředky v P2SH výstupech na nativní + segwit výstupy, které jsou vyžadovány pro interaktivní otevírání + kanálů. + +- [Core Lightning #5697][] přidává RPC volání `signinvoice` pro podepisování + [BOLT11][] faktur. Dříve podepisovalo CLN faktury pouze, pokud mělo + k dispozici předobraz [HTLC][topic HTLC] hashe, aby později mohlo platbu + nárokovat. Toto volání může podobné chování přepsat, což by mohlo být + například použito k okamžitému odeslání faktury a pozdějšímu obdržení + předobrazu z jiného programu. Uživatelé tohoto RPC volání by měli + mít na paměti, že kdokoliv se znalostí předobrazu by mohl platbu nárokovat. + To by znamenalo ne jen krádež prostředků, ale také poskytnutí + přesvědčivého svědectví o proběhlé platbě (toto svědectví je natolik silné, + že jej mnoho vývojářů nazývá *důkazem platby*). + +- [Core Lightning #5960][] přidává [bezpečnostní pravidlo][cln security.md] + s kontaktními adresami a PGP klíči. + +- [LND #7171][] vylepšuje RPC volání `signrpc` o podporu posledního + [návrhu BIP][musig draft bip] pro [MuSig2][topic musig]. Volání + nově vytváří sezení spojené s číslem verze MuSig2 protokolu, + aby všechny operace v rámci sezení používaly správný protokol. Bezpečnostní + problém starších verzí MuSig2 protokolu byl zmíněn ve [zpravodaji č. 222][news222 + musig2] (*angl.*). + +- [LDK #2002][] přidává podporu pro automatické opětovné poslání neúspěšných + [spontánních plateb][topic spontaneous payments]. + +- [BTCPay Server #4600][] aktualizuje [výběr mincí][topic coin selection] své + implementace [payjoinu][topic payjoin]. Nově se algoritmus pokusí vyvarovat + vytváření transakcí s *nadbytečnými vstupy*, konkrétně vstupy, které jsou + větší než jakýkoliv výstup u transakcí s více vstupy. Taková situace by + u běžné platby s jedním odesílatelem a jedním příjemcem nenastala: největší + vstup by byl schopen poskytnout platební výstup a další vstupy by tak + nebyly potřeba. Tato změna byla částečně inspirována [analýzou payjoinů][paper + analyzing payjoins]. + +{% include references.md %} +{% include linkers/issues.md v=2 issues="5361,5670,5956,851,5697,5960,7171,2002,4541,4600" %} +[news147 backups]: /en/newsletters/2021/05/05/#closing-lost-channels-with-only-a-bip32-seed +[cln security.md]: https://github.com/ElementsProject/lightning/blob/master/SECURITY.md +[news222 musig2]: /en/newsletters/2022/10/19/#musig2-security-vulnerability +[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://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://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://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 +[BTCPay Server 1.7.11]: https://github.com/btcpayserver/btcpayserver/releases/tag/v1.7.11 +[bdk 0.27.0]: https://github.com/bitcoindevkit/bdk/releases/tag/v0.27.0 +[news234 liana]: /cs/newsletters/2023/01/18/#vydana-penezenka-liana +[liana 0.2]: https://github.com/wizardsardine/liana/releases/tag/0.2 +[sparrow 1.7.2]: https://github.com/sparrowwallet/sparrow/releases/tag/1.7.2 +[news235 bip329]: /cs/newsletters/2023/01/25/#bips-1383 +[bitcoinex github]: https://github.com/RiverFinancial/bitcoinex +[libwally 0.8.8]: https://github.com/ElementsProject/libwally-core/releases/tag/release_0.8.8 diff --git a/_posts/cs/newsletters/2023-02-22-newsletter.md b/_posts/cs/newsletters/2023-02-22-newsletter.md new file mode 100644 index 0000000000..cff5df22b6 --- /dev/null +++ b/_posts/cs/newsletters/2023-02-22-newsletter.md @@ -0,0 +1,272 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 239' +permalink: /cs/newsletters/2023/02/22/ +name: 2023-02-22-newsletter-cs +slug: 2023-02-22-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden představujeme návrh BIP pro opkód `OP_VAULT`, přinášíme +souhrn diskuze o umožnění LN uzlům nastavit na svých kanálech příznak +vysoké dostupnosti, přeposíláme žádost o zpětnou vazbu k ohodnocování +sousedů LN uzlů a popisujeme návrh BIP pro zálohu a obnovu seedů bez +nutnosti používat jakoukoliv elektroniku. Též nechybí naše pravidelné +rubriky se souhrnem oblíbených otázek a odpovědí z Bitcoin StackExchange, +oznámeními o nových verzích a popisem významných změn oblíbených +páteřních bitcoinových projektů. + +## Novinky + + +- **Návrh BIP pro OP_VAULT:** James O'Beirne [zaslal][obeirne op_vault] + do emailové skupiny Bitcoin-Dev odkaz na [návrh BIP][bip op_vault] pro + opkód `OP_VAULT`, který dříve navrhl (viz [zpravodaj č. 234][news234 + vault]). Též oznámil, že se pokusí začlenit kód do Bitcoin Inquisition, + projektu pro testování významných návrhů změn konsenzu bitcoinu + a síťového protokolu. + +- **Příznak vysoké dostupnosti pro LN:** Joost Jager [zaslal][jager qos] + do emailové skupiny Lightning-Dev návrh na umožnění uzlům signalizovat, + že je kanál „vysoce dostupný,” tedy že operátor věří v jeho schopnost + přeposílat platby bez selhání. Pokud však k selhání dojde, odesílatel + by mohl přestat tento uzel používat na dobu mnohem delší, než v případě + uzlů, které by tento příznak nastaven neměly. Odesílatelé plateb + cílící na maximální rychlost (spíše než na nízké poplatky) by mohli + dávat přednost trasám obsahující uzly s příznakem. + + Christian Decker [odpověděl][decker qos] výtečným shrnutím problémů + reputačních systémů, včetně případů samozvané reputace. Jednou + z jeho obav je, že běžný odesílatel nebude zdaleka posílat tolik + plateb, aby v rámci rozsáhlé sítě kanálů opakovaně použil stejné uzly. + Hrozba dočasného odmítnutí poskytnutí dalších služeb není příliš + vážná v případě, kdy se jen zřídka vyžadují další služby. + + Antoine Riard [připomněl][riard boomerang] účastníkům alternativní + přístup k urychlení plateb: přeplácení s vrácením, dříve zvané + bumerangové platby („boomerang payments,” viz [zpravodaj č. 86][news86 + boomerang], *angl.*) či vratné přeplatky („refundable overpayments,” + viz [zpravodaj č. 92][news192 pp], *angl.*). V tomto schématu + by odesílatel vzal svou platbu, přidal peníze navíc, rozdělil na + několik [částí][topic multipath payments] a odeslal je po několika + trasách. Když příjemce obdrží dostatečné množství částí, které + fakturu zaplatí, nárokuje si pouze tyto části a ostatní odmítne. + Vyžaduje to, aby měl odesílatel ve svém kanálu prostředky navíc, + avšak funguje to, i když některé trasy vybrané odesílatelem selžou. + Snižuje to také nutnost, aby byl odesílatel schopen snadno vyhledat + vysoce dostupné kanály. Složitost přístupu tkví ve vytvoření + mechanismu, který by příjemcům zabránil nárokovat i přeplatky. + +- **Žádost o zpětnou vazbu k hodnocení dobrých sousedů v LN:** Carla Kirk-Cohen + a Clara Shikhelman [zaslaly][ckc-cs reputation] do emailové skupiny + Lightning-Dev žádost o komentáře k doporučeným parametrům, které by + umožnily uzlům posoudit, zda jsou druhé strany jejich kanálů dobrými + zdroji přeposlaných plateb. Navrhují několik kritérií a pro každé + z nich uvádí doporučené výchozí parametry. Rády by obdržely zpětnou + vazbu ke zvoleným nastavením. + + Usoudí-li uzel, že jedno z jeho spojení je dobrým sousedem, a tento soused + označí přeposlané platby za jím schválené, může tento uzel poskytnout + platbě přístup k více zdrojům než platbám nekvalifikovaným. Mohl by platbu + během přeposílání dalším uzlům také sám schválit. Tento mechanismus + je součástí návrhu na zabránění [útoků zahlcením kanálu][topic channel + jamming attacks], jak bylo popsáno v předchozím článku, jehož spoluautorkou + byla Shikhelman (viz [zpravodaj č. 226][news226 jam], *angl.*). + +- **Návrh BIP pro kódování seedů Codex32:** Russell O'Connor + a Andrew Poelstra [publikovali][op codex32] (pod přesmyčkami svých jmen) + návrh na BIP nového schématu pro zálohu a obnovu [BIP32][] seedů. Schéma + může volitelně, podobně jako [SLIP39][], vytvořit několik dílů pomocí + [Shamirova schématu pro sdílení tajných dat][Shamir's Secret Sharing Scheme] + („Shamir's Secret Sharing Scheme”, SSSS), které pro obnovení seedu vyžádá + použití přednastaveného minimálního počtu dílů. Útočník, který by + obdržel nižší než stanovený počet dílů, by se o seedu nic nedozvěděl. + Na rozdíl od obnovovacích kódů BIP39, Electrum, Aezeed či SLIP39, které + používají sadu slov, Codex32 používá stejnou abecedu jako [bech32][topic + bech32] adresy. Příklad jednoho takového dílu z návrhu BIP: + + ```text + ms12namea320zyxwvutsrqpnmlkjhgfedcaxrpp870hkkqrm + ``` + + Hlavní výhodou Codex32 oproti všem existujícím schématům je, že + všechny operace lze provést pouhým použitím tužky, papíru, instrukcí + a výstřižků, včetně generování seedu (lze použít hrací kostku), + jeho ochrany pomocí kontrolního součtu, generování dílů s kontrolními + součty, jejich ověření a obnovy. Možnost manuálně ověřit kontrolní + součet záloh seedu nebo jeho dílů nám připadá jako obzvláště mocný + koncept. Jedinou v současnosti dostupnou metodou ověření záloh + je vložení seedu do důvěryhodného počítače a ověření odvozených + veřejných klíčů. Avšak stanovení, zda lze zařízení věřit, není často + jednoduchou záležitostí. Co je horší, aby mohl uživatel ověřit + integritu existujících SSSS dílů (např. podle SLIP39), musí přinést + dohromady každý díl, který chtějí ověřit, spolu s dostatečným + množství ostatních dílů a poté je vložit do důvěryhodného počítače. + To znamená, že ověření integrity dílů potírá hlavní výhodu celého + schématu, tedy možnost uložit informace bezpečně a odděleně napříč + několika místy či lidmi. S Codex32 může uživatel pravidelně ověřovat + integritu každého dílu odděleně pouze pomocí papíru a pera, několika + vytištěných papírů a pár minut času. + + Diskuze v emailové skupině se hlavně soustředila na rozdíly mezi + Codex32 a SLIP32, které je v produkci používáno již několik let. + Doporučujeme každému zájemci o Codex32 pročíst jeho [webovou + stránku][codex32 website] nebo shlédnout [video][codex32 video] od + jednoho z autorů. Autoři doufají, že díky návrhu BIP začnou peněženky + přidávat podporu pro seedy kódované pomocí Codex32. + +## 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/" %} + +- [Proč se během úvodního stahování v ořezaném režimu stahují witnessy?]({{bse}}117057) + Pieter Wuille píše o případu uzlů běžících v [ořezaném + režimu][prune mode]: „jsou-li witnessy (a) před ‚assumevalid’ bodem a (b) + dostatečně hluboko za bodem ořezávání, skutečně nedává smysl je mít uložené.” + Existuje otevřený [návrh změny][Bitcoin Core #27050], která tuto situaci adresuje, + a [PR Review Club][pr review 27050] o této navrhované změně. + +- [Může bitcoinová P2P síť posílat komprimovaná data?]({{bse}}116999) + Pieter Wuille odkazuje na dvě emailové diskuze o kompresi (jedna je o + [kompresi pro výměnu hlaviček][specialized compression for headers sync], + druhá o [obecné kompresi založené na LZO][general LZO-based compression]) + a poznamenává, že satelity Blockstreamu používají pro transakce svá vlastní + kompresní schémata. + +- [Jak se stát DNS seedem pro Bitcoin Core?]({{bse}}116931) + Uživatel Paro vysvětluje požadavky pro [DNS seed][news66 dns seed], + které poskytuje novým uzlům prvotní spojení. + +- [Kde mohu nalézt otevřená témata výzkumu bitcoinu?]({{bse}}116898) + Michael Folkson poskytuje množství zdrojů, mimo jiné [Chaincode Labs + Research][] a [Bitcoin Problems][]. + +- [Jaká největší transakce bude přeposlána bitcoinovým uzlem ve výchozím nastavení?]({{bse}}117277) + Pieter Wuille poukazuje na pravidlo standardnosti, které uvádí 400 000 [váhových + jednotek][weight unit], nastavení však není konfigurovatelné. Dále vysvětluje + důvody limitu včetně ochrany proti zahlcení. + +- [Jak fungují Ordinals v bitcoinu? Co přesně se v blockchainu ukládá?]({{bse}}117018) + 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 + ``` + +- [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 + měly zdánlivě užitečnou schopnost stanovit expirační výšku, tj. výšku, + po které nebude transakci nadále platná. + +## 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.* + +- [BDK 0.27.1][] je bezpečnostní aktualizací opravující zranitelnost, která + „někdy způsobuje přetečení, když se do SQLite funkce printf strčí velký + řetězec.” Pouze software, který používá BDK s volitelnou SQLite databází, + musí být aktualizován. Detaily jsou obsaženy ve [zprávě o + zranitelnosti][RUSTSEC-2022-0090]. + +- [Core Lightning 23.02rc3][] je kandidátem na vydání nové údržbové verze + této oblíbené implementace LN. + +## Významné změny v kódu a dokumentaci + +*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] a [Lightning BOLTs][bolts repo].* + + +- [Bitcoin Core #24149][] přidává podporu pro podepisování [deskriptorů + výstupů][topic descriptors] založených na [miniscriptech][topic miniscript] + založených na P2WSH. Bitcoin Core bude schopen podepisovat vstup jakéhokoliv + miniscriptového deskriptoru, jsou-li přístupné všechny předobrazy a klíče + a jsou-li časové zámky platné. Některé možnosti pro úplnou podporu + zatím chybí: peněženka zatím neumí odhadnout váhu vstupu v případě některých + deskriptorů a neumí v některých případech podepsat [PSBT][topic PSBT]. + Na podpoře miniscriptu pro P2TR výstupy se též pracuje. + +- [Bitcoin Core #25344][] aktualizuje RPC volání `bumpfee` a `psbtbumpfee` + pro navyšování poplatků pomocí [Replace By Fee][topic rbf] (RBF). + Aktualizace umožňuje specifikovat výstupy nahrazující transakce. + Nahrazující transakce může obsahovat jinou sadu výstupů než transakce + nahrazovaná. Lze takto přidat nové výstupy (např. v případě iterativního + [dávkování][topic payment batching]) nebo výstupy odebrat (např. + chceme-li zrušit nepotvrzenou platbu). + +- [Eclair #2596][] omezuje, kolikrát se může spojení pokusit navýšit poplatek + pomocí [RBF][topic rbf] během otevírání kanálu s [oboustranným vkladem][topic dual + funding]. Je-li počet překročen, žádné další pokusy o změnu nebudou přijaty. + Důvodem této změny je, že uzel musí ukládat data o každé verzi otevírací + transakce, mohl by tedy být problém, pokud by bylo možné navýšit poplatek + bez omezení. Běžně je počet navýšení poplatku prakticky omezen potřebou + za každý pokus platit poplatky. V případě oboustranného vkladu se však očekává, + že budou uzly ukládat všechny pokusy, i takové, které nemohou validovat. + Útočník by tak mohl vytvořit neomezené množství nevalidních transakcí + navyšujících poplatek bez nutnosti za ně platit jakékoliv poplatky. + +- [Eclair #2595][] pokračuje v práci na přidání podpory [splicingu][topic splicing], + v tomto případě aktualizací konstruktorů transakcí. + +- [Eclair #2479][] přidává podporu platby [nabídek][topic offers] + následujícím způsobem: uživatel obdrží nabídku, řekne Eclairu, aby ji zaplatil, + Eclair pomocí nabídky stáhne od příjemce fakturu, ověří parametry faktury + a zaplatí ji. + +- [LND #5988][] přidává novou volitelnou funkci odhadu pravděpodobnosti + pro hledání platebních cest. Je částečně založen na dřívějším výzkumu + (viz [zpravodaj č. 192][news192 pp], *angl.*) s použitím závěrů + jiných přístupů. + +- [Rust Bitcoin #1636][] přidává funkci `predict_weight()` pro odhad váhy. + Vstupem funkce je vzor transakce, výstupem její očekávaná váha. To je obzvláště + užitečné pro správu poplatků: aby bylo možné určit, které vstupy mají být + přidány do transakce, musí být známa výše poplatku, ale aby byla známa výše + poplatku, musí být známa velikost transakce. Funkce poskytuje odhad velikosti, + aniž by se transakci pokusila sestavit. + +{% include references.md %} +{% include linkers/issues.md v=2 issues="24149,25344,2596,2595,2479,5988,1636,27050" %} +[core lightning 23.02rc3]: https://github.com/ElementsProject/lightning/releases/tag/v23.02rc3 +[news226 jam]: /en/newsletters/2022/11/16/#paper-about-channel-jamming-attacks +[news86 boomerang]: /en/newsletters/2020/02/26/#boomerang-redundancy-improves-latency-and-throughput-in-payment-channel-networks +[news92 overpayments]: /en/newsletters/2022/03/23/#payment-delivery-algorithm-update +[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://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://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://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://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 new file mode 100644 index 0000000000..9049b02576 --- /dev/null +++ b/_posts/cs/newsletters/2023-03-01-newsletter.md @@ -0,0 +1,117 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 240' +permalink: /cs/newsletters/2023/03/01/ +name: 2023-03-22-newsletter-cs +slug: 2023-03-01-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme souhrn diskuze o nejrychlejším způsobu ověření bez +použití jakéhokoliv digitálního zařízení, že záloha BIP32 seedu pravděpodobně +nebyla poškozena . Též nechybí naše pravidelné rubriky s oznámeními +o nových vydáních a souhrnem významných změn v populárních bitcoinových +páteřních projektech. + +## Novinky + +- **Rychlejší kontrolní součet zálohy seedu:** Peter Todd zaslal + [odpověď][todd codex32] k diskuzi o návrhu BIP pro Codex32 (viz + [zpravodaj z minulého týdne][news239 codex32]), což je schéma + pro vytváření, ověřování a používání obnovovacích kódů [BIP32][topic bip32] + seedů. Největší výhodou Codex32 oproti existujícím schématům je schopnost + ověřit integritu záloh pouze pomocí tužky, papíru, dokumentace a + času. + + Codex32 dává velkou jistotu ohledně detekce chyb v zálohách. Peter Todd + navrhl, že mnohem jednodušší metodou generování obnovovacích kódů by bylo + sečíst jejich části dohromady. Pokud by bylo možné výsledek tohoto kontrolního + součtu vydělit beze zbytku známou konstantou, znamenalo by to ověření + integrity zálohy v rámci parametrů. Peter Todd navrhl používat algoritmus, + který by poskytl zhruba 99,9% ochranu proti překlepům, což by podle něj + bylo dostatečně silné, snadné na používání a jednoduché na zapamatování. + Nebylo by tak potřeba používat dodatečnou dokumentaci. + + Russell O'Connor [odpověděl][o'connor codex32], že obnovovací + kód by bylo možné zkontrolovat mnohem rychleji než kompletní verifikací, + pokud by byl uživatel ochotný akceptovat slabší ochranu. Kontrola pouze + dvou znaků najednou by zaručila detekci všech jednoznakových chyb v + obnovovacím kódu a poskytla by 99,9% ochranu proti ostatním záměnám. + Postup by byl podobný generování kontrolního součtu popsaném Peterem + Toddem, avšak vyžadoval by používání zvláštní, těžko zapamatovatelné + vyhledávací tabulky. Pokud by byli uživatelé během každého ověřování + ochotni používat jinou tabulku, každé další ověření by zvýšilo pravděpodobnost + detekce chyby až do sedmého ověření, které by poskytlo stejnou garanci + jako plné ověření Codex32. K tomuto by nebyla potřeba žádná změna Codex32, + pouze dokumentace by musela být doplněna o nové tabulky a pracovní listy. + +## 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 2.2.1][] je údržbovým vydáním této aplikace umožňující softwarovým + peněženkám přístup k hardwarovým podpisovým zařízením. + +- [Core Lightning 23.02rc3][] je kandidátem na vydání nové údržbové verze + této oblíbené implementace LN. + +- [lnd v0.16.0-beta.rc1][] je kandidátem na vydání hlavní verze této oblíbené + implementace LN. + +## Významné změny v kódu a dokumentaci + +*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] a [Lightning BOLTs][bolts repo].* + +- [Bitcoin Core #25943][] přidává parametr RPC volání `sendrawtransaction`, + který omezuje množství spálených prostředků na výstup. Obsahuje-li + transakce výstup, jehož skript je vyhodnocen jako neutratitelný (s + `OP_RETURN`, nevalidním opkódem nebo příliš velkou velikostí) a jehož + hodnota je větší než `maxburnamount`, nebude do mempoolu přijata. + Výchozím nastavením je nula, což ochrání uživatele před nechtěným + spálením prostředků. + +- [Bitcoin Core #26595][] přidává do RPC volání [migratewallet][news217 + migratewallet] parametry `wallet_name` a `passphrase`. Umožní + migraci zašifrovaných zastaralých peněženek a peněženek nepoužívajících + [deskriptory][topic descriptors]. + +- [Bitcoin Core #27068][] mění nakládání se vstupem hesla. Dříve byla hesla + obsahující ASCII nulový znak (0x00) akceptována, avšak pouze část + řetězce před prvním nulovým znakem byla použita pro dešifrování + peněženky. To mohlo vést k použití méně bezpečného hesla, než uživatel + zamýšlel. Po této změně bude pro šifrování i dešifrování použito + kompletní heslo včetně nulových znaků. Pokud takové heslo při + dešifrování selže, budou uživateli nabídnuty instrukce k použití + předchozího chování. + +- [LDK #1988][] přidává limity pro počet připojení a kanálů bez prostředků + 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ě 50 spojení pokoušející se otevřít kanál. + + - 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]. + LDK ještě nepodporuje [zaslepené trasy][topic rv routing], nemůže tedy + zatím přijímat a odesílat nabídky napřímo, ale tato změna umožní + vývojářům začít s experimenty. + +{% include references.md %} +{% include linkers/issues.md v=2 issues="25943,26595,27068,1988,1977,798" %} +[core lightning 23.02rc3]: https://github.com/ElementsProject/lightning/releases/tag/v23.02rc3 +[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://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 new file mode 100644 index 0000000000..2fad2b93c4 --- /dev/null +++ b/_posts/cs/newsletters/2023-03-08-newsletter.md @@ -0,0 +1,196 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 241' +permalink: /cs/newsletters/2023/03/08/ +name: 2023-03-08-newsletter-cs +slug: 2023-03-08-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme popis návrhu alternativního designu `OP_VAULT` s +několika výhodami a oznamujeme nový týdenní Optech podcast. Též nechybí +naše pravidelné rubriky se souhrnem Bitcoin Core PR Review Club sezení, +oznámeními o nových vydáních a popisem významných změn oblíbených +páteřních bitcoinových projektů. + +## Novinky + +- **Alternativní návrh OP_VAULT:** Greg Sanders [zaslal][sanders + vault] do emailové skupiny Bitcoin-Dev alternativní design poskytující + 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. + + 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 + autorizace. V návrhu `OP_VAULT` mohl prostředky zmrazit kdokoliv, kdo + znal parametry zvolené Alicí. Ačkoliv to není problém bezpečnostní, + může být dosti otravný. V Sandersově návrhu by mohla Alice pro započetí + zmrazení vyžadovat například podpis nějaké slabě chráněné peněženky. To by + mohlo být dostatečné pro zabránění většiny otravných útoků, ale nebránilo + by to Alici v případě potřeby prostředky rychle zmrazit. + + Několik dalších výhod spočívá ve snadnosti porozumění a ověření správnosti + [protokolu][topic vaults]. Autor původního `OP_VAULT` návrhu James O'Beirne + se o Sandersově návrhu vyjádřil pozitivně. O'Beirne též přinesl několik + dodatečných změn, které popíšeme v budoucím čísle zpravodaje. + +- **Nový Optech podcast:** týdenní Optech Audio Recap na Twitter Spaces + je nyní dostupný jako podcast. Každá epizoda bude dostupná na všech + oblíbených podcastových platformách a přepis bude přístupný na našem webu. + Náš [blogový příspěvek][podcast post] obsahuje další informace včetně + vysvětlení, proč podcast považujeme za důležitý krok v naší misi za + vylepšení technické komunikace v bitcoinu. + +## 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í.* + +[Bitcoin-inquisition: Aktivační logika pro testování změn konsenzu][review club bi-16] +je PR od Anthonyho Townse, které přidává způsob aktivace a deaktivace soft forků v projektu +[Bitcoin Inquisition][], navrženém na testování na [signetu][topic signet]. Projekt +byl popsán ve [zpravodaji č. 219][newsletter #219 bi] (*angl.*). + +Konkrétně toto PR nahrazuje sémantiku bitů verze bloku podle [BIP9][] takzvaným +[dědičným nasazováním][Heretical Deployments] („Heretical Deployments”). Na rozdíl od změn konsenzu a přeposílání +na mainnetu, které se obtížně a zdlouhavě aktivují a vyžadují pečlivé budování konsenzu +mezi lidmi a spletitý mechanismus [aktivace][topic soft fork activation], mohou být +tyto změny na testnetu nasazovány jednodušeji. PR také implementuje způsob deaktivace +změn, které se ukázaly jako problematická či nežádoucí, což je další rozdíl oproti +mainnetu. + +{% include functions/details-list.md + q0="Proč chceme nasazovat změny konsenzu, které nejsou začleněny do + Bitcoin Core? Jaké problémy by přineslo začleňování kódu do Bitcoin Core + a následného otestování na signetu?" + a0="Bylo probráno několik důvodů. Nemůžeme nutit uživatele mainnetu k upgradu + jejich verze Bitcoin Core, a tedy i po opravení chyby mohou někteří uživatelé + stále provozovat chybovou verzi. Spoléhání pouze na regtest ztěžuje integrační + testování software třetích stran. Začleňování změn konsenzu do odděleného + repozitáře je mnohem méně riskantní než začleňování do Core: přidávání + logiky soft forků, byť deaktivované, může přinést chyby ovlivňující stávající chování." + a0link="https://bitcoincore.reviews/bitcoin-inquisition-16#l-37" + + q1="Dědičné nasazování postupně mění stav podobně jako BIP9 + (`DEFINED`, `STARTED`, `LOCKED_IN`, `ACTIVE` a`FAILED`), + avšak s jedním dodatečným stavem po `ACTIVE` nazývaným `DEACTIVATING` + (po němž následuje konečný stav `ABANDONED`). Jaký je smysl stavu + `DEACTIVATING`?" + a1="Dává uživatelům možnost vyzvednout prostředky, které mohou mít + v soft forku. Po deaktivaci nebo nahrazení forku by nemuseli mít + k prostředkům přístup, jelikož by transakce byla odmítnuta jako + nestandardní. Není ani tak důležité vyvarovat se ztrát prostředků + na signetu, ale snažit se nepřeplňovat množinu UTXO." + a1link="https://bitcoincore.reviews/bitcoin-inquisition-16#l-92" + + q2="Proč PR odstraňuje `min_activation_height`?" + a2="V novém modelu nepotřebujeme nastavitelný předaktivační interval. + S dědičným nasazováním se automaticky aktivuje na počátku následující + 432blokové periody (zhruba tři dny; tato perioda je pevně daná)." + a2link="https://bitcoincore.reviews/bitcoin-inquisition-16#l-126" + + q3="Proč je v tomto PR taproot trvale usazen?" + a3="Pokud by nebyl trvale usazen („buried”), musel by být dědičně + nasazen, což by vyžadovalo trochu kódování. Též by to znamenalo, že + by jeho časový limit jednou vypršel, což nechceme." + a3link="https://bitcoincore.reviews/bitcoin-inquisition-16#l-147" +%} + +## 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.* + +- [Core Lightning 23.02][] je vydáním nové verze této oblíbené implementace LN. + Obsahuje experimentální podporu ukládání záloh pro spojení (viz [zpravodaj + č. 238][news238 peer storage]) a aktualizuje experimentální podporu pro + [oboustranné vklady][topic dual funding] a [nabídky][topic offers]. Též + nechybí několik dalších vylepšení a oprav chyb. + +- [LDK v0.0.114][] je vydáním nové verze této knihovny pro budování + peněženek a aplikací s podporou LN. Opravuje několik bezpečnostních + chyb a obsahuje schopnost parsovat [nabídky][topic offers]. + +- [BTCPay 1.8.2][] je nejnovějším vydáním tohoto oblíbeného software pro + zpracování bitcoinových plateb. Poznámky k vydání verze 1.8.0 říkají, že + „tato verze přináší vlastní platební formuláře, možnosti nastavení + brandingu, předělaný pohled klávesnice PoS, nové ikony a štítkování adres.” + +- [LND v0.16.0-beta.rc2][] je kandidátem na vydání nové hlavní verze této oblíbené + implementace LN. + +## Významné změny v kódu a dokumentaci + +*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] a [Lightning BOLTs][bolts repo].* + +- [LND #7462][] umožňuje watch-only peněžkám se vzdáleným + podepisováním spuštění v bezstavovém režimu. + +{% include references.md %} +{% include linkers/issues.md v=2 issues="7462" %} +[core lightning 23.02]: https://github.com/ElementsProject/lightning/releases/tag/v23.02 +[lnd v0.16.0-beta.rc2]: https://github.com/lightningnetwork/lnd/releases/tag/v0.16.0-beta.rc2 +[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://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 +[newsletter #219 bi]: /en/newsletters/2022/09/28/#bitcoin-implementation-designed-for-testing-soft-forks-on-signet +[review club bi-16]: https://bitcoincore.reviews/bitcoin-inquisition-16 +[bitcoin inquisition]: https://github.com/bitcoin-inquisition/bitcoin +[heretical deployments]: https://github.com/bitcoin-inquisition/bitcoin/wiki/Heretical-Deployments +[bip9]: https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki diff --git a/_posts/cs/newsletters/2023-03-15-newsletter.md b/_posts/cs/newsletters/2023-03-15-newsletter.md new file mode 100644 index 0000000000..39e5a3b5a4 --- /dev/null +++ b/_posts/cs/newsletters/2023-03-15-newsletter.md @@ -0,0 +1,69 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 242' +permalink: /cs/newsletters/2023/03/15/ +name: 2023-03-15-newsletter-cs +slug: 2023-03-15-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme oznámení o service bitu používaném pro testování +Utreexo, odkazujeme na několik nových softwarových vydání a popisujeme +začleněný pull request Bitcoin Core. + +## Novinky + +- **Service bit pro Utreexo:** Calvin Kim [zaslal][kim utreexo] do + emailové skupiny Bitcoin-Dev zprávu, že software právě navrhovaný + pro experimenty na signetu a testnetu bude v P2P protokolu používat + service bit 24. Experimentální software poskytuje podporu pro + [Utreexo][topic utreexo], protokol umožňující plnou validaci + transakcí uzly, které neukládají sadu UTXO, což ušetří až 5 GB + diskového prostoru oproti modernímu Bitcoin Core plnému uzlu a + bez snížení bezpečnosti. Utreexo uzel potřebuje stáhnout dodatečná data, + obdrží-li nepotvrzenou transakci (nebo blok potvrzených transakcí), + service bit tedy pomůže uzlu najít spojení schopná tato data + poskytnout. + +## 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.* + +- [Core Lightning v23.02.2][] je údržbovým vydáním tohoto LN software. + Vrací zpět změny RPC volání `pay`, které způsobily problémy + jiným systémům, a obsahuje několik dalších změn. + +- [Libsecp256k1 0.3.0][] je vydáním této kryptografické knihovny. + Obsahuje změnu API, která porušuje kompatibilitu ABI. + +- [LND v0.16.0-beta.rc3][] je kandidátem na vydání hlavní verze této + oblíbené implementace LN. + +## Významné změny v kódu a dokumentaci + +*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] a [Lightning BOLTs][bolts repo].* + +- [Bitcoin Core #25740][] umožňuje uzlu používajícímu [assumeUTXO][topic assumeutxo] + ověrit všechny bloky a transakce v blockchainu až do stavu, o kterém + assumeUTXO tvrdí, že jím byl vygenerován. Zároveň s ověřováním se buduje + množina UTXO (chainstate). Je-li chainstate roven stavu + assumeUTXO staženému během prvního spuštění, je stav plně validován. + Uzel validuje každý blok v blockchainu, stejně jako jiné plné uzly, však + v jiném pořadí. Tento zvláštní chainstate, sloužící k ověření starších + bloků, je smazán při následném spuštění uzlu a diskový prostor je uvolněn. + Je potřeba do kódu začlenit ještě několik jiných částí [projektu][assumeUTXO project], + než bude použitelný. + +{% include references.md %} +{% include linkers/issues.md v=2 issues="25740" %} +[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://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-22-newsletter.md b/_posts/cs/newsletters/2023-03-22-newsletter.md new file mode 100644 index 0000000000..06efcd787a --- /dev/null +++ b/_posts/cs/newsletters/2023-03-22-newsletter.md @@ -0,0 +1,120 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 243' +permalink: /cs/newsletters/2023/03/22/ +name: 2023-03-22-newsletter-cs +slug: 2023-03-22-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme naše pravidelné rubriky s popisem změn ve službách +a klientech a souhrnem významných změn populárních bitcoinových páteřních +projektů. + +## Novinky + +*Tento týden se v emailových skupinách Bitcoin-Dev a +Lightning-Dev neobjevily žádné významné novinky.* + +## 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.* + +- **Banka Xapo podporuje Lightning:** + Banka Xapo [oznámila][xapo lightning blog] svým zákazníkům, že nyní mohou odesílat + lightningové platby z aplikace mobilního bankovnictví. Banka používá infrastrukturu + od Lightspark. + +- **Vydána typescriptová knihovna pro práci s deskriptory miniscriptu:** + [Bitcoin Descriptors Library][github descriptors library] založená na TypeScriptu + podporuje [PSBT][topic psbt], [deskriptory][topic descriptors] a [miniscript][topic miniscript], + včetně podpory pro přímé podepisování a podepisování pomocí některého hardware. + +- **Oznámeno Breez Lightning SDK:** + V nedávném [blogovém příspěvku][breez blog] oznámil Breez vydání open source + [Breez SDK][github breez sdk] pro mobilní vývojáře, kteří chtějí integrovat + bitcoinové a lightningové platby. SDK také podporuje [Greenlight][blockstream + greenlight], možnosti poskytovatelů lightningových služeb (LSP) a další + funkce. + +- **Spuštěna směnárna OpenOrdex založená na PSBT:** + [Open source][github openordex] software směnárny umožňuje prodávajícím vytvářet + knihu objednávek Ordinal satoshi pomocí [PSBT][topic psbt] a kupujícím + je podepisovat a odesílat. + +- **Vydán coinjoin plugin pro BTCPay Server:** + Wasabi Wallet [oznámila][wasabi blog], že kterýkoliv obchodník používající BTCPay Server + může tento plugin aktivovat. Podporuje [coinjoinový][topic coinjoin] protokol + [WabiSabi][news102 wabisabi]. + +- **Prohlížeč mempool.space vylepšuje podporu CPFP:** + [Prohlížeč][topic block explorers] mempool.space oznámil [rozšířenou podporu][mempool + tweet] transakcí využívající [CPFP][topic cpfp]. + +- **Vydán Sparrow v1.7.3:** + [Vydání v1.7.3][sparrow v1.7.3] peněženky Sparrow obsahuje mimo jiné podporu pro multisig + peněženky podle [BIP129][] (viz [zpravodaj č. 136][news136 bsms], *angl.*) a nastavitelný + prohlížeč bloků. + +- **Stack Wallet přidává výběr mincí a BIP47:** + Nedávné vydání [Stack Wallet][github stack wallet] přidává [výběr mincí][topic + coin selection] a podporu [BIP47][]. + +- **Vydána Wasabi Wallet v2.0.3:** + [Vydání v2.0.3][Wasabi v2.0.3] peněženky Wasabi obsahuje podepisování taprootových + coinjoinů a podporu taprootových drobných, volitelný výběr mincí pro odesílání, + zrychlené spouštění a další novinky. + +## 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.16.0-beta.rc3][] je kandidátem na vydání nové hlavní verze této oblíbené + implementace LN. + +## Významné změny v kódu a dokumentaci + +*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] a [Lightning BOLTs][bolts repo].* + +- [LND #7448][] přidává nové rozhraní pro opakované odesílání nepotvrzených + transakcí, zejména takových, které byly vyloučeny z mempoolů. Je-li toto + rozhraní aktivované, bude odesílat nepotvrzené transakce pomocí připojeného + plného uzlu jednou za blok až do úspěšného potvrzení. LND již dříve opakovaně + odesílalo transakce podobným způsobem, avšak pouze v režimu Neutrino. + Jak bylo poznamenáno v Stack Exchange Q&A, [Bitcoin Core v současnosti + transakce opakovaně neodesílá][no rebroadcast], ač by bylo žádoucí z + důvodu spolehlivosti a bezpečnosti, kdyby plný uzel opakovaně odesílal + transakce, které měly být (podle uzlu) začleněny do předchozího bloku. + Mezitím je odpovědností každé peněženky ujistit se o umístění transakce + v mempoolech. + +- [BDK #793][] přináší velkou restrukturalizaci knihovny založené na projektu + [bdk_core][bdk_core sub-project]. Dle popisku PR „zachovává současné API jak + jen je to možné a přidává jen velmi málo.” Tři zjevně menší změny API jsou + popsány v PR. + +{% include references.md %} +{% include linkers/issues.md v=2 issues="7448,793" %} +[lnd v0.16.0-beta.rc3]: https://github.com/lightningnetwork/lnd/releases/tag/v0.16.0-beta.rc3 +[bdk_core sub-project]: https://bitcoindevkit.org/blog/bdk-core-pt1/ +[no rebroadcast]: /en/newsletters/2021/03/31/#will-nodes-with-a-larger-than-default-mempool-retransmit-transactions-that-have-been-dropped-from-smaller-mempools +[xapo lightning blog]: https://www.xapobank.com/blog/another-first-xapo-bank-now-supports-lightning-network-payments +[github descriptors library]: https://github.com/bitcoinerlab/descriptors +[breez blog]: https://medium.com/breez-technology/lightning-for-everyone-in-any-app-lightning-as-a-service-via-the-breez-sdk-41d899057a1d +[github breez sdk]: https://github.com/breez/breez-sdk +[blockstream greenlight]: https://blockstream.com/lightning/greenlight/ +[github openordex]: https://github.com/orenyomtov/openordex +[wasabi blog]: https://blog.wasabiwallet.io/wasabiwalletxbtcpayserver/ +[news102 wabisabi]: /en/newsletters/2020/06/17/#wabisabi-coordinated-coinjoins-with-arbitrary-output-values +[mempool tweet]: https://twitter.com/mempool/status/1630196989370712066 +[news136 bsms]: /en/newsletters/2021/02/17/#securely-setting-up-multisig-wallets +[sparrow v1.7.3]: https://github.com/sparrowwallet/sparrow/releases/tag/1.7.3 +[github stack wallet]: https://github.com/cypherstack/stack_wallet +[Wasabi v2.0.3]: https://github.com/zkSNACKs/WalletWasabi/releases/tag/v2.0.3 diff --git a/_posts/cs/newsletters/2023-03-29-newsletter.md b/_posts/cs/newsletters/2023-03-29-newsletter.md new file mode 100644 index 0000000000..e129cf21f2 --- /dev/null +++ b/_posts/cs/newsletters/2023-03-29-newsletter.md @@ -0,0 +1,359 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 244' +permalink: /cs/newsletters/2023/03/29/ +name: 2023-03-29-newsletter-cs +slug: 2023-03-29-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme popis návrhu na zlepšení efektivity nakládání +s kapitálem v LN použitím nastavitelných pokut. Též nechybí naše pravidelné +rubriky se souhrnem zajímavých otázek a odpovědí z Bitcoin Stack Exchange, +oznámeními o nových vydáních a popisem významných změn v populárních +bitcoinových páteřních projektech. + +{% assign S0 = "_S0_" %} +{% assign S1 = "_S1_" %} + +## Novinky + +- **Jak předejít uvíznutí kapitálu pomocí kanálů s více stranami a továrnami kanálů:** + John Law [zaslal][law stranded post] do emailové skupiny Lightning-Dev + souhrn [studie][law stranded paper], jejíž je autorem. Popisuje, jak mohou + vždy dostupné uzly přeposílat platby, i když sdílejí kanál s uzlem, který + je momentálně nedostupný (např. mobilní LN peněženka). Je pro to potřeba + používat kanály s více stranami („multiparty channels”), které jsou kompatibilní + s návrhem na továrny kanálů („channel factories”), který Law dříve představil. + Také připomněl jednu známou výhodu [továren kanálů][topic channel factories]: + umožňují offchain rebalancování kanálů (tj. bez nutnosti publikovat na + blockchainu transakci), a tedy efektivnější nakládání s kapitálem. Law popisuje, + jak využít obou výhod v kontextu svého dalšího návrhu _nastavitelných pokut_ v LN. + V další části shrneme nastavitelné pokuty, ukážeme, jak mohou být využiti pro + kanály s více stranami a továrnami kanálů, a vysvětlíme Lawovy závěry. + + Alice a Bob vytvoří (prozatím nepodepsanou) transakci, která od každého utrácí + 50 miliónů sat (dohromady 100 miliónů) na výstup otevírací („funding”) transakce, + který bude pro utracení vyžadovat spolupráci obou stran. V následujících diagramech + jsou potvrzené transakce zobrazeny s šedým pozadím. + + {:.center} + ![Alice a Bob vytváří otevírací transakci](/img/posts/2023-03-tunable-funding.dot.png) + + Dále každý z nich použije odlišný výstup (který sami kontrolují) k vytvoření své + _stavové transakce_ („state transaction”), kterou prozatím nepublikují. První výstup + každé stavové transakce zaplatí nízkou částku (např. tisíc sat) jako vstup offchainové + _commitment transakce_ s časovým zámkem. Relativní časový zámek neumožní commitment + transakcím potvrzení na blockchainu, dokud neuběhne určitá doba od potvrzení své + rodičovské stavové transakce. Každá z obou commitment transakcí navíc utrácí shodný + výstup otevírací transakce, což umožní potvrzení pouze jedné z nich. Jakmile jsou + všechny transakce vytvořeny, otevírací transakce může být podepsána a publikována. + + {:.center} + ![Alice a Bob vytváří své commitment transakce](/img/posts/2023-03-tunable-commitment.dot.png) + + Každá z commitment transakcí utrácí aktuální stav kanálu. Ve výchozím stavu + ({{S0}}) vrátí Alici a Bobovi po 50 miliónech sat (pro jednoduchost neuvažujeme + poplatky). Alice a Bob mohou započít proces jednostranného uzavření kanálu + zveřejněním své verze stavové transakce a po nezbytné prodlevě mohou publikovat + odpovídající commitment transakci. Na příkladu Alice zveřejňuje svou stavovou a + commitment transakci (která platí jí i Bobovi). Bob po tomto okamžiku svou + stavovou transakci již zveřejňovat nebude a namísto toho může prostředky + utratit podle libovůle. + + {:.center} + ![Alice utrácí prostředky kanálu](/img/posts/2023-03-tunable-honest-spend.dot.png) + + K jednostrannému uzavření kanálu za výchozího stavu existují dvě alternativy. + V první řadě mohou Alice a Bob spolupracovat na uzavření kanálu utracením otevírací + transakce, jak se děje běžně v současném LN protokolu. Ve druhém případě mohou + aktualizovat svůj stav: například navýšením Alicina zůstatku o 10 miliónů sat + a snížením Bobova zůstatku o stejnou sumu. Stav {{S1}} je podobný výchozímu stavu + {{S0}}, avšak aby byl použitelný, musí každá strana anulovat předchozí stav tím, + že pošle protistraně witness[^keychain] pro utracení prvního výstupu stavové transakce + odpovídající předchozímu stavu {{S0}}. Ani jedna ze stran nemůže použít witness + protistrany, protože stavové transakce stavu {{S0}} ještě neobsahují witness a nemohou + tedy být publikovány. + + Existuje-li vícero stavů, je možné nedopatřením či úmyslně zavřít kanál + v neplatném stavu. Například se může Bob pokusit zavřít kanál ve stavu {{S0}}, + kde měl o 10 miliónů sat více, podepsáním a zveřejněním své stavové transakce + stavu {{S0}}. Bob však kvůli časovému zámku v commitment transakci musí čekat + určitou dobu, během které má Alice možnost jeho nekalý pokus odhalit a zabránit + mu použitím witnessu, který předtím od Boba obdržela. Prostředky ve stavové transakci + (tj. pokuta) budou zcela či částečně použity k platbě poplatků. Jelikož je tento výstup + totožný s výstupem, který musí Bob později použít ke zveřejnění commitment transakce + platící mu 10 miliónů sat navíc, nebude Bob moci si tyto prostředky nárokovat. + Jelikož bude v tento okamžik Bob blokován, může pouze Alice jednostranně zveřejnit + poslední stav na blockchain. I tehdy však můžou oba začít spolupracovat na + řádném zavření kanálu. + + {:.center} + ![Bob se pokouší podloudně utratit prostředky kanálu, je však Alicí zastaven](/img/posts/2023-03-tunable-dishonest-spend.dot.png) + + Všimne-li si Bob, že se Alice pokouší utratit z jeho předchozí stavové transakce, + může se pokusit vstoupit s Alicí do bitvy o RBF (nahrazení transakce vyšším + poplatkem), avšak zde se obzvláště ukáže výhoda _nastavitelnosti_ výše pokuty: + částka pokuty může být nízká (např. tisíc sat jako v našem příkladu), může + se rovnat sporné částce (10 miliónů sat) nebo převýšit hodnotu samotného kanálu. + Rozhodnutí, ke kterému dospějí během aktualizace stavu kanálu, je zcela na Alici a + Bobovi. + + Další výhoda protokolu s nastavitelnou pokutou (TPP, „Tunable-Penalty Protocol”) + spočívá ve skutečnosti, že pokuta je zcela placena uživatelem, který se pokouší + zveřejnit neplatnou stavovou transakci. Nepoužívají se k tomuto účelu žádné + prostředky z otevírací transakce. To umožňuje sdílení TPP kanálu více uživateli. + Například si můžeme představit, že Alice, Bob, Carol a Dan sdílí takový kanál + a každý z nich drží svou vlastní commitment transakci utrácející jejich vlastní + stavovou transakci: + + {:.center} + ![Kanál sdílený Alicí, Bobem, Carol a Danem](/img/posts/2023-03-tunable-multiparty.dot.png) + + Mohou jej provozovat jako kanál s více stranami, který vyžaduje, aby byl + kažý stav anulován každým účastníkem. Jinou možností je použití společné + otevírací transakce jako továrny kanálů a otevření několika kanálů mezi + skupinami uživatelů. Před tím, než loni Law představil tento důsledek TPP + (viz [zpravodaj č. 230][news230 tp]), se věřilo, že praktická implementace + továrny kanálů nad bitcoinem by vyžadovala nějaký mechanismus jako [eltoo][topic + eltoo] (který je podmíněn změnou konsenzu jako např. [SIGHASH_ANYPREVOUT][topic + sighash_anyprevout]). TPP nevyžaduje žádnou změnu konsenzu. Následující diagram + zobrazuje jediný kanál vytvořený továrnou se čtyřmi účastníky. Počet stavů, + který musí účastníci spravovat, se rovná počtu účastníků v továrně, i když + Law již [dříve popsal][law factories] alternativní schéma s jediným stavem + ale vyššími náklady na jednostranné zavření. + + {:.center} + ![Kanál mezi Alicí a Bobem vytořený z továrny s Alicí, Bobem, Carol a Danem](/img/posts/2023-03-tunable-factory.dot.png) + + Výhodou továren kanálů, jak byly popsány [v původním článku][channel factories + paper], je možnost účastníků v rámci továrny kooperativně rebalancovat své + kanály bez nutnosti vytvářet transakce na blockchainu. Mějme například + továrnu s účastníky Alicí, Bobem, Carol a Danem. Potom může být celková + hodnota kanálu mezi Alicí a Bobem snížena a hodnota kanálu mezi Carol a Danem + může být zvýšena o stejnou částku aktualizací offchain stavu továrny. + Lawovy továrny založené na TPP nabízí stejnou výhodu. + + Tento týden Law poznamenal, že továrny se schopností poskytovat kanály + s více účastníky (které jsou s TPP možné) mají ještě jednu výhodu: + umožňují používat kapitál, i když je jedna ze stran kanálu nedostupná. + Představme si například, že Alice a Bob mají vyčleněné LN uzly, které + jsou téměř vždy dostupné a schopné přeposílat platby, ale Carol a Dan + jsou běžní uživatelé, jejichž uzly jsou často nedostupné. Dle původního + návrhu továren má Alice kanál s Carol ({A,C}) a Danem ({A,D}). Alice + ale nemůže použít žádné prostředky těchto dvou kanálů, jsou-li Carol + a Dan nedostupní. Bob má stejný problém ({B,C} a {B,D}). + + V případě továrny založené na TPP mohou Alice, Bob a Carol spolu otevřít kanál + s více stranami, což bude během aktualizace stavu vyžadovat spolupráci všech tří. + Jeden z výstupů commitment transakce tohoto kanálu posílá prostředky Carol, + ale druhý výstup může být utracen jen, když Alice a Bob spolupracují. Je-li + Carol nedostupná, Alice a Bob mohou offline kooperativně změnit distribuci zůstatku + jejich společného výstupu, což jim umožní vytvářet nebo přeposílat LN platby, + pokud mají otevřené i jiné kanály. Zůstává-li Carol nedostupná příliš dlouho, + může kdokoliv z nich jednostranně kanál uzavřít. Stejné výhody existují, + i když Alice a Bob sdílí kanál s Danem. + + Alici a Bobovi to umožňuje vydělávat na poplatcích, i když jsou Carol a + Dan nedostupní. Schopnost rebalancovat kanály offchain odstraňuje Alici a Bobovi + některé nevýhody spojené s držením prostředků v továrně kanálu po delší dobu. + Tyto výhody mohou dohromady snížit počet transakcí na blockchainu, zvýšit + kapacitu bitcoinové sítě a snížit náklady na přeposílání plateb po LN. + + V době psaní zpravodaje neobdržely nastavitelné pokuty a další Lawovy + návrhy mnoho reakcí. + +## 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/" %} + +- [Proč není v Bitcoin Core nasazení taprootu trvale usazeno?]({{bse}}117569) + Andrew Chow vysvětluje důvody, proč není [nasazení][topic soft fork activation] + soft forku taprootu trvale [usazeno][BIP90] („buried”), jako v případě + [jiných soft forků][bitcoin buried deployments]. + +- [Jaká omezení má hodnota verze v hlavičce bloku?]({{bse}}117530) + Murch poukazuje na nárůst [bloků][explorer block 779960] vytěžených použitím + [otevřeného ASICBoostu][topic ASICBoost], vyjmenovává omezení hodnoty verze + a prochází několika příklady [verzí hlavičky bloku][FCAT block header blog]. + +- [Jaký je vztah mezi daty transakce a jejími identifikátory?]({{bse}}117453) + Pieter Wuille vysvětluje zastaralý serializační formát transakce (identifikátor + `txid`), serializační formát rozšířený o witnessy (`hash` a `wtxid`) + a v [separátní odpovědi][se117577] poznamenává, že přidaná hypotetická + data by spadala pod identifikátor `hash`. + +- [Mohu od ostatních spojení obdržet jednotlivé transakce?]({{bse}}117546) + Uživatel RedGrittyBrick poukazuje na zdroje vysvětlující důvody – + [výkonnost][wiki getdata] a [soukromí][Bitcoin Core #18861] – stojící + za nemožností vyžádat si pomocí Bitcoin Core od spojení konkrétní transakce. + +- [Eltoo: Určuje časový zámek prvního UTXO životnost kanálu?]({{bse}}117468) + Murch potvrzuje, že příklad [eltoo][topic eltoo] kanálu obsažený v otázce + má omezenou životnost a odkazuje na [eltoo whitepaper][], který uvádí možnosti, + jak expiracím zamezit. + +## 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.* + +- [Rust Bitcoin 0.30.0][] je posledním vydání této knihovny nabízející + datové struktury pro práci s bitcoinem. [Poznámky k vydání][rb rn] + zmiňují [novou webovou stránku][rust-bitcoin.org] a velké množství + změn API. + +- [LND v0.16.0-beta.rc5][] je kandidátem na vydání nové hlavní verze + této oblíbené implementace LN. + +- [BDK 1.0.0-alpha.0][] je zkušebním vydáním významných změn BDK + popsaných v [minulém vydání zpravodaje][news243 bdk]. Vývojáři + projektů používajících BDK jsou vyzváni, aby započali s testováním + integrace. + +## Významné změny v kódu a dokumentaci + +*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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Bitcoin Core #27278][] přidává ve výchozím stavu logování + obdržených hlaviček nových bloků (pokud neprobíhá prvotní stahování). + Tato změna byla [inspirována][obeirne selfish] několika provozovateli + uzlů, kteří si všimli tří bloků obdržených ve velmi těsné blízkosti. + Poslední dva z těchto bloků způsobily reorganizaci blockchainu a + tím z něj odstranily první blok. Nazývejme první blok _A_, jeho + náhradu _A'_ a poslední blok _B_. + + Tato situace naznačuje, že bloky A' a B byly vytvořeny jedním + těžařem, který záměrně pozdržel jejich zveřejnění do doby, kdy + byl blok jiného těžaře reorganizací zneplatněn, a tím mu tak odepřel + odměnu, kterou by jinak za A obdržel. Tento druh útoku se nazývá + _sobecká těžba_ („selfish mining”). Mohlo by se ale také jednat pouze o náhodu. + Nicméně jinou možností, na kterou během vyšetřování [poukázali][sanders requests] + vývojáři, je, že časy možná nebyly tak blízko, jak se původně zdálo. + Je možné, že Bitcoin Core si vyžádal A' až po obdržení B, jelikož + blok A' samotný by reorganizaci nespustil. + + Logování času přijetí hlaviček znamená, že pokud by se podobná + situace znovu opakovala, mohli by provozovatelé uzlu určit, kdy se + jejich uzel poprvé dozvěděl o existenci bloku A', i když se rozhodl jej + zatím nestáhnout. Toto logování může přidat až dva řádky na blok + (i když budoucí PR je může omezit na jediný řádek), což se považuje + za přijatelné množství, může-li to pomoci odhalit sobeckou těžbu a + jiné související problémy. + +- [Bitcoin Core #26531][] přidává trasovací body pro monitorování + událostí ovlivňující mempool použitím Extended Berkeley Packet Filter + (eBPF), jehož podpora byla přidaná dříve (viz [zpravodaj č. 133][news133 + usdt], *angl.*). Též byl přidán skript, který tyto trasovací body + umí v reálném čase využít pro tvorbu statistiky a monitorování aktivity + mempoolu. + +- [Core Lightning #5898][] aktualizuje svou závislost na [libwally][] + (viz [zpravodaj č. 238][news238 libwally]), která umožnila přidání + podpory pro [taproot][topic taproot], [PSBT][topic psbt] verze 2 + (viz [zpravodaj č. 128][news128 psbt2], *angl.*) a má dopad na + podporu sidechainů ve stylu Elements. + +- [Core Lightning #5986][] upravuje RPC volání vracející hodnoty + v jednotkách msat: tato volání již nebudou ve výsledku obsahovat + řetězec „msat”. Namísto toho budou všechny výsledky číselné. + Tato změna značí konec procesu zastarání, který začal před několika + vydáními, viz [zpravodaj č. 206][news206 msat] (*angl.*). + +- [Eclair #2616][] přidává podporu pro příležitostné [zero-conf + kanály][topic zero-conf channels]. Pošle-li protistrana zprávu + `channel_ready` ještě před očekávaným počtem konfirmací, + Eclair ověří, že byla otevírací transakce zcela vytvořena sebou + samým (aby nemohla protistrana zveřejnit konfliktní transakci) + a následně umožní kanál používat. + +- [LDK #2024][] přináší začleňování návrhů tras („route hints”) pro kanály, + které byly již otevřeny, ale ještě nebyly veřejně oznámeny, jako jsou + např. [zero-conf kanály][topic zero-conf channels]. + +- [Rust Bitcoin #1737][] přidává do projektu [pravidla pro bezpečnostní + reportování][rb sec]. + +- [BTCPay Server #4608][] umožňuje pluginům zpřístupnit své funkce jako + aplikace v rozhraní BTCPay. + +- [BIPs #1425][] přisuzuje číslo [BIP93][] schématu codex32 pro kódování + obnovy seedu podle [BIP32][]. Schéma používá Shamirovo schéma sdílení + tajných dat (SSSS), kontrolní součet a 32znakovou abecedu. Vše bylo + popsáno ve [zpravodaji č. 239][news239 codex32]. + +- [Bitcoin Inquisition #22][] přidává runtime volbu `-annexcarrier`, + která umožní nastavit 0 až 126 bytů dat pro pole annex taprootového + vstupu. Autor PR plánuje tuto volbu využít pro umožnění experimentů + s [eltoo][topic eltoo] (na signetu) za použití forku Core Lightning. + +## Poznámky + +[^keychain]: + V tomto náhledu není důležité popisovat obsah witnessu, ale některé + z uvedených výhod na těchto detailech závisí. Původní protol [nastavitelných + pokut][Tunable Penalties] navrhuje zveřejnit tajný klíč použitý k + vygenerování podpisu utracení commitment transakce. Je možné vygenerovat + tajné klíče sekvenčně tak, aby každý, kdo zná jeden klíč, mohl také + odvodit následující klíče (ale ne předchozí). To znamená, že vždy, + když Alice revokuje pozdější stav, může dát Bobovi dřívější klíč, který + může Bob použít k odvození jakéhokoliv pozdějšího klíče (pro dřívější + stav). Příklad: + + | Stav kanálu | Stav klíče | + | 0 | MAX | + | 1 | MAX - 1 | + | 2 | MAX - 2 | + | x | MAX - x | + | MAX | 0 | + + Toto Bobovi umožňuje efektivně ukládat všechny informace, které potřebuje + k utracení již neplatné stavové transakce (podle našich výpočtů méně + než 100 bytů). Tyto informace můžou být snadno sdílené se [strážními + věžemi][topic watchtowers] („watchtowers”). Ty nevyžadují důvěru, jelikož + každé úspěšné utracení zastaralé stavové transakce zabrání publikování + zastaralé commitment transakce. Jelikož patří všechny prostředky v této + zastaralé stavové transakci straně, která porušuje protokol, nepřináší + sdílení informací o jejím utrácení žádné bezpečnostní riziko. + +{% include references.md %} +{% include linkers/issues.md v=2 issues="27278,26531,5898,5986,2616,2024,1737,4608,1425,22,18861" %} +[lnd v0.16.0-beta.rc5]: https://github.com/lightningnetwork/lnd/releases/tag/v0.16.0-beta.rc5 +[bdk 1.0.0-alpha.0]: https://github.com/bitcoindevkit/bdk/releases/tag/v1.0.0-alpha.0 +[rust bitcoin 0.30.0]: https://github.com/rust-bitcoin/rust-bitcoin/releases/tag/bitcoin-0.30.0 +[news230 tp]: /cs/newsletters/2022/12/14/#navrh-na-ln-protokol-pro-tovarny +[channel factories paper]: https://tik-old.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks.pdf +[law factories]: https://raw.githubusercontent.com/JohnLaw2/ln-efficient-factories/main/efficientfactories10.pdf +[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://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 +[news133 usdt]: /en/newsletters/2021/01/27/#bitcoin-core-19866 +[libwally]: https://github.com/ElementsProject/libwally-core +[news128 psbt2]: /en/newsletters/2020/12/16/#new-psbt-version-proposed +[tunable penalties]: https://github.com/JohnLaw2/ln-tunable-penalties +[news238 libwally]: /cs/newsletters/2023/02/15/#vydana-libwally-0-8-8 +[rust-bitcoin.org]: https://rust-bitcoin.org/ +[rb rn]: https://github.com/rust-bitcoin/rust-bitcoin/blob/master/bitcoin/CHANGELOG.md#030---2023-03-21-the-first-crate-smashing-release +[news243 bdk]: /cs/newsletters/2023/03/22/#bdk-793 +[bitcoin buried deployments]: https://github.com/bitcoin/bitcoin/blob/master/src/consensus/params.h#L19 +[explorer block 779960]: https://blockstream.info/block/00000000000000000003a337a676b0101f3f7ef7dcbc01debb69f85c6da04dcf?expand +[FCAT block header blog]: https://medium.com/fcats-blockchain-incubator/understanding-the-bitcoin-blockchain-header-a2b0db06b515#b9ba +[se117577]: https://bitcoin.stackexchange.com/a/117577/87121 +[wiki getdata]: https://en.bitcoin.it/wiki/Protocol_documentation#getdata +[eltoo whitepaper]: https://blockstream.com/eltoo.pdf#page=15 diff --git a/_posts/cs/newsletters/2023-04-05-newsletter.md b/_posts/cs/newsletters/2023-04-05-newsletter.md new file mode 100644 index 0000000000..78b2d39177 --- /dev/null +++ b/_posts/cs/newsletters/2023-04-05-newsletter.md @@ -0,0 +1,136 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 245' +permalink: /cs/newsletters/2023/04/05/ +name: 2023-04-05-newsletter-cs +slug: 2023-04-05-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme popis nápadu na nakládání se zodpovědností strážních +věží a připojujeme naše pravidelné rubriky s oznámeními o vydání nových verzí a +popisem významných změn v populárních bitcoinových páteřních projektech. + +## Novinky + +- **Zodpovědnost strážních věží:** Sergi Delgado Segura + [zaslal][segura watchtowers post] minulý týden do emailové skupiny + Lightning-Dev příspěvek o způsobech, kterými by [strážní věže][topic watchtowers] + („watchtowers”) nesly zodpovědnost za selhání zabránit pokusům + o narušení protokolu. Příklad: Alice poskytne strážní věži data pro + detekci a zabránění potvrzení neplatného stavu LN kanálu. Později + je tento neplatný stav potvrzen, ale strážní věž nereaguje. Alice + by chtěla, aby měla možnost toto selhání veřejně prokázat a tím vedla + strážní věž k zodpovědnosti. + + Nejjednodušším řešením by bylo, aby měla strážní věž všeobecně známý veřejný + klíč, jehož soukromý klíč by generoval podpisy akceptovaných podkladů pro + detekci narušení. V případě selhání strážní věže zabránit narušení protokolu + 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. + + - *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ě + prokázat, že určitý prvek je součástí velké množiny prvků a nevyžadují + po každém vložení nového prvku přepočítání celé datové struktury. Některé + akumulátory umožňují i smazání prvků bez přepočítání. Delgado v [gistu][segura + watchtowers gist] nastiňuje konstrukci několika možných akumulátorů. + +## 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.16.0-beta][] je beta verzí nové hlavní verze této populární + implementace LN. [Poznámky k vydání][lnd rn] zmiňují množství nových + funkcí, oprav chyb a zlepšení výkonu. + +- [BDK 1.0.0-alpha.0][] je testovacím vydáním velkých změn přicházejících + do BDK popsaných ve [zpravodaji č. 243][news243 bdk]. Vývojáři + projektů používajících BDK jsou vyzváni, aby započali s testováním + integrace. + +## Významné změny v kódu a dokumentaci + +*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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Core Lightning #5967][] přidává RPC volání `listclosedchannels`, které poskytuje + data o uzavřených kanálech včetně důvodu zavření. Informace o dřívějších + spojeních se nyní též ukládají. + +- [Eclair #2566][] přidává podporu pro přijímání nabídek. Nabídky musí + být registrovány pluginem, který poskytuje handler reagující na + žádosti o faktury spojené s těmito nabídkami a přijímající platby. + Eclair zajišťuje, že požadavky a platby jsou v souladu s protokolem, + handler musí jen rozhodnout, zda produkty či služby mohou být poskytnuty. + Díky tomu může být odbavování nabídek libovolně komplexní, aniž + by mělo dopad na vnitřní logiku Eclairu. + +- [LDK #2062][] implementuje [BOLT #1031][bolts #1031] (viz [zpravodaj + č. 226][news226 bolts1031], *angl.*), [#1032][bolts #1032] (viz + [zpravodaj č. 225][news225 bolts1032], *angl.*) a [#1040][bolts #1040], + které umožňují konečnému příjemci platby ([HTLC][topic htlc]) akceptovat + větší částku a delší expirační lhůtu, než které byly požadovány. Snižuje + to schopnost přeposílajícího uzlu určit použitím drobných úprav parametrů, + zda je následující uzel v trase konečným příjemcem. Díky této změně může také + plátce zaslat příjemci mírně vyšší částku v případě používání [zjednodušených + plateb s více cestami][topic multipath payments]. To může být nutné v případech, + kdy zvolená trasa využívá kanály požadující minimální částku. Příklad: Alice + chce rozdělit platbu ve výši 900 sat na dvě části, ale obě jí zvolené cesty + požadují pro přeposlání minimálně 500 sat. Po této změně specifikace může + odeslat dvě 500sat platby, a tedy přeplatit 100 sat za možnost použít jí + preferovanou trasu. + +- [LDK #2125][] přidává pomocné funkce pro určení času zbývajícího do + expirace faktury. + +- [BTCPay Server #4826][] umožňuje, aby service hooks mohly vytvářet a + přijímat [LNURL][] faktury. Důvodem změny bylo přidání podpory pro + NIP-57 „zap” do BTCPay Server. + +- [BTCPay Server #4782][] přidává na účtenku [důkaz][topic proof of payment] + o proběhlé platbě. Pro onchain platby je důkazem ID transakce, + pro LN platby předobraz [HTLC][topic htlc]. + +- [BTCPay Server #4799][] přidává možnost exportovat [štítky][topic + wallet labels] transakcí ve formátu specifikovaném v [BIP329][]. Budoucí + PR může přidat podporu pro export i jiných druhů štítků, např. adres. + +- [BOLTs #765][] přidává do LN specifikace [zaslepení tras][topic rv routing], + které bylo poprvé popsáno ve [zpravodaji č. 85][news85 blinding] (*angl.*). + Umožňuje uzlu přijmout platbu nebo [onion zprávu][topic onion messages] + bez nutnosti odhalit odesílateli či plátci svůj identifikátor či jakoukoliv + jinou informaci vedoucí k jeho identifikaci. Zaslepená trasa umožňuje + příjemci zvolit si několik posledních uzlů, přes které bude platba nebo + zpráva směrována. Ty jsou zašifrované stejným způsobem jako běžné trasovací + informace. Zaslepená trasa je poskytnuta plátci nebo odesílateli, který odešle + platbu na její první uzel. Ten data odšifruje a pokračuje v přeposílání směrem + k příjemci. Během procesu se odesílatel nedozví informace o cílovém uzlu. + +{% include references.md %} +{% 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://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 +[news225 bolts1032]: /en/newsletters/2022/11/09/#bolts-1032 +[news243 bdk]: /cs/newsletters/2023/03/22/#bdk-793 +[lnd rn]: https://github.com/lightningnetwork/lnd/blob/master/docs/release-notes/release-notes-0.16.0.md +[lnurl]: https://github.com/lnurl/luds diff --git a/_posts/cs/newsletters/2023-04-12-newsletter.md b/_posts/cs/newsletters/2023-04-12-newsletter.md new file mode 100644 index 0000000000..6a1ff9ccda --- /dev/null +++ b/_posts/cs/newsletters/2023-04-12-newsletter.md @@ -0,0 +1,206 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 246' +permalink: /cs/newsletters/2023/04/12/ +name: 2023-04-12-newsletter-cs +slug: 2023-04-12-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme popis diskuze o LN splicingu a odkazujeme na +návrh BIP pro doporučenou terminologii v rámci transakcí. Též nechybí +naše pravidelné rubriky se souhrnem sezení Bitcoin Core PR Review Club, +oznámeními o vydáních, včetně bezpečnostní aktualizace libsecp256k1, +a popisem významných změn v populárních páteřních bitcoinových +projektech. + +## Novinky + +- **Diskuze o specifikaci splicingu:** několik vývojářů LN informovalo + tento týden emailovou skupinu Lightning-Dev o pokračující práci na + [návrhu specifikace][bolts #863] [splicingu][topic splicing], díky + kterému je možné utratit část prostředků LN kanálu na blockchainu + (splice-out) či prostředky z blockchainu přidat do LN kanálu + (splice-in). Kanál může během čekání na dostatečné množství konfirmací + splicingové transakce nadále fungovat bez přerušení. + + Na následujícím diagramu jsou šedě označeny potvrzené transakce a + přerušovanou čarou transakce, které prozatím zůstávají offchain. + + {:.center} + ![Splicing transaction flow](/img/posts/2023-04-splicing1.dot.png) + + Některé z diskuzí: + + - *Které podpisy commitmentů mají být poslány:* po vytvoření splicu + bude uzel držet paralelní commitment transakce; jedna utrácí + původní otvírací výstup a druhá utrácí každý nový otvírací výstup + všech nevyřízených spliců. Během každé změny stavu kanálu musí + být aktualizovány také všechny paralelní commitment transakce. + Jednoduchým způsobem by bylo rozeslat stejnou zprávu – která by + byla jinak určená samotné commitment transakci – také všem paralelním + commitment transakcím. + + Původní návrh specifikace splicingu (viz zpravodaje [č. 17][news17 splice] + a [č. 146][news146 splice], *angl.*) obsahoval právě takové řešení. + Avšak jak Lisa Neigut tento týden [vysvětlila][neigut splice], vytvoření + nového splicu vyžaduje podepsání nové odvozené commitment transakce. + V posledním návrhu specifikace vyžaduje každé odeslání podpisu také + poslání podpisů všech aktuálních commitment transakcí. To je však + nadbytečné, neboť podpisy ostatních commitment transakcí již byly + odeslány dříve. Navíc jelikož v současném LN protokolu potvrzují + jednotlivé strany obdržené podpisy zasláním dat pro anulování předchozí + commitment transakce, dochází i zde k opakovanému přenosu stejných dat. + Tato činnost není škodlivá, avšak vyžaduje více přenosové a výpočetní + kapacity. Výhodou je, že provádění stejné operace ve všech případech + zjednodušuje specifikaci a tím i složitost implementace a testování. + + Jinou možností je během vyjednávání o splicu posílat pouze nezbytné minimum + podpisů a potvrzení přijetí. I přes přidanou složitost se jedná o mnohem + efektivnější řešení. Je dobré míti na paměti, že LN uzly musí držet + paralelní commitment transakce pouze do získání dostatečného + množství konfirmací splicingové transakce. + + - *Relativní částky a splicing bez konfirmací:* Bastien Teinturier + [zaslal][teinturier splice] příspěvek s několika návrhy změn specifikace. + Kromě výše uvedené změny podpisů commitmentů též doporučuje, aby + výzva ke splicingu používala relativní částky, např. „200 000 sat” + pro přidání částky do kanálu (splice-in) nebo „−50 000 sat” pro + odeslání z kanálu (splice-out). Teinturier se též bez dalších + podrobností zmínil o svých obavách souvisejících se splicingem bez konfirmací. + +- **Návrh BIPu s terminologií transakcí:** Mark „Murch” Erhardt + [zaslal][erhardt terms] do emailové skupiny Bitcoin-Dev návrh na + [informační BIP][terms bip] s doporučenou nomenklaturou součástí transakcí + a konceptů s nimi spojených. V době psaní tohoto zpravodaje byly všechny + odpovědi souhlasné. + +## 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í.* + +[Nestahuj witnessy pro domněle validní bloky v ořezaném režimu][review club 27050] +je PR od Niklase Göggeho (dergoegge), které zrychluje prvotní stahování bloků tím, že +nebude stahovat witnessy u uzlů nastavených v [ořezaném režimu][docs pruning] a používajících +[assumevalid][docs assume valid] (nastavení, kdy uzel přeskočí validaci některých starých +transakcí). Tato optimalizace byla diskutována v nedávné [otázce na Stack Exchange][se117057]. + +{% include functions/details-list.md + q0="Proč musí uzel, který má nastaven assumevalid ale ne ořezávání, stahovat + witnessy, i když je nebude validovat? Mělo by PR tuto situaci také + řešit?" + a0="Data witnessů jsou potřeba, protože spojení si mohou vyžádat i staré + bloky (uzel nepracuje v ořezaném režimu)." + a0link="https://bitcoincore.reviews/27050#l-31" + + q1="O kolik může být díky tomuto vylepšení snížen datový přenos? Jinými slovy, + jaká je celková velikost všech witnessů až po nějaký nedávný blok, řekněme + 781213?" + a1="110,6 GB, což je zhruba čtvrtina celkového objemu dat. Jeden účastník poznamenal, + že 110 GB je zhruba 10 % jeho měsíčního limitu. Jedná se tedy o významnou + redukci. Účastníci předpověděli ještě větší ušetření, vzhledem k rozšířenému + používání witnessů v poslední době." + a1link="https://bitcoincore.reviews/27050#l-52" + + q2="Může tato změna snížit množství stahovaných dat všech bloků?" + a2="Ne, pouze od aktivace segwitu (výška 481824). Předchozí bloky + neměly witnessy." + a2link="https://bitcoincore.reviews/27050#l-73" + + q3="Toto PR implementuje dvě hlavní změny: logiky požadavků na bloky + a validace bloků. V čem tyto změny spočívají?" + a3="Je-li během validace přeskočeno ověření skriptu, je též přeskočeno ověření + Merkleova stromu witnessů. V logice požadavků na bloky je vyňat příznak + `MSG_WITNESS_FLAG`, aby spojení neposílala data witnessů." + a3link="https://bitcoincore.reviews/27050#l-83" + + q4="Před touto změnou byla validace skriptů (během assumevalid) přeskočena, + ale ostatní ověření dat witnessů přeskočena nebyla. Jaká ověření + budou po této změně přeskočena?" + a4="Merkleův kořen coinbasové transakce, velikost witnessů, maximální + počet prvků v zásobníku a váha bloku." + a4link="https://bitcoincore.reviews/27050#l-91" + + q5="Toto PR neobsahuje žádnou změnu kódu pro přeskočení všech nadbytečných + ověření popsaných v předchozí otázce. Jak to tedy funguje?" + a5="Tato ověření se přeskočí vždy, když neexistuje žádný witness. Jelikož + byl segwit soft forkem, dává to smysl. Až do bodu, který považujeme + za validní, tedy v podstatě předstíráme, že jsme předsegwitový uzel." + a5link="https://bitcoincore.reviews/27050#l-117" +%} + +## 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 0.3.1][] je **bezpečnostním vydáním** opravujícím + kód, který by měl běžet v konstantním čase, ale neběžel, když byl + použit Clang 14 nebo vyšší. Tato zranitelnost mohla umožnit druh + [útoku postranními kanály][topic side channels] spojený s časováním operací. + Autoři doporučují provést aktualizaci. + + +- [BDK 1.0.0-alpha.0][] je testovacím vydáním velkých změn přicházejících + do BDK popsaných ve [zpravodaji č. 243][news243 bdk]. Vývojáři + projektů používajících BDK jsou vyzváni, aby započali s testováním + integrace. + +## Významné změny v kódu a dokumentaci + +*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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Core Lightning #6012][] implementuje několik významných vylepšení v + pythonové knihovně pro psaní pluginů (viz [zpravodaj č, 26][news26 pyln-client], + *angl.*). Díky změnám mohou pluginy lépe pracovat s úložištěm gossip zpráv + a umožňují tak snadnější tvorbu analytických nástrojů. + +- [Core Lightning #6124][] přidává možnost blokovat runy (autorizační tokeny) + pluginu [commando][commando plugin] (umožňující spouštět příkazy na straně + spojení) a udržovat seznam všech run. + +- [Eclair #2607][] přidává nové RPC volání `listreceivedpayments`, které vrací + seznam všech plateb přijatých uzlem. + +- [LND #7437][] přidává podporu souborové zálohy jediného kanálu. + +- [LND #7069][] umožňuje klientům požádat svou [strážní věž][topic watchtowers] + („watchtower”) o ukončení sledování. Tím věž přestane monitorovat + transakce zavírající kanál v neplatném stavu a její nároky na + úložiště a procesor se sníží. + +- [BIPs #1372][] přiřazuje protokolu [MuSig2][topic musig] číslo [BIP327][]. + Protokol lze využít pro vytváření [elektronických podpisů s více + účastníky][topic multisignature], které mají uplatnění v [taprootu][topic taproot] + a jiných systémech používajících [Schnorrovy podpisy][topic schnorr signatures] + dle [BIP340][]. Jak je popsáno v BIPu, mezi výhody patří neinteraktivní + agregace klíčů a nutnost provést pro podpis pouze dvě kola vzájemné komunikace. + Je též možné provést neinteraktivní podepisování, mají-li účastníci určité + nastavení. Protokol nabízí všechny výhody schémat vícenásobných + podpisů, jako jsou významná redukce datové stopy na blockchainu a vylepšení + soukromí pro účastníky i ostatní uživatele sítě. + +{% include references.md %} +{% 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://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 +[news146 splice]: /en/newsletters/2021/04/28/#draft-specification-for-ln-splicing +[libsecp256k1 0.3.1]: https://github.com/bitcoin-core/secp256k1/releases/tag/v0.3.1 +[review club 27050]: https://bitcoincore.reviews/27050 +[docs pruning]: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.11.0.md#block-file-pruning +[docs assume valid]: https://bitcoincore.org/en/2017/03/08/release-0.14.0/#assumed-valid-blocks +[se117057]: https://bitcoin.stackexchange.com/questions/117057/why-is-witness-data-downloaded-during-ibd-in-prune-mode +[commando plugin]: /en/newsletters/2022/07/27/#core-lightning-5370 diff --git a/_posts/cs/newsletters/2023-04-19-newsletter.md b/_posts/cs/newsletters/2023-04-19-newsletter.md new file mode 100644 index 0000000000..a613c2f797 --- /dev/null +++ b/_posts/cs/newsletters/2023-04-19-newsletter.md @@ -0,0 +1,200 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 247' +permalink: /cs/newsletters/2023/04/19/ +name: 2023-04-19-newsletter-cs +slug: 2023-04-19-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme novinky o vývoji protokolu RGB a naše pravidelné +rubriky se souhrnem změn v klientech a službách, oznámeními +o nových vydáních a popisem významných změn v populárních páteřních +bitcoinových projektech. + +## Novinky + +- **Aktualizace RGB:** Maxim Orlovsky zaslal do emailové skupiny Bitcoin-Dev + [příspěvek][orlovsky rgb] s aktualizací stavu vývoje RGB. RGB je protokol, + který používá bitcoinové transakce k provádění změn stavu offchainových + kontraktů. Jednoduchým příkladem je vytváření a přenos tokenů, avšak RGB + bylo navrženo k širšímu spektru využití, než je transfer tokenů. + + - Alice offchain vytvoří kontrakt, jehož výchozí stav přiřazuje 1 000 + tokenů určitému UTXO, který kontroluje. + + - Bob chce 400 z těchto tokenů. Alice mu dá kopii původního kontraktu + spolu s transakcí, která utrácí její UTXO na nový výstup. Tento + výstup obsahuje neveřejný závazek (commitment) nového stavu + kontraktu. Nový stav kontraktu určuje distribuci prostředků (400 + Bobovi, 600 zpět Alici) a identifikátory dvou výstupů, které budou + kontrolovat tyto prostředky. Alice transakci zveřejní. Bezpečnost + tohoto přenosu tokenů proti dvojímu utracení je nyní shodná s bezpečností + Alicina přenosu bitcoinů, např. má-li její transakce šest konfirmací, + je přenos tokenů zabezpečený proti forku až šesti bloků. + + Výstupy, které kontrolují prostředky, nemusí být výstupy transakce, která + obsahuje commitment (ale mohou být). To narušuje schopnost použít + analýzu transakcí k vystopování přenosů založených na RGB. Tokeny mohly + být přeneseny na existující UTXO, nebo na jakékoliv UTXO, které bude + v budoucnosti existovat (např. předem podepsané utracení ze studené + peněženky, které se ještě roky nemusí na blockchainu objevit). Hodnota + bitcoinů na těchto výstupech a další jejich vlastnosti jsou pro RGB + protokol irelevantní, avšak Alice a Bob se budou chtít ujistit o jejich + snadné utratitelnosti. + + - Později by chtěla Carol koupit 100 tokenů od Boba v rámci atomické + výměny za použití jediné onchainové transakce. Vygeneruje nepodepsané + PSBT, které čerpá prostředky z jejích vstupů, posílá Bobovi bitcoin + v jednom výstupu a vrací jí zbytek ve výstupu druhém. Jeden z těchto + výstupů také zavazuje k příslušným částkám a identifikátorům UTXO, + na které Carol obdrží tokeny a Bob zbytek po přenosu. + + Bob Carol poskytne původní kontrakt a závazek, který předtím Alice + vytvořila, který dokazuje, že Bob vlastní 400 tokenů. Bob nemusí vědět, + jak Alice naložila se zbývajícími 600 tokeny a Alice se výměny mezi + Bobem a Carol vůbec neúčastní, což poskytuje soukromí a škálovatelnost. + Bob přidá do PSBT podpepsaný vstup UTXO, které tokeny kontroluje. + + Carol ověří původní kontrakt a historii předchozích aktualizací stavu. + Též se ujistí, že vše v PSBT je správné. Podepíše a transakci zveřejní. + + I když každý z uvedených transferů byl učiněn na blokchchainu, je jednoduché + protokol upravit pro fungování offchain. Carol poskytne Danovi kopii + kontraktu spolu s historií změn stavu, které ukazují, že obdržela 100 tokenů. + Ve spolupráci s Danem poté vytvoří výstup, který obdrží 100 tokenů a který + k utracení vyžaduje podpisy jich obou. Poté si offchain mohou posílat tokeny tam + a zpět; učiní tak generováním množství rozličných verzí transakce utrácející + onen výstup s vícenásobným podpisem. Každé offchain utracení se zaváže + k distribuci tokenů a identifikátorům výstupů, které tyto tokeny obdrží. + Nakonec jeden z nich zveřejní jednu z utrácejících transakcí, čímž + potvrdí stav na blockchainu. + + Výstupy, kterým byly tokeny přiřazeny, mohou být zatížené bitcoinovým + skriptem, který určí, kdo bude nakonec tokeny kontrolovat. Například + mohou platit [HTLC][topic htlc] skriptu, který dá Carol možnost + utratit tokeny, kdykoliv poskytne předobraz a podpis. Nebo umožní + Danovi utratit tokeny po určité době pouhým podpisem. Díky tomu mohou + být tokeny použity v přeposílaných offchain platbách, například v LN. + + Ve své [odpovědi][tenga rgb] poukázal Federico Tenga na [LN + uzel][rgb-lightning-sample] založený na RGB a forku [LDK][ldk repo] + a jeho [příkladu LN uzlu][ldk-sample]. Zkoumáním tohoto projektu jsme + našli další [užitečné informace][rgb.info ln] o kompatibilitě s LN. + Více informací o RGB protokolu lze nalézt na [webové stránce][rgb.tech] + provozované LNP/BP Association. + + Tento týden oznámil Orlovsky [vydání][rgb blog] RGB v0.10. Tato nová + verze není kompatibilní s kontrakty vytvořenými v předešlých verzích; + není však známa existence žádných RGB kontraktů na mainnetu. Nový design + umožní v případě změn upgrade všech nově vytvořených kontraktů. Vydání + obsahuje množství dalších vylepšení a nastiňuje budoucí vývoj. + + V době psaní tohoto zpravodaje obdrželo oznámení v emailové skupině + jen malé množství reakcí. + +## 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.* + +- **Descriptor wallet library přidává prohlížeč bloků:** + [Descriptor wallet library][] je rustová knihovna postavená na rust-bitcoin + pro peněženky založené na deskriptorech. Podporuje [miniscript][topic miniscript], + [deskriptory][topic descriptors], [PSBT][topic psbt] a díky předchozímu + [vydání][Descriptor Wallet v0.9.2] též textový [prohlížeč bloků][topic block explorers], + který zobrazuje informace o taprootových [control blocích][se107154] z witnessů + a deskriptory a miniscripty odpovídající skriptům v transakci. + +- **Aktualizace referenční implementace protokolu Stratum v2:** + Projekt [zveřejnil detaily][stratum blog] o změnách, mezi které patří + možnost pro těžaře v poolu zvolit transakce pro kandidáta na blok. + Autoři vyzývají těžaře, pooly a vývojáře firmware k testování a poskytnutí + zpětné vazby. + +- **Vydána Liana 0.4:** + Vydání Liany [verze 0.4][liana 0.4] přináší podporu pro obnovu s více možnostmi + a dodatečné deskriptory umožňující větší kvora. + +- **Firmware Coldcardu podporuje další sighash příznaky:** + [Verze 5.1.2 firmware][coldcard firmware] Coldcardu nyní vedle `SIGHASH_ALL` + podporuje všechny ostatní [sighashe][wiki sighash], což rozšíří + možnosti transakcí. + +- **Zeus přidává navýšení poplatku:** + [Zeus v0.7.4][] přidává navýšení poplatku pomocí [RBF][topic rbf] a [CPFP][topic + cpfp]. Navýšit poplatky lze onchainovým transakcím včetně otevíracích a zavíracích + transakcí LN kanálů. Navýšení poplatků lze zatím využít jen s LND backendem. + +- **Oznámen Electrum Server založený na utreexo:** + [Floresta][floresta blog] je server kompatibilní s Electrum protokolem, + který využívá [utreexo][topic utreexo] ke snížení požadavků na zdroje serveru. + Software v současnosti podporuje testovací síť [signet][topic signet]. + +## 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.* + +- [BDK 0.28.0][] je údržbovým vydáním této knihovny pro tvorbu bitcoinových aplikací. + +- [Core Lightning 23.02.2][] je údržbovým vydáním tohoto LN uzlu přinášející + několik oprav chyb. + +- [Core Lightning 23.05rc1][] je kandidátem na vydání příští verze tohoto LN uzlu. + +## Významné změny v kódu a dokumentaci + +*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] a [Lightning BOLTs][bolts repo].* + +- [Bitcoin Core #27358][] upravuje skript `verify.py` automatizující + ověřování souborů vydání Bitcoin Core. Uživatel importuje PGP + klíče lidí, kterým věří. Skript stáhne seznam souborů vydání spolu + s jejich kontrolními součty a podpisy lidí, kteří stvrdili tyto kontrolní + součty. Skript poté ověří minimálně *k* z těchto důvěryhodných lidí + (uživatel si *k* zvolí sám podle potřeby). Je-li nalezeno dostatečné + množství validních podpisů, stáhne skript soubory pro instalaci této + verze Bitcoin Core. [Dokumentace][verify docs] nabízí dodatečné informace. + Skript není pro používání Bitcoin Core vyžadován a nabízí jen automatizaci + procesu, který by uživatelé měli sami provádět před každým používáním citlivých + souborů stažených z internetu. + +- [Core Lightning #6120][] vylepšuje logiku [nahrazování transakcí][topic rbf] + včetně implementace pravidel pro automatické navýšení poplatků transakce + pomocí RBF a opakované zveřejňování nepotvrzených transakcí (viz + [zpravodaj č. 243][news243 rebroadcast]). + +- [Eclair #2584][] přidává podporu [splicingu][topic splicing]: pro splice-in + přidávající prostředky na existující kanál i splice-out posílající prostředky + z kanálu na blockchain. PR poznamenává, že obsahuje několik odlišností + od aktuálního [návrhu specifikace][bolts #863]. + +{% 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://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/ +[rgb.info ln]: https://docs.rgb.info/lightning-network-compatibility +[verify docs]: https://github.com/theuni/bitcoin/blob/754fb6bb8125317575edec7c20b5617ad27a9bdd/contrib/verifybinaries/README.md +[news243 rebroadcast]: /cs/newsletters/2023/03/22/#lnd-7448 +[rgb blog]: https://rgb.tech/blog/release-v0-10/ +[bdk 0.28.0]: https://github.com/bitcoindevkit/bdk/releases/tag/v0.28.0 +[Core Lightning 23.02.2]: https://github.com/ElementsProject/lightning/releases/tag/v23.02.2 +[Core Lightning 23.05rc1]: https://github.com/ElementsProject/lightning/releases/tag/v23.05rc1 +[Descriptor wallet library]: https://github.com/BP-WG/descriptor-wallet +[Descriptor Wallet v0.9.2]: https://github.com/BP-WG/descriptor-wallet/releases/tag/v0.9.2 +[stratum blog]: https://stratumprotocol.org/blog/stratumv2-jn-announcement/ +[liana 0.4]: https://wizardsardine.com/blog/liana-0.4-release/ +[coldcard firmware]: https://coldcard.com/docs/upgrade +[wiki sighash]: https://en.bitcoin.it/wiki/Contract#SIGHASH_flags +[zeus v0.7.4]: https://github.com/ZeusLN/zeus/releases/tag/v0.7.4 +[floresta blog]: https://medium.com/vinteum-org/introducing-floresta-an-utreexo-powered-electrum-server-implementation-60feba8e179d +[se107154]: https://bitcoin.stackexchange.com/questions/107154/what-is-the-control-block-in-taproot diff --git a/_posts/cs/newsletters/2023-04-26-newsletter.md b/_posts/cs/newsletters/2023-04-26-newsletter.md new file mode 100644 index 0000000000..9cfe4915fc --- /dev/null +++ b/_posts/cs/newsletters/2023-04-26-newsletter.md @@ -0,0 +1,143 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 248' +permalink: /cs/newsletters/2023/04/26/ +name: 2023-04-26-newsletter-cs +slug: 2023-04-26-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přeposíláme žádost o poskytnutí zpětné vazby k návrhu na +odstranění podpory BIP35 P2P zprávy `mempool` v Bitcoin Core. Dále nechybí +naše pravidelné rubriky s oblíbený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í bitcoinových páteřních projektech. + +## Novinky + +- **Návrh na odstranění BIP35 P2P zprávy `mempool`:** Will Clark zaslal + do emailové skupiny Bitcoin-Dev [příspěvek][clark mempool] o [PR][bitcoin + core #27426], který otevřel za účelem odstranění podpory pro P2P zprávu + `mempool`, která byla původně specifikována v [BIP35][]. Dle původní + implementace by uzel po obdržení zprávy `mempool` měl odpovědět zprávou + `inv` obsahující ID všech transakcí v jeho mempoolu. Uzel, který + odeslal původní požadavek, by poté mohl běžnou zprávou `getdata` + požádat o data kterékoliv transakce. BIP popisuje tři důvody pro existenci + této zprávy: diagnostika síťového provozu, možnost odlehčených klientů + žádat o nepotvrzené transakce a možnost těžařů požádat po restartu o + nepotvrzené transakce (v té době Bitcoin Core ještě neukládal mempool + na disk). + + Avšak později byly vyvinuty techniky, které zneužívaly zprávy `mempool` + a `getdata` k určení, který uzel jako první odeslal nějakou transakci. + Pro zlepšení [soukromí odesílatele transakcí][topic transaction origin privacy] + byla později odstraněna možnost požádat jiné uzly o neoznámené transakce + a zpráva `mempool` mohla být použita pouze s [bloom filtry transakcí][topic + transaction bloom filtering] (dle [BIP37][]). Ještě později Bitcoin Core + ve výchozím stavu bloom filtr neaktivoval (viz [zpravodaj č. 56][news56 bloom], + *angl.*) a umožnil jej používat pouze se spojeními, která měla aktivovanou + volbu `whitelist` ([zpravodaj č. 60][news60 bloom], *angl.*). To ve svém + důsledku znamená, že i zpráva `mempool` je ve výchozím stavu neaktivní. + + Clarkův pull request do Bitcoin Core obdržel podporu, avšak někteří z + podporujících soudí, že by měly být nejprve odstraněny BIP37 bloom filtry. + Zatím jediná [reakce][harding mempool] v emailové skupině poznamenává, + že odlehčené klienty, které se připojují k důvěryhodným uzlům, mohou v + současnosti využívat BIP35 a BIP37 jako nejefektivnějšího způsobu, jak se + mohou dozvědět o nepotvrzených transakcích. Autor příspěvku navrhl, + aby Bitcoin Core před odstraněním současného rozhraní nejdříve poskytl + alternativní způsob. + + Lidé, kteří používají BIP35 zprávu `mempool`, jsou žádáni o poskytnutí + zpětné vazby buď v emailové skupině nebo PR. + +## 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/" %} + +- [Kolik sigops je v nevalidním bloku 783426?]({{bse}}117837) + Vojtěch Strnad poskytl skript, který prochází všechny transakce v bloku a + počítá [sigops]({{bse}}117359) (opkódy, které ověřují elektronické podpisy). + Napočítal 80 003 sigops, což blok činí [nevalidním][max sigops]. + +- [Jak by mohl útočník až 500krát zvýšit poplatek potřebný k nahrazení transakce?]({{bse}}117734) + Michael Folkson poukazuje na návrh BIP pro [dočasné anchor výstupy][topic ephemeral + anchors] („ephemeral anchors”) a táže se, jakým způsobem je možné 500krát navýšit + poplatek vyžadovaný pro nahrazení transakce. Antoine Poinsot poskytuje příklad, + jak by útočník mohl zneužít pravidla navýšení poplatku pomocí [Replace-By-Fee (RBF)][topic rbf] + k vyžádání dodatečných transakcí, které by platily výrazně vyšší poplatky. + +- [Jak nejlépe na vícenásobné CPFP a CPFP + RBF?]({{bse}}117877) + Sdaftuar vysvětluje techniku navyšování poplatků pomocí RBF a CPFP + ([Child Pays For Parent][topic cpfp]) v situaci, kdy prvotní pokus o navýšení + pomocí CPFP selže z důvodu nedostatečného jednotkového poplatku. + +## 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 0.0.115][] je vydáním této knihovny pro stavbu peněženek a aplikací + s LN. Obsahuje několik nových funkcí a oprav chyb, včetně lepší podpory + pro experimentální protokol [nabídek][topic offers] a vylepšené + bezpečnosti a soukromí. + +- [LND v0.16.1-beta][] je vydáním této implementace LN, která obsahuje + několik oprav a další vylepšení. Poznámky o vydání zmiňují, že + CLTV delta byla navýšena ze 40 bloků na 80 (viz [zpravodaj č. 40][news40 + cltv], který se zabývá předchozí změnou výchozí hodnoty). + +- [Core Lightning 23.05rc1][] je kandidátem na vydání příští verze + této implementace LN. + +## Významné změny v kódu a dokumentaci + +*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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [LND #7564][] nyní umožňuje, aby uživatelé backendů poskytujících + přístup do mempoolu mohli monitorovat nepotvrzené transakce obsahující + předobraz HTLC svých kanálů. Díky tomu může uzel rychleji vyřídit + HTLC, jelikož nemusí čekat na potvrzení transakce. + +- [LND #6903][] přidává do RPC volání `openchannel` novou volbu `fundmax`, + která alokuje všechny prostředky kanálu na nový kanál. Vyňaty jsou + částky potřebné k přidání poplatků pomocí [anchor výstupů][topic anchor outputs]. + +- [LDK #2198][] prodlužuje dobu, po kterou LDK čeká, než odešle gossip zprávu + oznamující nedostupnost kanálu (např. kvůli nedostupnému spojení). + V předešlé verzi čekalo LDK zhruba minutu, avšak jiné implementace čekají + déle. Existující [návrh][bolts #1059] doporučuje používat počet bloků + namísto [unixové času][Unix epoch time], což by si vynutilo aktualizaci + gossip zpráv jednou za blok (průměrně zhruba každých deset minut). + Ač PR poznamenává, že pomalejší odesílání aktualizací má klady i zápory, + nastavuje novou hodnotu na deset minut. + +- [Bitcoin Inquisition #23][] přidává částečnou podporu [dočasných anchor + výstupů][topic ephemeral anchors]. Nepřináší podporu [přeposílání v3 transakcí][topic + v3 transaction relay], kterou dočasné anchor výstupy potřebují k zabránění + [transaction pinning útokům][topic transaction pinning]. + +{% include references.md %} +{% include linkers/issues.md v=2 issues="7564,6903,2198,1059,23,27426" %} +[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://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 +[news40 cltv]: /en/newsletters/2019/04/02/#lnd-2759 +[max sigops]: https://github.com/bitcoin/bitcoin/blob/e9262ea32a6e1d364fb7974844fadc36f931f8c6/src/consensus/consensus.h#L17 diff --git a/_posts/cs/newsletters/2023-05-03-newsletter.md b/_posts/cs/newsletters/2023-05-03-newsletter.md new file mode 100644 index 0000000000..1f65d10f17 --- /dev/null +++ b/_posts/cs/newsletters/2023-05-03-newsletter.md @@ -0,0 +1,177 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 249' +permalink: /cs/newsletters/2023/05/03/ +name: 2023-05-03-newsletter-cs +slug: 2023-05-03-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme popis analýzy použití návrhu flexibilních +kovenantů reimplementující `OP_VAULT`, souhrn příspěvku o +bezpečnosti signature adaptorů a přeposíláme oznámení o pracovní +příležitosti, která může některé čtenáře zajímat. Též nechybí +naše pravidelné rubriky popisující nová vydání, kandidáty +na vydání a významné změny v populárních bitcoinových páteřních +projektech. + +## Novinky + +- **Úschovny založené na MATT:** Salvatore Ingala zaslal do emailové + skupiny Bitcoin-Dev [příspěvek][ingala vaults] s popisem hrubé + implementace [úschovny][topic vaults] („vault”) s chováním podobným + nedávnému návrhu na `OP_VAULT` (viz [zpravodaj č. 234][news234 op_vault]), + avšak založený na Ingalově návrhu Merklize All The Things (MATT, „všechno + to zmerklujte“; viz [zpravodaj č. 226][news226 matt], *angl.*). MATT + by umožnil vytváření velmi flexibilních bitcoinových kontraktů pomocí + několika nových, jednoduchých [kovenantových][topic covenants] opkódu. + + Tento týden Ingala ukázal, že MATT by byl velice flexibilní a efektivní + a bylo by jej možné snadno použít ve vzorech transakcí, které by jednou + mohly být dosti využívané. Podobně jako poslední verze návrhu na + `OP_VAULT`, i zde staví Ingala na návrhu [BIP119][] na [OP_CHECKTEMPLATEVERIFY][topic + op_checktemplateverify] (CTV). Přidáním dvou dodatečných opkódů + (které, jak uznává, nepokryjí vše potřebné) nabízí množinu funkcí, + která je téměř ekvivalentní s `OP_VAULT`; jedinou významnou chybějící + funkcí je „možnost přidat dodatečný výstup, který posílá zpět do + stejné úschovny.” + + V době psaní tohoto zpravodaje neobdržel Ingalův příspěvek žádnou + přímou reakci, ale [diskuze][halseth matt] pokračovala pod jeho + původním příspěvkem o MATTu a jeho schopnosti ověřit, že + byl spuštěn nějaký (v podstatě) libovolně komplexní program. + +- **Analýza bezpečnosti signature adaptorů:** Adam Gibson + [zaslal][gibson adaptors] do emailové skupiny Bitcoin-Dev analýzu + bezpečnosti [signature adaptorů][topic adaptor signatures], která + se soustředí zejména na jejich interakci s protokoly [vícenásobných + podpisů][topic multisignature] jako je [MuSig][topic musig], ve kterých + musí množství účastníků bez vzájemné důvěry kooperovat na tvorbě adaptorů. + Plánuje se v dohledné době nasadit signature adaptory v LN pro + použití s [PTLC][topic ptlc], které vyústí ve zvýšení výkonnosti a soukromí. + Věří se, že budou používány také v jiných protokolech s cílem zvyšovat + efektivitu a/nebo soukromí. Představují jeden z nejmocnějších stavebních + kamenů nových i rozšířených existujících bitcoinových protokolů, pečlivá + analýza jejich bezpečnostních vlastností je tedy klíčová k dosažení + správného používání. Gibson staví na předešlé analýze Lloyda Fourniera + a dalších (viz [zpravodaj č. 129][news129 adaptors], *angl.*), ale také + upozorňuje na nutnost dalšího zkoumání a analyzování. + +- **Pracovní příležitost pro bitcoinové mágy:** Steve Lee z organizace Spiral, + která se zabývá distribucí grantů, [zaslal][lee hiring] do emailové skupiny + Bitcoin-Dev nabídku pro velmi zkušené bitcoinové přispěvatele na + placenou pozici na plný úvazek, jejíž náplní by bylo hledat a vést + projekty významně přispívající k dlouhodobým cílům bitcoinu jako + je škálovatelnost, bezpečnost, soukromí a flexibilita. Příspěvek obsahuje + další podrobnosti. + +## 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.16.2-beta][] je menší vydání této implementace LN, která + přináší opravy několika chyb postihující výkonnost, jež byly zaneseny + do předchozího vydání. + +- [Core Lightning 23.05rc2][] je kandidátem na vydání příští verze + této implementace LN. + +## Významné změny v kódu a dokumentaci + +*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] a [Lightning BOLTs][bolts repo].* + +- [Bitcoin Core #25158][] přidává pole `abandoned` do detailu transakce + v odpovědích na RPC volání `gettransaction`, `listtransactions` a `listsinceblock`. + Pole indikuje, které transakce byly označeny jako [abandoned][abandontransaction rpc] + („zahozené”). + +- [Bitcoin Core #26933][] vrací zpět podmínku, aby každá transakce splňovala + minimální jednotkový poplatek pro přeposílání nastavený uzlem pomocí + volby `-minrelaytxfee`, aby mohla být připuštěna do mempoolu, i v případě, + kdy je transakce vyhodnocena jako balíček. Validace balíčku i nadále + umožňuje navýšit poplatek transakce pod dynamický minimální jednotkový + poplatek mempoolu. Toto pravidlo bylo vráceno, aby eliminovalo riziko, + že transakce s nulovým poplatkem ztratí své potomky navyšující jí + poplatek. V budoucnu může být opět odstraněno, pokud se nalezne + lepší způsob, který by byl odolný vůči útokům odepření služby (DoS), + např. díky restrikcím topologie balíčku jako je v3 nebo modifikací + procesu odstranění transakcí z mempoolu. + +- [Bitcoin Core #25325][] přináší znovupoužitelný paměťový zdroj pro ukládání + UTXO do mezipaměti. Tato nová datová struktura předem alokuje a spravuje + větší úsek znovupoužitelné paměti namísto alokování a uvolňování paměti + pro každé UTXO zvlášť. Vyhledávání UTXO představuje hlavní důvod + přístupu do paměti obzvláště během prvotního stahování bloků. Benchmarky + ukazují, že rychlost reindexování se díky tomu zvýší o více než 20 %. + +- [Bitcoin Core #25939][] umožňuje uzlům s aktivovaným indexem transakcí + vyhledávat v tomto indexu během RPC volání `utxoupdatepsbt`, které přidává + do [PSBT][topic psbt] informace o výstupech transakce, kterou utrácí. + Když bylo volání v roce 2019 poprvé implementováno (viz [zpravodaj č. 34][news34 + psbt], *angl.*), byly v síti běžné dva druhu výstupů: zastaralé výstupy + a segwit v0 výstupy. Každé utracení zastaralého výstupu v PSBT vyžadovalo + začlenění kopie transakce, která tento výstup obsahovala, aby podpisovatel + mohl ověřit částku výstupu. Ověření je důležité, neboť utracení výstupu bez + ověření částky může vést k velkému přeplacení na poplatcích. + + Každé utracení segwit v0 výstupu zavazuje ke své částce, aby mohlo PSBT + začlenit pouze scriptPubKey výstupu a částku namísto celé předchozí + transakce. Věřilo se, že by to odstranilo potřebu kompletní transakci + začlenit. Jelikož je každý neutracený výstup každé potvrzené + transakce uložen v množině UTXO, může `utxoupdatepsbt` přidat + nezbytný scriptPubKey a částku do PSBT utrácející nějaké UTXO. `utxoupdatepsbt` + též dříve vyhledávalo UTXO v mempoolu, aby umožnilo uživatelům utratit + výstup nepotvrzené transakce. + + Avšak po přidání `utxoupdatepsbt` do Bitcoin Core začala některá + hardwarová podpisová zařízení vyžadovat začlenění kompletní transakce + i v případě segwit v0 výstupů, aby zabránila některým případům + přeplacení, ke kterému by mohlo dojít v důsledku dvojího podepsání + stejné transakce (viz [zpravodaj č. 101][news101 overpayment], *angl.*). + + Tato začleněná změna umožní vyhledat v indexu transakcí, pokud je aktivovaný, + a v místním mempoolu kompletní transakce a začlenit je do PSBT, pokud je + tak vyžadováno. Pokud není kompletní transakce nalezena, bude použita + množina UTXO. Taproot (segwit v1) odstraňuje podobné obavy o přeplacení + většiny transakcí, které utrácí alespoň jeden taprootový výstup, takže + očekáváme, že v budoucnu opadne potřeba mít v podobných + případech přístup k plným transakcím. + +- [LDK #2222][] umožňuje aktualizovat informace o kanálu pomocí zpráv + vyměňovaných uzly účastnící se tohoto kanálu bez nutnosti ověřovat, + zda existuje UTXO odpovídající tomuto kanálu. Gossip zprávy v LN + by měly být akceptované pouze, patří-li kanálu s existujícím UTXO. + Toto opatření je jedním ze způsobů ochrany před DoS útoky, avšak + některé LN uzly nemají přístup k UTXO a mohou disponovat jinými + způsoby ochrany před DoS útoky. Tato změna usnadňuje podobných uzlům + přijímat aktualizace informací. + +- [LDK #2208][] přidává přeposílání transakcí a navyšování poplatků + neukončeným [HTLC][topic htlc] v kanálech, které byly uzavřeny + bez kooperace. Změna adresuje některé [pinningové útoky][topic transaction + pinning] a zajišťuje spolehlivost. Viz též [zpravodaj č. 243][news243 + rebroadcast], kde LND přidalo své rozhraní přeposílání, a [minulé číslo][news247 + rebroadcast], kde CLN vylepšilo svou logiku. + +{% include references.md %} +{% include linkers/issues.md v=2 issues="25158,26933,25325,2222,2208,25939" %} +[Core Lightning 23.05rc2]: https://github.com/ElementsProject/lightning/releases/tag/v23.05rc2 +[lnd v0.16.2-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.16.2-beta +[news101 overpayment]: /en/newsletters/2020/06/10/#fee-overpayment-attack-on-multi-input-segwit-transactions +[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://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://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 new file mode 100644 index 0000000000..204b9641a7 --- /dev/null +++ b/_posts/cs/newsletters/2023-05-10-newsletter.md @@ -0,0 +1,274 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 250' +permalink: /cs/newsletters/2023/05/10/ +name: 2023-05-10-newsletter-cs +slug: 2023-05-10-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme popis článku o protokolu PoWswap a naše pravidelné +rubriky se souhrnem sezení Bitcoin Core PR Review Club, oznámeními o +nových verzích a popisem významných změn v populárních páteřních +bitcoinových projektech. Též nechybí krátká část oslavující pět let +Bitcoin Optech a naše 250. číslo. + +## Novinky + +- **Článek o protokolu PoWswap:** Thomas Hartman zaslal do emailové + skupiny Bitcoin-Dev [příspěvek][hartman powswap] o [článku][hnr powswap], + který napsal s Glebem Naumenkem a Antoinem Riardem, věnující se protokolu + [PoWSwap][] poprvé navrženém Jeremy Rubinem. PoWswap umožňuje + vytvářet onchainové kontrakty vztažené ke změně hash rate. Základní + myšlenka spočívá ve využití vztahu mezi časem a produkcí bloků, který + lze ověřovat na úrovni protokolu, spolu s možností vyjádřit časové + zámky buď formou času nebo počtu bloků. Mějme například následující skript: + + ``` + OP_IF + OP_CHECKSIGVERIFY <čas> OP_CHECKLOCKTIMEVERIFY + OP_ELSE + OP_CHECKSIGVERIFY OP_CHECKLOCKTIMEVERIFY + OP_ENDIF + ``` + + Představme si, že aktuální čas je _t_ a aktuální výška bloků je _x_. + Předpokládejme, že bloky jsou produkovány průměrně v desetiminutových + intervalech. Nastavíme-li `<čas>` na _t + 1 000 minut_ a `` na + _x + 50_, můžeme očekávat, že Bob by byl schopen utratit výstup + kontrolovaný výše uvedeným skriptem v průměru 500 minut před tím, než + by ho mohla utratit Alice. Avšak pokud by se produkce bloků zrychlila + více než dvakrát, mohla by Alice utratit výstup před Bobem. + + Lze si představit několik aplikací takového kontraktu: + + - *Pojištění proti navýšení hash rate:* těžaři musí zakoupit vybavení + před tím, než najisto vědí, jaký příjem jim bude generovat. Například + se může stát, že těžař zakoupí dost vybavení, aby obdržel jedno procento + současných odměn. Tento těžař by jistě nepřivítal, kdyby ve stejné + době jiný těžař zakoupil vybavení, kterým by zdvojnásobil celkový + hash rate a tím by snížil jeho odměny na 0,5 %. Náš těžař by mohl + pomocí PoWswap uzavřít kontrakt s někým, kdo je ochoten mu zaplatit + v případě navýšení hash rate před určitým datem, čímž by vyrovnal + těžařův neočekávaně nízký příjem. Výměnou by tento těžař souhlasil + zaplatit větší částku, pokud by hash rate zůstal stejný nebo se snížil. + + - *Pojištění proti poklesu hash rate:* množství známých problémů + bitcoinu by vyústilo ve velký pokles celkového hash rate. Hash rate + by se snížil, pokud by těžaři byli zavírání nějakými mocnými stranami + nebo pokud by se mezi zavedenými těžaři náhle začal ve velké míře + objevovat [fee sniping][topic fee sniping] anebo pokud by hodnota + BTC, který těžaři obdrží, náhle poklesla. Držitelé bitcoinu, kteří + by se chtěli proti takovým situacím pojistit, by mohli uzavřít + s těžaři nebo třetími stranami podobný kontrakt. + + - *Kurzové kontrakty:* obecně chtějí v případě navýšení kupní síly + bitcoinu těžaři navýšit jimi poskytovaný hash rate, aby obdrželi + více na odměnách. V případě poklesu kupní síly potom hash rate + klesá. Lidé by mohli uzavírat kontrakty navázané na budoucí + kupní sílu bitcoinu. + + I když se o PoWswap hovoří již několik let, tento článek poskytuje + množství podrobností a analýz, které jsme do této doby neviděli. + +## 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.* + +- [Core Lightning 23.05rc2][] je kandidátem na vydání příští verze + této implementace LN. + +- [Bitcoin Core 24.1rc2][] je kandidátem na údržbové vydání aktuální + verze Bitcoin Core. + +- [Bitcoin Core 25.0rc1][] je kandidátem na vydání příští hlavní verze + Bitcoin Core. + +## 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 getprioritisationmap, odstraň položku z mapDeltas pokud delta==0][review club 27501] +je PR od Glorie Zhao (glozow) vylepšující funkci Bitcoin Core, +která těžařům umožňuje upravit efektivní poplatek konkrétní transakce +v mempoolu (viz RPC volání [`prioritisetransaction`][prioritisetransaction RPC]), +a tím zvýšit či snížit prioritu její těžby. Hodnota, která navýší poplatek +(je-li kladná) či sníží poplatek (je-li záporná), se nazývá _fee delta_. +Hodnoty prioritizace transakcí jsou ukládány na disk do souboru `mempool.dat` +a jsou v případě restartu obnoveny. + +Jednou ze situací, kdy těžař využije prioritizaci transakcí, je obdržení +externí platby poplatku. Poplatek takové transakce se potom bude během +těžby považovat za vyšší. + +PR přidává nové RPC volání `getprioritisationmap`, které vrací seznam +prioritizovaných transakcí. PR dále odstraňuje již nepotřebné položky +prioritizace, je-li jejich delta nastavena na nulu. + +{% include functions/details-list.md + q0="Co je datová struktura [mapDeltas][] a proč ji potřebujeme?" + a0="Ukládá hodnoty prioritizace transakcí. Tyto hodnoty ovlivňují + rozhodování o lokální těžbě, zahazování transakcí a také + kalkulaci poplatků rodičů a potomků." + a0link="https://bitcoincore.reviews/27501#l-26" + + q1="Ovlivňuje prioritizace transakcí algoritmus odhadování poplatků?" + a1="Ne. Odhad poplatků musí přesně předpovídat očekávaná rozhodnutí + těžařů (v tomto případě se jedná o _ostatní_ těžaře) a tito + těžaři nemají stejnou prioritizaci jako my. Prioritizace je + lokální." + a1link="https://bitcoincore.reviews/27501#l-31" + + q2="Jak jsou do `mapDeltas` položky přidávány? Kdy jsou odstraněny?" + a2="Jsou přidávány RPC voláním `prioritisetransaction` a také během + restartu ze souboru `mempool.dat`. Odstraněny jsou v okamžiku + začlenění bloku s transakcí do blockchainu nebo když je transakce + [nahrazena (RBF)][topic rbf]." + a2link="https://bitcoincore.reviews/27501#l-34" + + q3="Proč bychom neměli odstranit položku z `mapDeltas`, když je její transakce + odstraněna z mempoolu (např. protože její čas vypršel nebo byla vyhozena + kvůli nízkému poplatku)?" + a3="Transakce se může vrátit zpět do mempoolu. Pokud by byla položka z + `mapDeltas` ostraněna, musel by uživatel opět nastavit prioritizaci + této transakce." + a3link="https://bitcoincore.reviews/27501#l-84" + + q4="Je-li transakce odstraněna z `mapDeltas` z důvodu začlenění do bloku + a tento blok je následně obětí reorganizace, nebude se muset + znovu nastavit prioritizace transakce?" + a4="Ano, ale reorganizace by měly nastávat zřídka. Navíc externí platby + mohou být ve formě bitcoinové transakce a ta také může vyžadovat + prioritizaci." + a4link="https://bitcoincore.reviews/27501#l-90" + + q5="Proč bychom měli umožnit prioritizaci transakce, která není přítomna + v mempoolu?" + a5="Protože tato transakce nemusí být v mempoolu _prozatím_. A nemusí + se do mempoolu ani dostat kvůli vlastnímu poplatku (bez prioritizace)." + a5link="https://bitcoincore.reviews/27501#l-89" + + q6="Jaký problém nastává, když `mapDeltas` nepročišťujeme?" + a6="Hlavním problémem je zbytečná alokace paměti." + a6link="https://bitcoincore.reviews/27501#l-107" + + q7="Kdy se `mempool.dat` (včetně `mapDeltas`) zapisuje na disk?" + a7="V případě řádného ukončení nebo RPC voláním `savemempool`." + a7link="https://bitcoincore.reviews/27501#l-114" + + q8="Jak před tímto PR těžaři pročišťovali `mapDeltas`?" + a8="Jediným způsobem bylo uzel restartovat, jelikož během restartu + nejsou nulové prioritizace do `mapDeltas` vkládány. Díky PR + jsou nulové položky z `mapDeltas` odstraněny okamžitě a nejsou + tak ani zapisovány na disk." + a8link="https://bitcoincore.reviews/27501#l-127" +%} + +## Významné změny v kódu a dokumentaci + +*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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Bitcoin Core #26094][] přidává do volání `getbalances`, `gettransaction`a + `getwalletinfo` hash a výšku bloku. Tato volání zamykají chainstate, + aby garantovala aktuální stav, začlenění validního hashe a výšky bloku + do odpovědi je pro ně tedy výhodné. + +- [Bitcoin Core #27195][] umožňuje odstranit všechny externí příjemce + transakce, která je [nahrazována][topic rbf] pomocí volání `bumpfee` + z interní peněženky Bitcoin Core. Uživatel tak učiní tím, že jediný + výstup nahrazující transakce platí na jeho vlastní adresu. Po potvrzení + nahrazující transakce nemůže dojít k zaplacení původním příjemcům. + Této technice se někdy říká „zrušení” bitcoinové platby. + +- [Eclair #1783][] přidává API `cpfpbumpfees` pro navýšení poplatku + jedné nebo více transakcí pomocí [CPFP][topic cpfp]. PR také aktualizuje + seznam [doporučených parametrů][eclair bitcoin.conf] pro provoz + Bitcoin Core tak, aby navyšování poplatků bylo možné. + +- [LND #7568][] přidává možnost definovat během startu dodatečné feature + bity. Dále odstraňuje možnost deaktivovat jakékoliv pevně zakódované + nebo definované feature bity během provozu (ale dodatečné bity + mohou být přidány a později odstraněny). Navázaný návrh v [BLIPs #24][] + poznamenává, že uživatelské [BOLT11][] feature bity jsou omezeny + na maximální hodnotu 5114. + +- [LDK #2044][] přináší několik změn v doporučeních tras v rámci + [BOLT11][] faktur, tedy mechanismu, kterého může příjemce využít + k návrhu tras, které může odesílatel použít. V rámci této změny + jsou pro doporučení použity pouze první tři kanály (z důvodu efektivity + a soukromí) a je vylepšena podpora phantom uzlů (viz [zpravodaj č. + 188][news188 phantom], *angl.*). Diskuze pod PR obsahuje [několik][carman + hints] užitečných [komentářů][corallo hints] o dopadech používání + doporučených tras na soukromí. + +## Oslavujeme zpravodaj číslo 250 + +Bitcoin Optech byl zčásti založen, aby „pomohl vylepšit vztahy mezi +byznysem a open source komunitou.” Tento týdenní zpravodaj byl vytvořen, +aby poskytl vedení a vývojářům v bitcoinových firmách přehled o +výsledcích snah open source komunity. Proto jsme se v počátcích +soustředili na dokumentování činnosti, která může mít vliv na byznys. + +Brzy jsme zjistili, že o tyto informace měli zájem nejen čtenáři +z řad byznysu. Mnoho přispěvatelů do bitcoinových projektů nemělo čas +na čtení všech diskuzí v emailových skupinách nebo na monitorování +významných změn jiných projektů. Rádi by, kdyby je někdo informoval +o změnách, které by je mohli zajímat či mít dopad na jejich práci. + +Je nám potěšením již téměř pět let poskytovat tuto službu. Snažíme se +tuto jednoduchou misi rozšiřovat a proto také poskytujeme průvodce +[kompatibilitou peněženek][compatibility matrix], rejstřík více než +100 [témat][topics] a týdenní diskuzní [podcast][podcast] s hosty, +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: +Adam Jonas, +Copinmalin, +David A. Harding, +Gloria Zhao, +Jiri Jakes, +Jon Atack, +Larry Ruane, +Mark „Murch” Erhardt, +Mike Schmidt, +nechteme, +Patrick Schwegler, +Shashwat Vangani, +Shigeyuki Azuchi, +Vojtěch Strnad, +Zhiwei „Jeffrey” Hu +a několik dalších, kteří přispěli k jednotlivým tématům. + +Též zůstáváme navždy vděčni našim [zakládajícím sponzorům][founding +sponsors] Wencesovi Casaserovi, Johnovi Pfefferovi, Alexovi Morcosovi +a mnoha těm, kteří [přispěli finančně][financial supporters]. + +Děkujeme vám za čtení. Doufáme, že v tom budete během následujících 250 +zpravodajů pokračovat. + +{% include references.md %} +{% include linkers/issues.md v=2 issues="26094,27195,1783,7568,24,2044" %} +[Core Lightning 23.05rc2]: https://github.com/ElementsProject/lightning/releases/tag/v23.05rc2 +[bitcoin core 24.1rc2]: https://bitcoincore.org/bin/bitcoin-core-24.1/ +[bitcoin core 25.0rc1]: https://bitcoincore.org/bin/bitcoin-core-25.0/ +[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://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]: /en/about/#founding-sponsors +[financial supporters]: /#members +[review club 27501]: https://bitcoincore.reviews/27501 +[prioritisetransaction rpc]: https://developer.bitcoin.org/reference/rpc/prioritisetransaction.html +[mapDeltas]: https://github.com/bitcoin/bitcoin/blob/fc06881f13495154c888a64a38c7d538baf00435/src/txmempool.h#L450 diff --git a/_posts/cs/newsletters/2023-05-17-newsletter.md b/_posts/cs/newsletters/2023-05-17-newsletter.md new file mode 100644 index 0000000000..65f9f99339 --- /dev/null +++ b/_posts/cs/newsletters/2023-05-17-newsletter.md @@ -0,0 +1,237 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 251' +permalink: /cs/newsletters/2023/05/17/ +name: 2023-05-17-newsletter-cs +slug: 2023-05-17-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme popis návrhu na započetí testování HTLC atestací, +předáváme žádost o poskytnutí zpětné vazby k návrhu specifikace +poskytovatelů lightningových služeb (LSP), probíráme těžkosti +s otevíráním zero-conf kanálů spolu s dvojím financováním, díváme se +na návrh pokročilých aplikací payjoin protokolu a odkazujeme na +souhrn nedávného osobního setkání vývojářů Bitcoin Core. Dále začleňujeme +první část nové série o pravidlech přeposílání transakcí a začleňování +do mempoolu. Též nechybí naše pravidelné rubriky s oznámeními o nových +vydáních (včetně bezpečnostního vydání libsecp256k1) a popisem významných +změn v populárních bitcoinových páteřních projektech. + +## Novinky + +- **Testování HTLC atestací:** před několika týdny zaslaly Carla Kirk-Cohen + a Clara Shikhelman [příspěvek][kcs endorsement] do emailové skupiny + Lightning-Dev o krocích, které ony spolu s dalšími lidmi plánují + podniknout ve snaze otestovat myšlenku [HTLC][topic htlc] atestací + (viz [zpravodaj č. 239][news239 endorsement]) jako součást souboru + opatření pro zamezení [útoku zahlcením kanálu][topic channel jamming attacks]. + Mimo jiné poskytly [návrh specifikace][bolts #1071], která by mohla být + nasazena s použitím experimentálního příznaku, což by umožnilo bez potíží + komunikovat s uzly, které tuto specifikaci neimplementují. + + Po nasazení v rámci experimentálního provozu by mělo být jednodušší + odpovědět na jednu z [konstruktivních kritik][decker endorsement] této myšlenky: + kolika přeposílaným platbám by toto schéma ve skutečnosti pomohlo. + Pokud si uživatelé LN často navzájem posílají platby přes množinu tras + a pokud systém reputací funguje správně, měla by síť tvořená těmito + uživateli být schopná ustát útok zahlcením kanálu. Avšak pokud většina + odesílatelů posílá platby jen zřídka (nebo zřídka posílají nejkritičtější + typ plateb jako jsou platby s vysokou hodnotou), potom nebudou mít + dostatečné množství interakcí k vybudování reputace, nebo budou + reputační data příliš zpožděna (což by dokonce mohlo umožnit zneužívání). + +- **Žádost o poskytnutí zpětné vazby k návrhu specifikace LSP:** Severin + Bühler zaslal do emailové skupiny Lightning-Dev [příspěvek][buhler lsp] + s žádostí o poskytnutí zpětné vazby ke dvěma specifikacím interoperability + mezi poskytovateli lightningových služeb (LSP) a jejich klienty (obvykle + LN uzly, které nepřeposílají platby). První specifikace popisuje API, + které umožní uživatelům zakoupit od LSP kanál. Druhá popisuje API + pro nastavení a správu JIT (Just-In-Time) kanálů, což jsou kanály, které + jsou vytvořeny jako virtuální platební kanály a teprve po první platbě + na tento kanál uveřejní LSP transakci, která tak po potvrzení ukotví kanál + v blockchainu a učiní jej běžným kanálem. + + V [odpovědi][zmnscpxj lsp] vyjádřil vývojář ZmnSCPxj souhlas s otevřenou + specifikací pro LSP. Poznamenal, že díky tomu se mohou klienti připojit + k více poskytovatelům a tím se vyhnout závislosti na jednom poskytovateli. + +- **Potíže s zero-conf kanály a dvojím financováním:** Bastien + Teinturier zaslal do emailové skupiny Lightning-Dev [příspěvek][teinturier 0conf] + o výzvách, které přináší vzájemné používání [zero-conf kanálů][topic zero-conf channels] + a [protokolu dvojího financování][topic dual funding]. Zero-conf kanály + mohou být používány ještě před potvrzením otevírací transakce, což v některých + případech nevyžaduje důvěru. Kanály s dvojím financováním jsou takové, + jejichž otevírací transakce obsahuje vstupy obou účastníků (a jsou tedy + financované oběma). + + Zero-conf nevyžaduje důvěru pouze v případě, kdy jeden z účastníků kontroluje + všechny vstupy otevírací transakce. Příklad: Alice vytvoří otevírací + transakci, poskytne Bobovi nějaké prostředky v kanálu a nato zkusí Bob + poslat tyto prostředky Carol přes Alici. Alice může platbu bezpečně + přeposlat, neboť ví, že konfirmace otevírací transakce je pod její + kontrolou. Pokud však mám Bob také vstup v otevírací transakci, může + nechat potvrdit konfliktní transakci, která nedovolí potvrzení + otevírací transakce. To zabrání Alici vymáhat kompenzaci za peníze + poslané Carol. + + Bylo probráno několik nápadů, jak umožnit otevírání zero-conf kanálů + s dvojím financováním. V době psaní zpravodaje se žádný z těchto + nápadů nejeví dostatečně uspokojující. + +- **Pokročilé aplikace payjoinu:** Dan Gould zaslal do emailové skupiny + Bitcoin-Dev [příspěvek][gould payjoin] s několika návrhy na pokročilejší + používání protokolu [payjoin][topic payjoin], než je jen prosté + odesílání a přijímaní plateb. Dva z těchto návrhů, které nás nejvíce + zaujaly, byly verze [prořezání transakcí][transaction cut-through] + („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. + +- **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 + některé aspekty projektu. Byly publikovány poznámky z několika + diskuzí uskutečněných během setkání. Mezi tématy nechybělo + [fuzz testování][fuzz testing], [assumeUTXO][], [ASMap][], [tiché + platby][silent payments], [libbitcoinkernel][], [refaktorování (či + ne)][refactoring (or not)] a [přeposílání balíčků][package relay]. + 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. + + - [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? + +_První část krátké týdenní série o přeposílání transakcí, začleňování +do mempoolu a výběru transakcí k těžbě včetně vysvětlení, proč má +Bitcoin Core přísnější pravidla, než co je povoleno konsenzem, a jak +mohou peněženky využít pravidla co nejefektivněji._ + +{% include specials/policy/cs/01-why-mempool.md %} + +## 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 0.3.2][] je bezpečnostním vydáním pro aplikace, které + používají libsecp pro [ECDH][] a které mohou být kompilovány GCC + verzí 13 a vyšší. Jak bylo autory [popsáno][secp ml], nová verze + GCC se snaží optimalizovat kód libsecp, který byl navržen tak, aby běžel + v pevném množství času. Kvůli optimalizaci je možné za určitých podmínek + spustit [útok postranními kanály][topic side channels]. Patří se poznamenat, + že Bitcoin Core ECDH nepoužívá. Vývojáři pracují na mechanismu detekce + podobných problémů v budoucnosti. + +- [Core Lightning 23.05rc2][] je kandidátem na vydání příští verze této + implementace LN. + +- [Bitcoin Core 23.2rc1][] je kandidátem na údržbové vydání předešlé + hlavní verze Bitcoin Core. + +- [Bitcoin Core 24.1rc3][] je kandidátem na údržbové vydání současné + verze Bitcoin Core. + +- [Bitcoin Core 25.0rc2][] je kandidátem na vydání příští hlavní verze + Bitcoin Core. + +## Významné změny v kódu a dokumentaci + +*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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Bitcoin Core #26076][] aktualizuje RPC metody, které zobrazují derivační + cesty veřejných klíčů: pro indikaci hardened derivace se namísto jednoduché + uvozovky `'` bude používat `h`. Tato změna má vliv na kontrolní součet + deskriptoru. Při nakládání s deskriptory obsahující privátní klíče je + použit shodný symbol s deskriptory, které byly vygenerovány nebo importovány. + Pro zastaralé peněženky zůstávají pole `hdkeypath` v `getaddressinfo` a + serializační formát nezměněny. + +- [Bitcoin Core #27608][] bude pokračovat v pokusech o stažení bloku od spojení, + i když jiné spojení tento blok již poskytlo. Bitcoin Core bude pokračovat + ve stahování, dokud není jeden z obdržených bloků zapsán na disk. + +- [LDK #2286][] umožňuje vytváření a podepisování [PSBT][topic psbt] pro + výstupy kontrolované lokální peněženkou. + +- [LDK #1794][] přináší počátek podpory [dvojího financování][topic dual + funding]. Prvně byly přidány metody potřebné pro interaktivní protokol financování. + +- [Rust Bitcoin #1844][] určuje, že schéma v [BIP21][] adresách bude malými písmeny, + tedy `bitcoin:`. I když specifikace URI (RFC3986) říká, že schéma nerozlišuje + malá a velká písmena, testy ukazují, že některé platformy neotevírají aplikace + přiřazené k URI `bitcoin:`, je-li použito schéma s velkými písmeny `BITCOIN:`. + Bylo by výhodnější použít velká písmena, neboť to umožňuje efektivnější + vytváření QR kódů (viz [zpravodaj č. 46][news46 qr], *angl.*). + +- [Rust Bitcoin #1837][] přidává funkci pro generování nového privátního klíče. + Oproti předchozí implementaci došlo ke zjednodušení tvorby privátních klíčů. + +- [BOLTs #1075][] upravuje specifikaci tak, aby se uzly již neodpojovaly po obdržení + varovné zprávy od spojení. + +{% include references.md %} +{% include linkers/issues.md v=2 issues="26076,27608,2286,1794,1844,1837,1075,1071,27677" %} +[Core Lightning 23.05rc2]: https://github.com/ElementsProject/lightning/releases/tag/v23.05rc2 +[bitcoin core 23.2rc1]: https://bitcoincore.org/bin/bitcoin-core-23.2/ +[bitcoin core 24.1rc3]: https://bitcoincore.org/bin/bitcoin-core-24.1/ +[bitcoin core 25.0rc2]: https://bitcoincore.org/bin/bitcoin-core-25.0/ +[news239 endorsement]: /cs/newsletters/2023/02/22/#zadost-o-zpetnou-vazbu-k-hodnoceni-dobrych-sousedu-v-ln +[fuzz testing]: https://btctranscripts.com/bitcoin-core-dev-tech/2023-04-27-fuzzing/ +[assumeutxo]: https://btctranscripts.com/bitcoin-core-dev-tech/2023-04-27-assumeutxo/ +[asmap]: https://btctranscripts.com/bitcoin-core-dev-tech/2023-04-27-asmap/ +[silent payments]: https://btctranscripts.com/bitcoin-core-dev-tech/2023-04-26-silent-payments/ +[libbitcoinkernel]: https://btctranscripts.com/bitcoin-core-dev-tech/2023-04-26-libbitcoin-kernel/ +[refactoring (or not)]: https://btctranscripts.com/bitcoin-core-dev-tech/2023-04-25-refactors/ +[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://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://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 new file mode 100644 index 0000000000..13bb4083bc --- /dev/null +++ b/_posts/cs/newsletters/2023-05-24-newsletter.md @@ -0,0 +1,225 @@ +--- +title: Zpravodaj „Bitcoin Optech” č. 252' +permalink: /cs/newsletters/2023/05/24/ +name: 2023-05-24-newsletter-cs +slug: 2023-05-24-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden popisujeme studii o důkazech validity s nulovou znalostí v +bitcoinu a souvisejících protokolech a přinášíme další příspěvek +v naší krátké týdenní sérii o pravidlech mempoolu. Též nechybí +naše pravidelné rubriky popisující aktualizace klientů a služeb, +nová vydání a změny v populárních bitcoinových páteřních projektech. + +## Novinky + +- **Komprese stavu pomocí důkazů validity s nulovou znalostí:** Robin Linus + zaslal do emailové skupiny Bitcoin-Dev [příspěvek][linus post] o + [studii][lg paper], jejíž je autorem spolu s Lukasem Georgem. + Studie pojednává o použití důkazů validity k redukci velikosti stavu, + který klient musí stáhnout, aby mohl bez požadavku na důvěru + ověřovat budoucí operace. Tento systém prvně aplikují na bitcoin. + Oznámili existenci prototypu, který umí podat důkaz o kumulativním + objemu důkazu práce v řetězci hlaviček bloků a který umožňuje klientovi + ověřit, zda je konkrétní hlavička bloku součástí tohoto řetězce. To + umožňuje klientovi, který obdrží několik důkazů, určit, který z nich + představuje nejvíce práce. + + Též mají (prozatím neoptimální) prototyp dokazující, že všechny změny + stavu transakcí blockchainu respektovaly pravidla měny (např. kolik + bitcoinů může být novým blokem vytvořeno, že každá necoinbasová + transakce nesmí vytvořit UTXO s větší hodnotou, než kolik utrácí, + a že si těžař může nárokovat rozdíl mezi UTXO utrácenými a vytvářenými). + Klient může pomocí tohoto důkazu a kopie aktuální množiny UTXO ověřit, + že množina je přesná a kompletní. Nazývají tento důkaz _assumevalid_, + stejně jako volitelnou [funkci v Bitcoin Core][assumevalid], která + přeskakuje verifikaci skriptů starších bloků, na jejichž validitě se + shodne množství přispěvatelů. + + Pro minimalizaci složitosti důkazu používají verzi [utreexo][topic utreexo] + s hashovací funkcí optimalizovanou pro tento systém. Navrhují, že kombinace + jejich důkazu a utreexo klienta umožní začít provozovat plný uzel téměř + okamžitě po stažení velmi malého množství dat. + + Co se týče použitelnosti prototypu, píší, že „implementovali prototyp důkazu + řetězce hlaviček a důkazu assumevalid stavu. Ten první je již použitelný, + druhý ještě vyžaduje vylepšení výkonnosti dokazování objemnějších bloků.” + Též pracují na validaci kompletních bloků včetně skriptů, ale podle jejich + slov musí dosáhnout minimálně 40násobného zrychlení. + + Vedle komprese stavu bitcoinového blockchainu též popisují protokol, který + může být použit pro tokenové protokoly s validací na straně klienta, který + používají například Taproot Assets od Lightning Labs (viz zpravodaj + [č. 195][news195 taro], *angl.*) nebo RGB ([č. 247][news247 rgb]). Když + Alice pošle Bobovi určité množství tokenů, musí Bob ověřit historii + každého předchozího transferu těchto konkrétních tokenů až zpět k jejich + vytvoření. V ideálním případě roste historie lineárně s množstvím + transferů. Ale chce-li Bob zaplatit Carol množstvím větším, než kolik + obdržel od Alice, bude muset zkombinovat některé z tokenů, které obdržel + od Alice, s jinými, které obdržel v jiných transakcích. Carol potom bude + muset ověřit obě historie. Toto se nazývá sloučení („merge”). Objevují-li + se sloučení často, dosahuje velikost historie, která se musí ověřit, + velikosti historie každého transferu tokenů mezi kterýmikoliv uživateli. + V bitcoinu, pro porovnání, ověřuje každý plný uzel každou transakci každého + uživatele. To není v tokenových protokolech s validací na straně klienta + nezbytnou nutností, ale jsou-li sloučení běžná, v podstatě se tak děje. + + Znamená to, že protokol přinášející kompresi bitcoinového stavu může být + upraven ke komprimování stavu historie tokenů, včetně těch s častými sloučeními. + Autoři popisují, jak by toho bylo možné dosáhnout. Jejich cílem je vytvořit + důkaz, že každý předchozí transfer tokenu se řídil pravidly tokenu a že + každý předchozí transfer byl řádně ukotven v bitcoinovém blockchainu. Alice + by potom mohla poslat Bobovi tokeny a poskytnout mu malý důkaz validity. + Bob by potom ověřením důkazu potvrdil, že transfer proběhl v určité blokové výšce + a že byl adresátem transferu. + + Ačkoliv je ve studii často zmiňována nutnost dodatečného výzkumu a vývoje, + přináší nám nadějný postup směrem ke [CoinWitness][coinwitness], funkci, + po které bitcoinoví vývojáři touží již více než deset let. + +## Čekání na potvrzení 2: incentivy + +_Krátká týdenní série o přeposílání transakcí, začleňování do mempoolu a výběru +transakcí k těžbě včetně vysvětlení, proč má Bitcoin Core přísnější pravidla, +než co je povoleno konsenzem, a jak mohou peněženky využít pravidla co nejefektivněji._ + +{% include specials/policy/cs/02-cache-utility.md %} + +## 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.* + +- **Vydán firmware verze 2.1.1 pro Passport:** + [Nejnovější firmware][passport 2.1.1] pro hardwarové podpisové zařízení Passport + podporuje posílání na [taprootové][topic taproot] adresy, [BIP85][] funkce a + zlepšuje nakládání s [PSBT][topic psbt] a vícenásobnými podpisy. + +- **Vydána MuSig peněženka Munstr:** + Beta software [Munstr][munstr github] používá [protokol Nostr][nostr protocol] + pro komunikaci potřebnou pro podepisování [MuSig][topic musig] transakcí + s vícenásobnými podpisy. + +- **Vydán Coffee, správce pluginů pro CLN:** + [Coffee][coffee github] je správce pluginů pro CLN, který vylepšuje instalaci, + konfiguraci, správu závislostí a upgradování [CLN pluginů][news22 plugins]. + +- **Vydáno Electrum 4.4.3:** + [Nejnovější vydání][electrum release notes] Electra obsahuje vylepšení výběru + mincí, nástroj pro analýzu soukromí UTXO, podporu krátkých identifikátorů kanálů + („Short Channel Identifiers,” SCID) a další opravy a vylepšení. + +- **Trezor Suite přidává podporu coinjoinů:** + Trezor Suite [oznámil][trezor blog] podporu [coinjoinů][topic coinjoin] za pomocí + koordinátora zkSNACKs. + +- **Lightning Loop používá MuSig2 ve výchozím nastavení:** + [Lightning Loop][news53 loop] nyní používá [MuSig2][topic musig] jako výchozí + protokol pro swap, což přinese nižší poplatky a větší soukromí. + +- **Mutinynet oznámil nový signet pro testování:** + [Mutinynet][mutinynet blog] je signet s 30sekundovými bloky, který poskytuje + testovací infrastrukturu včetně [prohlížeče bloků][topic block explorers], + zdroje testovacích bitcoinů a testovacích LN uzlů a LSP. + +- **Nunchuk přidává výběr mincí a podporu BIP329:** + Nejnovější androidová a iOS verze Nunchuku přidává [výběr mincí][nunchuk blog] + a export štítků peněženky podle [BIP329][]. + +- **MyCitadel Wallet přidává vylepšenou podporu miniscriptu:** + Vydání [v1.3.0][mycitadel v1.3.0] přidává pokročilejší možnosti [miniscriptu][topic miniscript] + včetně [časových zámků][topic timelocks]. + +- **Oznámen Edge Firmware pro Coldcard:** + Coinkite [oznámil][coinkite blog] experimentální firmware pro podpisové zařízení + Coldcard, který umožňuje vývojářům peněženek a pokročilým uživatelům experimentovat + s novými funkcemi. Prvotní vydání 6.0.0X přináší taprootové keypath platby, + [tapscriptové][topic tapscript] multisig platby a podporu [BIP129][]. + +## 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.* + +- [Core Lightning 23.05][] je vydání nejnovější verze této implementace LN. + Přináší mimo jiné podporu pro [zaslepené platby][topic rv routing], + [PSBT][topic psbt] verze 2 a flexibilnější správu poplatků. + +- [Bitcoin Core 23.2][] je údržbové vydání předchozí hlavní verze Bitcoin Core. + +- [Bitcoin Core 24.1][] je údržbové vydání současné verze Bitcoin Core. + +- [Bitcoin Core 25.0rc2][] je kandidátem na vydání příští hlavní verze Bitcoin Core. + +## Významné změny v kódu a dokumentaci + +*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] a [Lightning BOLTs][bolts repo].* + +- [Bitcoin Core #27021][] přidává rozhraní pro kalkulaci tzv. _schodku poplatku_ + („fee deficit”), který udává, kolik by stálo zarovnat výstupy nepotvrzených + rodičovských transakcí na daný jednotkový poplatek. Když algoritmy [výběru mincí][topic + coin selection] uvažují nad konkrétním výstupem s určitým jednotkovým + poplatkem, spočítají schodek poplatku jeho rodičů a výsledek odečtou + od jeho efektivní hodnoty. To zabraňuje, aby peněženka volila výstupy s příliš + velkým schodkem, jsou-li k dispozici vhodnější výstupy. V [následném PR][bitcoin + core #26152] bude toto rozhraní použito také k umožnění plateb s navýšeným poplatkem + („bump fees”), mají-li tak jako tak být zvoleny výstupy se schodkem. Zaručí to, + že nová transakce bude platit efektivní jednotkový poplatek vyžádaný uživatelem. + + Algoritmus je schopný vyhodnotit navyšování poplatků ve všech případech + díky posuzování kompletního souboru nepotvrzených transakcí spojených + s tímto nepotvrzeným UTXO a neuvažováním transakcí, které by byly s cíleným + jednotkovým poplatkem začleněny do bloku. Druhá metoda poskytuje agregované + navýšení poplatku napříč několika nepotvrzenými výstupy pro korigování + potenciálního překrývání předků. + +- [LND #7668][] přidává možnost připojit ke kanálu během otevírání soukromou + poznámku obsahující až 500 znaků. Tato poznámka může operátorovi připomenout + důvod otevření kanálu. + +- [LDK #2204][] přidává možnost nastavit uživatelský feature bit. Ten bude použit + při oznamování vlastním spojením nebo během zpracování oznámení od spojení. + +- [LDK #1841][] implementuje verzi bezpečnostních doporučení přidaných do + LN specifikace (viz [zpravodaj č. 128][news128 bolts803], *angl.*), podle které + by se uzel používající [anchor výstupy][topic anchor outputs] neměl pokoušet + vytvářet transakce se vstupy několika stran, je-li vyžadováno rychlé + potvrzení této transakce. To zabrání ostatním stranám konfirmaci + pozdržet. + +- [BIPs #1412][] přidává do [BIP329][] ([export štítků peněženky][topic wallet labels]) + pole pro ukládání informací o původu klíče. Dále specifikace nově doporučuje, + aby štítky nepřesáhly 255 znaků. + +{% include references.md %} +{% include linkers/issues.md v=2 issues="27021,7668,2204,1841,1412,26152" %} +[Core Lightning 23.05]: https://github.com/ElementsProject/lightning/releases/tag/v23.05 +[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://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 +[news195 taro]: /en/newsletters/2022/04/13/#transferable-token-scheme +[coinwitness]: https://bitcointalk.org/index.php?topic=277389.0 +[assumevalid]: https://bitcoincore.org/en/2017/03/08/release-0.14.0/#assumed-valid-blocks +[passport 2.1.1]: https://foundationdevices.com/2023/05/passport-version-2-1-0-is-now-live/ +[munstr github]: https://github.com/0xBEEFCAF3/munstr +[nostr protocol]: https://github.com/nostr-protocol/nostr +[coffee github]: https://github.com/coffee-tools/coffee +[news22 plugins]: /en/newsletters/2018/11/20/#c-lightning-2075 +[electrum release notes]: https://github.com/spesmilo/electrum/blob/master/RELEASE-NOTES +[trezor blog]: https://blog.trezor.io/coinjoin-privacy-for-bitcoin-11aaf291f23 +[mutinynet blog]: https://blog.mutinywallet.com/mutinynet/ +[news53 loop]: /en/newsletters/2019/07/03/#lightning-loop-supports-user-loop-ins +[nunchuk blog]: https://nunchuk.io/blog/coin-control +[mycitadel v1.3.0]: https://github.com/mycitadel/mycitadel-desktop/releases/tag/v1.3.0 +[coinkite blog]: https://blog.coinkite.com/edge-firmware/ diff --git a/_posts/cs/newsletters/2023-05-31-newsletter.md b/_posts/cs/newsletters/2023-05-31-newsletter.md new file mode 100644 index 0000000000..6e1ce6dfad --- /dev/null +++ b/_posts/cs/newsletters/2023-05-31-newsletter.md @@ -0,0 +1,306 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 253' +permalink: /cs/newsletters/2023/05/31/ +name: 2023-05-31-newsletter-cs +slug: 2023-05-31-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme popis návrhu nového protokolu spravovaného +joinpoolu a souhrn nápadu na přeposílání transakcí pomocí protokolu +Nostr. Též nechybí další příspěvek do naší krátké týdenní série +o pravidlech mempoolu a naše pravidelné rubriky se souhrnem zajímavých +otázek a odpovědí z Bitcoin Stack Exchange, seznamem nových softwarových +vydání a popisem významných změn v populárních páteřních bitcoinových +projektech. + +## Novinky + +- **Návrh na spravovaný joinpool protokol:** tento týden zaslal + Burak Keceli do emailové skupiny Bitcoin-Dev [příspěvek][keceli ark] + s popisem nápadu na _Ark_ („Archa”), nový protokol ve stylu + [joinpoolů][topic joinpools], ve kterém mohou vlastníci bitcoinů + volitelně využít protistranu jako spolu-podpisovatele všech transakcí + v rámci určitého časového úseku. Vlastníci mohou své bitcoiny buď + po uplynutí časového zámku jednostranně vybrat na blockchainu, nebo + je mohou okamžitě a bez požadavku na důvěru poslat offchain protistraně + před uplynutím časového zámku. + + Protistrana může, stejně jako jakýkoliv uživatel bitcoinu, kdykoliv + zveřejnit transakci utrácející pouze její prostředky. Je-li výstup + této transakce použit jako vstup offchainové transakce přenášející + prostředky od vlastníka protistraně, bude offchain transfer zneplatněn, + pokud se onchain transakce nepotvrdí během rozumně stanovené doby. + V tomto případě by protistrana nepodepsala svou onchain transakci, + dokud by neobdržela podepsanou offchain transakci. Tento způsob + poskytuje protokol pro atomický transfer od vlastníka k protistraně + 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. + + 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 + implementován nějaký návrh na [kovenanty][topic covenants] jako např. + [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify], + [SIGHASH_ANYPREVOUT][topic sighash_anyprevout] nebo [OP_CAT + + OP_CHECKSIGFROMSTACK][topic op_checksigfromstack], členové joinpoolu + by museli interagovat s protistranou pouze v coinjoinu, posílání + platby nebo obnově časového zámku offchainových prostředků. + + Každý coinjoin, platba nebo obnova vyžadují zveřejnění commitmentu + v onchainové transakci, avšak jedna malá transakce může obsahovat + v podstatě neomezené množství operací. K zajištění včasného dokončení + operací navrhuje Keceli, aby byly onchainové transakce posílány každých + pět sekund. Uživatelé by tak nemuseli čekat déle než tuto dobu. Každá + transakce je oddělená, není možné zkombinovat commitmenty z několika + transakcí pomocí [RBF][topic rbf] bez porušení těchto commitmentů + nebo spolupráce všech uživatelů přítomných v předchozích kolech, a tedy + přes 6,3 miliónů transakcí by mohlo být potřeba potvrdit každý rok + pro každou protistranu. Jednotlivé transakce jsou však malé. + + 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žší. + + Několik komentářů projevilo nad návrhem nadšení a těšilo se na budoucí + průzkum. + +- **Přeposílání transakcí po Nostru:** Joost Jager zaslal do emailové + skupiny [příspěvek][jager nostr] se žádostí o poskytnutí zpětné vazby + k nápadu Bena Carmana navrhující použít protokol [Nostr][] k přeposílání + transakcí, které mají potíže s propagací v bitcoinové P2P síti. + + Konkrétně se Jager zamýšlí nad možností použít Nostr pro přeposílání + balíčků transakcí, jako je například přeposílání rodičovské transakce + s příliš nízkým jednotkovým poplatkem spolu s jejím potomkem, který by + svým poplatkem rodiče kompenzoval. To by učinilo [CPFP][topic cpfp] + spolehlivějším a efektivnějším pro navyšování poplatků. Tato schopnost + se nazývá [přeposílání balíčků][topic package relay] („package relay”) + a vývojáři Bitcoin Core již pracují na její implementaci pro P2P síť. + Revizi návrhu a implementace přeposílání balíčků ztěžuje nutnost ujistit + se, že nepřinesou nové možnosti odepření služby (DoS) jednotlivým uzlům + ani těžařům (nebo obecně celé síti). + + Jager též poznamenal, že přeposílající servery Nostru mají možnost snadno + používat jiné druhy ochrany proti DoS, jako např. požadavek malé platby. + To by mohlo učinit přeposílání balíčků či jiných alternativních transakcí + praktické, i kdyby zlomyslné transakce nebo balíčky vedly k drobnému plýtvání + zdroji. + + V Jagerově příspěvku nechybí odkaz na [video][jager video], ve kterém + tuto funkci předvádí. Jeho příspěvek obdržel v době psaní pouze + několik reakcí, byť pozitivních. + +## Čekání na potvrzení 3: aukce blokového prostoru + +_Krátká týdenní [série][policy series] o přeposílání transakcí, začleňování do mempoolu a výběru +transakcí k těžbě včetně vysvětlení, proč má Bitcoin Core přísnější pravidla, +než co je povoleno konsenzem, a jak mohou peněženky využít pravidla co nejefektivněji._ + +{% include specials/policy/cs/03-bidding-for-block-space.md %} + +## 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/" %} + +- [Testování ořezávací logiky s bitcoind]({{bse}}118159) + Lightlike poukazuje na debugovací volbu `-fastprune`, která pro testovací + účely používá menší soubory bloků a nižší minimální ořezávací výšku. + +- [Jaká je hlavní motivace existence omezení počtu potomků?]({{bse}}118160) + Sdaftuar vysvětluje, že jelikož těžba i algoritmy vyloučení z mempoolu + (viz [zpravodaj č. 252][news252 incentives]) mají kvadratický čas 0(n²) + závislý na počtu předků nebo potomků, byly zavedeny tyto [konzervativní + limity][morcos limits]. + +- [Jak prospívá bitcoinové síti, provozuji-li uzel s větším než výchozím mempoolem?]({{bse}}118137) + Andrew Chow a Murch poznamenávají potenciální nevýhody mempoolu s větší + kapacitou než je výchozí nastavení. Mezi ně patří zhoršení propagace + znovu posílaných transakcí a propagace nahrazovaných transakcí bez signalizace. + +- [Jaký je nejvyšší možný počet vstupů a výstupů transakce?]({{bse}}118452) + Murch poskytuje počty vstupů a výstupů po aktivaci taprootu: + maximálně 3 223 (P2WPKH) výstupů nebo 1 738 (P2TR keypath) vstupů. + +- [Mohou být 2-ze-3 multisig prostředky obdrženy bez jednoho z xpubů?]({{bse}}118201) + Murch vysvětluje, že multisig sestavy, které nepoužívají holý („bare”) multisig + nebo které nebyly dříve použité ve stejném multisig výstupním skriptu, musí dát + pro utracení k dispozici všechny veřejné klíče. Poznamenává, že „zálohy + multisig peněženek musí zachovat jak soukromé klíče, tak i výstupní skripty“ a + doporučuje pro skripty používat [deskriptory][topic descriptors]. + +## 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 25.0][] je vydáním další hlavní verze Bitcoin Core. Vydání + přidává nové RPC volání `scanblocks`, zjednodušuje používání `bitcoin-cli`, + přidává do volání `finalizepsbt` podporu [miniscriptu][topic miniscript], + ve výchozím nastavení snižuje paměťové nároky s aktivovanou volbou `blocksonly` + a zrychluje reskenování peněženky po aktivaci [kompaktních filtrů bloků][topic + compact block filters] a další nové funkce, zlepšení výkonnosti a opravy + chyb. Další podrobnosti lze najít v [poznámkách k vydání][bcc rn]. + +## Významné změny v kódu a dokumentaci + +*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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Bitcoin Core #27469][] zrychluje prvotní stahování bloků (IBD, „Initial Block + Download”), pokud jsou používány peněženky. S touto změnou budou transakce + peněženky v bloku skenovány jen, pokud byl blok vytěžen po vzniku peněženky. + +- [Bitcoin Core #27626][] povoluje spojení, které náš uzel požádalo o poskytování + [přeposílání kompaktních bloků][topic compact block relay] ve velkokapacitním + režimu, vyžádat až tři transakce z posledního bloku, o kterém jsme toto + spojení informovali. Náš uzel pošle odpověď, i když jsme jim kompaktní blok + neposkytli. To umožní spojení, které obdrží kompaktní blok od jiného svého + spojení, vyžádat od nás kteroukoliv chybějící transakci. To může být užitečné, + pokud ono jiné spojení nereaguje. Naše spojení může díky tomu validovat blok + rychleji, a tak jej může dříve použít v časově kritických funkcích, jako je + těžba. + +- [Bitcoin Core #25796][] přidává nové volání `descriptorprocesspsbt`, + které může být použito k přidání informací do [PSBT][topic psbt], + které jim později usnadní podepsání nebo finalizování. [Deskriptor][topic + descriptors] předaný tomuto volání se použije k získání informací z + mempoolu a množiny UTXO (a také kompletní potvrzené transakce, pokud má + uzel aktivovánu volby `txindex`). Obdržené informace budou posléze + použity k doplnění PSBT. + +- [Eclair #2668][] zabraňuje Eclairu pokoušet se zaplatit za nárokování [HTLC][topic + htlc] větší poplatky, než kolik činí hodnota tohoto HTLC. + +- [Eclair #2666][] umožňuje vzdálenému spojení přijímajícímu [HTLC][topic htlc] + jej akceptovat, i kdyby potřebný poplatek za transakci snížil zůstatek na straně + spojení pod minimální rezervu kanálu. Rezerva kanálu existuje, aby spojení + ztratilo alespoň malé množství peněz v případě pokusu o zavření kanálu + se starým stavem. Avšak akceptuje-li spojení HTLC, které mu v případě + úspěšného vyřešení platí, budou mít více než je rezerva. A v případě + neúspěchu budou mít stejně jako před HTLC. + + Jedná se o řešení problému uvízlých prostředků, který se objevuje, + když by strana zodpovědná za placení poplatku musela platit větší + hodnotu, než je její aktuální zůstatek, i když je tato strana příjemcem + prostředků. Předchozí diskuzi o tomto problému lze nalézt ve [zpravodaji + č. 85][news85 stuck funds]. + +- [BTCPay Server 97e7e][] počíná nastavovat [BIP78][] parametr `minfeerate` + (minimální jednotkový poplatek) pro [payjoin][topic payjoin] platby. + Viz též [hlášení o chybě][btcpay server #4689], které vedlo k této změně. + +- [BIPs #1446][] činí drobou změnu a několik přídavků do [BIP340][], + specifikace [Schnorrových podpisů][topic schnorr signatures] pro bitcoinové + protokoly. Změna povoluje, aby podepisovaná zpráva měla libovolnou + délku (předchozí verze vyžadovaly 32 bytů). Viz související změna v knihovně + Libsecp256k1 popsaná ve [zpravodaji č. 157][news157 libsecp]. Změna nemá dopad + na způsob používání BIP340 v aplikacích, neboť podpisy používané v + [taprootu][topic taproot] i [tapscriptu][topic tapscript] (BIP + [341][bip341], resp. [342][bip342]) používají 32bytové zprávy. + + Přidán byl popis efektivního použití zpráv o libovolné délce a doporučení + o používání hashovaných tagovaných prefixů. Též poskytuje doporučení + pro zvýšení bezpečnosti během používání stejného klíče v různých doménách + (např. podepisování transakcí vs. podepisování prostého textu). + +{% include references.md %} +{% include linkers/issues.md v=2 issues="27469,27626,25796,2668,2666,4689,1446" %} +[policy series]: /cs/blog/waiting-for-confirmation/ +[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://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://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 new file mode 100644 index 0000000000..6a3bdda5b1 --- /dev/null +++ b/_posts/cs/newsletters/2023-06-07-newsletter.md @@ -0,0 +1,115 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 254' +permalink: /cs/newsletters/2023/06/07/ +name: 2023-06-07-newsletter-cs +slug: 2023-06-07-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme souhrn diskuze z emailové skupiny o použití +návrhu MATT ke správě joinpoolů a napodobení funkcí navrhovaného +`OP_CHECKTEMPLATEVERIFY`. Též nechybí další příspěvek do krátké +týdenní série o pravidlech mempoolu a naše pravidelné rubriky s +oznámeními o vydání software a popisem významných změn v populárních +bitcoinových páteřních projektech. + +## Novinky + +- **Využití MATT k napodobení CTV a správě joinpoolů:** Johan Torås + Halseth zaslal do emailové skupiny Bitcoin-Dev [příspěvek][halseth matt-ctv] + o možnosti využít opkód `OP_CHECKOUTPUTCONTRACTVERIFY` (COCV) z navrhovaného + konceptu Merklize All The Things (MATT, „všechno to zmerklujte“, viz + zpravodaje [č. 226][news226 matt], *angl.*, a [č. 249][news249 matt]) + k napodobení funkcionality jiného návrhu [OP_CHECKTEMPLATEVERIFY][topic + op_checktemplateverify]. Pro vytvoření commitmentu transakce s více + výstupy by každý výstup vyžadoval zvláštní COCV opkód (pro porovnání: + jediný CTV by stačil na commitment všech výstupů). To činí COCV méně + efektivním, avšak „dost jednoduchým na to, aby byl zajímavý.” + + Kromě popisu funkcionality nabízí Halseth také [demo][halseth demo] + s použitím [Tapsim][], nástroje pro „debugování tapscriptových transakcí […] + zaměřený na vývojáře, kteří si chtějí hrát se skriptem, debugovat a + pozorovat stav VM během výkonu skriptu.” + + V jiném vlákně [popsal][halseth matt-joinpool] Halseth použití MATT + s [OP_CAT][] k vytvoření [joinpoolu][topic joinpools] (též nazývaného + _coinpool_ nebo _payment pool_). I zde poskytuje [interaktivní demo][demo + joinpool] pomocí Tapsim. Také na základě svých experimentů navrhl několik + změn opkódů v MATT. Salvatore Ingala, původní autor návrhu MATT, se v + [odpovědi][ingala matt] vyjádřil pozitivně. + +## Čekání na potvrzení 4: odhad poplatků + +_Krátká týdenní [série][policy series] o přeposílání transakcí, začleňování do mempoolu a výběru +transakcí k těžbě včetně vysvětlení, proč má Bitcoin Core přísnější pravidla, +než co je povoleno konsenzem, a jak mohou peněženky využít pravidla co nejefektivněji._ + +{% include specials/policy/cs/04-feerate-estimation.md %} + +## 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 0.16.3-beta][] je údržbovým vydáním této populární implementace LN. + Poznámky k vydání uvádí, že „obsahuje pouze opravy chyb a má za cíl + optimalizovat nedávno přidanou logiku sledování mempoolu a také opravit + několik možných vektorů neúmyslného vynuceného zavření kanálu.” Pro + více informací o logice sledování mempoolu, viz [zpravodaj č. 248][news248 + lnd mempool]. + +## Významné změny v kódu a dokumentaci + +*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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Bitcoin Core #26485][] umožňuje RPC metodám, které jako parametr + přijímají objekt `options`, přijmout stejné položky jako jmenné + parametry. Například `bumpfee` může být voláno jako + `src/bitcoin-cli -named bumpfee txid fee_rate=10` namísto dřívějšího + `src/bitcoin-cli -named bumpfee txid options='{"fee_rate": 10}'`. + +- [Eclair #2642][] přidává RPC volání `closedchannels`, které poskytuje + data o vlastních zavřených kanálech. Viz též podobná změna v Core Lightning + popsaná ve [zpravodaji č. 245][news245 listclosedchannels]. + +- [LND #7645][] přidává kontrolu, že jakýkoliv jednotkový poplatek poskytnutý + uživatelem v rámci RPC volání `OpenChannel`, `CloseChannel`, `SendCoins` a + `SendMany` není nižší než hodnota relay fee rate (jednotkový poplatek + přeposílání). V poznámce je uvedeno: „Relay fee rate má pro různé backendy + trochu jiný význam. V bitcoind je to v podstatě max(relay fee, min mempool fee).“ + +- [LND #7726][] bude vždy utrácet všechna HTLC platící místnímu uzlu, pokud + kanál potřebuje vyrovnat zůstatky na blockchainu, včetně HTLC, jejichž + hodnota je nižší než hodnota poplatku za transakci. Porovnejte se změnou + v Eclair, již jsme popsali [minulý týden][news253 sweep], která programu + zabrání nárokovat [neekonomická][topic uneconomical outputs] HTLC. + Komentáře pod PR zmiňují, že LND pracuje na dalších změnách, které vylepší + jeho schopnost kalkulovat náklady a zisky vztažené k vyrovnávání HTLC + (offchain i onchain), což mu v budoucnosti umožní činit optimální rozhodnutí. + +- [LDK #2293][] odpojí a znovu připojí uzly, které přestanou odpovídat. Má to + zabránit problémům jiného LN software, které občas přestane odpovídat a vynutí + si zavření kanálů. + +{% include references.md %} +{% include linkers/issues.md v=2 issues="2642,26485,7645,7726,2293" %} +[policy series]: /cs/blog/waiting-for-confirmation/ +[news226 matt]: /en/newsletters/2022/11/16/#general-smart-contracts-in-bitcoin-via-covenants +[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://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://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://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 new file mode 100644 index 0000000000..d13fd90c5b --- /dev/null +++ b/_posts/cs/newsletters/2023-06-14-newsletter.md @@ -0,0 +1,183 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 255' +permalink: /cs/newsletters/2023/06/14/ +name: 2023-06-14-newsletter-cs +slug: 2023-06-14-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme souhrn diskuze o umožnění přeposílání transakcí +obsahující data v taprootové příloze a odkazujeme na návrh BIP na +tiché platby. Též nechybí další příspěvek v naší krátké týdenní sérii +o pravidlech mempoolu a pravidelné rubriky se souhrnem sezení Bitcoin +Core PR Review Clubu, oznámeními o nových vydáních a popisem významných +změn v populárních bitcoinových páteřních projektech. + +## Novinky + +- **Diskuze o taprootových přílohách:** Joost Jager zaslal do emailové + skupiny Bitcoin-Dev [příspěvek][jager annex] s žádostí o změnu v + pravidlech přeposílání transakcí a těžby v Bitcoin Core, aby umožnily + ukládání libovolných dat v rámci přílohy („annex”) v [taprootu][topic + taproot]. Toto pole je volitelnou součástí dat witnessu taprootových + transakcí. Je-li přítomno, musí se podpisy v taprootu a [tapscriptu][topic + tapscript] týkat i jeho dat (aby je nemohla třetí strana změnit, + přidat nebo odebrat), ale v současnosti nemá definovaný žádný další + význam. Je rezervováno pro budoucí upgrady protokolu, obzvláště + soft forky. + + I když se v minulosti objevily [návrhy][riard annex] na definování + formátu přílohy, nedočkaly se obecného přijetí ani implementace. Jager + navrhuje dva formáty ([1][jager annex], [2][jager annex2]), které + by mohly být použity k přidání libovolných dat způsobem, jež by + výrazně nekomplikoval pozdější pokusy o standardizaci svázanou + s případným soft forkem. + + Greg Sanders se v [odpovědi][sanders annex] tázal, jaká data by chtěl + Jager konkrétně v příloze ukládat, a popsal své vlastní využívání + přílohy v rámci testování protokolu [LN-Symmetry][topic eltoo] + s návrhem soft forku [SIGHASH_ANYPREVOUT][topic sighash_anyprevout] + pomocí Bitcoin Inquisition (viz [zpravodaj č. 244][news244 annex]). + Sanders také popsal problém s přílohami: v protokolech s více stranami + (jako je [coinjoin][topic coinjoin]) zavazuje každý podpis k příloze + vstupu obsahující tento podpis a ne k přílohám ostatních vstupů ve stejné + transakci. To znamená, že pokud by Alice, Bob a Mallory spolu podepsali + coinjoin, nemohou Alice ani Bob zabránit Mallorymu ve zveřejnění verze + transakce s větší přílohou, která by zpozdila konfirmaci. Jelikož Bitcoin + Core a ostatní implementace plných uzlů v současnosti nepřeposílají + transakce obsahující přílohy, nepředstavuje to zatím žádný problém. + Jager [odpověděl][jager annex4], že chce ukládat podpisy dočasných + klíčů pro druh [úschoven][topic vaults], který nevyžaduje soft fork, + a [navrhl][jager annex3], že tento problém s přeposíláním příloh + v některých protokolech s více stranami by mohl řešit [předchozí pokus][bitcoin + core #24007] v Bitcoin Core. + +- **Návrh BIP na tiché platby:** Josie Baker a Ruben Somsen [zaslali][bs sp] + do emailové skupiny Bitcoin-Dev návrh BIP na [tiché platby][topic silent + payments] („silent payments”), druh znovupoužitelného platebního kódu, + který při každém použití vygeneruje jedinečnou onchain adresu zabraňující + [linkování výstupů][topic output linking]. Linkování výstupů může výrazně + snížit soukromí uživatelů (včetně uživatelů, kteří se transakce přímo + neúčastní). Návrh obsahuje podrobnosti o svých výhodách, kompromisech + a možnostech využití. Pod [PR][bips #1458] se již objevilo několik + podnětných komentářů. + +## Čekání na potvrzení 5: pravidla pro ochranu zdrojů uzlů + +_Krátká týdenní [série][policy series] o přeposílání transakcí, začleňování do mempoolu a výběru +transakcí k těžbě včetně vysvětlení, proč má Bitcoin Core přísnější pravidla, +než co je povoleno konsenzem, a jak mohou peněženky využít pravidla co nejefektivněji._ + +{% include specials/policy/cs/05-dos.md %} + +## 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í.* + +[Umožni příchozím whitebind spojením agresivněji vyhazovat spojení +během plných slotů][review club 27600] je PR od Matthew Zipkina (pinheadmz), +které zlepšuje možnosti provozovatele uzlu v určitých případech nastavit +žádoucí spojení uzlu. Konkrétně pokud operátor explicitně povolí potenciální +příchozí spojení (například lehkého klienta pod jeho kontrolou), mohlo by se +bez tohoto PR stát, že by mu byl v určitém stavu odepřen pokus o připojení. + +Toto PR zvyšuje pravděpodobnost, že by bylo toto žádoucí spojení úspěšně navázáno. +Činí tak tím, že by vyhodilo jiné příchozí spojení, které bylo před PR nevyhoditelné. + +{% include functions/details-list.md + q0="Proč se toto PR týká pouze žádostí o příchozí připojení?" + a0="Náš uzel _iniciuje_ odchozí spojení; toto PR mění způsob, kterým + uzel _reaguje_ na žádost o příchozí spojení. Odchozí uzly mohou + být též vyhozeny, ale to má na starosti zcela odlišný algoritmus." + a0link="https://bitcoincore.reviews/27600#l-33" + + q1="Jaký dopad na návratovou hodnotu funkce `SelectNodeToEvict()` má + parametr `force`?" + a1="Nastavení `force` na `true` zajišťuje, že je vráceno příchozí spojení + bez `noban`, pokud existuje, i když by bylo jinak před vyhozením chráněno. + Bez tohoto PR by funkce nevrátila nic, pokud jsou všechna spojení před + vyhozením chráněna." + a1link="https://bitcoincore.reviews/27600#l-70" + + q2="Jak se tímto PR mění signatura funkce `EraseLastKElements()`?" + a2="Místo `void` vrací funkce poslední položku, která byla ze seznamu + kandidátů pro vyhození _odstraněna_. (Tento „chráněný” uzel + může být v případě potřeby vyhozen.) Avšak v důsledku diskuze + pod sezením review clubu bylo toto PR později zjednodušeno a tato + funkce zůstala nakonec nezměněna." + a2link="https://bitcoincore.reviews/27600#l-126" + + q3="`EraseLastKElements` bývalo template funkcí, toto PR však odstraňuje dva + template argumenty. Proč? Jaké jsou zápory této změny?" + a3="Tato funkce byla a (tímto PR) je volána s jedinečnými template argumenty, + není tedy potřeba, aby zůstala template. Nakonec byly změny této funkce + revertovány, neboť byly mimo rámec PR." + a3link="https://bitcoincore.reviews/27600#l-126" + + q4="Předpokládejme, že předáme funkci `SelectNodeToEvict()` seznam 40 kandidátů + na vyhození. Jaký je před a po PR teoretický maximální počet Tor uzlů, které + mohou být chráněny před vyhozením?" + a4="Před i po PR je počet 34 ze 40 za předpokladu, že nejsou příchozí a nemají + `noban`." + a4link="https://bitcoincore.reviews/27600#l-156" +%} + +## 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.* + +- [Core Lightning 23.05.1][] je údržbovým vydáním této implementace LN. + Poznámky k vydání udávají: „vydání obsahuje pouze opravy chyb způsobující + několik pádů. Doporučuje se upgrade z v23.05.” + +## Významné změny v kódu a dokumentaci + +*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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Bitcoin Core #27501][] přidává RPC volání `getprioritisedtransactions`, + které vrací mapu všech fee delta vytvořených uživateli pomocí + `prioritisetransaction` s txid jako klíči. Mapa též ukazuje, jsou-li + transakce v mempoolu. Viz též [zpravodaj č. 250][news250 getprioritisedtransactions]. + +- [Core Lightning #6243][] mění RPC volání `listconfigs`. Nově budou všechny + konfigurační informace obsaženy v jediném slovníku. Dále bude stav všech + konfiguračních voleb předávat restartovaným pluginům. + +- [Eclair #2677][] navyšuje výchozí `max_cltv` z 1 008 bloků (zhruba jeden + týden) na 2 016 bloků (zhruba dva týdny). Rozšiřuje tím maximální povolený + počet bloků před tím, než platba expiruje. Změna byla motivována uzly + rozšiřujícími svá rezervovaná časová okna, aby řešily HTLC expirující + (`cltv_expiry_delta`) kvůli vysokým onchain poplatkům. Podobné + změny byly začleněny do [LND][lnd max_cltv] i CLN. + +- [Rust bitcoin #1890][] přidává metodu pro spočítání operací s podpisy (sigops) + v netapscriptových skriptech. Počet sigops v bloku je omezen a kód výběru + transakcí během těžby v Bitcoin Core zachází s transakcemi s vysokým poměrem + sigops a velikosti (váhy), jakoby byly větší, čímž v důsledku snižuje jejich + jednotkový poplatek. Tato metoda může být důležitá pro všechny, kdo + vytváří nové transakce. + +{% 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://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://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://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 new file mode 100644 index 0000000000..8576dcd437 --- /dev/null +++ b/_posts/cs/newsletters/2023-06-21-newsletter.md @@ -0,0 +1,196 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 256' +permalink: /cs/newsletters/2023/06/21/ +name: 2023-06-21-newsletter-cs +slug: 2023-06-21-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme souhrn diskuze o rozšíření BOLT11 faktur o +požadavek na dvě platby. Též nechybí další příspěvek do naší krátké +týdenní série o pravidlech mempoolu a naše pravidelné rubriky +popisující změny v klientech a službách, nová vydání a změny v populárních +bitcoinových páteřních projektech. + +## Novinky + +- **Návrh na rozšíření BOLT11 faktur o požadavek na dvě platby:** Thomas + Voegtlin zaslal do emailové skupiny Lightning-Dev [příspěvek][v 2p] + s návrhem, aby byly [BOLT11][] faktury rozšířeny o volitelnou možnost + odesílatele vyžádat od plátce dvě oddělené platby, každou s vlastním + 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. + + 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 + kód a částku na poplatek placený dopředu (za onchain transakci) a druhý kód + 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. + + V době psaní byla diskuze stále aktivní. + +## Čekání na potvrzení 6: konzistence pravidel + +_Krátká týdenní [série][policy series] o přeposílání transakcí, začleňování do mempoolu a výběru +transakcí k těžbě včetně vysvětlení, proč má Bitcoin Core přísnější pravidla, +než co je povoleno konsenzem, a jak mohou peněženky využít pravidla co nejefektivněji._ + +{% include specials/policy/cs/06-consistency.md %} + +## 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.* + +- **Knihovny Greenlight open source:** + Nekustodiální CLN poskytovatel služeb [Greenlight][news162 greenlight] + [zveřejnil][decker twitter] [repozitář][github greenlight] klientských knihoven, + jazykových rozhraní a také [průvodce testovacím frameworkem][greenlight testing]. + +- **Debugger tapscriptu Tapsim:** + [Tapsim][github tapsim] je nástrojem pro debugování (viz [zpravodaj č. 254][news254 + tapsim]) a vizualizaci [tapscriptu][topic tapscript] používající btcd. + +- **Oznámen Bitcoin Keeper 1.0.4:** + [Bitcoin Keeper][] je mobilní peněženka podporující multisig, hardwarová podpisová + zařízení, [BIP85][] a díky poslednímu vydání také [coinjoin][topic coinjoin] + používající [protokol Whirlpool][gitlab whirlpool]. + +- **Oznámena lightningová peněženka EttaWallet:** + Nedávno byla [oznámena][ettawallet blog] mobilní [EttaWallet][github ettawallet] + s LN (díky LDK) a důrazem na použitelnost inspirovanou referenčním designem [daily + spending wallet][bitcoin design guide] od Bitcoin Design Community. + +- **Oznámeno ověření konceptu synchronizace hlaviček bloků založených na zkSNARKs:** + [BTC Warp][github btc warp] je ověřením konceptu lehkého synchronizačního klienta + používajícího zkSNARKs k prokázání a ověření řetězce hlaviček bitcoinových bloků. + Více podrobností lze nalézt v [blogovém příspěvku][btc warp blog]. + +- **Vydán lnprototest v0.0.4:** + Projekt [lnprototest][github lnprototest] je testovacím nástrojem pro LN včetně + „sady pomocných funkcí napsaných v Python3 navržených k usnadnění psaní nových + testů navrhovaných změn protokolu LN a testů existujících implementací.” + +## 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.* + +- [Eclair v0.9.0][] je novým vydáním této implementace LN, které „obsahuje + hodně přípravných prací důležitých (a složitých) lightningových funkcí: + [dual-funding][topic dual funding], [splicing][topic splicing] a [BOLT12 nabídky][topic + offers].” Tyto funkce jsou prozatím experimentální. Vydání také „dává nové + schopnosti pluginům, přináší opatření proti několika typům DoS a zlepšuje + výkonnost v mnoha oblastech.” + +## Významné změny v kódu a dokumentaci + +*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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [LDK #2294][] přidává podporu pro přehrávání [onion zpráv][topic onion messages] + a přináší LDK blíže k plné podpoře [nabídek][topic offers]. + +- [LDK #2156][] přidává podporu [keysend plateb][topic spontaneous payments], které + používají [zjednodušené platby s více cestami][topic multipath payments]. LDK dříve + podporovalo obě tyto technologie, avšak pouze pokud byly použité odděleně. + Platby s více cestami musí používat [skrytá data][topic payment secrets], ale + LDK dříve odmítalo keysend platby se skrytými daty. Byla také přidána chybová + hlášení, nastavení a varování, aby potenciálním problémům zabránila. + +{% include references.md %} +{% include linkers/issues.md v=2 issues="2294,2156" %} +[policy series]: /cs/blog/waiting-for-confirmation/ +[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 +[github greenlight]: https://github.com/Blockstream/greenlight +[greenlight testing]: https://blockstream.github.io/greenlight/tutorials/testing/ +[github tapsim]: https://github.com/halseth/tapsim +[news254 tapsim]: /cs/newsletters/2023/06/07/#vyuziti-matt-k-napodobeni-ctv-a-sprave-joinpoolu +[Bitcoin Keeper]: https://bitcoinkeeper.app/ +[gitlab whirlpool]: https://code.samourai.io/whirlpool/whirlpool-protocol +[github ettawallet]: https://github.com/EttaWallet/EttaWallet +[ettawallet blog]: https://rukundo.mataroa.blog/blog/introducing-ettawallet/ +[bitcoin design guide]: https://bitcoin.design/guide/daily-spending-wallet/ +[github btc warp]: https://github.com/succinctlabs/btc-warp +[btc warp blog]: https://blog.succinct.xyz/blog/btc-warp +[github lnprototest]: https://github.com/rustyrussell/lnprototest diff --git a/_posts/cs/newsletters/2023-06-28-newsletter.md b/_posts/cs/newsletters/2023-06-28-newsletter.md new file mode 100644 index 0000000000..bfcd41f77e --- /dev/null +++ b/_posts/cs/newsletters/2023-06-28-newsletter.md @@ -0,0 +1,209 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 257' +permalink: /cs/newsletters/2023/06/28/ +name: 2023-06-28-newsletter-cs +slug: 2023-06-28-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme popis nápadu na zabránění pinningu coinjoinových +transakcí a návrhu na spekulativní využití vysněných změn konsenzu. +Též nechybí další příspěvek do naší krátké týdenní série o pravidlech +mempoolu a pravidelné rubriky s populárními otázkami a odpověďmi z +Bitcoin Stack Exchange, novými vydáními a změnami v populárním +páteřním bitcoinovém software. + +## Novinky + +- **Přeposílání v3 transakcí zabraňuje pinningu coinjoinu:** Greg + Sanders ve svém [příspěvku][sanders v3cj] do emailové skupiny Bitcoin-Dev + popsal, jak by mohla navrhovaná [pravidla přeposílání v3 transakcí][topic v3 + transaction relay] pomoci vytvářet [coinjoinové][topic coinjoin] transakce + s více stranami, které by nebyly náchylné k [transaction pinningu][topic + transaction pinning]. Hrozba pinningu spočívá v možnosti jednoho z účastníků + použít svůj vstup k vytvoření konfliktní transakce, která by zabránila + coinjoinové transakci v konfirmaci. + + Sanders navrhuje, že by se mohly coinjoinové transakce této hrozbě vyhnout + tím, že by přiměly všechny účastníky nejprve utratit své bitcoiny na + skript, který by bylo možné utratit buď podpisy všech účastníků coinjoinu + nebo pouze tímto účastníkem po expiraci časového zámku. V případě + koordinovaného coinjoinu by musel koordinátor podepsat spolu s účastníkem + (nebo účastník sám po uplynutí časového zámku). + + Chtěl-li by účastník podepsat konfliktní transakci před uplynutím časového zámku, + musel by získat podpisy buď ostatních účastníků nebo koordinátora, což by + se mu podařilo jen v případě, kdy by podepsání bylo v zájmu všech (např. + v případě [navýšení poplatků][topic rbf]). + +- **Spekulativní využívání vysněných změn konsenzu:** Robin Linus + zaslal do emailové skupiny Bitcoin-Dev [příspěvek][linus spec] s nápadem + na utracení peněz na fragment skriptu, který nebude moci být spuštěn po + dlouhou dobu (např. 20 let). Byl-li by tento fragment interpretován + podle současných pravidel konsenzu, umožnil by těžařům za 20 let nárokovat + všechny prostředky. Fragment je však navržen tak, aby změna pravidel + konsenzu dala fragmentu odlišný význam. Linus dává za příklad opkód + `OP_ZKP_VERIFY`, který by v případě přidání do bitcoinu umožnil nárokovat + prostředky komukoliv, kdo poskytne důkaz s nulovou znalostí (Zero-Knowledge + Proof) na program s určitým hashem. + + Tento mechanismus by umožnil lidem utratit dnes bitcoin na jeden z těchto + skriptů a za důkaz o tomto utracení obdržet ekvivalentní množství bitcoinů + na [sidechainu][topic sidechains] nebo alternativním chainu (_jednosměrný + peg_). Bitcoiny na druhém chainu by mohly být opakovaně utráceny po dobu + 20 let, dokud by neexpiroval časových zámek. Poté by mohl současný vlastník + bitcoinů na druhém chainu vygenerovat ZKP důkaz, že bitcoiny vlastnil, + a použít jej k vyzvednutí uzamčeného vkladu na bitcoinovém mainnetu + (_obousměrný peg_). S dobrým návrhem ověřovacího programu by bylo vyzvednutí + snadné a flexibilní. + + Autoři poznamenávají, že lidé benefitující z tohoto konstruktu (např. + příjemci bitcoinů na druhém chainu) by se v podstatě sázeli, že nastane + změna pravidel konsenzu (např. že bude přidán `OP_ZKP_VERIFY`). To jim + dává podnět, aby změnu propagovali. Příliš silná propagace však může + ostatní odrazovat. Tento nápad v době psaní neobdržel žádné reakce. + +## Čekání na potvrzení 7: síťové zdroje + +_Krátká týdenní [série][policy series] o přeposílání transakcí, začleňování do mempoolu a výběru +transakcí k těžbě včetně vysvětlení, proč má Bitcoin Core přísnější pravidla, +než co je povoleno konsenzem, a jak mohou peněženky využít pravidla co nejefektivněji._ + +{% include specials/policy/cs/07-network-resources.md %} + +## 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/" %} + +- [Proč uzly akceptují bloky s tolika chybějícími transakcemi?]({{bse}}118707) + Uživatele commstarka zajímá, proč uzel akceptuje od těžaře blok, který neobsahuje + transakce, o kterých se na základě [šablony bloku][reference getblocktemplate] + předpokládalo, že budou začleněny. Existuje množství [nástrojů][miningpool observer], + které [porovnávají][mempool space] očekávané a skutečné bloky. Pieter Wuille + poznamenává, že kvůli inherentní [rozdílnosti mempoolů][waiting for confirmation 1] + napříč uzly způsobené propagací transakcí není možné vynucovat pravidla konsenzu + na základě obsahu bloků. + +- [Proč všichni říkají, že soft forky omezují existující sadu pravidel?]({{bse}}118642) + Pieter Wuille dává za příklad zpřísnění pravidla přidaná během [aktivace][topic soft + fork activation] soft forků [taprootu][topic taproot] a [segwitu][topic segwit]: + + - taproot přidal požadavek, aby se `OP_1 <32 bytes>` (taproot) výstup řídil + taprootovými pravidly konsenzu + - segwit přidal požadavek, aby se `OP_{0..16} <2..40 bytes>` (segwit) výstup + řídil segwitovými pravidly konsenzu a také vyžaduje pro předsegwitové výstupy prázdný witness + +- [Proč je výchozí limit LN kanálu nastaven na 16777215 sat?]({{bse}}118709) + Vojtěch Strnad osvětluje historii limitu 224 satoshi a motivaci pro + velké (wumbo) kanály. Též odkazuje na naše [téma velkých kanálů][topic large channels] + pro získání více informací. + +- [Proč během výběru transakcí používá Bitcoin Core hodnocení předků namísto jednotkového poplatku?]({{bse}}118611) + Sdaftuar vysvětluje, že důvodem použití jednotkového poplatku předků i hodnocení + předků algoritmem výběru transakcí pro těžbu je optimalizace výkonu. (Viz též + [Čekání na potvrzení 2: incentivy][waiting for confirmation 2].) + +- [Jak jsou definovány částky v LN platbách s více částmi (MPP)?]({{bse}}117405) + Rene Pickhardt píše, že [platby s více cestami][topic multipath payments] + nemají specifikovánu velikost jednotlivých částí a odkazuje na studie + zabývající se dělením plateb. + +## 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.* + +- [BTCPay Server 1.10.3][] je nejnovějším vydáním tohoto software pro zpracování + plateb. [Blogový příspěvek][btcpay 1.10] obsahuje přehled důležitých novinek + tohoto vydání. + +## Významné změny v kódu a dokumentaci + +*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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Core Lightning #6303][] přidává nové RPC volání `setconfig`, které umožňuje + měnit některá nastavení bez restartování démonu. + +- [Eclair #2701][] zaznamenává, kdy je přijato [HTLC][topic htlc] a kdy je + urovnáno. To umožňuje sledovat, jak dlouho bylo z pohledu uzlu HTLC + vyřizováno. Je-li mnoho HTLC nebo několik HTLC s vysokou hodnotou vyřizováno + po dlouhou dobu, může to značit probíhající [útok zahlcením kanálu][topic channel + jamming attacks]. Sledování trvání HTLC napomáhá k odhalování podobných + útoků a může je omezovat. + +- [Eclair #2696][] mění způsob nastavení jednotkových poplatků uživateli. + V předchozích verzích mohli uživatelé určit jednotkové poplatky + zvolením _cíle bloku_, např. nastavení na 6 znamenalo, že se Eclair + pokusí o potvrzení transakce během šesti bloků. Nově uživatel zvolí + mezi „pomalu,” „středně” a „rychle,” což se přeloží do konkrétního + jednotkového poplatku použitím konstanty nebo cíle. + +- [LND #7710][] dává pluginům a samotnému démonu přístup k datům + obdrženým dříve v rámci HTLC. To je nezbytné pro [zaslepování tras][topic + rv routing] a může být mimo jiné použito různými opatřeními proti + [zahlcení kanálu][topic channel jamming attacks]. + +- [LDK #2368][] umožňuje akceptovat nové kanály vytvořené spojením, které + používá [anchor výstupy][topic anchor outputs], ale vyžaduje, aby + měl ovládající program možnost každý kanál zvlášť akceptovat. Důvodem + je, že řádné vyrovnání anchor kanálů může po uživateli vyžadovat + vlastnictví jednoho či více UTXO s dostatečnou hodnotou. LDK jako + knihovna netuší, jaká UTXO mimo LN uživatelova peněženka vlastní. + Tento mechanismus dává programu možnost ověřit přítomnost tohoto UTXO. + +- [LDK #2367][] zpřístupňuje [anchor výstupy][topic anchor outputs] + běžnému uživateli API. + +- [LDK #2319][] umožňuje spojení vytvářet HTLC, které je zavázáno k platbě + nižší než je původní částka určená odesílatelem. Zbytek si může spojení + přisvojit jako poplatek. Tato možnost je užitečná pro vytváření [JIT + kanálů][topic jit channels], ve kterých spojení obdrží HTLC pro příjemce, + který ještě nemá kanál. Spojení vytvoří onchain transakci, která financuje + kanál a zavazuje k HTLC uvnitř tohoto kanálu, ale způsobuje dodatečné + náklady na poplatky při vytváření onchain transakce. Tento nový + poplatek může sloužit jako kompenzace. + +- [LDK #2120][] přidává podporu pro hledání trasy k příjemci, který používá + [zaslepné cesty][topic rv routing]. + +- [LDK #2089][] přidává funkci pro zpracování událostí, která usnadní peněženkám + navýšit poplatek za [HTLC][topic htlc], která musí být urovnána onchain. + +- [LDK #2077][] refaktoruje velké množství kódu pro snadné budoucí + přidání podpory [kanálů s oboustranným vkladem][topic dual funding]. + +- [Libsecp256k1 #1129][] implementuje techniku [ElligatorSwift][ElligatorSwift paper] + přinášející 64bytové kódování veřejného klíče, které je výpočetně + nerozeznatelné od náhodných dat. Modul `ellswift` poskytuje funkce + pro kódování a dekódování veřejných klíčů v novém formátu, funkce pro + generování nových náhodných klíčů a pro provádění ECDH výměny klíčů + s tímto kódováním. ECDH založené na ellswift bude použito v navazování + spojení v rámci protokolu [P2P šifrovaného transportu verze 2][topic v2 + p2p transport] ([BIP324][]). + +{% 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://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 +[mempool space]: https://mempool.space/graphs/mining/block-health +[waiting for confirmation 1]: /cs/blog/waiting-for-confirmation/#k-%C4%8Demu-je-mempool +[reference getblocktemplate]: https://developer.bitcoin.org/reference/rpc/getblocktemplate.html +[waiting for confirmation 2]: /cs/blog/waiting-for-confirmation/#incentivy +[ElligatorSwift paper]: https://eprint.iacr.org/2022/759 diff --git a/_posts/cs/newsletters/2023-07-05-newsletter.md b/_posts/cs/newsletters/2023-07-05-newsletter.md new file mode 100644 index 0000000000..c541435d0f --- /dev/null +++ b/_posts/cs/newsletters/2023-07-05-newsletter.md @@ -0,0 +1,84 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 258' +permalink: /cs/newsletters/2023/07/05/ +name: 2023-07-05-newsletter-cs +slug: 2023-07-05-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme další příspěvek do naší krátké týdenní série o +pravidlech mempoolu. Též nechybí naše pravidelné rubriky s oznámeními +o nových vydáních a popisem významných změn v populárních bitcoinových +páteřních projektech. + +## Novinky + +_V emailových skupinách Bitcoin-Dev a Lightning-Dev se tento týden neobjevily +žádné významné novinky._ + +## Čekání na potvrzení 8: pravidla jako rozhraní + +_Krátká týdenní [série][policy series] o přeposílání transakcí, začleňování do mempoolu a výběru +transakcí k těžbě včetně vysvětlení, proč má Bitcoin Core přísnější pravidla, +než co je povoleno konsenzem, a jak mohou peněženky využít pravidla co nejefektivněji._ + +{% include specials/policy/cs/08-interface.md %} {% assign timestamp="0:30" %} + +## 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.* + +- [Core Lightning 23.05.2][] je údržbovým vydáním této implementace LN uzlu, + které obsahuje opravy několika chyb, které mohou mít vliv na uživatele + produkčních nasazení. + +## Významné změny v kódu a dokumentaci + +*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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Bitcoin Core #24914][] načítá záznamy z databáze peněženky seřazené podle + druhu namísto procházení celé databáze dvakrát za účelem detekce závislostí. + Po této změně již nemusí být některé peněženky s poškozenými záznamy načteny, + avšak mohou být načteny předchozí verzí Bitcoin Core a migrovány na novou verzi. + +- [Bitcoin Core #27896][] odstraňuje experimentální sandboxing systémových volání + (syscall; viz [zpravodaj č. 170][news170 syscall], *angl.*). [Související report][Bitcoin + Core #24771] a jeho komentáře hovoří o nevýhodách této funkce včetně udržovatelnosti + seznamu volání a podpory OS, alternativy s lepší podporou a úvahy, zda + by syscall sandboxing měl být zodpovědností Bitcoin Core. + +- [Core Lightning #6334][] upravuje a rozšiřuje experimentální podporu + [anchor výstupů][topic anchor outputs] (viz prvotní implementace ve [zpravodaji č. + 111][news111 cln anchor], *angl.*). PR dále obsahuje aktivaci + experimentální podpory [HTLC][topic htlc] anchors s nulovými poplatky a + přidání nastavitelných kontrol, které zajistí, že má uzel dostatek prostředků, + pokud by potřeboval provozovat anchor kanál. + +- [BIPs #1452][] přidává do specifikace [BIP329][] pro exportní formát [popisků + peněženek][topic wallet labels] nový volitelný štítek `spendable`, který určuje, + zda je připojený výstup peněženkou utratitelný. Mnoho peněženek implementuje + funkce _kontroly mincí_, které uživateli umožňují určit, které výstupy nemá + algoritmus [výběru mincí][topic coin selection] zvažovat pro utracení, například + výstupy redukující soukromí uživatelů. + +- [BIPs #1354][] přidává [BIP389][] pro [deskriptory][topic descriptors] s více derivačními + cestami popsané ve [zpravodaji č. 211][news211 desc] (*angl.*). Umožňuje jedinému + deskriptoru specifikovat dvě svázané BIP32 cesty pro generování hierarchických + deterministických klíčů: jednu pro příchozí platby, druhou pro interní platby + (např. drobné). + +{% include references.md %} +{% include linkers/issues.md v=2 issues="24914,27896,6334,1452,1354,24771" %} +[policy series]: /cs/blog/waiting-for-confirmation/ +[news111 cln anchor]: /en/newsletters/2020/08/19/#c-lightning-3830 +[news211 desc]: /en/newsletters/2022/08/03/#multiple-derivation-path-descriptors +[core lightning 23.05.2]: https://github.com/ElementsProject/lightning/releases/tag/v23.05.2 +[news170 syscall]: /en/newsletters/2021/10/13/#bitcoin-core-20487 diff --git a/_posts/cs/newsletters/2023-07-12-newsletter.md b/_posts/cs/newsletters/2023-07-12-newsletter.md new file mode 100644 index 0000000000..049e2d990d --- /dev/null +++ b/_posts/cs/newsletters/2023-07-12-newsletter.md @@ -0,0 +1,173 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 259' +permalink: /cs/newsletters/2023/07/12/ +name: 2023-07-12-newsletter-cs +slug: 2023-07-12-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden popisujeme návrh na odstranění některých drobností ze specifikace LN, +které již nejsou relevantní, a přinášíme předposlední část naší krátké týdenní +série o pravidlech mempoolu. Též nechybí naše pravidelné rubriky se souhrnem +sezení Bitcoin Core PR Review Club, oznámeními o nových vydáních a kandidátech +na vydání a popisem významných změn v populárních bitcoinových páteřních +projektech. + +## Novinky + +- **Návrh na pročištění specifikace LN:** Rusty Russell zaslal do emailové + skupiny Lightning-Dev [příspěvek][russell clean up] s odkazem na + [PR][bolts #1092], ve kterém navrhuje odstranit některé funkce, které již + nejsou podporovány v moderních implementacích LN, a ponechané funkce + označit jako navždy podporované. Russell dále poskytl výsledky svého výzkumu + podporovaných funkcí veřejnými uzly dle jejich gossip zpráv. Výsledky + naznačují, že téměř všechny uzly podporují následující funkce: + + - *Onion zprávy s proměnlivou velikostí:* součástí specifikace jsou od + roku 2019 (viz [zpravodaj č. 58][news58 bolts619], *angl.*), tedy od doby, + kdy byly také představeny Type-Length-Value (TLV) pole. Tím byl nahrazen + původní formát šifrovaného onion routingu, který vyžadoval použití + zpráv o pevné délce a omezoval počet skoků na 20. Díky formátu s proměnlivou + velikostí je snazší přeposílat konkrétním skokům libovolná data. Jedinou + nevýhodou je, že celková velikost zprávy zůstává konstantní, čili nárůst + v objemu posílaných dat snižuje maximální počet skoků. + + - *Gossip dotazy:* součástí specifikace od roku 2018 (viz [BOLTs #392][]). + Umožňují uzlu vyžádat od svých spojení pouze podmnožinu gossip zpráv + poslaných jinými uzly v síti. Uzel může vyžádat například pouze nejnovější + aktualizace a ignorovat starší, čímž ušetří na datovém přenosu a čase + zpracování. + + - *Ochrana před ztrátou dat:* součástí specifikace od roku 2017 (viz + [BOLTs #240][]). Uzly používající tuto funkci posílají před novým připojením + informace o svém posledním stavu kanálu. Díky tomu může uzel detekovat, + že přišel o data. Dále nabádá uzel, který o data nepřišel, aby kanál uzavřel + ve svém posledním stavu. Viz [zpravodaj č. 31][news31 data loss] (*angl.*) + pro další informace. + + - *Statické klíče vzdálené strany:* součástí specifikace od roku 2019 + (viz [zpravodaj č. 67][news67 bolts642], *angl.*), umožňují uzlu požadovat, + aby každý channel update zavazoval k posílání ne[HTLC][topic htlc] prostředků + na stejnou adresu. Předtím mohla být v každém channel update použita jiná + adresa. Po této změně uzel, který používá tento protokol a ztratí + data, nakonec téměř vždy obdrží alespoň část svých prostředků na zvolenou + adresu, jako je například adresa v [HD peněžence][topic bip32]. + + První odpovědi k návrhu na pročištění byly pozitivní. + +## Čekání na potvrzení 9: návrhy pravidel + +_Krátká týdenní [série][policy series] o přeposílání transakcí, začleňování do mempoolu a výběru +transakcí k těžbě včetně vysvětlení, proč má Bitcoin Core přísnější pravidla, +než co je povoleno konsenzem, a jak mohou peněženky využít pravidla co nejefektivněji._ + +{% include specials/policy/cs/09-proposals.md %} + +## 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řestaň přeposílat transakce mimo mempool][review club 27625] je +PR od Marca Falkeho (MarcoFalke) zjednodušující klienta Bitcoin Core +odstraněním paměťové datové struktury `mapRelay`, která může způsobit vysokou +spotřebu paměti a není již více potřebná, respektive poskytuje pouze zcela +okrajové benefity. Tato mapa obsahuje transakce, které mohou či nemusí být +také v mempoolu. Někdy se používá pro generování odpovědi na požadavek +[`getdata`][wiki getdata]. + +{% include functions/details-list.md + q0="Jaké důvody stojí za odstraněním `mapRelay`?" + a0="Spotřeba paměti této datové struktury je neomezená. + I když v běžném případě nespotřebovává tolik paměti, je na pováženou, + je-li velikost jakékoliv datové struktury určena chováním vnějších + entit (spojení) a nemá žádné maximum. Takové případy mohou vnést DoS + zranitelnosti." + a0link="https://bitcoincore.reviews/27625#l-19" + + q1="Proč je těžké určit spotřebu paměti `mapRelay`?" + a1="Každý prvek v `mapRelay` je ukazatelem na transakci (`CTransaction`), + který může být sdílen s mempoolem. Druhý ukazatel na stejný objekt + používá velmi málo dodatečného prostoru v porovnání s jedním ukazatelem. + Je-li sdílená transakce odstraněna z mempoolu, veškerý jeho použitý prostor lze + připsat `mapRelay`. Čili spotřeba paměti `mapRelay` nezávisí pouze na počtu + a velikosti transakcí, ale také na tom, kolik jeho transakcí již není + v mempoolu. Toto není snadné dopředu určit." + a1link="https://bitcoincore.reviews/27625#l-33" + + q2="Jaký problém řeší přidaný `m_most_recent_block_txs`? + (Toto je seznam pouze těch transakcí, které jsou v posledním obdrženém bloku.)" + a2="Jelikož `mapRelay` není již k dispozici, nemohli bychom bez něj posílat + právě vytěžené transakce (z posledního bloku) spojením, která o něj požádají. + Tyto transakce již nejsou v našem mempoolu." + a2link="https://bitcoincore.reviews/27625#l-45" + + q3="Považujete za nezbytné přidávat `m_most_recent_block_txs`, + či by bylo možné odstranit `mapRelay` bez náhrady?" + a3="Mezi účastníky review klubu panovala u této otázky nejistota. + Někdo navrhl, že by mohl `m_most_recent_block_txs` vylepšit rychlost + propagace bloků, protože pokud naše spojení stále neobdrželo blok, který + my jsme právě obdrželi, může schopnost našeho uzlu poskytnout své transakce + pomoci zkompletovat našemu spojení [kompaktní blok][topic compact block relay]. + Jiný návrh byl, že může pomoci v případě chain splitu; pokud by naše spojení + bylo na jiném chainu než my, možná obdrželo transakci jinak než z bloku." + a3link="https://bitcoincore.reviews/27625#l-54" + + q4="Jaké jsou paměťové požadavky `m_most_recent_block_txs` v porovnání s + `mapRelay`?" + a4="Počet položek v `m_most_recent_block_txs` je ohraničen počtem transakcí + v bloku. Avšak paměťové požadavky jsou ještě menší, neboť položky v + `m_most_recent_block_txs` jsou sdílené ukazatele na transakce, na které + již ukazuje `m_most_recent_block`." + a4link="https://bitcoincore.reviews/27625#l-65" + + q5="Existují případy, ve kterých by v důsledku této změny byly transakce dostupné + po kratší nebo delší dobu než předtím?" + a5="Delší, pokud je doba od posledního bloku delší než 15 minut (což je čas, po + který zůstávají položky uloženy v `mapRelay`), jinak kratší. To je + přijatelné, neboť volba 15 minut byla spíše nahodilá. Avšak tato změna může + snížit dostupnost transakcí v případě chain splitu hlubšího než jeden blok + (ty jsou extrémně vzácné), protože neuchováváme transakce, které jsou obsaženy + pouze v bloku, jež není v našem řetězci." + a5link="https://bitcoincore.reviews/27625#l-70" +%} + +## 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.16.4-beta][] je údržbovým vydáním tohoto uzlu, které opravuje + memory leak postihující některé uživatele. + +## Významné změny v kódu a dokumentaci + +*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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Bitcoin Core #27869][] zobrazuje během načítání zastaralé peněženky varování + v rámci pokračující snahy popsané v [Bitcoin Core #20160][], jejímž cílem + je pomoci uživatelům migrovat zastaralé peněženky na peněženky s + [deskriptory][topic descriptors], jak bylo zmíněno ve zpravodajích [č. 125][news125 + descriptor wallets], [č. 172][news172 descriptor wallets] (oba *angl.*) a + [č. 230][news230 descriptor wallets]. + +{% include references.md %} +{% include linkers/issues.md v=2 issues="1092,392,240,20160,27869" %} +[news58 bolts619]: /en/newsletters/2019/08/07/#bolts-619 +[policy series]: /cs/blog/waiting-for-confirmation/ +[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://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 +[news172 descriptor wallets]: /en/newsletters/2021/10/27/#bitcoin-core-23002 +[news230 descriptor wallets]: /cs/newsletters/2022/12/14/#bude-bitcoin-core-moci-podepisovat-zpravy-i-se-zastaralymi-penezenkami diff --git a/_posts/cs/newsletters/2023-07-19-newsletter.md b/_posts/cs/newsletters/2023-07-19-newsletter.md new file mode 100644 index 0000000000..ee282b1bba --- /dev/null +++ b/_posts/cs/newsletters/2023-07-19-newsletter.md @@ -0,0 +1,146 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 260' +permalink: /cs/newsletters/2023/07/19/ +name: 2023-07-19-newsletter-cs +slug: 2023-07-19-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme poslední díl naší krátké týdenní série o pravidlech +mempoolu. Též nechybí naše pravidelné rubriky popisující významné změny +v klientech, službách a populárním bitcoinovém páteřním software. + +## Novinky + +_V emailových skupinách Bitcoin-Dev a Lightning-Dev se tento týden neobjevily +žádné významné novinky._ + +## Čekání na potvrzení 10: zapojte se + +_Poslední příspěvek do naší krátké týdenní [série][policy series] o +přeposílání transakcí, začleňování do mempoolu a výběru transakcí k +těžbě včetně vysvětlení, proč má Bitcoin Core přísnější pravidla, než +co je povoleno konsenzem, a jak mohou peněženky využít pravidla co +nejefektivněji._ + +{% include specials/policy/cs/10-get-involved.md %} + +## 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.* + +- **Peněženka od 10101 testuje sdílení prostředků mezi LN a DLC:** + 10101 oznámili [peněženku][10101 github] postavenou nad LDK a BDK, která uživatelům + umožňuje obchodovat deriváty nekustodiálním způsobem pomocí [DLC][topic dlc] + v [offchain kontraktu][10101 blog2], který též může být použit k posílání, přijímání + a přeposílání LN plateb. DLC závisí na orákulech, která vydávají [atestace][10101 blog1] + ceny použitím [adaptor podpisů][topic adaptor signatures]. + +- **Ohlášen LDK Node:** + Tým LDK [ohlásil][ldk blog] LDK Node [v0.1.0][LDK Node v0.1.0]. LDK Node je rustová + knihovna lightningového uzlu, která používá knihovny LDK a BDK. Přináší vývojářům + možnost rychle založit lightningový uzel a zároveň jim nechává vysoký stupeň + nastavitelnosti. + +- **Ohlášeno Payjoin SDK:** + [Payjoin Dev Kit (PDK)][PDK github] bylo [ohlášeno][PDK blog] jako rustová knihovna, + která implementuje [BIP78][] pro použití v peněženkách a službách, které si přejí + integrovat [payjoin][topic payjoin]. + +- **Ohlášena beta verze Validating Lightning Signer (VLS):** + VLS umožňuje oddělit lightningový uzel od klíčů, které kontrolují jeho prostředky. + Namísto používání lokálních klíčů přesměruje uzel běžící s VLS požadavky na podepsání + vzdálenému podpisovému zařízení. [Beta vydání][VLS gitlab] podporuje CLN a LDK, validační + pravidla vrstvy 1 i 2, možnost zálohy a obnovy a poskytuje referenční implementaci. + [Blogový příspěvek][VLS blog] s oznámením dále prosí o testování, funkční požadavky + a další zpětnou vazbu. + +- **BitGo přidává podporu MuSig2:** + BitGo [oznámilo][bitgo blog] podporu [BIP327][] ([MuSig2][topic musig]) a s ním + i nižší poplatky a vyšší soukromí v porovnání s ostatními podporovanými druhy adres. + +- **Peach přidává podporu RBF:** + Mobilní aplikace [Peach Bitcoin][peach website] pro peer-to-peer směnu [oznámila][peach tweet] + podporu pro navýšení poplatků pomocí [Replace-By-Fee (RBF)][topic rbf]. + +- **Peněženka Phoenix přidává podporu splicingu:** + ACINQ [oznámil][acinq blog] beta testování následující verze své mobilní lightningové + peněženky Phoenix. Peněženka podporuje jediný dynamický kanál, který se rebalancuje + pomocí [splicingu][topic splicing] a mechanismu připomínajícího [swap-in-potentiam][news233 sip]. + +- **Mining Development Kit žádá o zpětnou vazbu:** + Tým pracující na Mining Development Kit (MDK) [zveřejnil článek][MDK blog] o průběhu + vývoje hardware, software a firmware pro systémy pro těžbu bitcoinů. Příspěvek žádá komunitu + o zpětnou vazbu a připomínky k případům použití, šíři záběru a jejich přístupu. + +- **Binance přidává podporu lightningu:** + Binance [ohlásil][binance blog] podporu posílání (výběrů) a přijímání (vkladů) po + lightning network. + +- **Nunchuk přidává podporu CPFP:** + Nunchuk [ohlásil][nunchuk blog] podporu pro navyšování poplatků pomocí [Child-Pays-For-Parent + (CPFP)][topic cpfp], a to na straně odesílatele i příjemce transakce. + +## Významné změny v kódu a dokumentaci + +*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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Bitcoin Core #27411][] přestane oznamovat své Tor a I2P adresy spojením + na jiných sítích (jako jsou IPv4 nebo IPv6) a též nebude oznamovat své adresy + z [neanonymních sítí][topic anonymity networks] spojením na Tor a I2P. + Zabrání to možnosti párování běžných a anonymizovaných adres. CJDNS se tato + změna zatím týkat nebude. + +- [Core Lightning #6347][] přidává pluginům schopnost odebírat všechny události + použitím `*`. + +- [Core Lightning #6035][] přidává možnost vyžádat [bech32m][topic bech32] + adresu pro příjem vkladů na [P2TR][topic taproot] výstupy. Drobné z + transakce budou ve výchozím nastavení také poslány na P2TR výstup. + +- [LND #7768][] implementuje BOLTy [#1032][bolts #1032] a [#1063][bolts + #1063] (viz [zpravodaj č. 225][news225 bolts1032], *angl.*), které umožňují + konečnému příjemci platby (HTLC) akceptovat vyšší částku a delší expirační dobu, + než které byly požadované. Dříve se příjemci založení na LND drželi požadavku + z [BOLT4][], že částka a expirační doba se musí přesně rovnat. Tato + přesnost však dávala možnost drobnými změnami těchto hodnot odhalit, zda byl + následující skok konečným příjemcem. + +- [Libsecp256k1 #1313][] přináší automatické testování vývojovými verzemi kompilátorů + GCC a Clang. Testování může odhalit změny způsobující běh některého kódu + libsecp256k1 v proměnlivém čase, který může vést k [útokům postranními kanály][topic + side channels]. [Zpravodaj č. 246][news246 secp] poukazuje na jednu příležitost, + kde se tak mohlo stát, a [zpravodaj č. 251][news251 secp] odkazuje na jinou a na + oznámení o plánech na podobné testování. + +{% include references.md %} +{% include linkers/issues.md v=2 issues="27411,6347,6035,7768,1032,1063,1313" %} +[policy series]: /cs/blog/waiting-for-confirmation/ +[news225 bolts1032]: /en/newsletters/2022/11/09/#bolts-1032 +[news246 secp]: /cs/newsletters/2023/04/12/#libsecp256k1-0-3-1 +[news251 secp]: /cs/newsletters/2023/05/17/#libsecp256k1-0-3-2 +[10101 github]: https://github.com/get10101/10101 +[10101 blog1]: https://10101.finance/blog/dlc-to-lightning-part-1/ +[10101 blog2]: https://10101.finance/blog/dlc-to-lightning-part-2 +[LDK Node v0.1.0]: https://github.com/lightningdevkit/ldk-node/releases/tag/v0.1.0 +[LDK blog]: https://lightningdevkit.org/blog/announcing-ldk-node +[PDK github]: https://github.com/payjoin/rust-payjoin +[PDK blog]: https://payjoindevkit.org/blog/pdk-an-sdk-for-payjoin-transactions/ +[VLS gitlab]: https://gitlab.com/lightning-signer/validating-lightning-signer/-/releases/v0.9.1 +[VLS blog]: https://vls.tech/posts/vls-beta/ +[bitgo blog]: https://blog.bitgo.com/save-fees-with-musig2-at-bitgo-3248d690f573 +[peach website]: https://peachbitcoin.com/ +[peach tweet]: https://twitter.com/peachbitcoin/status/1676955956905902081 +[acinq blog]: https://acinq.co/blog/phoenix-splicing-update +[news233 sip]: /cs/newsletters/2023/01/11/#neinteraktivni-otvirani-ln-kanalu +[MDK blog]: https://www.mining.build/update-on-the-mining-development-kit/ +[binance blog]: https://www.binance.com/en/support/announcement/binance-completes-integration-of-bitcoin-btc-on-lightning-network-opens-deposits-and-withdrawals-eefbfae2c0ae472d9e1e36f1a30bf340 +[nunchuk blog]: https://nunchuk.io/blog/cpfp diff --git a/_posts/cs/newsletters/2023-07-26-newsletter.md b/_posts/cs/newsletters/2023-07-26-newsletter.md new file mode 100644 index 0000000000..edf576bef5 --- /dev/null +++ b/_posts/cs/newsletters/2023-07-26-newsletter.md @@ -0,0 +1,237 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 261' +permalink: /cs/newsletters/2023/07/26/ +name: 2023-07-26-newsletter-cs +slug: 2023-07-26-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden popisujeme protokol pro zjednodušení komunikace v rámci +kooperativního uzavření LN kanálu a přinášíme souhrn poznámek k +nedávnému setkání vývojářů LN. Též nechybí naše pravidelné rubriky +s oblíbenými otázkami a odpověďmi z Bitcoin Stack Exchange, oznámeními +o nových verzích a popisem významných změn v populárních bitcoinových +páteřních projektech. + +## Novinky + +- **Jednodušší zavírání LN kanálů:** Rusty Russell zaslal do emailové + skupiny Lightning-Dev [příspěvek][russell closing] s návrhem na + zjednodušení procesu, kterým dva LN uzly kooperativně zavírají kanál. + V novém protokolu uzavírání kanálu informuje jeden z uzlů svou protistranu, + že si přeje zavřít kanál, a určí výši transakčního poplatku, který zaplatí. + Tento iniciátor uzavření bude zodpovědný za celý poplatek, avšak + oba výstupy typické transakce kooperativního uzavření kanálu budou + okamžitě utratitelné, kterákoliv strana tedy bude moci použít + [navýšení poplatku pomocí CPFP][topic cpfp]. Nový protokol má též + kompatibilní způsob výměny informací s [protokoly vícenásobného + podpisu][topic multisignature] založenými na [MuSig2][topic musig], + který jsou součástí vyvíjených vylepšení LN mající za cíl navýšení + soukromí a snížení onchain nákladů. + + V době psaní neobdržel Russellův návrh v emailové skupině žádné komentáře, + avšak pod jeho [pull requestem][bolts #1096] se již několik reakcí + objevilo. + +- **Poznámky k LN summitu:** Carla Kirk-Cohen zaslala do emailové skupiny + 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. + +## 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/" %} + +- [Jak můžu ručně (na papíře) spočítat ze soukromého klíče klíč veřejný?]({{bse}}118933) + Andrew Poelstra nejprve poskytuje přehled manuálních ověřovacích technik, + jako je [codex32][news239 codex32], a poté nabízí kroky k ruční derivaci + veřejného klíče z klíče soukromého. Podle jeho odhadu by tento proces i s + různými optimalizacemi trval nejméně 1 500 hodin. + +- [Proč existuje 17 verzí nativního segwitu?]({{bse}}118974) + Murch vysvětluje, že [segwit][topic segwit] definoval pro [verzi witnessu][bip141 + witness program] 17 hodnot (0–16), aby využil existující opkódy konstant + `OP_0` … `OP_16`. Dále poznamenává, že další čísla by vyžadovala použití + méně datově efektivnějších opkódů `OP_PUSHDATA`. + +- [Vynucuje `0 OP_CSV`, aby utrácející transakce signalizovala nahraditelnost podle BIP125?]({{bse}}115586) + Murch poukazuje na [diskuzi][rbf csv discussion] potvrzující, že jelikož + [časový zámek][topic timelocks] `OP_CHECKSEQUENCEVERIFY` (CSV) i nahrazení poplatkem + ([RBF][topic rbf]) jsou [vynucovány ]({{bse}}87376) použitím pole + `nSequence`, musí transakce s výstupem s `0 OP_CSV` signalizovat nahraditelnost + dle [BIP125][]. + +- [Jak ovlivňují návrhy tras hledání cesty?]({{bse}}118755) + Christian Decker vysvětluje dva důvody, proč by příjemce v LN poskytl + odesílateli návrhy tras. Jeden důvod je, pokud by příjemce používal + [neoznámené kanály][topic unannounced channels]. Druhým důvodem je poskytnutí + odesílateli seznamu kanálů, které mají dostatečný zůstatek pro dokončení + platby. O této technice hovoří jako o „route boost.” + +- [Co znamená, že zabezpečení 256bitových ECDSA, a tedy i bitcoinových klíčů je 128 bitů?]({{bse}}118928) + Pieter Wuille objasňuje, že 256bitová ECDSA poskytuje pouze 128bitové + zabezpečení kvůli algoritmům, které mohou derivovat soukromý klíč z + veřejného klíče efektivněji než hrubou silou. Pokračuje vysvětlením + rozdílu mezi zabezpečením jednotlivých klíčů a zabezpečením [seedu][topic bip32]. + +## 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 2.3.0][] je vydáním tohoto middleware umožňujícího softwarovým peněženkám + komunikovat s podpisovými zařízeními. Přidává podporu pro osobně sestrojená + zařízení Jade a binárku pro běh hlavního programu `hwi` na zařízeních Apple + Silicon s MacOS 12.0+. + +- [LDK 0.0.116][] je vydáním tého knihovny pro tvorbu LN software. Obsahuje + podporu pro [anchor výstupy][topic anchor outputs] a [platby s více cestami][topic + multipath payments] s [keysend][topic spontaneous payments]. + +## Významné změny v kódu a dokumentaci + +*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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Bitcoin Core GUI #740][] aktualizuje dialog pro používání [PSBT][topic psbt]. + Nově označuje výstupy platící vlastní peněžence jako „vlastní adresa.” + To usnadní porozumění importovaných PSBT obzvláště v situacích, ve kterých + transakce vrací zbytek odesílateli. + +{% include references.md %} +{% include linkers/issues.md v=2 issues="740,1096" %} +[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 +[news226 jamming]: /en/newsletters/2022/11/16/#paper-about-channel-jamming-attacks +[news120 commitments]: /en/newsletters/2020/10/21/#simplified-htlc-negotiation +[news239 codex32]: /cs/newsletters/2023/02/22/#navrh-bip-pro-kodovani-seedu-codex32 +[bip141 witness program]: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#witness-program +[wiki script]: https://en.bitcoin.it/wiki/Script#Constants +[rbf csv discussion]: https://twitter.com/SomsenRuben/status/1683056160373391360 +[hwi 2.3.0]: https://github.com/bitcoin-core/HWI/releases/tag/2.3.0 +[ldk 0.0.116]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.0.116 diff --git a/_posts/cs/newsletters/2023-08-02-newsletter.md b/_posts/cs/newsletters/2023-08-02-newsletter.md new file mode 100644 index 0000000000..d467efe288 --- /dev/null +++ b/_posts/cs/newsletters/2023-08-02-newsletter.md @@ -0,0 +1,175 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 262' +permalink: /cs/newsletters/2023/08/02/ +name: 2023-08-02-newsletter-cs +slug: 2023-08-02-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme odkazy na přepisy nedávného setkání o specifikaci +LN a souhrn diskuze o bezpečnosti zaslepeného MuSig2 podepisování. +Též nechybí naše pravidelné rubriky s popisem nových vydání, kandidátů +na vydání a významných změn v populárních bitcoinových páteřních +projektech. + +## Novinky + +- **Přepisy pravidelných setkání o specifikaci LN:** Carla + Kirk-Cohen zaslala do emailové skupiny Lightning-Dev [příspěvek][kc scripts] + s oznámením, že byly pořízeny přepisy několika posledních videokonferencí, + ve kterých se diskutovaly změny specifikace LN. Přepisy jsou nyní + [dostupné][btcscripts spec] na webové stránce Bitcoin Transcripts. + A ještě jedna související informace: jak bylo diskutováno před několika + týdny během osobního setkání vývojářů LN, IRC skupina `#lightning-dev` na + [Libera.chat][] zaznamenala v poslední době významný vzestup aktivity. + +- **Bezpečnost zaslepeného podepisování v MuSig2:** Tom Trevethan zaslal + do emailové skupiny Bitcoin-Dev [příspěvek][trevethan blind] se žádostí + o posouzení kryptografického protokolu zamýšleného jako součást nasazení + [statechainů][topic statechains]. Cílem je nasazení služby, která by + používala své klíče k vytváření částečných [MuSig2][topic musig] + elektronických podpisů, aniž by se mohla cokoliv dozvědět o předmětu + či účelu podepisování. Služba by jen oznamovala, kolik podpisů s + konkrétními klíči vytvořila. + + Přispěvatelé do diskuze ze zabývali úskalími různých konstruktů + souvisejících s tímto problém či [obecně s vytvářením zaslepených + Schnorrových podpisů][generalized blind schnorr]. Zmíněn byl též + loňský [gist][somsen gist] od Rubena Somsena o protokolu zaslepené + [Diffieho-Hellmanovy (DH) výměny klíčů][dhke], který může být použit pro + zaslepený ecash. Předchozími implementacemi tohoto schématu jsou + například [Lucre][] a [Minicash][], další související implementací + je [Cashu][], která navíc integruje podporu bitcoinu a LN. Zájemcům + o kryptografii může tato diskuze přinést podnětné informace o + kryptografických technikách. + +## 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.* + +- [BTCPay Server 1.11.1][] je nejnovějším vydáním tohoto platebního procesoru. + Vydání přináší vylepšení ve vykazování faktur a pokladních procesech a + přináší nové funkce pro platební terminály. + +## Významné změny v kódu a dokumentaci + +*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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Bitcoin Core #26467][] umožňuje uživatelům při použití `bumpfee` + určit, který výstup transakce je určen pro zůstatek. Peněženka během + vytváření [nahrazující transakce][topic rbf] pro navýšení poplatků + odečítá hodnotu z tohoto výstupu. Ve výchozím stavu se peněženka pokouší + výstup pro drobné určit automaticky a pokud jej nenalezne, vytváří nový. + +- [Core Lightning #6378][] a [#6449][core lightning #6449] bude označovat + offchain příchozí [HTLC][topic htlc] za neúspěšné, je-li uzel neschopen + (či neochoten kvůli poplatkům) dosáhnout zrušení příslušného onchain HTLC. + Příklad: Alicin uzel přepošle Bobovu uzlu HTLC s expirací 20 bloků + a Bobův uzel přepošle Carol HTLC se stejným platebním kódem s expirací + 10 bloků. Nato je kanál mezi Bobem a Carol nuceně uzavřen onchain. + + Po expiraci po 10 blocích nastane situace, která by se však často přihodit + neměla: Bobův uzel se buď bude snažit o refundaci, ale tato transakce + se nepotvrdí, nebo se rozhodne, že náklady na získání refundace by byly + vyšší než její výsledek a refundační transakci nevytvoří. Před touto + změnou by Bobův uzel nevytvořil offchain zrušení HTLC od Alice, protože + by to umožnilo Alici nechat si peníze, které mu přeposlala, a Carol + nárokovat peníze přeposlané jí Bobem. Bob by tak přišel o hodnotu HTLC. + + Avšak po expiraci HTLC od Alice po 20 blocích může Alice nuceně uzavřít + kanál a tím se pokusit obdržet refundaci částky, kterou přeposlala + Bobovi. Její software tak může učinit automaticky, aby zabránil + ztrátě Aliciných prostředků nárokováním od uzlů ležících dále v platební + cestě. Pokud ale nuceně uzavře kanál, může se ocitnout ve stejné + situaci jako Bob: buď není schopna refundaci nárokovat nebo se o ní z + ekonomických důvodů ani nepokusí. Znamená to, že kanál mezi Alicí + a Bobem by byl zavřen zcela bezdůvodně. Tento problém by se mohl opakovat + několikrát po cestě dále od Alice. Jeho výsledkem by byl řetězec + nechtěně zavřených kanálů. + + V rámci tohoto PR je problém řešen tak, že Bob bude čekat co nejdelší + rozumnou dobu před tím, než bude refundaci nárokovat. Pokud se mu to + nepodaří, vytvoří offchain zrušení HTLC od Alice, což jim umožní pokračovat + v provozování kanálu, i když tím Bob může přijít o hodnotu HTLC. + +- [Core Lightning #6399][] přidává podporu pro příkaz `pay`, který + zaplatí faktury vytvořené lokálním uzlem. Může se díky němu zjednodušit + kód software, který spravuje účty a volá CLN. Podrobnosti lze + nalézt v nedávném [vlákně][fiatjaf custodial] v emailové skupině. + +- [Core Lightning #6389][] přidává volitelnou službu CLNRest, „jednoduchý + plugin napsaný v Pythonu, který překládá RPC volání na REST. Díky + generování endpointů REST API umožňuje v pozadí volat RPC metody Core + Lightningu a vracet odpovědi v JSON.” [Dokumentace][clnrest doc] + obsahuje další informace. + +- [Core Lightning #6403][] a [#6437][core lightning #6437] přemisťují + mechanismus autorizace a autentizace (pomocí protokolu _runes_, tedy „runy”) z + pluginu commando (viz [zpravodaj č. 210][news210 commando], *angl.*) + do samotného jádra. Díky tomu bude moci být používán i dalšími pluginy. + Dále bylo aktualizováno i několik příkazů souvisejících s vytvářením, + rušením a přejmenováním run. + +- [Core Lightning #6398][] rozšiřuje RPC volání `setchannel` o novou volbu + `ignorefeelimits`, díky které nebude bráno v potaz nastavení minimálního + onchain poplatku kanálu. Umožní to druhé, vzdálené straně nastavit jednotkový + poplatek pod minimum místního uzlu. Volba může být použita pro obcházení + potenciálních chyb v jiných implementacích LN uzlů či pro urovnání sporů + o poplatky v případě problémů s částečně důvěryhodnými kanály. + +- [Core Lightning #5492][] přidává staticky definované uživatelské trasovací + body (User-level Statically Defined Tracepoints, USDT). Umožní uživatelům + sledovat operace uvnitř uzlu za účelem ladění, aniž by významně + utrpěla výkonnost. [Zpravodaj č. 133][news133 usdt] (*angl.*) informuje + o předešlém začlenění USDT do Bitcoin Core. + +- [Eclair #2680][] přidává podporu pro protokol _quiescence_, který je vyžadován + pro [splicing ][topic splicing] podle návrhu v [BOLTs #863][]. + Protokol quiescence („chvíle ticha”) dočasně zabraňuje oběma uzlům sdílejícím + kanál posílat si navzájem nová [HTLC][topic htlc], dokud se neukončí nějaká + operace, jako je například vyjednávání o parametrech splicingu a kooperativní + podepisování onchain transakcí pro splice-in a splice-out. HTLC přijatá + během vyjednávání o splicingu a podepisování by mohla zneplatnit předchozí + vyjednávání a podpisy, je tedy jednodušší pozastavit přeposílání HTLC po + nezbytnou dobu. Eclair již splicing podporuje, ale tato změna + jej přináší blíže k protokolu ostatních implementací LN uzlů. + +- [LND #7820][] přidává do RPC volání `BatchOpenChannel` všechna pole, která + jsou obsažena v nedávkovém volání `OpenChannel` s dvěma výjimkami: + `funding_shim` (není pro dávkové otvírání kanálů potřebné) a `fundmax` + (neboť při otevírání většího množství kanálů nelze alokovat všechny prostředky + jedinému z nich). + +- [LND #7516][] rozšiřuje RPC volání `OpenChannel` o nový parametr `utxo`, + který umožní určit jedno či více UTXO, která by měla být použita pro + financování kanálu. + +- [BTCPay Server #5155][] přidává do administrace stránku s výkazy o platbách + a onchain peněženkách a možnost exportovat je do CSV. Její funkčnost lze rozšířit + pluginy. + +{% include references.md %} +{% 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://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://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://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 new file mode 100644 index 0000000000..994fc93ce4 --- /dev/null +++ b/_posts/cs/newsletters/2023-08-09-newsletter.md @@ -0,0 +1,366 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 263' +permalink: /cs/newsletters/2023/08/09/ +name: 2023-08-09-newsletter-cs +slug: 2023-08-09-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden varujeme před závažnou zranitelností v nástroji Libbitcoinu +Bitcoin Explorer (bx), přinášíme souhrn diskuze o návrhu ochrany před +odepřením služby, oznámení plánu na testování a sběr dat HTLC atestací +a popis dvou navrhovaných změn pravidel přeposílání transakcí v +Bitcoin Core. Též nechybí naše pravidelné rubriky se souhrnem sezení +Bitcoin Core PR Review Club, oznámeními o nových verzích a popisem +významných změn v populárních bitcoinových páteřních projektech. + +## Upozornění + +- **Závažná zranitelnost v Libbitcoin Bitcoin Explorer:** pokud jste + pomocí příkazu `bx seed` vytvořili [BIP32][topic BIP32] seed, tajný + seznam slov podle [BIP39][], soukromé klíče či jiné bezpečnostní + kódy, zvažte okamžité přesunutí prostředků na jinou, bezpečnou adresu. + V rubrice Novinky uvádíme další podrobnosti. + +## Novinky + +- **Návrh na ochranu před odepřením služby (DoS):** Anthony + Towns zaslal do emailové skupiny Lightning-Dev [odpověď][towns dos] + k sekci poznámek ze setkání vývojářů LN (viz [zpravodaj č. 261][news261 + jamming]) zabývající se [zahlcením kanálu][topic channel jamming attacks]. + Poznámky tvrdily, že „náklady na odrazení útočníka jsou pro čestného + uživatele nepřiměřené a náklady, které by byly pro čestného uživatele + přiměřené, jsou příliš nízké na odrazení útočníka.” + + Towns navrhl jiný směr, než pokoušet se útočníka přeplatit: náklady + sdílené útočníky i čestnými uživateli by měly odrážet skutečné + náklady provozovatelů uzlů na poskytování služeb. Tímto způsobem + by provozovatel uzlu, který vydělává na poskytování služeb čestným + uživatelům, vydělával, kdyby jeho služeb začali využívat i útočníci. + Pokud by se útočník pokusil o odepření služeb čestným uživatelům + nadměrným využíváním zdrojů uzlu, měli by provozovatelé uzlů + motivaci (vyšší výdělek) navýšit tyto zdroje. + + Jako návrh na fungování tohoto systému oživil Towns několik let + starou myšlenku (viz [zpravodaj č. 86][news86 hold fees], *angl.*) + na kombinaci dopředných commitment poplatků a zpětných poplatků za + držení, které by byly placeny nad rámec běžných poplatků za úspěšnou + platbu. Během propagace HTLC od Alice (plátce) k Bobovi (přeposílající + uzel) by Alice zaplatila drobný dopředný commitment poplatek; Bobova + část tohoto poplatku by odpovídala jeho nákladům na zpracování HTLC + (např. datový přenos). Bob by po přijetí HTLC začal pravidelně + platit Alici malé zpětné poplatky za držení až do doby, kdy by bylo + HTLC vyřízeno. Tím by Alice obdržela kompenzaci za dobu čekání na + potvrzení či zrušení její platby. Pokud by Bob okamžitě přeposlal + platbu Carol, zaplatil by jí mírně nižší dopředný commitment + poplatek, než který obdržel od Alice (rozdíl by byl jeho kompenzací), + a Carol by mu poskytla mírně vyšší zpětný poplatek za držení + (rozdíl by byl opět jeho kompenzací). Dokud žádný z přeposílajících + uzlů nebo příjemce nepozdrží HTLC, byl by jediným nákladem navíc + oproti běžnému poplatku za úspěšnou platbu onen malý dopředný + commitment poplatek. Pokud by však příjemce nebo kterýkoliv jiný + uzel po cestě platbu pozdržel, byl by nakonec zodpovědný za placení + všech zpětných poplatků za držení. + + Clara Shikhelman [odpověděla][shikhelman dos], že zpětné poplatky + za držení placené během určité doby by mohly snadno převýšit částku, + kterou by uzel vydělal za úspěšně dokončenou platbu. Záškodnické uzly + by tím byly motivovány ke zneužívání tohoto mechanismu k výběru + poplatků od svých protistran. Popsala obtíže, se kterými by se potýkal + systém podobný tomu popsanému Townsem. Towns v [odpovědi][towns dos2] + přinesl protiargumenty a přidal shrnutí: „Věřím, že i když se současná + implementace zaměřuje na techniky založené na reputaci, finanční odrazování + od DoS má i nadále šanci stát se v případě zájmu zajímavým předmětem + výzkumu.” + +- **Testování a sběr dat HTLC atestací:** Carla Kirk-Cohen a Clara + Shikhelman zaslaly do emailové skupiny Lightning-Dev [příspěvek][kcs + endorsement] s oznámením, že vývojáři spříznění s Eclairem, Core + Lightningem a LND pracují na implementaci části protokolu [HTLC + atestací][topic htlc endorsement] („HTLC endorsement”), aby mohli + začít sbírat relevantní data. Navrhli též soubor dat, jehož sběr + testovacími uzly by byl pro výzkum užitečný. Mnoho položek bude obsahovat + náhodná data, aby nemohlo dojít k úniku soukromých informací. Testování + má proběhnout v několika fázích, v každé se budou účastnící se uzly + chovat jiným způsobem. + +- **Návrhy změn výchozích pravidel přeposílání v Bitcoin Core:** Peter Todd + otevřel v emailové skupině Bitcoin-Dev dvě vlákna související s jeho + pull requesty měnící výchozí pravidla přeposílání transakcí v Bitcoin Core. + + - *Full RBF ve výchozím stavu:* [první vlákno][todd rbf] a [pull + request][bitcoin core #28132] navrhují v příštích verzích Bitcoin + Core učinit [full RBF][topic rbf] výchozí volbou. V současnosti + ve výchozím stavu Bitcoin Core přijímá do mempoolu a přeposílá + nahrazení nepotvrzených transakcí pouze, obsahuje-li nahrazovaná + transakce [BIP125][] příznak signalizující volitelnou nahraditelnost + (a pokud obě transakce, původní i nahrazující, splňují několik dalších + pravidel). Tato situace se nazývá _opt-in RBF_. Konfigurační volba + `-mempoolfullrbf` umožňuje provozovatelům uzlů namísto toho nastavit + přijímání nahrazení jakékoliv nepotvrzené transakce, i těch + neobsahujících BIP125 příznak. Zde hovoříme o _full RBF_ (viz + [zpravodaj č. 208][news208 rbf], *angl.*). Dle Toddova návrhu + by byl full RBF výchozí volbou, avšak provozovatelé uzlů by měli + možnost zvolit opt-in RBF. + + Peter Todd tvrdí, že tato změna je odůvodněná, protože dle jeho měření + (které bylo [zpochybněno][towns rbf]) má významná část těžařů nastaveno + full RBF a existuje také dostatečné množství přeposílajících uzlů + s touto volbou (aby nahrazení bez příznaku byla přeposlána k + těžařům). Dále říká, že neví o žádné aktivní službě, která by v + současnosti přijímala nepotvrzené onchain transakce jako konečnou + platbu. + + - *Odstranění omezení `OP_RETURN` výstupů:* [druhé vlákno][todd opr] + a [pull request][bitcoin core #28130] navrhují odstranit z Bitcoin Core + omezení transakcí, které obsahují výstupní skripty začínající opkódem + `OP_RETURN` (_OP_RETURN výstupy_). V současnosti Bitcoin Core ve výchozím + stavu nepřeposílá ani nepřijímá do mempoolu transakce, které mají více + než jeden `OP_RETURN` výstup nebo mají `OP_RETURN` výstup se skriptem + větším než 83 bytů (tedy více než 80 bytů libovolných dat). + + Podnětem umožnění přeposílání a těžení malého množství dat v rámci + `OP_RETURN` výstupů byly transakce, které předtím obsahovaly data + v jiných druzích výstupů, které se ukládaly v množině UTXO, většinou + nadobro. `OP_RETURN` výstupy nemusí být uloženy v množině UTXO, nepřináší + tedy takové potíže. Od té doby začali někteří lidé ukládat velká množství + dat ve witnessech transakcí. + + Pull request by ve výchozím stavu povolil jakékoliv množství `OP_RETURN` + výstupů a jakékoliv množství dat v `OP_RETURN` výstupech. Transakce by + se i nadále musely řídit dalšími pravidly přeposílání (např. celková + velikost transakce musí být menší než 100 000 vbytů). V době psaní + zpravodaje byly názory na pull request smíšené. Někteří vývojáři + se obávají, že uvolněná pravidla by navýšila množství nefinančních dat + uložených v blockchainu. Jiní tvrdí, že neexistuje žádný důvod, proč + bránit lidem ve využívání `OP_RETURN` výstupů, když se již používají + jiné způsoby ukládání dat v blockchainu. + +- **Odhalení bezpečnostní zranitelnosti v Libbitcoin Bitcoin Explorer:** + několik bezpečnostních výzkumníků vyšetřujících nedávnou ztrátu bitcoinů + mezi uživateli Libbitcoin [zjistilo][milksad], že příkaz `seed` Bitcoin + Exploreru (bx) v rámci tohoto programu generuje pouze zhruba čtyři + miliardy jedinečných hodnot. Útočník, který předpokládal, že byl tento + program použit pro tvorbu soukromých klíčů nebo peněženek s určitou + derivační cestou (např. BIP39), mohl potenciálně během jediného dne + na běžném počítači prohledat všechny možné peněženky a tím ukrást + prostředky na ně přijaté. Jedna taková krádež se pravděpodobně udála + 12. července 2023 se ztrátou téměř 30 BTC (v té době zhruba 19 miliónů + korun). + + Několik postupů podobných výše uvedenému bylo [nalezeno][mb milksad] v + knize _Mastering Bitcoin_, na [domovské stránce dokumentace][bx home] + Bitcoin Exploreru a mnoha dalších místech dokumentace (např. [1][bx1], + [2][bx2], [3][bx3]). Nikde v této dokumentaci nebylo jasné varování o + nebezpečnosti kromě [online dokumentace][seed doc] příkazu `seed`. + + Doporučujeme, aby každý, kdo mohl použít `bx seed` ke generování peněženek + nebo adres, navštívil [stránku][milksad] s popisem zranitelnosti a zvážil + použití jejich služby k otestování hashů zranitelných seedů. Pokud jste + použili shodný postup jako útočník, vaše bitcoiny byly již zřejmě ukradené. + S variacemi postupu však máte ještě šanci přesunout bitcoiny do bezpečí. + Pokud se domníváte, že vaše peněženka používá Libbitcoin, informujte prosím + vývojáře o této zranitelnosti a požádejte je o prošetření. + + Děkujeme výzkumníkům za úsilí vynaložené na přípravu [zodpovědného + zveřejnění][topic responsible disclosures] zranitelnosti [CVE-2023-39910][]. + +## 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í.* + +[Tiché platby: naimplentuj BIP352][review club 28122] je PR od uživatele josibake, +které podniká první kroky v přidání [tichých plateb][topic silent payments] +(„silent payments”) do peněženky Bitcoin Core. Toto PR implementuje pouze logiku +z [BIP352][] a nepřináší žádné změny peněženky. + +{% include functions/details-list.md + q0="Proč PR přidává vlastní ECDH hashovací funkci a nepoužívá tu poskytovanou + `secp256k1`?" + a0="Ve skutečnosti _nechceme_ hashovat výsledek ECDH; vlastní funkce + neaplikuje `sha256` na výsledek ECDH operace. To je potřeba, pokud + tvůrce transakce nemá pod kontrolou všechny její vstupy. Absence hashování + výsledku během ECDH umožňuje jednotlivým účastníkům provést ECDH + pouze s jejich soukromým klíčem a předat částečné ECDH dále. Výsledky + částečných ECDH mohou být sečteny a poté lze provést zbytek protokolu." + a0link="https://bitcoincore.reviews/28122#l-126" + + q1="PR přidává funkce pro kódování a dekódování adres tichých plateb. Proč + nemůžeme jednoduše přidat adresy tichých plateb jako další variantu + `CTxDestination` a použít existující třídy a funkce?" + a1="Adresa tiché platby totiž nekóduje žádný konkrétní výstupový skript + (není to `scriptPubKey`). Kóduje namísto toho veřejné klíče potřebné + k _odvození_ skutečného výstupového skriptu, který také závisí na + vstupech vaší transakce tiché platby. Tedy namísto poskytování + `scriptPubKey` pro přijetí platby (tradiční adresy) vám tichá platba + dá veřejné klíče pro ECDH a protokol promění tento sdílený tajný + kód v `scriptPubKey`, který příjemce detekuje a později z něj utratí." + a1link="https://bitcoincore.reviews/28122#l-153" + + q2="[BIP352][] odkazuje na verzování a dopřednou kompatibilitu. Co je + dopředná kompatibilita a proč je důležitá?" + a2="Umožňuje (například) peněžence verze 0 dekódovat a poslat prostředky + na adresu tiché platby peněženky verze 1 (a verze 2 atd.), i když + není peněženka schopna vygenerovat adresu verze 1. Je to důležité, + protože peněženky nemusí upgradovat hned, jakmile se objeví nová + verze." + a2link="https://bitcoincore.reviews/28122#l-170" + + q3="A co kdyby nová verze chtěla záměrně porušit kompatibilitu?" + a3="Verze 31 je vyhraněna pro upgrade, který by kompatibilitu narušil." + a3link="https://bitcoincore.reviews/28122#l-186" + + q4="Proč stačí vyhradit pouze jednu verzi (31) pro narušení kompatibility?" + a4="Můžeme odložit na později definici nových pravidel, jak by se mělo nakládat + s verzemi _po_ této narušující změně." + a4link="https://bitcoincore.reviews/28122#l-188" + + q5="`DecodeSilentAddress` obsahuje kontrolu verze a velikosti dat. Co tato + kontrola dělá a proč je důležitá?" + a5="Přinese-li nová verze do adresy větší množství dat, musíme mít způsob, + jak obdržet pouze dopředně kompatibilní části. Jinými slovy musíme + se omezit na parsování první 66 bytů (formát verze 0). Je to důležité + pro dopřednou kompatibilitu." + a5link="https://bitcoincore.reviews/28122#l-194" + + q6="Nový kód tichých plateb je umístěn v adresáři peněženky v + `src/wallet/silentpayments.cpp`. Je to dobré místo? Dokážete + vymyslet situaci, kdy bychom chtěli použít kód tichých plateb + mimo kontext peněženky?" + a6="Není to nejlepší, pokud by někdo chtěl naimplementovat server + bez peněženek, který by detekoval tiché platby (či prováděl + relevantní výpočty) pro lehčí peněženky. Lze si představit + situaci, kdy plný uzel indexuje tweaky transakcí a umožňuje + lehkým klientům mezi nimi vyhledávat nebo poskytovat tato data + pomocí filtru podobného [BIP158][]. Avšak dokud tato situace + nenastane, kód v `src/wallet` je lépe organizován." + a6link="https://bitcoincore.reviews/28122#l-205" + + q7="Třída `Recipient` je v PR inicializována se dvěma soukromými klíči: + klíčem pro utracení a klíčem pro prohledávání. Jsou oba tyto klíče + pro prohledávání potřebné?" + a7="Ne, pouze klíč pro prohledávání je potřebný. Schopnost prohledávat + tiché platby bez klíče pro utracení může být implementována v budoucnosti." + a7link="https://bitcoincore.reviews/28122#l-217" +%} + +## 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.* + +- [BDK 0.28.1][] je vydáním této oblíbené knihovny pro budování peněženek. + Obsahuje opravy chyb a přidává šablonu pro odvozování cest dle [BIP86][] + pro [P2TR][topic taproot] v [deskriptorech][topic descriptors] . + +## Významné změny v kódu a dokumentaci + +*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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Bitcoin Core #27746][] zjednodušuje vztah mezi úložištěm bloků a + chainstate objekty tím, že přemisťuje rozhodování, zda uložit blok + na disk, do validační logiky, která je na aktuálním chainstate + nezávislá. Rozhodnutí, zda uložit blok na disk, souvisí s validačními + pravidly, která nevyžadují přístup ke stavu UTXO. V předchozích verzích + používal Bitcoin Core z anti-DoS důvodů heuristiku pro konkrétní + chainstate, ale s [assumeUTXO][topic assumeutxo] a možností existence + dvou chainstate najednou byl tento mechanismus přepracován, aby mohl + být rozdělen. + +- [Core Lightning #6376][] a [#6475][core lightning #6475] implementují + plugin nazývaný `renepay`, který používá Pickhardtovy platby pro + vytváření optimálních [plateb s více cestami][topic multipath payments] + (viz [zpravodaj č. 192][news192 pp], *angl.*). Pickhardtovy platby + předpokládají, že likvidita v každém kanálu je ve směru toku náhodně + rozdělena mezi 0 a plnou kapacitou. Platby vysokých částek mohou + selhat, protože cesta nemusí poskytovat dostatečnou likviditu nebo protože + rozdělení platby do mnoha částí násobí pravděpodobnost selhání. Platba + je poté namodelována jako tok v lightningové síti mající za cíl nalézt + střední cestu mezi počtem částí platby a částkami jednotlivých částí. + Díky tomuto přístupu nacházejí Pickhardtovy platby optimální tok, který + splňuje omezení daná kapacitami a zůstatky a zároveň maximalizuje + pravděpodobnost úspěchu. Odpovědi nedokončených plateb jsou použity + pro aktualizaci předpokládané distribuce likvidity všech zúčastněných + kanálů. Jelikož by použití základních poplatků dle [BOLT7][] bylo + výpočetně náročné (viz [zpravodaj č. 163][news163 base], *angl.*), + budou uzly používající `renepay` nadhodnocovat relativní poplatek + u kanálů s nenulovým základním poplatkem. Onion balíčky zkonstruované + pro doručení platby používají skutečné poplatky. + +- [Core Lightning #6466][] a [#6473][core lightning #6473] přidávají + podporu pro zálohu a obnovu [hlavního tajného kódu][topic BIP32] + peněženky ve formátu [codex32][topic codex32] dle [BIP93][]. + +- [Core Lightning #6253][] a [#5675][core lightning #5675] přidávají + experimentální implementaci [splicingu][topic splicing] dle návrhu + specifikace z [BOLTs #863][]. Pokud obě strany kanálu podporují + splicing, mohou přidat prostředky do kanálu pomocí onchain transakce + (splice-in) nebo odebrat prostředky z kanálu platbou onchain + (splice-out). Ani jedna z těchto operací nevyžaduje uzavření kanálu + a během čekání na potvrzení onchain splicingové transakce může + kanál pokračovat ve své obvyklé činnosti. Klíčovou výhodou splicingu + je možnost LN peněženek držet většinu prostředků offchain a utrácet + tyto prostředky onchain podle potřeby. Díky tomu mohou peněženky + ukazovat uživateli jediný zůstatek (a ne offchain a onchain zůstatky + zvlášť). + +- [Rust Bitcoin #1945][] upravuje pravidla projektu stanovující + minimální počet schválení PR v případě pouhého refaktorování. + Jiné projekty potýkající se s problémem schvalování malých změn + dle stejných standardů jako ostatní PR mohou prozkoumat nová + pravidla Rust Bitcoin. + +- [BOLTs #759][] přidává do specifikace LN podporu [onion zpráv][topic + onion messages]. Onion zprávy umožňují jednosměrné poslání zprávy + napříč celou sítí. Podobně jako platby (HTLC) používají i tyto + zprávy onion šifrování, takže každý přeposílající uzel ví pouze, + odkud zprávu obdržel a kam má zprávu poslat dále. Obsah zprávy + je také šifrován, pouze konečný příjemce ji může přečíst. Na rozdíl + od přeposílaných HTLC, které jsou obousměrné (commitment proudí + směrem k příjemci a předobraz potřebný k nárokování platby teče + opačným směrem k odesílateli), nemusí být onion zprávy díky své + jednosměrné povaze ukládány, ač některá navrhovaná opatření proti + DoS závisí na držení malého množství agregovaných informací + (viz [zpravodaj č. 207][news207 onion], *angl.*). Obousměrného + posílání lze dosáhnout přilepením zpáteční cesty ke zprávě. Onion + zprávy používají [zaslepené cesty][topic rv routing], které byly + přidány do specifikace před několika měsíci (viz [zpravodaj č. + 245][news245 blinded]), a jsou také využívány vyvíjeným protokolem + [nabídek][topic offers]. + +{% 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://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://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://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 +[CVE-2023-39910]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-39910 +[milksad]: https://milksad.info/ +[mb milksad]: https://github.com/bitcoinbook/bitcoinbook/commit/76c5ba8000d6de20b4adaf802329b501a5d5d1db#diff-7a291d80bf434822f6a737f3e564be6a67432e2f3f12669cf0469aedf56849bbR126-R134 +[bx home]: https://web.archive.org/web/20230319035342/https://github.com/libbitcoin/libbitcoin-explorer/wiki +[bx1]: https://web.archive.org/web/20210122102649/https://github.com/libbitcoin/libbitcoin-explorer/wiki/How-to-Receive-Bitcoin +[bx2]: https://web.archive.org/web/20210122102714/https://github.com/libbitcoin/libbitcoin-explorer/wiki/bx-mnemonic-new +[bx3]: https://web.archive.org/web/20210506162634/https://github.com/libbitcoin/libbitcoin-explorer/wiki/bx-hd-new +[seed doc]: https://web.archive.org/web/20210122102710/https://github.com/libbitcoin/libbitcoin-explorer/wiki/bx-seed +[news208 rbf]: /en/newsletters/2022/07/13/#bitcoin-core-25353 +[bdk 0.28.1]: https://github.com/bitcoindevkit/bdk/releases/tag/v0.28.1 +[news192 pp]: /en/newsletters/2022/03/23/#payment-delivery-algorithm-update +[news163 base]: /en/newsletters/2021/08/25/#zero-base-fee-ln-discussion diff --git a/_posts/cs/newsletters/2023-08-16-newsletter.md b/_posts/cs/newsletters/2023-08-16-newsletter.md new file mode 100644 index 0000000000..5553cc4df1 --- /dev/null +++ b/_posts/cs/newsletters/2023-08-16-newsletter.md @@ -0,0 +1,128 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 264' +permalink: /cs/newsletters/2023/08/16/ +name: 2023-08-16-newsletter-cs +slug: 2023-08-16-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme souhrn diskuze o přidání data expirace do adres tichých +plateb a poskytujeme přehled návrhu BIP pro bezserverový payjoin. Příspěvek v +podobě terénní zprávy popisuje implementaci a nasazení peněženky založené na +MuSig2 pro scriptless vícenásobné elektronické podpisy. Též nechybí naše +pravidelné rubriky s oznámeními o nových vydáních a popisem významných změn +v populárních bitcoinových páteřních projektech. + +## Novinky + +- **Přidání expirace do adres tichých plateb:** Peter Todd + zaslal do emailové skupiny Bitcoin-Dev [příspěvek][todd expire] s + doporučením přidat do adres [tichých plateb][topic silent payments] + uživatelem zvolené datum expirace. Na rozdíl od běžných bitcoinových + adres, které v případě použití k obdržení více plateb odhalují [vazby mezi + výstupy][topic output linking], vedou adresy tichých plateb při každém + správném použití k jedinečnému výstupnímu skriptu. To může výrazně zvýšit + soukromí v případech, kdy je nemožné či nepraktické poskytnout plátci pro + každou platbu novou běžnou adresu. + + Peter Todd poznamenává, že by bylo žádoucí, aby měly všechny adresy datum + expirace, neboť dříve nebo později většina uživatelů přestane peněženku + používat. Expirace není u předpokládaného jediného použití běžné adresy natolik + důležitá, avšak pro tiché platby, u kterých se očekává opakované použití, + je začlenění doby expirace mnohem důležitější. Navrhuje v adresách zahrnout + buď dvoubytový čas, který by mohl zaujmout dobu expirace až 180 let, + nebo tříbytový čas, který by obsáhl zhruba 45 000 let. + + Doporučení obdrželo v emailové skupině průměrné množství reakcí, avšak + v době psaní zpravodaje žádné jasné rozuzlení. + +- **Bezserverový payjoin:** Dan Gould zaslal do emailové skupiny Bitcoin-Dev + [příspěvek][gould spj] s [návrhem BIPu][spj bip] pro _bezserverový payjoin_ + (viz [zpravodaj č. 236][news236 spj]). Podle [BIP78][] specifikace [payjoinu][topic + payjoin] se očekává, že příjemce bude provozovat server pro bezpečné přijetí + [PSBT][topic psbt] od odesílatele platby. Gould navrhuje asynchronní model s + prostředníky, na jehož počátku by příjemce použil [BIP21][] URI k oznámení + prostředníka a klíče symetrického šifrování, které by byly použity pro + příjem payjoinové platby. Odesílatel by zašifroval PSBT a předal + jej prostředníkovi zvolenému příjemcem. Příjemce by toto PSBT stáhl, + rozšifroval, přidal do něj podepsaný vstup, zašifroval a odeslal zpět + prostředníkovi. Odesílatel upravené PSBT stáhne, rozšifruje, ujistí se o jeho + správnosti, podepíše a zveřejní v síti. + + V [odpovědi][gibson spj] Adam Gibson varoval před nebezpečím začlenění šifrovacího + klíče v BIP21 adrese a před rizikem ohrožení soukromí prostředníkem, který + by byl schopný vytvořit spojení mezi IP adresami příjemce a odesílatele a + množinou transakcí zveřejněných v rámci časového okna kolem dokončení jejich + sezení. Gould nato návrh [revidoval][gould spj2] ve snaze adresovat Gibsonovy + obavy o šifrovacím klíči. + + Očekáváme, že diskuze o tomto protokolu bude pokračovat. + +## Terénní zpráva o implementaci MuSig2 + +{% include articles/cs/bitgo-musig2.md extrah="#" %} + +## 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.* + +- [Core Lightning 23.08rc2][] je kandidátem na vydání příští hlavní verze této + oblíbené implementace LN uzlu. + +## Významné změny v kódu a dokumentaci + +*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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Bitcoin Core #27213][] pomáhá Bitcoin Core otevírat a udržovat spojení + v různorodější množině sítí, což v některých situacích sníží hrozbu + [útoku zastíněním][topic eclipse attacks]. Tento druh útoku se objevuje, + když se uzel nemůže připojit ani k jednomu čestnému uzlu. Je tak připojen + pouze k nepoctivým uzlům, které mu mohou podsunout jiné bloky než zbytku + sítě. To může být zneužito k přesvědčení uzlu, že některé transakce byly + potvrzeny, i když s tím zbytek sítě nesouhlasí. Potenciálně by tím mohl + provozovatel uzlu přijmout bitcoiny, které nebude moci utratit. Navýšení + rozmanitosti spojení může též napomoci v předcházení náhodného štěpení sítě, + kdy jsou spojení v rámci malé sítě izolována od hlavní sítě a nejsou schopna + obdržet čerstvé bloky. + + Přijaté PR se snaží otevřít alespoň jedno spojení v každé dosažitelné síti + a zabrání automatickému vyloučení, pokud se jedná o jediné spojení v síti. + +- [Bitcoin Core #28008][] přidává šifrovací a dešifrovací funkce připravené k + použití v implementaci [transportního protokolu verze 2][topic v2 P2P transport] + 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” + + - „Proudová šifra FSChaCha20 (forward secrecy) podle specifikace v + BIP324 (rekeying wrapper okolo ChaCha20)” + + - „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” + +- [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í + implementace z platby extrahovat. Díky tomu bude snadnější v rámci platby + poslat vlastní data a metadata. + +{% include references.md %} +{% include linkers/issues.md v=2 issues="27213,28008,2308" %} +[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://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 new file mode 100644 index 0000000000..ef57c4dc44 --- /dev/null +++ b/_posts/cs/newsletters/2023-08-23-newsletter.md @@ -0,0 +1,234 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 265' +permalink: /cs/newsletters/2023/08/23/ +name: 2023-08-23-newsletter-cs +slug: 2023-08-23-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme popis dokladů o podvodu za poskytnutí staré zálohy +stavu kanálu. Nechybí též naše pravidelné rubriky s popisem nedávných +změn ve službách a klientech, oznámeními o nových vydáních a popisem +významných změn v populárním bitcoinovém páteřním software. + +## Novinky + +- **Doklad o podvodu za poskytnutí staré zálohy:** Thomas Voegtlin zaslal + do emailové skupiny Lightning-Dev [příspěvek][voegtlin backups] s myšlenkou + 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. + + - 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í. + + - 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ď. + + 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 + [OP_CHECKSIGFROMSTACK (CSFS) a OP_CAT][topic op_checksigfromstack] byly + soft forkem přidány do bitcoinu, bylo by možné používat doklady o podvodu + onchain. + + Příklad: Alice a Bob sdílejí LN kanál s dodatečnou [taprootovou][topic taproot] + podmínkou, která Alici umožňuje utratit všechny prostředky kanálu, pokud + by poskytla doklad o podvodu. Běžný provoz kanálu by obsahoval jen + jeden další krok: po každé aktualizaci kanálu by Alice poskytla Bobovi + podpis současného stavu (včetně čísla verze). Nato by při každém novém + připojení k Bobovi Alice vyžádala poslední zálohu a ověřila její integritu. + Pokud by Bob poskytl starou zálohu, Alice by si mohla díky dokladu o + podvodu a platební podmínce CSFS nárokovat celý zůstatek kanálu. + + Pro Alici by díky tomuto mechanismu bylo bezpečnější použít stav poskytnutý + Bobem jako poslední stav kanálu v případě, kdy by Alice opravdu svá + data ztratila. Podle současného designu LN kanálů (LN-Penalty) by mohl Bob + ukrást celý Alicin zůstatek, kdyby se mu podařilo podstrčit jí starý stav. + I v navrhovaných aktualizacích jako [LN-Symmetry][topic eltoo] by Alicino + použití starého stavu umožnilo Bobovi ji okrást. Bobova ochota nabídnout + starý stav by v případě hrozby penalizace byla nižší. + + Návrh obdržel významné množství reakcí: + + - Peter Todd [poznamenal][todd backups1], že mechanismus je v základu + obecně použitelný. Není vázaný na LN a mohl by být užitečný v řadě + protokolů. [Též poznamenal][todd backups2], že jednodušším způsobem by + bylo, kdyby Alice od Boba jednoduše stahovala poslední stav při každém + novém připojení bez použití jakýchkoliv dokladů o podvodu. Kdyby jí + poskytl starý stav, mohla by kanál zavřít a tím mu odepřít možné budoucí + poplatky za přeposílání plateb. Podobá se to verzi [peer storage][topic + peer storage] popsané v [BOLT 881][BOLTs #881], jehož experimentální + implementace se dříve letos objevila v Core Lightning (viz [zpravodaj č. + 238][news238 peer storage]) a (jak ve svém [příspěvku][teinturier + backups] naznačuje Bastien Teinturier) i ve verzi schématu implementovaného + v LN peněžence Phoenix. + + - Ghost43 ve své [reakci][ghost43 backups] vysvětlil, že doklady o podvodu + vedoucí k finanční penalizaci poskytují mocný nástroj klientům + ukládajícím data u anonymních uzlů. Velké populární služby mohou dbát o + svou reputaci natolik, aby se lhaní svým klientům vyvarovaly, ale + anonymní uzly nemají žádnou reputaci, o kterou by mohly přijít. Ghost43 + dále navrhl úpravu protokolu, která by jej učinila symetrickým, tedy aby + vedle Alice ukládající stav u Boba (s potrestáním Boba v případě lhaní) + ukládal i Bob svůj stav u Alice, která by mohla být za lhaní potrestána. + + Voegtlin tuto myšlenku rozšířil o [varování][voegtlin backups2], že + poskytovatelé softwarových peněženek mají potřebu zachovat si dobrou + reputaci, kterou by ztráceli, kdyby jejich uživatelé ztráceli peníze, + i kdyby software fungoval, jak nejlépe mohl. Pro něj jako vývojáře softwarové + peněženky je tak velmi důležité minimalizovat hrozbu, že by anonymní + uzel mohl okrást uživatele peněženky Electrum, který používá podobný + mechanismus zálohování. + + Diskuze nepřinesla jasné rozuzlení. + +## 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.* + +- **Scaling Lightning žádá o zpětnou vazbu:** + [Scaling Lightning][] je testovacím souborem nástrojů pro Lightning Network + na regtestu a signetu. Projekt si klade za cíl poskytnout nástroje pro + testování různých implementací LN v rozličných konfiguracích a scénářích. + Projekt nedávno komunitě nabídl [video update][sl twitter update]. Vývojáři + LN, badatelé a provozovatelé infrastruktury jsou vyzýváni k [poskytnutí + zpětné vazby][sl tg]. + +- **Vydán Torq v1.0:** + Software pro pokročilou správu LN uzlu [Torq][torq github] [oznámil][torq blog] + vydání verze 1.0 včetně funkcí Lightning Service Provider (LSP), automatizačních + postupů a pokročilých funkcí pro provozovatele velkých uzlů. + +- **Vydána Blixt Wallet v0.6.8:** + [Vydání v0.6.8][blixt v0.6.8] obsahuje mimo jiné podporu pro [pozdržené + faktury][topic hold invoices] („hold invoices”) a [zero-conf kanály][topic + zero-conf channels]. + +- **Vydán Sparrow 1.7.8:** + Sparrow [1.7.8][sparrow 1.7.8] přidává podporu pro [podepisování zpráv][topic + generic signmessage] dle [BIP322][] včetně P2TR adres a přidává několik + vylepšení do navyšování poplatků pomocí [RBF][topic rbf] a [CPFP][topic cpfp]. + +- **Prototyp bitaxeUltra, open source ASIC zařízení pro těžbu:** + [BitaxeUltra][github bitaxeUltra] je open source zařízením pro těžbu používající + zákaznického integrovaného obvodu (ASIC) a založený na existujícím komerčním + těžícím hardware. + +- **Oznámen FROST software Frostsnap:** + Tým [oznámil][frostsnap blog] svou představu [budování][frostsnap github] + nad schématem [prahového elektronického podpisu][topic threshold signature] + FROST a za použití experimentální implementace FROST [secp256kfun][secp256kfun + github]. + +- **Oznámena knihovna Libfloresta:** + [Libfloresta][libfloresta blog] je rustová knihovna pro přidání podpory funkcí + bitcoinového uzlu založeného na [utreexo][topic utreexo] do aplikací. Staví na + výsledcích práce na utreexo uzlu [Floresta][news247 floresta]. + +- **Vydána Wasabi Wallet 2.0.4:** + Wasabi [2.0.4][wasabi 2.0.4] přidává nové funkce pro navyšování poplatků pomocí + [RBF][topic rbf] i [CPFP][topic cpfp], vylepšení [coinjoinu][topic coinjoin], + rychlejší načítání peněženky, vylepšení RPC a další novinky a opravy chyb. + +## 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.* + +- [Core Lightning 23.08rc3][] je kandidátem na vydání příští hlavní verze této + populární implementace LN uzlu. + +- [HWI 2.3.1][] je nové vydání tohoto nástroje pro práci s hardwarovými podpisovými + zařízeními. + +## Významné změny v kódu a dokumentaci + +*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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Bitcoin Core #27981][] opravuje chybu, které mohla potenciálně způsobit, + že by dva uzly nebyly schopny od sebe navzájem přijímat data. Pokud by + Alicin uzel měl hodně dat čekajících ve frontě na odeslání Bobovu uzlu, + pokusil by se tato data odeslat před přijetím jakýchkoliv dat od Boba. Pokud by Bob + též měl hodně dat ve frontě na odeslání Alici, také by nepřijal od Alice + žádná nová data. To by mohlo vést k situaci, kdy by se žádný z těchto + uzlů nikdy nepokusil o přijetí dat od druhého. Problém byl původně + objeven v [projektu Elements][Elements Project]. + +- [BOLTs #919][] přidává do specifikace LN doporučení, aby po dosažení určité + částky přestaly uzly akceptovat další ořezaná HTLC. Ořezané HLTC je + přeposílatelná platba, která však není přidána na výstup commitment + transakce kanálu. Namísto toho je částka rovnající se hodnotě ořezaného + HTLC vyhrazena na transakční poplatky. Díky tomu je možná v rámci LN + přeposílat platby, které by onchain byly [neekonomické][topic uneconomical + outputs]. Avšak pokud by se kanál měl zavřít v době, kdy jsou zpracovávány + ořezaná HTLC, nemá uzel žádnou možnost, jak tyto prostředky nárokovat. + Stanovení horní meze tohoto druhu ztráty je tedy rozumné. Viz též naše + popisy rozličných implementací přidávající tento limit: LDK ve [zpravodaji + č. 162][news162 trim], Eclair ve [zpravodaji č. 171][news171 trim] a + Core Lightning ve [zpravodaji č. 173][news173 trim] a také + [zpravodaj č. 170][news170 trim] (vše *angl.*) popisující relevantní + bezpečností problémy. + +- [Rust Bitcoin #1990][] volitelně umožňuje, aby byl `bitcoin_hashes` zkompilován + s pomalejšími implementacemi SHA256, SHA512 a RIPEMD160, která mají však + poloviční velikost. Užitečné mohou být ve vestavěných zařízeních, které + nevykonávají časté hashování. + +- [Rust Bitcoin #1962][] přidává možnost používat hardwarově optimalizované + SHA256 operace na x86 kompatibilních architekturách. + +- [BIPs #1485][] přidává několik aktualizací do [BIP300][] specifikace + [drivechainů][topic sidechains]. Hlavní změnou se jeví být nová definice + `OP_NOP5` v některých kontextech `OP_DRIVECHAIN`. + +{% include references.md %} +{% include linkers/issues.md v=2 issues="27460,27981,919,1990,1962,1485,881" %} +[core lightning 23.08rc3]: https://github.com/ElementsProject/lightning/releases/tag/v23.08rc3 +[news238 peer storage]: /cs/newsletters/2023/02/15/#core-lightning-5361 +[news162 trim]: /en/newsletters/2021/08/18/#rust-lightning-1009 +[news171 trim]: /en/newsletters/2021/10/20/#eclair-1985 +[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://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 +[torq github]: https://github.com/lncapital/torq +[torq blog]: https://ln.capital/articles/announcing-torq-V1.0 +[blixt v0.6.8]: https://github.com/hsjoberg/blixt-wallet/releases +[sparrow 1.7.8]: https://github.com/sparrowwallet/sparrow/releases/tag/1.7.8 +[github bitaxeUltra]: https://github.com/skot/bitaxe/tree/ultra +[frostsnap blog]: https://frostsnap.com/introducing-frostsnap.html +[frostsnap github]: https://github.com/frostsnap/frostsnap +[secp256kfun github]: https://github.com/LLFourn/secp256kfun +[news247 floresta]: /cs/newsletters/2023/04/19/#oznamen-electrum-server-zalozeny-na-utreexo +[libfloresta blog]: https://blog.dlsouza.lol/2023/07/07/libfloresta.html +[wasabi 2.0.4]: https://github.com/zkSNACKs/WalletWasabi/releases/tag/v2.0.4 +[hwi 2.3.1]: https://github.com/bitcoin-core/HWI/releases/tag/2.3.1 diff --git a/_posts/cs/newsletters/2023-08-30-newsletter.md b/_posts/cs/newsletters/2023-08-30-newsletter.md new file mode 100644 index 0000000000..022424998e --- /dev/null +++ b/_posts/cs/newsletters/2023-08-30-newsletter.md @@ -0,0 +1,214 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 266' +permalink: /cs/newsletters/2023/08/30/ +name: 2023-08-30-newsletter-cs +slug: 2023-08-30-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme oznámení o zodpovědném zveřejnění zranitelnosti +postihující staré LN implementace a souhrn návrhu na mix opkódů +pro kovenanty. 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ích bitcoinových páteřních projektech. + +## Novinky + +- **Zveřejnění proběhlé zranitelnosti LN spojené s falešným financováním:** Matt + Morehouse zaslal do emailové skupiny Lightning-Dev [příspěvek][morehouse dos] + s popisem zranitelnosti, kterou předtím [zodpovědně zveřejnil][topic + responsible disclosures] a kterou ve svých posledních vydáních adresují + všechny populární implementace LN. Abychom zranitelnosti porozuměli, + představme si, že Bob provozující LN uzel obdrží od Malloryho žádost o + otevření nového kanálu. Absolvují proces otevření kanálu až do bodu, ve + kterém se od Malloryho očekává zveřejnění transakce financující kanál. + Aby bylo možné kanál později používat, musí Bob uložit relevantní data + a sledovat nové bloky pro dostatečné potvrzení této transakce. Pokud však + Mallory transakci nikdy nezveřejní, plýtvá Bob úložištěm a zdroji vynaloženými + na sledování bloků. Opakuje-li Mallory tento process tisíckrát nebo + milionkrát, může přivést Bobův uzel až do bodu, kdy jej není možné vůbec + používat a to včetně provádění citlivých operací nutných pro zabránění ztráty + peněz. + + Během testování svého vlastního uzlu byl Morehouse schopen způsobit výrazné + problémy Core Lightningu, Eclairu, LDK i LND, a to včetně dvou případů, které + mohly podle našeho názoru vést ke ztrátě peněz mnoha uzlů. Morehousův + [popis][morehouse post] odkazuje na PR, která tento problém adresují (včetně + PR zmíněných ve zpravodajích [č. 237][news237 dos] a [č. 240][news240 dos]) + a vyjmenovává vydání, která tuto zranitelnost opravují: + + - Core Lightning 23.02 + - Eclair 0.9.0 + - LDK 0.0.114 + - LND 0.16.0 + + V emailové skupině i na [IRC][stateless funding] se objevilo množství + reakcí. + +- **Kovenanty namíchané z `TXHASH` a `CSFS`:** Brandon Black + zaslal do emailové skupiny Bitcoin-Dev [příspěvek][black mashup] s návrhem + na variantu `OP_TXHASH` (viz [zpravodaj č. 185][news185 txhash], *angl.*) + zkombinovanou s [OP_CHECKSIGFROMSTACK][topic op_checksigfromstack], která + by mohla poskytnout většinu funkcí [OP_CHECKTEMPLATEVERIFY][topic + op_checktemplateverify] (CTV) a [SIGHASH_ANYPREVOUT][topic + sighash_anyprevout] (APO) bez velkých nadbytečných onchain nákladů oproti + původním jednotlivým návrhům. I když je návrh zajímavý sám o sobě, jeho + vznik byl částečně motivován snahou „objasnit naše uvažování o [CTV a APO] + jednotlivě i dohromady a potenciálně nás posunout směrem ke konsenzu na + cestě […] k úžasným budoucím možnostem používání bitcoinu.” + Návrh obdržel v emailové skupině několik reakcí, [další příspěvky][delv mashup] + a diskuze se objevily ve fóru Delving Bitcoin. + +## 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/" %} + +- [Existují ekonomické podněty k přechodu z P2WPKH na P2TR?]({{bse}}119301) + Murch prochází běžné vzory používání peněženek a porovnává váhy transakčních + vstupů a výstupů pro P2WPKH a [P2TR][topic taproot]. Jeho závěr: + „Celkově bys mohl používáním P2TR místo P2WPKH ušetřit na poplatcích až 15,4 %. + Pokud odesíláš mnohem více drobných plateb, než přijímáš, setrváním u P2WPKH + bys mohl ušetřit až 1,5 %.” + +- [Jaká je struktura BIP324 zašifrovaných paketů?]({{bse}}119369) + Pieter Wuille ukazuje strukturu síťových paketů u [P2P přenosu verze 2][topic + v2 p2p transport] dle návrhu v [BIP324][], jehož implementaci lze sledovat + v [Bitcoin Core #27634][]. + +- [Kolik falešně pozitivních výsledků vrací kompaktní filtry bloků?]({{bse}}119142) + Murch poukazuje na [BIP158][] a jeho část o výběru parametrů [filtru bloků][bip158 + filters], která poznamenává, že míra falešně pozitivních výsledků [kompaktních + filtrů bloků][topic compact block filters] je 1:784 931, tedy zhruba + jeden blok každých osm týdnů v případě peněženky monitorující kolem tisíce + výstupních skriptů. + +- [Které opkódy jsou součástí navrhovaného MATT?]({{bse}}119239) + Salvatoshi objasňuje koncept Merkleize All The Things ([MATT][merkle.fun], + „všechno to zmerklujte”), jehož je sám autorem, včetně současně navrhovaných + opkódů: [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify], + OP_CHECKCONTRACTVERIFY a [OP_CAT][]. Viz též zpravodaje [č. 226][news226 + matt] (*angl.*), [č. 249][news249 matt] a [č. 254][news254 matt]. + +- [Je poslední bitcoinový blok nějak definovaný?]({{bse}}119223) + RedGrittyBrick a Pieter Wuille vysvětlují, že i když výška bloku nemá žádné + omezení, současná pravidla konsenzu nepřijmou žádný nový blok obsahující + časové razítko nad limit daný bezznaménkovým 32bitovým datovým typem, tedy + rok 2106. Transakce a jejich [nLockTime][topic timelocks] hodnoty mají stejné + [omezení]({{bse}}110666). + +- [Proč těžaři nastavují locktime v coinbasových transakcích?]({{bse}}110474) + Bordalix odpovídá na dlouho otevřenou otázku, proč těžaři zjevně používají + locktime v coinbasových transakcích. Provozovatel těžebního poolu vysvětlil, + že „přepoužili tyto čtyři byty pro držení dat stratum session, což jim + umožňuje rychlejší připojení” a dále celé schéma [objasnil][twitter satofishi]. + +- [Proč během Schnorrova podepisování nepoužívá Bitcoin Core doplňkovou náhodnost?]({{bse}}119042) + Matthew Leon se táže, proč [BIP340][] doporučuje během generování nonce [Schnorrových + podpisů][topic schnorr signatures] používat doplňkovou náhodnost jako ochranu + před [útoky postranními kanály][topic side channels], a přesto Bitcoin Core + tuto doplňkovou náhodnost ve své implementaci nepoužívá. Andrew Chow odpovídá, + že současná implementace je i takto bezpečná a že žádné PR ještě nebylo otevřeno, + aby toto doporučení adresovalo. + +## 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.* + +- [Core Lightning 23.08][] je nejnovějším hlavním vydáním této oblíbené + implementace LN uzlu. Mezi novými funkcemi a opravami chyb je možnost + změnit několik položek konfigurace uzlu bez nutnosti jej restartovat, + podpora pro zálohu a obnovu [seedu][topic bip32] pomocí [Codex32][topic + codex32], nový experimentální plugin pro vylepšené hledání cest, + experimentální podpora pro [splicing][topic splicing] a možnost platit + lokálně generované smlouvy. + +- [LND v0.17.0-beta.rc1][] je kandidátem na vydání příští hlavní verze + této populární implementace LN uzlu. Významnou novou experimentální + funkcí plánovanou pro toto vydání, které by testování prospělo, + je podpora „jednoduchých taprootových kanálů” popsaných v LND PR #7904 + v rubrice s významnými změnami. + +## Významné změny v kódu a dokumentaci + +*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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Bitcoin Core #27460][] přidává nové RPC volání `importmempool`. + Volání načte soubor `mempool.dat` a pokusí se do mempoolu přidat načtené + transakce. + +- [LDK #2248][] přináší vestavěný systém, který může projektům používajícím + LDK poskytnout sledování UTXO odkazovaných v gossip zprávách. LN uzly, které + gossip zpracovávají, musí akceptovat pouze zprávy podepsané klíčem přidruženým + k nějakému UTXO, jinak by mohly být donuceny zpracovávat a přeposílat + spam nebo přeposílat platby přes neexistující kanály (což by vždy selhalo). + Nový vestavěný `UtxoSource` funguje s LN uzly připojenými k lokální instanci + Bitcoin Core. + +- [LDK #2337][] usnadňuje používání LDK pro budování [strážních věží][topic + watchtowers], které běží nezávisle na uživatelově peněžence, ale které + mohou od uživatelova uzlu přijímat zašifrované transakce s LN pokutami. + Strážní věž může z každé transakce v novém bloku extrahovat informace a + pokusit se díky nim dešifrovat data přijatá dříve. Pokud rozšifrování + uspěje, může strážní věž trestnou transakci zveřejnit. To chrání uživatele + před protistranami publikujícími starý, neplatný stav kanálu v době uživatelovy + nedostupnosti. + +- [LDK #2411][] a [#2412][ldk #2412] přidávají API pro konstrukci platebních + cest pro [zaslepené platby][topic rv routing]. PR odděluje kód pro [onion + zprávy][topic onion messages] (které zaslepené cesty používají) od samotných + zaslepených cest. Následující PR [#2413][ldk #2413] vlastní podporu pro zaslepené + cesty přidává. + +- [LDK #2507][] obchází dlouhotrvající problémy jiné implementace, které vedou + ke zbytečnému nucenému zavření kanálu. + +- [LDK #2478][] přidává událost, která poskytuje informace o přeposílaném + [HTLC][topic htlc], které již bylo vyrovnáno, včetně kanálu, ze kterého + přišlo, částky a velikosti poplatku. + +- [LND #7904][] přidává experimentální podporu „jednoduchých taprootových kanálů,” + která umožní používat [P2TR][topic taproot] pro otevírací a commitment + transakce. To s sebou také přináší podporu bezskriptového podepisování + [vícenásobnými elektronickými podpisy][topic multisignature] dle [MuSig2][topic + musig]. Sníží to váhu transakce a vylepší soukromí v případě kooperativního + zavření. LND nadále používá výhradně [HTLC][topic htlc], díky čemuž mohou + být platby začínající v taprootovém kanálu i nadále přeposílány i uzly, + které taproot kanály nepodporují. + + Toto PR sestává z 134 commitů, které byly předtím začleněny do pracovní + větve z následujících PR: [#7332][lnd #7332], [#7333][lnd #7333], + [#7331][lnd #7331], [#7340][lnd #7340], [#7344][lnd #7344], [#7345][lnd #7345], + [#7346][lnd #7346], [#7347][lnd #7347] a [#7472][lnd #7472]. + +{% include references.md %} +{% include linkers/issues.md v=2 issues="27460,2466,2248,2337,2411,2412,2413,2507,2478,7904,7332,7333,7331,7340,7344,7345,7346,7347,7472,27634" %} +[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://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://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 +[merkle.fun]: https://merkle.fun/ +[news254 matt]: /cs/newsletters/2023/06/07/#vyuziti-matt-k-napodobeni-ctv-a-sprave-joinpoolu +[news249 matt]: /cs/newsletters/2023/05/03/#uschovny-zalozene-na-matt +[news226 matt]: /en/newsletters/2022/11/16/#general-smart-contracts-in-bitcoin-via-covenants +[twitter satofishi]: https://twitter.com/satofishi/status/1693537663985361038 diff --git a/_posts/cs/newsletters/2023-09-06-newsletter.md b/_posts/cs/newsletters/2023-09-06-newsletter.md new file mode 100644 index 0000000000..4364ac0c7e --- /dev/null +++ b/_posts/cs/newsletters/2023-09-06-newsletter.md @@ -0,0 +1,132 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 267' +permalink: /cs/newsletters/2023/09/06/ +name: 2023-09-06-newsletter-cs +slug: 2023-09-06-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme popis nové techniky komprese bitcoinových transakcí +a souhrn myšlenky na zvýšení soukromí během kooperativního podepisování +transakcí. Též nechybí naše pravidelné rubriky s oznámeními o nových +vydáních a popisem významných změn v populárním bitcoinovém páteřním +software. + +## Novinky + +- **Komprimované bitcoinové transakce:** Tom Briar zaslal do emailové skupiny + Bitcoin-Dev [příspěvek][briar compress] s návrhy [specifikace][compress + spec] a [implementace][compress impl] komprese bitcoinových transakcí. + Menší transakce by umožnily praktičtější přeposílání médii s omezenou + šířkou pásma, jako je satelit nebo použíti steganografie (např. zakódování + transakce do rastrového obrázku). Tradiční kompresní algoritmy využívají + vlastnosti, že většina strukturovaných dat obsahuje elementy, které se + objevují častěji než jiné. Avšak typická bitcoinová transakce sestává + většinou z rovnoměrně rozložených prvků jako veřejné klíče a hashe, + které vypadají náhodně. + + V Briarově návrhu je tato skutečnost adresována několika způsoby: + + - Části transakce s celými čísly reprezentovanými čtyřmi byty (např. + verze transakce a index výstupu) jsou nahrazeny celým číslem s + proměnlivou délkou, které mohou mít i pouhé dva bity. + + - Rovnoměrné rozložené 32bytové ID výstupní transakce je v každém vstupu + nahrazeno ukazatelem na umístění této transakce v blockchainu za použití + výšky bloku a indexu transakce, např. `123456` a `789` by ukazovaly + na 789. transakci v bloku 123 456. Jelikož se může blok v určité výšce + změnit kvůli reorganizacím (což by v důsledku znemožnilo transakci + dekomprimovat), je tato metoda použita pouze pro odkazované transakce + mající více než 100 konfirmací. + + - U P2WPKH transakcí, ve kterých musí struktura witnessu obsahovat podpis + spolu s 33bytovým veřejným klíčem, je tento veřejný klíč vynechán a + namísto toho je rekonstruován z podpisu. + + Pro ušetření několika dalších bytů jsou u typických transakcí použity + i další techniky. Obecnou nevýhodou návrhu je, že převést komprimované + transakce zpět na data, která plný uzel a další software mohou používat, + vyžaduje více CPU, paměti a I/O než běžná serializovaná transakce. + Proto zřejmě spojení s vysokou šířkou pásma zůstanou u běžného formátu + a komprimované transakce budou používány jen v případech, kdy takové + pásmo není k dispozici. + + Myšlenka obdržela průměrné množství reakci, většinou obsahující nápady na + ušetření dalších bytů. + +- **Kooperativní podepisování se zvýšeným soukromím:** Nick Farrow zaslal + do emailové skupiny Bitcoin-Dev [příspěvek][farrow cosign] ukazující, + jak mohou [bezskriptová schémata prahového elektronického podepisování][topic + threshold signature] jako [FROST][] zvýšit soukromí lidí, kteří používají + služby poskytující kooperativní podepisování. Typický uživatel takové + služby má několik klíčů pro podepisování, které jsou z důvodu bezpečnosti + uloženy odděleně. Aby však bylo běžné placení jednodušší, umožňují též, + aby byly jejich výstupy utraceny kombinací některých svých klíčů spolu + s jedním či více klíči drženými jedním či více poskytovateli služby, + kteří podepíší jen po autentizaci uživatele nějakým způsobem. Uživatel + může poskytovatele v případě potřeby obejít, ale tento poskytovatel + služby ve většinu případů vše usnadňuje. + + Použitím skriptových schémat prahového elektronického podpisu, jako je 2-ze-3 + `OP_CHECKMULTISIG`, musí být veřejný klíč poskytovatele asociován s + utráceným výstupem. Každý poskytovatel služby je tak schopen na blockchainu + vyhledat transakce, které podepsal, a tím shromažďovat data o svých + uživatelích. Co je ještě horší, všechny současně používané protokoly, + kterých jsme si vědomi, přímo vyžadují odhalení uživatelovy transakce + poskytovateli. Ten tak může některé transakce odmítnout podepsat. + + Dle Farrowova popisu umožňuje FROST před poskytovatelem skrýt podepisovanou + transakci v každém kroku procesu, od generování výstupního skriptu přes + podepisování až po publikaci kompletní podepsané transakce. Služba ví jen, + kdy byla transakce podepsána, a zná další data, která uživatel službě + sám poskytl za účelem autentizace. + + Příspěvek obdržel v emailové skupině několik komentářů. + +## 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 0.4.0][] je nejnovějším vydáním knihovny pro bitcoinové + kryptografické operace. Nová verze obsahuje modul s implementací kódování + ElligatorSwift. Více informací lze najít v [changelogu][libsecp cl]. + +- [LND v0.17.0-beta.rc2][] je kandidátem na vydání příští hlavní verze + této oblíbené implementace LN uzlu. Velkou novou experimentální funkcí + plánovanou pro toto vydání, které by prospělo testování, je podpora + „jednoduchých taprootových kanálů.” + +## Významné změny v kódu a dokumentaci + +*Významné změny z tohoto týdne v [Bitcoin Core][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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Bitcoin Core #28354][] mění na testnetu výchozí hodnotu `-acceptnonstdtxn` + na 0, což je výchozí hodnota na všech ostatních sítích. Změna může pomoci + aplikacím vyvarovat se vytváření nestandardních transakcí, které by + mohly být odmítnuty mainnetovými uzly ve výchozím nastavení. + +- [LDK #2468][] umožňuje uživatelům poskytnout `payment_id` zašifrované + v metadatech v žádosti o fakturu. LDK metadata v přijatých fakturách + kontroluje a zaplatí pouze, pokud ID rozpozná a pokud ještě nebylo + použito. Toto PR je součástí [snahy][ldk bolt12] přidat implementaci + [BOLT12][topic offers]. + +{% 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://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://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 +[ldk bolt12]: https://github.com/lightningdevkit/rust-lightning/issues/1970 diff --git a/_posts/cs/newsletters/2023-09-13-newsletter.md b/_posts/cs/newsletters/2023-09-13-newsletter.md new file mode 100644 index 0000000000..e0400b0a28 --- /dev/null +++ b/_posts/cs/newsletters/2023-09-13-newsletter.md @@ -0,0 +1,168 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 268' +permalink: /cs/newsletters/2023/09/13/ +name: 2023-09-13-newsletter-cs +slug: 2023-09-13-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme odkaz na návrh specifikací spojených s taprootovými +aktivy a souhrn několika alternativních protokolů, které umožní LN začít +používat PTLC. Též nechybí naše pravidelné rubriky se souhrnem sezení +Bitcoin Core PR Review Club, oznámeními o nových softwarových vydáních a +popisem významných změn v populárním bitcoinovém páteřním software. + +## Novinky + +- **Specifikace Taproot Assets:** Olaoluwa Osuntokun zaslal do + emailových skupin Bitcoin-Dev a Lightning-Dev dva oddělené + příspěvky o [protokolu validujícím na straně klienta][topic + client-side validation] _Taproot Assets_. Ve skupině Bitcoin-Dev + [ohlásil][osuntokun bips] sedm návrhů na BIP (o jeden více než + při prvním oznámení protokolu, tehdy pod názvem _Taro_; viz. + [zpravodaj č. 195][news195 taro], *angl.*). Ve skupině Lightning-Dev + potom [ohlásil][osuntokun blip post] [návrh BLIPu][osuntokun blip] + pro posílání a přijímání taprootových aktiv přes LN pomocí protokolu + založeném na experimentálních „jednoduchých taprootových kanálech” + plánovaných pro LND 0.17.0-beta. + + I přes svůj název nejsou Taproot Assets součástí bitcoinového protokolu + a žádným způsobem nemění protokol konsenzu. Použitím stávajících + vlastností poskytuje nové funkce uživatelům, kteří mají zájem. + + Specifikace neobdržely v době psaní žádné komentáře. + +- **Změny v LN určené pro PTLC:** s blížícím se vydáním první + LN implementace s experimentální podporou kanálů používajících [P2TR][topic + taproot] a [MuSig2][topic musig] zaslal Greg Sanders do emailové + skupiny Lightning-Dev [příspěvek][sanders post] se [souhrnem][sanders ptlc] + úprav LN zpráv, které by umožnily zasílání plateb pomocí [PTLC][topic ptlc] + namísto [HTLC][topic htlc]. Většinou se změny nezdají být příliš rozsáhlé + či invazivní, poznamenáváme však, že většina implementací bude pravděpodobně + nadále používat jednu sadu zpráv pro přeposílání obstarožních HTLC a + jinou sadu pro přeposílání PTLC. Budou tedy obsahovat dvě odlišné cesty, + které budou muset být udržované až do vyřazení HTLC. Pokud by některá + z implementací přidala experimentální podporu PTLC ještě před standardizací + zpráv, musely by – ke škodě všech – implementace podporovat dokonce tři či více různých + protokolů najednou. + + Sandersův souhrn neobdržel v době psaní žádné komentáře. + +## Bitcoin Core PR Review Club + +*V této měsíční rubrice shrnujeme nedávné sezení [Bitcoin Core PR Review Club][] a +vyzdvihujeme některé z důležitých otázek a odpovědí. Klikněte na otázku a odpověď se vám odhalí.* + +[Abstrakce přenosu][review club 28165] je PR od Pietera Wuilleho (sipa), které bylo +nedávno začleněno a které přináší abstraktní třídu pro _transport dat_. Konkrétní implementace +této abstraktní třídy přeměňují serializované zprávy z a na přenosový formát. +Můžeme si to představit jako implementaci nižší úrovně serializace a deserializace. +Tyto třídy neprovádí samotné posílání a přijímání. + +PR též přináší dvě implementace třídy `Transport`: `V1Transport` (současný stav) a +`V2Transport` (šifrovaný přenos) a je součástí [projektu][v2 p2p tracking pr] +_P2P šifrovaného transportního protokolu verze 2_ dle [BIP324][topic v2 p2p transport]. + +{% include functions/details-list.md + q0="Jaký je rozdíl mezi [*net*][net] a [*net_processing*][net_processing]?" + a0="*Net* je zcela naspodu síťového rozhraní a má na starosti nízkoúrovňovou + komunikaci mezi spojeními. Nad ním je postaven *net_processing*, + který zprávy validuje a dále zpracovává." + a0link="https://bitcoincore.reviews/28165#l-22" + + q1="Jmenujte příklady tříd nebo funkcí, které jsou spojeny s _net_ a _net_processing_." + a1="*net_processing*: `PeerManager`, `ProcessMessage`. + *net*: `CNode`, `ReceiveMsgBytes`, `CConnMan`." + a1link="https://bitcoincore.reviews/28165#l-25" + + q2="Vyžaduje BIP324 změny na *net* vrstvě, *net_processing* vrstvě + či obou? Má dopad na pravidla či konsenzus?" + a2="Změny jsou pouze na *net* vrstvě. Nemají žádný dopad na konsenzus." + a2link="https://bitcoincore.reviews/28165#l-37" + + q3="Jaké jsou příklady implementačních chyb, které by mohly vyústit v nezamýšlenou + změnu konsenzu?" + a3="Chyba, která omezuje nejvyšší velikost zprávy na méně než 4 MB, což by + mělo za následek odmítání bloků validních podle jiných uzlů. Chyba v + deserializiaci bloku, která by způsobila odmítání validních bloků." + a3link="https://bitcoincore.reviews/28165#l-45" + + q4="`CNetMsgMaker` i `Transport` “serializují” zprávy. + Jaký je rozdíl mezi těmi dvěma?" + a4="`CNetMsgMaker` provádí serializaci datových struktur do bytů. + `Transport` obdrží tyto byty, přidá (serializuje) hlavičku a odešle." + a4link="https://bitcoincore.reviews/28165#l-60" + + q5="Co se děje během převodu objektů jako `CTransactionRef` (transakce) + do bytů či síťových paketů? Do jakých datových struktur jsou + převáděny?" + a5="`msgMaker.Make()` serializuje zprávu `CTransactionRef` voláním + `SerializeTransaction()`, poté `PushMessage()` umístí serializovanou + zprávu do fronty `vSendMsg`, potom `SocketSendData()` přidá hlavičku + a kontrolní součet (po tomto PR) a požádá transport o odeslání dalšího + paketu. Nakonec zavolá `m_sock->Send()`." + a5link="https://bitcoincore.reviews/28165#l-83" + + q6="Kolik bytů je odesláno po síti zprávou `sendtxrcncl` (berme tuto zprávu + používanou v [Erlay][topic erlay] jako jednoduchý příklad)?" + a6="36 bytů: 24 bytů je hlavička (4 pevné byty, příkaz 12 bytů, + velikost zprávy 4 byty, kontrolní součet 4 byty) a 12 bytů tělo + (verze 4 bytů, sůl 8 bytů)." + a6link="https://bitcoincore.reviews/28165#l-86" + + q7="Jsou v době návratu z funkce `PushMessage()` odeslány již byty odpovídající této + zprávě? Ano/ne/možná? Proč?" + a7="Možné jsou všechny odpovědi. **Ano**: *net_processing* nemusí činit nic + dalšího, aby se zpráva odeslala. **Ne**: je velice nepravděpodobné, že by + příjemce zprávu obdržel ještě před návratem této funkce. **Možná**: + jsou-li všechny fronty prázdné, byla zpráva již odeslána síťové vrstvě + jádra; pokud však některé fronty prázdné nejsou, bude odeslání ještě + čekat na uvolnění." + a7link="https://bitcoincore.reviews/28165#l-112" + + q8="Která vlákna mají přístup k `CNode::vSendMsg`?" + a8="`ThreadMessageHandler`, pokud je zpráva odeslána synchronně + („optimisticky”); `ThreadSocketHandler`, pokud je zařazena do fronty + a odeslána později." + a8link="https://bitcoincore.reviews/28165#l-120" +%} + +## Vydání nových verzí + +*Vydání nových verzí oblíbených páteřních bitcoinových projektů. Prosíme, +zvažte upgrade či pomoc s testováním.* + +- [LND v0.17.0-beta.rc2][] je kandidátem na vydání příští hlavní verze této + oblíbené implementace LN uzlu. Velkou novou experimentální funkcí + plánovanou pro toto vydání, které by prospělo testování, je podpora + „jednoduchých taprootových kanálů.” + +## Významné změny v kódu a dokumentaci + +*Významné změny z tohoto týdne v [Bitcoin Core][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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Bitcoin Core #26567][] mění způsob, jakým peněženka odhaduje váhu podepsaného + vstupu z [deskriptoru][topic descriptors]. Původní přístup, který prováděl podepsání + nanečisto, nebyl dostatečný pro některé složitější [miniscriptové][topic miniscript] + deskriptory. + +{% include references.md %} +{% include linkers/issues.md v=2 issues="26567" %} +[LND v0.17.0-beta.rc2]: https://github.com/lightningnetwork/lnd/releases/tag/v0.17.0-beta.rc2 +[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://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://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 new file mode 100644 index 0000000000..0d1e50c7a6 --- /dev/null +++ b/_posts/cs/newsletters/2023-09-20-newsletter.md @@ -0,0 +1,155 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 269' +permalink: /cs/newsletters/2023/09/20/ +name: 2023-09-20-newsletter-cs +slug: 2023-09-20-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme oznámení o nadcházejícím setkání badatelů a naše +pravidelné rubriky se souhrnem významných změn ve službách a klientském +software, oznámeními o nových vydáních a popisem významných změn v populárních +bitcoinových páteřních projektech. + +## Novinky + +- **Setkání bitcoinových badatelů:** Sergi Delgado Segura a Clara Shikhelman + zaslali do emailových skupin Bitcoin-Dev a Lightning-Dev [příspěvek][ds brd] + oznamující _Bitcoin Research Day_, osobní setkání, které se uskuteční + 27. října v New Yorku. Během dne vystoupí několik známých bitcoinových + badatelů. Rezervace jsou povinné. V době psaní bylo ještě několik volných + slotů pro pětiminutové prezentace. + +## 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.* + +- **Vydán Bitcoin-like Script Symbolic Tracer (B'SST):** + [B'SST][] je nástroj pro analýzu skriptů bitcoinu a Elements, který poskytuje rozbor + skriptů včetně „vynucovaných podmínek, možných selhání a možných hodnot dat.” + +- **Demo ověřování řetězce hlaviček pomocí STARK:** + Projekt [ZeroSync][news222 zerosync] oznámil [ukázku][zerosync demo] a + [repozitář][zerosync code] používající STARK k prokázání a ověření řetězce + bitcoinových hlaviček. + +- **Vydán JoinMarket v0.9.10:** + Vydání [v0.9.10][joinmarket v0.9.10] přináší podporu [RBF][topic rbf] u + ne[coinjoin][topic coinjoin]ových transakcí, vylepšený odhad poplatků a další + novinky. + +- **BitBox přidává miniscript:** + [Nový BitBox02 firmware][bitbox blog] přidává podporu [miniscriptu][topic + miniscript], bezpečnostní opravu a vylepšení použitelnosti. + +- **Machankura oznamuje aditivní dávkování:** + Poskytovatel bitcoinových služeb [Machankura][] [oznámil][machankura tweet] + beta verzi funkce, která podporuje aditivní [dávkování][batching] pomocí + RBF v [taprootové][topic taproot] peněžence s podporou [prahových][topic + threshold signature] podmínek utrácení FROST. + +- **Lightningový simulátor SimLN :** + [SimLN][] je simulační nástroj pro výzkumníky LN a vývojáře protokolu a aplikací, + který generuje realistickou aktivitu LN plateb. SimLN podporuje LND a CLN, + podpora pro Eclair a LDK-Node je ve vývoji. + +## 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.* + +- [Core Lightning 23.08.1][] je údržbovým vydáním obsahující opravy několika + chyb. + +- [LND v0.17.0-beta.rc4][] je kandidátem na vydání příští hlavní verze této + oblíbené implementace LN uzlu. Velkou novou experimentální funkcí + plánovanou pro toto vydání, které by prospělo testování, je podpora + „jednoduchých taprootových kanálů.” + +## Významné změny v kódu a dokumentaci + +*Významné změny z tohoto týdne v [Bitcoin Core][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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Bitcoin Core #26152][], stavějící na dříve přidaném rozhraní (viz + [zpravodaj č. 252][news252 bumpfee]), přidává možnost zaplatit jakýkoliv + _schodek poplatku_ („fee deficit”) mezi vstupy vybranými do + transakce. Schodek poplatku nastává, když musí peněženka zvolit UTXO + s nepotvrzenými rodiči, kteří platí nízký jednotkový poplatek. + Aby mohla transakce platit uživatelem zvolený jednotkový poplatek, + musí transakce platit dostatečně velký poplatek, aby zaplatila za sebe + i za nepotvrzené rodiče s nízkým jednotkovým poplatkem. Ve stručnosti + toto PR zajišťuje, aby se uživatelovi, který volbou poplatku určuje prioritu + potvrzení transakce, této priority dostálo, i když musí jeho peněženka platit + za nepotvrzená UTXO. Všechny ostatní peněženky, kterých jsme si vědomi, + garantují prioritu založenou na jednotkovém poplatku pouze v případě + utrácení potvrzených UTXO. Viz též [zpravodaj č. 229][news229 bumpfee], + jehož souhrn sezení Bitcoin Core PR Review Club se věnuje právě tomuto PR. + +- [Bitcoin Core #28414][] přidává do RPC volání `walletprocesspsbt` + kompletní serializovanou transakci, pokud tento krok vyústí v + transakci připravenou na zveřejnění. Díky tomu nemusí uživatel + volat `finalizepsbt`, pokud je [PSBT][topic psbt] již hotové. + +- [Bitcoin Core #28448][] zastarává konfigurační parameter `rpcserialversion` + určující verzi RPC serializací. Tato volba byla přidána během přechodu + na v0 segwit, aby mohly mít starší programy nadále přístup k blokům + a transakcím ve formátu bez segwitových polí. Dnes by již všechny + programy měly být schopné zpracovávat segwitové transakce a tato volba + by již neměla být potřebná. Dle poznámek k vydání přidaných tímto PR + je však možné volbu dočasně znovu aktivovat jako zastaralou. + +- [Bitcoin Core #28196][] přidává významný kus kódu potřebný k podpoře + [transportního protokolu verze 2][topic v2 p2p transport] dle specifikace + v [BIP324][] spolu s důsledným fuzz testováním tohoto kódu. Neaktivuje + žádné nové schopnosti, pouze redukuje množství kódu, který bude muset + být v budoucích PR přidán. + +- [Eclair #2743][] přidává RPC volání `bumpforceclose`, které řekne uzlu, + aby použil [anchor výstup][topic anchor outputs] kanálu na navýšení + poplatku commitment transakce pomocí [CPFP][topic cpfp]. Uzly Eclair + nabízí v nutných případech automatické navyšování poplatků, toto volání + umožní provozovateli učinit totéž i manuálně. + +- [LDK #2176][] navyšuje přesnost, se kterou se LDK pokouší o pravděpodobnostní + odhad výše likvidity ve vzdálených kanálech, přes které se snažilo + posílat platby. Přesnost byla dříve až 0,01500 BTC v 1BTC kanálech. Nová + přesnost dosahuje ve stejně velikých kanálech kolem 0,00006 BTC. Díky + tomu se může mírně snížit čas nalezení cesty pro platby, avšak testy + naznačují, že rozdíl bude velmi malý. + +- [LDK #2413][] přidává podporu pro zasílání plateb na [zaslepené cesty][topic + rv routing] a umožňuje přijímat platby na cesty, jejichž poslední skok + před odesílatelem je skrytý (zaslepený). [PR #2514][ldk #2514], též + začleněné tento týden, poskytuje další podporu zaslepených cest. + +- [LDK #2371][] přidává podporu správy plateb používajících [nabídky][topic + offers]. Umožňuje klientským aplikacím použít nabídku k zaznamenání + záměru provést platbu faktury, expirovat pokus o platbu, pokud odeslaná + nabídka nevyústí v odeslanou fakturu, a nato použít existující kód v LDK + k provedení platby faktury (včetně opakovaných pokusů v případě selhání). + +{% 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://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 +[B'SST]: https://github.com/dgpv/bsst +[news222 zerosync]: /en/newsletters/2022/10/19/#zerosync-project-launches +[zerosync demo]: https://zerosync.org/demo/ +[zerosync code]: https://github.com/ZeroSync/header_chain +[joinmarket v0.9.10]: https://github.com/JoinMarket-Org/joinmarket-clientserver/releases/tag/v0.9.10 +[bitbox blog]: https://bitbox.swiss/blog/bitbox-08-2023-marinelli-update/ +[Machankura]: https://8333.mobi/ +[machankura tweet]: https://twitter.com/machankura8333/status/1695827506794754104 +[batching]: /en/payment-batching/ +[SimLN]: https://github.com/bitcoin-dev-project/sim-ln diff --git a/_posts/cs/newsletters/2023-09-27-newsletter.md b/_posts/cs/newsletters/2023-09-27-newsletter.md new file mode 100644 index 0000000000..7eb1492a08 --- /dev/null +++ b/_posts/cs/newsletters/2023-09-27-newsletter.md @@ -0,0 +1,254 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 270' +permalink: /cs/newsletters/2023/09/27/ +name: 2023-09-27-newsletter-cs +slug: 2023-09-27-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme popis návrhu na použití kovenantů k významnému +navýšení škálovatelnosti LN. Též nechybí naše pravidelné rubriky se +souhrnem oblíbených otázek a odpovědí z Bitcoin Stack Exchange, +oznámeními o nových vydáních a popisem významných změn v populárním +bitcoinovém páteřním software. + +## Novinky + +- **Kovenanty pro navýšení škálovatelnosti LN:** John Law zaslal do + emailových skupin Bitcoin-Dev a Lightning-Dev [příspěvek][law cov + post] přinášející souhrn jeho [článku][law cov paper] o vytváření + velkých [továren kanálů][topic channel factories] pomocí [kovenantů][topic + covenants] a správě výsledných kanálů použitím verzí několika protokolů, + které dříve popsal; viz zpravodaje č. [221][news221 law] (*angl.*), + [230][news230 law] a [244][news244 law]. + + Nejdříve popisuje problém škálovatelnosti u protokolů založených na + digitálních podpisech, které vyžadují účast velkého množství uživatelů, + jako je [coinjoin][topic coinjoin] nebo předešlé návrhy na továrny: + dohodne-li se tisíc uživatelů na účasti v obdobném protokolu, ale jeden + z nich je během podepisování nedostupný, ostatních 999 podpisů je + k ničemu. Pokud je během dalšího pokusu jiný účastník nedostupný, + ostatních posbíraných 998 podpisů je též k ničemu. Jako řešení problému + navrhuje Law kovenanty typu [OP_CHECKTEMPLATEVERIFY][topic + op_checktemplateverify] či [SIGHASH_ANYPREVOUT][topic sighash_anyprevout]. + Ty, jak známo, umožňují malé transakci omezit, jak mohou být její prostředky + utraceny jednou či více předdefinovanými následnými transakcemi. Také tyto + následné transakce mohou být kovenantem omezeny. + + Law použitím tohoto mechanismu vytváří _expirační strom_ („timeout tree”), + ve kterém _zakládající transakce_ („funding transaction”) platí stromu + předem definovaných následných transakcí, které nakonec budou utraceny + offchain do velkého počtu oddělených platebních kanálů. Mechanismus + podobný Ark (viz [zpravodaj č. 253][news253 ark]) umožňuje každému + platebnímu kanálu volitelné zveřejnění onchain, ale též dává zakladatelům + továrny možnost získat zpět prostředky kanálu, který nebyl včas zveřejněn + onchain. Může to být velice efektivní: offchain expirační strom vytvářející + milióny kanálů může být vytvořen pomocí jedné malé onchain transakce. + Po expiraci mohou být prostředky vráceny zakladateli továrny v další + malé onchain transakci a jednotliví uživatelé mohou před expirací továrny + poslat své prostředky jinam přes LN. + + Tento model je kompatibilní s LN-Penalty, současným modelem konstrukce + kanálů, i s navrhovaným [LN-Symmetry][topic eltoo]. Avšak zbytek Lawova + článku se soustředí na modifikace jím navrhovaného protokolu optimalizovaného pro + továrny bez použití strážních věží (FFO-WF, „Fully Factory Optimized Watchtower + Free“), který použitím kovenantů nabízí několik výhod. Kromě výhod popsaných + v předchozích číslech zpravodaje, jako je například možnost _běžných uživatelů_ + být online jen pár minut každých několik měsíců a _zapálených uživatelů_ + efektivněji používat svůj kapitál napříč kanály, nová výhoda aktualizované + konstrukce umožňuje zakladateli továrny přesouvat prostředky běžných + uživatelů z jedné továrny (založené na konkrétní onchain transakci) do jiné + továrny (ukotvené v jiné onchain transakci), aniž by vyžadoval uživatelovu + spoluúčast. To znamená, že běžná uživatelka Alice, která ví, že musí být online + před půlroční expirací továrny, se může připojit po pěti měsících a zjistit, + že její prostředky byly již přesunuty do jiné továrny s novou, několikaměsíční + expirací. Alice nemusí dělat nic a přitom si zachovává celkovou kontrolu nad + svými prostředky. To snižuje pravděpodobnost situace, kdy se Alice připojí + online příliš krátkou dobu před expirací a zjistí, že je zakladatel továrny + dočasně nedostupný. Byla by tak nucena zveřejnit svou část expiračního + stromu onchain, což by vyžadovalo transakční poplatky a snižovalo celkovou + škálovatelnost sítě. + + Anthony Towns vyjádřil ve své [odpovědi][towns cov] obavu, kterou nazývá + problémem „burácejícího stáda” a jež byla v [původním článku o LN][ln paper] + nazývána „vynucený expirační spam” („forced expiration spam”). Townsova + obava spočívá v úmyslném či nahodilém selhání velkého zapáleného uživatele, + po kterém by muselo velké množství uživatelů ve stejný čas zveřejnit onchain + své časově citlivé transakce. Například továrna s miliónem uživatelů by + mohla vyžadovat včasné potvrzení až miliónu transakcí, po kterém by následovaly + až dva milióny dalších transakcí uživatelů, kteří chtějí otevřít nové kanály. + V současnosti trvá potvrzení tří miliónů transakcí zhruba týden. Uživatelé + továrny s miliónem uživatelů by tak mohli po továrně požadovat přesunutí + prostředků několik týdnů před expirací či několik měsíců, obávají-li se + podobných problémů postihující několik miliónových továren najednou. + + Jedna z verzí původního článku o LN navrhovala řešení tohoto problému pomocí + [myšlenky][maxwell clock stop] Gregoryho Maxwella, která by prodloužila expiraci, + pokud by byly „bloky plné” (například pokud by jednotkové poplatky byly příliš vysoké). + Law Townsovi [odpověděl][law fee stop], že již pracuje na konkrétním návrhu + řešení tohoto typu a zveřejní jej, až s ním bude hotov. + +## 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/" %} + +- [Jak v Bitcoin v0.1 fungovalo hledání spojení?]({{bse}}119507) + Pieter Wuille popisuje vývoj způsobů hledání spojení v Bitcoin Core od + hledání na IRC ve vydání 0.1 přes napevno zakódované IP adresy až po + současný DNS seeding. + +- [Mohla by série reorganizací rozbít bitcoin kvůli pravidlu dvou hodin?]({{bse}}119677) + Uživatel fiatjaf se táže, zda by mohla série reorganizací blockchainu, například + jako výsledek [fee snipingu][topic fee sniping], způsobit problémy kvůli + restrikcím časových razítek bitcoinových bloků. Antoine Poinsot a Pieter Wuille + popisují tyto dvě restrikce (musí být větší než [Median Time Past (MTP)][news146 mtp], + tj. medián časových razítek posledních 11 bloků, a ne více než dvě hodiny do + budoucnosti dle lokálního času) a vyvozuje, že ani jedna z restrikcí není + reorganizacemi umocněna. + +- [Existuje způsob, jak stáhnout bloky bez nutnosti nejdříve stáhnout hlavičky?]({{bse}}119503) + Pieter Wuille potvrzuje, že je možné stáhnout bloky bez hlaviček, ale upozorňuje + na nevýhodu, že dokud uzel nestáhne a nezpracuje všechny bloky, neví, zda je na nejlepším + blockchainu. Porovnává tento přístup s [prvotní synchronizací hlaviček][headers first pr] + a ukazuje, jaké P2P zprávy jsou u každého přístupu používány. + +- [Kde je ve zdrojovém kódu bitcoinu stanoven limit 21 miliónů?]({{bse}}119475) + Pieter Wuille vysvětluje funkci `GetBlockSubsidy` z Bitcoin Core, která + definuje plán uvolňování. Také odkazuje na předchozí diskuzi na Stack Exchange + o [limitu 20 999 999,976 9 BTC]({{bse}}38998) a ukazuje na konstantu `MAX_MONEY` + používanou jako rychlá kontrola v kódu validace konsenzu. + +- [Jsou bloky s nestandardními transakcemi přeposílány sítí nebo nejsou stejně jako nestandardní transakce?]({{bse}}119693) + Uživatel fiatjaf odpovídá, že i když transakce, které jsou dle [pravidel][policy series] + nestandardní, nejsou ve výchozím nastavení P2P sítí přeposílány, bloky obsahující + nestandardní transakce přeposílány jsou, pokud se drží pravidel konsenzu. + +- [Kdy mi Bitcoin Core umožňuje „zahodit transakci”?]({{bse}}119771) + Murch vypisuje tři podmínky, aby mohla být transakce v bitcoin Core + [zahozena][rpc abandontransaction]: + + - tato transakce ještě zahozena nebyla + - tato transakce ani žádná konfliktní transakce nejsou potvrzeny + - tato transakce není v mempoolu uzlu + +## Vydání nových verzí + +*Vydání nových verzí oblíbených páteřních bitcoinových projektů. Prosíme, +zvažte upgrade či pomoc s testováním.* + +- [LND v0.17.0-beta.rc5][] je kandidátem na vydání příští hlavní verze této + oblíbené implementace LN uzlu. Velkou novou experimentální funkcí + plánovanou pro toto vydání, které by prospělo testování, je podpora + „jednoduchých taprootových kanálů.” + +## Významné změny 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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Bitcoin Core #28492][] přidává do výsledku RPC volání `descriptorprocesspsbt` + kompletní serializovanou transakci, pokud zpracování [PSBT][topic psbt] + vyústí v transakci připravenou ke zveřejnění. Viz podobné začleněné PR + popsané v [minulém čísle zpravodaje][news269 psbt]. + +- [Bitcoin Core GUI #119][] odstraňuje v GUI ze seznamu transakcí zvláštní + kategorii „platba sama sobě.” Nově budou transakce, jejichž vstupy i + výstupy mají dopad na peněženku, zobrazeny na samostatných řádkách jako + přijetí a odeslání. Může to pomoci porozumění v případě [coinjoinů][topic + coinjoin] a [payjoinů][topic payjoin], i když Bitcoin Core zatím ani + jeden z těchto typů transakcí nepodporuje. + +- [Bitcoin Core GUI #738][] přidává do menu položku umožňující migraci + ze zastaralých peněženek založených na klíčích a jejich výstupních + skriptech uložených v BerkeleyDB (BDB) na moderní peněženku, která + používá [deskriptory][topic descriptors] uložené v SQLite. + +- [Bitcoin Core #28246][] aktualizuje způsob, kterým peněženka v Bitcoin + Core interně určuje, jakým výstupním skriptů (scriptPubKey) by měla + transakce platit. Dříve transakce platily kterýmkoliv výstupním + skriptům uživatelem určeným, ale pokud by byla do Bitcoin Core přidána + podpora [tichých plateb][topic silent payments], výstupní skripty + by byly odvozeny z dat ze vstupů vybraných pro transakci. Díky této + aktualizaci to bude snadnější. + +- [Core Lightning #6311][] odstraňuje volbu sestavení `--developer`, + která vyústila v binární soubory s více možnostmi než standardní + CLN. Nově jsou experimentální a doplňkové možnosti přístupné + konfigurační volbou `--developer` předanou během spuštění `lightningd`. + Volba sestavení `--enable-debug` bude i nadále produkovat mírně + odlišné binární soubory vhodné pro testování. + +- [Core Lightning #6617][] přidává do výsledku RPC volání `showrunes` + novou položku `last_used`, která zobrazuje čas posledního použití + _runy_ (autentizačního tokenu). + +- [Core Lightning #6686][] přidává do REST rozhraní nastavitelné hlavičky + Content-Security-Policy (CSP) a Cross-Origin-Resource-Sharing (CORS). + +- [Eclair #2613][] umožňuje, aby Eclair spravoval všechny své soukromé + klíče a používal Bitcoin Core pouze pro watch-only peněženku (peněženku + mající pouze veřejné klíče). To může být užitečné v případech, kdy + je Eclair provozován ve více zabezpečených prostředích než Bitcoin Core. + [Dokumentace][eclair keys] přidaná tímto PR obsahuje více podrobností. + +- [LND #7994][] přidává do RPC rozhraní vzdáleného podepisování podporu + pro otevírání taprootových kanálů. Rozhraní vyžaduje veřejný klíč a + nonce pro [MuSig2][topic musig]. + +- [LDK #2547][] přidává do kódu pravděpodobnostního vyhledávání cest + předpoklad, že vzdálené kanály mají pravděpodobně většinu své + likvidity na jedné straně kanálu. Například v případě jednobitcoinového + kanálu mezi Alicí a Bobem je nejméně pravděpodobný stav s 0,5 BTC + na každé straně. S větší pravděpodobností bude mít jeden z nich 0,9 BTC + a 0,99 BTC s ještě větší pravděpodobností. + +- [LDK #2534][] přidává metodu `ChannelManager::send_preflight_probes` + umožňující [sondování][topic payment probes] platební cesty před uskutečněním + samotné platby. Sonda je vytvořena odesílatelem jako běžná LN platba, ale + obsah jejího [HTLC][topic htlc] předobrazu je nastaven na nepoužitelnou + hodnotu (například hodnotu známou pouze odesílateli). Když platba dosáhne + svého cíle, příjemce ji odmítne z důvodu neznámého předobrazu a odešle + zpět chybovou hlášku. Obdrží-li odesílatel tuto chybu, ví, že platební + cesta má dostatek likvidity pro skutečnou platbu a skutečná platba + se stejnou částkou by tedy pravděpodobně uspěla. Pokud by obdržel jinou + chybovou hlášku, například chybu ukazující na nemožnost jednoho uzlu + na cestě platbu přeposlat, mohla by být pro sondu vybraná jiná cesta. + + Sondování před skutečnou platbou („preflight”) může být užitečný a levný + způsob nalezení uzlů v cestě, které mají nějaké potíže a mohly by způsobit + zdržení. Pokud na několik hodin uvízne několik set (či méně) satoshi, není + to většinou velký problém. Pokud by však uvízla částka představující + významnou část kapitálu uzlu, mohlo by to být velice otravné. Je též + možné sondovat několik cest zároveň a později z nich vybrat tu nejlepší + pro skutečnou platbu. + +{% include references.md %} +{% include linkers/issues.md v=2 issues="28492,119,738,28246,6311,6617,6686,2613,7994,2547,2534" %} +[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://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://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://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 +[eclair keys]: https://github.com/ACINQ/eclair/blob/d3ac58863fbb76f4a44a779a52a6893b43566b29/docs/ManagingBitcoinCoreKeys.md +[news269 psbt]: /cs/newsletters/2023/09/20/#bitcoin-core-28414 +[news146 mtp]: /en/newsletters/2021/04/28/#what-are-the-different-contexts-where-mtp-is-used-in-bitcoin +[headers first pr]: https://github.com/bitcoin/bitcoin/pull/4468 +[policy series]: /cs/blog/waiting-for-confirmation/ diff --git a/_posts/cs/newsletters/2023-10-04-newsletter.md b/_posts/cs/newsletters/2023-10-04-newsletter.md new file mode 100644 index 0000000000..967156f01f --- /dev/null +++ b/_posts/cs/newsletters/2023-10-04-newsletter.md @@ -0,0 +1,166 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 271' +permalink: /cs/newsletters/2023/10/04/ +name: 2023-10-04-newsletter-cs +slug: 2023-10-04-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme souhrn návrhu na vzdálené ovládání LN uzlů pomocí +hardwarových podpisových zařízení, popis výzkumu a kódu umožňující LN +uzlům dynamicky dělit platby a pohled na návrh zlepšení LN likvidity +umožněním skupině uzlů sdílet prostředky odděleně od svých běžných +kanálů. Též nechybí naše pravidelné rubriky s oznámeními nových verzí +a popisem významných změn v populárních bitcoinových páteřních projektech. + +## Novinky + +- **Zabezpečené vzdálené ovládání LN uzlů:** Bastien Teinturier + zaslal do emailové skupiny Lightning-Dev [příspěvek][teinturier remote post] + o [návrhu BLIPu][blips #28], který by specifikoval možnost uživatelů + posílat z hardwarových podpisových zařízení podepsané příkazy svým LN + uzlům nebo jiným peněženkám. Podpisové zařízení by muselo implementovat pouze + tento BLIP a komunikaci dle [BOLT8][] a LN uzel by musel implementovat + pouze BLIP. Jedná se o mechanismus podobný Core Lightning pluginu + _commando_ ([viz zpravodaj č. 210][news210 commando], *angl.*), který + umožňuje téměř kompletní vzdálené ovládání LN uzlu. Avšak Teinturier vidí + tuto funkci primárně jako způsob provádění nejcitlivějších úkonů jako + autorizace platby, tedy úkonů, pro které by byl uživatel ochoten projít + připojením a odemčením hardwarového zařízení. Mohlo by to koncovým + uživatelům usnadnit zabezpečení svých prostředků v LN stejným zařízením + jako zabezpečení onchain prostředků. + +- **Dělení a přepínání plateb:** Gijs van Dam zaslal do emailové skupiny + Lightning-Dev [příspěvek][van dam pss post] o [pluginu][pss plugin], který + napsal pro Core Lightning, a o souvisejícím [výzkumu][pss research], který + provedl. Plugin umožňuje přeposílajícím uzlům informovat svá spojení, + že podporují _dělení a přepínání plateb_ („přepínání” ve smyslu síťových přepínačů, + tedy switchů; PSS, „payment splitting and switching“). Nechť Alice + sdílí s Bobem kanál a oba podporují PSS. Když potom Alice obdrží platbu, která + má být přeposlána Bobovi, může ji plugin rozdělit na dvě či více [částí][topic + multipath payments]. Jedna z těchto částí může být přeposlána Bobovi běžným + způsobem, avšak ostatní části mohou následovat alternativní cesty (například + přes Carol). Bob počká, až obdrží všechny části, a potom platbu dále + přepošle běžným způsobem. + + Hlavní výhoda tohoto přístupu spočívá ve ztížení provádění _útoků odhalující zůstatky_ + (BDA, „Balance Discovery Attacks”), při kterých mohou třetí strany opakovaně + [sondovat][topic payment probes] kanál a sledovat jeho zůstatek. Pokud je + BDA prováděn pravidelně, může sledovat hodnoty plateb procházející kanálem. + Pokud je prováděn na mnoho kanálů, může sledovat konkrétní platbu napříč + sítí. Pokud by bylo použito PSS, útočník by musel vedle zůstatku kanálu + Alice–Bob také sledovat kanály Alice–Carol a Carol–Bob, aby mohl platbu + sledovat. I kdyby útočník sledoval zůstatek ve všech těchto kanálech, + výpočetní náročnost sledování platby by se zvyšovala spolu s pravděpodobností, + že by mohly být platby jiných uživatelů chybně pokládány za části původní, + sledované platby. Van Damův [výzkum][pss research] ukazuje 62% redukci + v množství informací, které by útočník mohl po nasazení PSS získat. + + Van Dam zmiňuje dvě další výhody PSS: navýšení propustnosti LN a jeho použití + jako část opatření proti [útoku zahlcením kanálu][topic channel jamming attacks]. + V době psaní zpravodaje obdržel nápad malé množství reakcí. + +- **Sdílená likvidita pro LN:** ZmnSCPxj zaslal do emailové skupiny + Lightning-Dev [příspěvek][zmnscpxj sidepools1] s návrhem na jím + zvané _sidepooly_. Ty by umožnily skupinám spolupracujících přeposílajících + uzlů vložit prostředky do stavového kontraktu, tedy do offchain kontraktu + (ukotveného onchain podobně jako LN kanál), který by umožnil prostředky + převádět mezi účastníky aktualizováním jeho offchain stavu. Například + úvodní stav přiznávající Alici, Bobovi a Carol každému 1 BTC by mohl + být aktualizován na nový stav, který dává Alici 2 BTC, Bobovi 0 BTC + a Carol 1 BTC. + + Přeposílající uzly by nadále mohly používat běžné LN kanály mezi páry + uzlů. Například tito tři uživatelé by mohli mít tři oddělené kanály: + Alice s Bobem, Bob s Carol a Carol s Alicí. Běžným způsobem by těmito + kanály přeposílali platby. + + Pokud by se jeden či více z těchto běžných kanálů staly nevyváženými, + například by příliš mnoho prostředků v kanálu mezi Alicí a Bobem + náleželo Alici, mohl by tento nepoměr být vyřešen provedením offchain + [peerswapu][peerswap] ve stavovém kontraktu. Například by mohla Carol + Alici poskytnout nějaké prostředky ve stavovém kontraktu výměnou za + stejnou částku zaslanou Alicí Carol přes Boba v běžném LN kanálu. + Tím by byla v LN kanálu mezi Alicí a Bobem znovu nastolena rovnováha. + + Jednou z výhod tohoto přístupu je, že nikdo kromě účastníků nemusí o + stavovém kontraktu vědět. Pro všechny běžné uživatele LN a všechny + ostatní přeposílající uzly bude LN fungovat podle současného protokolu. + Další výhodou v porovnání s existujícími způsoby rebalancování kanálů + je umožnění velkému množství přeposílajících uzlů zachovat přímá spojení + výměnou za malý onchain prostor. To by mohlo odstranit jakékoliv + onchain rebalanční poplatky mezi těmito spojeními. Díky zachování + minimálních rebalančních poplatků mohou přeposílající uzly udržovat + své kanály v rovnováze, což zlepší jejich možnost výdělku a + učiní posílání plateb LN sítí spolehlivější. + + Nevýhodou přístupu je nutnost udržovat stavový kontrakt s více účastníky, + což, pokud víme, zatím nebylo v produkčním prostředí implementováno. + ZmnSCPxj zmiňuje dva protokoly, které mohou sloužit jako základ: + [LN-Symmetry][topic eltoo] a [duplexní platební kanály][duplex payment + channels]. LN-Symmetry by vyžadoval změnu konsenzu, což se zřejmě + v blízké budoucnosti nestane, proto se v [následném příspěvku][zmnscpxj + sidepools2] ZmnSCPxj soustředí na duplexní platební kanály (které + ZmnSCPxj nazývá „Decker-Wattenhofer” podle autorů prvního návrhu). + Nevýhodou duplexních platebních kanálů je, že nemohou zůstat otevřené + nastálo, i když dle ZmnSCPxjovy analýzy pravděpodobně mohou být + otevřené dostatečně dlouho a projít dostatečným množstvím změn stavu, + aby byly jejich náklady efektivně amortizovány. + + V době psaní zpravodaje neobdržel příspěvek žádné veřejné reakce, + avšak ze soukromé korespondence se ZmnSCPxjem víme, že tuto myšlenku + dále rozvíjí. + +## Vydání nových verzí + +*Vydání nových verzí oblíbených páteřních bitcoinových projektů. Prosíme, +zvažte upgrade či pomoc s testováním.* + +- [LND v0.17.0-beta][] je vydáním příští hlavní verze této oblíbené + implementace LN uzlu. Hlavní novou experimentální funkcí tohoto + vydání je podpora „jednoduchých [taprootových][topic taproot] kanálů,” + které umožňují používat [neveřejné kanály][topic unannounced channels] + financované onchain pomocí P2TR výstupu. Jedná se o první krok směrem + k přidání dalších funkcí jako je podpora [Taproot Assets][topic client-side + validation] a [PTLC][topic ptlc]. Toto vydání také obsahuje významné zlepšení + výkonu pro uživatele backendu Neutrino, které podporuje [kompaktní filtry + bloků][topic compact block filters], a vylepšení funkcionality vestavěné + [strážní věže][topic watchtowers]. Více informací lze nalézt v [poznámkách + k vydání][lnd rn] a [blogovém příspěvku o vydání][lnd 17 blog]. + +## 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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Eclair #2756][] přináší monitorování [splicingových][topic splicing] operací. + Sbírány jsou informace o iniciátorovi operace a typ: splice-in, splice-out či + splice-cpfp. + +- [LDK #2486][] přidává podporu zakládání více kanálů jednou transakcí. Garantuje + přitom atomicitu, tedy založeny budou buď všechny kanály, nebo žádný. + +- [LDK #2609][] umožňuje vyžádat [deskriptory][topic descriptors], které byly + v minulosti použity pro obdržení platby. Dříve je museli uživatelé ukládat + sami, aktualizované API umožní z různých uložených dat deskriptory rekonstruovat. + +{% 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://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://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://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://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 new file mode 100644 index 0000000000..72e4c2ec15 --- /dev/null +++ b/_posts/cs/newsletters/2023-10-11-newsletter.md @@ -0,0 +1,204 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 272' +permalink: /cs/newsletters/2023/10/11/ +name: 2023-10-11-newsletter-cs +slug: 2023-10-11-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme odkaz na specifikaci navrhovaného opkódu +`OP_TXHASH`. Nechybí též naše pravidelné rubriky se souhrnem sezení +Bitcoin Core PR Review Club, oznámeními o nových vydáních a popisem +významných změn v populárních páteřních bitcoinových projektech. + +## Novinky + +- **Návrh specifikace `OP_TXHASH`:** Steven Roose zaslal do emailové + skupiny Bitcoin-Dev [příspěvek][roose txhash] s [návrhem BIPu][bips #1500] + nového opkódu `OP_TXHASH`. O myšlence stojící za tímto opkódem jsme + již dříve informovali (viz [zpravodaj č. 185][news185 txhash], *angl.*), + avšak jedná se o první její specifikaci. Kromě přesného popisu chování + opkódu se též zabývá opatřeními proti některým možným nevýhodám, jako + je potřeba plných uzlů spočítat několik megabytů hashů při každém volání + opkódu. Rooseův návrh obsahuje též ukázku implementace opkódu. + +## 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í.* + +[util: Typově bezpečné identifikátory transakcí][review club 28107] je PR od Niklase Göggeho +(dergoegge), které zvyšuje typovou bezpečnost zavedením odlišných typů +pro `txid` (identifikátor transakce, který neobsahuje data segwitových witnessů) +a `wtxid` (obsahující data segwitových witnessů). Dříve byly oba identifikátory +reprezentovány typem `uint256` (256bitové celé číslo, které může obsáhnout +SHA256 hash). PR by nemělo mít žádný dopad na provoz, cílí na zabránění +případných programátorských chyb, kvůli kterým by mohl být jeden druh +identifikátoru nesprávně použit namísto druhého. Podobné chyby budou nově +odhaleny v době kompilace. + +Za účelem minimalizace zásahů a usnadnění revize budou tyto nové typy +použity nejdříve v jediné části kódu (v „sirotčinci” transakcí), budoucí +PR pak jejich použíti mohou rozšiřovat dále. + +{% include functions/details-list.md + q0="Co znamená, když je identifikátor transakce typově bezpečný? + Proč je to důležité či užitečné? Přináší to nějaké nevýhody?" + a0="Typová bezpečnost zaručuje, že identifikátor transakce, který může nabývat + dvou různých významů (`txid` či `wtxid`), nemůže být použit s nesprávným + významem. Tedy `txid` nemůže být použito, je-li očekáváno `wtxid`, a naopak. + Tato vlastnost je vynucována kompilátorem během typové kontroly." + a0link="https://bitcoincore.reviews/28107#l-38" + + q1="Mělo být raději upřednostněno _začlenění_ (obalení) typu `uint256` + uvnitř nových tříd `Txid` a `Wtxid` před _děděním_ z `uint256`? + Jak si tyto dva přístupy stojí v porovnání?" + a1="Tyto třídy by mohly dědit, ale v důsledku by bylo potřeba pozměnit mnohem + víc řádků zdrojového kódu." + a1link="https://bitcoincore.reviews/28107#l-39" + + q2="Proč je lepší vynucovat typy během kompilace než za běhu?" + a2="Vývojáři nacházejí chyby rychleji během kódování a nemusí spoléhat + na psaní rozsáhlých testů, který by je odhalily za běhu (tyto testy + navíc nemusí všechny chyby najít). Avšak testování je i nadále + užitečné, neboť typová bezpečnost nezabrání zvolení nesprávného + typu identifikátoru." + a2link="https://bitcoincore.reviews/28107#l-67" + + q3="Kdy byste měli během psaní nového kódu odkazujícího na transakce + použít `txid` a kdy `wtxid`? Můžete ukázat na nějaké příklady kódu, + kdy by jejich záměna vedla k problémům?" + a3="Obecně je používání `wtxid` preferováno, neboť obsahuje celou transakci. + Důležitou výjimkou je `prevout`, který ve vstupech odkazuje na utrácený + výstup (UTXO) a musí být `txid`. [Zde][wtxid example] je příklad, + ve kterém je důležité použít jeden a nikoliv druhý typ (pro podrobnosti + viz [zpravodaj č. 104][news104 wtxid], *angl.*)." + a3link="https://bitcoincore.reviews/28107#l-85" + + q4="Jakým způsobem by mohlo používání `transaction_identifier` namísto + `uint256` odhalit existující chybu či zabránit zanesení nové? Na + druhou stranu, mohla by tato změna přinést nové chyby?" + a4="Bez tohoto PR bychom mohli funkci, která vyžaduje argument typu `uint256` + (např. identifikátor bloku), předat `txid`. Po tomto PR to vyvolá + chybu kompilace." + a4link="https://bitcoincore.reviews/28107#l-128" + + q5="Již existuje třída [`GenTxid`][GenTxid]. Jakým způsobem vynucuje + typovou správnost a jak se odlišuje od přístupu z tohoto PR?" + a5="Tato třída obsahuje hash a příznak určující, je-li hash `wtxid` + či `txid`. Jedná se tedy o jediný typ a ne o dva odlišné. Typovou + kontrolu umožňuje, ale musí být explicitně napsána v kódu a, + co je důležitější, může být prováděna pouze za běhu. Řeší případy, + ve kterých chceme předat kterýkoliv ze dvou druhů identifikátoru. + Proto toto PR `GenTxid` neodstraňuje. V budoucnu může být vhodnější + alternativou `std::variant`." + a5link="https://bitcoincore.reviews/28107#l-161" + + q6="Jak je možné, že `transaction_identifier` rozšiřuje `uint256`, + když jsou v C++ celá čísla typy a na třídami?" + a6="Protože samo `uint256` je třídou a ne vestavěným typem. + (Největší vestavěný celočíselný typ má v C++ 64 bitů.)" + a6link="https://bitcoincore.reviews/28107#l-194" + + q7="Chová se jinak `uint256` stejně jako například `uint64_t`?" + a7="Ne, aritmetické operace nejsou nad `uint256` povoleny, protože + nedávají pro hashe, které jsou hlavním použitím `uint256`, smysl. + Jméno je zavádějící, jedna se opravdu jen o shluk 256 bitů. + Existuje též `arith_uint256`, který aritmetické operace povoluje + (používaný například pro PoW výpočty)." + a7link="https://bitcoincore.reviews/28107#l-203" + + q8="Proč `transaction_identifier` rozšiřuje `uint256` namísto vytvoření + zcela nového typu?" + a8="Umožňuje nám prozatím ponechat beze změn kód, který očekává identifikátor + transakce ve formě `uint256` , a použít explicitní i implicitní konverze. + Kód může být ve vhodný čas refaktorován, aby používal striktnější typy + `Txid` či `Wtxid`." + a8link="https://bitcoincore.reviews/28107#l-219" +%} + +## 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 0.0.117][] je kandidátem na vydání této knihovny pro budování + LN aplikací. Přináší opravy bezpečnostních chyb související s + [anchor výstupy][topic anchor outputs] přidanými v předchozím vydání. + Dále mimo jiné zlepšuje hledání cest, podporu [strážní věže][topic + watchtowers] a umožňuje [dávkové][topic payment batching] financování + nových kanálů. + +- [BDK 0.29.0][] je kandidátem na vydání této knihovny pro budování + peněženek. Aktualizuje závislosti a opravuje (pravděpodobně vzácnou) + chybu objevující se v případech, kdy peněženka obdržela více než jeden + výstup z coinbasových transakcí. + +## 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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Bitcoin Core #27596][bitcoin core #27596] uzavírá první fázi + projektu [assumeutxo][topic assumeutxo]. Přináší všechny zbývající + změny potřebné pro používání assumedvalid snapshot chainstate i + pro plně validovanou synchronizaci na pozadí. UTXO snapshoty lze načíst + voláním `loadtxoutset`. Dále přidává do chainparams parametr `assumeutxo`. + + I když celý soubor nových funkcí nebude ještě před samotnou [aktivací][bitcoin + core #28553] na mainnetu přístupný, přináší tato změna vyvrcholení + několikaleté práce. Projekt, který byl [navržen v roce 2018][assumeutxo + core dev] a [formalizován v roce 2019][assumeutxo 2019 mailing list], + výrazně zpříjemní používání nových plných uzlů a jejich připojení do sítě. + Související následné změny: [Bitcoin Core #28590][bitcoin core #28590], + [#28562][bitcoin core #28562] a [#28589][bitcoin core #28589]. + +- [Bitcoin Core #28331][], [#28588][bitcoin core #28588], + [#28577][bitcoin core #28577] a [GUI #754][bitcoin core gui #754] + přidávají podporu [šifrovaného P2P přenosu verze 2][topic v2 p2p + transport] dle specifikace v [BIP324][]. Tato funkce je ve výchozím + nastavení neaktivní, může být však zapnuta volbou `-v2transport`. + + Šifrovaný přenos pomáhá navýšit soukromí bitcoinových uživatelů tím, + že zabraňuje pasivním pozorovatelům (jako jsou například poskytovatelé + internetového připojení) přímo zjistit, jaké transakce uzly přeposílají + svým spojením. Je též možné porovnáváním identifikátorů sezení zabránit + aktivním man-in-the-middle odposloucháním. V budoucnu přidané další + [funkce][topic countersign] mohou usnadnit lehkým klientům bezpečné + připojení k důvěryhodným uzlům. + +- [Bitcoin Core #27609][] zpřístupňuje RPC volání `submitpackage` i na jiných + sítích než regtest. Uživatelé mohou pomocí tohoto volání odesílat balíčky + jediné transakce s jejími nepotvrzenými předky, pokud žádný z předků + neutrácí výstup jiného předka. Potomek může být použit k provedení CPFP + předků, jejichž jednotkový poplatek spadá pod dynamické minimum mempoolu + uzlu. Jelikož však [přeposílání balíčků][topic package relay] není + ještě podporováno, nemusí se tyto transakce dostat k ostatním uzlům + v síti. + +- [Bitcoin Core GUI #764][] odstraňuje z GUI možnost vytvářet zastaralé + typy peněženek. Všechny nově vytvořené peněženky v budoucích verzích + Bitcoin Core budou založeny na [deskriptorech][topic descriptors]. + +- [Core Lightning #6676][] přidává nové RPC volání `addpsbtoutput`, které + přidá do [PSBT][topic psbt] výstup pro příjem onchain prostředků peněženkou + uzlu. + +{% 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://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 +[review club 28107]: https://bitcoincore.reviews/28107 +[wtxid example]: https://github.com/bitcoin/bitcoin/blob/3cd02806ecd2edd08236ede554f1685866625757/src/net_processing.cpp#L4334 +[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://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 new file mode 100644 index 0000000000..00a12469e2 --- /dev/null +++ b/_posts/cs/newsletters/2023-10-18-newsletter.md @@ -0,0 +1,182 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 273' +permalink: /cs/newsletters/2023/10/18/ +name: 2023-10-18-newsletter-cs +slug: 2023-10-18-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme stručnou zmínku nedávného zveřejnění bezpečnostního +problému postihujícího uživatele LN, popis článku o platbách podmíněných +výsledkem běhu libovolného programu a oznámení návrhu BIP na přidání polí +pro MuSig2 do PSBT. Též nechybí naše pravidelné rubriky se souhrnem vylepšení +klientů a služeb, oznámeními o nových vydáních a popisem významných změn v +populárním bitcoinovém páteřním software. + +## Novinky + +- **Zveřejnění bezpečnostního problému postihujícího LN:** Antoine Riard + zaslal do emailových skupin Bitcoin-Dev a Lightning-Dev [příspěvek][riard cve] + zveřejňující problém, který předtím sám [zodpovědně nahlásil][topic + responsible disclosures] vývojářům pracujícím na bitcoinovém + protokolu a různých populárních implementacích LN. Poslední verze + Core Lightning, Eclair, LDK a LND činí tento útok hůře proveditelným, + ačkoliv jádro problému zcela neodstraňují. + + Problém byl zveřejněn po obvyklé uzávěrce našeho zpravodaje, jsme tedy + schopni tento týden poskytnout pouze odkaz. Příští týden přineseme + více podrobností. + +- **Platby podmíněné libovolným výpočtem:** Robin Linus zaslal do emailové + skupiny Bitcoin-Dev [příspěvek][linus post] odkazující na svůj [článek][linus + paper] o _BitVM_. Jedná se o kombinaci metod, která umožňuje poslat + bitcoiny komukoliv, kdo prokáže, že úspěšně spustil nějaký program. + Popsaný způsob je možné provádět již nyní, nevyžaduje žádnou změnu + konsenzu bitcoinu. + + Známou vlastností bitcoinu je požadavek, aby odesílatel bitcoinů uspokojil + určitý programovací výraz (nazývaný _skript_), se kterým jsou odesílané + bitcoiny svázané. Například skript obsahující veřejný klíč může být + uspokojen pouze, pokud odpovídající soukromý klíč podepíše utrácející + transakci. Aby mohly být tyto skripty vynucovány konsenzem, musí být + napsány v jazyce bitcoinu (nazývaném _Script_), avšak Script je záměrně + ve svých možnostech omezen. + + Linusův článek některá tato omezení obchází. Pokud by Alice nedůvěřovala Bobovi + v ničem jiném, než že by Bob učinil nějaké kroky v případě nesprávného + spuštění programu, mohla by Alice poslat prostředky na [taprootový][topic taproot] + strom, který by Bobovi umožnil tyto prostředky nárokovat, pokud by prokázal, + že Alice správně nespustila nějaký program. Pokud by Alice program správně + spustila, mohla by prostředky sama utratit, i kdyby se ji Bob pokoušel zastavit. + + Aby mohl být použit libovolný program, musí být rozložen na základní + primitiva ([hradla NAND][NAND gate]) a musí být vytvořen commitment pro + každé hradlo. To si vyžádá offchain výměnu velkého množství dat, až + gigabyty i v případě jednoduchých programů. Avšak pokud Bob uzná, + že Alice program spustila správně, budou potřebovat jedinou onchain + transakci. V opačném případě bude muset Bob prokázat Alicino selhání + poměrně malým počtem onchain transakcí. Pokud by tento scénář proběhl + v platebním kanále mezi Alicí a Bobem, mohlo by několik programů + běžet paralelně nebo sekvenčně a nebylo by třeba žádných onchain + transakcí, kromě vytvoření kanálu a buď jeho kooperativního zavření + nebo vynuceného zavření, v rámci kterého by Bob demonstroval, že + Alice správně nevykonala logiku tohoto libovolného programu. + + BitVM lze bez požadavku na důvěru používat v případech, ve kterých jsou + Alice a Bob přirozenými protivníky, jakou je například hra v šachy: + oba pošlou prostředky na výstup, který bude moci být utracen vítězem partie. + Mohou potom použít dva (téměř identické) programy, z nichž každý obdrží + stejnou sekvenci šachových tahů. Jeden program vrátí true v případě + Alicina vítězství, druhý vrátí true v opačném případě. Jeden z účastníků + poté zveřejní onchain transakci, která bude tvrdit, že jeho program + vrátil true (tedy že vyhrál). Druhý účastník to buď uzná (a vzdá se prostředků) + nebo prokáže podvod (a obdrží prostředky). V případech, ve kterých + Alice a Bob přirozenými protivníky nejsou, by mohla Alice Bobovi poskytnout + podněty k ověřování správnosti výpočtu, například nabídkou prostředků, + pokud by Bob prokázal, že Alice výpočet správně neprovedla. + + Tato myšlenka obdržela v emailové skupině i na Twitteru a různých bitcoinových + podcastech velké množství komentářů. Očekáváme, že v následujících týdnech + a měsících bude diskuze pokračovat. + +- **Návrh BIPu na přidání polí pro MuSig2 do PSBT:** Andrew Chow zaslal + do emailové skupiny Bitcoin-Dev [příspěvek][chow mpsbt] s [návrhem BIPu][mpsbt-bip], + částečně založeným na [dřívější práci][kanjalkar mpsbt] Sanketa Kanjalkara, + na přidání několika polí pro „klíče, veřejná nonce a částečné podpisy + vyprodukované [MuSig2][topic musig]” do všech verzí [PSBT][topic psbt]. + + Anthony Towns [se zeptal][towns mpsbt], zda-li bude navrhovaný BIP též + obsahovat pole pro [adaptor signatures][topic adaptor signatures], avšak + probíhající diskuze naznačuje, že budou pravděpodobně definovány ve + zvláštním BIPu. + +## 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.* + +- **Vydána pythonová knihovna pro BIP-329:** + [BIP-329 Python Library][] je souborem nástrojů, který umí načítat, zapisovat, + šifrovat a dešifrovat soubory se štítky peněženek dle [BIP329][]. + +- **Oznámen nástroj pro testování LN Doppler:** + [Doppler][], který byl nedávno [oznámen][doppler announced], podporuje definování + topologie bitcoinových a lightningových uzlů a onchain/offchain platební aktivity + pomocí doménově specifického jazyka (DSL) a následné testování součinnosti LND, CLN + a Eclairu. + +- **Vydán Coldcard Mk4 v5.2.0:** + [Aktualizace][coldcard blog] firmwaru obsahuje podporu pro [PSBT][topic psbt] verze 2 + dle [BIP370][], rozšířenou podporu [BIP39][] a možnost používat více seedů. + +- **Tapleaf circuits: demo BitVM:** + [Tapleaf circuits][] je implementací obvodů ve formátu Bristol za použití + BitVM zmíněného výše. Účelem implementace je ověření konceptu. + +- **Vydán Samourai Wallet 0.99.98i:** + Vydání [0.99.98i][samourai blog] obsahuje rozšířenou podporu PSBT, štítkování UTXO + a dávkového odesílání. + +- **Krux: firmware pro podpisová zařízení:** + [Krux][krux github] je projektem open source firmware pro budování hardwarových + podpisových zařízení používající běžně dostupný hardware. + +## 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 24.2rc2][] a [Bitcoin Core 25.1rc1][] jsou kandidáty na vydání + údržbových verzí 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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Bitcoin Core #27255][] portuje [miniscript][topic miniscript] do [tapscriptu][topic tapscript]. + Tato změna umožňuje používat miniscript v P2TR [deskriptorech výstupu][topic descriptors], + a tím přidává podporu „tapminiscriptových deskriptorů” umožňujících sledování i podepisování. + Dříve byl miniscript dostupný pouze pro P2WSH deskriptory výstupu. Autor poznamenává, + že výhradně pro použití v P2TR deskriptorech byl přidán nový fragment `multi_a` (mající + sémantiku shodnou s `multi` v P2WSH deskriptorech). Komentář k PR poznamenává, + že většina úsilí byla věnována řádnému sledování změn spotřeby zdrojů v rámci tapscriptů. + +- [Eclair #2703][] odrazuje odesílatele od přeposílání plateb přes místní uzel, + je-li zůstatek uzlu nízký a hrozí-li jejich odmítnutí. Je tak dosahováno tím, + že uzel oznámí snížení maximální hodnoty HTLC. Předcházení odmítání plateb + zvyšuje plátcům komfort a napomáhá vyvarovat se penalizace místního uzlu + vyhledávači tras, které snižují hodnocení uzlů, jež nedávno nedokázaly + přeposlat platbu. + +- [LND #7267][] umožňuje vytvářet trasy do [zaslepených cest][topic rv routing]. + Díky tomu se LND posunulo výrazně blíže plné podpoře zaslepených plateb. + +- [BDK #1041][] přidává modul pro získávání dat o blockchainu z Bitcoin Core + pomocí jeho RPC rozhraní. + +{% include references.md %} +{% include linkers/issues.md v=2 issues="27255,2703,7267,1041" %} +[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://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://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 +[coldcard blog]: https://blog.coinkite.com/5.2.0-seed-vault/ +[Tapleaf circuits]: https://github.com/supertestnet/tapleaf-circuits +[samourai blog]: https://blog.samourai.is/wallet-update-0-99-98i/ +[krux github]: https://github.com/selfcustody/krux diff --git a/_posts/cs/newsletters/2023-10-25-newsletter.md b/_posts/cs/newsletters/2023-10-25-newsletter.md new file mode 100644 index 0000000000..362e6f1e98 --- /dev/null +++ b/_posts/cs/newsletters/2023-10-25-newsletter.md @@ -0,0 +1,520 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 274' +permalink: /cs/newsletters/2023/10/25/ +name: 2023-10-25-newsletter-cs +slug: 2023-10-25-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme popis replacement cycling útoku na HTLC používané v +LN i jiných systémech, zkoumáme opatření nasazená proti tomuto útoku a +vypisujeme návrhy na další možná opatření. Dále popisujeme významnou chybu +postihující Bitcoin Core RPC, výzkum kovenantů vyžadujících pouze minimální +změny bitcoinového Scriptu a návrh BIPu na opkód `OP_CAT`. Též nechybí naše +pravidelná měsíční rubrika se souhrnem oblíbených otázek a odpovědí z +Bitcoin Stack Exchange. + +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +## Novinky + +- **Zranitelnost replacement cycling postihující HTLC:** Jak bylo krátce + zmíněno v [minulém čísle zpravodaje][news274 cycle], zaslal Antoine Riard + do emailových skupin Bitcoin-Dev a Lightning-Dev [příspěvek][riard cycle1] + popisující [zodpovědně nahlášenou][topic responsible disclosures] + zranitelnost postihující starší verze všech implementací LN. V době od + nahlášení byla do implementací přidána opatření před útokem, důrazně + doporučujeme aktualizovat vámi používaný LN software na poslední verzi. + Postiženy jsou pouze uzly přeposílající platby; uzly používané pouze pro + zahajování či přijímání plateb postiženy nejsou. + + Náš popis této zranitelnosti je rozdělen do tří částí: samotný popis + zranitelnosti (tento bod), popis opatření dosud nasazených implementacemi + LN a souhrn dodatečných opatření a řešení navržených v emailové skupině. + + Pro připomenutí: je možné využít [nahrazování transakcí][topic rbf] + k odstranění jednoho či více vstupů transakce (mající více vstupů) z mempoolu. + Mějme jednoduchý příklad, [drobně odlišný]({{bse}}120200) od + původního Riardova popisu: Mallory zveřejní transakci se dvěma vstupy, + které utrácí výstupy _A_ a _B_. Potom nahradí tuto transakci alternativní + verzi s jediným vstupem, který utrácí pouze výstup _B_. Po tomto + nahrazení je vstup _A_ (a všechna související data) odstraněn z mempoolů, + které toto nahrazení zpracovaly. + + Ač není tento postup pro běžnou peněženku bezpečný[^rbf-warning], je to + chování, kterého může Mallory zneužít k odstranění vstupu z mempoolů. + + Konkrétně sdílí-li Mallory kontrolu nad výstupem s Bobem, může počkat, až Bob + výstup utratí, poté může nahradit jeho utracení svým vlastním, které obsahuje + dodatečný vstup, a nato může nahradit své utracení transakcí, která společný + výstup již neutrácí. A právě toto je _replacement cycle_ („cyklus nahrazování“). + Těžaři sice obdrží od Mallory transakční poplatky, ale s velkou pravděpodobností + nebude Bobovo ani Mallořino utracení výstupu během krátké doby od zveřejnění + potvrzeno. + + To je důležité v případě LN a několika dalších protokolů, protože určité transakce + se musí objevit během určitého časového okna, aby bylo zajištěno, že uživatelé + přeposílající platby nepřijdou o peníze. Příklad: Mallory použije jeden ze + svých uzlů (nazývejme ho _MalloryA_) pro přeposlání platby Bobovi a Bob + přepošle tuto platbu dalšímu z Mallořiných uzlů (_MalloryB_). Od MalloryB se + očekává, že buď poskytne Bobovi _předobraz_ (který mu umožní obdržet přeposlanou + platbu od MalloryA) nebo přeposílanou platbu od Boba během určité doby zruší (revokuje). + Namísto toho ale MalloryB během určené doby nic neudělá, a Bob je tak donucen + zavřít kanál a zveřejnit transakci, která by mu zpět poslala tuto přeposílanou + platbu. Tato transakce by měla být ihned potvrzena, aby tím mohl Bob zrušit + (revokovat) platbu od MalloryA, čímž by se zůstatek každého účastníka vrátil + do stavu před pokusem o přeposlání platby (kromě transakčních poplatků + za zavření a urovnání kanálu mezi Bobem a MalloryB). + + Druhou možností je, že Bob kanál zavře a pokusí se utratit přeposílanou platbu + zpět sobě. MalloryB toto utracení nahradí svým vlastním a tím odhalí předobraz. + Je-li tato transakce včas potvrzena, může Bob pomocí tohoto předobrazu nárokovat + platbu od MalloryA. Bob by tak byl spokojen. + + Pokud však MalloryB nahradí Bobovu transakci svou vlastní transakcí, která + obsahuje předobraz, a nato rychle ten vstup odstraní, je + nepravděpodobné, že by se Bobova transakce i předobraz MalloryB objevily + na blockchainu. Bob by tak nedostal od MalloryB své peníze zpět. Bez + předobrazu by nebyl Bob schopen držet přeposílanou platbu od MalloryA, musel by ji + tedy refundovat. V tento okamžik by mohla MalloryB zveřejnit a nechat potvrdit + transakci s předobrazem, což by jí umožnilo nárokovat přeposílanou platbu od Boba. + Byla-li by přeposílaná částka _x_, MalloryA by nezaplatila nic, MalloryB by obdržela _x_ + a Bob by o _x_ přišel (různé poplatky nejsou zahrnuty). + + 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 + ``` + + 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 + relay], které byly navrženy na ochranu před pinningem, jsou pro replacement + cycling nedostatečné. + +- **Opatření proti replacement cycling nasazená v LN uzlech:** jak + [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. + +- **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. + +- **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] + s oznámením o objevení chyby v Bitcoin Core ve výpočtu hashe aktuální + množiny UTXO. Výpočet hashe UTXO nebral do úvahy výšku a coinbase, + které jsou nutné pro vynucování pravidel 100blokové zralosti coinbasových + transakcí a relativních časových zámků dle [BIP68][]. Všechny tyto informace + zůstávají v databázi uzlu, který se synchronizuje od nuly (všechny současné + Bitcoin Core uzly), a jsou nadále používané pro vynucování, takže tato chyba + nepostihuje žádný známý vydaný software. Avšak experimentální [assumeUTXO][topic + assumeutxo] plánované pro příští hlavní verzi Bitcoin Core umožní uživatelům + navzájem sdílet své UTXO databáze. Neúplný commitment znamená, že upravená + databáze by mohla mít stejný hash jako ověřená databáze, což by mohlo + otevřít úzké okno útokům proti uživatelům assumeUTXO. + + Pokud víte o software, který používá pole `hash_serialized_2`, upozorněte + prosím autory na tento problém a doporučte jim přečtení Jahrova emailu + popisující změny, které budou v příštím hlavním vydání Bitcoin Core tuto + chybu adresovat. + +- **Výzkum obecných kovenantů s minimálními změnami Scriptu:** + Rusty Russell zaslal do emailové skupiny Bitcoin-Dev [příspěvek][russell + scripts] s odkazem na svůj [výzkum][russell scripts blog] použití + několika jednoduchých nových opkódů umožňujících skriptu spouštěnému + v transakci nahlížet do výstupních skriptů, na které se platí v té + stejné transakci (_introspekce_). Schopnost provádět introspekci + výstupních skriptů (a jejich commitmentů) by umožnila implementaci + [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. + + 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. + +- **Návrh BIPu pro OP_CAT:** Ethan Heilman zaslal do emailové skupiny + Bitcoin-Dev [příspěvek][heilman cat] s [návrhem BIPu][op_cat bip] + na přidání opkódu [OP_CAT][] do tapscriptu. Opkód by spojil dva elementy + z vrcholu zásobníku do jednoho elementu. Odkazuje na několik popisů + možností, které by sám `OP_CAT` přinesl. Jím navrhovaná referenční + implementace obsahuje pouze 13 řádků (kromě prázdných řádků). + + Návrh obdržel průměrné množství reakcí, většina z nich se soustředila + na limity v tapscriptu, které mohou snižovat užitečnost, a maximální + možné náklady aktivace `OP_CAT` (či měl-li být některý z těchto limitů + pozměněn). + +## 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 %} + +- [Jak funguje algoritmus výběru mincí Branch and Bound?]({{bse}}119919) + Murch shrnuje své bádání o algoritmu [Branch and Bound][branch + and bound paper] („metoda větví a mezí”) pro [výběr mincí][topic coin selection], + který „hledá nejméně plýtvající množinu vstupů, která produkuje transakci bez + zůstatku.“ + +- [Proč se v bitcoinové síti posílá každá transakce dvakrát?]({{bse}}119819) + Antoine Poinsot odpovídá na starší Satoshiho příspěvek v emailové skupině, který + tvrdí, že „každá transakce musí být poslána dvakrát.” Poinsot vysvětluje, že + sice v té době byla transakce poslána dvakrát (jednou během přeposílání transakce, + podruhé během přeposílání bloku), avšak po následném přidání [přeposílání kompaktních bloků][topic + compact block relay] dle [BIP152][] se data transakcí posílají jen jednou + na každé spojení. + +- [Proč jsou v bitcoinu OP_MUL a OP_DIV neaktivní?]({{bse}}119785) + Antoine Poinsot se domnívá, že opkódy `OP_MUL` a `OP_DIV` byly pravděpodobně + deaktivovány (spolu s [dalšími opkódy][github disable opcodes]) v reakci na + chyby [„1 RETURN”]({{bse}}38037) a [OP_LSHIFT crash][CVE-2010-5137] objevené + několik týdnů předtím. + +- [Proč jsou hashSequence a hashPrevouts počítány odděleně?]({{bse}}119832) + Pieter Wuille vysvětluje, že rozdělením hashovaných dat transakce na + předchozí výstupy a sekvence je možné hashe vypočítat pouze jednou + a použít je na výpočet všech druhů sighash. + +- [Proč při porovnávání hashe přidává Miniscript kontrolu velikosti předobrazu?]({{bse}}119892) + Antoine Poinsot poznamenává, že [miniscript][topic miniscript] omezuje předobrazy + ve velikosti, aby se vyvaroval nestandardních bitcoinových transakcí a + nevalidních atomických směn napříč různými blockchainy a aby zajistil možnost + přesného výpočtu velikosti (a nákladů) witnessů. + +- [Jak může být poplatek v příštím bloku nižší, než je vylučovací poplatek mempoolu?]({{bse}}120015) + Uživatel Steven odkazuje na rozhraní mempool.space, které ukazuje výchozí vylučovací + poplatek 1,51 sat/vB, ale zároveň odhaduje, že příští blok bude obsahovat transakci + s poplatkem 1,49 sat/vB. Podle Glozow je pravděpodobným vysvětlením, že plný mempool + vyloučil transakci, která navyšovala minimální jednotkový poplatek (`-incrementalRelayFee`), + ale ponechal v mempoolu některé transakce s nižším jednotkovým poplatkem, které vyloučeny + být nemusely. + + Též zmiňuje, že asymetrie mezi [skórem předků][waiting for confirmation 2] pro výběr šablony + bloku a skórem potomků pro vyloučení z mempoolu může být dalším možným vysvětlením. + Odkazuje na [problém][Bitcoin Core #27677] související s [cluster mempool][topic cluster + mempool], který asymetrii vysvětluje a nabízí možný nový přístup. + +## 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 25.1][] je údržbovým vydáním obsahujícím hlavně opravy chyb. + Jedná se o aktuálně doporučovanou verzi Bitcoin Core. + +- [Bitcoin Core 24.2][] je údržbovým vydáním obsahujícím hlavně opravy chyb. + Je doporučována každému, kdo stále používá 24.0 nebo 24.1 a není schopen + či ochoten aktualizovat na verzi 25.1. + +- [Bitcoin Core 26.0rc1][] je kandidátem na vydání příští hlavní verze této + převládající implementace plného uzlu. Ověřené testovací binárky nebyly + v době psaní zveřejněny, očekáváme však jejich zveřejnění na této adrese + krátce po vydání zpravodaje. Kandidáti na předchozí vydání mívají průvodce + testování na [Bitcoin Core developer wiki][] a sezení [Bitcoin Core PR + Review Club][] věnované testování. Vyzýváme čtenáře, aby pravidelně + kontrolovali, zda jsou tyto zdroje již dostupné i pro tohoto kandidáta. + +## Významné změny kódu a dokumentace +_Kvůli objemu novinek v tomto čísle a nedostatku času našeho hlavního +autora jsme nebyli schopni zpracovat přehled změn kódu za poslední týden. +Budou obsaženy v příštím vydání. Za zpoždění se omlouváme._ + +## Poznámky + +[^rbf-warning]: + Replacement cycle útok popsaný zde je založen na nahrazení transakce + transakcí s nižším počtem vstupů, než měla transakce původní. Autoři + peněženek jsou většinou před tímto chováním varováni. Například kniha + _Mastering Bitcoin, 3rd edition_ uvádí: + + > Buďte obzvláště opatrní, vytváříte-li více než jedno nahrazení stejné + > transakce. Musíte zajistit, aby byly všechny verze transakce v konfliktu + > se všemi ostatními. Pokud by v konfliktu nebyly, mohlo by dojít k potvrzení + > více transakcí, což by vedlo k přeplacení. Například: + > + > - Transakce verze 0 obsahuje vstup A. + > + > - Transakce verze 1 obsahuje vstupy A a B (např. jste museli přidat vstup B + > k zaplacení poplatku). + > + > - Transakce verze 2 obsahuje vstupy B a C (např. jste museli přidat vstup C + > k platbě zvláštních poplatků, ale C bylo dostatečně velké, že už jste + > nepotřebovali A). + > + > V tomto scénáři může těžař, který uložil transakci verze 0, potvrdit verze 0 i 2. + > Platí-li obě verze stejnému příjemci, obdrží prostředky dvakrát (a těžař obdrží + > poplatky ze dvou transakcí). + > + > Jednoduchým způsobem, jak se tomuto problému vyhnout, je ujistit se, že nahrazující + > transakce vždy obsahuje všechny vstupy jako její předchozí verze. + +{% 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://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://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://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://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/ +[news40 delta]: /en/newsletters/2019/04/02/#lnd-2759 +[news95 delta]: /en/newsletters/2020/04/29/#new-attack-against-ln-payment-atomicity +[news109 delta]: /en/newsletters/2020/08/05/#lnd-4488 +[news112 delta]: /en/newsletters/2020/08/26/#bolts-785 +[news142 delta]: /en/newsletters/2021/03/31/#rust-lightning-849 +[news248 delta]: /cs/newsletters/2023/04/26/#lnd-v0-16-1-beta +[news255 delta]: /cs/newsletters/2023/06/14/#eclair-2677 +[bitcoin core developer wiki]: https://github.com/bitcoin-core/bitcoin-devwiki/wiki +[bitcoin core pr review club]: https://bitcoincore.reviews/#upcoming-meetings +[branch and bound paper]: https://murch.one/erhardt2016coinselection.pdf +[github disable opcodes]: https://github.com/bitcoin/bitcoin/commit/4bd188c4383d6e614e18f79dc337fbabe8464c82#diff-27496895958ca30c47bbb873299a2ad7a7ea1003a9faa96b317250e3b7aa1fefR94 +[CVE-2010-5137]: https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures#CVE-2010-5137 +[waiting for confirmation 2]: /cs/blog/waiting-for-confirmation/#incentivy diff --git a/_posts/cs/newsletters/2023-11-01-newsletter.md b/_posts/cs/newsletters/2023-11-01-newsletter.md new file mode 100644 index 0000000000..11e4cd51cd --- /dev/null +++ b/_posts/cs/newsletters/2023-11-01-newsletter.md @@ -0,0 +1,159 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 275' +permalink: /cs/newsletters/2023/11/01/ +name: 2023-11-01-newsletter-cs +slug: 2023-11-01-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme pokračování několika nedávných diskuzí o návrzích +změn bitcoinového skriptovacího jazyka. 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 + +- **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á. + +## 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 0.0.118][] je nejnovějším vydáním této knihovny pro budování LN + aplikací. Obsahuje vedle dalších nových funkcí a oprav chyb i částečnou + experimentální podporu protokolu [nabídek][topic offers]. + +- [Rust Bitcoin 0.31.1][] je nejnovějším vydáním této knihovny pro práci + s bitcoinovými daty. Pro seznam nových funkcí a oprav chyb viz [poznámky + k vydání][rb rn]. + +_Poznámka:_ Bitcoin Core 26.0rc1, který jsme zmínili v předešlém čísle, +má ve zdrojovém kódu svůj štítek, avšak binární sestavení nebyla zveřejněna +kvůli změně od Apple, která zabraňuje vytvoření reprodukovatelných binárek +pro macOS. Vývojáři Bitcoin Core pracují na odstranění problému v rámci +druhého kandidáta na vydání. + +## 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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Bitcoin Core #28685][] opravuje chybu ve výpočtu hashe množiny UTXO, kterou + jsme zmínili v [předchozím čísle][news274 hash bug]. Obsahuje nekompatibilní + změnu v RPC volání `gettxoutsetinfo`, ve kterém nahrazuje pole `hash_serialized_2` + novým polem `hash_serialized_3` obsahujícím správný hash. + +- [Bitcoin Core #28651][] umožňuje [miniscriptu][topic miniscript] přesněji + odhadovat nejvyšší počet bytů, které bude nutné začlenit do struktury + witnessu, aby mohl být [taprootový][topic taproot] výstup utracen. + Zvýšená přesnost pomůže Bitcoin Core zabránit přeplácení na poplatcích. + +- [Bitcoin Core #28565][] staví nad [#27511][Bitcoin Core #27511] a přidává + RPC volání `getaddrmaninfo` zobrazující počet adres spojení, která jsou + buď „new” (nová) nebo „tried” (vyzkoušená), seskupených dle sítě (IPv4, IPv6, + Tor, I2P, CJDNS). Pro motivaci, která stojí za tímto členěním, viz [zpravodaj + č. 237][news237 pr review] a [podcast č. 237][pod237 pr review]. + +- [LND #7828][] vyžaduje, aby spojení odpovídala na zprávy `ping` + v rozumné době, jinak budou odpojena. Pomůže to zajistit, aby spojení + zůstávala aktivní (což sníží pravděpodobnost, že by mrtvé spojení + pozdrželo platbu a vynutilo si tak nežádoucí zavření kanálu). Existuje + mnoho dalších výhod posílání pingů a pongů: mohou pomoci zastřít síťovou + aktivitu, ztížit trasování plateb (jelikož ping, pong i platby jsou šifrované), + pomáhají častěji obměňovat šifrovací klíče (viz [BOLT1][]) a LND používá + zprávy `pong` k zabránění [útoků zastíněním][topic eclipse attacks] („eclipse + attacks”, viz [zpravodaj č. 164][news164 pong], _angl._). + +- [LDK #2660][] poskytuje volajícím více flexibility ve výběru jednotkového + poplatku pro onhcain transakce, včetně nastavení pro absolutní minimum, + nízký poplatek způsobující i více než den čekání na potvrzení, normální + prioritu a zvýšenou prioritu. + +- [BOLTs #1086][] stanovuje, že uzly by měly odmítnout (refundovat) HTLC a + vrátit chybu `expiry_too_far`, pokud by instrukce pro vytvoření přeposílaného + [HTLC][topic htlc] požadovaly, aby místní uzel čekal více než 2 016 bloků, + než by si mohl nárokovat refundaci. Snížení tohoto nastavení redukuje nejhorší + možnou ztrátu příjmu uzlu způsobenou [útokem zahlcením kanálu][topic channel + jamming attacks] („channel jamming attack”) nebo dlouhotrvající [pozdrženou + fakturou][topic hold invoices] („hold invoice”). Navýšení tohoto nastavení + umožňuje platbám, aby byly přeposlány více kanály za použití nastavení stejných + maximálních HTLC delta (nebo stejný počet skoků s vyšším maximálním HTLC delta, + což může zlepšit obranu proti určitým útokům, jako je replacement cycling + popsaný v [minulém čísle][news274 cycling]). + +{% 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://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://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://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://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 +[news274 cycling]: /cs/newsletters/2023/10/25/#zranitelnost-replacement-cycling-postihujici-htlc +[ldk 0.0.118]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.0.118 +[rust bitcoin 0.31.1]: https://github.com/rust-bitcoin/rust-bitcoin/releases/tag/bitcoin-0.31.0 +[rb rn]: https://github.com/rust-bitcoin/rust-bitcoin/blob/master/bitcoin/CHANGELOG.md#0311---2023-10-18 +[news274 hash bug]: /cs/newsletters/2023/10/25/#nahrazeni-vypoctu-hashe-mnoziny-bitcoinovych-utxo +[news237 pr review]: /cs/newsletters/2023/02/08/#bitcoin-core-pr-review-club +[pod237 pr review]: /en/podcast/2023/02/09/#bitcoin-core-pr-review-club-transcript diff --git a/_posts/cs/newsletters/2023-11-08-newsletter.md b/_posts/cs/newsletters/2023-11-08-newsletter.md new file mode 100644 index 0000000000..bfdb5dad88 --- /dev/null +++ b/_posts/cs/newsletters/2023-11-08-newsletter.md @@ -0,0 +1,209 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 276' +permalink: /cs/newsletters/2023/11/08/ +name: 2023-11-08-newsletter-cs +slug: 2023-11-08-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme oznámení o nadcházejících změnách v emailové skupině +Bitcoin-Dev a krátký souhrn návrhu na agregaci několika HTLC dohromady. Též +nechybí naše pravidelné rubriky se souhrnem sezení Bitcoin Core PR Review Club, +oznámeními o nových vydáních a popisem významných změn v populárním +bitcoinovém páteřním software. + +## Novinky + +- **Hosting emailové skupiny:** administrátoři emailové skupiny Bitcoin-Dev + [oznámili][bishop lists], že organizace, která skupinu na svých serverech + hostuje, tak přestane po novém roce činit. Archiv emailů by měl na současných + webových adresách v dohledné době zůstat. Předpokládáme, že stejným + způsobem bude postižena i skupina Lightning-Dev, která je hostována + stejnou organizací. + + Administrátoři žádali komunitu o poskytnutí zpětné vazby ohledně možností, + mezi kterými je i migrace skupiny do Google Groups. Pokud by takový + přechod nastal, Optech by jej začal používat jako jeden ze svých + [zdrojů][sources]. + + Jsme si vědomi, že před několika měsíci začali někteří etablovaní vývojáři + experimentovat s diskuzemi na webovém fóru [DelvingBitcoin][]. Optech okamžitě + začne toto fórum monitorovat. + +- **Agregace HTLC pomocí kovenantů:** Johan Torås Halseth zaslal do emailové + skupiny Lightning-Dev [příspěvek][halseth agg] s návrhem na agregaci několika + [HTLC][topic htlc] do jediného výstupu pomocí [kovenantu][topic covenants]. + Takový výstup by mohl být v případě znalosti všech předobrazů utracen najednou. + Pokud by utrácející neznal všechny předobrazy, mohl by nárokovat jen ty, které + zná, a zůstatek by byl zaslán druhé straně. Halseth poznamenává, že tento + způsob by byl efektivnější onchain a mohl by ztížit provádění určitého druhu + [útoku zahlcením kanálu][topic channel jamming attacks]. + +## 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í.* + +[Aktualizace odhadu poplatku z Validation rozhraní/CScheduler vlákna][review club 28368] +je PR od Abubakara Sadiqa Ismaila (ismaelsadeeq), které upravuje způsob, jímž +je aktualizován odhad poplatků za transakce. (Odhad poplatků se používá, když +vlastník uzlu vytváří transakci.) Dříve probíhaly aktualizace odhadu poplatků +synchronně během aktualizací mempoolu (když byly transakce přidány nebo odebrány), +nově by se tak mělo dít asynchronně. I když tento způsob přidává na složitosti, +zvyšuje výkonnost v kritické cestě (což následující diskuze ozřejmí). + +Když je nalezen nový blok, jeho transakce jsou spolu s konfliktními transakcemi +odstraněny z mempoolu. Jelikož je zpracování bloků a jejich přeposílání kritické z hlediska +výkonnosti, je výhodné snížit během zpracování nového bloku množství požadované +práce, jako jen například aktualizace odhadu poplatků. + +{% include functions/details-list.md + q0="Proč je výhodné odstranit z `CTxMempool` závislost na `CBlockPolicyEstimator`?" + a0="V současnosti je po přijetí nového bloku jeho zpracování blokováno, dokud se + nedokončí aktualizace odhadu poplatků. To má za následek delší zpracování a + prodlevu v přeposílání. Odstraněním závislosti na `CBlockPolicyEstimator` + z `CTxMempool` může být odhad poplatků aktualizován asynchronně, tj. + z jiného vlákna. Validace a přeposílání tak mohou být dokončeny rychleji. + Navíc testování `CTxMempool` může být snazší. V budoucnu to také umožní + používat složitější algoritmy odhadu poplatků, aniž by měly dopad + na rychlost validace a přeposílání." + a0link="https://bitcoincore.reviews/28368#l-30" + + q1="Není odhad poplatků aktualizován synchronně pokaždé, když jsou transakce přidány či + odebrány z mempoolu, bez ohledu na to, zda uzel obdržel nový blok?" + a1="Ano, ale výkonnost není tak kritická jako během validace a přeposílání." + a1link="https://bitcoincore.reviews/28368#l-41" + + q2="Nabízí současný stav, tedy `CBlockPolicyEstimator` uvnitř `CTxMempool` + a synchronní aktualizace, nějaké výhody? Přináší jeho odstranění nějaké + nevýhody?" + a2="Synchronní kód je jednodušší a srozumitelnější. Odhad poplatků má navíc + větší vhled do celého mempoolu. Na druhou stranu je nutné zapouzdřit + všechny informace pro odhad poplatků do struktury `NewMempoolTransactionInfo`. + Odhad poplatků však mnoho informací nepotřebuje." + a2link="https://bitcoincore.reviews/28368#l-43" + + q3="Jaké jsou podle vás výhody a nevýhody přístupu tohoto PR oproti [PR 11775][], + které rozděluje `CValidationInterface`?" + a3="I když rozdělení vypadá atraktivně, ve skutečnosti části stále sdílely backend + (aby byly události patřičně seřazené), nebyly tedy na sobě zcela nezávislé. + Nezdá se, že by z praktického hlediska přinášelo rozdělení významné výhody. + Toto PR je ve svém záběru užší a s menším dopadem." + a3link="https://bitcoincore.reviews/28368#l-71" + + q4="Proč je implementace rozhraní `CValidationInterface` ekvivalentní odebírání událostí?" + a4="Všechny třídy implementující `CValidationInterface` jsou klienty. + Třída může implementovat všechny nebo jen některé metody (callbacky) z `CValidationInterface`, + například připojení či odpojení bloku nebo [přidání][tx add] či [odebrání][tx remove] + transakce z mempoolu. Po registraci (voláním `RegisterSharedValidationInterface()`) + budou implementované metody vykonány pokaždé, když je callback zavolán pomocí + `CMainSignals`. Callbacky jsou zavolány, kdykoliv nastane odpovídající událost." + a4link="https://bitcoincore.reviews/28368#l-90" + + q5="[`BlockConnected`][BlockConnected] a [`NewPoWValidBlock`][NewPoWValidBlock] + jsou rozdílné callbacky. Který z nich je asynchronní a který synchronní? + Jak to lze poznat?" + a5="`BlockConnected` je asynchronní, `NewPoWValidBlock` je synchronní. + Asynchronní callback přidá do fronty „událost,“ která bude později + vykonána v rámci vlákna `CScheduler`." + a5link="https://bitcoincore.reviews/28368#l-105" + + q6="Proč přidáváme v [commitu 4986edb][commit 4986edb] nový callback + `MempoolTransactionsRemovedForConnectedBlock` namísto použití + `BlockConnected` (který navíc také indikuje, že byla transakce odstraněna + z mempoolu)?" + a6="Algoritmus odhadu poplatku musí vědět, kdy jsou transakce z jakéhokoliv důvodu + odstraněny z mempoolu, tedy nejen v případě připojení bloku. Odhad poplatku též + potřebuje znát bázový poplatek transakce a ten `BlockConnected` + (který zpřístupňuje `CBlock`) nenabízí. Mohli bych přidat bázový poplatek + do položek `block.vtx` (seznam transakcí), ale není žádoucí z tohoto důvodu + měnit tak důležitou a všudypřítomnou datovou strukturu." + a6link="https://bitcoincore.reviews/28368#l-130" + + q7="Proč nepoužíváme `std::vector` jako parametr callbacku + `MempoolTransactionsRemovedForBlock`? Mohlo by to odstranit požadavek + na novou strukturu, která by držela transakční informace potřebné pro + odhad poplatků." + a7="Odhad poplatků nepotřebuje všechna pole obsažená v `CTxMempoolEntry`." + a7link="https://bitcoincore.reviews/28368#l-159" + + q8="Jak je počítán bázový poplatek `CTransactionRef`?" + a8="Jedná se o součet vstupních hodnot minus součet výstupních hodnot. Callback + ale nemá přístup ke vstupním hodnotám, neboť jsou uloženy ve výstupech předchozí + transakce (k nimž callback přístup nemá). Proto je bázový poplatek obsažen ve + struktuře `TransactionInfo`." + a8link="https://bitcoincore.reviews/28368#l-166" +%} + +## 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 26.0rc2][] je kandidátem na vydání příští hlavní verze této + převládající implementace plného uzlu. K dispozici je stručný přehled + [navrhovaných témat k testování][26.0 testing] a na 15. listopadu 2023 + je naplánované sezení [Bitcoin Core PR Review Club][]. + +- [Core Lightning 23.11rc1][] je kandidátem na vydání příští hlavní verze + této implementace LN uzlu. + +- [LND 0.17.1-beta.rc1][] je kandidátem na vydání údržbové verze této 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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Core Lightning #6824][] upravuje implementaci [interaktivního protokolu + financování][topic dual funding], aby „ukládala stav během posílání + `commitment_signed`, a [přidává] do `channel_reestablish` pole + `next_funding_txid`, které si od spojení vyžádá přeposlání podpisů, + které ještě nemáme.” Změna je založena na [aktualizaci][36c04c8ac] + PR návrhu [oboustranného financování][bolts #851]. + +- [Core Lightning #6783][] zastarává v nastavení volbu `large-channels`. + [Velké kanály][topic large channels] a velké částky budou vždy aktivní. + +- [Core Lightning #6780][] zlepšuje podporu navýšení poplatků onchain transakcí + spojených s [anchor výstupy][topic anchor outputs]. + +- [Core Lightning #6773][] přidává do RPC volání `decode` ověření, že + obsahu záložního souboru je validní a obsahuje informace potřebné k provedení plné obnovy. + +- [Core Lightning #6734][] přidává do výsledku RPC volání `listfunds` informace + potřebné k [CPFP][topic cpfp] navýšení poplatku transakce vzájemného zavření kanálu. + +- [Eclair #2761][] umožňuje přeposlat omezený počet [HTLC][topic htlc], i když je + kanál pod požadavkem minimální rezervy. Může to napomoci vyřešit _problém s uvízlými + prostředky_, který se může objevit po [splicingu][topic splicing] či [oboustranném + financování][topic dual funding]. [Zpravodaj č. 253][news253 stuck] popisuje další + opatření Eclairu proti uvízlým prostředkům. + +{% include references.md %} +{% include linkers/issues.md v=2 issues="6824,6783,6780,6773,6734,2761,851" %} +[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]: /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://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 +[26.0 testing]: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/26.0-Testing-Guide-Topics +[review club 28368]: https://bitcoincore.reviews/28368 +[pr 11775]: https://github.com/bitcoin/bitcoin/pull/11775 +[tx add]: https://github.com/bitcoin/bitcoin/blob/eca2e430acf50f11da2220f56d13e20073a57c9b/src/validation.cpp#L1217 +[tx remove]: https://github.com/bitcoin/bitcoin/blob/eca2e430acf50f11da2220f56d13e20073a57c9b/src/txmempool.cpp#L504 +[BlockConnected]: https://github.com/bitcoin/bitcoin/blob/d53400e75e2a4573229dba7f1a0da88eb936811c/src/validationinterface.cpp#L227 +[NewPoWValidBlock]: https://github.com/bitcoin/bitcoin/blob/d53400e75e2a4573229dba7f1a0da88eb936811c/src/validationinterface.cpp#L260 +[commit 4986edb]: https://github.com/bitcoin-core-review-club/bitcoin/commit/4986edb99f8aa73f72e87f3bdc09387c3e516197 diff --git a/_posts/cs/newsletters/2023-11-15-newsletter.md b/_posts/cs/newsletters/2023-11-15-newsletter.md new file mode 100644 index 0000000000..eaee3e05b8 --- /dev/null +++ b/_posts/cs/newsletters/2023-11-15-newsletter.md @@ -0,0 +1,107 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 277' +permalink: /cs/newsletters/2023/11/15/ +name: 2023-11-15-newsletter-cs +slug: 2023-11-15-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme popis aktualizace návrhu dočasných anchorů a +začleňujeme externí terénní zprávu o miniscriptu od vývojáře pracujícího +ve Wizardsardine. Též nechybí naše pravidelné rubriky s oznámeními o nových +vydáních a souhrnem významných změn v populárních bitcoinových páteřních +projektech. + +## Novinky + +- **Odstranění poddajnosti dočasných anchorů:** Gregory Sanders zaslal do fóra + Delving Bitcoin [příspěvek][sanders mal] s úpravou navrhovaných [dočasných + anchorů][topic ephemeral anchors] („ephemeral anchors”). Návrh by umožnil, + aby transakce obsahovaly výstup s nulovou hodnotou a anyone-can-spend výstupním + skriptem. Protože by tento výstup mohl utratit kdokoliv, kdokoliv by také + mohl transakci, která výstup vytvořila, navýšit poplatek pomocí [CPFP][topic cpfp]. + To je výhodné pro protokoly s kontrakty s více účastníky jako LN, kde se + transakce často podepisují před tím, než je možné přesně určit, jaký jednotkový + poplatek by měly platit. Dočasné anchory umožňují, aby kterákoliv strana kontraktu + přidala takový poplatek, jaký považuje za nezbytný. Pokud by kterákoliv + strana (nebo z jakéhokoliv důvodu i kterýkoliv jiný uživatel) chtěla přidat + vyšší poplatek, mohou navýšení pomocí CPFP [nahradit][topic rbf] svým vlastním + CPFP navýšením. + + Jako anyone-can-spend skript je navrhován výstupní skript obsahující ekvivalent + `OP_TRUE`, který lze utratit vstupem s prázdným vstupním skriptem. Jak Sanders + tento týden poznamenal, zastaralý druh výstupního skriptu znamená, že potomek, + který jej utrácí, bude mít poddajné txid, tedy kterýkoliv těžař může do vstupního + skriptu přidat data, aby tím změnil txid potomka. Kvůli tomu by nebylo moudré + použít potomka k jinému účelu, než je navýšení poplatku, neboť v opačném případě + by mohl být potvrzen s jiným txid, což by tranzitivně zneplatnilo jakéhokoliv potomka + tohoto potomka. + + Sanders proto navrhuje použití jednoho z výstupních skriptů, které byly rezervovány + pro budoucí upgrady segwitu. Sice by to vyžadovalo o trochu více blokového + prostoru (čtyři byty u segwitu oproti jednomu bytu v případě holého `OP_TRUE`), + ale na druhou stranu by to odstranilo rizika poddajnosti transakce. Později Sanders + navrhl možnost používat obě varianty: `OP_TRUE`, pokud uživatele poddajnost nezajímá, + ale chce co nejmenší velikost transakce, a segwitovou verzi, která je větší, avšak + nedovoluje pozměnit potomka. Diskuze ve vlákně se dále soustředila na výběr bytů + v segwitové variantě tak, aby vznikaly zapamatovatelné [bech32m addresy][topic bech32]. + +## Terénní zpráva: Cesta k miniscriptu + +{% include articles/cs/wizardsardine-miniscript.md extrah="#" %} {% assign timestamp="20:17" %} + +## 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 0.17.1-beta][] je údržbovým vydáním této implementace LN uzlu, které obsahuje opravy + několika chyb a drobná vylepšení. + +- [Bitcoin Core 26.0rc2][] je kandidátem na vydání příští hlavní verze této + převládající implementace plného uzlu. K dispozici je [průvodce testování][26.0 + testing] a na 15. listopadu 2023 je naplánované sezení [Bitcoin Core PR Review Club][] + věnované testování. + +- [Core Lightning 23.11rc1][] je kandidátem na vydání příští hlavní verze + této 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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Bitcoin Core #28207][] upravuje způsob, kterým je mempool uložen na disku + (což se děje během vypínání uzlu, ale lze též vynutit RPC voláním `savemempool`). + Dříve byl uložen jako prostá serializovaná data v paměti. Nově je tato + serializovaná struktura XORována hodnotou náhodně vygenerovanou každým uzlem, + aby tím byla data zatemněna. Během zapínání uzlu jsou zatemněná data XORována + stejnou hodnotou. Zatemnění zabraňuje vložení určitých dat do transakce, která + by se potom objevila mezi uloženými daty mempoolu a která by mohly antivirové + a podobné programy označit za nebezpečná. Stejná metoda byla již dříve použita + na ukládání množiny UTXO v [PR #6650][bitcoin core #6650]. Software, který + potřebuje data mempoolu z disku načíst, by měl být sám schopen provést XOR nebo + použít konfigurační volbu `-persistmempoolv1`, která bude ukládat data v + nezatemněném formátu. Tato volba bude v budoucím vydání odstraněna. + +- [LDK #2715][] umožňuje uzlu volitelně přijmout menší hodnotu [HTLC][topic htlc], + než která má být doručena. To je užitečné, pokud spojení proti směru toku platí + uzlu přes nový [JIT kanál][topic jit channels], za jehož onchain náklady musí + platit a odečíst tyto náklady z hodnoty HTLC. Viz [zpravodaj č. 257][news257 jitfee] + pro detaily o implementaci druhé části této vlastnosti. + +{% include snippets/recap-ad.md when="2023-11-16 15:00" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="28207,6650,2715" %} +[bitcoin core 26.0rc2]: 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.11rc1]: https://github.com/ElementsProject/lightning/releases/tag/v23.11rc1 +[lnd 0.17.1-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.17.1-beta +[sanders mal]: https://delvingbitcoin.org/t/segwit-ephemeral-anchors/160 +[news257 jitfee]: /cs/newsletters/2023/06/28/#ldk-2319 diff --git a/_posts/cs/newsletters/2023-11-22-newsletter.md b/_posts/cs/newsletters/2023-11-22-newsletter.md new file mode 100644 index 0000000000..0bc3c76092 --- /dev/null +++ b/_posts/cs/newsletters/2023-11-22-newsletter.md @@ -0,0 +1,177 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 278' +permalink: /cs/newsletters/2023/11/22/ +name: 2023-11-22-newsletter-cs +slug: 2023-11-22-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme popis návrhu na přijímání LN nabídek pomocí +určité DNS adresy podobné lightningovým adresám. Též nechybí naše pravidelné +rubriky se souhrnem změn ve službách a klientech, oznámeními o nových +vydáních a popisem významných změn v populárním bitcoinovém páteřním +software. + +## Novinky + +- **LN adresy kompatibilní s nabídkami:** Bastien Teinturier zaslal do + emailové skupiny Lightning-Dev [příspěvek][teinturier addy] o vytváření + adres (ve stylu emailových adres) pro uživatele LN. Návrh využívá + možnosti nabízené protokolem [nabídek][topic offers]. Existující + populární standard [lightningových adres][lightning address] je založený na [LNURL][], + který vyžaduje provoz vždy dostupného HTTP serveru překládajícího + 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. + + - _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. + + 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). + + 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 + přímo v DNS). + +## 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.* + +- **Vydána BitMask Wallet 0.6.3:** + [BitMask][bitmask website] je peněženka pro web a rozšíření prohlížeče, podporuje + bitcoin, Lightning Network, RGB a [payjoin][topic payjoin]. + +- **Oznámena stránka s dokumentací opkódů:** + Nedávno byla ohlášena webová stránka [https://opcodeexplained.com/], která obsahuje + vysvětlení mnoha bitcoinových opkódů. Na stránce se dále pracuje, [příspěvky jsou + vítány][OE github]. + +- **Athena Bitcoin přidává podporu lightningu:** + [Provozovatel][athena website] bitcoinových bankomatů nedávno [oznámil][athena tweet] + podporu pro výběry přes lightningové platby. + +- **Vydán Blixt v0.6.9:** + Vydání [v0.6.9][blixt v0.6.9] obsahuje podporu pro jednoduché taprootové kanály, + používá [bech32m][topic bech32] adresy ve výchozím nastavení a zlepšuje podporu + [zero conf kanálů][topic zero-conf channels]. + +- **Ohlášen článek o Durabitu:** + [Článek o Durabitu][Durabit whitepaper] nastiňuje protokol používající bitcoinové + transakce s [časovými zámky][topic timelocks] ve spojení s chaumovskou ražbou mincí, + který by poskytoval ekonomické podněty pro hostování a sdílení velkých souborů. + +- **Ohlášen článek o BitStreamu:** + [Článek o BitStreamu][BitStream whitepaper] a jeho [raný protyp][bitstream github] představují protokol + pro hostování a atomickou výměnu digitálního obsahu za mince pomocí časových zámků + a Merkleových stromů s verifikací a doklady o podvodech. Pro předchozí diskuzi + o protokolech placeného přenosu dat viz [zpravodaj č. 53][news53 data] (_angl._). + +- **Ověření konceptu BitVM:** + Byla vydána dvě ověření konceptu stavějící na [BitVM][news273 bitvm]. Jedno + [implementuje][bitvm tweet blake3] hashovací funkci [BLAKE3][], [druhé][bitvm + techmix poc] potom [implementuje][bitvm sha256] SHA256. + +- **Bitkit přidává podporu pro odesílání taprootu:** + Mobilní bitcoinová a lightningová peněženka [Bitkit][bitkit website] přidává ve + svém vydání [v1.0.0-beta.86][bitkit v1.0.0-beta.86] podporu pro odesílání + s [taprootem][topic taproot]. + +## 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.2-beta][] je údržbové vydání, které pouze obsahuje drobnou opravu chyby + nahlášené v [LND #8186][]. + +- [Bitcoin Core 26.0rc2][] je kandidátem na vydání příští hlavní verze této + převládající implementace plného uzlu. K dispozici je [průvodce testováním][26.0 + testing]. + +- [Core Lightning 23.11rc3][] je kandidátem na vydání příští hlavní verze této + 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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Core Lightning #6857][] upravuje názvy několika konfiguračních voleb + používaných pro REST rozhraní, aby nekolidovaly s těmi používanými + pluginem [c-lightning-rest][]. + +- [Eclair #2752][] umožňuje, aby údaje v [nabídce][topic offers] odkazovaly + na uzel buď pomocí jeho veřejného klíče nebo identity některého z jeho + kanálů. Typicky se pro identifikaci uzlu používá veřejný klíč, ale ten + používá 33 bytů. Kanál je možné identifikovat pomocí krátkého identifikátoru + dle [BOLT7][] („short channel identifier”, SCID), který používá pouze osm bytů. + Jelikož jsou kanály sdíleny dvěma uzly, je před SCID přidán ještě dodatečný bit + určující jeden z těchto dvou uzlů. Jelikož nabídky jsou často používány + v prostředích s omezenou velikostí, ušetřené místo může být významné. + +{% include snippets/recap-ad.md when="2023-11-22 15:00" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="6857,2752,8186" %} +[bitcoin core 26.0rc2]: 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.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://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 +[bitmask website]: https://bitmask.app/ +[https://opcodeexplained.com/]: https://opcodeexplained.com/opcodes/ +[OE tweet]: https://twitter.com/thunderB__/status/1722301073585475712 +[OE github]: https://github.com/thunderbiscuit/opcode-explained +[athena website]: https://athenabitcoin.com/ +[athena tweet]: https://twitter.com/btc_penguin/status/1722008223777964375 +[blixt v0.6.9]: https://github.com/hsjoberg/blixt-wallet/releases/tag/v0.6.9 +[Durabit whitepaper]: https://github.com/4de67a207019fd4d855ef0a188b4519c/Durabit/blob/main/Durabit%20-%20A%20Bitcoin-native%20Incentive%20Mechanism%20for%20Data%20Distribution.pdf +[BitStream whitepaper]: https://robinlinus.com/bitstream.pdf +[bitstream github]: https://github.com/robinlinus/bitstream +[news273 bitvm]: /cs/newsletters/2023/10/18/#platby-podminene-libovolnym-vypoctem +[bitvm tweet blake3]: https://twitter.com/robin_linus/status/1721969594686926935 +[BLAKE3]: https://cs.wikipedia.org/wiki/BLAKE#BLAKE3 +[bitvm techmix poc]: https://techmix.github.io/tapleaf-circuits/ +[bitvm sha256]: https://raw.githubusercontent.com/TechMiX/tapleaf-circuits/abc38e880872150ceec08a8b67ac2fddaddd06dc/scripts/circuits/bristol_sha256.js +[bitkit website]: https://bitkit.to/ +[bitkit v1.0.0-beta.86]: https://github.com/synonymdev/bitkit/releases/tag/v1.0.0-beta.86 +[news53 data]: /en/newsletters/2019/07/03/#standardized-atomic-data-delivery-following-ln-payments diff --git a/_posts/cs/newsletters/2023-11-29-newsletter.md b/_posts/cs/newsletters/2023-11-29-newsletter.md new file mode 100644 index 0000000000..d082e0c412 --- /dev/null +++ b/_posts/cs/newsletters/2023-11-29-newsletter.md @@ -0,0 +1,134 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č.279' +permalink: /cs/newsletters/2023/11/29/ +name: 2023-11-29-newsletter-cs +slug: 2023-11-29-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme souhrn aktualizace specifikace inzerátů likvidity. +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 popisem +významných změn v populárních bitcoinových páteřních projektech. + +## Novinky + +- **Aktualizace specifikace inzerátů likvidity:** Lisa Neigut + zaslala do emailové skupiny Lightning-Dev [příspěvek][neigut liqad] + oznamující aktualizaci specifikace [inzerátů likvidity][topic + liquidity advertisements] („liquidity advertisements”). Tato funkce, + implementovaná v Core Lightning a právě vyvíjená i pro Eclair, + umožňuje uzlu oznámit, že je ochoten přispět prostředky na + [kanál s oboustranným vkladem][topic dual funding]. Pokud jiný + uzel nabídku přijme požadavkem na otevření kanálu, žádající + uzel musí předem zaplatit nabízejícímu uzlu poplatek. To umožňuje + uzlu, který potřebuje příchozí likviditu (např. obchodník), nalézt + dobře propojená spojení, která mohou tuto likviditu za trží cenu + poskytnout. Použit je k tomu pouze open source software a decentralizovaný + gossip protokol. + + Aktualizace obsahuje několik změn struktur a zvýšenou flexibilitu + doby trvání kontraktu a stropu příchozích poplatků. Příspěvek + obdržel v emailové skupině několik odpovědí a očekávány jsou + další změny [specifikace][bolts #878]. Neigut v příspěvku dále + poznamenala, že současná konstrukce inzerátů likvidity a oznamování + kanálů teoreticky umožňuje kryptograficky prokázat případ, ve kterém + jedna ze stran kontrakt poruší. Návrh na kompaktní doklad o podvodu, + který by mohl být použit v kontraktech s finančním závazkem k odrazení + porušování kontraktu, je otevřeným problémem. + +## 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/" %} + +- [Jsou Schnorrovy digitální podpisy schématem pro interaktivní podepisování s více účastníky a zároveň i neagregované neinteraktivní schéma?]({{bse}}120402) + Pieter Wuille popisuje rozdíly mezi podpisy s více účastníky, agregací podpisů a + bitcoinovým multisigem a poukazuje na několik souvisejících schémat včetně + [Schnorrových podpisů][topic schnorr signatures] dle [BIP340][], [MuSig2][topic musig], + FROST a Bellare-Neven 2006. + +- [Je vhodné provozovat kandidáta na vydání jako plný uzel na mainnetu?]({{bse}}120375) + Vojtěch Strnad a Murch poznamenávají, že provozovat kandidáta na vydání Bitcoin Core + na mainnetu neohrožuje bitcoinovou _síť_, ale uživatelé API, peněženky a další + funkcionality by měli být opatrní a důkladně svou konfiguraci otestovat. + +- [Jaký je vztah mezi nLockTime a nSequence?]({{bse}}120256) + Antoine Poinsot a Pieter Wuille odpovídají na sérii otázek o `nLockTime` a `nSequence`, + včetně [vztahu mezi těmito dvěma]({{bse}}120273), [původním smyslu `nLockTime`]({{bse}}120276), + [možných hodnotách `nSequence`]({{bse}}120254) a vztahu k [BIP68]({{bse}}120320) a + [`OP_CHECKLOCKTIMEVERIFY`]({{bse}}120259). + +- [Co by se stalo, kdybychom poskytli opkódu OP_CHECKMULTISIG více podpisů, než je práh (m)?]({{bse}}120604) + Pieter Wuille vysvětluje, že zatímco toto bylo dříve možné, po soft forku [BIP147][] + již není nadále umožněno, aby dodatečný prvek v zásobníku u OP_CHECKMULTISIG a OP_CHECKMULTISIGVERIFY + byla libovolná hodnota. + +- [Co jsou „pravidla (mempoolu)”?]({{bse}}120269) + Antoine Poinsot definuje termíny _pravidla_ („policy”) a _standardnost_ („standardness”) + v kontextu Bitcoin Core a poskytuje několik příkladů. Též odkazuje na naši sérii o pravidlech + [Čekání na potvrzení][policy series]. + +- [Co znamená Pay to Contract (P2C)?]({{bse}}120362) + Vojtěch Strnad popisuje [Pay-to-Contract (P2C)][topic p2c] a odkazuje na + [původní návrh][p2c paper]. + +- [Může být nesegwitová transakce serializovaná do segwitového formátu?]({{bse}}120317) + Pieter Wuille vysvětluje, že zatímco několik starších verzí Bitcoin Core + neúmyslně umožňovalo rozšířenou serializaci pro nesegwitové transakce, + [BIP144][] specifikuje, že nesegwitové transakce musí použít starý + formát serializace. + +## 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.* + +- [Core Lightning 23.11][] je vydáním další hlavní verze této implementace + LN uzlu. Nabízí více flexibility autentizačního mechanismu _run_, vylepšenou + verifikaci záloh a nové možnosti pluginů. + +- [Bitcoin Core 26.0rc3][] je kandidátem na vydání příští hlavní verze + této převládající implementace plného uzlu. K dispozici je [průvodce + testováním][26.0 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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Rust Bitcoin #2213][] upravuje výpočet předpokládané váhy P2WPKH vstupů + během odhadu poplatků. Jelikož jsou transakce s high-s podpisy považovány + za nestandardní již od Bitcoin Core verzí [0.10.3][bcc 0.10.3] a [0.11.1][bcc + 0.11.1], mohou procesy tvorby transakcí bezpečně předpokládat, že serializované + ECDSA podpisy budou zabírat nejvíce 72 bytů namísto předchozí hodnoty + 73 bytů. + +- [BDK #1190][] přidává novou metodu `Wallet::list_output`, která vrací + všechny výstupy v peněžence, utracené i neutracené. Dříve bylo snadné + získat seznam neutracených výstupů, avšak obdržet seznam utracených + výstupů bylo těžké. + +{% assign day_after_posting = page.date | date: "%s" | plus: 86400 | date: "%Y-%m-%d 15:00" %} +{% include snippets/recap-ad.md when=day_after_posting %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="2213,1190,878" %} +[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://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 +[bcc 0.10.3]: https://bitcoin.org/en/release/v0.10.3#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 new file mode 100644 index 0000000000..710d776eff --- /dev/null +++ b/_posts/cs/newsletters/2023-12-06-newsletter.md @@ -0,0 +1,253 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 280' +permalink: /cs/newsletters/2023/12/06/ +name: 2023-12-06-newsletter-cs +slug: 2023-12-06-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden popisujeme několik diskuzí o navrhovaném cluster mempoolu +a shrnujeme výsledky testu provedeného pomocí warnetu. Též nechybí naše +pravidelné rubriky se souhrnem sezení Bitcoin Core PR Review Clubu, +oznámeními o nových vydáních a popisem významných změn v populárním +bitcoinovém páteřním software. + +## Novinky + +- **Diskuze o cluster mempoolu:** vývojáři Bitcoin Core pracující na + [cluster mempoolu][topic cluster mempool] ustanovili v rámci fóra + Delving Bitcoin svou [pracovní skupinu][wg-cluster-mempool]. Cluster + mempool je návrh na usnadnění práce s mempoolem za zachování požadovaného + řazení transakcí. Validní řazení bitcoinových transakcí požaduje, aby + byli předkové potvrzeni dříve než potomci. Toho lze dosáhnout začleněním + předka v dřívějším bloku nebo na dřívější pozici v rámci stejného bloku. + Dle návrhu cluster mempoolu jsou _clustery_ jedné nebo více souvisejících + transakcí rozděleny do _chunků_ seřazených dle jednotkového poplatku. + Kterýkoliv chunk může být začleněn do bloku (až do maximální váhy bloku), + pokud jsou všechny předchozí nepotvrzené chunky (s vyššími jednotkovými + poplatky) zařazeny dříve do stejného bloku. + + Jakmile jsou všechny transakce seřazeny do clusterů a clustery rozděleny + do chunků, je jednoduché vybrat transakce pro začlenění do bloku: + stačí zvolit chunk s nejvyšším jednotkovým poplatkem, potom s druhým + nejvyšším a tak dále až do zaplnění bloku. Je-li použit tento algoritmus, + je zřejmé, že chunk s nejnižším jednotkovým poplatkem je také chunk, který + má do začlenění do bloku nejdále. Můžeme tedy použít převrácený algoritmus + na vypořádání se s plným mempoolem, kdy je potřeba vyhodit některé transakce: + vyhoďme chunk s nejnižším jednotkovým poplatkem, potom druhým nejnižším a + tak dále, dokud není náš mempool opět pod svou zamýšlenou nejvyšší velikostí. + + 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. + +- **Testování s warnetem:** Matthew Zipkin zaslal do Delving Bitcoin + [příspěvek][zipkin warnet] s výsledky simulací, které provádí pomocí + [warnetu][warnet], programu spouštějícímu velké množství bitcoinových + uzlů s definovanými vzájemnými spojeními (obvykle v testovací síti). + Zipkinovy výsledky ukazují, jaká paměť navíc by byla potřeba, pokud + by bylo přijato několik navrhovaných změn kódu správy spojení (ať již + nezávisle nebo spolu). Dále poznamenává, že by rád prováděl testovací + simulace i dalších navrhovaných změn a měřil dopad navrhovaných útoků. + +## 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í.* + +Sezení review klubu [Testování kandidátů na vydání Bitcoin Core 26.0][review club v26-rc-testing] +se nezabývalo konkrétním PR, ale společným testováním. + +Důsledné testování členy komunity před každým [hlavním vydáním Bitcoin Core][major Bitcoin Core release] +je nezbytné. Z tohoto důvodu sepíše dobrovolník průvodce testování [kandidáta na +vydání][release candidate], aby mohlo co nejvíce lidí efektivně testovat, +aniž by museli sami zjišťovat, co je nového, co se změnilo a jaké kroky je potřeba +podniknout k jejich otestování. + +Testování může být náročné, protože nemusí být v případě neočekávaného chování +jasné, zda se jedná o chybu programu či omyl v testování. Reportování chyb, +které nejsou skutečnými chybami, plýtvá časem vývojářů. Sezení review klubu +se zabývá konkrétním kandidátem na vydání (v tomto případě 26.0rc2), aby se předešlo +podobným problémům. + +[Průvodce testováním kandidáta na vydání 26.0][26.0 testing] napsal Max Edwards, +který se též zhostil vedení sezení review klubu. Pomáhal mu Stéphan (stickies-v). + +Účastníci byli dále vyzýváni, aby se čtením [poznámek k vydání 26.0][26.0 release notes] sami inspirovali +k nápadům na testování. + +Toto sezení klubu se zabývalo dvěma RPC voláními: [`getprioritisedtransactions`][PR +getprioritisedtransactions] (bylo též předmětem [jednoho z předchozích sezení][news250 pr review], +ačkoliv tehdy ještě pod jiným názvem) a [`importmempool`][PR importmempool]. +Tato i další nová volání jsou popsána v sekci poznámek k vydání [New RPCs][]. +Sezení se dále zabývalo [přenosem verze 2 (BIP324)][topic v2 p2p transport] +a zamýšlelo též pokrýt [TapMiniscript][PR TapMiniscript], ale z časových důvodů +se na toto téma nedostalo. + +{% include functions/details-list.md + q0="Které operační systémy lidé používají?" + a0="Ubuntu 22.04 na WSL (Windows Subsystem for Linux); macOS 13.4 (M1 chip)." + a0link="https://bitcoincore.reviews/v26-rc-testing#l-18" + + q1="Jaké byly výsledky vašeho testování `getprioritisedtransactions`?" + a1="Účastníci hlásili, že fungovalo dle očekávání, avšak jeden z nich si + povšiml, že se důsledek [`prioritisetransaction`][prioritisetransaction] + sčítal: pokud bylo voláno dvakrát pro stejnou transakci, poplatek se + zdvojil. + Toto chování je dle očekávání. Poplatek v argumentu je _přičten_ ke + stávající prioritě transakce." + a1link="https://bitcoincore.reviews/v26-rc-testing#l-32" + + q2="Jakých výsledků testování `importmempool` jste dosáhli?" + a2="Jeden z účastníku obdržel chybu \"Importovat mempool lze až po stažení + bloků a synchronizaci\", avšak po dvou minutách čekání bylo volání + úspěšné. Jiný účastník poznamenal, že to trvá dlouho." + a2link="https://bitcoincore.reviews/v26-rc-testing#l-45" + + q3="Co se stane, pokud během importu přerušíme CLI proces a potom jej bez + zastavení `bitcoind` restartujeme?" + a3="Toto nezpůsobilo žádné potíže, druhý požadavek o import se dokončil + podle očekávání. Zdá se, že proces importování pokračoval i po přerušení + CLI příkazu a druhý požadavek nezpůsobil, aby dvě vlákna importu běžela + najednou a kolidovala se sebou." + a3link="https://bitcoincore.reviews/v26-rc-testing#l-91" + + q4="Jaký byl výsledek provozování přenosu verze 2?" + a4="Účastníci nebyli schopni připojit se ke známému uzlu s V2 na mainnetu. + Zdálo se, že nepřijímal žádná spojení. Je možné, že všechny příchozí + sloty uzlu již byly obsazené. Z tohoto důvodu nedošlo během sezení + k testování P2P." + a4link="https://bitcoincore.reviews/v26-rc-testing#l-115" +%} + +## 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 26.0][] je další hlavní vydání této převládající implementace + plného uzlu. Vydání obsahuje experimentální podporu pro [protokol přenosu + verze 2][topic v2 p2p transport], [taproot][topic taproot] v [miniscriptu][topic + miniscript], nová RPC volání pro práci s [assumeUTXO][topic assumeutxo], + experimentální RPC volání pro zpracování [balíčků][topic package relay] + transakcí (podpora pro přeposílání ještě začleněna není) a množství dalších + vylepšení a oprav chyb. + +- [LND 0.17.3-beta.rc1][] je kandidátem na vydání obsahující opravy několika 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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Bitcoin Core #28848][] upravuje chybová hlášení RPC volání `submitpackage`. + Namísto vrácení `JSONRPCError` s první chybou nově vrací výsledek za každou transakci. + +- [LDK #2540][] staví na posledním vývoji [zaslepených cest][topic rv routing] v LDK + (viz zpravodaje [č. 257][news257 ldk2120] a [č. 266][news266 ldk2411]) a přidává + podporu pro přeposílání jako první uzel v zaslepené cestě. Změna je součástí + [vývoje][LDK #1970] podpory [nabídek][topic offers] dle BOLT12. + +{% assign day_after_posting = page.date | date: "%s" | plus: 86400 | date: "%Y-%m-%d 15:00" %} +{% include snippets/recap-ad.md when=day_after_posting %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="28848,2540,1970" %} +[bitcoin core 26.0]: 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 +[wg-cluster-mempool]: https://delvingbitcoin.org/c/implementation/wg-cluster-mempool/9 +[clusterdef]: https://delvingbitcoin.org/t/clustermempool-definitions-theory/202 +[cluster merge]: https://delvingbitcoin.org/t/merging-incomparable-linearizations/209/38 +[cluster rbf]: https://delvingbitcoin.org/t/post-clustermempool-package-rbf-per-chunk-processing/190 +[cluster rbf-old1]: https://delvingbitcoin.org/t/defunct-post-clustermempool-package-rbf/173 +[cluster rbf-old2]: https://delvingbitcoin.org/t/defunct-cluster-mempool-package-rbf-sketch/171 +[cluster rbf-old3]: https://delvingbitcoin.org/t/cluster-mempool-rbf-thoughts/156 +[zipkin warnet]: https://delvingbitcoin.org/t/warnet-simulations/232 +[warnet]: https://github.com/bitcoin-dev-project/warnet +[wuille incomplete]: https://github.com/bitcoinops/bitcoinops.github.io/pull/1421#discussion_r1414487021 +[mempool replacements]: https://github.com/bitcoin/bitcoin/blob/fa9cba7afb73c01bd2c8fefd662dfc80dd98c5e8/doc/policy/mempool-replacements.md +[LND 0.17.3-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.17.3-beta.rc1 +[review club v26-rc-testing]: https://bitcoincore.reviews/v26-rc-testing +[major bitcoin core release]: https://bitcoincore.org/en/lifecycle/#major-releases +[26.0 release notes]: https://github.com/bitcoin/bitcoin/blob/44d8b13c81e5276eb610c99f227a4d090cc532f6/doc/release-notes.md +[new rpcs]: https://github.com/bitcoin/bitcoin/blob/44d8b13c81e5276eb610c99f227a4d090cc532f6/doc/release-notes.md#new-rpcs +[news250 pr review]: /cs/newsletters/2023/05/10/#bitcoin-core-pr-review-club +[release candidate]: https://bitcoincore.org/en/lifecycle/#versioning +[pr getprioritisedtransactions]: https://github.com/bitcoin/bitcoin/pull/27501 +[pr importmempool]: https://github.com/bitcoin/bitcoin/pull/27460 +[pr tapminiscript]: https://github.com/bitcoin/bitcoin/pull/27255 +[prioritisetransaction]: https://developer.bitcoin.org/reference/rpc/prioritisetransaction.html +[news257 ldk2120]: /cs/newsletters/2023/06/28/#ldk-2120 +[news266 ldk2411]: /cs/newsletters/2023/08/30/#ldk-2411 diff --git a/_posts/cs/newsletters/2023-12-13-newsletter.md b/_posts/cs/newsletters/2023-12-13-newsletter.md new file mode 100644 index 0000000000..13f02e46a8 --- /dev/null +++ b/_posts/cs/newsletters/2023-12-13-newsletter.md @@ -0,0 +1,197 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 281' +permalink: /cs/newsletters/2023/12/13/ +name: 2023-12-13-newsletter-cs +slug: 2023-12-13-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme souhrn diskuze o záškodnických inzerátech likvidity +a připojujeme naše pravidelné rubriky s popisem změn ve službách a klientském +software, souhrnem oblíbených otázek a odpovědí z Bitcoin Stack Exchange, +oznámeními o nových softwarových vydáních a přehledem nedávných změn +v populárním bitcoinovém páteřním software. + +## Novinky + +- **Diskuze o záškodnických inzerátech likvidity:** Bastien Teinturier + zaslal do emailové skupiny Lightning-Dev [příspěvek][teinturier liqad] + s popisem možného problému s časovými zámky [kanálů s oboustranným + vkladem][topic dual funding] („dual-funded channels”) vytvořených z [inzerátů + likvidity][topic liquidity advertisements] („liquidity ads”). Problém byl již + dříve zmíněn v [rekapitulaci č. 279][recap279 liqad]. Příklad: Alice inzeruje, + že je za poplatek ochotna poskytnout svých 10 000 satoshi nějakému kanálu na + 28 dní. Tento 28denní časový zámek zaručuje, že Alice nebude moci po obdržení + platby jen tak zavřít kanál a použít své prostředky k jiným účelům. + + Dále v tomto příkladu Bob otevře kanál s dodatečným přispěním svých prostředků + ve výši 100 000 000 satoshi (1 BTC). Tímto kanálem potom pošle téměř všechny své + prostředky. Na Alicině straně však nyní není 10 000 satoshi, za které obdržela + poplatek, ale téměř 10 000× více. Má-li Bob zlé úmysly, nedovolí Alici až do + vypršení 28denního časového zámku její prostředky použít. + + Opatření navržené Teinturierem a diskutované spolu s ostatními spočívá v + aplikaci časového zámku pouze na příspěvek pocházející z likvidity (čili + v našem případě 10 000 satoshi). To navyšuje složitost a neefektivitu, + ale může to problém vyřešit. Jiným Teinturierovým návrhem bylo jednoduše + časový zámek zavrhnout (nebo ho učinit volitelným) a nechat na příjemci + likvidity riziko, že poskytovatel může krátce po obdržení poplatku + za likviditu kanál zavřít. Pokud by v typickém případě kanály otevřené pomocí + inzerátů likvidity generovaly významný příjem na poplatcích, bylo by v zájmu + provozovatelů je nechat otevřené. + +## 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.* + +- **Spuštěn těžební pool se Stratum v2:** + [DEMAND][demand website] je těžební pool postavený na [referenční implementaci + protokolu Stratum v2][news247 sri]. Zpočátku povoluje sólo těžbu, těžba v poolu je plánována + do budoucna. + +- **Oznámen simulační nástroj bitcoinové sítě warnet:** + Software [warnet][warnet github] umožňuje specifikovat topologie uzlů, spouštět + nad sítí [naskriptované scénáře][warnet scenarios], [monitorovat][warnet monitoring] + a analyzovat chování. + +- **Vydán klient Payjoinu pro Bitcoin Core:** + Rustový projekt [payjoin-cli][] přidává pomocí konzolového nástroje [payjoin][topic payjoin] + do Bitcoin Core možnost odesílání a přijímání payjoinu. + +- **Žádost o poskytnutí času přijetí bloků:** + Přispěvatel do repozitáře projektu [Bitcoin Block Arrival Time Dataset][block arrival github] + [vyzývá][b10c tweet] provozovatele uzlů o poskytnutí časových razítek přijetí + bloků svými uzly. Pro sběr dat o starých blocích („stale blocks”) existuje + podobný [repozitář][stale block github]. + +- **Envoy 1.4 released:** + [Vydádní 1.4][envoy v1.4.0] bitcoinové peněženky Envoy přidává mimo jiné + [výběr mincí][topic coin selection] a [štítkování peněženky][topic wallet labels] + (podpora pro [BIP329][] přijde brzy). + +- **Ohlášeno kódovací schéma BBQr:** + [Schéma][bbqr github] umí efektivně kódovat větší soubory, například [PSBT][topic + psbt], do animované série QR kódů pro používání peněženkami nemajícími připojení k + počítači. + +- **Vydán Zeus v0.8.0:** + Vydání [v0.8.0][zeus v0.8.0] obsahuje mimo jiné vestavěný LND uzel, dodatečnou podporu pro + [zero conf kanály][topic zero-conf channels] a podporu pro jednoduché taprootové kanály. + +## 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/" %} + +- [Jaká existují pravidla ohledně navyšování poplatků pomocí CPFP?]({{bse}}120853) + Pieter Wuille poznamenává, že na rozdíl od navyšování poplatků pomocí [RBF][topic rbf], + které má řadu pravidel, nemá [CPFP][topic cpfp] technika žádná dodatečná + pravidla. + +- [Jak se počítá, kolik transakcí se má nahradit pomocí RBF?]({{bse}}120823) + Murch a Pieter Wuille procházejí několika příklady RBF nahrazení v kontextu + pravidla číslo 5 z [BIP125][]: „Počet původních transakcí, které budou nahrazeny, + a jejich potomků, kteří budou vyhozeni z mempoolu, nesmí dohromady překročit sto + transakcí.” Čtenáře může dále zajímat sezení PR Review Clubu [Přidej test BIP-125 pravidla + číslo 5 s výchozím mempoolem][review club 25228]. + +- [Jaké existují typy RBF a které z nich Bitcoin Core podporuje a používá?]({{bse}}120749) + Murch vysvětluje historii nahrazování transakcí v Bitcoin Core a v [související + otázce]({{bse}}120773) poskytuje souhrn pravidel nahrazení dle RBF. Dále odkazuje na + dokumentaci Bitcoin Core [Mempool Replacements][bitcoin core mempool + replacements] a na nápad na [zlepšení RBF][glozow rbf improvements]. + +- [V čem spočívá problém bloku 1 983 702?]({{bse}}120834) + Antoine Poinsot poskytuje přehled problémů, které vedly k [BIP30][] omezujícímu + duplikovaná txid a [BIP34][] požadujícímu začlenění čísla bloku v coinbase. + Dále poznamenává, že existuje řada bloků, jejichž coinbase obsahuje náhodná data, která + vypadají jako výška pozdějšího bloku. Blok 1 983 702 byl prvním, který v praxi mohl + opakovat coinbase transakci nějakého předchozího bloku. V [související otázce]({{bse}}120836) + se touto možností Murch a Antoine Poinsot zabývají hlouběji. Viz též + [zpravodaj č. 182][news182 block1983702] (_angl._). + +- [K čemu se v bitcoinu používají hashovací funkce?]({{bse}}120418) + Pieter Wuille vypisuje přes třicet různých případů v pravidlech konsenzu, + peer to peer protokolu, peněžence a implementaci uzlu, které dohromady používají + nejméně deset různých hashovacích funkcí. + +## 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 0.17.3-beta][] je vydání obsahující opravy několika chyb včetně redukce + použité paměti během používání Bitcoin Core backendu. + +## 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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [LDK #2685][] přidává možnost získávání blockchainových dat ze serverů + fungujících podobně jako Electrum. + +- [Libsecp256k1 #1446][] odstraňuje z projektu část assembly kódu pro x86_64 + a přechází na používání stávajícího jazyka C, který byl vždy používán na + ostatních platformách. Assembly kód byl před několika lety ručně optimalizován za + účelem zvýšení výkonnosti knihovny, avšak kompilátory se od té doby + zlepšily a nové verze GCC i LLVM (clang) nyní produkují ještě efektivnější + kód. + +- [BTCPay Server #5389][] přidává podporu pro bezpečné vytváření multisig + peněženek dle [BIP129][] (viz [zpravodaj č. 136][news136 bip129], _angl._). + To umožňuje BTCPay serveru spolupracovat během jednoduchého nastavení + multisigu s několika softwarovými peněženkami a hardwarovými podpisovými zařízeními. + +- [BTCPay Server #5490][] začíná ve výchozím nastavení používat [mempool.space][] + pro [odhad poplatků][ms fee api] s místním Bitcoin Core uzlem jako jeho zálohou. + Vývojáři pod PR poznamenávají, že mají pocit, že odhad poplatků poskytovaný + Bitcoin Core nereaguje dostatečně rychle na změny v místním mempoolu. Viz + [Bitcoin Core #27995][] pro související diskuzi o obtížích vylepšování + přesnosti odhadu poplatků. + +## Krásné svátky! + +Toto číslo je letošním posledním pravidelným vydáním. Ve středu 20. prosince +vydáme náš šestý roční přehled. Pravidelné vydávání zpravodaje bude pokračovat ve středu +3. ledna. + +{% assign day_after_posting = page.date | date: "%s" | plus: 86400 | date: "%Y-%m-%d 15:00" %} +{% include snippets/recap-ad.md when=day_after_posting %} +{% 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://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 +[recap279 liqad]: /en/podcast/2023/11/30/#update-to-the-liquidity-ads-specification-transcript +[news182 block1983702]: /en/newsletters/2022/01/12/#bitcoin-core-23882 +[demand website]: https://dmnd.work/ +[news247 sri]: /cs/newsletters/2023/04/19/#aktualizace-referencni-implementace-protokolu-stratum-v2 +[warnet github]: https://github.com/bitcoin-dev-project/warnet +[warnet scenarios]: https://github.com/bitcoin-dev-project/warnet/blob/main/docs/scenarios.md +[warnet monitoring]: https://github.com/bitcoin-dev-project/warnet/blob/main/docs/monitoring.md +[payjoin-cli]: https://github.com/payjoin/rust-payjoin/tree/master/payjoin-cli +[block arrival github]: https://github.com/bitcoin-data/block-arrival-times +[b10c tweet]: https://twitter.com/0xb10c/status/1732826609260872161 +[stale block github]: https://github.com/bitcoin-data/stale-blocks +[envoy v1.4.0]: https://github.com/Foundation-Devices/envoy/releases/tag/v1.4.0 +[bbqr github]: https://github.com/coinkite/BBQr +[zeus v0.8.0]: https://github.com/ZeusLN/zeus/releases/tag/v0.8.0 +[review club 25228]: https://bitcoincore.reviews/25228 +[bitcoin core mempool replacements]: https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md +[glozow rbf improvements]: https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff diff --git a/_posts/cs/newsletters/2024-01-03-newsletter.md b/_posts/cs/newsletters/2024-01-03-newsletter.md new file mode 100644 index 0000000000..f0253f9c55 --- /dev/null +++ b/_posts/cs/newsletters/2024-01-03-newsletter.md @@ -0,0 +1,373 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 283' +permalink: /cs/newsletters/2024/01/03/ +name: 2024-01-03-newsletter-cs +slug: 2024-01-03-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden sdílíme informace o odhalení nedávných zranitelností v LND, +shrnujeme návrh na časové zámky závislé na poplatcích, popisujeme myšlenku na +zlepšení odhadu poplatků použitím clusterů transakcí, diskutujeme o specifikaci +neutratitelných klíčů v deskriptorech, zkoumáme náklady na pinning v navrhovaném +přeposílání transakcí verze 3, zmiňujeme návrh BIPu na začlenění deskriptorů +do PSBT, oznamujeme nástroj používající navrhovaný MATT pro doklad o spuštění +nějakého programu, nahlížíme na návrh umožňující vysoce efektivní skupinové +vystoupení ze sdílených UTXO a poukazujeme na nové strategie výběru mincí +navrhovaných pro Bitcoin Core. Též nechybí naše pravidelné rubriky oznamující +nová vydání a popisující významné změny v populárních bitcoinových +páteřních projektech. + +## Novinky + +- **Zveřejnění nedávných zranitelností LND:** Niklas Gögge zaslal do fóra + Delving Bitcoin [příspěvek][gogge lndvuln] o dvou zranitelnostech, které + předtím [zodpovědně nahlásil][topic responsible disclosures]. Následně + byly vydány dvě opravné verze LND. Verze 0.15.0 či pozdější zranitelnost + neobsahují. Uživatelé starších verzí by měli zvážit kvůli této i dalším + 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ů. + + - 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 + uživatelů, kteří byli těmito zranitelnostmi postiženi. + +- **Časové zámky se závislostí na poplatcích:** John Law zaslal do emailových + skupin Bitcoin-Dev a Lightning-Dev [příspěvek][law fdt] s hrubým návrhem + na soft fork, který by umožňoval, aby mohly [časové zámky][topic timelocks] + transakci volitelně odemknout, pouze pokud by byl medián jednotkových poplatků + v bloku pod zvolenou úrovní. Například Alice chce vložit peníze do + platebního kanálu s Bobem, ale vyžaduje též, aby mohla prostředky refundovat, + pokud by byl Bob nedostupný. Dá mu tedy možnost kdykoliv nárokovat své + prostředky, které mu vyplatí, avšak sobě navíc poskytne možnost nárokovat + po vypršení časového zámku zpět svůj vklad. S blížící se expirací časového + zámku se Bob pokusí své prostředky nárokovat, ale aktuální jednotkový poplatek + je mnohem vyšší, než kolik v počátku kontraktu předpokládali. Bob není schopen + nechat potvrdit transakci vyjadřující jeho nárok na prostředky, ať již z důvodu + nedostatku bitcoinů na poplatky nebo kvůli neekonomičnosti. Současný bitcoinový + protokol by kvůli Bobově nemožnosti konat umožnil Alici refundovat své prostředky. + S Lawovým návrhem by byla expirace časového zámku, který Alici v refundaci + zabraňuje, prodloužena, dokud by nepřišla série bloků s mediánem jednotkových + poplatků pod hodnotou stanovenou Alicí a Bobem během vyjednávání kontraktu. + Bob by tak měl možnost nechat svou transakci potvrdit s přijatelnějším + poplatkem. + + Law poznamenává, že tento návrh řeší jeden z dlouhodobých problémů popsaných + [v původním článku o Lightning Network][original Lightning Network paper] + jako _záplava vynucených expirací_ („forced expiration floods”). Problém + se vyskytuje v situaci, kdy se příliš mnoho kanálů najednou snaží o + uzavření a v důsledku není pro všechny dostatek blokového prostoru, aby stihli + transakci potvrdit před vypršením časových zámků. Časové zámky závislé + na poplatcích by v takovém případě byly prodloužené, neboť by aktuální + jednotkové poplatky převyšovaly mez. Transakce by opět mohly být potvrzovány, + jakmile se aktuální poplatky budou snižovat. V současnosti mají LN kanály + pouze dva uživatele, ale návrhy jako [továrny kanálů][topic channel factories] + či [joinpooly][topic joinpools], kde jsou UTXO sdílena více než dvěma uživateli, + jsou ještě náchylnější. Tento návrh by výrazně zvýšil jejich bezpečnost. + Law dále poznamenává, že v některých těchto konstruktech se strana, která + drží podmínku refundace (v našem příkladě Alice), kvůli zvyšujícím se + poplatkům dostává do největší nevýhody, neboť její kapitál je uzamčen + v kontraktu až do doby, kdy se poplatky začnou snižovat. Časové zámky + závislé na poplatcích dávají této straně další podněty, aby jednala způsobem, + který udržuje poplatky nízké, tedy aby neuzavírala množství kanálů během + krátké doby. + + Implementace časových zámků závislých na poplatcích je zvolena tak, + aby byly snadno a volitelně použitelné účastníky kontraktu a aby bylo + množství ukládaných dat potřebných pro validaci plnými uzly co nejnižší. + + Návrh obdržel průměrné množství reakcí obsahující například návrhy na + [ukládání][riard fdt] parametrů v příloze („annex”) [taprootu][topic taproot], + [zavazování][boris fdt] bloků ke svému mediánu poplatku pro podporu + lehkých klientů či [způsob][harding pruned], kterým by mohly ořezané + uzly fork podporovat. Mezi Lawem a [ostatními][evo fdt] proběhla + další diskuze o dopadu placení poplatků těžařům mimo blockchain (napřímo). + +- **Odhad poplatků a clustery:** Abubakar Sadiq Ismail zaslal do fóra + Delving Bitcoin [příspěvek][ismail cluster] o použití některých nástrojů + a poznatků z návrhu [cluster mempoolu][topic cluster mempool] k vylepšení + odhadu poplatků v Bitcoin Core. Současný algoritmus odhadu poplatků + v Bitcoin Core sleduje, kolik bloků uplyne mezi přijetím transakce do + místního mempoolu a jejím potvrzením. Když je transakce potvrzena, její + jednotkový poplatek je použit k aktualizaci systému předpovídání, jak + dlouho potrvá čekání transakcí s podobným jednotkovým poplatek, než + budou potvrzené. + + Používáním tohoto způsobu jsou některé transakce Bitcoin Core pro kalkulaci + poplatků ignorovány, zatímco jiné mohou být započítány nesprávně. Důvodem + je [CPFP][topic cpfp], kde potomci dávají těžařům podnět k potvrzení + jejich předků. Potomci mohou mít sami o sobě vyšší jednotkový poplatek, + ale když se jejich poplatek a poplatek předků posoudí dohromady, + může být jednotkový poplatek výrazně nižší. To vede k delšímu čekání + na potvrzení. Aby nenadhodnocoval rozumnou výši poplatků, neaktualizuje + Bitcoin Core odhad poplatků transakcemi, které vstoupí do mempoolu, + když je jejich rodič nepotvrzený. Podobně může mít rodičovská transakce + sama o sobě nižší jednotkový poplatek, ale posouzena spolu se svými + potomky bude mít jednotkový poplatek výrazně vyšší. Taková transakce + bude potvrzena v porovnání s odhadem rychleji. Bitcoin Core neprovádí + v takových případech žádné kompenzace. + + Cluster mempool bude držet související transakce spolu a bude nabízet + jejich dělení do chunků, jejichž společná těžba bude výdělečná. Ismail + navrhuje sledovat jednotkové poplatky chunků oproti individuálním + transakcím (i když chunk může být tvořen jedinou transakcí) a poté + se pokusit nalézt stejné chunky v blocích. Je-li chunk potvrzen, + může být odhad poplatků aktualizován jeho jednotkovým poplatkem namísto + poplatků jednotlivých transakcí. + + Návrhu se dostalo pozitivního přijetí, vývojáři diskutují o podrobnostech, + které by takový algoritmus musel vzít do úvahy. + +- **Specifikace neutratitelných klíčů v deskriptorech:** Salvatore Ingala + otevřel na fóru Delving Bitcoin [diskuzi][ingala undesc] o tom, jak + umožnit [deskriptorům][topic descriptors], jmenovitě [taprootovým][topic + taproot], specifikovat klíč, pro který není znám žádný soukromý klíč. + Jednou z důležitých situací je posílání peněz na taprootové výstupy, + které mohou být utraceny pouze skriptem. Jako klíč pro utracení + klíčem se musí použít nějaký neutratitelný. + + Ingala popsal několik obtíží používání neutratitelných klíčů v + deskriptorech a navrhl několik řešení s různými kompromisy. + Pieter Wuille shrnul několik nedávných osobních diskuzí o deskriptorech, + včetně jednoho [nápadu][wuille undesc2] týkajícího se neutratitelných + klíčů. Josie Baker se ptal po důvodech, proč nemohou být neutratitelné + klíče konstantní (jako například tzv. NUMS bod v BIP341), což by + umožnilo komukoliv okamžitě poznat, že byl použit neutratitelný klíč. + To by mohlo být výhodné v některých protokolech, například v + [tichých platbách][topic silent payments]. Ingala Bakerovi odpověděl, + že „je to forma zanechávání stop. Můžeš se sám rozhodnout tuto informaci + kdykoliv odhalit, ale je dobré, když tě standardy nenutí.” Wuille dále + sdílel algoritmus pro generování důkazu. V posledním příspěvku vlákna + v době psaní zpravodaje Ingala poznamenal, že specifikace pravidel + souvisejících s neutratitelnými klíči může být rozdělena mezi + deskriptory a pravidla peněženek dle [BIP388][]. + +- **Náklady na pinning V3 transakcí:** Peter Todd zaslal do emailové skupiny + Bitcoin-Dev [analýzu][todd v3] navrhovaných pravidel [přeposílání v3 + transakcí][topic v3 transaction relay] týkající se [pinningu transakcí][topic + transaction pinning] u protokolů jako je LN. Mějme příklad, ve kterém + Bob a Mallory sdílí kanál. Bob chce kanál zavřít, zveřejní tedy svou + aktuální commitment transakci a připojí drobnou transakci, která + přispěje na výši poplatku pomocí [CPFP][topic cpfp], s celkovou velikostí + 500 vbyte. Mallory v P2P síti detekuje Bobovy transakce před tím, než + dosáhnou nějakého těžaře, a odešle svou vlastní commitment transakci spolu + s velikým potomkem s celkovou velikostí 100 000 vbyte, avšak s + nižším jednotkovým poplatkem, než byla Bobova původní verze. Dle současných + výchozích pravidel přeposílání v Bitcoin Core i aktuálního návrhu + [přeposílání balíčků][topic package relay] se může Bob pokusit + [nahradit][topic rbf] dvě Mallořiny transakce, avšak kvůli pravidlu č. 3 + [BIP125][] bude muset zaplatit i za prostor zabraný Mallořinou transakcí. + Pokud Bob původně platil 10 sat/vbyte (tedy celkem 5 000 sat) a Mallořina + verze měla 5 sat/vbyte (500 000 sat), musel by Bob za náhradu zaplatit stokrát + víc, než kolik platil původně. Pokud částka překračuje Bobovu mez, Mallořina + velká transakce s nízkým poplatkem nemusí před vypršením časového zámku obdržet + žádnou konfirmaci, což by vedlo ke krádeži Bobových peněz. + + V navrhovaném přeposílání transakcí verze 3 umožňují pravidla transakcím + nejvýše jednoho nepotvrzeného potomka, který bude přeposílán, ukládán + v mempoolech a vytěžen uzly dodržující pravidla verze 3. Jak Peter Todd + ve svém příspěvku ukázal, i to by umožnilo Mallory navýšit Bobovy náklady + zhruba 1,5×, než kolik původně zamýšlel zaplatit. Reakce většinou + souhlasily s existencí rizika, že by musel Bob platit záškodnické protistraně více. + Poznamenávají však, že by to bylo výrazně méně než v případě současných pravidel. + + Dodatečná diskuze se vedla kolem konkrétních bodů pravidel verze 3, + [dočasnými anchory][topic ephemeral anchors] („ephemeral anchors”) a jejich + porovnání s aktuálně dostupnými [CPFP carve-out][topic cpfp carve out] a [anchor + výstupy][topic anchor outputs]. + +- **Návrh BIPu na deskriptory v PSBT:** Tým SeedHammer zaslal do emailové skupiny + Bitcoin-Dev [návrh BIPu][seedhammer descpsbt] na přidání [deskriptorů][topic + descriptors] do [PSBT][topic psbt]. Hlavním záměrem zdá se býti zapouzdření + deskriptorů do PSBT pro přenos mezi peněženkami, jelikož návrh umožňuje, + aby PSBT neobsahovalo transakční data, je-li přítomen deskriptor. To by + mohlo být užitečné pro přenos informací o výstupech ze softwarové + peněženky do hardwarového podpisového zařízení nebo pro několik peněženek + podílejících se na vícenásobném podpisu pro sdílení informací o výstupech, + které chtějí vytvářet. V době psaní zpravodaje neobdržel návrh BIPu + v emailové skupině žádné reakce, ačkoliv dřívější, listopadový [příspěvek][seedhammer + descpsbt2] o předchůdci návrhu zpětnou vazbu [obdržel][black descpsbt]. + +- **Verifikace libovolných programů pomocí navrhovaného opkódu z MATT:** + Johan Torås Halseth zaslal do fóra Delving Bitcoin [příspěvek][halseth ccv] + o [elftrace][], programu, který pomocí opkódu `OP_CHECKCONTRACTVERIFY` + z návrhu soft forku [MATT][] umožňuje nějaké straně v kontraktu nárokovat + peníze, pokud by byl úspěšně spuštěn libovolný program. Jedná se o koncept + podobný BitVM (viz [zpravodaj č. 273][news273 bitvm]), ale díky opkódu + navrženému přímo pro verifikaci spuštění programu je jeho bitcoinová + implementace jednodušší. Elftrace je schopen fungovat s programy + zkompilovanými pro architekturu RISC-V a používající linuxový formát + [ELF][]. Téměř každý programátor může snadno vytvořit programy pro + tento formát, což činí elftrace vysoce dostupným. Příspěvek neobdržel + v době psaná zpravodaje žádné reakce. + +- **Dávkování plateb při odchodu z poolu pomocí dokladů o podvodu:** + Salvatore Ingala zaslal do fóra Delving Bitcoin [návrh][ingala exit], + který může vylepšit kontrakty s více stranami, kde několik uživatelů + sdílí jedno UTXO (např. [joinpooly][topic joinpools] či [továrny + kanálů][topic channel factories]) a někteří z uživatelů chtějí z kontraktu + vystoupit v době, kdy jsou ostatní nedostupní, ať již záměrně či neúmyslně. + Typicky jsou takové protokoly konstruovány tak, že každý uživatel má + offchain k dispozici transakci, kterou může zveřejnit, když má v záměru + vystoupit. Znamená to, že chce-li pět uživatelů z kontraktu vystoupit, + i v nejlepším případě musí každý z nich zveřejnit jednu transakci a každá + z nich bude mít minimálně jeden vstup a jeden výstup; dohromady pět vstupů + a pět výstupů. Ingala navrhuje způsob, kterým by tito uživatelé mohli + spolupracovat a vystoupit s použitím pouze jediné transakce s jedním vstupem + a pěti výstupy. Tím by dosáhli redukce velikosti okolo 50 %, + obvyklé v [dávkových platbách][topic payment batching]. + + Ve složitých kontraktech s mnoha účastníky může redukce v onchain + velikosti snadno výrazně přesáhnout 50 %. Ba co více, pokud by těchto + pět uživatelů chtělo jednoduše přesunout své prostředky na nové UTXO + sdílené jen jimi, mohli by použít transakci s jedním vstupem a + jedním výstupem. Pět uživatelů by tak dosáhlo 80% redukce velikosti, + v případě sta uživatelů by snížení bylo 99 %. Takto výrazné snížení + velikosti u velkých skupin uživatelů, kteří se chtějí přesunout + z jednoho kontraktu do jiného, může být kritické v obdobích s vysokými + poplatky. Pro příklad mějme sto uživatelů, kteří mají každý zůstatek + 10 000 sat (110 Kč v době psaní). Pokud by každý z nich měl jednotlivě + platit transakční poplatek za vystoupení z kontraktu a vstup do nového + kontraktu, spotřebovala by dokonce i nepravděpodobně malá transakce + o velikosti 100 vbyte s poplatkem 100 sat/vbyte celý jejich zůstatek. + Pokud by mohli dohromady přesunout svůj 1 milión sat v jediné + 200vbytové transakci s poplatkem 100 sats/vbyte, každý z nich by zaplatil + pouze 200 sat (2 % zůstatku). + + Dávkové platby se dosáhne tím, že jeden z účastníků kontraktu vytvoří + transakci s útratou společných prostředků na výstupy odsouhlasené + ostatními aktivními stranami. Kontrakt toto umožní pouze v případě, + pokud uživatel vytvářející transakci pošle nejdříve peníze do fondu, + o který by přišel v případě podvodu. Výše fondu by měla být výrazně + vyšší, než kolik by podvodem jinak získal. Pokud by žádná strana + nebyla schopna poskytnout doklad o podvodu ukazující, že autor transakce + jednal nečestně, byly by prostředky z fondu vrácenu jemu. Ingala zhruba + popsal, jak by tento systém mohl být přidán do protokolů s kontrakty + s více účastníky pomocí [OP_CAT][], `OP_CHECKCONTRACTVERIFY` a introspekce + částky z navrhovaného soft forku [MATT][]. Poznamenal, že by to bylo + ještě jednodušší, pokud by byly k dispozici i [OP_CSFS][topic op_checksigfromstack] + a 64bitové aritmetické operátory [tapscriptu][topic tapscript]. + + Myšlenka se setkala s mírným množstvím reakcí. + +- **Nové strategie výběru mincí:** Mark Erhardt zaslal do fóra Delving + Bitcoin [příspěvek][erhardt coin] popisující krajní případy používání + [výběru mincí][topic coin selection] v Bitcoin Core a navrhuje dvě + nové strategie, které by tyto krajní případy adresovaly snížením + počtu vstupů transakcí s vysokým jednotkovým poplatkem. Dále shrnuje + výhody a nevýhody všech strategií v Bitcoin Core, již implementovaných + i jím navrhovaných, a poskytuje výsledky několik simulací, které provedl + s různými algoritmy. Konečným cílem pro Bitcoin Core je vybírat sadu + vstupů, která dlouhodobě minimalizuje podíl poplatků na hodnotě UTXO + vyhýbá se tvoření nadbytečně velkých transakcí v době s vysokými + poplatky. + +## 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.* + +- [Core Lightning 23.11.2][] je opravným vydáním, které pomáhá zajistit, + aby LND uzly mohly platit faktury vytvořené uživateli Core Lightning. + Podrobnosti jsou obsaženy níže v poznámkách k Core Lightning #6957 + v rubrice o _významných změnách_. + +- [Libsecp256k1 0.4.1][] je vedlejším vydáním, které „mírně zrychluje ECDH + operace a výrazně zvyšuje výkonnost mnoha funkcí na x86_64 ve výchozím + nastavení.” + +## Významné změny v kódu a dokumentaci + +*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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Bitcoin Core #28349][] přináší požadavek na používání kompilátorů kompatibilních + s C++20. Díky tomu mohou budoucí PR používat vlastnosti C++20. Jak uvádí popis PR, + „C++20 umožní psát bezpečnější kód, neboť umožňuje během kompilace kontrolovat + více věcí.” + +- [Core Lightning #6957][] opravuje neúmyslnou nekompatibilitu, která zabraňovala + uživatelům LND platit faktury vygenerované Core Lightningem ve výchozím nastavení. + Problém spočívá v nastavení `min_final_cltv_expiry`, které určuje minimální počet + bloků, po který musí příjemce čekat před nárokováním platby. [BOLT2][] navrhuje + nastavit tuto volbu ve výchozím stavu na 18, avšak LND používá hodnotu 9, což je + nižší hodnota, než kterou Core Lightning ve výchozím nastavení přijme. Core Lightning + problém řeší tím, že ve faktuře nastaví pole vyžadující, aby tato hodnota byla 18. + +- [Core Lightning #6869][] upravuje RPC volání `listchannels`, aby již nadále nezačleňovalo + [neoznámené kanály][topic unannounced channels]. Uživatelé, kteří tuto informaci + vyžadují, mohou použít volání `listpeerchannels`. + +- [Eclair #2796][] aktualizuje svou závislost na [logback-classic][], aby tím + vyřešil jednu zranitelnost. Eclair přímo nepoužívá postiženou funkcionalitu, + upgrade má však zajistit, aby žádný plugin nebo jiný související software touto + zranitelností postižen nebyl. + +- [Eclair #2787][] aktualizuje svou podporu stahování hlaviček z BitcoinHeaders.net + na nejnovější verzi API. Stahování hlaviček přes DNS napomáhá chránit uzel před + [útoky zastíněním][topic eclipse attacks] („eclipse attacks”). [Zpravodaj č. 123][news123 + headers] (_angl._) popisuje původní začlenění do Eclairu. I jiný software + používající BitcoinHeaders.net by měl aktualizovat verzi používaného API. + +- [LDK #2781][] a [#2688][ldk #2688] upravují podporu pro posílání a přijímání + [zaslepených plateb][topic rv routing], obzvláště se zaslepenými cestami s více + skoky. Dále vylepšuje dodržování pravidla, aby [nabídky][topic offers] vždy + obsahovaly alespoň jeden zaslepený skok. + +- [LDK #2723][] přidává podporu pro posílání [onion zpráv][topic onion + messages] pomocí _přímých spojení_. V případě, kdy odesílatel nemůže nalézt + trasu k příjemci, avšak zná jeho síťovou adresu (například protože příjemce + je veřejný uzel, který zveřejnil svou IP adresu), může odesílatel k příjemcovi + jednoduše otevřít přímé spojení, zprávu odeslat a pak volitelně spojení zavřít. + Díky tomu mohou onion zprávy dobře fungovat, i pokud jsou podporovány pouze + malým počtem uzlů (což je současný stav). + +- [BIPs #1504][] upravuje BIP2, aby umožňoval používání Markdownu pro BIPy. Dříve musely + být BIPy psány ve značkovacím jazyce Mediawiki. + +{% assign day_after_posting = page.date | date: "%s" | plus: 86400 | date: "%Y-%m-%d 15:00" %} +{% include snippets/recap-ad.md when=day_after_posting %} +{% 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://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://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://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 +[news273 bitvm]: /cs/newsletters/2023/10/18/#platby-podminene-libovolnym-vypoctem +[elf]: https://cs.wikipedia.org/wiki/Executable_and_Linkable_Format +[ingala exit]: https://delvingbitcoin.org/t/aggregate-delegated-exit-for-l2-pools/297 +[erhardt coin]: https://delvingbitcoin.org/t/gutterguard-and-coingrinder-simulation-results/279/1 +[logback-classic]: https://logback.qos.ch/ +[news123 headers]: /en/newsletters/2020/11/11/#eclair-1545 +[bip388]: https://github.com/bitcoin/bips/pull/1389 +[core lightning 23.11.2]: https://github.com/ElementsProject/lightning/releases/tag/v23.11.2 +[libsecp256k1 0.4.1]: https://github.com/bitcoin-core/secp256k1/releases/tag/v0.4.1 diff --git a/_posts/cs/newsletters/2024-01-10-newsletter.md b/_posts/cs/newsletters/2024-01-10-newsletter.md new file mode 100644 index 0000000000..56d4c3668e --- /dev/null +++ b/_posts/cs/newsletters/2024-01-10-newsletter.md @@ -0,0 +1,345 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 284' +permalink: /cs/newsletters/2024/01/10/ +name: 2024-01-10-newsletter-cs +slug: 2024-01-10-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme souhrn diskuze o LN anchorech a součástech návrhu +přeposílání transakcí verze 3 a připojujeme oznámení o pokusné implementaci +LN-Symmetry. Též nechybí naše pravidelné rubriky se souhrnem sezení +Bitcoin Core PR Review Clubu a popisem významných změn v populárním +bitcoinovém páteřním software. + +## Novinky + +- **Diskuze o LN anchorech a přeposílání transakcí verze 3:** + Antoine Poinsot zaslal do fóra Delving Bitcoin [příspěvek][poinsot v3] + oživující debatu o návrzích [pravidel přeposílání transakcí verze 3][topic + v3 transaction relay] a [dočasných anchorů][topic ephemeral anchors] + („ephemeral anchors”). Zdá se, že vlákno bylo motivováno [kritikou][todd v3] + pravidel přeposílání v3, kterou Peter Todd zveřejnil na svém blogu. + Diskuzi jsme rozčlenili do několik částí: + + - **Časté používání externích poplatků může ohrožovat decentralizaci těžby:** + v ideální podobě by bitcoinový protokol odměňoval těžaře dle + jejich hashrate. Poplatky placené za transakce tuto vlastnost zachovávají: + těžař s 10 % hashrate má 10% pravděpodobnost ulovení poplatků za příští + blok, zatímco těžař s 1 % hashrate má 1% šanci. Poplatky placené mimo + transakce, tedy napřímo těžařům (nazývané [out-of-band fees][topic out-of-band + fees]) tuto vlastnost narušují: systém, který platí těžařům kontrolujícím dohromady + přes 55 % hashrate, nabízí 99% šanci potvrzení transakce během příštích + šesti bloků. To by pravděpodobně mělo za následek velice málo poplatků + směřující k malým těžařům s méně než 1 % hashrate. Pokud by byli malí těžaři + placeni relativně méně než velcí, přirozeně by to vedlo k centralizaci. + Ta by dále snížila počet subjektů, které musí být napadeny za účelem + cenzurování transakcí. + + Aktivně používané protokoly, jako jsou [LN-Penalty s anchory][topic + anchor outputs] (LN-Anchors), [DLC][dlc cpfp] či [validace na straně + klienta][topic client-side validation], umožňují přinejmenším části + svých onchain transakcí platit _exogenními_ poplatky. Tyto poplatky placené + transakcí mohou být navýšeny poplatky placenými pomocí nezávislých UTXO. + Například v LN-Anchors obsahuje commitment transakce za každou stranu + jeden výstup pro navýšení poplatků pomocí [CPFP][topic cpfp] (potomek + platí UTXO navíc) a transakce HTLC-Success a HTLC-Failure (HTLC-X) jsou + částečně podepsané pomocí `SIGHASH_SINGLE|SIGHASH_ANYONECANPAY`. Mohou + tak být agregovány do jediné transakce s přinejmenším jedním vstupem + navíc pro platbu poplatků (z odděleného UTXO). + + Peter Todd se soustředil na potenciální verzi LN, která používá [P2TR][topic + taproot] a navrhované dočasné anchory, a tvrdí, že jeho závislost na + exogenních poplatcích motivuje k placení poplatků mimo blockchain. + Konkrétně by jednostranné uzavření kanálu, ve kterém nečekají žádné platby + ([HTLC][topic htlc]), umožnilo velkému těžaři přijímajícímu poplatky + mimo blockchain začlenit do bloku dvakrát více zavírajících transakcí, + než kolik by byl schopen začlenit malý těžař přijímající pouze běžné + poplatky přes CPFP navyšování. Velký těžař by mohl vydělávat na + nabízení poplatků mimo blockchain s dodatečnou slevou. Dle Petera Todda + se jedná o ohrožení decentralizace. + + Příspěvek naznačuje, že některá použití exogenních poplatků v rámci + protokolů jsou přijatelná, důležitá je tedy frekvence očekávaného + používání a relativní rozdíl jejich velikostí oproti poplatkům mimo + blockchain. Jinými slovy, často se opakující jednostranná uzavření + kanálů bez čekajících plateb a se 100% velikostí navíc by zřejmě + byla považována za rizikovější než zřídka se opakující jednostranná + uzavření s 20 čekajícími HLTC, kde je 20 % velikosti navíc. + + - **Dopady exogenních poplatků na bezpečnost, škálovatelnost a náklady:** + Toddův příspěvek také poznamenává, že existující návrhy jako + [LN-Anchors][topic anchor outputs] i budoucí návrhy, které používají + [dočasné anchory][topic ephemeral anchors], vyžadují po každém uživateli + uchovávat v peněžence jedno UTXO navíc pro důležitá navýšení poplatků. + Jelikož vytvoření UTXO s sebou nese náklady v podobě blokového prostoru, + teoreticky se tím snižuje maximální počet nezávislých uživatelů protokolu + o polovinu či více. Dále to znamená, že uživatel nemůže bezpečně alokovat + celý svůj zůstatek peněženky na své LN kanály, což zhoršuje uživatelskou + přívětivost LN. A konečně, používání [navyšování poplatků pomocí CPFP][topic + cpfp] nebo dodatečných vstupů transakcí pro exogenní platby poplatků + vyžaduje používání většího blokového prostoru a placení více poplatků + než placení poplatků přímo ze vstupní hodnoty transakce (endogenní + poplatky). Teoretické náklady se tak zvyšují, i kdybychom ostatní problémy + neuvažovali. + + - **Dočasné anchory představují nový druh pinningových útoků:** jak jsme zmínili + [v minulém zpravodaji][news283 pinning], Peter Todd popsal drobný pinningový + útok proti uživatelům dočasných anchorů. Nemá-li commitment transakce + žádné čekající platby (HTLC), může neprivilegovaný útočník vytvořit situaci, + ve které může čestný uživatel platit 1,5× až 3,7× více na poplatcích, aby + dosáhl zamýšleného jednotkového poplatku. Avšak pokud by se tento čestný + uživatel rozhodl pro [trpělivost][harding pinning] namísto placení poplatků + navíc, platil by útočník část nebo celý poplatek čestného uživatele. Jelikož + nejsou commitment transakce bez čekajících plateb tlačené žádnými časovými + zámky, mnoho čestných uživatelů se může rozhodnout pro trpělivost a nechat + své transakce potvrdit za útočníkovy náklady. Útok je též proveditelný, + pokud jsou nějaká HTLC použita, avšak náklady na vymanění se z útoku + jsou pro čestného uživatele nižší a i tak může útočník nakonec tratit. + + - **Alternativa: používání endogenních poplatků s předem podepsanými RBF navýšeními:** + Peter Todd navrhuje a analyzuje alternativní přístup: podepsání několika verzí + každé commitment transakce s různými jednotkovými poplatky. Například navrhuje + podepsat 50 různých verzí LN-Penalty commitment transakce v poplatcích + začínajících na 10 sat/vbyte a navýšené v každé verzi o 10 % až do poplatku + 1 000 sat/vbyte. Nemá-li commitment transakce žádné čekající platby (HTLC), + vyplývá z jeho analýzy, že by podepisování zabralo kolem pěti milisekund. + Avšak za každé HTLC připojené ke commitment transakci by se počet podpisů + zvýšil o 50 a podepisování by se navýšilo o pět milisekund. Bastien Teinturier + odkázal na [dřívější diskuzi][bolts #1036], ve které použil podobný přístup. + + Ačkoliv může tento nápad v některých případech fungovat, Peter Todd poznamenal, + že endogenní poplatky s předem podepsanými inkrementálními navýšeními nejsou + vždy dostatečnou náhradou za exogenní poplatky. Jsou-li časová zdržení + vyžadovaná za podepsání commitment transakcí obsahující několik HTLC + vynásobena počtem skoků běžné platební cesty, může [prodleva][harding delays] + snadno dosáhnout více než sekundy a teoreticky může vystoupat až za jednu + minutu. Peter Todd poznamenal, že zdržení by mohlo být zhruba konstantní, + pokud by byl dostupný navrhovaný opkód [SIGHASH_ANYPREVOUT][topic sighash_anyprevout] + (APO). + + I kdyby prodleva byla konstantních pět milisekund, je [možné][harding stuckless], + že by přeposílající uzly používající endogenní poplatky vydělávaly méně + než uzly používající exogenní poplatky. Důvodem by bylo očekávání, + že by plátci využívali [redundatního přeplácení][topic redundant + overpayments], které by odměňovalo rychlejší přeposílání oproti + pomalejším, i kdyby byl rozdíl pouze v řádu milisekund. + + Další obtíží by bylo používání stejných endogenních poplatků za předem podepsané + HTLC-Success a HTLC-Timeout transakce (HTLC-X). I s APO by to mohlo vyžadovat + n2 podpisů. Jak Peter Todd dodává, toto číslo by + mohlo být sníženo předpokladem, že HTLC-X transakce by platily podobný + jednotkový poplatek jako commitment transakce. + + [Diskuze][teinturier fees], zda by endogenní poplatky mohly vyústit + v nadměrné množství kapitálu rezervovaného na poplatky, zůstala nedořešena. + Například pokud by Alice podepsala varianty s poplatky od 10 do 1 000 sat/vbyte, + musela by se rozhodovat na základě možnosti, že by její protistrana Bob + odeslal na blockchain variantu s 1 000 sat/vbyte, i když ona sama by takový + poplatek neplatila. Znamená to, že nemůže od Boba přijmout platby, ve kterých + Bob odesílá peníze, které by potřeboval na variantu s 1 000 sat/vbyte. + Například commitment transakce s 20 HTLC by dočasně zablokovala jeden milión + satoshi (10 000 Kč v době psaní). Pokud by endogenní poplatky byly použity + také pro HTLC-X transakce, dočasně zablokovaná částka za 20 HTLC by byla + blíže k 4,5 miliónům satoshi (46 000 Kč). Pro porovnání, pokud by Bob + očekával poplatky exogenně, nemusela by Alice pro svou bezpečnost + redukovat kapacitu kanálu. + + - **Závěr:** diskuze v době psaní zpravodaje stále probíhala. Peter Todd ji + uzavřel slovy, že „existující použití anchor výstupů by mělo být kvůli výše + zmíněným rizikům centralizace těžby ukončeno a žádná nová podpora pro anchor + výstupy by neměla být do nových protokolů či Bitcoin Core přidávána.” + LN vývojář Rusty Russell zaslal [příspěvek][russell inline] o používání + efektivnější formy exogenních poplatků v nových protokolech za účelem + minimalizace rizik poplatků mimo blockchain. Ve vlákně ve fóru Delving + Bitcoin obhajovali vývojáři pracující na LN, transakcích verze 3 a dočasných + anchorech užitečnost anchorů a zdá se pravděpodobné, že budou fungovat i v protokolech + kolem v3. Pokud se něco význačného přihodí, budeme o tom v budoucích zpravodajích + informovat. + +- **Implementace LN-Symmetry** Gregory Sanders zaslal do fóra Delving + Bitcoin [příspěvek][sanders lns] se svou [pokusnou implementací][poc lns] + protokolu [LN-Symmetry][topic eltoo] (původně nazývaného _eltoo_) pracující + nad forkem Core Lightning. LN-Symmetry poskytuje obousměrné platební kanály, + které zaručují schopnost publikovat na blockchainu poslední stav kanálu bez + potřeby trestných transakcí. Avšak vyžadují, aby mohly dceřiné transakce + utrácet z kterékoliv verze rodičovské transakce. To je možné pouze se softforkovou + 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. + + 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ů. + +## 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í.* + +[Vyhoď upravený čas (druhý pokus)][review club 28956] +je PR od Niklase Göggeho, které upravuje kontrolu validity +bloku v souvislosti s časovým razítkem bloku. Zjednodušeně řečeno, +pokud je časové razítko bloku (obsažené v jeho hlavičce) příliš daleko +v minulosti nebo v budoucnosti, uzel blok odmítne jako nevalidní. +Poznamenejme, že je-li blok nevalidní kvůli časovému razítku, které +je příliš daleko v budoucnosti, může se tento blok stát validním +později (i když blockchain už se mezitím posune jinam). + +{% include functions/details-list.md + q0="Musí mít hlavička bloku časové razítko? Pokud ano, proč?" + a0="Ano, časové razítko se používá v úpravách náročnosti a k validaci + časových zámků transakcí." + a0link="https://bitcoincore.reviews/28956#l-39" + + q1="Jaký je rozdíl mezi Median Time Past (MTP) a časem upraveným + dle sítě (network-adjusted)? Který z nich je relevantní pro + toto PR?" + a1="MTP je medián času posledních 11 bloků a používá se jako spodní + hranice validity časového razítka bloků. Čas upravený dle sítě + je spočítán jako čas našeho uzlu plus medián rozdílů mezi naším + časem a časem náhodně vybraných odchozích spojení (tento medián + může být negativní). Pouze čas upravený dle sítě je předmětem + tohoto PR." + a1link="https://bitcoincore.reviews/28956#l-67" + + q2="Proč jsou tyto časy koncepčně zcela odlišné?" + a2="MTP je jedinečně definovaný pro všechny uzly synchronizované + na stejný blockchain: existuje konsenzus času. Čas upravený + dle sítě se mezi uzly liší." + a2link="https://bitcoincore.reviews/28956#l-74" + + q3="Proč zkrátka nepoužíváme MTP pro všechno a nevyhodíme čas dle sítě zcela?" + a3="MTP se používá jako spodní hranice validity časového razítka bloku, + ale jako horní hranice nemůže být použit, neboť časová razítka + budoucích bloků jsou neznámá." + a3link="https://bitcoincore.reviews/28956#l-77" + + q4="Proč jsou vynucovány limity, jak moc mimo může časové razítko bloku + být od vlastního času uzlu? A jelikož nevyžadujeme přesný souhlas + na čase, mohou být tyto limity přísnější?" + a4="Rozsah časového razítka bloku je omezen, aby nemohly záškodnické + uzly snadno manipulovat se změnami náročnosti a časovými zámky. + Tento druh útoků se nazývá ohýbání času („timewarp”). + Validní rozsah může být do určité míry striktnější, + ale kdyby byl příliš striktní, mohlo by to vést k dočasnému + štěpení blockchainu, neboť by některé uzly odmítaly bloky + shledané validními jinými uzly. Časová razítka bloků nemusí + být přesná, ale musí v dlouhodobém horizontu sledovat + skutečný čas." + a4link="https://bitcoincore.reviews/28956#l-82" + + q5="Proč by se před tímto PR snažil útočník manipulovat časem upraveným dle sítě?" + a5="Jedná-li se o těžící uzel, mohl by způsobit odmítání + vytěžených bloků nebo zabránění přijetí validního bloku, + načež by těžař plýtval hashrate (oba tyto případy by pomohly + konkurenčním těžařům). Mohl by přinutit napadený uzel + následovat špatný blockchain. Mohl by způsobit, aby se transakce + s časovými zámky netěžily ve správný čas. Mohl by provést + [útok dilatací času][time dilation attack] v Lightning Network." + a5link="https://bitcoincore.reviews/28956#l-89" + + q6="Jak mohl útočník před tímto PR manipulovat s časem upraveným dle sítě? + Které síťové zprávy by použil?" + a6="Útočník by nám musel poslat „version” zprávy s pozměněnými + časovými razítky od několika spojení, která mají pod kontrolou. + Musel by nás donutit mít více než polovinu odchozích spojení + k jeho uzlům, což je velice náročné, avšak jednodušší než + kompletní zastínění uzlu." + a6link="https://bitcoincore.reviews/28956#l-100" + + q7="Toto PR používá jako horní hranici pro validaci času bloku místní čas uzlu + namísto času upraveného dle sítě. Můžeme si být jisti, že se tím + dosáhne snížení možnosti provádět tajuplné útoky a ne jejich + zvýšení?" + a7="Diskuze, zda je pro útočníka jednodušší ovlivnit množinu spojení + uzlu nebo jeho vnitřní čas (např. použitím malware nebo falešnými + NTP zprávami), zůstala bez jasného závěru. Většina účastníků se + shodla, že PR přináší zlepšení." + a7link="https://bitcoincore.reviews/28956#l-102" + + q8="Mění toto PR chování konsenzu? Pokud ano, jedná se o soft fork, hard fork + nebo ani jeden? A proč?" + a8="Protože pravidla konsenzu nemohou používat vnější data mimo blockchain + (např. čas uzlu), nemůže toto PR být považováno za změnu konsenzu. + Jedná se jen o změnu pravidel _přijetí_ sítí. Neznamená to však, + že by tato pravidla byla volitelná – pravidla určující, jak daleko + do budoucnosti se může časové razítko bloku odchýlit, jsou pro + bezpečnost sítě [zásadní][se timestamp accecptance]." + a8link="https://bitcoincore.reviews/28956#l-141" + + q9="Které operace před tímto PR závisely na času upraveném dle sítě?" + a9="[`TestBlockValidity`][TestBlockValidity function], + [`CreateNewBlock`][CreateNewBlock function] (používaný těžaři pro + tvorbu šablon bloku) a + [`CanDirectFetch`][CanDirectFetch function] (používaný v P2P vrstvě). + Rozmanitost použití ukazuje, že PR neovlivňuje pouze validitu bloků, + ale má také další dopady, které musí být ověřeny." + a9link="https://bitcoincore.reviews/28956#l-197" +%} + +## Významné změny v kódu a dokumentaci + +*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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [LND #8308][] navyšuje `min_final_cltv_expiry_delta` z 9 na 18 dle doporučení + BOLT2 pro konečné platby. Tato hodnotu postihuje externí faktury, které nedodají + parametr `min_final_cltv_expiry`. Změna napravuje problémy s interoperabilitou + objevené poté, co CLN přestalo začleňovat parametr, když byla použita výchozí + hodnota 18. O tomto problému jsme se též zmínili [v minulém čísle][cln hotfix]. + +{% assign day_after_posting = page.date | date: "%s" | plus: 86400 | date: "%Y-%m-%d 15:00" %} +{% include snippets/recap-ad.md when=day_after_posting %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="1036,8308" %} +[poinsot v3]: https://delvingbitcoin.org/t/v3-transaction-policy-for-anti-pinning/340 +[todd v3]: https://petertodd.org/2023/v3-transactions-review +[dlc cpfp]: https://github.com/discreetlogcontracts/dlcspecs/blob/master/Non-Interactive-Protocol.md +[news283 pinning]: /cs/newsletters/2024/01/03/#naklady-na-pinning-v3-transakci +[harding pinning]: https://delvingbitcoin.org/t/v3-transaction-policy-for-anti-pinning/340/22 +[harding delays]: https://delvingbitcoin.org/t/v3-transaction-policy-for-anti-pinning/340/6 +[harding stuckless]: https://delvingbitcoin.org/t/v3-transaction-policy-for-anti-pinning/340/5 +[teinturier fees]: https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1873793179 +[russell inline]: https://rusty.ozlabs.org/2024/01/08/txhash-tx-stacking.html +[sanders lns]: https://delvingbitcoin.org/t/ln-symmetry-project-recap/359 +[poc lns]: https://github.com/instagibbs/lightning/tree/eltoo_support +[cln hotfix]: /cs/newsletters/2024/01/03/#core-lightning-6957 +[review club 28956]: https://bitcoincore.reviews/28956 +[time dilation attack]: /en/newsletters/2020/06/10/#time-dilation-attacks-against-ln +[se timestamp accecptance]: https://bitcoin.stackexchange.com/a/121251/97099 +[TestBlockValidity function]: https://github.com/bitcoin/bitcoin/blob/063a8b83875997068b3eb506b5f30f2691d18052/src/validation.cpp#L4228 +[CreateNewBlock function]: https://github.com/bitcoin/bitcoin/blob/063a8b83875997068b3eb506b5f30f2691d18052/src/node/miner.cpp#L106 +[CanDirectFetch function]: https://github.com/bitcoin/bitcoin/blob/063a8b83875997068b3eb506b5f30f2691d18052/src/net_processing.cpp#L1314 diff --git a/_posts/cs/newsletters/2024-01-17-newsletter.md b/_posts/cs/newsletters/2024-01-17-newsletter.md new file mode 100644 index 0000000000..00531b18df --- /dev/null +++ b/_posts/cs/newsletters/2024-01-17-newsletter.md @@ -0,0 +1,285 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 285' +permalink: /cs/newsletters/2024/01/17/ +name: 2024-01-17-newsletter-cs +slug: 2024-01-17-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme odhalení nedávné zranitelnosti postihující +Core Lightning a oznámení o dvou nových návrzích na soft fork. Dále +poskytujeme přehled návrhu cluster mempoolu, předáváme informaci +o aktualizované specifikaci a implementaci komprese transakcí a +shrnujeme diskuzi o těžaři extrahovatelné hodnotě (MEV) v nenulových +dočasných anchorech. 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 + +- **Odhalení nedávné zranitelnosti v Core Lightning:** Matt Morehouse + [oznámil][morehouse delving] na fóru Delving Bitcoin zranitelnost, + kterou před tím [zodpovědně nahlásil][topic responsible disclosures]. + Zranitelnost postihovala Core Lightning verze 23.02 až 23.05.2. + Novější verze 23.08 a vyšší postiženy nejsou. + + Morehouse tuto zranitelnost objevil, když pokračoval v práci na falešném + financování (viz [zpravodaj č. 266][news266 lnbugs]). Když znovu testoval + uzly s opravami, podařilo se mu vyvolat [souběh][race condition] („race + condition”), který po zhruba 30 sekundách CLN shodil. Je-li uzel offline, + nemůže bránit uživatele proti zlomyslným nebo porouchaným protistranám, + které uživatelovy prostředky vystavují riziku. Analýza ukázala, že CLN + opravilo původní zranitelnost falešného financování, ale než stačilo + opravu řádně otestovat, zranitelnost byla zveřejněna a jeden z pluginů + začlenil zneužitelný souběh. Po Morehouseově nahlášení byl připraven + patch, aby souběh nezpůsobil pád uzlu. + + Pro více informací doporučujeme přečíst Morehouseův skvělý blogový + příspěvek s [odhalením][morehouse full]. + +- **Návrh nového soft forku LNHANCE:** Brandon Black [zaslal][black lnhance] + do fóra Delving Bitcoin detaily o soft forku, který kombinuje předchozí + návrhy [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] (CTV) a + [OP_CHECKSIGFROMSTACK][topic op_checksigfromstack] (CSFS) s novým + návrhem `OP_INTERNALKEY`, který do zásobníku umisťuje [taprootový + interní klíč][taproot internal key]. Než budou moci zaplatit na výstup, + musí znát autoři skriptů interní klíč, aby ho mohli umístit + přímo do skriptu. `OP_INTERNALKEY` je zjednodušenou verzí [staršího + návrhu][rubin templating] původního autora CTV Jeremy Rubina. Nová + verze ušetří několik vbyte a díky ní budou skripty snadněji znovupoužitelné, + neboť hodnota klíče bude moci být načtena od interpretru skriptu. + + Ve vlákně popsali Black i jiní některé protokoly, které by tato kombinace + změn konsenzu umožňovala: [LN-Symmetry][topic eltoo] (eltoo), + [joinpooly][topic joinpools] ve stylu [Ark][topic ark], zjednodušená + [DLC][topic dlc] a [úschovny][topic vaults] bez předem podepsaných + transakcí. Další výhody přináší pro protokoly nižší úrovně jako + kontrola zahlcení ve stylu CTV či delegace podpisů ve stylu CSFS. + + V době psaní zpravodaje se technická diskuze omezovala na žádosti + o vysvětlení, které protokoly by tento návrh umožnil. + +- **Návrh na soft fork pro 64bitovou aritmetiku:** Chris Stewart + zaslal do fóra Delving Bitcoin [příspěvek][stewart 64] s [návrhem BIPu][bip + 64] na přidání 64bitových aritmetických operací do bitcoinu v budoucím + soft forku. Bitcoin [v současnosti][script wiki] umožňuje pouze 32bitové + operace (celá čísla se znaménkem, čísla přes 31 bitů tedy nemohou být + použita). Podpora pro 64bitové hodnoty by byla obzvláště výhodná v + jakýchkoliv konstruktech, které potřebují pracovat s částkou v satoshi + placenou na výstup. Ta je specifikována jako 64bitové celé číslo. + Například výstupovým protokolům [joinpoolu][topic joinpools] by + se introspekce částky hodila; viz zpravodaje [č. 166][news166 tluv] (_angl._) + a [č. 283][news283 exits]. + + V době psaní zpravodaje se diskuze soustředila na podrobnosti návrhu, + jak celá čísla kódovat, jaký způsob upgradu [taprootu][topic taproot] + použít a zda-li je lepší představit nové aritmetické opkódy či + využít stávající. + +- **Přehled návrhu cluster mempoolu:** Suhas Daftuar zaslal do fóra + Delving Bitcoin [souhrn][daftuar cluster] návrhu [cluster mempoolu][topic + cluster mempool]. Optech zpravodaj se pokusil shrnout současný stav + diskuze o cluster mempoolu ve [zpravodaji č. 280][news280 cluster], avšak + důrazně doporučujeme přečíst si tento přehled. Daftuar je jedním z + 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]. + + 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. + Proto četbu Daftuarova popisu doporučujeme vývojářům pracujícím na těžebním + software, peněženkách či kontraktových protokolech. V případě jakýchkoliv + nejasností nebo obav o možných negativních dopadech na bitcoin a jeho + interakci s cluster mempoolem se můžete zapojit do diskuze. + +- **Aktualizace specifikace a implementace komprese bitcoinových transakcí:** + Tom Briar zaslal do emailové skupiny Bitcoin-Dev [příspěvek][briar compress] + s aktualizovaným [návrhem specifikace][compress spec] a [implementace][bitcoin + core #28134] komprimovaných bitcoinových transakcí. Menší transakce by + byly praktičtější pro přeposílání omezenými médii, jakou jsou satelity + či steganografie (např. zakódování transakce do bitmapového obrázku). + Ve [zpravodaji č. 267][news267 compress] uvádíme popis původního návrhu. + Briar popisuje významné změny: „odstranění hledání nLocktime ve prospěch + relativní výšky bloků, která je používána všemi komprimovanými vstupy, + a použití druhého typu celého čísla s proměnlivou délkou.” + +- **Diskuze o těžaři extrahovatelné hodnotě v nenulových dočasných anchorech:** + Gregory Sanders zaslal do fóra Delving Bitcoin [příspěvek][sanders mev] + vyjadřující obavy o výstupech [dočasných anchorů][topic ephemeral anchors], + které obsahují více než 0 satoshi. Dočasný anchor platí na standardizovaný + výstupní skript, který může být utracen kýmkoliv. + + Jedním způsobem použití dočasných anchorů by bylo mít nulovou výstupní + hodnotu, což je rozumné vzhledem k pravidlům, která vyžadují, aby byly + doprovázeny dceřinou transakcí utrácející tento anchor výstup. Avšak + v současném LN protokolu chce-li jedna ze stran vytvořit [neekonomické][topic + uneconomical outputs] HTLC, je jeho částka použita na přeplacení + onchain poplatků commitment transakce. Takové HTLC se nazývá _ořezané_ + („trimmed HTLC”). Je-li ořezávání HTLC v commitment transakci učiněno + použitím dočasných anchorů, mohlo by být pro těžaře výdělečné, kdyby + potvrdil transakci bez dceřiné transakce utrácející výstup dočasného + anchoru. Po potvrzení commitment transakce není nikdo motivován k + utracení nulového výstupu dočasného anchoru, bude tedy navždy + okupovat prostor množiny UTXO v plných uzlech. + + Navrženou alternativou je nastavit hodnoty výstupů dočasných anchorů + rovnající se částkám ořezaných HTLC. Bude tak výhodné těžit commitment + transakci i utracení výstupu dočasného anchoru. Ve svém příspěvku + Sanders tuto možnosti analyzuje. Shledává, že tento způsob může přinést + několik bezpečnostních problémů. Ty mohou být vyřešeny těžaři, kteří + transakce analyzují a určí, kdy by bylo výhodnější, aby sami utratili + výstup dočasných anchorů nově vytvořenými transakcemi. Jedná se o druh + [těžaři extrahovatelné hodnoty][news201 mev] (MEV, „miner extractable value”). + Bylo navrženo několik dalších alternativních řešení: + + - *Přeposílání pouze takových transakcí, které jsou kompatibilní se záměry těžařů:* + pokud by se někdo pokusil utratit dočasný anchor způsobem, který nemaximalizuje + těžařovy příjmy, taková transakce by nebyla přeposlána. + + - *Spálení ořezané hodnoty:* namísto přeměny hodnoty ořezaného HTLC do poplatku + může být částka utracena na `OP_RETURN` výstup. Tím by byly satoshi + navždy neutratitelné. To by bylo možné pouze, pokud by byla commitment + transakce s ořezaným HTLC poslána do blockchainu. V běžném případě + jsou ořezané HTLC vyřešeny offchain a jejich hodnota je přesunuta + od jedné strany k druhé. + + - *Zajištění snadné propagace MEV transakcí:* namísto toho, aby těžaři + používali zvláštní kód maximalizující jejich hodnotu, usnadněme propagaci + těchto transakcí sítí, ať může kdokoliv spustit MEV kód a přeposlat + výsledky k těžařům způsobem, který zaručí, že všichni těžaři a + přeposílající uzly obdrží stejnou sadu transakcí. + + V době psaní zpravodaje nebylo dosaženo jasného závěru. + +## 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 0.0.119][] je novým vydáním této knihovny pro budování aplikací + nabízející LN. Bylo přidáno několik nových funkcí včetně přijímání plateb + na [zaslepené cesty][topic rv routing] s několika skoky. Vydání dále obsahuje + opravy několika chyb a další vylepšení. + +## 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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Bitcoin Core #29058][] je přípravným krokem k aktivaci [P2P přenosu + verze 2 (BIP324)][topic v2 p2p transport] ve výchozím nastavení. + Změna přidává podporu pro v2transport v konfiguračních argumentech + `-connect`, `-addnode` a `-seednode`, pokud je nastaven `-v2transport`. + Pokud spojení nepodporuje v2, použije se v1. Dále tento update + přidává do dashboardu `netinfo` (`bitcoin-cli`) sloupeček s verzí + přenosového protokolu. + +- [Bitcoin Core #29200][] umožňuje, aby [podpora sítě I2P][topic + anonymity networks] používala spojení šifrované pomocí „ECIES-X25519 + a ElGamal (typ 4 a 0, respektive). To umožní připojit se k I2P uzlům + kteréhokoliv druhu. Novější a rychlejší ECIES-X25519 bude upřednostňováno.” + +- [Bitcoin Core #28890][] odstraňuje konfigurační parameter `-rpcserialversion`, + který byl dříve označen za zastaralý (viz [zpravodaj č. 269][news269 rpc]). + Tato volba byla představena během přechodu na v0 segwit, aby umožnila + starším programům nadále přistupovat k blokům a transakcím bez segwitových + polí. Dnes by již všechny programy měly segwitovým transakcím rozumět + a tato volba již nadále není zapotřebí. + +- [Eclair #2808][] přidává do příkazu `open` parametr + `--fundingFeeBudgetSatoshis`, který definuje maximální částku, jakou + je uzel ochoten platit na onchain poplatcích za otevření kanálu. Výchozí + hodnota je nastavena na 0,1 % částky posílané do kanálu. Eclair se pokusí + zaplatit nižší poplatek, pokud je to možné, ale v případě nutnosti jej + navýší až na uvedenou částku. Do příkazu `rbfopen` byl přidán totožný + parametr, který definuje maximální částku na utracení za [RBF + navýšení poplatku][topic rbf]. + +- [LND #8188][] přidává několik nových RPC volání pro rychlé získání + debugovacích informací. Ty jsou zašifrované nějakým veřejným klíčem + a mohou tedy být patřičným soukromým klíčem rozšifrovány. Jak je v PR + vysvětleno, „myšlenkou je, že bychom v šabloně chybového hlášení na GitHubu + uvedli veřejný klíč a požádali uživatele, aby spustil příkaz `lncli encryptdebugpackage`. + Výstup potom může nahrát na GitHub a tím nám poskytnout informace, které + normálně pro debugování potřebujeme.“ + +- [LND #8096][] přidává „nárazníkovou zónu pro případ vysokých poplatků.” + V současném LN protokolu je strana, která sama financuje kanál, zodpovědná + za placení jakýchkoliv onchain poplatků přímo obsažených v commitment + transakci a předem podepsaných transakcích HTLC-Success a HTLC-Timeout + (HTLC-X). Nemá-li tato strana v kanálu příliš mnoho prostředků a poplatky + vzrostou, nemusí být schopna přijmout nové příchozí platby, neboť nemají + dostatek peněz na zaplacení poplatků, ačkoliv právě přijímají peníze. + Pro vyvarování se tohoto druhu problému se zaseknutými kanály doporučuje + [BOLT2][] (jak do něj bylo před několika lety přidáno v [BOLTs #740][]) + financující straně držet rezervu, aby mohly být platby přijímány i za + zvýšených poplatků. LND nyní také implementuje toto řešení, které je již + obsaženo v Core Lightning i Eclair (viz zpravodaje [č. 85][news85 stuck] a + [č. 89][news89 stuck], _angl._). + +- [LND #8095][] a [#8142][lnd #8142] přidávají dodatečnou logiku do částí kódu + LND, které zpracovávají [zaslepené trasy][topic rv routing]. Jedná se o součást + práce na plné podpoře zaslepených tras v LND. + +{% assign day_after_posting = page.date | date: "%s" | plus: 86400 | date: "%Y-%m-%d 15:00" %} +{% include snippets/recap-ad.md when=day_after_posting %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="28134,29058,29200,28890,2808,8188,8096,8095,8142,740" %} +[morehouse delving]: https://delvingbitcoin.org/t/dos-disclosure-channel-open-race-in-cln/385 +[morehouse blog]: https://morehouse.github.io/lightning/cln-channel-open-race/ +[script wiki]: https://en.bitcoin.it/wiki/Script#Arithmetic +[news166 tluv]: /en/newsletters/2021/09/15/#amount-introspection +[news283 exits]: /cs/newsletters/2024/01/03/#davkovani-plateb-pri-odchodu-z-poolu-pomoci-dokladu-o-podvodu +[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://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 +[race condition]: https://cs.wikipedia.org/wiki/Soub%C4%9Bh +[morehouse full]: https://morehouse.github.io/lightning/cln-channel-open-race/ +[black lnhance]: https://delvingbitcoin.org/t/lnhance-bips-and-implementation/376/ +[stewart 64]: https://delvingbitcoin.org/t/64-bit-arithmetic-soft-fork/397/ +[daftuar cluster]: https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393/ +[sanders mev]: https://delvingbitcoin.org/t/ephemeral-anchors-and-mev/383/ +[bip 64]: https://github.com/bitcoin/bips/pull/1538 +[taproot internal key]: /en/newsletters/2019/05/14/#complex-spending-with-taproot +[news56 carveout]: /en/newsletters/2019/07/24/#bitcoin-core-15681 +[news269 rpc]: /cs/newsletters/2023/09/20/#bitcoin-core-28448 +[news85 stuck]: /en/newsletters/2020/02/19/#c-lightning-3500 +[news89 stuck]: /en/newsletters/2020/03/18/#eclair-1319 +[ldk 0.0.119]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.0.119 +[rubin templating]: https://freenode.irclog.whitequark.org/bitcoin-wizards/2019-05-24#24661606; diff --git a/_posts/cs/newsletters/2024-01-24-newsletter.md b/_posts/cs/newsletters/2024-01-24-newsletter.md new file mode 100644 index 0000000000..7caa6deba0 --- /dev/null +++ b/_posts/cs/newsletters/2024-01-24-newsletter.md @@ -0,0 +1,223 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 286' +permalink: /cs/newsletters/2024/01/24/ +name: 2024-01-24-newsletter-cs +slug: 2024-01-24-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme zveřejnění opraveného selhání konsenzu ve +starších verzích btcd, ohlášení nového repozitáře bitcoinových +specifikací a popis navrhovaných změn LN pro dočasné anchory +a přeposílání transakcí verze 3. Též nechybí naše pravidelné rubriky +s popisem aktualizací služeb a klientského software, 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 + +- **Zveřejnění opraveného selhání konsenzu v btcd:** Niklas Gögge + [oznámil][gogge btcd] ve fóru Delving Bitcoin selhání konsenzu + starších verzí btcd, které předtím [zodpovědně nahlásil][topic + responsible disclosures]. Relativní [časové zámky][topic timelocks] + byly do bitcoinu [přidány][topic soft fork activation] v soft forku + přiřazením významu sekvenčním číslům vstupů a jeho vynucování konsenzem. + Aby bylo zajištěno, že žádné podepsané transakce vytvořené před soft forkem + nebudou považovány za neplatné, jsou relativní časové zámky aplikovány pouze + na transakce verze 2 či vyšší. To umožňuje transakcím s původním číslem verze 1 + zachovat platnost s jakýmikoliv vstupy. Avšak v původním bitcoinovém + programu jsou čísla verzí celými čísly se znaménkem, což znamená, že záporná + čísla verzí jsou možná. Část _referenční implementace_ [BIPu 68][BIP68] + poznamenává, že „verze 2 a vyšší” se týká čísla verze [přetypované][cast] + z celého čísla se znaménkem na celé číslo bez znaménka, z čeho vyplývá, + že se pravidla aplikují na jakoukoliv verzi, která není 0 či 1. + + Gögge zjistil, že btcd toto přetypování neimplementovalo. Bylo tedy možné + zkonstruovat transakci se záporným číslem verze, dle které by Bitcoin Core + musel následovat pravidla BIP68, ale btcd by nemuselo. V tom případě by + jeden uzel transakci odmítl (a každý blok, který by ji obsahoval), zatímco + jiný uzel by ji přijal (spolu s blokem). To by vedlo ke štěpení blockchainu. + Útočník by toho mohl zneužít k oklamání provozovatele btcd uzlu (nebo + software na něj připojeného) k přijetí nevalidních bitcoinů. + + Chyba bylo diskrétně nahlášena vývojářům btcd, kteří ji opravili ve vydání + v0.24.0. Všichni, kteří používají btcd pro vynucování konsenzu by měli + vážně zvážit upgrade. Dále Chris Stewart [zaslal][stewart bitcoin-s] do fóra + patch s opravou stejné chyby obsažené v knihovně bitcoin-s. Autoři kódu, + který by mohl být použit k validaci relativních časových zámků dle BIP68, + jsou vyzýváni, aby svůj kód též ověřili. + +- **Návrh změn LN pro přeposílání verze 3 a dočasné anchory:** Bastien + Teinturier zaslal do fóra Delving Bitcoin [příspěvek][teinturier v3] + s popisem změn specifikace Lightning Network, které by podle něj účinně + využívaly [přeposílání transakcí verze 3][topic v3 transaction relay] a + [dočasných anchorů][topic ephemeral anchors] („ephemeral anchors”). Změny + se zdají býti jednoduché: + + - *Výměna anchorů*: commitment transakce mají v současnosti dva [anchor výstupy][topic + anchor outputs], které díky pravidlu [CPFP carve out][topic cpfp carve out] + garantují možnost [navýšit poplatek pomocí CPFP][topic cpfp]. Tyto dva + anchor výstupy budou nahrazeny jedním dočasným anchorem. + + - *Snížení prodlevy*: aby bylo zajištěno, že pravidlo CPFP carve out bude vždy fungovat, je na + commitment transakce aplikována jednobloková prodleva navíc. V rámci přeposílání + verze 3 již není prodleva potřeba, může tedy být odstraněna. + + - *Přesměrování ořezaných HTLC*: V případě existence [ořezaných HTLC][topic trimmed htlc] + („trimmed HTLCs”) se namísto utracení jejich celkové hodnoty na poplatcích za commitment + transakci přidá jejich kombinovaná hodnota na anchor výstup. Díky tomu mohou + být tyto poplatky navíc použity na zajištění potvrzení commitment transakce + i dočasného anchoru ([minulé číslo zpravodaje][news285 mev] obsahuje podrobnosti). + + - *Další změny*: Několik dalších drobných změn a zjednodušení. + + Následná diskuze zkoumala několik zajímavých důsledků navržených změn včetně: + + - *Snížené požadavky na UTXO*: Díky odstranění jednoblokové prodlevy navíc je jednodušší zajistit, že + bude publikován správný stav kanálu. Pokud pochybná strana zveřejní + revokovanou commitment transakci, druhá strana může použít hlavní výstup + své commitment transakce pro navýšení poplatku revokované commitment transakce + pomocí CPFP. Nemusí tedy držet oddělené potvrzené UTXO pouze pro tento účel. + Aby to bylo bezpečné, musí mít tato strana dodatečnou finanční rezervu, + neboť 1% minimum doporučované [BOLT2][] nemusí být dostatečné. Uzly, které + nepřeposílají platby a mají dostatečnou rezervu, potřebují z bezpečnostních + důvodů jedno oddělené UTXO pouze, chtějí-li přijmout příchozí platbu. + + - *Vštípená v3 logika:* V reakci na obavy vyjádřené během setkání vývojářů specifikace + LN, že design, implementace a nasazení těchto změn mohou trvat dlouho, + [navrhuje][sanders transition] Gregory Sanders mezikrok, + ve kterém by bylo zvláštním způsobem nakládáno s transakcemi, které vypadají + jako LN commitment transakce se současným stylem anchorů. Bitcoin Core + by tak mohl nasadit cluster mempool bez čekání na vývoj LN. Po dosažení dostatečně + širokého nasazení a po dokončení upgradu LN implementací by mohlo být toto + dočasné pravidlo odstraněno. + + - *Určení maximální velikosti potomka:* návrh v3 přeposílání nastavuje velikost + nepotvrzeného potomka na 1 000 vbyte. Čím je velikost větší, tím více musí čestný + uživatel platit na překonání [pinningu][topic transaction pinning] (viz + [zpravodaj č. 283][news283 v3pin]). Nižší velikost omezuje čestného uživatele + v možnostech výběru vstupu pro přispění na poplatky. + +- **Nový repozitář dokumentace:** Anthony Towns zaslal do emailové skupiny + Bitcoin-Dev [příspěvek][towns binana] oznamující nový repozitář specifikací + 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-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-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 + v rubrice s _významnými změnami kódu a dokumentace_. + +## 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.* + +- **Vydán Envoy 1.5:** + [Envoy 1.5][] přidává podporu [taprootového][topic taproot] posílání i přijímání + a mění způsob, kterým nakládá s [neekonomickými výstupy][topic uneconomical outputs]. + Dále obsahuje opravy chyb [a další novinky][envoy blog]. + +- **Vydána Liana v4.0:** + Byla [vydána][liana blog] [Liana v4.0][]. Obsahuje podporu pro [navyšování + poplatků pomocí RBF][topic rbf], rušení transakcí pomocí RBF, automatický + [výběr mincí][topic coin selection] a ověřování adres hardwarovými podpisovými + zařízeními. + +- **Ohlášen Mercury Layer:** + [Mercury Layer][] je [implementací][mercury layer github] [statechainů][topic statechains], + která používá [variaci][mercury blind musig] protokolu [MuSig2][topic musig] pro + zaslepené podepisování provozovatelem statechainu. + +- **Ohlášena peněženka AQUA:** + [Peněženka AQUA][AQUA wallet] je [open source][aqua github] mobilní peněženkou, která podporuje + bitcoin, Lightning Network a [sidechain][topic sidechains] Liquid. + +- **Samourai Wallet ohlašuje atomické směny:** + [Atomická směna napříč blockchainy][samourai gitlab swap] založená na předchozím + [bádání][samourai gitlab comit] umožňuje peer-to-peer směny mezi bitcoinem a Monerem. + +## 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 0.0.120][] je bezpečnostní vydání této knihovny pro budování aplikací + s LN. „Opravuje DoS zranitelnost, kterou lze vyvolat nedůvěryhodným vstupem + od spojení, je-li aktivována volba `UserConfig::manually_accept_inbound_channels`.” + Vydání dále obsahuje drobná vylepšení a opravy několika dalších chyb. + +- [HWI 2.4.0-rc1][] je kandidátem na vydání příští verze toho balíčku + poskytujícího jednotné rozhraní k několika různým hardwarovým podpisovým + zařízením. + +## 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] a +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Bitcoin Core #29239][] umožňuje pomocí RPC volání `addnode` používat + [přenosový protokol verze 2][topic v2 p2p transport], je-li aktivní volba + `-v2transport`. + +- [Eclair #2810][] umožňuje, aby informace [trampolínového routování][topic + trampoline payments] zašifrované v onion zprávě používaly více než 400 + bytů. Maximální velikost je dle [BOLT4][] 1 000 bytů. Trampolínové + routování vyžadující méně než 400 bytů je zarovnáno na 400 bytů. + +- [LDK #2791][], [#2801][ldk #2801] a [#2812][ldk #2812] dokončují přidání + podpory [zaslepených cest][topic rv routing] a počínají tuto schopnost + oznamovat síti. + +- [Rust Bitcoin #2230][] přidává funkci pro kalkulaci _efektivní hodnoty_ vstupu, + což je jeho hodnota bez nákladů na utracení. + +{% assign day_after_posting = page.date | date: "%s" | plus: 86400 | date: "%Y-%m-%d 15:00" %} +{% include snippets/recap-ad.md when=day_after_posting %} +{% 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://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 +[news232 inqui]: /cs/newsletters/2023/01/04/#bitcoin-inquisition +[news285 mev]: /cs/newsletters/2024/01/17/#diskuze-o-tezari-extrahovatelne-hodnote-v-nenulovych-docasnych-anchorech +[news285 lnhance]: /cs/newsletters/2024/01/17/#navrh-noveho-soft-forku-lnhance +[stewart bitcoin-s]: https://delvingbitcoin.org/t/disclosure-btcd-consensus-bugs-due-to-usage-of-signed-transaction-version/455/2 +[gogge btcd]: https://delvingbitcoin.org/t/disclosure-btcd-consensus-bugs-due-to-usage-of-signed-transaction-version/455 +[hwi 2.4.0-rc1]: https://github.com/bitcoin-core/HWI/releases/tag/2.4.0-rc.1 +[ldk 0.0.120]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.0.120 +[cast]: https://cs.wikipedia.org/wiki/P%C5%99etypov%C3%A1n%C3%AD#Explicitn%C3%AD_(vynucen%C3%A9) +[Envoy 1.5]: https://github.com/Foundation-Devices/envoy/releases/tag/v1.5.1 +[envoy blog]: https://foundationdevices.com/2024/01/envoy-version-1-5-1-is-now-live/ +[Liana v4.0]: https://github.com/wizardsardine/liana/releases/tag/v4.0 +[liana blog]: https://www.wizardsardine.com/blog/liana-4.0-release/ +[Mercury Layer]: https://mercurylayer.com/ +[mercury blind musig]: https://github.com/commerceblock/mercurylayer/blob/dev/docs/blind_musig.md +[mercury layer github]: https://github.com/commerceblock/mercurylayer/tree/dev/docs +[AQUA Wallet]: https://aquawallet.io/ +[aqua github]: https://github.com/AquaWallet/aqua-wallet +[samourai gitlab swap]: https://code.samourai.io/wallet/comit-swaps-java/-/blob/master/docs/SWAPS.md +[samourai gitlab comit]: https://code.samourai.io/wallet/comit-swaps-java/-/blob/master/docs/files/Atomic_Swaps_between_Bitcoin_and_Monero-COMIT.pdf diff --git a/_posts/cs/newsletters/2024-01-31-newsletter.md b/_posts/cs/newsletters/2024-01-31-newsletter.md new file mode 100644 index 0000000000..4c9dfd9ccc --- /dev/null +++ b/_posts/cs/newsletters/2024-01-31-newsletter.md @@ -0,0 +1,242 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 287' +permalink: /cs/newsletters/2024/01/31/ +name: 2024-01-31-newsletter-cs +slug: 2024-01-31-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme popis návrhu na nahrazování transakcí verze 3 +pomocí RBF pravidel k usnadnění přechodu na cluster mempool a +souhrn polemiky proti `OP_CHECKTEMPLATEVERIFY` na základě jeho potřeby +exogenních poplatků. Též nechybí naše pravidelné rubriky se souhrnem +zajímavých otázek a odpovědí z Bitcoin Stack Exchange, oznámeními o +nových vydáních a popisem významných změn v populárních bitcoinových +páteřních projektech. + +## Novinky + +- **Příbuzenské nahrazování poplatkem:** Gloria Zhao zaslala do fóra Delving + Bitcoin [příspěvek][zhao v3kindred] o nahrazování transakcí + příbuznými transakcemi i bez existence konfliktu mezi nimi. Dvě + transakce jsou _v konfliktu_, pokud nemohou obě dvě zároveň + existovat ve validním blockchainu. Obvyklým důvodem je utracení + stejného UTXO, což porušuje pravidlo proti dvojímu utracení. Pravidla [RBF][topic rbf] + porovnávají transakci v mempoolu oproti nově obdržené transakci, která + je s ní v konfliktu. Zhao navrhuje idealizovaný způsob, jak nakládat + s konflikty: má-li přeposílající uzel dvě transakce, z nichž akceptována může být pouze + jedna, měl by vybrat ne první, ale tu, která nejlépe vyhovuje provozovatelovým + cílům (např. maximalizace příjmů z těžby a omezení přeposílání + zdarma). Pravidla RBF aplikují toto pravidlo na konflikty, Zhao + ve svém příspěvku tuto myšlenku rozšiřuje i na příbuzné transakce. + + Bitcoin Core aplikuje _pravidla_ omezující počet a velikost příbuzných + transakcí, které mohou být zároveň v mempoolu. To zabraňuje několika druhům + DoS útoků, ale také kvůli tomu může mempool odmítnout transakci B proto, + že předtím obdržel transakci A a tím bylo dosaženo limitu. Toto je + v rozporu s výše popsaným principem: namísto toho by měl Bitcoin Core akceptovat + A či B v souladu se svými cíli. + + Navrhovaná pravidla pro [přeposílání transakcí verze 3][topic v3 + transaction relay] povolují, aby měl nepotvrzený v3 rodič v mempoolu + pouze jediného potomka. Jelikož žádná z těchto transakcí nemůže mít + žádné další předky v mempoolu, aplikace existujících pravidel RBF na + nahrazení tohoto potomka je snadná a Zhao ji již + [naimplementovala][zhao kindredimpl]. Pokud by existující LN + commitment transakce s [anchor výstupy][topic anchor outputs] + automaticky přijaly pravidla v3, jak popisuje [minulé číslo + zpravodaje][news286 imbued], byla by každá ze stran vždy schopna + navýšit poplatek commitment transakce: + + - Alice může poslat commitment transakci s potomkem pro placení poplatků. + + - Alice může poté navýšit poplatek potomka pomocí RBF. + + - Bob může použít příbuzenského nahrazení k vyhození Alicina potomka + zasláním svého vlastního potomka, který platí vyšší poplatky. + + - Alice může poté použít příbuzenského nahrazení na Bobova potomka + zasláním svého potomka s ještě vyšším poplatkem (Bobův potomek by + tak byl vyhozen). + + Přidání tohoto pravidla a jeho automatická aplikace na existující + LN anchory umožní odstranit pravidlo [CPFP carve-out][topic cpfp carve out]. + Toto odstranění je nutné pro implementaci [cluster mempoolu][topic cluster + mempool], který by měl v budoucnu umožnit nejrůznější druhy nahrazení + v souladu s ekonomickými záměry těžařů. + + V době psaní zpravodaje nenadnesl ve fóru nikdo proti této myšlence žádné + námitky. Jeden přispěvatel se tázal, zda by se tímto staly [dočasné + anchory][topic ephemeral anchors] nepotřebnými. Autor tohoto návrhu + Gregory Sanders odpověděl: „Neplánuju přestat pracovat na dočasných + anchorech. Nulové výstupy mají několik důležitých použití i mimo LN.” + +- **Opozice vůči CTV kvůli vyžadování exogenních poplatků:** + Peter Todd zaslal do emailové skupiny Bitcoin-Dev [příspěvek][pt ctv] + se svými argumenty proti [exogenním poplatkům][topic fee sourcing] + (viz [zpravodaj č. 284][news284 ptexogenous]) aplikovanými na navrhovaný + [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify]. Poznamenává, + že „v mnoha (ne-li ve všech) případech, kdy je CTV použito + k umožnění sdílení jednoho UTXO mezi několika stranami, je náročné až + nemožné zajistit, aby všechny varianty CTV pokryly všechny možné + jednotkové poplatky. Očekává se, že CTV budou obvykle používané spolu + s [anchor výstupy][topic ephemeral anchors], které budou platit poplatky, […] + nebo snad i pomocí soft forku [sponzorovaných transakcí][topic fee + sponsorship]. […] Požadavek, aby měl každý uživatel k dispozici UTXO + na placení poplatků, je v rozporu s nabízenou efektivitou schémat sdílení + UTXO použitím CTV. […] Jedinou realistickou alternativou je zaplatit za UTXO + pomocí třetí strany (např. LN platbou), ale to už by bylo výhodnější zaplatit + poplatek [mimo blockchain][topic out-of-band fees]. To je pochopitelně + velice nežádoucí z pohledu centralizace těžby.” (Odkazy přidal Optech.) + Doporučuje vzdát se CTV a namísto toho pracovat na [schématech kovenantů][topic + covenants], která jsou kompatibilní s [RBF][topic rbf]. + + John Law odpověděl, že díky časovým zámkům závislým na poplatku (viz [zpravodaj + č. 283][news283 fdt]) by mohlo být CTV s endogenními poplatky bezpečné v případech, + kdy je potřebné dosáhnout potvrzení transakce před vypršením nějaké lhůty. Na druhou + stranu by časové zámky závislé na poplatcích mohly na velmi dlouho pozdržet některá + vyrovnání kontraktů. + +## 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/" %} + +- [Jak dnes v Bitcoin Core funguje synchronizace bloků?]({{bse}}121292) + Pieter Wuille popisuje strom hlaviček bloků, data bloků, aktivní + chaintip (vrchol řetězce) a datové struktury blockchainu. Dále vysvětluje + synchronizaci hlaviček, bloků a procesy aktivace bloků, které následují. + +- [Jak zabraňuje stažení hlaviček před bloky útoku zaplněním disku?]({{bse}}76018) + Pieter Wuille doplňuje starou otázku o vysvětlení pozdějšího opatření proti + spamu přidanému do Bitcoin Core 24.0, které se nazývá „Headers Presync” (viz + [zpravodaj č. 216][news216 headers presync], _angl._) a během kterého dochází + k synchronizaci hlaviček před tím, než započne synchronizace dat bloků. + +- [Je BIP324 v2transport u tor a i2p spojení nadbytečný?]({{bse}}121360) + Pieter Wuille připouští, že [přenos verze 2][topic v2 p2p transport] nenabízí + během používání [anonymních sítí][topic anonymity networks] další výhody. + Dodává, že oproti nešifrované verzi 1 může potenciálně dosáhnout lepšího + výpočetního výkonu. + +- [Jak rozumně nastavit maximální počet spojení?]({{bse}}121088) + Pieter Wuille rozlišuje mezi [odchozími a příchozími spojeními]({{bse}}121015) + a vypisuje body, které je dobré zvážit při nastavení vyšších hodnot + `-maxconnections`. + +- [Proč není horní hranice (+2 hodiny) času bloku nastavena jako pravidlo konsenzu?]({{bse}}121248) + V této i [dalších]({{bse}}121247) souvisejících [otázkách]({{bse}}121253) vysvětluje + Pieter Wuille požadavek, aby časové razítko nového bloku nebylo více než + dvě hodiny v budoucnosti, důležitost tohoto požadavku a proč „pravidla konsenzu + mohou záviset pouze na informacích, ke kterým existuje závazek (commitment) pomocí + hashů bloku.” + +- [Počet sigop a jeho dopad na výběr transakce?]({{bse}}121355) + Uživatel Cosmik Debris se ptá, jak omezení operací ověření podpisů + („sigop”) dopadají na těžařovu konstrukci šablony bloku a na mempoolový + [odhad poplatků][topic fee estimation]. + +## 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 2.4.0][] je vydáním další verze tohoto balíčku poskytujícího společné + rozhraní několika různým hardwarovým podpisovým zařízením. Nové vydání přidává + podporu pro Trezor Safe 3 a obsahuje několik drobných vylepšení. + +## 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 #29291][] přidává test, který selže, pokud má transakce spouštějící + opkód `OP_CHECKSEQUENCEVERIFY` záporné číslo verze. Pokud by byl + tento test spouštěn alternativními implementacemi konsenzu, odhalil by chybu + zmíněnou v [minulém čísle][news286 bip68ver]. + +- [Eclair #2811][], [#2813][eclair #2813] a [#2814][eclair #2814] + přidávají [trampolínovým platbám][topic trampoline payments] možnost + použít [zaslepenou cestu][topic rv routing] ke konečnému příjemci. + Trampolínové routování samo o sobě nadále používá běžné identifikátory + uzlu zašifrované v onion zprávě, každý trampolínový uzel se tedy dozví + identifikátor následujícího trampolínového uzlu. Avšak je-li použita zaslepená + cesta, poslední trampolínový uzel se nově dozví pouze počáteční uzel zaslepené + cesty. Nedozví se identifikátor konečného příjemce. + + Dříve záviselo soukromí trampolín na použití několika trampolínových + přeposílajících uzlů, aby žádný z nich s jistotou nevěděl, jsou-li + posledním přeposílajícím. Nevýhodou tohoto přístupu je používání + delších cest, které zvyšovaly pravděpodobnost selhání a vyžadovaly platbu + vyšších poplatků. Nově přeposlání platby i přes jediný trampolínový + uzel zabrání, aby se tento uzel dozvěděl konečného příjemce. + +- [LND #8167][] umožňuje, aby LND uzel kooperativně zavřel kanál, který + má stále jednu či více čekajících plateb ([HTLC][topic htlc]). [BOLT2][] + specifikace určuje, že správným řešením je, aby jedna strana poslala + zprávu `shutdown`, po které nebudou přijata žádná nová HTLC. Poté, + co jsou všechna čekající HTLC vyřízena offchain, obě strany si vyjednají + a podepíší transakci kooperativního uzavření. Když v předchozích verzích + LND obdrželo zprávu `shutdown`, uzavřelo kanál jednostranně, což si + vyžádalo nadbytečné onchain transakce a poplatky. + +- [LND #7733][] přidává do [strážní věže][topic watchtowers] možnost + zálohy a vynucení správného uzavření [jednoduchých taprootových + kanálů][topic simple taproot channels], které jsou nyní v LND + experimentálně podporovány. + +- [LND #8275][] počíná od spojení vyžadovat podporu určitých univerzálně + nasazených vlastností dle specifikace v [BOLTs #1092][] (viz [zpravodaj + č. 259][news259 lncleanup]). + +- [Rust Bitcoin #2366][] zastarává metodu `.txid()` objektů `Transaction` + a nahrazuje ji metodou `.compute_txid()`. Kdykoliv je metoda `.txid()` + volána, je txid transakce vypočítáno nově, což spotřebovává u velkých + transakcí či velkého množství malých transakcí významný procesorový + čas. Nové jméno pomůže programátorům uvědomit si potenciální náklady + volání metody. Metody `.wtxid()` a `.ntxid()` (založené na + [BIP141][], respektive na [BIP140][]) jsou podobným způsobem přejmenovány + na `.compute_wtxid()` a `.compute_ntxid()`. + +- [HWI #716][] přidává podporu pro hardwarové podpisové zařízení Trezor Safe 3. + +- [BDK #1172][] přidává do peněženky API pro registraci jednotlivých bloků. + Uživatel s přístupem k množině bloků může postupně, blok po bloku, aktualizovat + peněženku dle transakcí z těchto bloků. To může být použito pro každý blok + v řetězci. Software dále může použít nějaký způsob filtrování (např. + [kompaktní filtry bloků][topic compact block filters]) k nalezení pouze + takových bloků, které pravděpodobně obsahují transakce relevantní pro peněženku, + a může tedy uvažovat pouze tuto podmnožinu bloků. + +- [BINANAs #3][] přidává [BIN24-5][] se seznamem repozitářů s bitcoinovými + specifikacemi, jakou jsou BIPy, BOLTy, BLIPy, SLIPy, LNPBP a specifikace DLC. + Též jsou vyjmenovány repozitáře se specifikacemi i jiných, souvisejících projektů. + +{% assign day_after_posting = page.date | date: "%s" | plus: 86400 | date: "%Y-%m-%d 15:00" %} +{% include snippets/recap-ad.md when=day_after_posting %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="29291,2811,2813,2814,8167,7733,8275,1092,2366,716,1172,3" %} +[hwi 2.4.0]: https://github.com/bitcoin-core/HWI/releases/tag/2.4.0 +[news286 bip68ver]: /cs/newsletters/2024/01/24/#zverejneni-opraveneho-selhani-konsenzu-v-btcd +[trezor safe 3]: https://trezor.io/trezor-safe-3 +[news283 fdt]: /cs/newsletters/2024/01/03/#casove-zamky-se-zavislosti-na-poplatcich +[zhao v3kindred]: https://delvingbitcoin.org/t/sibling-eviction-for-v3-transactions/472 +[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://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 new file mode 100644 index 0000000000..422c61cdb6 --- /dev/null +++ b/_posts/cs/newsletters/2024-02-07-newsletter.md @@ -0,0 +1,297 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 288' +permalink: /cs/newsletters/2024/02/07/ +name: 2024-02-07-newsletter-cs +slug: 2024-02-07-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme oznámení o veřejném odhalení chyby v Bitcoin Core +postihující LN, popis bezpečného otevírání nových 0-conf kanálů v souladu +s omezenou topologií navrhovaných transakcí verze 3, popis pravidla, kterým +se musí řídit mnohé protokoly umožňující třetím stranám přispět vstupem +do transakce, souhrn několika diskuzí o návrhu nových pravidel nahrazování +transakcí eliminující pinning transakcí a aktualizaci migrace emailové +skupiny Bitcoin-Dev. + +## Novinky + +- **Zveřejnění chyby v Bitcoin Core způsobující pozdržení bloků a postihující LN:** + Eugene Siegel [odhalil][siegel stall] na fóru Delving Bitcoin chybu + v Bitcoin Core, kterou [zodpovědně nahlásil][topic responsible + disclosures] před téměř třemi lety. Bitcoin Core 22 a vyšší obsahují opravy + této chyby, ale mnoho lidí stále provozuje dotčené verze a někteří z nich + mohou provozovat i LN implementace či jiný podobný software, který by + mohl být zranitelný vůči zneužití chyby. Důrazně se doporučuje upgradovat + na Bitcoin Core 22 či vyšší. Pokud víme, nikdo kvůli tomuto útoku + nepřišel o prostředky. + + Útočník nalezne přeposílající LN uzel, který je napojený na bitcoinový + uzel s Bitcoin Core verze starší než 22. Dále útočník otevře k bitcoinovému uzlu + oběti velké množství spojení. Poté se snaží oběti doručit nově nalezené + bloky rychleji než jiná, čestná spojení. Uzel oběti nato automaticky + přiřadí spojením kontrolovaným útočníkem veškeré sloty se širokým pásmem + pro [přeposílání kompaktních bloků][topic compact block relay]. + + Poté, co útočník získá kontrolu nad mnoha sloty uzlu oběti, začne používat + 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 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 + (tato těžařova asistence je potřebná pouze během útoků na implementace LN, + které monitorují mempool). Tento blok (nebo jiný vytvořený tímto těžařem) + též nárokuje platbu uvolněním předobrazu [HTLC][topic htlc]. V běžné situaci + by bitcoinový uzel oběti tento blok viděl, poskytl by jej LN uzlu a LN uzel by + předobraz extrahoval. Díky tomu by mohl částku platby nárokovat a udržet + tak přeposílání v rovnováze. + + V tomto případě však útočník zneužije této odhalené chyby, kvůli které + se uzel s Bitcoin Core o bloku obsahujícím předobraz nedozví. Starší verze + Bitcoin Core byly ochotné čekat až deset minut na doručení oznámeného bloku od + jednoho spojení, než si ho vyžádaly od spojení jiného. Jelikož je průměrná doba + mezi dvěma bloky deset minut, mohl by útočník kontrolující _x_ spojení pozdržet + uzel od obdržení bloku zhruba po dobu odpovídající _x_ blokům. Pokud musí + být přeposílaná platba nárokovaná během 40 bloků, má útočník kontrolující + 50 spojení nemalou možnost, že se mu podaří zabránit uzlu spatřit blok + s předobrazem. Pokud by se tak stalo, útočníkův odesílající uzel by neplatil + nic a útočníkův přijímající uzel by obdržel částku extrahovanou od uzlu + oběti. + + 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 #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 + zahájil diskuzi o bezpečném [otevírání 0-conf kanálů][topic zero-conf + channels], jakmile začnou být používána navrhovaná [pravidla přeposílání + transakcí verze 3][topic v3 transaction relay]. 0-conf kanály jsou nové + kanály financované jednou stranou, kde zakládající strana věnuje část + nebo všechny počáteční prostředky straně druhé. Tyto prostředky nejsou + zabezpečené, dokud otevírající transakce neobdrží dostatečné množství + konfirmací, avšak útrata těchto prostředků přes zakládající stranu + nepřináší příjemci kanálu žádné riziko. Původní návrh pravidel přeposílání + transakcí verze 3 umožňoval, aby měla nepotvrzená v3 transakce v mempoolu + maximálně jednoho potomka. Očekávalo se, že by tento jediný potomek + v případě potřeby navýšil rodičovské transakci poplatek pomocí [CPFP][topic + cpfp]. + + Tato pravidla nejsou v souladu s možností obou stran 0-conf kanálů navýšit + poplatek: zakládající transakce, která kanál vytváří, je rodičem v3 transakce, + která kanál zavírá, a prarodičem v3 transakce pro navýšení poplatku. + Jelikož v3 pravidla povolují pouze jednoho rodiče a jednoho potomka, neexistuje + způsob navýšení poplatku zakládající transakce, aniž by byl změněn způsob, + kterým je tvořena. Bastien Teinturier [poznamenává][teinturier splice], + že [splicing][topic splicing] trpí podobným problémem. + + V době psaní zpravodaje se hlavním řešením zdá býti přidat extra výstup + pro CPFP navyšování nyní, počkat, až bude [cluster mempool][topic cluster + mempool] shovívavější i vůči jiným topologiím (tedy více než jeden + rodič a jeden potomek), a potom opět extra výstup zahodit. + +- **Požadavky na ověření, že vstupy v protokolech citlivých na poddajnost txid používají segwit:** + Bastien Teinturier zaslal do fóra Delving Bitcoin [příspěvek][teinturier segwit] + s popisem snadno přehlédnutelného požadavku na protokoly, ve kterých třetí strana + přispívá vstupem transakce, aby se nemohlo změnit txid poté, co jiný uživatel + transakci podepíše. Například během [otevření LN kanálu s oboustranným + financováním][topic dual funding] mohou Alice i Bob přispět vstupem. + Aby zajistili, že každý z nich obdrží refundaci, pokud by druhá strana později + přestala spolupracovat, vytvoří a podepíší utracení financující transakce, + které prozatím ponechají offchain. Poté, co oba refundovací transakci podepíší, + mohou bezpečně podepsat a zveřejnit rodičovskou, financující transakci. + Jelikož závisí potomek (refundovací transakce) na txid rodiče (financující + transakce), je tento process bezpečný pouze, pokud není možné txid změnit. + + Segwit brání poddajnosti txid jen, pokud všechny vstupy transakce utrácejí + segwitové výstupy předchozích transakcí. Segwit v0 nabízí Alici pouze jednu + možnost, jak zaručit, že Bob utrácí segwitový výstup: Bob musí Alici + poskytnout celou předchozí transakci. Pokud by Alice Bobův vstup neověřila, + mohl by Bob o utrácení segwitového výstupu lhát a namísto toho utrácet + zastaralý výstup, který by mu umožnil pozměnit txid. Tím by mohl zneplatnit + refundovací transakcí a odmítat vrátit Alici prostředky, dokud by nesouhlasila + s platbou výkupného. + + U segwitu v1 ([taproot][topic taproot]) je každý `SIGHASH_ALL` podpis zavázán + všem předchozím utráceným výstupům (viz [zpravodaj č. 97][news97 spk], _angl._), + Alice tedy může od Boba vyžadovat odhalení jeho scriptPubKey (které by se stejně + dozvěděla z jiných informací, které jí Bob musí sdělit, aby mohli vytvořit + sdílenou transakci). Alice ověří, že scriptPubKey používá segwit (v0 nebo v1) a + zaváže mu svůj podpis. Nyní, pokud by Bob lhal a ve skutečnosti přispěl + nesegwitovým výstupem, závazek Alicina podpisu by nebyl platný, a tedy podpis + by nebyl validní, financující transakce by se nepotvrdila a nebyla by žádná + potřeba refundace. + + To vede ke dvěma pravidlům, kterými se pro zajištění bezpečnosti musí protokoly + závisející na předem podepsaných refundacích řídit: + + 1. Pokud přispíváte vstupem, upřednostňujte vstup, který utrácí segwit v1 + výstup, získejte předchozí výstupy všech ostatních vstupů v transakci, + ověřte, že všechny používají segwitové scriptPubKey a zavažte vůči nim + svůj podpis. + + 2. Pokud nepřispíváte vstupem nebo neutrácíte segwitový v1 výstup, získejte + kompletní předchozí transakce všech vstupů, ověřte, že všechny výstupy + utrácené v této transakci jsou segwitové výstupy a zavažte vůči těmto + transakcím svůj podpis. Tuto možnost lze aplikovat ve všech případech, + avšak v nejhorším případě spotřebuje až téměř 20 000× více šířky + pásma než první možnost. + +- **Návrh na nahrazování jednotkovým poplatkem jako řešení pinningu:** Peter Todd + zaslal do emailové skupiny Bitcoin-Dev [příspěvek][todd rbfr] s návrhem na + skupinu pravidel [nahrazování transakcí][topic rbf], která by mohla být + použita, i když stávající pravidla nahrazování poplatkem (RBF) nahrazení transakce + nepovolují. Jeho návrh obsahuje dvě varianty: + + - *Ryzí nahrazení jednotkovým poplatkem („pure replace by feerate“, „pure RBFr”):* + transakce v mempoolu může být nahrazena konfliktní transakcí, která platí + výrazně vyšší jednotkový poplatek (například dvojnásobně vyšší). + + - *Jednorázové nahrazení jednotkovým poplatkem („one-shot replace by feerate”, „one-shot RBFr”):* + transakce v mempoolu může být nahrazena konfliktní transakcí, která platí + mírně vyšší jednotkový poplatek (např. 1,25×), pokud by byl jednotkový + poplatek nahrazující transakce dostatečně vysoký na zařazení mezi + nejvyšších 1 000 000 vbyte mempoolu (tedy nahrazovaná transakce by + byla vytěžena, pokud by byl blok nalezen ihned po přijetí transakce). + + Mark Erhardt popsal ([1][erhardt rbfr1], [2][erhardt rbfr2]), jak by mohla být + tato navrhovaná pravidla zneužita k plýtvání nekonečného množství šířky + pásma uzlu s minimálními náklady pro útočníka. Peter Todd pravidla upravil, + aby tuto konkrétní možnost zneužití eliminoval, ale Gregory Sanders a + Gloria Zhao nadnesli ve [vlákně fóra][sz rbfr] další obavy: + + - „Přemýšlet o tomto před cluster mempoolem je hodně těžké. Peterova + první iterace této myšlenky byla rozbitá, protože umožňovala neomezené + přeposílání zdarma. Tvrdí, že to opravil přidáním dalších RBF restrikcí, + ale jako obvykle je velmi náročné o současných pravidlech uvažovat, + možná i nemožné. Myslím, že by se úsilí mělo raději soustředit na + nastavení správných incentiv pro RBF než na kompletní zahození + ochrany proti přeposílání grátis.” ---Sanders + + - „Mempool v současnosti kvůli neomezené velikosti clusteru nepodporuje + efektivní způsob výpočtu ‚těžařova skóre’ nebo souladu ekonomických podnětů. + […] Jednou z výhod cluster mempoolu je možnost spočítat věci jako + těžařovo skóre a soulad ekonomických podnětů napříč mempoolem. Podobně + je jednou z výhod v3 možnost to díky omezené topologii dělat i před cluster + mempoolem. Dřív, než lidé začali navrhovat a implementovat cluster mempool, + hovořila jsem o v3 jako o ‚cluster limitech’ bez nutnosti cluster limity + implementovat, protože je to jedna z mála možností, jak kodifikovat + cluster limit (počet=2) pomocí stávajících limitů balíčků (předkové=2, + potomci=2. Při navýšení na 3 bychom opět měli neomezené clustery). Další + výhodou v3 je, že může pomoci odblokovat cluster mempool, což je podle + mého názoru bez debat. Abych to shrnula, nemyslím si, že návrh na + One-Shot Replace by Feerate funguje (tj. netrpí problémem přeposílání + zdarma) a je možné ho přesně implementovat.” + ---Zhao + + V době psaní nedosáhly diskuze urovnání. Peter Todd uvolnil experimentální + [implementaci][libre relay] pravidel nahrazování jednotkovým poplatkem. + +- **Aktualizace migrace emailové skupiny Bitcoin-Dev:** v době psaní již emailová + skupina Bitcoin-Dev přestala akceptovat nové příspěvky v rámci migrace k jinému + provozovateli skupiny (viz [zpravodaj č. 276][news276 ml]). Až bude migrace + dokončena, poskytneme další aktualizaci. + +## 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.4-beta][] je údržbovým vydáním této oblíbené implementace LN + uzlu. Jeho poznámky k vydání uvádějí: „jedná se o opravné vydání, které + opravuje několik chyb: otevírání kanálu uvízlé až do restartu, únik paměti + při použití dotazovacího režimu pro `bitcoind`, ztracená synchronizace + s ořezanými uzly a REST proxy nefungující se zapnutým šifrováním s TLS + certifikáty.” + +## 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 #29189][] zastarává libconsensus. Libconsensus byl pokus sdílet + logiku konsenzu Bitcoin Core s jiným software. Avšak knihovna se nesetkala + s významným použitím a začala být během udržování Bitcoin Core přítěží. + Plán je „nemigrovat ji na CMake a ukončit ji s v27. V budoucnosti by měla + všechny zbývající případy použití zvládnout knihovna [libbitcoinkernel][].” + +- [Bitcoin Core #28956][] odstraňuje z Bitcoin Core čas upravený dle sítě a varuje + uživatele, pokud není čas jejich počítače v souladu se zbytkem sítě. Čas + upravený dle sítě („adjusted time”) byla automatická úprava času místního + uzlu založená na času jeho spojení. To mohlo pomoci uzlu s mírně nepřesnými + hodinami se o problému dozvědět a předejít tak zbytečnému odmítání bloků a dát + produkovaným blokům přesnější čas. Avšak upravený čas vedl v minulosti k některým + problémům a v současné síti neposkytuje žádné významné výhody. Tímto PR + jsme se zabývali ve [zpravodaji č. 284][news284 adjtime]. + +- [Bitcoin Core #29347][] ve výchozím stavu zapíná [P2P přenos verze 2][topic v2 p2p + transport]. Nová spojení mezi dvěma uzly podporujícími v2 protokol budou používat + šifrování. + +- [Core Lightning #6985][] přidává do `hsmtool` volbu, která mu umožní vrátit + soukromé klíče pro onchain peněženku. Ty mohou být nato importovány do jiné + peněženky. + +- [Core Lightning #6904][] přináší několik aktualizací kódu správy spojení + a gossip zpráv. Viditelnou změnou je přidání pole, které ukazuje, kdy mělo + nějaké spojení stabilní připojení k místnímu uzlu na více než minutu. Díky + tomu mohou být nestabilní spojení ukončena. + +- [Core Lightning #7022][] odstraňuje z testovací infrastruktury `lnprototest`. + [Zpravodaj č. 145][news145 lnproto] (_angl._) popisuje jeho přidání. + +- [Core Lightning #6936][] přidává infrastrukturu napomáhající se zastaráváním + funkcí CLN. Funkce jsou nyní v kódu zastarávány automatickou deaktivací ve + výchozím nastavení dle verze programu. Uživatelé mohou funkci aktivovat + i po této verzi, dokud kód funkce stále existuje. Zabraňuje to občasným + problémům, kdy byla funkce CLN označena za zastaralou, ale ve výchozím + nastavení nadále po dlouhou dobu fungovala i po plánovaném odstranění. + Kvůli tomu mohli na funkci uživatelé nadále záviset a tím tak reálné odstranění + ztížit. + +- [LND #8345][] počíná před samotným zveřejněním testovat, zda bude transakce + pravděpodobně rozeslána. Používá k tomu volání `testmempoolaccept`, pokud + je dostupné. To umožní uzlu odhalit případné problémy s transakcí dříve, než + je cokoliv odesláno třetím stranám, urychlit odhalení problémů a omezit + jejich dopady. Varianty volání `testmempoolaccept` jsou dostupné v Bitcoin + Core, jeho nejnovějších odnožích a v btcd. + +{% assign day_after_posting = page.date | date: "%s" | plus: 86400 | date: "%Y-%m-%d 15:00" %} +{% include snippets/recap-ad.md when=day_after_posting %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="29189,28956,29347,6985,6904,7022,6936,7022,6936,8345,22144,22147" %} +[news154 stall]: /en/newsletters/2021/06/23/#bitcoin-core-22144 +[news145 lnproto]: /en/newsletters/2021/04/21/#c-lightning-4444 +[siegel stall]: https://delvingbitcoin.org/t/block-stalling-issue-in-core-prior-to-v22-0/499/ +[corallo 0conf]: https://delvingbitcoin.org/t/0conf-ln-channels-and-v3-anchors/494/ +[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://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 +[news284 adjtime]: /cs/newsletters/2024/01/10/#bitcoin-core-pr-review-club +[news276 ml]: /cs/newsletters/2023/11/08/#hosting-emailove-skupiny +[lnd v0.17.4-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.17.4-beta diff --git a/_posts/cs/newsletters/2024-02-14-newsletter.md b/_posts/cs/newsletters/2024-02-14-newsletter.md new file mode 100644 index 0000000000..c4aece878d --- /dev/null +++ b/_posts/cs/newsletters/2024-02-14-newsletter.md @@ -0,0 +1,273 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 289' +permalink: /cs/newsletters/2024/02/14/ +name: 2024-02-14-newsletter-cs +slug: 2024-02-14-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Tento týden přinášíme souhrn nápadů na zlepšení přeposílání po nasazení +cluster mempoolu, popisujeme výsledky výzkumu topologií a velikostí anchor +výstupů ve stylu LN v roce 2023, oznamujeme nového hostitele emailové +skupiny Bitcoin-Dev a nabádáme čtenáře k poděkování vývojářům svobodného +software v rámci oslav I Love Free Software Day. Též nechybí naše pravidelné +rubriky se souhrnem sezení Bitcoin Core PR Review Clubu a popisem významných +změn v populárním bitcoinovém páteřním software. + +## Novinky + +- **Nápady na vylepšení přeposílání po nasazení cluster mempoolu:** + Gregory Sanders zaslal do fóra Delving Bitcoin [příspěvek][sanders future] + s několika nápady, které by po úplné implementaci, otestování a nasazení [cluster + mempoolu][topic cluster mempool] umožnily jednotlivým transakcím se volitelně + řídit jistými pravidly mempoolu. Tato vylepšení staví na [přeposílání transakcí + verze 3][topic v3 transaction relay] uvolněním některých pravidel, která již + nejsou potřebná, a přidáním požadavku, aby transakce (či [balíček][topic package relay] + transakcí) platily jednotkové poplatky, díky kterým by pravděpodobně byly + vytěžené během jednoho či dvou následujících bloků. + +- **Co by se bývalo stalo, kdyby byla v3 sémantika aplikována na anchor výstupy před rokem?** + Suhas Daftuar zaslal do fóra Delving Bitcoin [příspěvek][daftuar retrospective], + ve kterém popsal svůj výzkum myšlenky na automaticky aplikovaná [pravidla přeposílání + transakcí verze 3][topic v3 transaction relay] na LN commitmenty ve stylu [anchor výstupů][topic + anchor outputs] a transakce navyšující poplatky (viz [zpravodaj č. 286][news286 imbued], + který popisuje návrh na _vštípenou v3 logiku_, na které je tato myšlenka založena). + V krátkosti: v roce 2023 zaznamenal 14 124 transakcí, které vypadaly + jako útraty anchorů. Z nich: + + - Kolem 94 % by bylo úspěšných s aplikovanými pravidly v3. + + - Kolem 2,1 % mělo více než jednoho rodiče (např. pokusy o dávkové CPFP). + Některé LN peněženky tak činí pro účinnější zavírání více než jednoho kanálu + během krátké doby. Toto chování by musely ukončit, pokud by výstupům + ve stylu anchorů měly být vštípeny vlastnosti v3. + + - Kolem 1,8 % nebylo prvním potokem svého rodiče. Díky návrhu na vštípenou v3 + 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 + 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 + v3. + + - Kolem 1,2 % nebylo nikdy vytěženo a nebylo dále ani analyzováno. + + - Kolem 0,1 % utrácelo nesouvisející nepotvrzený výstup, načež mělo utracení + anchoru více než jednoho rodiče. Vývojář Bastien Teinturier míní, že toto + mohlo být chování Eclairu a poznamenává, že Eclair by tuto situaci automaticky + vyřešil i se současným kódem. + + - Méně než 0,1 % bylo větších než 1 000 vbyte. I toto chování by LN peněženky + musely změnit. Daftuarovo následné bádání ukázalo, že téměř všechna utracení + anchorů měla méně než 500 vbyte, z čehož vyplývá, že maximální velikost ve + verzi 3 by mohla být ještě snížena. Díky tomu by bylo levnější přenést se přes + [pinningový útok][topic transaction pinning] proti utráceným anchorům, ale + také by to zabránilo LN peněženkám v možnosti používat na poplatky více než + několik málo UTXO. Teinturier [poznamenal][teinturier better], že „je velmi + lákavé snížit tuto 1 000vbyte hodnotu, ale data ukazují pouze čestné + pokusy (s malým počtem čekajících HTLC), jelikož jsme zatím ještě neviděli + žádný rozsáhlý útok na síť. Je tedy těžké vymyslet, jaká hodnota by byla ‚lepší’.“ + + I když se očekává další diskuze a výzkumy vztažené k tomuto tématu, měli jsme + z výsledků pocit, že než bude moci Bitcoin Core bezpečně nakládat s útratami + anchor výstupů jako s v3 transakcemi, budou muset LN peněženky učinit několik změn, + aby byly lépe v souladu s v3 pravidly. + +- **Přesun emailové skupiny Bitcoin-Dev:** emailová skupina pro diskuze okolo + vývoje protokolu je nyní hostována na novém serveru s novou emailovou adresou. + Každý, kdo si přeje pokračovat v přijímání příspěvků, se musí znovu zaregistrovat. + [Email][migration email] napsaný Bryanem Bishopem obsahuje další podrobnosti. + Zpravodaje [č. 276][news276 ml] a [č. 288][news288 ml] přinesly popis diskuzí + o migraci. + +- **I Love Free Software Day:** každý rok 14. února nabádají organizace jako + [FSF][] a [FSFE][] uživatele svobodného a open source software (FOSS), aby + „kontaktovali a poděkovali všem lidem, kteří spravují a přispívají do + svobodného software.” I pokud čtete toto vydání zpravodaje po 14. únoru, + snažte se nalézt chvilku a poslat poděkování některým svým oblíbeným + přispěvatelům do bitcoinových FOSS projektů. + +## 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 `submitpackage` argumenty `maxfeerate` a `maxburnamount`][review club 28950] +je PR Grega Sanderse (instagibbs na GitHubu), které do RPC volání `submitpackage` +přidává funkcionalitu již obsaženou v RPC pro jednotlivé transakce +`sendrawtransaction` a `testmempoolaccept`. PR je součástí rozsáhlejšího +projektu [přeposílání balíčků][topic package relay]. Konkrétně toto PR +umožní odesílateli balíčku specifikovat argumenty (zmíněné v titulku), +které zajistí provedení hrubé kontroly transakcí v balíčku a předejdou +tak nezamýšlené ztrátě prostředků. Sezení klubu vedl Abubakar Sadiq Ismail +(ismaelsadeeq na GitHubu). + +{% include functions/details-list.md + q0="Proč je důležité provádět tyto kontroly odesílaných balíčků?" + a0="Pomáhají uživatelům zajistit, aby měly transakce v rámci odesílaných + balíčků stejné garance jako jednotlivé odesílané transakce." + a0link="https://bitcoincore.reviews/28950#l-27" + + q1="Existují vedle `maxburnamount` a `maxfeerate` i jiné důležité kontroly, + které by měly být nad balíčky vykonány před akceptováním do mempoolu?" + a1="Ano, dvěma příklady jsou kontrola bázového poplatku a maximální + velikost standardní transakce. Tyto kontroly jsou na nízké úrovni, + mohou být provedeny časně a rychle balíček odmítnout." + a1link="https://bitcoincore.reviews/28950#l-33" + + q2="Volby `maxburnamount` a `maxfeerate` mohou transakci zabránit + od vstupu do mempoolu a přeposílání. Můžeme tyto volby považovat + za pravidla mempoolu? Proč ano a proč ne?" + a2="Jedná se o pravidla; tyto kontroly nejsou aplikovány na transakce + ve vytěžených blocích, nejedná se tedy o konsenzus. Dokonce ani + neovlivňují přeposílání transakcí od spojení, pouze transakce + odeslané lokálně přes RPC." + a2link="https://bitcoincore.reviews/28950#l-47" + + q3="Proč validujeme maximální jednotkový poplatek proti modifikovanému + jednotkovému poplatku namísto bázového jednotkového poplatku?" + a3="(Minulá sezení klubu [24152][review club 24152], + [24538][review club 24538] a [27501][review club 27501] + se zabývala konceptem modifikovaných a bázových poplatků.) + Většina účastníků se domnívala, že by měl být používán bázový poplatek + namísto modifikovaného, neboť `sendrawtransaction` i `testmempoolaccept` + používají ve svých kontrolách bázový poplatek. Zdálo by se to + více konzistentní. Jelikož je `prioritisetransaction` (díky kterému + jsou bázové a modifikované poplatky odlišné) obecně používán pouze + těžaři, neznamená v praxi volba poplatku výrazný rozdíl." + a3link="https://bitcoincore.reviews/28950#l-69" + + q4="Maximální jednotkový poplatek validujeme proti modifikovanému + jednotkovému poplatku jednotlivých transakcí v balíčku a ne proti + jednotkovému poplatku balíčku. Kdy to může přinést nepřesnosti?" + a4="Když je potomek v balíčku odmítnut, protože jeho modifikovaný + jednotkový poplatek přesahuje `maxfeerate`, ale ne v případě + kontroly celého balíčku." + a4link="https://bitcoincore.reviews/28950#l-84" + + q5="Vzhledem k této možné nepřesnosti, proč raději nekontrolovat + `maxfeerate` proti jednotkovému poplatku balíčku?" + a5="Protože to může způsobit jinou nepřesnost. Předpokládejme, že má + transakce A nulový poplatek a B ho pomocí CPFP navýší. + A i B jsou fyzicky velké, takže ani jedna z nich nepřevýší + `maxfeerate`. Ale nyní je přidána C, která má vysoký jednotkový + poplatek a utrácí z A i B. (Tato topologie balíčku je povolená, + neboť má jen dvě úrovně, i když bylo ukázáno, že volání + `submitpackage` tuto topologii nedovoluje.) V tomto případě + by transakce C byla akceptována, protože A a B absorbují část jejích + poplatků. C by však měla být odmítnuta." + a5link="https://bitcoincore.reviews/28950#l-108" + + q6="Proč nemůže být `maxfeerate` zkontrolován ihned po dekódování stejně jako + `maxburnamount`?" + a6="Protože, jak známo, vstup transakce nestanoví hodnotu vstupu. Ta je + známa až po vyhledání rodičovského výstupu. Jednotkový poplatek vyžaduje, + aby byl znám poplatek, což vyžaduje znalost hodnoty vstupu." + a6link="https://bitcoincore.reviews/28950#l-141" + + q7="Jak se liší kontrola `maxfeerate` ve volání `testmempoolaccept`od + volání `submitpackage`? Proč nemůžou být stejné?" + a7="`submitpackage` používá modifikované poplatky, zatímco `testmempoolaccept` + používá bázové poplatky, jak bylo vysvětleno výše. Dále je + kontrola jednotkového poplatku provedena po zpracování balíčku + v rámci `testaccept`, protože transakce nejsou po zpracování přidány + do mempoolu a zveřejněny. Můžeme tedy bezpečně zkontrolovat `maxfeerate` + a vrátit vhodnou chybovou zprávu. To stejné nelze učinit v `submitpackage`, + protože transakce balíčku již mohly být do mempoolu přijaty a odeslány + dalším uzlům. Kontrola by byla nadbytečná." + a7link="https://bitcoincore.reviews/28950#l-153" +%} + +## 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 #28948][] přidává podporu (ale neaktivuje) pro [přeposílání + transakcí verze 3][topic v3 transaction relay]. Umožní tím kterékoliv + v3 transakci mající nepotvrzeného rodiče vstoupit do mempoolu dle + běžných pravidel přijetí transakce. Tato v3 transakce může mít poplatek + navýšen pomocí [CPFP][topic cpfp], avšak pouze pokud má potomek + 1 000 vbyte nebo méně. Každý v3 rodič může mít v mempoolu pouze jediného + nepotvrzeného potomka a každý potomek může mít pouze jednoho nepotvrzeného + rodiče. Obě transakce mohou být kdykoliv [nahrazeny poplatkem][topic rbf] (RBF). + Pravidla se dotýkají pouze pravidel přeposílání Bitcoin Core. Na úrovni + konsenzu jsou v3 transakce validovány stejným způsobem jako transakce verze 2 + dle definice v [BIP68][]. Nová pravidla mají za cíl pomoci protokolům + používajícím kontrakty (jako je LN) zajistit, aby mohly být jejich předem + připravené transakce rychle potvrzeny s minimálními dodatečnými poplatky + na vymanění se z [pinningových útoků][topic transaction pinning]. + +- [Core Lightning #6785][] bude ve výchozím stavu v bitcoinové síti vytvářet + kanály ve stylu [anchorů][topic anchor outputs]. Neanchorové kanály budou + nadále používány pro kanály v Elements [sidechainech][topic sidechains]. + +- [Eclair #2818][] maximalizuje počet vstupů, o kterých se peněženka Eclair + domnívá, že je může bezpečně utratit. Činí tak odhalováním některých případů, + ve kterých je velmi nepravděpodobné, že by existující nepotvrzená transakce + dosáhla potvrzení. Eclair používá pro správu UTXO pro onchain platby a navyšování + poplatků transakcí peněženku Bitcoin Core. Je-li UTXO pod kontrolou této peněženky + použito jako vstup nějaké transakce, peněženka Bitcoin Core nepovolí vytváření + dalších nesouvisejících transakcí s tímto vstupem. Pokud však tuto transakci + nelze utratit kvůli dvojímu utracení jiného vstupu, povolí peněženka Bitcoin Core + jiné utracení tohoto vstupu v rámci jiné transakce. Avšak pokud rodiče + této transakce nelze utratit kvůli jiné potvrzené verzi, peněženka Bitcoin Core + nepovolí automaticky nové utracení tohoto UTXO. Eclair může nezávisle dvojí utracení + rodičovské transakce detekovat a instruovat peněženku Bitcoin Core, aby + dřívější pokus o alokaci UTXO [anulovala][rpc abandontransaction] a umožnila + jej znovu utratit. + +- [Eclair #2816][] umožňuje provozovateli uzlu zvolit maximální částku, kterou + je pro potvrzení commitment transakce ochoten utratit na [anchor výstupu][topic + anchor outputs]. Dříve Eclair utrácel až pět procent hodnoty kanálu, což + může být pro některé hodnotné kanály příliš vysoká částka. Nový výchozím nastavením + je nejvyšší jednotkový poplatek navržený odhadcem jednotkového poplatku až + do maximální výše 10 000 sat. Eclair bude i nadále platit částku rovnající + se až hodnotám [HTLC][topic htlc], kterým se blíží doba expirace. Tato + částka může být vyšší než 10 000 sat. + +- [LND #8338][] přidává funkce pro nový protokol kooperativního zavírání + kanálů (viz [zpravodaj č. 261][news261 close] a [BOLTs #1096][]). + +- [LDK #2856][] upravuje implementaci [zaslepeného routování][topic rv routing], + aby zajistil, že má příjemce dostatečný blokový čas k nárokování platby. + Aktualizace je založena na změně specifikaci v [BOLTs #1131][]. + +- [LDK #2442][] přidává do `ChannelDetails` podrobnosti o každém [HTLC][topic htlc] + čekajícím na vyřízení. To umožní uživatelům API zjistit, jaký krok + je potřeba dále učinit k posunu HTLC blíže k přijetí nebo odmítnutí. + +- [Rust Bitcoin #2451][] odstraňuje požadavek, aby HD derivační cesta začínala + na `m`. V [BIP32][] je `m` použito jako proměnná představující hlavní („master”) + soukromý klíč. Při odkazování na pouhou derivační cestu je `m` nadbytečné + a může v některých případech být dokonce chybné. + +{% assign day_after_posting = page.date | date: "%s" | plus: 86400 | date: "%Y-%m-%d 15:00" %} +{% include snippets/recap-ad.md when=day_after_posting %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="28948,6785,2818,2816,8338,2856,2442,2451,1131,1096" %} +[fsfe]: https://fsfe.org/activities/ilovefs/index.en.html +[fsf]: https://www.fsf.org/blogs/community/i-love-free-software-day-is-here-share-your-love-software-and-a-video +[sanders future]: https://delvingbitcoin.org/t/v3-and-some-possible-futures/523 +[news261 close]: /cs/newsletters/2023/07/26/#jednodussi-zavirani-ln-kanalu +[teinturier better]: https://delvingbitcoin.org/t/v3-transaction-policy-for-anti-pinning/340/37 +[daftuar retrospective]: https://delvingbitcoin.org/t/analysis-of-attempting-to-imbue-ln-commitment-transaction-spends-with-v3-semantics/527/ +[news286 imbued]: /cs/newsletters/2024/01/24/#vstipena-v3-logika +[review club 28950]: https://bitcoincore.reviews/28950 +[review club 24152]: https://bitcoincore.reviews/24152 +[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://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-21-newsletter.md b/_posts/cs/newsletters/2024-02-21-newsletter.md new file mode 100644 index 0000000000..75aebdc14f --- /dev/null +++ b/_posts/cs/newsletters/2024-02-21-newsletter.md @@ -0,0 +1,296 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 290' +permalink: /cs/newsletters/2024/02/21/ +name: 2024-02-21-newsletter-cs +slug: 2024-02-21-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Zpravodaj tento týden popisuje návrh na poskytování čitelných bitcoinových +platebních instrukcí založených na DNS, shrnuje příspěvek s úvahou o +mempoolu a souladu ekonomických podnětů, odkazuje na vlákno s diskuzí +o designu Cashu a dalších ecashových systémů, krátce nahlíží na +pokračující diskuzi o 64bitové aritmetice v bitcoinových skriptech +(včetně specifikace již dříve navrženého opkódu) a poskytuje přehled +vylepšeného procesu reprodukovatelné tvorby ASMap. Též nechybí naše +pravidelné rubriky s popisem aktualizací klientů a služeb, nových +vydání a významných změn v populárních bitcoinových páteřních projektech. + +## Novinky + +- **Čitelné bitcoinové platební instrukce založené na DNS:** v návaznosti + na předchozí diskuzi (viz [zpravodaj č. 278][news278 dns]) zaslal Matt + Corallo do fóra Delving Bitcoin [příspěvek][corallo dns] s [návrhem BIPu][dns + bip], díky kterému bude možné přeložit řetězce jako `example@example.com` + na DNS adresu jako například `example.user._bitcoin-payment.example.com`, + která vrátí TXT záznam podepsaný [DNSSEC][] obsahující URI dle [BIP21][], + např. `bitcoin:bc1qexampleaddress0123456`. BIP21 URI mohou být + rozšířené o podporu několika protokolů (viz [BIP70 platební protokoly][topic + bip70 payment protocol]); například následující TXT záznam by určoval + [bech32m][topic bech32] adresu jako alternativu pro jednoduché onchain + peněženky, adresu [tiché platby][topic silent payments] pro onchain + peněženky s patřičnou podporou a LN [nabídku][topic offers] pro LN + peněženky: + + ```text + bitcoin:bc1qexampleaddress0123456?sp=sp1qexampleaddressforsilentpayments0123456&b12=lno1qexampleblindedpathforanoffer... + ``` + + Návrh BIPu neobsahuje podrobnosti ohledně podporovaných platebních protokolů. + Corallo má dva další návrhy: [BOLT][dns bolt] a [BLIP][dns BLIP] popisující + detaily pro LN uzly. BOLT umožňuje vlastníkovi domény nastavit wildcard + záznam jako `*.user._bitcoin-payment.example.com`, který se přeloží + na BIP21 URI s parametrem `omlookup` obsahujícím zaslepenou cestu k uzlu, + který po přijetí [onion zprávy][topic onion messages] vrátí BOLT12 nabídku. + Plátce, který by chtěl poslat nabídku na `example@example.com`, potom + tomuto uzlu předá identifikátor příjemce (`example`) a tím bude moci uzel + platbu řádně zpracovat. BLIP popisuje možnost, jak by mohl kterýkoliv LN + uzel bezpečně tyto platební instrukce přeložit pro kterýkoliv jiný + uzel pomocí komunikačního protokolu LN. + + V době psaní zpravodaje byla většina diskuze vedena pod [PR v BIP repozitáři][bips + #1551]. Jeden příspěvek navrhoval použít HTTPS, které může být pro + mnoho webových vývojářů přístupnější, ale vyžadovalo by dodatečné + závislosti; Corallo řekl, že tuto část specifikace měnit nebude, ale napsal + [malou knihovnu][dnssec-prover] s [ukázkovou webovou stránkou][dns demo], + která za webové vývojáře vše vyřeší. Další příspěvek navrhoval použít + existující systém překladu platebních adres založený na DNS [OpenAlias][], + který je již podporován některým bitcoinovým software, např. Electrum. + Dalším diskutovaným tématem byl způsob, jak adresy zobrazovat: mělo + by to být `example@example.com`, `@example@example.com`, `example$example.com` + či jinak? + +- **Úvaha o mempoolu a souladu ekonomických podnětů:** Suhas Daftuar + zaslal do fóra Delving Bitcoin [příspěvek][daftuar incentive] s několika + pohledy na kritéria, která za účelem maximalizace zisku mohou plné uzly + použít k výběru transakcí přidaných do svých mempoolů, přeposílaných dalším + uzlům a pro těžbu. Příspěvek začíná základními principy a pokračuje až + na hranici současného výzkumu. Přístupné popisy by měly být srozumitelné + každému, kdo se zajímá o design pravidel pro přeposílání transakcí. + Mezi postřehy, které jsou podle nás nejzajímavější, patří: + + - *Ryzí nahrazení jednotkovým poplatkem nezaručuje soulad ekonomických podnětů:* + zdá se, že [nahrazení][topic rbf] transakce platící nižší jednotkový + poplatek transakcí platící vyšší jednotkový poplatek by mělo být pro + pro těžaře vždy výhrou. Daftuar poskytuje jednoduchý [ilustrovaný + příklad][daftuar feerate rule] ukazující, že to tak nemusí vždy být. + [Zpravodaj č. 288][news288 rbfr] obsahuje předešlou diskuzi o ryzím + nahrazení jednotkovým poplatkem. + + - *Těžaři s různými hashrate mají různé priority:* těžař s 1 % hashrate + celé sítě, který se vzdá začlenění konkrétní transakce do své šablony + bloku a kterému se podaří nalézt blok, bude mít pouze 1% šanci na vytěžení + následného bloku, který by mohl tuto transakci začlenit. Proto má + malý těžař silný podnět k výběru co nejvyššího poplatky nyní, i za cenu + výrazné redukce výše poplatku dostupného těžařům (i sobě samému) v budoucích + blocích. + + V porovnání s ním bude mít těžař s 25 % hashrate, který se rozhodne + nezačlenit transakci do bloku, 25% šanci na vytěžení následného + bloku, který by mohl tuto transakci obsahovat. Pro tohoto velkého + těžaře je výhodné odložit výběr některých poplatků na později, kdy + mu to může s určitou pravděpodobností vynést vyšší poplatky. + + Daftuar nabízí [příklad][daftuar incompatible] dvou konfliktních + transakcí. Menší transakce platí vyšší jednotkový poplatek, větší + transakce platí vyšší absolutní poplatek. Pokud by nebylo v mempoolu + mnoho transakcí s jednotkovým poplatkem podobným větší transakci, + blok obsahující tuto transakci by přinesl těžařovi více na poplatcích + než blok s menší transakcí (s vyšším jednotkovým poplatkem). Avšak + pokud by bylo v mempoolu mnoho transakcí s podobným jednotkovým + poplatkem, jako má větší transakce, pro těžaře s menším podílem na celkovém + hashrate může být výhodnější vytěžit menší transakci (vyšší jednotkový + poplatek), aby získal co nejvíce na poplatcích nyní, zatímco těžař + s větším podílem na celkovém hashrate může být motivován vyčkat, + až bude výdělečné vytěžit větší transakci (nižší jednotkový poplatek) + nebo až se odesílatel unaví čekáním a vytvoří verzi s ještě vyšším + jednotkovým poplatkem. Odlišné podněty pro různé těžaře mohou + indikovat, že neexistuje jeden univerzální soubor pravidel pro + soulad ekonomických podnětů. + + - *Bylo by užitečné nalézt pravidla souladu ekonomických podnětů, která nejsou odolná vůči DoS:* + Daftuar popisuje, jak se Bitcoin Core snaží [implementovat][mempool series] + pravidla, která jsou v souladu s ekonomickými podněty a zároveň + jsou odolná vůči útokům odepření služby (DoS). Avšak poznamenává, že + „zajímavou a hodnotnou oblastí výzkumu by bylo určit, zda-li existují + (a pokud ano, charakterizovat je) chování v souladu s ekonomickým podněty, + která nejsou odolná vůči DoS. Pokud existují, mohla by taková + chování představovat podněty pro uživatele, aby se připojovali + přímo k těžařům, což by mohlo být pro tyto strany vzájemně výhodné, + ale celkově škodlivé pro decentralizaci těžby. […] Porozumění těmto + scénářům by nám také mohlo pomoci během navrhování protokolů, které + jsou odolné vůči DoS, jelikož bychom znali hranice možného.” + +- **Diskuze o designu Cashu a dalších ecash systemů:** před několika týdny + zaslal vývojář Thunderbiscuit do fóra Delving Bitcoin [příspěvek][thunderbiscuit + ecash] s popisem [schématu zaslepených podpisů][blind signature scheme] + stojícího za [chaumovským][Chaumian ecash] ecash systémem použitým + v [Cashu][]. Tento systém používá satoshi jako jednotku zůstatků a + umožňuje odesílat a přijímat peníze pomocí bitcoinu a LN. Vývojáři + Moonsettler a Zmnscpxj tento týden ve svých odpovědích uvedli některá + omezení této jednoduché verze zaslepeného podepisování a popsali, + jak by alternativní protokoly mohly přinést další výhody. Diskuze + se vedla zcela v teoretické úrovni, ale věříme, že by mohla být + zajímavá pro každého se zájmem o ecashové systémy. + +- **Pokračující diskuze o 64bitové aritmetice a opkódu `OP_INOUT_AMOUNT`:** + několik vývojářů [pokračovalo v diskuzu][64bit discuss] o potenciálním + budoucím soft forku, který by mohl do bitcoinu přidat 64bitové aritmetické + operace (viz [zpravodaj č. 285][news285 64bit]). Většina diskuze se po naší + předchozí zmínce soustředila na kódování 64bitových hodnot ve skriptech. + Hlavním rozdílem je, zda používat formát minimalizující onchain data nebo + formát co nejjednodušší pro programování. Dále se diskutovalo, zda používat + celá čísla se znaménkem nebo povolit pouze celá čísla bez znaménka (pro neznalé, + mezi které evidentně patří také jeden samozvaný brilantní bitcoinový inovátor: + celá čísla se znaménkem indikují, jaké znaménko používají (kladné/záporné); + celá čísla bez znaménka mohou být pouze kladná čísla nebo nula). Dále + bylo uvažováno, zda umožnit pracovat s většími čísly, potenciálně až + 4160bitovými (což odpovídá 520 bytům, tedy současné maximální velikosti + prvku bitcoinového zásobníku). + + Tento týden vytvořil Chris Stewart nové [vlákno][stewart inout] + [s návrhem BIPu][bip inout] pro opkód původně navržený jako + součást `OP_TAPLEAF_UPDATE_VERIFY` (viz [zpravodaj č. 166][news166 tluv], + _angl._). Tento opkód `OP_INOUT_AMOUNT` přidá do zásobníku hodnotu + aktuálního vstupu (což je hodnota výstupu, který utrácí) a hodnotu výstupu, + který má stejný index jako tento vstup. Například má-li v transakci + první vstup hodnotu 4 milióny sat, druhý vstup 3 milióny sat, první + výstup platí 2 milióny sat a druhý výstup 1 milión sat, potom by + `OP_INOUT_AMOUNT` spuštěn během vykonávání druhého vstupu přidal do + zásobníku `3_000_000 1_000_000`. (Pokud chápeme návrh BIPu správně, + bylo by to kódováno jako 64bitové celé číslo bez znaménka v little endian, + tedy `0xc0c62d0000000000 0x40420f0000000000`). Pokud by byl opkód do bitcoinu + přidán, výrazně by kontraktům usnadnil ověřování očekávaného rozsahu částek + vstupů a výstupů, např. že uživatel vybral z [joinpoolu][topic joinpools] + pouze částku, na kterou měl nárok. + +- **Vylepšený proces opakovatelného sestavování ASMap:** Fabian Jahr + zaslal do fóra Delving Bitcoin [příspěvek][jahr asmap] o vývoji ve vytváření mapy [autonomních + systémů][autonomous systems] (ASMap, „map of autonomous systems”), + které kontrolují routování po rozsáhlých částech internetu. Bitcoin Core + se v současnosti pokouší udržovat spojení do různorodých podsítí globálního + jmenného prostoru. Aby mohl útočník provést i ten nejjednodušší druh [útoku + zastíněním][topic eclipse attacks] („eclipse attack”), potřeboval by získat + IP adresy ve všech podsítích. Avšak někteří poskytovatelé internetového + připojení (ISP) a hostingové služby kontrolují IP adresy ve více podsítích, + což tuto ochranu oslabuje. Projekt ASmap má za cíl poskytovat přímo v Bitcoin + Core přibližné informace o tom, který ISP kontroluje které IP adresy + (viz zpravodaje [č. 52][news52 asmap] a [č. 83][news83 asmap], _angl._). + Náročným úkolem je umožnit vícero přispěvatelům opakovatelně tuto mapu vytvořit, + díky čemuž by bylo možné nezávisle ověřit přesnost obsahu mapy v době jejího + vytvoření. + + Jahr tento týden ve svém příspěvku popisuje nástroje a techniky, které podle + jeho slov „nabízejí dobrou šanci, že ve skupině s pěti nebo více členy dojde + většina účastníků ke stejnému výsledku. […] Kdokoliv může tento proces zahájit, + podobně jako Core PR. Účastníci se stejným výsledkem mohou být počítáni jako + ACK. Pokud někdo spatří ve výsledcích něco divného nebo zkrátka nenalezne shodu, + může požádat o sdílení surových dat a hledat příčiny.” + + Pokud by se tento proces setkal s přijetím (po případných úpravách), mohly by + být budoucí verze Bitcoin Core dodávány s ASMapami a tato funkce by mohla + být ve výchozím nastavení zapnuta. Díky tomu by se zvýšila odolnost vůči + útokům zastíněním. + +## 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ášen protokol NWC pro koordinaci více stran:** + [Nostr Wallet Connect (NWC)][nwc blog] je koordinační protokol zprostředkující + komunikaci v interaktivních scénářích s účastní několik stran. Ačkoliv se NWC + zpočátku soustředí na LN, mohl by tento protokol být užitečný i pro schémata + jako [joinpooly][topic joinpools], [Ark][topic ark], [DLC][topic dlc] či + [vícenásobné podpisy][topic multisignature] (multisig). + +- **Vydána Mutiny Wallet v0.5.7:** + Vydání [Mutiny Wallet][mutiny github] přidává podporu pro [payjoin][topic payjoin] + a vylepšuje funkce NWC a LSP. + +- **Služba dávkování transakcí GroupHug:** + [GroupHug][grouphug github] je služba pro [dávkování plateb][scaling payment batching] + používající [PSBT][topic psbt], s [některými omezeními][grouphug blog]. + +- **Boltz ohlašuje taproot swap:** + Nekustodiální swap směnárna Boltz [ohlásila][boltz blog] aktualizaci svého protokolu + atomických swapů. Nově bude používat [taproot][topic taproot], [Schnorrovy podpisy][topic + schnorr signatures] a [MuSig2][topic musig]. + +## 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.* + +- [Core Lightning 24.02rc1][] 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 #27877][] přidává do peněženky Bitcoin Core novou strategii + [výběru mincí][topic coin selection] CoinGrinder (viz [zpravodaj č. 283][news283 + coingrinder]). Účelem této strategie je použití v případech, kdy je odhadovaný + jednotkový poplatek v porovnání s dlouhodobou úrovní vysoký. To peněžence + umožní vytvořit malé transakce nyní (důsledkem může být nutnost vytvořit + větší transakce později, snad s nižším jednotkovým poplatkem). + +- [BOLTs #851][] přidává do specifikace LN podporu [oboustranného financování][topic + dual funding] („dual funding”) spolu s podporou protokolu pro interaktivní konstrukci + transakcí. Interaktivní konstrukce umožňuje dvěma uzlům vyměnit si detaily + o nastavení a UTXO a tím spolupracovat na vytvoření otevírající transakce. + Oboustranné financování umožňuje transakci obsahovat vstupy kterékoliv nebo + obou stran. Například Alice může chtít otevřít s Bobem kanál. Před touto + změnou musela Alice poskytnout kompletní financování kanálu. Nyní může + Alice otevřít s Bobem kanál, ve kterém poskytne kompletní financování on nebo + se o financování podělí. Může to být použito spolu s [protokolem inzerátů + likvidity][topic liquidity advertisements] („liquidity advertisements”), + který zatím do specifikace přidán nebyl. + +{% assign day_after_posting = page.date | date: "%s" | plus: 86400 | date: "%Y-%m-%d 15:00" %} +{% include snippets/recap-ad.md when=day_after_posting %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="1551,27877,851" %} +[news283 coingrinder]: /cs/newsletters/2024/01/03/#nove-strategie-vyberu-minci +[news52 asmap]: /en/newsletters/2019/06/26/#differentiating-peers-based-on-asn-instead-of-address-prefix +[news83 asmap]: /en/newsletters/2020/02/05/#bitcoin-core-16702 +[jahr asmap]: https://delvingbitcoin.org/t/asmap-creation-process/548 +[autonomous systems]: https://cs.wikipedia.org/wiki/Autonomn%C3%AD_syst%C3%A9m +[daftuar feerate rule]: https://delvingbitcoin.org/t/mempool-incentive-compatibility/553#feerate-rule-9 +[news288 rbfr]: /cs/newsletters/2024/02/07/#navrh-na-nahrazovani-jednotkovym-poplatkem-jako-reseni-pinningu +[daftuar incompatible]: https://delvingbitcoin.org/t/mempool-incentive-compatibility/553#using-feerate-diagrams-as-an-rbf-policy-tool-13 +[daftuar incentive]: https://delvingbitcoin.org/t/mempool-incentive-compatibility/553 +[news285 64bit]: /cs/newsletters/2024/01/17/#navrh-na-soft-fork-pro-64bitovou-aritmetiku +[dnssec]: https://cs.wikipedia.org/wiki/Domain_Name_System_Security_Extensions +[corallo dns]: https://delvingbitcoin.org/t/human-readable-bitcoin-payment-instructions/542/ +[dns bip]: https://github.com/TheBlueMatt/bips/blob/d46a29ff4b4ac27210bc81474ae18e4802141324/bip-XXXX.mediawiki +[dns bolt]: https://github.com/lightning/bolts/pull/1136 +[dns blip]: https://github.com/lightning/blips/pull/32 +[dnssec-prover]: https://github.com/TheBlueMatt/dnssec-prover +[dns demo]: http://http-dns-prover.as397444.net/ +[news278 dns]: /cs/newsletters/2023/11/22/#ln-adresy-kompatibilni-s-nabidkami +[news166 tluv]: /en/newsletters/2021/09/15/#amount-introspection +[64bit discuss]: https://delvingbitcoin.org/t/64-bit-arithmetic-soft-fork/397 +[stewart inout]: https://delvingbitcoin.org/t/op-inout-amount/549 +[thunderbiscuit ecash]: https://delvingbitcoin.org/t/building-intuition-for-the-cashu-blind-signature-scheme/506 +[blind signature scheme]: https://en.wikipedia.org/wiki/Blind_signature +[chaumian ecash]: https://en.wikipedia.org/wiki/Ecash +[openalias]: https://openalias.org/ +[cashu]: https://github.com/cashubtc/nuts +[bip inout]: https://github.com/Christewart/bips/blob/92c108136a0400b3a2fd66ea6c291ec317ee4a01/bip-op-inout-amount.mediawiki +[mempool series]: /cs/blog/waiting-for-confirmation/ +[Core Lightning 24.02rc1]: https://github.com/ElementsProject/lightning/releases/tag/v24.02rc1 +[nwc blog]: https://blog.getalby.com/scaling-bitcoin-apps/ +[mutiny github]: https://github.com/MutinyWallet/mutiny-web +[grouphug blog]: https://peachbitcoin.com/blog/group-hug/ +[grouphug github]: https://github.com/Peach2Peach/groupHug +[boltz blog]: https://blog.boltz.exchange/p/introducing-taproot-swaps-putting diff --git a/_posts/cs/newsletters/2024-02-28-newsletter.md b/_posts/cs/newsletters/2024-02-28-newsletter.md new file mode 100644 index 0000000000..21075ee425 --- /dev/null +++ b/_posts/cs/newsletters/2024-02-28-newsletter.md @@ -0,0 +1,343 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 291' +permalink: /cs/newsletters/2024/02/28/ +name: 2024-02-28-newsletter-cs +slug: 2024-02-28-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Zpravodaj tento týden popisuje návrh kontraktu pro futures s těžebními +poplatky bez požadavku na důvěru, odkazuje na algoritmus výběru mincí +pro LN uzly nabízející likviditu v rámci oboustranného financování, zkoumá +prototyp úschovny používající `OP_CAT` a nahlíží na posílání a přijímání +ecash pomocí LN a ZKCP. Též nechybí naše pravidelné rubriky se souhrnem +oblíbených otázek a odpovědí z Bitcoin Stack Exchange, oznámeními o +nových vydáních a popisem změn v populárních bitcoinových páteřních +projektech. + +## Novinky + +- **Kontrakty pro futures s těžebními poplatky bez požadavku na důvěru:** ZmnSCPxj + zaslal do fóra Delving Bitcoin [příspěvek][zmnscpxj futures] se souborem + skriptů, které dvěma stranám umožní si navzájem podmínečně zaplatit + (dle jednotkového poplatku) za začlenění transakce v budoucím bloku. + V našem příkladu je Alice uživatelkou, která očekává začlenění transakce + do bloku 1 000 000 (nebo krátce po něm). Bob je těžař, který má určitou + šanci na vytěžení bloku v té době. Oba vloží nějaké prostředky na + _financující transakci_, která může být utracena jedním ze tří způsobů: + + 1. Bob obdrží zpět svůj vklad a navíc si nárokuje Alicin vklad tím, že + utratí výstup financující transakce v bloku 1 000 000 (nebo krátce + po něm). Skript vyžaduje, aby bylo Bobovo jednostranné utracení + o určité velikosti, například větší než dvě běžné platby. + + 2. Druhou možností je, že Alice obdrží zpět svůj vklad a navíc si + nárokuje Bobův vklad tím, že utratí výstup financující + transakce někdy po bloku 1 000 000 (například o den později + v bloku 1 000 144). Alicina transakce je relativně malá. + + 3. Jinou možností je, že Alice s Bobem kooperativně utratí výstup + financující transakce, jakkoliv si přejí. Zde je pro maximální + efektivitu použito [taprootové][topic taproot] utracení klíčem. + + Jsou-li jednotkové poplatky kolem bloku 1 000 000 nižší, než očekávali, + může Bob do tohoto bloku začlenit svou velkou transakci (nebo bloku krátce + po něm) a vydělat na tom. Pro Boba je to v období nízkých poplatků obzvláště + výhodné, neboť není jako těžař za produkované bloky tolik bohatě odměňován. + + Jsou-li jednotkové poplatky kolem bloku 1 000 000 vyšší, než očekávali, + nebude Bob chtít svou velkou transakci do bloku začlenit, neboť by ho + to na poplatcích stálo více, než kolik by vydělal. Vydělat na tom tak může + Alice, když bude její menší platba začleněna do bloku 1 000 144 (nebo pozdějšího). + Pro Alici je to v období vysokých poplatků obzvláště výhodné, neboť + tím budou kompenzovány vysoké náklady na začlenění běžné transakce + do dříve plánovaného bloku 1 000 000. + + Dále pokud si Alice i Bob uvědomí, že bude pro Boba výdělečné začlenit + jeho utracení do bloku 1 000 000, mohou oba kooperativně vytvořit + menší transakci, než byla původní Bobova jednostranná verze. Díky + tomu Bob ušetří na poplatcích a Alice může díky redukci množství dat + v bloku 1 000 000 dostat svou transakci do plánovaného bloku s nižším + poplatkem. + + Ve vlákně diskuze se objevilo několik reakcí. Jedna odpověď [poznamenala][harding + futures], že tento kontrakt nejen že nevyžaduje důvěru (což je pro + kontrakty vynucované konsenzem běžné), ale navíc neumožňuje podplácení + protistrany. Pokud by například existoval centralizovaný trh s poplatkovými + futures, Bob a ostatní těžaři by mohli [přijímat poplatky bokem][topic out-of-band + fees] nebo využít jiných triků k manipulaci zjevného jednotkového poplatku. + Se ZmnSCPxjovo konstrukcí to však nehrozí: Bobovo rozhodnutí, zda velkou transakci + začlení nebo ne, závisí zcela na jeho úhlu pohledu na mempool a na současné + podmínky těžby. Zmíněná reakce dále rozjímala, zda by neměli větší + těžaři výhodu oproti menším. Anthony Towns [poskytl][towns futures] + tabulku výdělků ukazující, že pokusy o manipulaci by vedly k vyšším výdělkům + pro těžaře používající běžný algoritmus výběru transakcí. + +- **Výběr mincí pro poskytovatele likvidity:** Richard Myers + zaslal do fóra Delving Bitcoin [příspěvek][myers cs], ve kterém popisuje + vytvoření algoritmu [výběru mincí][topic coin selection], který je + optimalizován pro LN uzly nabízející likviditu pomocí [inzerátů][topic + liquidity advertisements]. Jeho příspěvek algoritmus popisuje a + odkazuje na jeho [PR][bitcoin core #29442] do Bitcoin Core. Během testování + dosáhl „15% redukce onchain poplatků v porovnání s výchozím výběrem + mincí [v Bitcoin Core].” Myers žádá o kritiku přístupu a návrhy + na vylepšení. + +- **Prototyp jednoduché úschovny používající `OP_CAT`:** vývojář Rijndael + zaslal do fóra Delving Bitcoin [příspěvek][rijndael vault] o rustové + implementaci [úschovny][topic vaults], kterou napsal jako ověření konceptu. + Jeho implementace závisí pouze na současných pravidlech konsenzu + a navrhovaném opkódu [OP_CAT][topic op_cat]. Uvádíme stručný příklad použití + úschovny: Alice vygeneruje adresu se skriptem vytvořeným softwarem + úschovny a obdrží na tuto adresu platbu. Nato se ona nebo nějaký zloděj pokusí + tyto prostředky utratit. + + - *Legitimní platba:* Alice platbu zahájí vytvořením spouštěcí transakce + se dvěma vstupy a dvěma výstupy. Jeden vstup utrácí částku z úschovny, + druhý přidává poplatky. Jeden výstup představuje přípravný výstup se + shodnou částkou prvního vstupu, druhý potom platí na případnou adresu + pro vybrání. Po uplynutí určitého množství bloků dokončí Alice vybrání + prostředků vytvořením transakce se dvěma vstupy a jedním výstupem: + jeden vstup utrácí první výstup spouštěcí transakce, druhý přidává dodatečný + poplatek. Výstup je adresou pro vybrání. + + V první transakci se pomocí `OP_CAT` a jednoho dříve popsaného triku + se [Schnorrovým podpisy][topic schnorr signatures] (viz [zpravodaj č. + 134][news134 cat], _angl._) ověřuje, zda má utrácený výstup stejný skript + a částku jako odpovídající právě vytvářený výstup. Tím se zajistí, + že spouštěcí transakce nemůže z úschovny odeslat žádné prostředky. + Druhá transakce ověřuje, že její první vstup obsahuje relativní + [časový zámek][topic timelocks] dle [BIP68][] na určitý počet + bloků (např. 20), že výstup platí shodnou částku jako první vstup a + že výstup platí na adresu shodnou s druhým výstupem spouštěcí transakce. + Relativní časový zámek poskytuje lhůtu na zpochybnění (viz níže). + Ověření přesné částky zajišťuje, že žádné prostředky nemohou být odeslány + bez povolení. Ověření adresy zabraňuje zlodějovi na poslední + chvíli vyměnit legitimní adresu pro vybrání za svou vlastní (tímto + problémem trpí, pokud víme, všechny předem podepsané úschovny, viz + [zpravodaj č. 59][news59 vaults], _angl._). + + - *Nelegitimní platba:* Mallory zahájí platbu vytvořením spouštěcí transakce, + jak bylo popsáno výše. Alicina [strážní věž][topic watchtowers] si během + lhůty na zpochybnění uvědomí, že utracení není legitimní, a vytvoří + transakci pro navrácení prostředků zpět do úschovny. Tato transakce má + dva vstupy a jeden výstup. Jeden vstup je prvním výstupem spouštěcí + transakce, druhý platí poplatek. Výstup vrací částku zpět do úschovny. + Protože má transakce vracející prostředky do úschovny pouze jediný + výstup, ale podmínky pro vybrání stanovené skriptem vyžadují utracení + ze spouštěcí transakce se dvěma výstupy, není Mallory schopen krádež + Aliciných peněz dokončit. + + Jelikož jsou peníze vráceny na stejný skript úschovny, může Mallory + opět vytvořit novou spouštěcí transakci a nutit tak Alici podstupovat + dokola stejný cyklus. Mallory i Alici vznikají náklady platbami poplatků. + Rijndaelova [rozsáhlá dokumentace][cat vault readme] projektu poznamenává, + že by bylo zřejmě v tom případě vhodnější, aby nechala Alice vrátit peníze + na jiný skript. V jeho schématu je tato konstrukce možná, ale zatím + není z důvodu zachování jednoduchosti implementována. + + Tyto úschovny založené na CAT mohou být srovnány s předem podepsanými + úschovnami, které lze vytvářet již nyní bez změn konsenzu, a s úschovnami + ve stylu [BIP345][] (`OP_VAULT`), které by v případě přidání soft forkem + nabízely dosud nejlepší soubor vlastností. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Př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` + +
    Útok nahrazení adresy na poslední chvíliZranitelné + + **Nejsou zranitelné** + + + + **Nejsou zranitelné** + +
    Vybrání části prostředkůPokud zajištěno předem + + **Ano** + + Ne
    Statické a neinteraktivně odvoditelné adresy pro vkladyNe + + **Ano** + + + + **Ano** + +
    Redukce 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
    + + V době psaní zpravodaje se tento prototyp setkal s malým množství diskuze a rozboru. + +- **Posílání a přijímání ecash pomocí LN a ZKCP:** Anthony Towns + zaslal do fóra Delving Bitcoin [příspěvek][towns lnecash] o napojení + „[ecashových][topic ecash] mincoven do Lightning Network bez ztráty + anonymity či bez potřeby vyššího stupně důvěry.“ Jeho návrh používá + podmíněné platby s nulovou znalostí ([ZKCP][topic acc], „zero-knowledge + contingent payment”) pro odeslání platby uživateli ecash. Dále popisuje + proces, jak použít commitment předobrazu hashe potřebný pro odeslání + ecashových prostředků do LN. + + Calle, vedoucí vývojář ecashové implementace [Cashu][], uvedl v odpovědi + některé potenciální problémy, ale též vyjádřil myšlence podporu. Dále + poskytl odkaz na systém důkazů s nulovou znalostí implementovaný v Cashu + a poznamenal, že aktivně zkoumá a implementuje podporu atomických + plateb z ecash do LN. + +## 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/" %} + +- [Proč nemohou mít uzly volbu pro zakázání přeposílání některých typů transakcí?]({{bse}}121734) + Ava Chow uvažuje o smyslu [mempoolu a pravidel přeposílání][policy series], výhodách + stejnorodých mempoolů včetně [odhadu poplatků][topic fee estimation] a [přeposílání kompaktních + bloků][topic compact block relay] a dotýká se i obcházení pravidel například + [placením poplatků][topic out-of-band fees] těžařům mimo blockchain. + +- [Co je kruhová závislost při podepisování řady nepotvrzených transakcí?]({{bse}}121959) + Ava Chow vysvětluje problém [kruhových závislostí][mastering 06 cds] při + používání nepotvrzených zastaralých druhů bitcoinových transakcí. + +- [Jak funguje systém výplat TIDES u Ocean?]({{bse}}120719) + Uživatel Lagrang3 objasňuje systém výplat TIDES (Transparent Index of Distinct Extended + Shares) používaný těžebním poolem Ocean. + +- [Jaká data peněženka Bitcoin Core vyhledává během skenování blockchainu?]({{bse}}121563) + Pieter Wuille a Ava Chow shrnují, jak peněženka Bitcoin Core identifikuje transakce + související se zastaralým druhem peněženky nebo s peněženkou založenou na [deskriptorech][topic + descriptors]. + +- [Jak funguje opakované zveřejňování transakcí u watch-only peněženek?]({{bse}}121899) + Ava Chow poznamenává, že logika opakovaného zveřejňování transakcí nezávisí na + druhu peněženky. Nicméně, aby se uzel pokoušel opakovaně zveřejnit transakci + z watch-only peněženky, musela být transakci v nějakém okamžiku přijata do + jeho mempoolu. + +## 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.* + +- [Core Lightning 24.02][] je vydáním příští hlavní verze tohoto populárního LN uzlu. + Obsahuje vylepšení pluginu `recover`, díky kterým „jsou nouzové obnovy méně stresující,“ + vylepšení [anchor kanálů][topic anchor outputs], o 50 % rychlejší synchronizaci + blockchainu a opravu chyby parsování velké transakce nalezené na testnetu. + +## 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 #2770][] přináší přípravy na budoucí podporu [kanálů s oboustranným financováním][topic + dual funding]. + +{% assign day_after_posting = page.date | date: "%s" | plus: 86400 | date: "%Y-%m-%d 15:00" %} +{% include snippets/recap-ad.md when=day_after_posting %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="2770,29442" %} +[Core Lightning 24.02]: https://github.com/ElementsProject/lightning/releases/tag/v24.02 +[myers csliq]: https://delvingbitcoin.org/t/liquidity-provider-utxo-management/600 +[news134 cat]: /en/newsletters/2021/02/03/#replicating-op-checksigfromstack-with-bip340-and-op-cat +[news59 vaults]: /en/newsletters/2019/08/14/#bitcoin-vaults-without-covenants +[cashu]: https://github.com/cashubtc/nuts +[zmnscpxj futures]: https://delvingbitcoin.org/t/an-onchain-implementation-of-mining-feerate-futures/547 +[harding futures]: https://delvingbitcoin.org/t/an-onchain-implementation-of-mining-feerate-futures/547/2 +[myers cs]: https://delvingbitcoin.org/t/liquidity-provider-utxo-management/600 +[rijndael vault]: https://delvingbitcoin.org/t/basic-vault-prototype-using-op-cat/576 +[cat vault readme]: https://github.com/taproot-wizards/purrfect_vault +[towns lnecash]: https://delvingbitcoin.org/t/ecash-and-lightning-via-zkcp/586 +[towns futures]: https://delvingbitcoin.org/t/an-onchain-implementation-of-mining-feerate-futures/547/6?u=harding +[policy series]: /cs/blog/waiting-for-confirmation/ +[mastering 06 cds]: https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch06_transactions.adoc#circular-dependencies +[calle lnecash]: https://delvingbitcoin.org/t/ecash-and-lightning-via-zkcp/586/2 diff --git a/_posts/cs/newsletters/2024-03-06-newsletter.md b/_posts/cs/newsletters/2024-03-06-newsletter.md new file mode 100644 index 0000000000..a4d244d595 --- /dev/null +++ b/_posts/cs/newsletters/2024-03-06-newsletter.md @@ -0,0 +1,161 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 292' +permalink: /cs/newsletters/2024/03/06/ +name: 2024-03-06-newsletter-cs +slug: 2024-03-06-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Zpravodaj tento týden shrnuje diskuzi o aktualizaci specifikace URI typu +`bitcoin:` dle BIP21, popisuje návrh na správu několika souběžných sezení +MuSig2 s minimálním stavem, odkazuje na vlákno o přidání editorů repozitáře +BIPů a představuje soubor nástrojů, který by umožnil rychle přemístit projekt +Bitcoin Core z GitHubu na vlastní instanci GitLabu. Též nechybí naše pravidelné +rubriky s oznámeními nových vydání a souhrnem nedávných změn v populárním +bitcoinovém páteřním software. + +## Novinky + +- **Aktualizace BIP21 pro URI typu `bitcoin:` :** Josie Baker zaslal + do fóra Delving Bitcoin [příspěvek][baker bip21] o URI dle [BIP21][]: + jak je jejich používání specifikováno, jak jsou dnes používány a jak + by mohly být používány v budoucnosti. Specifikace vyžaduje, aby ihned + za dvojtečkou následoval zastaralý druh P2PKH adresy, např. `bitcoin:1BoB...`. + Po této části mohou být předány další parametry včetně novějších formátů + adres, například bech32m adresa: `bitcoin:1Bob...?bech32m=bc1pbob...`. + Avšak tento způsob se významně odlišuje od současného běžného používání. + Adresy odlišné od P2PKH jsou často posazeny hned za dvojtečku a někdy tato + pozice ani obsazená není, pokud chce software přijímat platby pouze pomocí + alternativních platebních protokolů. Dále Baker poznamenává, že adresy + `bitcoin:` se více a více používají pro přenos trvalých identifikátorů + pro platby respektující soukromí, jako jsou [tiché platby][topic silent payments] + či [nabídky][topic offers]. + + Dle diskutujících ve vlákně by zlepšením bylo, kdyby mohl autor URI + specifikovat všechny podporované způsoby plateb jako parametry bez + klíčů, např. `bitcoin:?bc1q...&sp1q...`. Plátce (který je obvykle + zodpovědný za platbu poplatků) by si tak mohl ze seznamu vybrat + preferovanou metodu. Ač byly v době psaní zpravodaje některé technické + drobnosti stále diskutovány, žádná vážnější kritika se ve vlákně neobjevila. + +- **PSBT pro více současně probíhajících MuSig2 sezení:** Salvatore + Ingala zaslal do fóra Delving Bitcoin [příspěvek][ingala musig2] o minimalizaci + stavu potřebného pro vykonání několika paralelně běžících podepisovacích sezení + [MuSig2][topic musig]. Pomocí podpisového algoritmu popsaného v [BIP327][] + bude skupina podepisujících potřebovat dočasně uložit lineárně se zvyšující + množství dat pro každý dodatečný vstup, který chtějí přidat do podepisované + transakce. Mnoho hardwarových podpisových zařízení má k dispozici pouze omezené + úložiště, bylo by tedy vhodné jejich vyžadované množství minimalizovat + bez negativního dopadu na bezpečnost. + + Ingala navrhuje vygenerovat jediný stavový objekt pro celé [PSBT][topic psbt] + a z něj deterministicky odvodit stav pro každý vstup. Odvozování musí + zaručit, že je jeho výsledek nerozlišitelný od náhodných dat. Tímto + způsobem by bylo množství stavových dat, která zařízení podepisuje, + konstantní a tedy nezávislé na počtu podepisovaných vstupů. + + Vývojář Christopher Scott ve své [reakci][scott musig2] poznamenal, + že [BitEscrow][] již podobný mechanismus používá. + +- **Diskuze o přidání dalších editorů BIPů:** Ava Chow zaslala do emailové + skupiny Bitcoin-Dev [příspěvek][chow bips] s návrhem na přidání editorů + BIPů, aby pomohli editorům současným. Jeden z nich, Luke Dashjr, + [říká][dashjr backlogged], že práci na BIPech nestíhá a požádal o pomoc. + Chow navrhla, aby se dva známí přispěvatelé stali editory, což se + setkalo s podporou. Dále se diskutovalo, zda by noví editoři měli mít + schopnost přiřazovat čísla BIPů. V době psaní nebylo dosaženo jasného + závěru. + +- **Záloha githubového projektu Bitcoin Core na GitLabu:** Fabian Jahr + zaslal do fóra Delving Bitcoin [příspěvek][jahr gitlab] informující + o udržování zálohy projektu Bitcoin Core (původně hostovaném na + GitHubu) na vlastní instanci GitLabu. V případě, že by projekt + náhle potřeboval GitHub opustit, mohly by být na GitLabu rychle zpřístupněny + pull requesty a hlášení chyb, což by umožnilo pokračovat v práci jen + s krátkým přerušením. Jahr poskytl náhled projektu na Gitlabu a plánuje + zálohy udržovat pro případ náhlé potřeby na GitLab přejít. Jeho příspěvek + neobdržel v době psaní žádné komentáře, avšak my mu děkujeme za + usnadnění případného přechodu. + +## 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.* + +- [Eclair v0.10.0][] je novým vydáním této implementace LN uzlu. „Přidává oficiální + podporu pro [oboustranné financování][topic dual funding], aktualizuje + implementaci [nabídek][topic offers] dle BOLT12 a přináší zcela funkční + prototyp [splicingu][topic splicing].” Dále obsahuje „rozličná vylepšení + související s onchain poplatky, více možností nastavení, výkonnostní + zlepšení a opravy drobných chyb.” + +- [Bitcoin Core 26.1rc1][] je kandidátem na údržbové vydání této převládající + implementace plného 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 #29412][] přidává kód, který prověří každý známý způsob + modifikace, jež z validního bloku činí nevalidní za zachování stejného + hashe hlavičky. Modifikované bloky v minulosti způsobily několik zranitelností. + V letech 2012 a 2017, kdy Bitcoin Core cachoval odmítnutí nevalidních bloků, + mohl útočník vzít validní blok, modifikovat ho a jako nevalidní jej podstrčit + uzlu oběti. Tento uzel by blok odmítl jako nevalidní a později by nepřijal + ani validní formu tohoto bloku (dokud by uzel nebyl restartován). Tímto + druhem [útoku zastíněním][topic eclipse attacks] by tak v uzlu oběti způsobil + štěpení blokchainu (viz [zpravodaj č. 37][news37 invalid], _angl._, pro další + podrobnosti). Další potíže nastaly v nedávné době, když Bitcoin Core vyžádal + od jednoho spojení blok a jiné spojení mu podstrčilo modifikovaný blok. Bitcoin + Core potom od prvního spojení žádné další bloky neobdržel. Oprava byla popsána + ve [zpravodaji č. 251][news251 block]. + + Kód přidaný tímto PR umožňuje rychle zkontrolovat, zda právě obdržený blok + obsahuje některou ze známých modifikací, které by jej učinily nevalidním. + Pokud ano, může být nevalidní blok odmítnut hned na začátku a nebude tak + příčinou odmítnutí validního bloku později. + +- [Eclair #2829][] umožňuje pluginům stanovit pravidla přispívání prostředků + během otevírání [kanálů s oboustranným financováním][topic dual funding]. + Ve výchozím stavu nepřispívá Eclair do kanálů s oboustranným financováním + žádnými prostředky. Toto PR nabízí pluginům toto pravidlo přepsat a + rozhodnout, kolik prostředků provozovatele uzlu může být na nový kanál + použito. + +- [LND #8378][] přináší několik vylepšení [výběru mincí][topic coin selection]. + Mimo jiné umožňuje uživatelům zvolit strategii výběru a vybrat vstupy, + které musí být součástí transakce. Algoritmus však může v případě potřeby + přispět dalšími vstupy. + +- [BIPs #1421][] přidává [BIP345][] pro opkód `OP_VAULT` a související změny + konsenzu, které by v případě aktivace soft forkem přinesly podporu + [úschoven][topic vaults] (vaults). Narozdíl od úschoven dostupných dnes + použitím předem podepsaných transakcí jsou úschovny dle BIP345 odolné + vůči útokům nahrazení transakce na poslední chvíli. Úschovny dle BIP345 + dále umožňují [dávkové][topic payment batching] operace, díky kterým + jsou účinnější než většina návrhů používající pouze obecnější + mechanismus [kovenantů][topic covenants]. + +{% assign day_after_posting = page.date | date: "%s" | plus: 86400 | date: "%Y-%m-%d 15:00" %} +{% include snippets/recap-ad.md when=day_after_posting %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="29412,2829,8378,1421" %} +[jahr gitlab]: https://delvingbitcoin.org/t/gitlab-backups-for-bitcoin-core-repository/624 +[ingala musig2]: https://delvingbitcoin.org/t/state-minimization-in-musig2-signing-sessions/626 +[scott musig2]: https://delvingbitcoin.org/t/state-minimization-in-musig2-signing-sessions/626/2 +[baker bip21]: https://delvingbitcoin.org/t/revisiting-bip21/630 +[bitescrow]: https://github.com/BitEscrow/escrow-core +[chow bips]: https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/ +[dashjr backlogged]: https://twitter.com/LukeDashjr/status/1761127972302459000 +[news37 invalid]: /en/newsletters/2019/03/12/#bitcoin-core-vulnerability-disclosure +[news251 block]: /cs/newsletters/2023/05/17/#bitcoin-core-27608 +[eclair v0.10.0]: https://github.com/ACINQ/eclair/releases/tag/v0.10.0 +[bitcoin core 26.1rc1]: https://bitcoincore.org/bin/bitcoin-core-26.1/ diff --git a/_posts/cs/newsletters/2024-03-13-newsletter.md b/_posts/cs/newsletters/2024-03-13-newsletter.md new file mode 100644 index 0000000000..2a5ed7d84b --- /dev/null +++ b/_posts/cs/newsletters/2024-03-13-newsletter.md @@ -0,0 +1,155 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 293' +permalink: /cs/newsletters/2024/03/13/ +name: 2024-03-13-newsletter-cs +slug: 2024-03-13-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Zpravodaj tento týden shrnuje příspěvek o onchain sázení o případném +soft forku bez požadavku na důvěru a odkazuje na podrobný přehled Chia Lispu +pro bitcoinery. Též nechybí naše pravidelné rubriky se souhrnem sezení +Bitcoin Core PR Review Clubu, oznámeními o nových vydáních a popisem významných +změně v populárním bitcoinovém páteřním software. + +## Novinky + +- **Onchain sázky na případné soft forky bez požadavku na důvěru:** ZmnSCPxj + zaslal do fóra Delving Bitcoin [příspěvek][zmnscpxj bet] s popisem + protokolu předávajícího kontrolu nad UTXO straně, která správně předpoví + aktivaci nějakého konkrétního soft forku. Pro příklad uvažujme, že Alice věří v aktivaci + konkrétního soft forku a chtěla by získat nějaké bitcoiny. Bob má stejný + zájem, avšak domnívá se, že soft fork aktivován nebude. Kooperativně shromáždí + určité množství bitcoinů v předem domluveném poměru (např. 1:1). Pokud by + soft fork byl aktivován před určitým časovým limitem, Alice by obdržela kombinovanou + částku. V opačném případě by připadla Bobovi. Pokud by před vypršením časového + limitu došlo k trvalému štěpení blockchainu (jeden by fork aktivoval, druhý + zakazoval), obdržela by Alice kombinovanou částku v aktivovaném blockchainu + a Bob v blockchainu zakazujícím aktivaci. + + Základní myšlenka byla již dříve navržena ([příklad][rubin bet]), avšak + ZmnSCPxjova verze se umí vypořádat se specifiky očekávanými v minimálně + jednom případném budoucím soft forku: [OP_CHECKTEMPLATEVERIFY][topic + op_checktemplateverify]. ZmnSCPxj též krátce uvažuje o potížích + generalizace této myšlenky na jiné navrhované soft forky, obzvláště ty, + které mění definici opkódu `OP_SUCCESSx`. + +- **Chia Lisp pro bitcoinery:** Anthony Towns zaslal do fóra Delving + Bitcoin [příspěvek][towns lisp] s podrobným přehledem varianty [Lispu][Lisp] + používané kryptoměnou Chia. Towns již dříve navrhl přidat soft forkem + do bitcoinu skriptovací jazyk založený na Lispu (viz [zpravodaj č. 191][news191 lisp], + _angl._). Lidem se zájmem o toto téma doporučujeme si jeho příspěvek + přečíst. + +## 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í.* + +[Opět aktivuj `OP_CAT`][review club bitcoin-inquisition 39] je PR od Armina +Sabouriho (0xBEEFCAF3 na GitHubu), které vrací opkód [OP_CAT][topic op_cat], +avšak pouze na [signetový][topic signet] [Bitcoin Inquisition][bitcoin inquisition +repo] a pro [tapscript][topic tapscript] (taproot script). Satoshi Nakamoto +tento opkód v roce 2010 pravděpodobně z přílišné opatrnosti deaktivoval. +Operace nahrazuje první dva prvky v zásobníku jejich spojením +(„con**cat**enation”). + +Motivace pro `OP_CAT` diskutovány nebyly. + +{% include functions/details-list.md + q0="Za jakých podmínek může provedení `OP_CAT` vyústit v chybu?" + a0="Méně než dva prvky v zásobníku, přílišná velikost výsledného + prvku, zakázání nastavovacími příznaky (protože například ještě + nebyl aktivován soft fork) a pokud se objevuje v netaprootovém + skriptu (witness verze 0 nebo zastaralé typy)." + a0link="https://bitcoincore.reviews/bitcoin-inquisition-39#l-46" + + q1="`OP_CAT` mění definici jednoho z `OP_SUCCESSx` opkódů. + Proč však nemění definici jednoho z `OP_NOPx` opkódů (které též + byly v minulosti používané na soft forky)?" + a1="Opkódy `OP_SUCCESSx` a `OP_NOPx` mohou být předefinovány za účelem + implementace soft forku, protože zpřísňují pravidla validace + (volání jsou vždy úspěšná, zatímco po redefinici mohou selhat). + Jelikož vykonávání skriptu pokračuje i po `OP_NOP`, nesmí + předefinované `OP_NOP` opkódy ovlivňovat zásobník (jelikož + by skripty, které dříve selhávaly, mohly končit úspěšně, což + by pravidla zmírňovalo). Předefinované opkódy `OP_SUCCESS` mohou + zásobník ovlivňovat, jelikož `OP_SUCCESS` vykonávání skriptu + okamžitě úspěšně ukončuje. Jelikož `OP_CAT` zásobník mění, + nemůže redefinovat `OP_NOP` opkód." + a1link="https://bitcoincore.reviews/bitcoin-inquisition-39#l-33" + + q2="Toto PR přidává `SCRIPT_VERIFY_OP_CAT` i `SCRIPT_VERIFY_DISCOURAGE_OP_CAT`. + Proč jsou obě volby potřebné?" + a2="Umožňují, aby byl soft fork nasazen po částech. Nejprve jsou obě nastavené + na `true` (aktivace na úrovni konsenzu, ale žádné přeposílání ani těžba), + dokud neupgraduje většina sítě. Poté je `SCRIPT_VERIFY_DISCOURAGE_OP_CAT` + nastaven na `false`, aby umožnil používání. Pokud by experiment v Bitcoin + Inquisition selhal, může být proces vrácen stejnými kroky v opačném směru. + Pokud by byly obě volby nastavené na `false`, byl by `OP_CAT` jen + pouhým opkódem `OP_SUCCESS`." + a2link="https://bitcoincore.reviews/bitcoin-inquisition-39#l-60" +%} + +## 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.* + +- [Core Lightning v24.02.1][] je menší aktualizací tohoto LN uzlu přinášející + „opravy několika drobných chyb a vylepšení nákladové funkce algoritmu + routování.“ + +- [Bitcoin Core 26.1rc1][] je kandidátem na vydání údržbové verze této převládající + implementace plného uzlu. + +- [Bitcoin Core 27.0rc1][] je kandidátem na vydání příští hlavní verze této převládající + implementace plného 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]._ + +- [LND #8136][] přidává do RPC volání `EstimateRouteFee` fakturu a časový limit. + Když je vybrána trasa pro platbu faktury, zašle se po ní [sonda][topic payment + probes]. Pokud sonda ukončí činnost před vypršením časového limitu, + jsou vráceny náklady na vybranou trasu. V opačném případě bude vyvolána + chyba. + +- [LND #8499][] přináší významné změny typů založených na TLV (Type-Length-Value) + používaných pro [jednoduché taprootové kanály][topic simple taproot + channels]. Účelem je zlepšení souvisejícího API. Nejsme si vědomi žádné jiné + implementace, která by v současnosti nabízela jednoduché taprootové kanály, + ale pokud je někdo používá, vězte, že se může jednat o zpětně nekompatibilní + změnu. + +- [LDK #2916][] přidává jednoduché API pro převod předobrazu platby + do jejího hashe. LN faktura obsahuje hash platby a aby bylo možné + platbu nárokovat, musí konečný příjemce odhalit předobraz, který tomuto + hashi odpovídá. Každý uzel po trase obdrží tento předobraz od uzlu + po směru toku platby a může s jeho pomocí nárokovat platbu od uzlu + proti směru toku platby. Jelikož lze hash z předobrazu odvodit (nikoliv + však naopak), příjemci a přeposílající uzly potřebují ukládat pouze + předobraz. Díky tomuto API mohou kdykoliv dle potřeby hash odvodit. + +{% assign day_after_posting = page.date | date: "%s" | plus: 86400 | date: "%Y-%m-%d 14:00" %} +{% include snippets/recap-ad.md when=day_after_posting %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="8136,8499,2916" %} +[zmnscpxj bet]: https://delvingbitcoin.org/t/economic-majority-signaling-for-op-ctv-activation/635 +[rubin bet]: https://blog.bitmex.com/taproot-you-betcha/ +[news191 lisp]: /en/newsletters/2022/03/16/#using-chia-lisp +[towns lisp]: https://delvingbitcoin.org/t/chia-lisp-for-bitcoiners/636 +[lisp]: https://cs.wikipedia.org/wiki/Lisp +[bitcoin core 26.1rc1]: https://bitcoincore.org/bin/bitcoin-core-26.1/ +[Bitcoin Core 27.0rc1]: https://bitcoincore.org/bin/bitcoin-core-27.0/test.rc1/ +[Core Lightning v24.02.1]: https://github.com/ElementsProject/lightning/releases/tag/v24.02.1 +[review club bitcoin-inquisition 39]: https://bitcoincore.reviews/bitcoin-inquisition-39 diff --git a/_posts/cs/newsletters/2024-03-20-newsletter.md b/_posts/cs/newsletters/2024-03-20-newsletter.md new file mode 100644 index 0000000000..934b5724f9 --- /dev/null +++ b/_posts/cs/newsletters/2024-03-20-newsletter.md @@ -0,0 +1,193 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 294' +permalink: /cs/newsletters/2024/03/20/ +name: 2024-03-20-newsletter-cs +slug: 2024-03-20-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Zpravodaj tento týden oznamuje projekt pro vytváření BIP324 proxy +lehkým klientům a shrnuje diskuzi o návrhu jazyka BTC Lisp. Též nechybí +naše pravidelné rubriky s popisem nedávných změn v klientech a službách, +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 + +- **BIP324 proxy pro lehké klienty:** Sebastian Falbesoner + zaslal do fóra Delving Bitcoin [příspěvek][falbesoner bip324] oznamující + TCP proxy překládající mezi bitcoinovým P2P protokolem verze 1 (v1) a + [protokolem v2][topic v2 p2p transport], jak je definován v [BIP324][]. + Cílí zvláště na lehké klienty napsané pro v1, kterým umožní využívat výhod + šifrované komunikace protokolu v2. + + Lehké klienty obvykle pouze oznamují transakce, které patří jejich peněžence. + Každý, kdo je schopen odposlouchávat nešifrované spojení v1 tak může snadno + odvodit, které transakce pochází od související IP adresy. Je-li používáno + šifrování (v2), pouze plné uzly, které transakci obdrží, budou schopny + určit IP jejího původce – lehkého klienta – za předpokladu, že se spojení + lehkého klienta nestalo obětí man-in-the-middle útoku (který je možné + v některých případech detekovat a proti kterému se mohou [budoucí verze][topic + countersign] automaticky bránit). + + Falbesonerovo původní dílo používá BIP324 funkce napsané v Pythonu pro + testovací sadu nástrojů Bitcoin Core. Kvůli tomu je proxy „příšerně pomalá + a náchylná k útokům postranními kanály [a] nedoporučuji ji používat pro nic + jiného než testování.” Pracuje již nicméně na přepsání proxy v Rustu. + Uvažuje, že publikuje některé funkce jako knihovnu pro lehké klienty + nebo jiný software, který chce v2 P2P protokol nativně podporovat. + +- **Přehled BTC Lispu:** Anthony Towns zaslal do fóra Delving Bitcoin + [příspěvek][towns lisp] popisující své experimenty s tvorbou varianty + jazyka [Lisp][] nazvaného BTC Lisp během posledních několika let. Předešlé + diskuze jsme shrnuli ve zpravodajích [č. 293][news293 lisp] a [č. 191][news191 + lisp] (_angl._). Příspěvek zachází do velkých podrobností, zájemcům doporučujeme + jeho přečtení. Krátce zde uvedeme citace ze sekce _závěr_ a _budoucí práce_: + + „[BTC Lisp] může být na blockchainu trochu dražší, ale zdá se, že s ním + lze dělat v podstatě cokoliv. […] Nemyslím si, že by implementace lispového + interpretru nebo opkódů, které by ho musely doprovázet, byla příliš + náročná, [ale] psát lispový kód bez kompilátoru překládajícího z vysokoúrovňové + reprezentace do opkódů na úrovni konsenzu je dost otravné, [i když] + i to by mělo být řešitelné. Mohli bychom to vzít ještě dále, implementovat + nějaký takový jazyk a nasadit ho na signetu nebo inquisition.“ + + Russell O'Connor, vývojář jazyka [Simplicity][topic simplicity], který + by také mohl být považován za případnou alternativu skriptovacího jazyka + konsenzu, přinesl ve své [reakci][oconnor lisp] porovnání mezi současným + bitcoinovým jazykem Script, Simplicity a Chia/BTC Lisp. Usuzuje, že + „Simplicity i clvm (Chia Lisp Virtual Machine) jsou nízkoúrovňové jazyky, + které jsou určené pro snadné vykonávání počítačem. Kvůli tomu jsou hůře + srozumitelné lidem. Mají být kompilovány z nějakých jiných, srozumitelnějších + nekonsenzuálních jazyků. Simplicity a clvm nabízejí odlišné způsoby vyjádření + starých dobrých věcí: načítat data z prostředí, kombinovat části dat, + provádět podmíněné příkazy a kopu dalších primitivních operací. […] + Jelikož stejně chceme [rozdělení na efektivní nízkoúrovňový konsenzuální + jazyk a vysokoúrovňový nekonsenzuální srozumitelný jazyk], nejsou detaily + tohoto nízkoúrovňového jazyka natolik důležité. Tedy po vynaložení nějakého + úsilí by tvůj vysokoúrovňový BTC Lisp mohl být pravděpodobně přeložen/kompilován + do Simplicity. […] Bez ohledu na to, kde nakonec skončí design Simphony (vysokoúrovňový + nekonsenzuální jazyk založený na Simplicity), bude zřejmě moci být + přeložen/kompilován do tvého nízkoúrovňového BTC Lispu. Každá kombinace + jazyka a překladače by nabízela odlišnou složitost a možnosti optimalizace.” + +## 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.* + +- **BitGo přidává podporu pro RBF:** + V [nedávném blogu][bitgo blog] oznámil BitGo podporu pro navyšování poplatků + [nahrazením poplatkem (RBF)][topic rbf] ve své peněžence a API. + +- **Vydána Phoenix Wallet v2.2.0:** + Tímto vydáním může Phoenix podporovat [splicing][topic splicing] během provádění LN + plateb pomocí protokolu quiescence („chvíle ticha,” viz [zpravodaj č. 262][news262 + eclair2680]). Dále Phoenix u funkce swap-in vylepšuje soukromí a poplatky pomocí + vlastního protokolu [swaproot][swaproot blog]. + +- **Vydáno hardwarové podpisové zařízení Bitkey:** + Zařízení [Bitkey][bitkey website] je navrženo pro používání v konfiguraci multisigu + 2-ze-3 s mobilním zařízením a klíčem serveru Bitkey. Zdrojový kód firmware + a dalších komponent je [dostupný][bitkey github] pod licencí MIT s Commons Clause. + +- **Vydán Envoy v1.6.0:** + [Vydání][envoy blog] přináší funkce pro navyšování poplatků transakcí a rušení + transakcí. Obě funkce používají RBF (nahrazení poplatkem). + +- **Vydán VLS v0.11.0:** + [Beta vydání][vls beta 3] umožňuje jednomu LN uzlu používat několik podepisujících zařízení. + Tuto schopnost nazývají [tag team signing][vls blog]. + +- **Ohlášeno hardwarové podpisové zařízení Portal:** + [Nedávno ohlášené][portal tweet] zařízení Portal funguje se smartphony pomocí + NFC. Zdrojové kódy hardwaru i softwaru jsou [dostupné][portal github] na GitHubu. + +- **Těžební pool Braiins přidává podporu pro Lightning Network:** + Těžební pool Braiins [ohlásil][braiins tweet] beta verzi placení odměn pomocí Lightningu. + +- **Vydána Ledger Bitcoin App 2.2.0:** + [Vydání 2.2.0][ledger 2.2.0] přidává podporu [miniscriptu][topic miniscript] pro + [taproot][topic taproot]. + +## 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 26.1rc2][] je kandidátem na údržbové vydání této převažující + implementace plného uzlu. + +- [Bitcoin Core 27.0rc1][] je kandidátem na vydání příští hlavní verze + této převažující implementace plného 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]._ + +*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 #27375][] přidává funkcím `-proxy` a `-onion` podporu pro + používání unixových doménových soketů namísto lokálních TCP portů. + Sokety mohou být rychlejší než TCP a nabízejí odlišné bezpečnostní + kompromisy. + +- [Bitcoin Core #27114][] umožňuje používat v konfiguračním parametru + `whitelist` „in” a „out”, díky kterým lze přiznat zvláštní přístup + konkrétním příchozím a odchozím spojením. Ve výchozím nastavení + obdrží spojení uvedené ve whitelistu zvláštní přístup pouze, pokud + se připojuje k uživatelovu lokálnímu uzlu (příchozí spojení). + Zvolením „out” může nyní uživatel určit, že spojení obdrží zvláštní + přístup, i když se lokální uzel připojuje k němu, například po + RPC volání `addnode`. + +- [Bitcoin Core #29306][] přidává [vylučování sourozenců][topic kindred + rbf] („sibling eviction”) transakcím vycházejícím z nepotvrzeného [v3 + rodiče][topic v3 transaction relay]. Může poskytnout uspokojivou + alternativu [CPFP carve-out][topic cpfp carve out], které je v současnosti + používáno [LN anchor výstupy][topic anchor outputs]. V3 přeposílání + transakcí včetně vylučování sourozenců není v současnosti na mainnetu + aktivováno. + +- [LND #8310][] umožňuje, aby byly hodnoty parametrů `rpcuser` a `rpcpass` + (heslo) načteny z proměnných prostředí. Díky tomu může být soubor `lnd.conf` + například spravován veřejným verzovacím systémem, jelikož nemusí obsahovat + uživatelské jméno a heslo. + +- [Rust Bitcoin #2458][] přidává podporu pro podepisování [PSBT][topic psbt], + které obsahují taprootové vstupy. + +{% 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="27375,27114,29306,8310,2458" %} +[bitcoin core 26.1rc2]: https://bitcoincore.org/bin/bitcoin-core-26.1/ +[Bitcoin Core 27.0rc1]: https://bitcoincore.org/bin/bitcoin-core-27.0/test.rc1/ +[lisp]: https://cs.wikipedia.org/wiki/Lisp +[news293 lisp]: /cs/newsletters/2024/03/13/#chia-lisp-pro-bitcoinery +[news191 lisp]: /en/newsletters/2022/03/16/#using-chia-lisp +[falbesoner bip324]: https://delvingbitcoin.org/t/bip324-proxy-easy-integration-of-v2-transport-protocol-for-light-clients-poc/678 +[towns lisp]: https://delvingbitcoin.org/t/btc-lisp-as-an-alternative-to-script/682 +[oconnor lisp]: https://delvingbitcoin.org/t/btc-lisp-as-an-alternative-to-script/682/7 +[bitgo blog]: https://blog.bitgo.com/available-now-for-clients-bitgo-introduces-replace-by-fee-f74e2593b245 +[news262 eclair2680]: /cs/newsletters/2023/08/02/#eclair-2680 +[swaproot blog]: https://acinq.co/blog/phoenix-swaproot +[bitkey website]: https://bitkey.world/ +[bitkey github]: https://github.com/proto-at-block/bitkey +[envoy blog]: https://foundation.xyz/2024/03/envoy-version-1-6-0-is-now-live/ +[vls beta 3]: https://gitlab.com/lightning-signer/validating-lightning-signer/-/releases/v0.11.0 +[vls blog]: https://vls.tech/posts/tag-team/ +[portal tweet]: https://twitter.com/afilini/status/1766085500106920268 +[portal github]: https://github.com/TwentyTwoHW +[braiins tweet]: https://twitter.com/BraiinsMining/status/1760319741560856983 +[ledger 2.2.0]: https://github.com/LedgerHQ/app-bitcoin-new/releases/tag/2.2.0 diff --git a/_posts/cs/newsletters/2024-03-27-newsletter.md b/_posts/cs/newsletters/2024-03-27-newsletter.md new file mode 100644 index 0000000000..9e72eb4bb5 --- /dev/null +++ b/_posts/cs/newsletters/2024-03-27-newsletter.md @@ -0,0 +1,280 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 295' +permalink: /cs/newsletters/2024/03/27/ +name: 2024-03-27-newsletter-cs +slug: 2024-03-27-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Zpravodaj tento týden oznamuje odhalení útoku plýtvajícího přenosovým pásmem +Bitcoin Core a jeho spojení, popisuje několik vylepšení myšlenky na sponzorování +poplatků transakcí a shrnuje diskuzi o používání živých dat mempoolu k +vylepšení odhadu poplatků v Bitcoin Core. 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 významnými změnami populárních bitcoinových páteřních +projektů. + +## Novinky + +- **Odhalení free relay útoku:** Peter Todd zaslal + do emailové skupiny Bitcoin-Dev [příspěvek][todd free relay] s popisem + útoku plýtvajícího přenosovým pásmem, který předtím [zodpovědně nahlásil][topic + responsible disclosures] vývojářům Bitcoin Core. Ve zkratce: Mallory + pošle jednu verzi transakce Alici a jinou verzi Bobovi. Transakce jsou + navrženy tak, aby Bob neakceptoval Alicinu verzi jako [RBF nahrazení][topic + rbf] a naopak. Mallory nato odešle Alici nahrazení, které ona akceptuje, + ale Bob ne. Alice přepošle nahrazení Bobovi, které Bob odmítne, což + vyústí v plýtvání přenosového pásma (tomuto plýtvání se říká [free relay][topic + free relay], „přeposílání zdarma”). Mallory může postup opakovat několikrát, + dokud se jeho transakce nepotvrdí. V každém kole cyklu Alice nahrazení + akceptuje, pošle ji Bobovi (použití přenosového pásma) a ten ji odmítne. + Následky útoku mohou být znásobeny, pokud by Mallory paralelně posílal několik + podobně zkonstruovaných transakcí a Alice měla několik spojení tato nahrazení + odmítajících. + + Útok je omezen náklady na poplatky, které Mallory zaplatí v případě + potvrzení některé z transakcí. Peter Todd však poznamenává že náklady mohou + být v podstatě nulové, pokud by Mallory stejně transakci plánoval odeslat. + Maximální množství přenosového pásma, kterým lze plýtvat, je omezeno + stávajícími limity přeposílání transakcí v Bitcoin Core, ačkoliv je možné, + že mnohonásobné paralelní provádění tohoto útoku by zpozdilo propagaci + legitimních nepotvrzených transakcí. + + Peter Todd též zmiňuje jiný známý druh plýtvání přenosového pásma uzlu, + při kterém uživatel zveřejní sadu velkých transakcí a poté ve spolupráci + s těžařem vytvoří blok, který obsahuje relativně malou transakci kolidující + se všemi přeposlanými transakcemi. Například transakce o velikost 29 000 + vbyte by mohla z mempoolu každého přeposílajícího uzlu odstranit 200 megabajtů + transakcí. Říká, že existence útoků umožňujících plýtvání přenosového + pásma znamená, že povolit určité množství přeposílání zdarma by bylo rozumné, + jak umožňuje například navrhované nahrazování jednotkovým poplatkem (viz + [zpravodaj č. 288][news288 rbfr]). + + +- **Vylepšení sponzorování transakčních poplatků:** Martin Habovštiak + zaslal do emailové skupiny Bitcoin-Dev [příspěvek][habovstiak boost] s nápadem + umožnit transakci zvýšit prioritu jiné, nesouvisející transakce. Fabian Jahr + [poznamenal][jahr boost], že v jádru je tato myšlenka podobná [sponzorování + transakčních poplatků][topic fee sponsorship], které v roce 2020 navrhl + Jeremy Rubin (viz [zpravodaj č. 116][news116 sponsor], _angl._). V Rubinově + původním návrhu _sponzorující transakce_ zavazovala _posilované transakci_ + pomocí výstupního skriptu nulové hodnoty o velikosti kolem 42 vbyte za + jedno sponzorství a kolem 32 vbyte za každé dodatečné sponzorství. + V Haboštiakově verzi zavazuje sponzorující transakce posilované transakci + pomocí taprootové přílohy ([annex][topic annex]), která používá 8 vbyte + za jedno sponzorství a 8 vbyte za každé další. + + Záhy po zveřejnění Habovštiakovy myšlenky zaslal David Harding do fóra + Delving Bitcoin [příspěvek][harding sponsor] s popisem způsobu navýšení + efektivity, který s Rubinem v lednu vyvinul. Sponzorující transakce zavazuje + posilované transakci pomocí signature commitment zprávy, která nikdy nebude + publikována onchain, nezabírá tedy žádný blokový prostor. Sponzorující + transakce se však musí objevit v blocích a zprávách [přeposílání balíčků][topic + package relay] okamžitě po posilované transakci. To umožní ověřujícím plným + uzlům během ověřování sponzorující transakce odvodit txid posilované transakce. + + V případech, kdy by blok obsahoval více sponzorujících transakcí zavazujících + stejné posilované transakci, by nebylo možné jednoduše umístit sérii posilovaných + transakcí přímo před jejich sponzory, proto není možné mít kompletně odvoditelné + závazky. Harding popisuje jednoduchou alternativu, která zabírá + pouze 0,5 vbyte za posilovanou transakci. Anthony Towns myšlenku dále + [vylepšuje][towns sponsor]: v jeho verzi by to nikdy nebylo více než 0,5 vbyte + za posílení, ve většině případů by používala prostoru méně. + + Habovštiak i Harding poukazují na možnost outsourcingu: každý, kdo plánuje + tak jako tak zveřejnit nějakou transakci (nebo kdo má nepotvrzenou transakci + a je ochoten ji [nahradit poplatkem][topic rbf]), může navýšit její + jednotkový poplatek a posílit jinou transakci. Dodatečné náklady by byly + nízké, pouze 0,5 vbyte či méně za každé posílení. Pro porovnání: 0,5 vbyte + je kolem 0,3 % transakce s jedním vstupem a dvěma P2TR výstupy. Bohužel, + jak oba varují, neexistuje pohodlný způsob, kterým za posílení transakce + třetí straně zaplatit bez požadavku na důvěru. Avšak jak Habovštiak dodává, + kdokoliv platící přes LN obdrží [doklad platby][topic proof of payment], + mohl by tedy prokázat podvod. + + Towns dále poznamenává, že sponzorování transakcí se zdá být kompatibilní + s návrhem [cluster mempoolu][topic cluster mempool] a že nejefektivnější + verze sponzorování by představovaly drobné potíže při cachování ověřování + transakcí. Na závěr ukazuje tabulku srovnávající relativní blokový prostor + spotřebovávaný současnými i navrhovanými technikami navyšování poplatků. + Lepší než sponzorování s 0,5 vbyte nebo méně za jedno posílení je pouze + nejlepší scénář s RBF (0 vbyte) a placení těžařům [stranou][topic + out-of-band fees]. Jelikož sponzorování poplatků umožňuje dynamické + navyšování a je téměř tak efektivní jako placení stranou, může pomoci + vyřešit velký problém protokolů, které závisí na [exogenních poplatcích][topic + fee sourcing]. + + V [probíhající diskuzi][daftuar sponsor] zveřejnil krátce před publikováním + zpravodaje Suhas Daftuar obavy, že sponzorování by mohlo přinést + problémy, které cluster mempool snadno řešit neumí a které by mohly dále + způsobit potíže uživatelům, které sponzorování nepotřebují. Naznačil, + že pokud by bylo sponzorování poplatků do bitcoinu přidáno, mělo by se týkat + pouze transakcí, které jej povolí. + +- **Odhad poplatků založený na mempoolu:** Abubakar Sadiq Ismail + zaslal do fóra Delving Bitcoin [příspěvek][ismail fees] s popisem vylepšení + [odhadu jednotkových poplatků][topic fee estimation] v Bitcoin Core pomocí + dat z lokálního mempoolu. V současnosti Bitcoin Core odhaduje poplatky + zaznamenáním výšky bloku, kdykoliv se objeví nepotvrzená transakce, + výšky bloky, když se transakce potvrdí, a jejího jednotkového poplatku. + Jsou-li všechny tyto informace známy, je rozdíl mezi výškou během přijetí + a výškou během potvrzení použit k aktualizaci exponenciálně váženého + klouzavého průměru v různých přihrádkách jednotkových poplatků. Například + transakce, která dosáhne potvrzení za 100 bloků s jednotkovým poplatkem + 1,1 sat/vbyte, bude zařazena do průměru v přihrádce 1 sat/vbyte. + + Výhodou tohoto přístupu je jeho odolnost vůči manipulaci: všechny + transakce musí být přeposlány (jsou tedy dostupné všem těžařům) a + potvrzeny (neporušují pravidla konsenzu). Nevýhodou je, že k aktualizaci + dochází pouze jednou za blok a může zaostávat za jinými metodami odhadu, + které používají aktuální informace z mempoolu. + + Ismail se účastnil [předešlé diskuze][bitcoin core #27995] o + začlenění dat z mempoolu do odhadu poplatku, předběžně napsal nějaký kód + a provedl analýzu porovnávající současný algoritmus s novým (bez začlenění + bezpečnostních kontrol). [Jedna odpověď][harding fees] ve vlákně navíc + odkázala na [předešlé bádání][alm fees] Kalleho Alma a vedla k diskuzi + o tom, zda by informace z mempoolu měly být použity pro zvyšování i snižování + odhadů poplatků nebo pouze pro snižování. Výhodou použití pro obě varianty je, že + díky tomu bude odhad poplatku užitečnější. Výhodou pouze snižování + (a zvyšování pomocí stávajících odhadů) je, že by bylo odolnější vůči manipulaci + cyklů s pozitivní odezvou. + + V době psaní zpravodaje diskuze stále probíhala. + +## 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/" %} + +- [Jaká rizika přináší provozování předsegwitového uzlu (0.12.1)?]({{bse}}122211) + Michael Folkson, Vojtěch Strnad a Murch vyjmenovávají nevýhody provozování + Bitcoin Core 0.12.1 včetně zvýšeného rizika akceptování nevalidní transakce + či bloku, zvýšené zranitelnosti vůči útokům dvojího utracení, zvýšené + závislosti na validaci prováděné ostatními účastníky sítě, výrazně pomalejší + validace bloků, chybějících vylepšení výkonnosti, nemožnosti používat + [přeposílání kompaktních bloků][topic compact block relay], nemožnosti přeposílat + kolem 95 % současných nepotvrzených transakcí a zranitelností způsobených (dnes již opravenými) + bezpečnostními chybami. Uživatelé peněženky v 0.12.1 by také postrádali novinky + kolem [miniscriptu][topic miniscript], [deskriptorových][topic descriptors] peněženek + a úspory na poplatcích a další vylepšení skriptovacích možností, které přinesly + [segwit][topic segwit], [taproot][topic taproot] a [Schnorrovy podpisy][topic schnorr + signatures]. Mezi dopady na bitcoinovou síť by v případě širšího nasazení Bitcoin Core + 0.12.1 patřily vyšší pravděpodobnost přijetí nevalidních bloků a s ním spojeného + rizika reorganizací, tlak na centralizaci těžby a snížené odměny těžařům + provozujícím tuto verzi. + +- [Kdy je OP_RETURN levnější než OP_FALSE OP_IF?]({{bse}}122321) + Vojtěch Strnad ukazuje, jaké náklady přináší šíření dat v `OP_RETURN` + a v `OP_FALSE` `OP_IF`. Na závěr vysvětluje, že „`OP_RETURN` je levnější + pro data menší než 143 bajtů.” + +- [Proč BIP-340 používá secp256k1?]({{bse}}122268) + Pieter Wuille vysvětluje důvody zvolení secp256k1 na úkor Ed25519 pro Schnorrovy + podpisy dle [BIP340][]. Přidává další důvody: „znovupoužitelnost stávající infrastruktury + odvozování klíčů” a „zachování bezpečnostních předpokladů.” + +- [Jaká kritéria používá Bitcoin Core pro tvorbu šablon bloků?]({{bse}}122216) + Murch vysvětluje stávající algoritmus Bitcoin Core pro výběr transakcí do kandidáta + na blok založený na jednotkových poplatcích předků. Dále zmiňuje probíhající + práce na [cluster mempoolu][topic cluster mempool] přinášející rozličná vylepšení. + +- [Jak funguje pole initialblockdownload v RPC volání getblockchaininfo?]({{bse}}122169) + Pieter Wuille vyjmenovává dvě podmínky, které musí být splněny, aby mělo pole `initialblockdownload` + po spuštění uzlu hodnotu false: + + 1. „Současný aktivní řetězec má alespoň tolik kumulativního PoW jako pevně zakódovaná konstanta” + 2. „Časové razítko současného aktivního vrcholu řetězce není více než 24 hodin v minulosti” + +## 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 26.1rc2][] je kandidátem na vydání údržbové verze této převládající + implementace plného uzlu. + +- [Bitcoin Core 27.0rc1][] je kandidátem na vydání příští hlavní verze této převládající + implementace plného uzlu. K dispozici je stručný přehled [navrhovaných témat pro testovaní][bcc + testing] a sezení [Bitcoin Core PR Review Club][] věnované testování je naplánováno + na 27. březen od 15:00 UTC. + +## 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 #28950][] přidává do RPC volání `submitpackage` parametry + `maxfeerate` a `maxburnamount`, které vyvolají chybu, pokud by měl poskytnutý + balíček agregovaný jednotkový poplatek nad stanoveným maximem nebo pokud + by posílal více než stanovenou hodnotu známému tvaru neutratitelného + výstupu. + +- [LND #8418][] přidává pravidelné načítání hodnot [BIP133][] `feefilter` + od připojeného bitcoinového klienta. Zpráva `feefilter` umožňuje uzlu + informovat spojení o nejnižších jednotkových poplatcích, které akceptuje + pro přeposílání transakcí. LND použije tuto informaci, aby zabránilo + odesílání transakcí s příliš nízkým poplatkem. Použity jsou pouze hodnoty pro odchozí + spojení, protože to jsou spojení vybraná a iniciovaná uzlem, + je tedy menší pravděpodobnost, že jsou pod kontrolou útočníka. + +- [LDK #2756][] přidává do svých zpráv podporu pro pakety [trampolínového routování][topic + trampoline payments]. Nepřidává tím plnou podporu pro používání trampolínového + routování nebo poskytování jeho služeb, usnadňuje však přidání podpory + uživatelům LDK. + +- [LDK #2935][] přidává podporu pro posílání [keysend plateb][topic + spontaneous payments] na [zaslepené trasy][topic rv routing]. Keysend platby + jsou bezpodmínečné platby poslané bez faktury. Zaslepené trasy skrývají + poslední skoky platební cesty. Zaslepené trasy jsou obvykle zakódovány + ve faktuře, nejsou tedy obvykle kombinovány s keysend platbami, avšak + mohou být užitečné v případech, kdy poskytovatel lightningových služeb + (LSP) nebo nějaký jiný uzel chtějí poskytnout obecnou fakturu pro + konkrétního adresáta bez odhalení identifikátoru adresátova uzlu. + +- [LDK #2419][] přidává automat (state machine) pro [interaktivní konstrukci + transakcí][topic dual funding], která je nutná pro kanály s dvojí financováním + a pro [splicing][topic splicing]. + +- [Rust Bitcoin #2549][] upravuje API pro práci s relativními [časovými zámky][topic + timelocks]. + +- [BTCPay Server #5852][] přidává podporu pro skenování animovaných QR kódů BBQr + (viz [zpravodaj č. 281][news281 bbqr]) pro [PSBT][topic psbt]. + +{% 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="28950,8418,2756,2935,2419,2549,5852,27995" %} +[bitcoin core 26.1rc2]: https://bitcoincore.org/bin/bitcoin-core-26.1/ +[Bitcoin Core 27.0rc1]: https://bitcoincore.org/bin/bitcoin-core-27.0/test.rc1/ +[bcc testing]: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/27.0-Release-Candidate-Testing-Guide +[news281 bbqr]: /cs/newsletters/2023/12/13/#ohlaseno-kodovaci-schema-bbqr +[todd free relay]: https://gnusha.org/pi/bitcoindev/Zfg%2F6IZyA%2FiInyMx@petertodd.org/ +[news288 rbfr]: /cs/newsletters/2024/02/07/#navrh-na-nahrazovani-jednotkovym-poplatkem-jako-reseni-pinningu +[habovstiak boost]: https://gnusha.org/pi/bitcoindev/CALkkCJZWBTmWX_K0+ERTs2_r0w8nVK1uN44u-sz5Hbb-SbjVYw@mail.gmail.com/ +[jahr boost]: https://gnusha.org/pi/bitcoindev/45ghFIBR0JCc4INUWdZcZV6ibkcoofy4MoQP_rQnjcA4YYaznwtzSIP98QvIOjtcnIdRQRt3jCTB419zFa7ZNnorT8Xz--CH4ccFCDv9tv4=@protonmail.com/ +[harding sponsor]: https://delvingbitcoin.org/t/improving-transaction-sponsor-blockspace-efficiency/696 +[news116 sponsor]: /en/newsletters/2020/09/23/#transaction-fee-sponsorship +[towns sponsor]: https://delvingbitcoin.org/t/improving-transaction-sponsor-blockspace-efficiency/696/5 +[ismail fees]: https://delvingbitcoin.org/t/mempool-based-fee-estimation-on-bitcoin-core/703 +[harding fees]: https://delvingbitcoin.org/t/mempool-based-fee-estimation-on-bitcoin-core/703/2 +[alm fees]: https://scalingbitcoin.org/stanford2017/Day2/Scaling-2017-Optimizing-fee-estimation-via-the-mempool-state.pdf +[daftuar sponsor]: https://delvingbitcoin.org/t/improving-transaction-sponsor-blockspace-efficiency/696/6 diff --git a/_posts/cs/newsletters/2024-04-03-newsletter.md b/_posts/cs/newsletters/2024-04-03-newsletter.md new file mode 100644 index 0000000000..842603eff4 --- /dev/null +++ b/_posts/cs/newsletters/2024-04-03-newsletter.md @@ -0,0 +1,134 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 296' +permalink: /cs/newsletters/2024/04/03/ +name: 2024-04-03-newsletter-cs +slug: 2024-04-03-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Zpravodaj tento týden shrnuje diskuzi a obnoveném úsilí na soft fork +pročišťující konsenzus a oznamuje plán na výběr nových editorů BIPů +před koncem tohoto týdne. Též nechybí naše pravidelné rubriky +s oznámeními o nových verzích a popisem významných změn v populárním +bitcoinovém páteřním software. + +## Novinky + +- **Návrat k tématu pročištění konsenzu:** Antoine Poinsot zaslal do + fóra Delving Bitcoin [příspěvek][poinsot cleanup], ve kterém připomíná + návrh Matta Coralla z roku 2019 na [pročištění konsenzu][topic consensus + cleanup] (viz [zpravodaj č. 36][news36 cleanup], _angl._). Na začátek + se pokouší kvantifikovat nejhorší scénáře několika problémů, které + by návrh odstranil, včetně možnosti vytvořit blok, jehož ověření + by na moderním laptopu zabralo přes tři minuty a na Raspberry Pi 4 kolem + 1,5 hodiny, schopnosti těžařů pomocí [útoku ohýbáním času][topic time warp] + („time warp attack”) ukrást odměny a snížit bezpečnost LN po + zhruba jednoměsíční přípravě či schopnosti klamem přinutit lehké klienty + k přijetí falešných transakcí ([CVE-2017-12842][topic cves]) a plné + uzly k odmítání validních bloků (viz [zpravodaj č. 37][news37 trees], _angl._). + + Nad rámec Corallova původního návrhu doporučuje Poinsot vypořádat + se se zbývajícím problémem [duplikovaných transakcí][topic duplicate + transactions], který začne postihovat plné uzly při výšce 1 983 702 (a již postihuje uzly + na testnetu). + + Všechny zmíněné problémy mají technicky jednoduchá řešení, která mohou + být nasazena soft forkem. Dříve nevržené řešení problému s pomalým ověřováním + bloků bylo mírně kontroverzní, jelikož by mohlo zneplatnit skripty, které + by teoreticky mohly být použity v předem podepsaných transakcích. Tím by + mohlo dojít k porušení pravidla na [zabraňování nechtěných konfiskací][topic + accidental confiscation] (viz [zpravodaj č. 37][news37 confiscation], _angl._). + Nejsme si vědomi žádného použití takového skriptu, ať již v desetileté + historii bitcoinu před původním návrhem či během pěti let po něm. Některá + použití by však byla nedetekovatelná, dokud by nebyla předem podepsaná transakce + zveřejněna. + + Pro odstranění této námitky Poinsot navrhl, aby byla upravená pravidla konsenzu + aplikována pouze na výstupy vytvořené po určité výšce bloku. Výstupy + vytvořené dříve by byly utratitelné dle starých pravidel. + +- **Výběr nových editorů BIPů:** Mark „Murch” Erhardt ve [vlákně][erhardt bip editors] + o přidání nových editorů BIPů navrhl, aby všichni „do konce pátku (5. dubna) uvedli + své důvody pro a proti jakémukoliv z kandidátů z vlákna. Pokud by někteří z kandidátů + obdrželi širokou podporu, mohli by být přidáni jako noví editoři následující pondělí (8. dubna).” + + V době psaní zpravodaje diskuze stále probíhala. Učiníme, co je v našich silách, abychom + o výsledcích informovali v příštím vydání zpravodaje. + +## 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 26.1][] je údržbovým vydáním této převládající implementace + plného uzlu. Jeho [poznámky k vydání][26.1 rn] popisují opravy několika chyb. + +- [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 k revizi + [navrhovaných témat pro testování][bcc testing]. + +- [HWI 3.0.0-rc1][] je kandidátem na vydání příští hlavní verze tohoto balíčku + poskytujícího jednotné rozhraní k několika různým hardwarovým podpisovým zařízením. + +## 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 #27307][] přináší sledování transakcí v mempoolu, které kolidují + s transakcemi patřícími peněžence vestavěné v Bitcoin Core, včetně transakcí + v mempoolu, které jsou v konfliktu s předky transakcí této peněženky. Je-li + kolidující transakce potvrzena, nemůže být transakce peněženky začleněna + do blockchainu, je tedy užitečné o konfliktech vědět. Kolidující transakce + z mempoolu jsou nyní obsaženy v novém poli `mempoolconflict` ve výsledku + volání `gettransaction` na nějakou transakci peněženky. Vstupy transakce + s kolizí v mempoolu mohou být znovu utraceny bez ručního zahození kolidující + transakce v mempoolu a jsou zahrnuty v zůstatku peněženky. + +- [Bitcoin Core #29242][] představuje pomocné funkce k porovnání dvou + [diagramů jednotkových poplatků][sdaftuar incentive compatibility] a k vyhodnocení + souladu ekonomických podnětů nahrazení clusterů až dvěma transakcemi. + Tyto funkce poskytnou základ nahrazování [balíčků][topic package relay] + poplatkem ([RBF][topic rbf]) clustery o maximální velikosti dva včetně + [transakcí do potvrzení topologicky omezenených][TRUC BIP draft] (TRUC, „Topologically + Restricted Until Confirmation”), známých též jako [transakce verze 3][topic v3 transaction + relay]. + +- [Core Lightning #7094][] odstraňuje několik funkcí, které byly předtím označeny za + zastaralé použitím nového způsobu zastarávání v Core Lightning (viz [zpravodaj č. 288][news288 + cln deprecation]). + +- [BDK #1351][] mění interpretaci parametru `stop_gap`, který nastavuje chování + [gap limitu][topic gap limits]. Jednou konkrétní změnou se přibližuje chování jiných + peněženek: `stop_gap` s hodnotou 10 znamená, že BDK bude generovat nové adresy + pro skenování transakcí tak dlouho, dokud nenalezne deset po sobě jdoucích adres bez + jakékoliv transakce. + +{% 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="27307,29242,7094,1351" %} +[bitcoin core 26.1]: https://bitcoincore.org/bin/bitcoin-core-26.1/ +[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/ +[poinsot cleanup]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710 +[news36 cleanup]: /en/newsletters/2019/03/05/#cleanup-soft-fork-proposal +[news37 confiscation]: /en/newsletters/2019/03/12/#cleanup-soft-fork-proposal-discussion +[erhardt bip editors]: https://gnusha.org/pi/bitcoindev/52a0d792-d99f-4360-ba34-0b12de183fef@murch.one/ +[sdaftuar incentive compatibility]: https://delvingbitcoin.org/t/mempool-incentive-compatibility/553 +[TRUC BIP draft]: https://github.com/bitcoin/bips/pull/1541 +[news288 cln deprecation]: /cs/newsletters/2024/02/07/#core-lightning-6936 +[26.1 rn]: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-26.1.md +[HWI 3.0.0-rc1]: https://github.com/bitcoin-core/HWI/releases/tag/3.0.0-rc.1 +[news37 trees]: /en/newsletters/2019/03/12/#bitcoin-core-vulnerability-disclosure 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/podcast.md b/en/podcast.md new file mode 100644 index 0000000000..dd4a292125 --- /dev/null +++ b/en/podcast.md @@ -0,0 +1,9 @@ +--- +layout: podcast +lang: en +title: Podcast +name: podcast +permalink: /en/podcast/ +share: false +version: 1 +--- diff --git a/en/publications.md b/en/publications.md index df098f4af7..cc29fdc383 100644 --- a/en/publications.md +++ b/en/publications.md @@ -7,24 +7,14 @@ permalink: /en/publications/ share: false version: 1 --- -{%- if jekyll.environment == 'future' -%} -- [Scaling book][]: a guide to effective practices and techniques - that engineers interacting with the Bitcoin block chain can adopt - today. - -- [Newsletters][]: a weekly summary of news about Bitcion and LN +- [Newsletters][]: a weekly summary of news about Bitcoin and LN development. - [Blog posts][]: Occasional updates and reference material from the Optech team. -## Latest publications - -{% else %} -{:.center} -Recent publications from our [blog posts][] and [newsletters][]. -{% endif %} +- [Podcast Episodes][]: Audio discussions of our newsletters. [blog posts]: /en/blog/ [newsletters]: /en/newsletters/ -[scaling book]: /en/scaling/ +[podcast episodes]: /en/podcast/ 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..16f14b136b 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) +
      {% 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/blog.md b/fr/blog.md new file mode 100644 index 0000000000..e3a923fdfd --- /dev/null +++ b/fr/blog.md @@ -0,0 +1,11 @@ +--- +layout: blog +lang: fr +title: Blog-fr +name: blog-fr +permalink: /fr/blog/ +share: false +version: 1 +--- + +Vous souhaitez participer à la traduction de nos publications ? Consultez la documentation [CONTRIBUTING](https://github.com/bitcoinops/bitcoinops.github.io/blob/master/CONTRIBUTING.md#translations), les rapports d'erreurs ou les PRs pour proposer des [tradcuctions françaises sur notre dépot Github](https://github.com/bitcoinops/bitcoinops.github.io/pulls?&q=label%3Alocalization-french) diff --git a/fr/newsletters.md b/fr/newsletters.md new file mode 100644 index 0000000000..99e6536bf9 --- /dev/null +++ b/fr/newsletters.md @@ -0,0 +1,12 @@ +--- +layout: newsletters +lang: fr +title: Newsletters-fr +name: newsletters-fr +permalink: /fr/newsletters/ +share: false +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 [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 new file mode 100644 index 0000000000..ba24ec035f --- /dev/null +++ b/fr/publications.md @@ -0,0 +1,23 @@ +--- +layout: publications +lang: fr +title: Publications-fr +name: publications-fr +permalink: /fr/publications/ +share: false +version: 1 +--- +{%- if jekyll.environment == 'future' -%} +- [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. + +## Dernières publications + +{% else %} +{:.center} +Publications récentes sur nos [blog posts][] et [newsletters][]. +{% endif %} + +[blog posts]: /fr/blog/ +[newsletters]: /fr/newsletters/ 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/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/brd/brd.png b/img/compatibility/brd/brd.png deleted file mode 100644 index 5066f368ff..0000000000 Binary files a/img/compatibility/brd/brd.png and /dev/null differ diff --git a/img/compatibility/brd/rbf/send-fee-options-expanded.png b/img/compatibility/brd/rbf/send-fee-options-expanded.png deleted file mode 100644 index ef04cdca7a..0000000000 Binary files a/img/compatibility/brd/rbf/send-fee-options-expanded.png and /dev/null differ diff --git a/img/compatibility/brd/rbf/send-screen-default.png b/img/compatibility/brd/rbf/send-screen-default.png deleted file mode 100644 index fc90fce38e..0000000000 Binary files a/img/compatibility/brd/rbf/send-screen-default.png and /dev/null differ diff --git a/img/compatibility/brd/rbf/send-transaction-confirmation.png b/img/compatibility/brd/rbf/send-transaction-confirmation.png deleted file mode 100644 index 8bdcb5b675..0000000000 Binary files a/img/compatibility/brd/rbf/send-transaction-confirmation.png and /dev/null differ diff --git a/img/compatibility/brd/rbf/transaction-details-incoming-rbf.png b/img/compatibility/brd/rbf/transaction-details-incoming-rbf.png deleted file mode 100644 index 16d2355c67..0000000000 Binary files a/img/compatibility/brd/rbf/transaction-details-incoming-rbf.png and /dev/null differ diff --git a/img/compatibility/brd/rbf/transaction-details-incoming-replacement.png b/img/compatibility/brd/rbf/transaction-details-incoming-replacement.png deleted file mode 100644 index 7644c45941..0000000000 Binary files a/img/compatibility/brd/rbf/transaction-details-incoming-replacement.png and /dev/null differ diff --git a/img/compatibility/brd/rbf/transaction-details-sent.png b/img/compatibility/brd/rbf/transaction-details-sent.png deleted file mode 100644 index ce9ae9ecd7..0000000000 Binary files a/img/compatibility/brd/rbf/transaction-details-sent.png and /dev/null differ diff --git a/img/compatibility/brd/rbf/transaction-list-incoming-rbf.png b/img/compatibility/brd/rbf/transaction-list-incoming-rbf.png deleted file mode 100644 index a9d035bfa1..0000000000 Binary files a/img/compatibility/brd/rbf/transaction-list-incoming-rbf.png and /dev/null differ diff --git a/img/compatibility/brd/rbf/transaction-list-incoming-replacement-confirmed.png b/img/compatibility/brd/rbf/transaction-list-incoming-replacement-confirmed.png deleted file mode 100644 index d6dd5295ee..0000000000 Binary files a/img/compatibility/brd/rbf/transaction-list-incoming-replacement-confirmed.png and /dev/null differ diff --git a/img/compatibility/brd/rbf/transaction-list-incoming-replacement.png b/img/compatibility/brd/rbf/transaction-list-incoming-replacement.png deleted file mode 100644 index 1cc4bc9390..0000000000 Binary files a/img/compatibility/brd/rbf/transaction-list-incoming-replacement.png and /dev/null differ diff --git a/img/compatibility/brd/segwit/receive-screen.png b/img/compatibility/brd/segwit/receive-screen.png deleted file mode 100644 index 2746ff2797..0000000000 Binary files a/img/compatibility/brd/segwit/receive-screen.png and /dev/null differ diff --git a/img/compatibility/brd/segwit/send-screen.png b/img/compatibility/brd/segwit/send-screen.png deleted file mode 100644 index 94f0af78aa..0000000000 Binary files a/img/compatibility/brd/segwit/send-screen.png and /dev/null differ diff --git a/img/compatibility/brd/segwit/sent-segwit-v1-details.png b/img/compatibility/brd/segwit/sent-segwit-v1-details.png deleted file mode 100644 index fa524bd2c5..0000000000 Binary files a/img/compatibility/brd/segwit/sent-segwit-v1-details.png and /dev/null differ diff --git a/img/compatibility/brd/segwit/settings-enable-segwit-details.png b/img/compatibility/brd/segwit/settings-enable-segwit-details.png deleted file mode 100644 index 1bdb0bc6a3..0000000000 Binary files a/img/compatibility/brd/segwit/settings-enable-segwit-details.png and /dev/null differ diff --git a/img/compatibility/brd/segwit/settings-enable-segwit.png b/img/compatibility/brd/segwit/settings-enable-segwit.png deleted file mode 100644 index faf01ec99b..0000000000 Binary files a/img/compatibility/brd/segwit/settings-enable-segwit.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 9a947a873d..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/mycelium.png b/img/compatibility/mycelium/mycelium.png deleted file mode 100755 index 4d238684dd..0000000000 Binary files a/img/compatibility/mycelium/mycelium.png and /dev/null differ diff --git a/img/compatibility/mycelium/rbf/send-miner-fee-options.png b/img/compatibility/mycelium/rbf/send-miner-fee-options.png deleted file mode 100644 index 663e60daf2..0000000000 Binary files a/img/compatibility/mycelium/rbf/send-miner-fee-options.png and /dev/null differ diff --git a/img/compatibility/mycelium/rbf/send-screen-default.png b/img/compatibility/mycelium/rbf/send-screen-default.png deleted file mode 100644 index e9f0d0506f..0000000000 Binary files a/img/compatibility/mycelium/rbf/send-screen-default.png and /dev/null differ diff --git a/img/compatibility/mycelium/rbf/transaction-details-sent.png b/img/compatibility/mycelium/rbf/transaction-details-sent.png deleted file mode 100644 index 96ceefc7d2..0000000000 Binary files a/img/compatibility/mycelium/rbf/transaction-details-sent.png and /dev/null differ diff --git a/img/compatibility/mycelium/rbf/transaction-list-incoming-rbf.png b/img/compatibility/mycelium/rbf/transaction-list-incoming-rbf.png deleted file mode 100644 index b0ba57030d..0000000000 Binary files a/img/compatibility/mycelium/rbf/transaction-list-incoming-rbf.png and /dev/null differ diff --git a/img/compatibility/mycelium/rbf/transaction-list-sent.png b/img/compatibility/mycelium/rbf/transaction-list-sent.png deleted file mode 100644 index cc51a0bccd..0000000000 Binary files a/img/compatibility/mycelium/rbf/transaction-list-sent.png and /dev/null differ diff --git a/img/compatibility/mycelium/segwit/receive-screen.png b/img/compatibility/mycelium/segwit/receive-screen.png deleted file mode 100644 index 24cf0feac2..0000000000 Binary files a/img/compatibility/mycelium/segwit/receive-screen.png and /dev/null differ diff --git a/img/compatibility/mycelium/segwit/send-screen-segwit-v1-error.png b/img/compatibility/mycelium/segwit/send-screen-segwit-v1-error.png deleted file mode 100644 index 12bff4e62d..0000000000 Binary files a/img/compatibility/mycelium/segwit/send-screen-segwit-v1-error.png and /dev/null differ diff --git a/img/compatibility/mycelium/segwit/send-screen.png b/img/compatibility/mycelium/segwit/send-screen.png deleted file mode 100644 index 51dc5e0370..0000000000 Binary files a/img/compatibility/mycelium/segwit/send-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/podcast/amazon.png b/img/podcast/amazon.png new file mode 100644 index 0000000000..764ad24cf5 Binary files /dev/null and b/img/podcast/amazon.png differ diff --git a/img/podcast/anchor.png b/img/podcast/anchor.png new file mode 100644 index 0000000000..13c882e014 Binary files /dev/null and b/img/podcast/anchor.png differ diff --git a/img/podcast/apple_podcasts.png b/img/podcast/apple_podcasts.png new file mode 100644 index 0000000000..b161bcdaf4 Binary files /dev/null and b/img/podcast/apple_podcasts.png differ diff --git a/img/podcast/castbox.png b/img/podcast/castbox.png new file mode 100644 index 0000000000..296825688b Binary files /dev/null and b/img/podcast/castbox.png differ diff --git a/img/podcast/google_podcasts.png b/img/podcast/google_podcasts.png new file mode 100644 index 0000000000..0f31b3c57e Binary files /dev/null and b/img/podcast/google_podcasts.png differ diff --git a/img/podcast/pocket_casts.png b/img/podcast/pocket_casts.png new file mode 100644 index 0000000000..915e78c2b6 Binary files /dev/null and b/img/podcast/pocket_casts.png differ diff --git a/img/podcast/podcast-index.png b/img/podcast/podcast-index.png new file mode 100644 index 0000000000..510b00aed8 Binary files /dev/null and b/img/podcast/podcast-index.png differ diff --git a/img/podcast/rss.png b/img/podcast/rss.png new file mode 100644 index 0000000000..278dd1b556 Binary files /dev/null and b/img/podcast/rss.png differ diff --git a/img/podcast/spotify.png b/img/podcast/spotify.png new file mode 100644 index 0000000000..9cf704c674 Binary files /dev/null and b/img/podcast/spotify.png differ diff --git a/img/posts/2023-03-tunable-commitment.dot b/img/posts/2023-03-tunable-commitment.dot new file mode 100644 index 0000000000..3da461b6f0 --- /dev/null +++ b/img/posts/2023-03-tunable-commitment.dot @@ -0,0 +1,44 @@ +digraph tunable { + +rankdir=LR; +ranksep=0.9; +splines=ortho; + +node [ shape = "box" ]; + +Funding [ label = "Funding", style = filled ]; +IndividualA [ label = "A", style = filled ]; +IndividualB [ label = "B", style = filled ]; + +StateA [ label = 0> ]; +StateB [ label = 0> ]; + +hidden_funding_spend [ shape = "none", label = "", width=0.001, height=0.001 ]; + +{ + node [ height = 0.9 ]; + CommitmentA [ label = A> ]; + CommitmentB [ label = B> ]; +} + +//Not confirmed +{ + node [ shape = none, width=0, height=0 ]; + OutputAtoA [label = "A" ]; OutputAtoB [ label = "B" ]; + OutputBtoA [label = "A" ]; OutputBtoB [label = "B" ]; +} + + +Funding -> hidden_funding_spend [ dir=none, style = "dotted" ]; +hidden_funding_spend -> {CommitmentA, CommitmentB} [ style = "dotted" ]; + + +IndividualA -> StateA -> CommitmentA; +IndividualB -> StateB -> CommitmentB; + +{ + CommitmentA -> {OutputAtoA, OutputAtoB} ; + CommitmentB -> {OutputBtoA, OutputBtoB} ; +} + +} diff --git a/img/posts/2023-03-tunable-commitment.dot.png b/img/posts/2023-03-tunable-commitment.dot.png new file mode 100644 index 0000000000..59ac030d2d Binary files /dev/null and b/img/posts/2023-03-tunable-commitment.dot.png differ diff --git a/img/posts/2023-03-tunable-dishonest-spend.dot b/img/posts/2023-03-tunable-dishonest-spend.dot new file mode 100644 index 0000000000..1c1bcf85eb --- /dev/null +++ b/img/posts/2023-03-tunable-dishonest-spend.dot @@ -0,0 +1,41 @@ +digraph tunable { + +rankdir=LR; +ranksep=0.9; +splines=ortho; + +node [ shape = "box" ]; + +IndividualB [ label = "B", style = filled ]; +IndividualA [ label = "A", style = filled ]; +Funding [ label = "Funding", style = filled ]; + +StateA [ label = 0> ]; +StateB [ label = 0>, style = filled ]; + +hidden_funding_spend [ shape = "none", label = "", width=0.001, height=0.001 ]; + +CommitmentA [ label = A>, height=0.9 ]; + +//Not confirmed +{ + node [ shape = none, width=0.001, height=0.001, label = "" ]; + OutputAtoA [label = "A"]; OutputAtoB [label = "B" ]; +} + + +Funding -> hidden_funding_spend [ dir=none, style = "dotted" ]; +hidden_funding_spend -> {CommitmentA} [ style = "dotted" ]; + + +IndividualA -> StateA -> CommitmentA; +IndividualB -> StateB; + +{ + CommitmentA -> {OutputAtoA, OutputAtoB} [ len = 0.1 ]; +} + +A [ style = filled ]; +StateB -> A; + +} diff --git a/img/posts/2023-03-tunable-dishonest-spend.dot.png b/img/posts/2023-03-tunable-dishonest-spend.dot.png new file mode 100644 index 0000000000..3c12fdd20b Binary files /dev/null and b/img/posts/2023-03-tunable-dishonest-spend.dot.png differ diff --git a/img/posts/2023-03-tunable-factory.dot b/img/posts/2023-03-tunable-factory.dot new file mode 100644 index 0000000000..93789de39d --- /dev/null +++ b/img/posts/2023-03-tunable-factory.dot @@ -0,0 +1,84 @@ +digraph tunable { + +rankdir=LR; +ranksep=0.9; +//splines=ortho; + +node [ shape = "box" ]; + +Funding [ label = "Funding", style = filled ]; +IndividualA [ label = "A", style = filled ]; +IndividualB [ label = "B", style = filled ]; + +StateA [ label = 0> ]; +StateAA0 [ label = 0.0> ]; +StateAA1 [ label = 0.0> ]; +StateB [ label = 0> ]; +StateBB0 [ label = 0.0> ]; +StateBB1 [ label = 0.0> ]; + +{ //hidden + node [ shape = "none", label = "", width=0.001, height=0.001 ]; + hidden_funding_spend; + hidden_funding_spend2; + hidden_funding_spend3; + hidden_prestate_a; + hidden_prestate_b; +} + +{ + CommitmentA [ label = A> ]; + CommitmentAA0 [ label = A.A> ]; + CommitmentAA1 [ label = A.A> ]; + CommitmentB [ label = B> ]; + CommitmentBB0 [ label = B.B> ]; + CommitmentBB1 [ label = B.B> ]; +} + +OutputAtoAB [ label = "AB" ]; + +//Not confirmed +{ + node [ shape = none, width=0.001, height=0.001, label = "" ]; + OutputAtoC [ label = "C" ]; OutputAtoD [ label = "D" ]; + OutputBtoC [ label = "C" ]; OutputBtoD [ label = "D" ]; + OutputAA0toA [ label = "A" ]; OutputAA0toB [ label = "B" ]; + OutputAA1toA [ label = "A" ]; OutputAA1toB [ label = "B" ]; + OutputBB0toA [ label = "A" ]; OutputBB0toB [ label = "B" ]; + OutputBB1toA [ label = "A" ]; OutputBB1toB [ label = "B" ]; +} + +OutputBtoAB [ label = "AB" ]; + +Funding -> hidden_funding_spend [ dir=none, style = "dotted" ]; +hidden_funding_spend -> {CommitmentA, CommitmentB} [ style = "dotted" ]; + + +IndividualA -> StateA -> CommitmentA; +IndividualA -> hidden_prestate_a [ style = "dotted", dir=none ]; +hidden_prestate_a -> { StateAA0, StateAA1} [ style = "dotted" ]; +StateAA0 -> CommitmentAA0; +StateAA1 -> CommitmentAA1; + +IndividualB -> StateB -> CommitmentB; +IndividualB -> hidden_prestate_b [ style = "dotted", dir=none ]; +hidden_prestate_b -> { StateBB0, StateBB1} [ style = "dotted" ]; +StateBB0 -> CommitmentBB0; +StateBB1 -> CommitmentBB1; + +{ + CommitmentA -> {OutputAtoAB, OutputAtoC, OutputAtoD}; + CommitmentB -> {OutputBtoAB, OutputBtoC, OutputBtoD}; +} + +OutputAtoAB -> hidden_funding_spend2 [ dir=none, style = "dotted" ]; +OutputBtoAB -> hidden_funding_spend3 [ dir=none, style = "dotted" ]; + +hidden_funding_spend2 -> {CommitmentAA0, CommitmentBB0} [ style = dotted ]; +hidden_funding_spend3 -> {CommitmentAA1, CommitmentBB1} [ style = dotted ]; + +CommitmentAA0 -> {OutputAA0toA, OutputAA0toB}; +CommitmentAA1 -> {OutputAA1toA, OutputAA1toB}; +CommitmentBB0 -> {OutputBB0toA, OutputBB0toB}; +CommitmentBB1 -> {OutputBB1toA, OutputBB1toB}; +} diff --git a/img/posts/2023-03-tunable-factory.dot.png b/img/posts/2023-03-tunable-factory.dot.png new file mode 100644 index 0000000000..0915a6a148 Binary files /dev/null and b/img/posts/2023-03-tunable-factory.dot.png differ diff --git a/img/posts/2023-03-tunable-funding.dot b/img/posts/2023-03-tunable-funding.dot new file mode 100644 index 0000000000..58cf65ba04 --- /dev/null +++ b/img/posts/2023-03-tunable-funding.dot @@ -0,0 +1,19 @@ +digraph tunable { + +rankdir=LR; +ranksep=0.3; +splines=ortho; + +node [ shape = "box" ]; + +Funding [ label = "Funding" ] + +{ + node [ style = filled ]; + A; + B; +} + +{A, B} -> Funding; + +} diff --git a/img/posts/2023-03-tunable-funding.dot.png b/img/posts/2023-03-tunable-funding.dot.png new file mode 100644 index 0000000000..0e10487604 Binary files /dev/null and b/img/posts/2023-03-tunable-funding.dot.png differ diff --git a/img/posts/2023-03-tunable-honest-spend.dot b/img/posts/2023-03-tunable-honest-spend.dot new file mode 100644 index 0000000000..2c5212c27c --- /dev/null +++ b/img/posts/2023-03-tunable-honest-spend.dot @@ -0,0 +1,36 @@ +digraph tunable { + +rankdir=LR; +ranksep=0.9; +splines=ortho; + +node [ shape = "box" ]; + +IndividualB [ label = "B", style = filled ]; +IndividualA [ label = "A", style = filled ]; +Funding [ label = "Funding", style = filled ]; + +StateA [ label = 0>, style = filled ]; + +//hidden_funding_spend [ shape = "none", label = "", width=0.001, height=0.001 ]; + +CommitmentA [ label = A>, style = filled, height=0.9 ]; + +//Not confirmed +{ + node [ shape = none, width=0.001, height=0.001, label = "" ]; + OutputAtoA [ label = "A" ]; OutputAtoB [ label = "B" ]; +} + + +//Funding -> hidden_funding_spend [ dir=none, style = "dotted" ]; +Funding -> CommitmentA [ minlen=2 ]; + + +IndividualA -> StateA -> CommitmentA; + +{ + CommitmentA -> {OutputAtoA, OutputAtoB} [ len = 0.1 ]; +} + +} diff --git a/img/posts/2023-03-tunable-honest-spend.dot.png b/img/posts/2023-03-tunable-honest-spend.dot.png new file mode 100644 index 0000000000..c235a671a0 Binary files /dev/null and b/img/posts/2023-03-tunable-honest-spend.dot.png differ diff --git a/img/posts/2023-03-tunable-multiparty.dot b/img/posts/2023-03-tunable-multiparty.dot new file mode 100644 index 0000000000..7d89c6e83d --- /dev/null +++ b/img/posts/2023-03-tunable-multiparty.dot @@ -0,0 +1,56 @@ +digraph tunable { + +rankdir=LR; +ranksep=0.9; +nodesep=0.05; +//splines=ortho; + +node [ shape = "box" ]; + +Funding [ label = "Funding", style = filled ]; +IndividualA [ label = "A", style = filled ]; +IndividualB [ label = "B", style = filled ]; +IndividualC [ label = "C", style = filled ]; +IndividualD [ label = "D", style = filled ]; + +StateA [ label = 0> ]; +StateB [ label = 0> ]; +StateC [ label = 0> ]; +StateD [ label = 0> ]; + +hidden_funding_spend [ shape = "none", label = "", width=0.001, height=0.001 ]; + +{ + node [ height = 0.5 ]; + CommitmentA [ label = A> ]; + CommitmentB [ label = B> ]; + CommitmentC [ label = C> ]; + CommitmentD [ label = D> ]; +} + +//Not confirmed +{ + node [ shape = none, width=0.001, height=0.001, label = "" ]; + OutputAtoA [ label = "A" ]; OutputAtoB [ label = "B" ]; OutputAtoC [ label = "C" ]; OutputAtoD [ label = "D" ]; + OutputBtoA [ label = "A" ]; OutputBtoB [ label = "B" ]; OutputBtoC [ label = "C" ]; OutputBtoD [ label = "D" ]; + OutputCtoA [ label = "A" ]; OutputCtoB [ label = "B" ]; OutputCtoC [ label = "C" ]; OutputCtoD [ label = "D" ]; + OutputDtoA [ label = "A" ]; OutputDtoB [ label = "B" ]; OutputDtoC [ label = "C" ]; OutputDtoD [ label = "D" ]; +} + +Funding -> hidden_funding_spend [ dir=none, style = "dotted" ]; +hidden_funding_spend -> {CommitmentA, CommitmentB, CommitmentC, CommitmentD} [ style = "dotted" ]; + + +IndividualA -> StateA -> CommitmentA; +IndividualB -> StateB -> CommitmentB; +IndividualC -> StateC -> CommitmentC; +IndividualD -> StateD -> CommitmentD; + +{ + CommitmentA -> {OutputAtoA, OutputAtoB, OutputAtoC, OutputAtoD}; + CommitmentB -> {OutputBtoA, OutputBtoB, OutputBtoC, OutputBtoD}; + CommitmentC -> {OutputCtoA, OutputCtoB, OutputCtoC, OutputCtoD}; + CommitmentD -> {OutputDtoA, OutputDtoB, OutputDtoC, OutputDtoD}; +} + +} diff --git a/img/posts/2023-03-tunable-multiparty.dot.png b/img/posts/2023-03-tunable-multiparty.dot.png new file mode 100644 index 0000000000..f643d80cad Binary files /dev/null and b/img/posts/2023-03-tunable-multiparty.dot.png differ diff --git a/img/posts/2023-04-splicing1.dot b/img/posts/2023-04-splicing1.dot new file mode 100644 index 0000000000..2cc9995a3e --- /dev/null +++ b/img/posts/2023-04-splicing1.dot @@ -0,0 +1,82 @@ +digraph lightning_network { + rankdir="LR"; + node [shape=box, style="filled", color="black", fontcolor="black", fillcolor="white"]; + + subgraph cluster_splice_out { + label="Splice Out"; + + "Funding2" -> "Splice Out"; + "Splice Out" -> "Alice1"; + "Splice Out" -> "Commitment2"; + "Commitment2" -> "HTLC2-1"; + "Commitment2" -> "HTLC2-2"; + "Commitment2" -> "HTLC2-3"; + + Funding2 -> oricom2; + oricom2 -> {HTLCxa, HTLCxb, HTLCxc}; + HTLCxa [label="", style=invis, width=0, height=0]; + HTLCxb [label="", style=invis, width=0, height=0]; + HTLCxc [label="", style=invis, width=0, height=0]; + + oricom2 [ style = dashed, label = "Commitment\n(Original)" width = 0.5, height = 0.5 ] + + "Funding2" [label="Funding", fillcolor="silver"]; + "Splice Out" [label="New Funding"]; + "Alice1" [label="Alice"]; + "Commitment2" [label="Commitment\n(New)", style=dashed]; + "HTLC2-1" [label="", style=invis, width=0, height=0]; + "HTLC2-2" [label="", style=invis, width=0, height=0]; + //"HTLC2-2" [label="HTLCs", style="filled", shape=plaintext]; + "HTLC2-3" [label="", style=invis, width=0, height=0]; + } + + subgraph cluster_new_funding { + label="Splice In"; + + "Funding3" -> "Splice In"; + "Alice2" -> "Splice In"; + "Splice In" -> "Commitment3"; + "Commitment3" -> "HTLC3-1"; + "Commitment3" -> "HTLC3-2"; + "Commitment3" -> "HTLC3-3"; + + Funding3 -> oricom3; + oricom3 -> {HTLCya, HTLCyb, HTLCyc}; + HTLCya [label="", style=invis, width=0, height=0]; + HTLCyb [label="", style=invis, width=0, height=0]; + HTLCyc [label="", style=invis, width=0, height=0]; + + oricom3 [ style = dashed, label = "Commitment\n(Original)" width = 0.5, height = 0.5 ] + + "Funding3" [label="Funding", fillcolor="silver"]; + "Alice2" [label="Alice", fillcolor="silver"]; + "Splice In" [label="New Funding"]; + "Commitment3" [label="Commitment\n(New)", style=dashed]; + "HTLC3-1" [label="", style=invis, width=0, height=0]; + "HTLC3-2" [label="", style=invis, width=0, height=0]; + //"HTLC3-2" [label="HTLCs", style="filled", shape=plaintext]; + "HTLC3-3" [label="", style=invis, width=0, height=0]; + } + + subgraph cluster_before_splicing { + label="State before splicing"; + + "Funding1" -> "Commitment1"; + "Commitment1" -> "HTLC1-1"; + "Commitment1" -> "HTLC1-2"; + "Commitment1" -> "HTLC1-3"; + + "Funding1" [label="Funding", fillcolor="silver"]; + "Commitment1" [label="Commitment\n(Original)", style=dashed]; + "HTLC1-1" [label="", style=invis, width=0, height=0]; + "HTLC1-2" [label="HTLCs", style="filled", shape=plaintext]; + "HTLC1-3" [label="", style=invis, width=0, height=0]; + + "HTLC1-2" -> foo [style=invis]; + foo [ style=invis, label = "", width=0.001, height=0]; + } + + labelloc=b + label="Shaded: confirmed\ \ \ \ \ \ \ Dashed: kept offchain unless needed" +} + diff --git a/img/posts/2023-04-splicing1.dot.png b/img/posts/2023-04-splicing1.dot.png new file mode 100644 index 0000000000..c7f84b9187 Binary files /dev/null and b/img/posts/2023-04-splicing1.dot.png differ diff --git a/img/posts/2023-10-cltv-expiry-delta-cycling.gnuplot b/img/posts/2023-10-cltv-expiry-delta-cycling.gnuplot new file mode 100644 index 0000000000..7a8ab365a1 --- /dev/null +++ b/img/posts/2023-10-cltv-expiry-delta-cycling.gnuplot @@ -0,0 +1,40 @@ +# Riard's numbers: "Default setting: Eclair 144, Core-Lightning 34, LND +# 80 and LDK 72." + +unset key + + +set terminal pngcairo size 800,400 +set output "output.png" + +set style line 1 lt 1 lc rgb "black" lw 2 +set style line 2 dashtype 2 linewidth 2 lc rgb "gray" + + + +set arrow from 144, graph 0 to 144, graph 1 nohead ls 2 +set label "Eclair" at 140, graph 0.82 rotate left + +set arrow from 80, graph 0 to 80, graph 1 nohead ls 2 +set label "LND" at 84, graph 0.77 rotate left + +set arrow from 72, graph 0 to 72, graph 1 nohead ls 2 +set label "LDK" at 68, graph 0.77 rotate left + +set arrow from 34, graph 0 to 34, graph 1 nohead ls 2 +set label "Core Lightning" at 30, graph 0.40 rotate left + +set label "30 seconds" at 150, graph 0.95 font "Courier-Italic" +set label "6 seconds" at 150, graph 0.76 font "Courier-Italic" +set label "Average time\nper block that\nany HTLC spend is\nin miner mempools" at 150, graph 0.56 font "Courier-Italic" +set label "0.6 seconds" at 150, graph 0.12 font "Courier-Italic" + +set xlabel "Blocks (CLTV expiry delta)" +set ylabel "Probability attack will fail within x blocks" + +set format y "%.0f%%" +set ytics 20 +set xtics 40 + +plot [1:200] 100*(1 - 0.999**x) ls 1, 100*(1 - 0.99**x) ls 1, 100*(1 - 0.95**x) ls 1 + diff --git a/img/posts/2023-10-cltv-expiry-delta-cycling.png b/img/posts/2023-10-cltv-expiry-delta-cycling.png new file mode 100644 index 0000000000..32cfd9c1b3 Binary files /dev/null and b/img/posts/2023-10-cltv-expiry-delta-cycling.png differ diff --git a/img/posts/2023-12-clusterings.data b/img/posts/2023-12-clusterings.data new file mode 100644 index 0000000000..a39fe1d782 --- /dev/null +++ b/img/posts/2023-12-clusterings.data @@ -0,0 +1,6 @@ +# size fee size fee size fee +0 0 0 0 0 0 +1 20 1 10 1 25 +3 30 4 28 3 31 +6 45 6 34 5.5 37 +12 50 12 50 12 50 diff --git a/img/posts/2023-12-comparable-chunkings.gnuplot b/img/posts/2023-12-comparable-chunkings.gnuplot new file mode 100644 index 0000000000..084e1c2e82 --- /dev/null +++ b/img/posts/2023-12-comparable-chunkings.gnuplot @@ -0,0 +1,19 @@ +set terminal pngcairo size 800,200 + +set style line 1 lc rgb 'black' lt 1 lw 3 # Black line style +set style line 2 lc rgb 'grey' lt 1 lw 3 # Grey line style + +set key off # Turn off the legend + +unset xtics +unset ytics +set xlabel "Accumulated weight (vbytes)" +set ylabel "Accumulated fees" + +set output '2023-12-comparable-chunkings.png' +plot '2023-12-clusterings.data' using 1:2 with linespoints linestyle 1, \ + '2023-12-clusterings.data' using 3:4 with linespoints linestyle 2 + +set output '2023-12-incomparable-chunkings.png' +plot '2023-12-clusterings.data' using 1:2 with linespoints linestyle 1, \ + '2023-12-clusterings.data' using 5:6 with linespoints linestyle 2 diff --git a/img/posts/2023-12-comparable-chunkings.png b/img/posts/2023-12-comparable-chunkings.png new file mode 100644 index 0000000000..5f09bf4bf7 Binary files /dev/null and b/img/posts/2023-12-comparable-chunkings.png differ diff --git a/img/posts/2023-12-incomparable-chunkings.png b/img/posts/2023-12-incomparable-chunkings.png new file mode 100644 index 0000000000..eca45431c3 Binary files /dev/null and b/img/posts/2023-12-incomparable-chunkings.png 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/bitgo-musig/musig-taproot-tree.png b/img/posts/bitgo-musig/musig-taproot-tree.png new file mode 100644 index 0000000000..035b9291f4 Binary files /dev/null and b/img/posts/bitgo-musig/musig-taproot-tree.png differ diff --git a/img/posts/specials/input-output-weights.png b/img/posts/specials/input-output-weights.png new file mode 100644 index 0000000000..851247b957 Binary files /dev/null and b/img/posts/specials/input-output-weights.png differ diff --git a/img/supporters/xapo.png b/img/supporters/xapo.png index 5f1a96d662..a65eaa0a9d 100644 Binary files a/img/supporters/xapo.png and b/img/supporters/xapo.png differ 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 9cd7f3692b..6b2da059e0 100644 --- a/index.md +++ b/index.md @@ -11,26 +11,26 @@ 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], and help facilitate improved relations between businesses +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/ -[about]: /about -[compatibility]: /en/compatibility/ +[podcast]: /en/podcast/ +[about]: /en/about +[matrix]: /en/matrix/ {% assign posts_en = site.posts | where:"lang","en" %} -

      Recent newsletters and blog posts

      +

      Recent newsletters, blog posts, and podcasts

        - {%- for post in posts_en limit:3 -%} + {%- for post in posts_en limit:5 -%}
      • {%- assign date_format = site.minima.date_format | default: "%b %-d, %Y" -%} {{ post.date | date: date_format }} diff --git a/ja/blog.md b/ja/blog.md index 2a98521b28..97e34d6c57 100644 --- a/ja/blog.md +++ b/ja/blog.md @@ -8,8 +8,7 @@ share: false version: 1 --- -_Would you like to help translate our publications? See the [CONTRIBUTING -documentation](https://github.com/bitcoinops/bitcoinops.github.io/blob/master/CONTRIBUTING.md#translations) -and the [Japanese translation issues and -PRs](https://github.com/bitcoinops/bitcoinops.github.io/pulls?&q=label%3Alocalization-japanese) -in our github repo._ +_記事の翻訳を手伝ってみませんか？Githubリポジトリの[CONTRIBUTINGドキュメント +](https://github.com/bitcoinops/bitcoinops.github.io/blob/master/CONTRIBUTING.md#translations)と +[日本語翻訳のIssueとPR](https://github.com/bitcoinops/bitcoinops.github.io/pulls?&q=label%3Alocalization-japanese)を +ご覧ください。_ 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/ja/newsletters.md b/ja/newsletters.md index 1980e3f01a..de55671a92 100644 --- a/ja/newsletters.md +++ b/ja/newsletters.md @@ -8,8 +8,7 @@ share: false version: 1 --- -_Would you like to help translate our newsletters? See the [CONTRIBUTING -documentation](https://github.com/bitcoinops/bitcoinops.github.io/blob/master/CONTRIBUTING.md#translations) -and the [Japanese translation issues and -PRs](https://github.com/bitcoinops/bitcoinops.github.io/pulls?&q=label%3Alocalization-japanese) -in our github repo._ +_ニュースレターの翻訳を手伝ってみませんか？Githubリポジトリの[CONTRIBUTINGドキュメント +](https://github.com/bitcoinops/bitcoinops.github.io/blob/master/CONTRIBUTING.md#translations)と +[日本語翻訳のIssueとPR](https://github.com/bitcoinops/bitcoinops.github.io/pulls?&q=label%3Alocalization-japanese)を +ご覧ください。_ diff --git a/ja/publications.md b/ja/publications.md index ff20cb3dfa..f66e11db12 100644 --- a/ja/publications.md +++ b/ja/publications.md @@ -7,14 +7,18 @@ permalink: /ja/publications/ share: false version: 1 --- -_Would you like to help translate our publications? See the [CONTRIBUTING -documentation](https://github.com/bitcoinops/bitcoinops.github.io/blob/master/CONTRIBUTING.md#translations) -and the [Japanese translation issues and -PRs](https://github.com/bitcoinops/bitcoinops.github.io/pulls?&q=label%3Alocalization-japanese) -in our github repo._ -{:.center} -Recent publications from our [blog posts][] and [newsletters][]. +_記事の翻訳を手伝ってみませんか？Githubリポジトリの[CONTRIBUTINGドキュメント +](https://github.com/bitcoinops/bitcoinops.github.io/blob/master/CONTRIBUTING.md#translations)と +[日本語翻訳のIssueとPR](https://github.com/bitcoinops/bitcoinops.github.io/pulls?&q=label%3Alocalization-japanese)を +ご覧ください。_ + +- [ニュースレター][newsletters]: BitcoinおよびLNの開発に関するニュースを毎週まとめてお届けします。 + +- [ブログ記事][blog posts]: Optechチームからの最新情報と参考資料。 + +- [ポッドキャストエピソード][podcast episodes]: ニュースレターの音声ディスカッション。 [blog posts]: /ja/blog/ [newsletters]: /ja/newsletters/ +[podcast episodes]: /en/podcast/ 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 new file mode 100644 index 0000000000..65f165c080 --- /dev/null +++ b/topics.json @@ -0,0 +1,23 @@ +--- +--- +{% capture raw_categories %} +{%- for topic in site.topics -%} + {%- for category in topic.categories -%} + {{category}}| + {%- endfor -%} +{%- endfor -%} +{% endcapture %} +{% assign categories = raw_categories | split: "|" | sort_natural | uniq %} +[ + {% for topic in site.topics %} + {% assign topic_slug = topic.shortname | default: topic.title | slugify %} + { + "title": {{ topic.title | jsonify }}, + "slug": {{ topic_slug | jsonify }}, + "optech_url": "{{ site.url }}{{ topic.url }}", + "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/