In a similar spirit to my now decade old segwit consensus code review , I (and one of my clients) thought it would be worthwhile to do a code review of the consensus parts of the Knots BIP-110 implementation, to ensure there are no surprises when it activates. Unlike my segwit consensus code review, this review is done from the point of view of user/miner of the existing Bitcoin chain, with…
Is OpenTimestamps incompatible with or threatened by the Bitcoin Knots fork of Bitcoin Core and/or the OCEAN mining pool? I’m told this question has come up a few times from investors and potential users of OpenTimestamps, so I thought it would be worth answering in a blog post. This post isn’t going to get into the politics of Bitcoin Knot’s transaction relaying policy, or OCEAN’s transaction…
I was asked by Kruw to analyze and respond to Yuval “nothingmuch” Kogman’s post 1 on centralized, coordinator-based, deanonymization attacks. In particular 2 , attacks on the WabiSabi protocol used by Wasabi wallet; Kogman was involved in the design of WabiSabi, but “left in protest before its release” 1 . Kogman claims that the “this software is not fit for purpose and should not be used unless…
An unintuitive aspect of the Lightning protocol is that channels in the middle of your route don’t have to be real. If Alice is trying to pay BTC to David, through the route Alice ↔ Bob ↔ Charlie ↔ David, whether or not the Lightning channels between Bob and Charlie represent real channels with real Bitcoin doesn’t matter! Indeed, it doesn’t even matter to Alice whether or not David received…
With the recent success of Starship’s 5th and 6th test flights, mining Bitcoin in space and data centers in space have gotten renewed attention. But every time this is discussed, people inevitably raise the objections that “space isn’t cold”, “keeping things cool in space is almost impossible”, and “latency is too high”. These people are wrong. They’ve read too much over-simplified “pop science”,…
On-chain wallets achieve a roughly 1-1 mapping of transactions to transactions: for every economic transaction that a user performs, roughly one blockchain transaction is needed. Aggregations, coinjoin, cut-through-payments, etc. change this statement a bit. But it’s roughly correct. Lightning achieved a many-to-one mapping of transactions to transactions: the magic of Lightning is that an…
I recently released a prototype Libre Relay fork of Bitcoin Core v26.0, that among other things, implements Pure Replace-By-Fee-Rate (RBFR) with a 2x ratio. This means that transactions will be replaced if the fee-rate of the new transaction is at least 2x higher than the old transaction(s), even if the absolute fee is lower. RBFR policies are highly desirable for Lightning and similar smart…
Currently Bitcoin Core implements a Replace-by-Fee (RBF) policy, where transactions are not replaced unless the new transaction pays at least a higher total fee than the replaced transaction, regardless of fee-rate. When RBF was first implemented over 8 years ago this was a reasonable, conservative, default. However, since then we’ve found that strictly requiring a higher absolute fee creates the…
V3 transactions is a proposed set of mempool policies with the aim of allowing transactions to use Child-Pays-For-Parent (CPFP), anchor outputs, and package relay as the primary method of paying for fees in contracting protocols such as Lightning. In this article we will go over how V3 transactions and anchor outputs are meant to work, their role in protocols such as Lightning. Finally we’ll show…
V3 Transactions 1 is a set of transaction relay policies intended to aim L2/contracting protocols, namely Lightning. The main aim of V3 transactions is to solve Rule 3 transaction pinning 2 , allowing the use of ephemeral anchors 3 that do not contain a signature check; anchor outputs that do contain a signature check are not vulnerable to pinning attacks, as only the intended party is able to…