1/7 New write-up: github.com/sipa/writeups/…

Imagine you can encrypt all of an application's P2P network connections, but only some are deliberately to specific peers, while others are just made randomly.

How private can you make an authentication protocol for this use case? Very! 2/7 The most surprising part is that if you can make it so that a Man-in-the-Middle cannot tell deliberate connections and random ones apart, the random ones get some protection too: MitMs can't selectively intercept if every connection could be an attempt to authenticate.

1/ To put the recent performance improvements in github.com/bitcoin-core/s… into perspective, I made this graph of the library's performance over time on ARM64 and x86_64. 2/ On the X axis a number of PR numbers are listed which had some noticeable effect on performance. In particular 830 (enabling the GLV endomorphism by default) and 831 (safegcd based modular inverses) had a huge impact.

About GLV endomorphism:

https://twitter.com/pwuille/status/1309722142607515648

As of block 687284, Taproot signalling has reached 1815 blocks this period, guaranteeing that absent very deep reorgs, it is guaranteed to lock in. Following that, it will activate at block 709632, probably around mid-November 2021. 🥕 It's been a long story, that started in a diner in Los Altos, CA where in Greg Maxwell, Andrew Poelstra and I somewhere in January 2018 had lunch.

While I briefly had to leave the table, they had come up with a really cool idea to hide Merkle roots in P2PK-like outputs.

@benthecarman @RubinhoISR The motivating example is hypothetical opcodes that are more expensive per byte than signature checking.

BIP342 replaces the sigops limit with a resource cost: everything is translated to bytes that you "pay" for. If a script executes N checksigs, it needs 50*N witness bytes. @benthecarman @RubinhoISR That avoids the complex optimization problem for miners that exists in theory today (actual implementations just ignore it, though). Ideally they'd try to both maximize fee per weight and fee per sigop - this much harder to do (and estimate) than just one metric.

I wrote this analysis of insertion, deletion, substitution, and swap errors in Bech32: gist.github.com/sipa/a9845b37c… The context is github.com/sipa/bech32/is…, which discovered that if a valid Bech32 ends in a 'p', then it may be possible to insert/delete 'q' character just before that 'p'.

Just announced our Miniscript project website on the bitcoin-dev mailinglist: bitcoin.sipa.be/miniscript/ In short, it's a way to write (some) Bitcoin scripts in a structured, composable way that allows various kinds of static analysis, generic signing, and compilation of policies.

1) This question was clearly a bit underspecified, as some of the more creative responses showed. Despite that, my answer is (c) 5M-10M BTC. This includes all outputs with P2PK/raw multisig outputs, plus P2PKH outputs with known pubkeys, and P2SH/P2WSH with known scripts.

https://twitter.com/pwuille/status/1107720144300572672

2) This includes about 1.75 M BTC in P2PK/raw multisig outputs, and over 4M BTC due to known pubkeys and scripts, revealed in the Bitcoin blockchain. If you include forkcoin chains, another ~0.5 M BTC becomes accessible to such a hypothetical machine.

1/ The correct answer is (d), with a value of 2 weeks, 20 minutes, 1.19seconds; that's a factor of 2016/2014 longer than 2 weeks.

The reason for this is due to two different effects, one well known, and one pretty obscure.

https://twitter.com/pwuille/status/1098288749098795008

2/ The first effect is that the observed "length" of the retarget window is only 2015 blocks. This means that the retargetting logic is aiming to make 2015 blocks take 2 weeks, or 2016 will take 2016/2015 times two weeks - 10 minutes longer than 2 weeks. That's not all, however..