diff --git a/_config.yml b/_config.yml
index c65111a3e..3ce8a2228 100644
--- a/_config.yml
+++ b/_config.yml
@@ -84,5 +84,7 @@ languages:
name: German
- code: fr
name: French
+ - code: pt
+ name: Portuguese
## In-text aliases
trb: "709,632" # TapRoot Block (activation)
diff --git a/_posts/pt/newsletters/2025-06-06-newsletter.md b/_posts/pt/newsletters/2025-06-06-newsletter.md
new file mode 100644
index 000000000..7d4fa4be9
--- /dev/null
+++ b/_posts/pt/newsletters/2025-06-06-newsletter.md
@@ -0,0 +1,194 @@
+---
+title: 'Newsletter Bitcoin Optech #357'
+permalink: /pt/newsletters/2025/06/06/
+name: 2025-06-06-newsletter
+slug: 2025-06-06-newsletter
+type: newsletter
+layout: newsletter
+lang: pt
+---
+A newsletter desta semana compartilha uma análise sobre sincronização de full-nodes
+sem witness antigas. Também incluídas estão nossas seções regulares com
+descrições de discussões sobre mudanças de consenso, anúncios de
+novos lançamentos e candidatos a lançamento, e resumos de mudanças notáveis em
+software popular de infraestrutura do Bitcoin.
+
+## Notícias
+
+- **Sincronizando nós completos sem dados de testemunha (witness):** Jose SK [postou][sk nowit]
+ no Delving Bitcoin um resumo de uma [análise][sk nowit gist] que ele
+ fez sobre os tradeoffs de segurança de permitir que nós-completos recém-iniciados
+ com uma configuração em particular evitem baixar alguns
+ dados da blockchain. Por padrão, nós Bitcoin Core usam a
+ configuração `assumevalid` que pula a validação de scripts
+ em blocos criados mais de um mês ou dois antes do lançamento da
+ versão do Bitcoin Core sendo executada. Embora desabilitado por padrão, muitos
+ usuários do Bitcoin Core também definem uma configuração `prune` que
+ exclui blocos algum tempo após validá-los (por quanto tempo os blocos são
+ mantidos depende do tamanho dos blocos e da configuração específica selecionada
+ pelo usuário).
+
+ SK argumenta que dados de testemunha (witness), que são usados apenas para validar
+ scripts, não deveriam ser baixados por nós prunados para blocos assumevalid
+ porque eles não os usarão para validar scripts e eventualmente serão excluídos.
+ Pular o download de testemunhas "pode reduzir o uso de banda em mais de 40%", ele escreve.
+
+ Ruben Somsen [argumenta][somsen nowit] que isso muda o modelo de segurança
+ até certo ponto. Embora scripts não sejam validados, os
+ dados baixados são validados contra o commitment da raiz merkle do cabeçalho do bloco
+ para a transação coinbase para os dados da testemunha.
+ Isso garante que os dados estavam disponíveis e não corrompidos no momento em que o
+ nó foi inicialmente sincronizado. Se ninguém rotineiramente valida a
+ existência dos dados, eles poderiam concebivelmente ser perdidos, como [aconteceu][ripple loss]
+ com pelo menos uma altcoin.
+
+ A discussão estava em andamento no momento da escrita.
+
+## Mudando consenso
+
+_Uma seção mensal resumindo propostas e discussões sobre mudanças
+nas regras de consenso do Bitcoin._
+
+- **Relatório de computação quântica:** Clara Shikhelman [postou][shikelman
+ quantum] no Delving Bitcoin o resumo de um [relatório][sm report] que ela
+ co-autorou com Anthony Milton sobre os riscos para usuários Bitcoin de
+ computadores quânticos rápidos, uma visão geral de várias vias para [resistência
+ quântica][topic quantum resistance], e uma análise de compensações
+ envolvidas na atualização do protocolo do Bitcoin. Os autores encontraram 4 a 10
+ milhões de BTC potencialmente vulneráveis a roubo quântico, alguma
+ mitigação é agora possível, e é improvável que a mineração do Bitcoin seja
+ ameaçada pela computação quântica no curto ou médio prazo, e
+ atualizar requer acordo generalizado.
+
+- **Limite de peso de transação com exceção para prevenir confisco:**
+ Vojtěch Strnad [postou][strnad limit] no Delving Bitcoin a proposta de uma
+ ideia de mudança de consenso para limitar o peso máximo da maioria
+ das transações em um bloco. A regra simples apenas permitiria uma transação
+ maior que 400.000 unidades de peso (100.000 vbytes) em um bloco se fosse
+ a única transação naquele bloco além da transação coinbase.
+ Strnad e outros descreveram a motivação para limitar o peso máximo
+ da transação:
+
+ - _Otimização de template de bloco mais fácil:_ é mais fácil encontrar uma
+ solução quase ótima para o [problema da mochila][] quanto menores forem os
+ itens comparados ao limite geral. Isso é parcialmente
+ devido à minimização da quantidade de espaço sobrado no final, com
+ itens menores deixando menos espaço não utilizado.
+
+ - _Política de retransmissão mais fácil:_ a política para retransmitir transações não confirmadas
+ entre nós prevê quais transações serão
+ mineradas para evitar desperdiçar largura de banda. Transações gigantes tornam
+ previsões precisas mais difíceis, pois mesmo uma pequena mudança na taxa de topo pode causar
+ que sejam atrasadas ou removidas.
+
+ - _Evitando centralização de mineração:_ garantir que nós completos de retransmissão sejam
+ capazes de lidar com quase todas as transações impede que usuários de transações especiais
+ precisem pagar [taxas fora de banda][topic
+ out-of-band fees], o que pode levar à centralização de mineração.
+
+ Gregory Sanders [notou][sanders limit] que poderia ser razoável
+ simplesmente fazer um soft fork de limite de peso máximo sem exceções baseado
+ na política de retransmissão consistente de 12 anos do Bitcoin Core. Gregory
+ Maxwell [adicionou][maxwell limit] que transações gastando apenas UTXOs
+ criados antes do soft fork poderiam ter uma exceção permitida para prevenir
+ confisco, e que um [soft fork transitório][topic transitory soft
+ forks] permitiria que a restrição expirasse se a
+ comunidade decidisse não renová-la.
+
+ Uma discussão adicional examinou as necessidades de partes querendo
+ transações grandes, principalmente usuários [BitVM][topic acc] no curto prazo,
+ e se abordagens alternativas estavam disponíveis para eles.
+
+- **Removendo saídas do conjunto UTXO baseado em valor e tempo:** Robin
+ Linus [postou][linus dust] no Delving Bitcoin para propor um soft fork
+ para remover saídas de baixo valor do conjunto UTXO após algum
+ tempo. Várias variações da ideia foram discutidas, sendo as duas
+ principais alternativas:
+
+ - _Destruir fundos antigos não econômicos:_ saídas de pequeno valor que não
+ foram gastas por muito tempo se tornariam ingastáveis.
+
+ - _Requerer que fundos antigos não econômicos sejam gastos com prova de existência:_
+ [utreexo][topic utreexo] ou um sistema similar poderia ser usado para permitir
+ que uma transação prove que as saídas que ela gasta são parte do
+ UTXO set. Saídas antigas e [não econômicas][topic uneconomical outputs] precisariam
+ incluir esta prova, mas saídas mais novas e de maior valor ainda seriam
+ armazenadas no conjunto UTXO.
+
+ Qualquer solução efetivamente limitaria o tamanho máximo do conjunto UTXO
+ (assumindo um valor mínimo e o limite de 21 milhões de bitcoins).
+ Vários aspectos técnicos interessantes de um design foram discutidos,
+ incluindo alternativas às provas Utreexo para esta aplicação que
+ poderiam ser mais práticas.
+
+## Lançamentos e candidatos a lançamento
+
+_Novos lançamentos e candidatos a lançamento para projetos populares de infraestrutura
+do Bitcoin. Por favor, considere atualizar para novos lançamentos ou ajudar a testar
+candidatos a lançamento._
+
+- [Core Lightning 25.05rc1][] é um candidato a lançamento para a próxima versão principal
+ desta implementação popular de nó LN.
+
+- [LND 0.19.1-beta.rc1][] é um candidato a lançamento para uma versão de manutenção
+ desta implementação popular de nó LN.
+
+## Mudanças notáveis em código e documentação
+
+_Mudanças recentes notáveis no [Bitcoin Core][bitcoin core repo], [Core
+Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo],
+[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet
+Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay
+Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement
+Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo],
+[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition
+repo], e [BINANAs][binana repo]._
+
+- [Bitcoin Core #32582][] adiciona novo logging para medir o desempenho da
+ [reconstrução de bloco compacto][topic compact block relay] rastreando o
+ tamanho total de transações que um nó solicita de seus pares
+ (`getblocktxn`), o número e tamanho total de transações que um nó envia
+ para seus pares (`blocktxn`), e adicionando um timestamp no início de
+ `PartiallyDownloadedBlock::InitData()` para rastrear quanto tempo apenas o passo
+ de busca no mempool leva (em modos de alta e baixa largura de banda). Veja Newsletter
+ [#315][news315 compact] para um relatório de estatísticas anterior sobre reconstrução
+ de bloco compacto.
+
+- [Bitcoin Core #31375][] adiciona uma nova ferramenta CLI `bitcoin -m` que envolve e
+ executa os binários [multiprocesso][multiprocess project] `bitcoin node`
+ (`bitcoind`), `bitcoin gui` (`bitcoinqt`), `bitcoin rpc` (`bitcoin-cli
+ -named`). Atualmente, estes funcionam da mesma forma que os
+ binários monolíticos, exceto que suportam a opção `-ipcbind` (veja Newsletter
+ [#320][news320 ipc]), mas melhorias futuras permitirão que um operador de nó
+ inicie e pare componentes independentemente em diferentes máquinas e
+ ambientes. Veja [Newsletter #353][news353 pr review] para um Bitcoin Core PR
+ Review Club cobrindo este PR.
+
+- [BIPs #1483][] incorpora [BIP77][] que propõe [payjoin v2][topic payjoin], uma
+ variante assíncrona sem servidor na qual o remetente e receptor entregam seus
+ PSBTs criptografados para um servidor de diretório payjoin que apenas armazena e encaminha
+ mensagens. Como o diretório não pode ler ou alterar as cargas úteis, nenhuma carteira
+ precisa hospedar um servidor público ou estar online ao mesmo tempo. Veja Newsletter
+ [#264][news264 payjoin] para contexto adicional sobre payjoin v2.
+
+{% include snippets/recap-ad.md when="2025-06-10 16:30" %}
+{% include references.md %}
+{% include linkers/issues.md v=2 issues="32582,31375,1483" %}
+[Core Lightning 25.05rc1]: https://github.com/ElementsProject/lightning/releases/tag/v25.05rc1
+[ripple loss]: https://x.com/JoelKatz/status/1919233214750892305
+[sk nowit]: https://delvingbitcoin.org/t/witnessless-sync-for-pruned-nodes/1742/
+[sk nowit gist]: https://gist.github.com/JoseSK999/df0a2a014c7d9b626df1e2b19ccc7fb1
+[somsen nowit]: https://gist.github.com/JoseSK999/df0a2a014c7d9b626df1e2b19ccc7fb1?permalink_comment_id=5597316#gistcomment-5597316
+[shikelman quantum]: https://delvingbitcoin.org/t/bitcoin-and-quantum-computing/1730/
+[sm report]: https://chaincode.com/bitcoin-post-quantum.pdf
+[strnad limit]: https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/
+[problema da mochila]: https://en.wikipedia.org/wiki/Knapsack_problem
+[sanders limit]: https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/2
+[maxwell limit]: https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/4
+[linus dust]: https://delvingbitcoin.org/t/dust-expiry-clean-the-utxo-set-from-spam/1707/
+[lnd 0.19.1-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.1-beta.rc1
+[news315 compact]: /pt/newsletters/2024/08/09/#statistics-on-compact-block-reconstruction
+[multiprocess project]: https://github.com/ryanofsky/bitcoin/blob/pr/ipc/doc/design/multiprocess.md
+[news320 ipc]: /pt/newsletters/2024/09/13/#bitcoin-core-30509
+[news264 payjoin]: /pt/newsletters/2023/08/16/#serverless-payjoin
+[news353 pr review]: /pt/newsletters/2025/05/09/#bitcoin-core-pr-review-club
\ No newline at end of file
diff --git a/pt/about.md b/pt/about.md
new file mode 100644
index 000000000..00b892d76
--- /dev/null
+++ b/pt/about.md
@@ -0,0 +1,54 @@
+---
+layout: page
+title: Sobre
+permalink: /pt/about/
+redirect_from: /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 e 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 000000000..96f98d749
--- /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 000000000..37f86aea8
--- /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/podcasts.md b/pt/podcasts.md
new file mode 100644
index 000000000..4ba5baae3
--- /dev/null
+++ b/pt/podcasts.md
@@ -0,0 +1,9 @@
+---
+layout: podcast
+lang: pt
+title: Podcast
+name: podcast
+permalink: /pt/podcast/
+share: false
+version: 1
+---
diff --git a/pt/publications.md b/pt/publications.md
new file mode 100644
index 000000000..4c4391bf0
--- /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]: /pt/podcast/
diff --git a/pt/topic-categories.md b/pt/topic-categories.md
new file mode 100644
index 000000000..6618329b3
--- /dev/null
+++ b/pt/topic-categories.md
@@ -0,0 +1,45 @@
+---
+title: Tópicos
+permalink: /pt/topic-categories/
+layout: page
+---
+{% include linkers/topic-pages.md %}
+
+{% capture raw_categories %}
+{%- for topic in site.topics -%}
+ {%- if topic.topic-categories == empty -%}
+ {% include ERROR_92_MISSING_TOPIC_CATEGORY %}
+ {%- endif -%}
+ {%- for category in topic.topic-categories -%}
+ {{category}}|
+ {%- endfor -%}
+{%- endfor -%}
+{% endcapture %}
+{% assign categories = raw_categories | split: "|" | sort_natural | uniq %}
+
+
+
+{{ categories | size }} categories for {{site.topics | size}} tópicos
+únicos, com vários tópicos aparecendo em múltiplas categorias.
+
+{% for category in categories %} [{{category | replace: ' ', ' '}}](#{{category | slugify}}) {% unless forloop.last %}\|{% endunless %}{% endfor %}
+
+
+{% comment %}{% endcomment %}
+
+{% for category in categories %}
+
{{category}}
+
+ {% for topic in site.topics %}
+ {% if topic.topic-categories contains category %}
+ - {{topic.title}}
+ {% endif %}
+ {% endfor %}
+
+{% endfor %}
+
+
" | remove: "
" | strip }} 🔗ENDMENTION{% endcapture %}
+ {% assign number_of_events = number_of_events | plus: 1 %}
+ {%- endif -%}
+ {%- endfor -%}
+
+ {%- assign mymentions = mymentions | split: "ENDMENTION" -%}
+ {%- assign mymentions_size = mymentions | size -%}
+ {%- assign mentions_countdown = 999 | minus: mymentions_size -%}
+ {%- if mymentions_size > 0 -%}
+ {% capture month_topics %}{{month_topics}}{{mentions_countdown}}SIZE_DELIMITER{{topic.title}}TITLE_DELIMITER{{mymentions | join: "ENDMENTION"}}TOPIC_DELIMITER{% endcapture %}
+ {%- endif -%}
+ {%- endfor -%}
+
+ {%- assign month_topics = month_topics | split: "TOPIC_DELIMITER" | sort -%}
+ {% assign month_topics_size = month_topics | size %}
+ {%- if month_topics_size > 0 -%}{{month | append: "-01" | date: "%B %Y" }}
+ {% assign number_of_months = number_of_months | plus: 1 %}
+
+ {% for month_topic in month_topics -%}
+ {%- assign topic_data = month_topic | split: "SIZE_DELIMITER" -%}
+ {%- assign topic_data = topic_data[1] | split: "TITLE_DELIMITER" -%}
+ {%- assign topic_title = topic_data[0] -%}
+ {%- assign topic_mentions = topic_data[1] | split: "ENDMENTION" -%}
+ {%- assign topic_size = topic_mentions | size -%}
+
+ - {{topic_title}}
+
+ {%- for topic_mention in topic_mentions -%}
+ - {{topic_mention}}
+ {%- endfor -%}
+
+
+ {%- endfor -%}
+
+ {% endif %}
+ {%- endfor -%}
+{% 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 %}
+{{list}}
+
+
+{% include linkers/request-a-topic.md %}
diff --git a/pt/topics.md b/pt/topics.md
new file mode 100644
index 000000000..102e199fa
--- /dev/null
+++ b/pt/topics.md
@@ -0,0 +1,64 @@
+---
+title: Tópicos
+permalink: /pt/topics/
+layout: page
+---
+{% include linkers/topic-pages.md %}
+
+{% comment %}{% endcomment %}
+{% capture raw_topics_list %}
+{%- for topic in site.topics -%}
+
+ [{{topic.title}}]({{topic.url}})ENDTOPIC
+ {%- for alias in topic.title-aliases -%}*[{{alias}}]({{topic.url}})*ENDTOPIC{%- endfor -%}
+{%- endfor -%}
+{% endcapture %}
+
+{% assign topics_list = raw_topics_list | split: 'ENDTOPIC' | sort_natural %}
+{% assign number_of_topics = site.topics | size %}
+{% assign number_of_entries = topics_list | size %}
+{% 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).
+
+{:.center}
+{% assign previous_character = '' %}
+{% for entry in topics_list %}
+ {%- assign first_character = entry | remove_first: '{%- endcomment -%}
+ {%- if first_character != previous_character -%}
+ {%- if previous_character != nil -%}
+ [{{first_character | upcase}}](#{{first_character}}){{' '}}
+ {%- endif -%}
+ {%- endif -%}
+ {%- assign previous_character = first_character -%}
+{% endfor %}
+
+
+{% comment %}{% endcomment %}
+
+{% assign previous_character = '' %}
+{% for entry in topics_list %}
+ {% assign first_character = entry | remove_first: '{%- endcomment %}
+ {% if first_character != previous_character %}
+ {% if previous_character != '' %}{% endif %}
+
{{first_character | upcase}}
+
+ {% endif %}
+ - {{entry | markdownify | remove: "
" | remove: "
" | strip }}
+ {% assign previous_character = first_character %}
+{% endfor %}
+
+
+