This newsletter from June 8th 2018 was a preview run of the Optech newsletter.
Technical news about Bitcoin from last Friday to this Thursday, June 1st through June 7th.
A new maintenance release of Bitcoin Core is coming soon with a change to relay policy, hash rate has been increasing rapidly so it could be a good time to send low-fee transactions, wallet providers may want to investigate proposed BIP174 before it’s fully implemented, filters for P2P lightweight clients are heavily discussed, feedback is requested on proposals to change private key serialization and how mining pools communicate with their hashers, and Bitcoin Core merges an optimization to build merkle trees up to about 7x faster.
Key action items
Check for use of the CodeSeparator opcode: Bitcoin Core 0.16.1, expected to be released within the next week or so, will no longer relay legacy (non-segwit) transactions using this opcode. As far as Bitcoin Core contributors know, nobody uses this opcode, but if your organization does use it or plans to use it, you should immediately contact a protocol developer or optech team member ASAP to inform them of this. Ultimately it is possible that this opcode will be removed from the Bitcoin Protocol for legacy transactions via a soft fork.
Test release candidates for Bitcoin Core version 0.16.1. RC1 available now; RC2 likely to be available shortly. This release will contain bugfixes particularly important for miners. There are no major changes for spender-receivers and API providers, but they may benefit from bugfixes.
Hash rate increases: the difficulty of mining increased almost 15% this week and shorter-term averages of network hash rate show continued growth. This means that blocks are being produced more frequently than normal and this will likely hold down transaction fees for as long as the trend continues. It’s a good time to consolidate transaction outputs or otherwise send low-fee transactions.
Very low-fee transactions: an increase in the number of very-low fee transactions paying less than 10 nanobitcoins per vbyte has been observed on nodes with non-default transaction acceptance policy (the default policy is to reject transactions paying less than 10 nBTC/vbyte). This may indicate misconfigured wallets paying fees that are too low, or it may indicate that some spenders believe this is a viable strategy to save on fees. It may be worth experimenting to determine whether these extremely low fees can be used for consolidations and other time-insensitive intrawallet transfers.
BIP174 discussion and review ongoing: this BIP creates a standardized format for wallets to reliably share information related to unsigned and partially-signed transactions. This is expected to be implemented in Bitcoin Core and may also be implemented in other wallets, allowing software wallets, hardware wallets, and offline (cold) wallets to easily interact with each other for both single-signature and multi-signature transactions. This BIP has the potential to become an industry standard and so all major wallet providers are encouraged to investigate the specification.
BIP157/BIP158 lightweight client filters: these BIPs allow nodes to create a compact index of transaction data for each block on the chain and then distribute copies of that index to light clients who request them. The client can then privately determine whether or not the block might contain any of the client’s transactions.
Exactly what data should be indexed was heavily discussed on the mailing list this week. This probably does not directly affect most large receiver-spenders and API services, but any providers planning to release wallets using the peer-to-peer network protocol may want to review the BIPs.
Bitcoin Core PR #13243, merged this week, is part of an effort to bring this feature to Bitcoin Core.
Proposed BIP for private key & HD wallet serialization: currently private keys are usually transmitted using the same encoding as legacy Bitcoin addresses, and HD wallet extended keys and seeds are transmitted using either the same format, hex, or a mnemonic phrase. This new proposal would allow using the bech32 format used for native segwit addresses.
Discussion focused on whether or not to use the exact bech32 standard or a modification of it that would be more resistant to transcription and data loss errors. Services that plan to accept or distribute secret key material may wish to contribute to reviewing the specification.
BetterHash mining protocol: A proposed replacement for the Stratum mining protocol currently almost universally used for mining pools to distribute work to individual miners. The proposal claims to provide better security for the pool operator and allows individual miners to select what transactions they include in their blocks, increasing Bitcoin censorship resistance and also possibly making miners using the protocol more effective. The protocol is championed by the developer and operator of the FIBRE network used by almost all miners.
The protocol has been in semi-private development for some time and is just now being distributed for public comment. Organizations planning to sell or operate mining equipment are encouraged to review the protocol, as are any groups or individuals desiring changes to Bitcoin’s consensus rules so that the protocol can potentially be made forward compatible with those changes. There has not yet been much on-list discussion of the proposal.
On this day in Bitcoin commit history…
2017: Andrew Chow authored commit ec6902d paving the way to remove the last parts of the confusing “safe mode” functionality added to Bitcoin 0.3.x after the value overflow incident.
2016: Luke Dashjr’s PR #7935 was merged adding support for BIP9 versionbits to the GetBlockTemplate RPC call, allowing miners to signal support for future soft forks—such as the soft fork that activated BIP141 segregated witness.
2015: Gavin Andresen authored commit 65b94545 to refine the criteria a node uses to detect that it may no longer be receiving blocks from the best block chain.
2014: Cozz Lovan authored commit 95a93836 removing a legacy part of the GUI that assumed any transaction fee below 0.01 BTC was a low transaction fee.
2013: Wladimir van der Laan authored commit 3e9c8ba fixing a bug related to the data directory.
2012: Luke Dashjr authored several commits (e.g. 9655d73) related to enabling IPv6 support.