I am listing some topics to consider discussing in person. Ideally we should focus on (perhaps non-trivial) things that are not widely understood by each other, or things that might have been forgotten in endless IRC and mailing list scrollbacks. I am sure that folks would like to use time for short-term coding tasks too.
Also, I don't guess that these topics can all be covered, so I am listing them out so that we can each pick and choose which things we want to bug folks about.
Btw I think we could use this as an opportunity to get many thoughts written down, either as draft BIPs or emailable notetaking.
http://coredev.tech/nextmeeting.html
https://github.com/sipa/bitcoin/commit/5b0cd48d9f29f4a839640819230d4e88e077ce40
(reminders for bryan- sdaftuar logs, morcos logs, and http://diyhpl.us/~bryan/2016-04-19-segwit.txt )
sipa to talk about segwit areas of concern
probabilistic payments for sub-satoshi payments on lightning network http://diyhpl.us/wiki/transcripts/sf-bitcoin-meetup/2016-04-11-lightning-network-as-a-directed-graph-single-funded-channel-network-topology/
lightning network status, testing and compatibility between mutiple implementations
lightning deployment- core coupling if any, wallets, daemons, SDKs, web app integrations, etc.
a proposal for SIGHASH_NOINPUT in segwit, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012460.html
poon's fidelity bond sidechain peg proposal (maybe tadge knows details)
lightning network key derivation
annexation of canada
low-frequency delayed UTXO commitments, utxo set commitments, delayed txo commitments, stxo commitments, merkle mountain ranges, transactions with proofs https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012715.html
"wallets bring the utxo proofs with their outgoing transactions"
linearized coin history proposals
fraud proofs (or the inverse, non-fraud proofs)
possible hard-fork (not soft-fork as originally claimed) fix for block withholding attacks? https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012441.html
segwit status, code review status, areas of concern
optimal checksums for base32 address data
ideas for improved block relay protocols, beyond the current proposal by greg and matt
schnorr signature aggregation (which has a few non-obvious security pitfalls)
one-way aggregatable signatures
(1) schnorr multisig (just within a single input) (2) schnorr aggregation (across all inputs of a transaction) (3) BLS aggregation (across all inputs of a block) (4) OWAS (delegating signing to BLS keys which are aggregated, with privacy but no efficiency advantage)
aggregateable schnorr and when/how to get that into bitcoin
tree signatures https://blockstream.com/2015/08/24/treesignatures/
other tree signature stuff not mentioned in above link?
we should be using recoverable hash for P2WSH, saving 32 bytes on the wire per txin (but greg has shown sipa's recoverable hash idea to be insecure) (another scheme exists)
pairing crypto stuff ? more pairing crypto things to mention?
encrypted transactions
human-memorable RC4-variant test vectors (ciphersaber), http://cypherspace.org/adam/csvec/
innovations in libsecp256k1, bitcoin-core/secp256k1#396 (comment)
signature aggregation stuff, like https://bitcointalk.org/index.php?topic=1377298
various signature schemes, ring signatures, maybe threshold signature schemes, lamport signature things
flagverify BIP proposal, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011853.html
anti-dos PoW at network layer maybe
follow-up on zero-knowledge contingent payments? anything else on this front to discuss in group ??
status of confidential transactions BIP if any?
confidential transactions as a soft-fork (someone else's proposal), https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012194.html
recent compact SPV proof things?
'there is the scheme I described where miners public a set of updates to utxo set (remove this, add that) and a constant size proof "this update is a rule conforming update according to some set of transactions known to me, which I'm never going to bother telling anyone else about." e.g. it's doing the cutthrough optimization implicitly but it is still not constant size because of the need to publish the resulting utxo set, which I think cannot be escaped or otherwise no one else can mine the next block. now, when fetching the history, you perhaps only care about the hashes, and so you can skip. but publication at tip must force utxo.'
that strange proposal about getting rid of transactions from the bitcoin system (in terms of history) "I argue a specific commitment structure where miners, armed with a succinct ZKP for NP statements, create blocks which provide only an update to the UTXO set, and a constant size proof that the new utxo set was an authorized modification according to some unspecified number of undisclosed transactions. It's lovely, except for the current infeasability of running ECDSA verification in the prover unless we don't mind 12 hour blocks."
bip124 hierarchical deterministic script templates, bitcoin/bips#246
bip83 dynamic hierarchical deterministic key trees, bitcoin/bips#242
flexcap things
validation cost metric things
various ways that DAOs are currently broken and insecure
future segwit script enhancements — key trees, poly trees, script replacement, etc.
validation state commitment approaches
signature aggregation
merkleized abstract syntax tree
gpg multisig
deterministic debian
formal verification of script stuff
CHECKPRIVATEKEYVERIFY bip proposal, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-April/012609.html MAST things (bip114)
script 2.0 things, like BIP-mastopcodes https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-April/012619.html
hard-fork bit BIP draft, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012342.html
.. and maybe luke-jr's related pre-BIP growth soft-hard-fork proposal https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012377.html https://github.com/luke-jr/bips/blob/bip-mmhf/bip-mmhf.mediawiki
SPV hard-fork opt-in BIP draft, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012357.html
header format upgrades roadmap, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012414.html
segwit feature wishlist, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011935.html
sergio's OP_PUSH_SIG proposal
list of opcode proposals, http://diyhpl.us/~bryan/irc/bitcoin/opcode-proposals.2016-04-29.txt
fixing misconceptions about zeromq?
libconsensus and code separation progress or issues
network library things?
p2p things (for Saturday)
p2p authentication and encryption BIP draft, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-March/012575.html and https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-April/012599.html
fast bootstrapping with a pre-generated UTXO-set database, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012478.html
compact block relay BIP stuff, other block relay improvement proposals, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012624.html
wallet separation
sidechain pre-BIP discussion https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-April/012610.html
prioritization of bram cohen fee estimation things?
fixing misconceptions about longpolling, rpc, notifications, zeromq (jtimon?), etc.