Anyway, none of it looks hugely unusual. The biggest single mention probably goes to what wasn't merged, with the bcachefs pull request resulting in a long thread (we didn't hit a hundred emails yet, but it's not far away).
The curious can read that long thread in the list archives.
Covenants are a construction to allow introspection: a transaction output can place conditions on the transaction which spends it (beyond the specific “must provide a valid signature of itself and a particular pubkey”).
This power extends script in useful ways, such as allow creation of force spending paths (such as vaults which force spending delays), and rebindable inputs (such as required for Lightning “state fixup” proposals, aka LN-Symmetry). But when we discuss specific proposals (such as OP_TX, OP_TXHASH or OP_CHECKTEMPLATEVERIFY) it’s been difficult to nail down the exact trade-offs made for each one. So I want to describe the landscape (or taxonomy) which we can use to categorize and assess covenants.
The Simplest Covenant (Which Doesn’t Quite Work!)Firstly, consider the simplest covenant: OP_TXIDVERIFY. This would check the txid of the spending transaction is equal to the given txid. This is easy to implement both in existing script (replacing OP_NOP3), and in tapscript. It doesn’t actually work, since it makes a commitment circle (the txid contains the txid of the input, which contains the txid…; thanks Jeremy Rubin), but it’s a useful thought experiment.
Fully Complete CovenantsNow, consider the most complete covenant proposal: OP_TX. The idea is to push some specified field of the spending transaction onto the stack. For efficiency, it would take a bitmap to push multiple fields at once and (because we don’t have OP_CAT) have an option to concatenate them all as push them as one element. There are details here which matter, such as how primitive Bitcoin script is when dealing with numbers, and stack space limits for large transactions, but the idea is simple.
This allows you to do things like “output amount must be > 100000 sats”.
Equality CovenantsOn the spectrum from simplest to most complete, is Russell O’Connor’s OP_TXHASH (which I generalized into the OP_TX proposal), which takes a bitmap from the stack and hashes those fields together, then pushes the resulting hash onto the stack. Of course, you can have multiple OP_IF branches allowing different equalities, but only a handful: you’ll run out of scripts space quite fast. With OP_CAT you could extend this further to assemble a template to compare against at runtime, but we don’t have that so I’ll ignore that for now.
This allows for simple equality tests, such as “output amount must be 100000 sats”.
OP_CHECKTEMPLATEVERIFY CovenantOP_CHECKTEMPLATEVERIFY is a further restriction on basic equality covenants: it’s like OP_TXHASH with a fixed bitmap. It’s an opinionated subset though, which makes it more powerful than OP_TXIDVERIFY (and usable!): in particular it doesn’t commit to inputs at all (except the input number), but commits to all the outputs; this means you can theoretically add fees and still match, but you can’t have a change output. It’s also usable outside tapscript, since it’s written in the old “don’t-touch-the-stack” script soft-fork style.
Taproot Allows Us To Design, Then RestrictDesigning in the second half of 2023, I think it’s reasonable to assume covenants are only relevant inside taproot.
This means we have the ability to easily limit it in a way which can be unlimited in stages later via future soft-forks:
As an example, let’s turn OP_TX into OP_TXIDVERIFY. We only define one bit: OP_TX_BIT_TXID. That bit means “push the txid on the stack”, and if anything else is set, OP_TX is interpreted as OP_SUCCESS:
01 OP_TX_BIT_TXID OP_TX <txid> OP_EQUALVERIFYSimilarly, if we want OP_CHECKTEMPLATEVERIFY, we require the following OP_TX bits to be defined:
i.e: (assuming they’re assigned bits from 0 to 10)
02 b1111111111 OP_TX OP_SHA256 <hash> OP_EQUALVERIFYThere are some differences in how fields are hashed, and perhaps their order, but these are cosmetic not functional differences.
Extending this in future simply means defining other fields, and what combinations are allowed.
The Recursion DistractionThere are many ways we can argue about how to clip covenants’ wings. But I want to address (and dismiss) one specifically: the idea of restricting recursive covenants which restrict all future descendants.
Any covenant system listed here can restrict outputs. That means I can require that the spending transaction spend to a spending transaction that spends to a spending transaction that spends to…. 100 million transactions later… an output to me. You could prevent this by requiring that any covenant-spending tx itself is not allowed to use covenants at all, but that adds complexity and reduces usefulness.
Mathematically, there’s a difference between being able to restrict transactions to arbitrary depth and to infinite depth. Nobody else cares: either way, there are far better ways to render your coins useless than placing them in a giant chain or loop.
Covenants by the Back DoorI wrote a previous post on Covenants via Signatures which noted that signatures with BIP-118 can be used to make covenants. This is not a neat design, it’s more like “we have a jackhammer, we can use it to knock in a nail”. On the covenant spectrum, it’s an Equality Covenant between OP_TXHASH and OP_CHECKTEMPLATEVERIFY, in that it can be used with several different field bitmaps, according to the SIGHASH flags used on the signature.
Introspection Is Not All We WantIt’s worth noting that Bitcoin’s OP_CHECKSIG (and family) do three things:
OP_TX implements the first, and we already have various OP_SHA256 and similar operations for the second. OP_TXHASH and OP_CHECKTEMPLATEVERIFY combine the first two.
It’s logical to want a separate operation for the third one, hence the proposal to be able to check a signature signs a given hash: OP_CHECKSIGFROMSTACK. This would let you simulate any OP_CHECKSIG variation (depending on what OP_TX/OP_TXHASH flags were enabled):
02 <flags> OP_TX OP_SHA256 <pubkey> OP_CHECKSIGFROMSTACK SummaryWe should enable ANYPREVOUT. This will enable LN-symmetry which makes Lightning simpler (and thus more robust!), which has already been implemented. It will also enable covenants, though with a weird requirement for a signature-in-output, which makes them less efficient than they could be, but enables real uses and experimentation to inform future soft forks.
For future covenant soft forks, we should look at complete designs like OP_TX, then clip their wings as desired so we can enable the full functionality later. This may well end up looking like OP_CHECKTEMPLATEVERIFY!
Meanwhile, Greg Sanders, who both refined the OP_VAULT proposal and implemented LN-Symmetry (nee Eltoo), expressed the opinion that we’re fast approaching the edge of Bitcoin Script usability, and he now was firmly of the opinion that a soft fork to introduce Simplicity would be better. Perhaps that will happen instead of OP_TX or the like?
This brings us back around to a statement I made at the outset: that roguelikes are the exception that proves the rule of open-source game development — and just possibly of open-source software development in general. The cast of thousands who contribute to them do so in order to make exactly the games that they want to play, which in the abstract is the best of all possible reasons to make a game. The experience they end up with is, unsurprisingly, much like high-wire programming at its most advanced, presenting players with an immense, multi-faceted system to be explored and mastered.
[EDIT: An earlier version claimed we do covenants already. Oops! Thanks Ruben Somsen and Jimmy Song.]
In Bitcoin, covenants refers to restricting how an output is spent: this is from the legal term where conditions on property persist beyond sale. This is usually defined to exclude the “obvious” common requirement that the spending transaction be signed by a given key.
But to step back, there are logically three things OP_CHECKSIG (and friends) do:
For covenants, you really just want the first part: the ability to introspect so you can check whatever feature of the transaction you care about (this is the basis for OP_TX, which takes a bitmap telling it what about the spending transaction to push onto the stack so you can test it). But if you only care about equality, you can get away with something that does the first two things (this insight was the basis for Russell O’Connor’s OP_TXHASH, like OP_TX but always hashes before putting on the stack), and just check the hash is what you expected.
But, Burak points out that if you only care about equality, and are happy to specify all the fields that are covered by signatures (with the various SIGHASH variants), you can simply put a pubkey with pre-made signature and an OP_CHECKSIG into the output script! That constrains the transaction’s fields to hash to whatever that OP_CHECKSIG expects.
This, of course, is overkill: you don’t actually care about the signature operation, you’re just using it test hashes to create covenants. But unfortunately (as pointed out when I posted on Twitter, all excited!), it doesn’t quite work yet, because your signature has to commit to the script which contains the signature: a circular dependency.
But BIP-118 (a.k.a. ANYPREVOUT) proposes new SIGHASH flags which allow you not to commit to the input script, so this covenant-via-signature is possible, and Rearden Code has a tweak which makes this more powerful. I also suspect that you can probably use a simple 0x1 as the pubkey in some cases, since BIP-118 defines that to mean the taproot internal key, saving 32 bytes.
We believe an open source community can ethically collect limited aggregate data on how its software is used without involving big data companies or building creepy tracking profiles that are not in the best interests of users. Users will have the option to disable data upload before any data is sent for the first time. Our service will be operated by Fedora on Fedora infrastructure, and will not depend on Google Analytics or any other controversial third-party services. And in contrast to proprietary software operating systems, you can redirect the data collection to your own private metrics server instead of Fedora's to see precisely what data is being collected from you, because the server components are open source too.
The major pfsync(4) rewrite on which we recently reported has been committed to -current by David Gwynne (dlg@).
As it says in the commit message
deraadt@ says this is a good time to put it inWe put ourselves at risk of stating the glaringly obvious by saying testing will be much appreciated.
The commit message by Bob Beck (beck@) reads,
From: Bob Beck <beck () cvs ! openbsd ! org> Date: 2023-07-05 15:13:28 CVSROOT: /cvs Module name: src Changes by: beck@cvs.openbsd.org 2023/07/05 09:13:28 Modified files: sys/kern : vfs_syscalls.c sys/sys : mount.h sys/ufs/ffs : ffs_softdep.c ffs_vfsops.c Log message: Make softdep mounts a no-op Softdep is a significant impediment to progressing in the vfs layer so we plan to get it out of the way. It is too clever for us to continue maintaining as it is. ok kettenis@ kn@ tobhe@ and most of the g2k23 room except bluhm@
We look forward to further work and explanation of the motivation behind this change, sure to follow.
A flaw was found in the handling of stack expansion in the Linux kernel 6.1 through 6.4, aka "Stack Rot". The maple tree, responsible for managing virtual memory areas, can undergo node replacement without properly acquiring the MM write lock, leading to use-after-free issues. An unprivileged local user could use this flaw to compromise the kernel and escalate their privileges.
As StackRot is a Linux kernel vulnerability found in the memory management subsystem, it affects almost all kernel configurations and requires minimal capabilities to trigger. However, it should be noted that maple nodes are freed using RCU callbacks, delaying the actual memory deallocation until after the RCU grace period. Consequently, exploiting this vulnerability is considered challenging.
The disclosure contains a detailed description of the problem. Fixes have been merged into the mainline and the 6.4.1, 6.3.11, and 6.1.37 stable kernel updates.
Canonical, the creator and main contributor of the LXD project has decided that after over 8 years as part of the Linux Containers community, the project would now be better served directly under Canonical’s own set of projects.
While the team behind Linux Containers regrets that decision and will be missing LXD as one of its projects, it does respect Canonical’s decision and is now in the process of moving the project over.
Frissült a CWE (Common Weakness Enumeration) a legveszélyesebb sebezhetőségekről vezetett Top 25-ös listája. Továbbra is az Out-of-bounds Write [CWE-787] (határon kívüli értékek írása) számít a legsúlyosabb biztonsági hibának.
The post Ezek a legveszélyesebb típusú sebezhetőségek first appeared on Nemzeti Kibervédelmi Intézet.