#Bitcoin

Bitcoin Optech #429 highlights a proposed way for multiple signers to construct Silent Payments and verify their contributions. The design remains research, with an important security assumption unresolved.

Lichen is a research design for a single-issuer layer 2 that aims to let users recover bitcoin through an onchain dispute process when the issuer will not cooperate. Users and the issuer lock funds separately, with redemption rights subject to an agreed capacity. Tokens above that limit still require the issuer's cooperation.

The design continues to depend on the sequencer recording state correctly; malicious sequencing can cause losses. The newsletter also covers a proposal to store known hash preimages in output descriptors. These secrets should be backed up and protected like keys, and excluded from public descriptors.

This issue discloses two denial-of-service flaws in Eclair's channel-opening process involving duplicate channel identifiers and limits on pending channels. They could exhaust memory. The newsletter states that versions through v0.14.0 were affected and that fixes shipped in July with v0.14.1.

LN-GAP explores complex, multi-round contracts inside Lightning channels. A committee attests whether messages were published on time, addressing an unresponsive counterparty. Although the committee does not custody funds, security still depends on an honest majority, so the design is not fully trustless.

This issue introduces a draft allowing peers to assign their own one-byte message identifiers for BIP324 transport. Aliases announced when connecting could reduce dependence on a globally coordinated table for new messages. The proposal concerns network transport and is not an already activated consensus change.

It also covers Shielded Bitcoin, which explores hiding transfer amounts and counterparties through encrypted notes, nullifiers and external verification. Details of its deposit and exit mechanisms were awaiting a companion paper. The design remains research rather than a completed privacy product.

This issue covers two older Eclair denial-of-service vulnerabilities in feature-bit parsing and gossip-message decompression, where small requests could consume excessive resources. The newsletter says versions through v0.13.1 were affected and fixes shipped in May with v0.14.0. October is the disclosure date.

Another proposal would let wallets sharing a descriptor synchronize encrypted labels through an untrusted store, reducing manual export and import. It builds on BIP329 records and addresses conflicts and deletion markers. Standardization was still under discussion.

Bitcoin records transactions in a shared public ledger called the blockchain. Wallets use this ledger to calculate available balances. When sending funds, a user creates a digital signature with a private key so the network can verify that the spending is authorized, without revealing that key to the recipient. Addresses receive payments; private keys authorize spending.

After a transaction is broadcast, miners include it in a block and the network verifies it against its rules. Mining helps participants agree on transaction order and makes rewriting history more costly.

Using Bitcoin means understanding who controls the assets and who is responsible for keeping them safe. Holding your own private keys gives you direct control, but also makes you responsible for preserving recovery information. If you permanently lose access, no central authority can reset it for you. Leaving assets with an exchange instead introduces reliance on its custody and ability to honor withdrawals.

The article also explains that blockchain records are public and persist over time, so Bitcoin is not fully anonymous. There is no bank customer service team that can reverse a payment, and an unconfirmed transaction should not be treated as a completed receipt.

Wallet security involves everyday use, backups and asset storage. The source recommends separating small amounts for daily spending from longer-term holdings, choosing online services carefully, and checking that backups cover everything needed to recover funds. A single backup can fail if a device breaks or something happens to the place where it is stored.

The guide covers wallet encryption, offline signing, hardware wallets and multisignature arrangements. These tools address different problems: encryption does not replace backups or eliminate malware threats.

A Bitcoin address does not display a name, but its transaction amounts, flows and balance can be inspected publicly. Once an address is linked to purchases, public posts or other identifying information, earlier and later transactions may become traceable. Using a pseudonymous address therefore does not make transactions inherently anonymous.

The source explains how reusing receiving addresses, posting addresses publicly and sharing transaction details can make information easier to connect. It also discusses fresh addresses and wallets for different purposes. These practices can reduce unnecessary exposure but cannot guarantee that activity is untraceable.

Bitcoin.org organizes getting started into four steps: understanding the basics, choosing a wallet, obtaining bitcoin and making payments. Wallets can run on a phone or computer. Bitcoin can be obtained by accepting it for goods and services, or by buying it from other people or exchange services, then spent with merchants that accept it.

For merchants, the page describes handling payments and invoices directly or using a merchant service, with the option to keep bitcoin or local currency. It also covers accounting, tax and merchant directories, noting that tax treatment depends on local rules. This is an overview of spending and receiving payments, with links to more detailed resources for each step.