Non-IRC meeting summary for 2016-05-20

Overview

Main topics

  • Segregated witness code review
  • Error correcting codes for future address types
  • Encryption for the peer-to-peer network protocol
  • Compact block relay protocol
  • Schnorr signatures and aggregation
  • New networking library

Notes / short topics

  • This meeting was held in person in Zurich, Switzerland rather than the usual IRC channel. Details at http://coredev.tech/.
  • Some participants took the opportunity to verify PGP fingerprints and sign each others’ keys, to expand the PGP web of trust around Bitcoin for improved security.
  • The special travis caching features that Bitcoin Core is using should now available to all GitHub users, so the CI tests should run on arbitrary repositories, and not just the Bitcoin Core one.
  • Greg Maxwell noted that some developers appear to be getting an influx of PDF malware.

Segregated witness code review

background

Segregated witness is a change to omit signatures from the canonical transaction ids, to eliminate unintentional malleability. It also as a side effect takes the opportunity to improve scalability and increase the maximum block size.

meeting comments

Jonas Nick backported segnet (a custom testnet dedicated to segregated witness testing) to 0.9 and checked segwit backward compatibility and upgrading post-activation to a segwit-enabled version. Suhas collected a list of remaining tests. Much code review was done, resulting in a few minor bug fixes. Uncertainty with regard to the unusual requirements of fund-raw-transaction was discussed.

meeting conclusion

  • Fund-raw-transaction should not present a need to change consensus segwit code.
  • sdaftuar drew up a list of extra tests that should be written.
  • Mining: work out how GBT will work (non-segwit aware software shouldn’t be able to signal segwit’s version bit); see #7935 for some context of how we’ll likely implement
  • Seed nodes for segwit - being worked on by jonasschnelli
  • Add documentation to release notes.
  • review how are we handling misbehaving peers.

Error correcting codes for future address types

background

For most of Bitcoin’s history, a custom base-58 encoding has been used for Bitcoin addresses. Efforts to migrate to a payment protocol have not been successful, so there is possibly demand for new address types in the future. Base-58 is commonly considered a poor encoding, so there is some desire to come up with a new one that improves on it for future address types.

meeting comments

Pieter gave a status update on his work on high performance base-32 BCH codes for future address type definitions. Pieter has made good progress finding trivial to implement codes which have good performance (e.g. 30 correction bits giving certain detection of up to 4 transposition errors or 4 substitution errors.)

meeting conclusion

Using error correction logic for reliable error detection is a good idea, but should explicitly not try to correct user error for security reasons.

Encryption for the peer-to-peer network protocol

background

The Bitcoin network does not encrypt communication between peers today. This opens up security issues (eg: traffic manipulation by others) and allows for mass surveillance / analysis of bitcoin users. Mostly this is negligible because of the nature of Bitcoins trust model, however for SPV nodes this can have significant privacy impacts and could reduce the censorship-resistance of a peer.

Encrypting peer traffic will make analysis and specific user targeting much more difficult than it currently is. Today it’s trivial for a network provider or any other men-in-the-middle to identify a Bitcoin user and its controlled addresses/keys (and link with his Google profile, etc.). Just created and broadcasted transactions will reveal the amount and the payee to the network provider.

The protocol used to communicate between Bitcoin nodes has always been unencrypted, since communications are considered public. However, there is desire to have the option of security for users who run thin clients for their wallet, yet want to use their own private node for security.

meeting comments

Jonas Schnelli has updated the BIP151 and it now looks like it’s ready for a trial implementation. Beyond improving privacy this change should also make the p2p protocol have less CPU overhead.

meeting conclusion

The draft BIP151 is now published in the BIPs repository, and Jonas will be working on an implementation.

Compact block relay protocol

background

Bandwidth is a major bottleneck in relaying blocks across the peer-to-peer network. Unless this bottleneck can be reduced, larger block sizes can be very damaging to Bitcoin’s decentralisation qualities.

Historically, the Bitcoin P2P protocol has not been very bandwidth efficient for block relay. Every transaction in a block is included when relayed, even though a large number of the transactions in a given block are already available to nodes before the block is relayed. This causes moderate inbound bandwidth spikes for nodes when receiving blocks, but can cause very significant outbound bandwidth spikes for some nodes which receive a block before their peers. When such spikes occur, buffer bloat can make consumer-grade internet connections temporarily unusable, and can delay the relay of blocks to remote peers who may choose to wait instead of redundantly requesting the same block from other, less congested, peers.

Thus, decreasing the bandwidth used during block relay is very useful for many individuals running nodes.

While the goal of this work is explicitly not to reduce block transfer latency, it does, as a side effect reduce block transfer latencies in some rather significant ways. Additionally, this work forms a foundation for future work explicitly targeting low-latency block transfer.

meeting comments

More people were asked to review the mempool interactions (esp. the use of reference counting instead of copying.)

meeting conclusion

Continue review of BIP152 draft and Core implementation #8068.

Schnorr signatures and aggregation

background

Currently Bitcoin requires a single signature for each output consumed in a transaction, and for each party in the case of multisig coins. Schnorr signatures allow combining these into a single signature which can then be checked for the entire transaction, reducing validation time and data size significantly.

meeting comments

Pieter went over the state of his thinking about constructions for schnorr signatures and signature aggregation.

meeting conclusion

The general expectation is that a BIP related to Schnorr signatures would be made within the next 12 months.

New networking library

background

Bitcoin Core’s networking code is very minimal and not very flexible or easy to improve on. Cory has been working on rewriting it.

meeting comments

Cory Fields provided an overview of his recent work on a new networking library.

meeting conclusion

This could eventually be used to remove the dependency on boost in the source code.

Merkelized Abstract Syntax Tree

background

BIP114, Merkelized Abstract Syntax Tree (MAST), is an enhancement of the Bitcoin scripting language that takes advantage of segwit script versioning. It increases efficiency and privacy of conditional transactions. This BIP114 also safely enables many of the opcodes that were disabled in an early version of Bitcoin. MAST scripts increase privacy because less data needs to be made public, and can also make transactions smaller, thus saving space.

meeting comments

The MAST proposal is quite straightforward. It’s quite similar to the current P2WSH scheme. You need to provide when you are spending the coin, you need to provide the script and the merkle branch and also the position. You use ECDSA validation to calculate the root, and compare with the scriptpubkey. It builds a tree where the leaves are scripts. And then you say, this is the script I’m executing, here’s a merkle branch that proves it was committed to.

Many of the advantages of MAST were discussed as well as implementation details.

meeting conclusion

MAST depends on segwit activation.

Child Pays for Parent

Child pays for parent is a way of adding fees to a transaction by making an another transaction that depends on the first.

meeting comments

The pull request has been completed and is ready for review.

meeting conclusion

Review the following pull-requests #7600 and #7598.

Participants

IRC nick Name/Nym
adam3us Adam Back
kanzure Bryan Bishop
jcorgan Johnathan Corgan
sdaftuar Suhas Daftuar
luke-jr Luke Dashjr
Adiabat Tadge Dryja
MarcoFalke Marco Falke
cfields Cory Fields
maaku Mark Friedenbach
wumpus Wladimir van der Laan
jl2012 Johnson Lau
CodeShark Eric Lombrozo
gmaxwell Gregory Maxwell
nickler Jonas Nick
instagibbs Gregory Sanders
jonasschnelli Jonas Schnelli
jtimon Jorge Timón
petertodd Peter Todd
sipa Pieter Wuille

Disclaimer

This summary was compiled without input from some of the participants in the discussion, so errors may be the fault of the summary and not the discussion participants.