[bitcoin-dev] Covenants and capabilities in the UTXO model

[Bram Cohen via bitcoin-dev]

There are a few different approaches to adding covenants and capabilities
to the UTXO model with varying tradeoffs. It turns out that it can be done
while making very few but not quite zero compromises to practices Bitcoin
has been following so far.

First, the good news: Full support for both capabilities and covenants can
be added without changing the UTXO model whatsoever by adding some more
programmatic capabilities to the language and doing some programmatic
tricks. Since scriptpubkeys/scriptsigs continue to run ephemerally at
validation time full turing completeness is much less dangerous than people
fear. The main thing missing from what's expressed in transactions
themselves is a coherent notion of a single parent of each output instead
of the all-inputs-lead-to-all-outputs approach of transactions currently.
It would also probably be a good idea to add in a bunch of special purpose
opcodes for making coherent statements about transactions since in Bitcoin
they're a very complex and hard to parse format.

Now for the controversial stuff. Once you start implementing complex
general purpose functionality it tends to get very expensive very fast and
is likely impractical unless there's a way to compress or at least
de-duplicate snippets of code which are repeated on chain. Currently
Bitcoin has a strong policy that deciding which transactions to let into a
block for maximum fee is a strictly linear optimization problem and while
it's possible to keep things mostly that way making it completely strict is
unlikely to workable. About as close as you can get is to make it so that
each block can reference code snippets in previous blocks for
deduplication, so at least the optimization is linear for each block by
itself.

Having covenants and capabilities at all is controversial in and of itself.
With covenants the main issue is whether they're opt-in or opt-out. For a
payment to someone to come with a rider where they could accept it and
think their system was working properly for a while until you exercised
some kind of retroactive veto on new action or even clawback would
obviously be unacceptable behavior. But for payments to come with covenants
but the recipient not even be able to parse them unless they're fully
buying into that behavior is much more reasonable.

The main issue which people have raised with capabilities is that if you
were to have colored coins whose value was substantially greater than the
chain they were tokenized on then that could potentially create a business
model for attacking the underlying chain. While this is a real concern
tokenized assets have been out for a while now and have never come close to
causing this to happen, so maybe people aren't so worried about it now.

Given all the above caveats it turns out one weird trick is all you need to
support general purpose capabilities: for a UTXO to have a capability its
scriptpubkey asserts that its parent must either be the originator of that
capability or also conform to the same parent-asserting format. More
complex functionality such as supporting on-chain verifiable colored coins
can also be done but it follows the same pattern: Capabilities are
implemented as backwards pointing covenants.

If you'd like to see a fleshed out implementation of these ideas (albeit in
a slightly different model) there's quite a bit of stuff on chialisp.com
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP-119 Deployment and Review Workshops

[Heritage Samuel Falodun via bitcoin-dev]

Okay Jeremy, I plan to attend.

On Thu, Dec 30, 2021 at 9:29 PM Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Dear Bitcoin Developers,
>
> I've selected a time (every 2 weeks on Tuesday 12:00 PM PT starting
> January 11th in Liber ##ctv-bip-review) to host a recurring meeting to
> discuss BIP-119 review and deployment topics.
>
> Before the meeting, please send me any topics you would like to cover & I
> will circulate a preliminary agenda incorporating feedback in advance of
> the meeting.
>
> The rough plan will be to coordinate review, testing, and iron out any
> wrinkles around release timelines and procedures based on my request for
> comment here https://rubin.io/bitcoin/2021/12/24/advent-27/. Meetings
> will be moderated tightly to remain on topic, but all relevant topics will
> be welcome (similar to how I moderated the meetings I hosted for Taproot).
>
> Participation in these meetings does not signify any sort of endorsement
> of BIP-119's inclusion, nor a specific roadmap, but rather to carry on the
> 'gradient descent process' of consensus in an open, interactive, and
> productive format. Logs will be available via gnusha.
>
> Happy New Year,
>
> Jeremy
>
> p.s. If you plan to attend feel free to drop me a private note / reply
> here, otherwise I may ping you to ask if you can attend.
>
> --
> @JeremyRubin 
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-- 
Heritage Samuel Falodun
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] On the regularity of soft forks

