Main topics

Segwit review and status update of the BIPs

Short topics

The transition to travis trusty and C++11 has been successful

The independent review for the constant time AES library talked about in the 2016-03-24 meeting is finished and he formally proved some parts were correct and analyzed the constant timeness.

For his replace-by-fee (RBF) wallet implementation jonasschnelli wondered whether he should attribute RBF transactions as “replaceable” or non-RBF transactions as “non-replaceable”. Developers seem to agree the former makes the most sense as non-RBF is just less replaceable. After many propositions jonasschnelli decided to go with “replaceability signaled” for the exact wording.

Someone contacted jonasschnelli asking for a repository for Bitcoin Core logos and communication material. There’s no clear logo or visual identity for bitcoin core. The developers don’t really care about that but the userbase might. It might make sense to have a “press kit” available somewhere. press kits for open source projects aren’t very usual and they almost always are accompanied by a licensing policy. So unless people want to police such a licensing policy a press kit would be more of a collection of recommended images/text we also use.

background

Developers are working on a soft fork to introduce segregated witness onto Bitcoin mainnet, with initial testing being performed on a special testnet. Segregated witness (segwit) allows transaction signature data to be stored outside of the data hashed to produce transaction identifiers, removing all known forms of third-party malleability, allowing full nodes to compile the current UTXO set without downloading all signatures, and laying the groundwork for fraud proofs that can allow lightweight (SPV) clients to help enforce more of the consensus rules. The segwit soft fork also allows miners to substitute 1 byte of block space with 4 bytes of segwit data, increasing transaction capacity for wallets that use segwit. segregated witness BIPs: BIP141, BIP142, BIP143, BIP144 and BIP145

Cfields has started working with the mining pools to ensure their setups can deal with segregated witness. His aim is to get each pool to mine at least one segnet block.

Given the many different parts involved in the segwit PR #7910 very few developers are confident they can fully utACK it since they might not be familiar enough with specific parts of the code. Developers will focus on the parts they are most confident in and ACK those parts.

There has been feedback from a few people towards the BIP texts and small clarifications have been made frequently as a result. Instagibbs verified BIP141 and BIP143 match up with their implementation.

meeting conclusion

Sipa will list a few areas where he thinks mildly tricky things are done that warrant extra review

BIP 144 needs to include the service bit stuff

Comic relief

(edited to leave out non-bikeshed comments)

19:35:30 <jonasschnelli> RBF naming: should we flag/attribute RBF transaction as "replaceable" or should we attribute "current" non RBF transaction as "non-replacable"? 19:35:59 <petertodd> jonasschnelli: I'd lean towards replacable, as non-replacable implies we're promising something... 19:37:16 <instagibbs> 'mempool-replaceable' ? 19:38:13 <jtimon> "standard-policy-0.12-replaceable"? 19:38:40 <jonasschnelli> "standard-policy-0.12-BIP125-replaceable" 19:40:21 <jtimon> ack bip125-replaceable 19:42:24 <petertodd> jonasschnelli: "easily replacable" 19:42:27 <jtimon> opt-in-repleaceable ? 19:42:38 <petertodd> jonasschnelli: or heck, "trivially replacable" 19:42:45 <paveljanik> "updatable"? 19:43:03 <luke-jr> "replacement-requested" 19:43:04 <jonasschnelli> of "signs replicability"? 19:43:39 <paveljanik> replacability signalled ;-) 19:44:38 <jtimon> "replace explicitly allowed"? 19:44:41 <sdaftuar> fee-replaceable ? 19:45:58 <jonasschnelli> "fee-replacability signalled"? 19:48:21 <jtimon> what was wrong about "Opted in to replacement" or something along those lines?

Participants

Disclaimer

This summary was compiled without input from any of the participants in the discussion, so any errors are the fault of the summary author and not the discussion participants.