[Keagan McClelland via bitcoin-dev]

>  But whether or not it is a basic principle of general software
engineering kind of misses the point. Security critical software clearly
isn't engineered in the same way as a new social media app. Bugs are easily
reverted in a new social media app.On top of that we aren't just dealing
with security critical software. One of the most important objectives is to
keep all the nodes on the network in consensus. Introducing a consensus
change before we are comfortable there is community consensus for it is a
massive effective bug in itself. The network can split in multiple ways
e.g. part of the network disagrees on whether to activate the consensus
change, part of the network disagrees on how to resist that consensus
change, part of the network disagrees on how to activate that consensus
change etc

>  A consensus change is extremely hard to revert and probably requires a
hard fork, a level of central coordination we generally attempt to avoid
and a speed of deployment that we also attempt to avoid.

This seems to assert the idea that soft forks are all the same: they are
not. For instance a soft fork, lowering the block subsidy is completely
different than changing the semantics of an OP_NOP to have semantics that
may reject a subset of the witnesses that attest to the transactions
permissibility. As a result, reversion means two entirely different things
in these contexts. While a strict reversion of both soft forks is by
definition a hard fork, the requirement of reversion as a result of
undesired behavior is not the same. In the case of opcodes, there is almost
never a requirement to revert it. If you don't like the way the opcodes
behave, then you just don't use them. If you don't like the reduction of
the block subsidy, well that's a much bigger problem.

I make this point to elucidate the idea that we cannot treat SoftForks™ as
a single monolithic idea. Perhaps we need to come up with better
terminology to be specific about what each fork actually is. The soft vs.
hard distinction is a critical one but it is not enough and treating soft
forks that are noninvasive such as OP_NOP tightenings. This has been
proposed before [1], and while I do not necessarily think the terms cited
are necessarily complete, they admit the low resolution of our current
terminology.

> Soft fork features can (and should) obviously be tested thoroughly on
testnet, signet, custom signets, sidechains etc on a standalone basis and a
bundled basis.

I vehemently disagree that any consensus changes should be bundled,
especially when it comes to activation parameters. When we start to bundle
things, we amplify the community resources needed to do review, not reduce
them. I suspect your opinion here is largely informed by your frustration
with the Taproot Activation procedure that you underwent earlier this year.
This is understandable. However, let me present the alternative case. If we
start to bundle features, the review of the features gets significantly
harder. As the Bitcoin project scales, the ability of any one developer to
understand the entire codebase declines. Bundling changes reduces the
number of people who are qualified to review a particular proposal, and
even worse, intimidates people who may be willing and able to review
logically distinct portions of the proposal, resulting in lower amounts of
review overall. This will likely have the opposite effect of what you seem
to desire. BIP8 and BIP9 give us the ability to have multiple independent
soft forks in flight at once. Choosing to bundle them instead makes little
sense when we do not have to. Bundling them will inevitably degenerate into
political horse trading and everyone will be worse off for it.

> part of the network disagrees on whether to activate the consensus
change, part of the network disagrees on how to resist that consensus
change, part of the network disagrees on how to activate that consensus
change etc

Disagreements, and by extension, forks are a part of Bitcoin. What is
important is that they are well defined and clean. This is the reason why
the mandatory signaling period exists in BIP8/9, so that clients that
intend to reject the soft fork change have a very easy means of doing so in
a clean break where consensus is clearly divergent. In accordance with
this, consensus changes should be sequenced so that people can decide which
sides of the forks they want to follow and that the economic reality can
reorganize around that. If choose to bundle them, you have one of two
outcomes: either consensus atomizes into a mist where people have different
ideas of which subsets of a soft fork bundle they want to adopt, or what
likely comes after is a reconvergence on the old client with none of the
soft fork rules in place. This will lead to significantly more confusion as
well given that with sufficient miner consensus some of the rules may stick
anyway even if the rest of the user base reconverges on the old client.

It is quite likely less damaging to