zeroth-Descendant Transaction Chain and BIP69

Normal wallets should basically always apply bip69 for transactions they create.

The downside of this here is that OP_RETURN outputs would be the zero'th output and you'd burn your identity.

I suggest a special casing here to avoid accidentally losing your identity, when the zero'th output is an op-return, use the second one.

Jonas has raised this point again, I'll just copy the talk verbatim from TG channel

bitcoincashautist, [12/5/22 10:49 PM] @bitjson BCMR q from @jldqt : "(thinking of loud) I wonder if it would be best to have the authbase->authhead txid chain available in an API in the BCMR service/indexer separated from the Electrum protocol. An Electrum client would only need to verify the authhead using SPV."

"And also: was there any resolution to the BIP-69 problem where OP_RETURN outputs is placed as the first output. Will BCMR use 'first-index-with-nonzero-amount" or should wallets not use BIP-69?"

bitcoincashautist, [12/5/22 10:49 PM] for the 2nd part I think I can answer: the spec is clear: index 0 output... whatever the locking script is, so OP_RETURN terminates an authchain, and apps using authchains should not use BIP69 sorting

bitcoincashautist, [12/5/22 10:50 PM] very simple convention... then it's on users to make good use of it and ensure the desired output goes in the 0 slot

Tom Zander, [12/5/22 10:52 PM] I think I opened a bugreport on the authchain spec about the op_return issue.

My suggestion is to go for the first non-zero output.

Tom Zander, [12/5/22 10:52 PM] Saying people should not use bip69 is asking for trouble.

bitcoincashautist, [12/5/22 11:14 PM] but like, you're not going to use a normal wallet to do authchains? I have to say I hated bip69 when I was playing with contracts because specific order of my ins&outs mattered since introspection opcodes required the right thing at the right index, and I was annoyed that electron cash sorted my tx even when I imported it from raw. If the idea is to avoid fingerprinting "normal" wallet software, then if you use contracts/special opreturn your'e already kinda exposing yourself as abnormal user, right? So what exactly does bip69 achieve when used on "special" txes?

bitcoincashautist, [12/5/22 11:16 PM] but sure, I understand your pov... let's just c&p this to the issue

Jonas, [12/5/22 11:30 PM] Kind of the whole point of BIP-69 is to not have "special" transactions where one observer can gain any (albeit tiny) information of the purpose of the transaction just by looking at the order of the outputs. If 100% of all transactions currently follows BIP-69 (I have no idea what the actual number is… 1%? 10%? 99%? Dunno but it's easy to find out) any movement of an authhead will stand out like a sore thumb. There might very well be token metadata that is supposed to be "private" for a select few.

bitcoincashautist, [12/5/22 11:32 PM] that makes sense when you do normal p2pkh -> p2pkh (or multisig p2sh)... but as soon as you add some contracts or opreturns then that alone already flags it as special, what exactly would sort order achieve? unless there are multiple wallets which can do these "smart" txes so the sort order hides which software you're using

bitcoincashautist, [12/5/22 11:33 PM] even still... if the spec can work with bip69, I guess it's 0 cost and some little benefit for privacy

I fully agree that EC is being silly if it reorders a transaction it didn't build.

But that directly also is the reason for my point of view. Wallets very likely will just do the lazy thing and reorder before signing instead of reorder on building. And thus they kill an authchain by accident.

So, sure, you could say that the wallet is wrong, and indeed I think EC may benefit from changing that. But maybe we can fix the spec to not kill your authchain when that happens.

My suggestion is to go for the first non-zero output.

Shuld we make a PR for this @bitjson ? Redefine the spec to say "first non-zero output" instead of "first output" - it'd still be Script-agnostic and you could still send 1 sat to an OP_RETURN if you wanted to burn the authchain.

Hey y'all! Sorry I haven't had time to focus back on BCMR yet, hoping to do so in March or April. I definitely encourage anyone interested to try different variations and see what works best! It's hard to judge things very well just looking at the spec, we really need to try things in wallets and indexers.

On this issue specifically, I'm wary of adding a logical branch to this spec to accommodate BIP69. Scattered thoughts:

Authchains are naturally on-chain entities, so their "transactional privacy" is irrelevant – pseudonymous users gain no additional value by making their authchain transactions BIP69 compliant:

If you're using OP_RETURNs for signaling, the whole world can see the signal, so BIP69 is worthless
If you're not using OP_RETURNs for signaling, only parties you've shared the authbase with are following your transaction, and BIP69 is irrelevant; other parties can see that your transaction isn't BIP69 compliant, but that still doesn't impact your privacy (if anything, it just reduces the anonymity set for other BIP69 users by an infinitesimal amount)

Authchains are controlled via output ordering: if you want authchain transactions to comply with BIP69, you're committing to grinding for valid matches, possibly using HD keys and skipping indexes and/or other deterministic generation of statically pushed values. Worse, since output values are sorted too, you sometimes need to reallocate actual funds to make a match.

It's maybe a shame that BIP69 didn't choose to order output amounts in descending order – covenant treasuries, vaults, etc. are likely going to want to use those higher indexes for contract behavior, so forcing larger outputs to the end of the list is logistically messy. In fact, I'd entertain the thought of BIP69 being amended in the BCH ecosystem to sort outputs in descending order. (But there still: other activity is making clustering easy, BIP69 doesn't add much privacy.)

Good point that BIP69 sorting makes accidental burning of identities more likely. In context though: that's only possible if we're talking about a wallet sophisticated enough to be creating OP_RETURNs for some reason, but not sophisticated enough to understand authchains/identities + the user has transferred an identity to that wallet. This remains a bad situation even if we make a special case for 0-value outputs, and I'd argue the spec change makes it even worse: sure we prevent the wallet from burning the identity, but under most UTXO management strategies, the wallet is now giving the identity away as a change output! (Wallets attempt to select the smallest UTXO that satisfies a payment requirement, and the smaller change will now be sorted to output 0.)

So even if we make a special case for zero-value outputs, outcomes haven't improved:

The tiny fraction of these "naive wallets" that for some reason add an OP_RETURN output to their transactions) go from burning the identity to giving it away – a worse outcome. It would be better to publicly retire the identity (fixed damages) than have it unwittingly compromised (unlimited damages).
The much larger portion of naive wallets that don't use OP_RETURN outputs are still giving away identities (we haven't solved the root problem: users sending identities to wallets that don't understand/handle them properly).

So it seems like the more complete solution to this issue would be a standard scheme for signaling identity support in wallets via addresses/URIs/payment protocol/etc. Maybe just i=1 as a query parameter in the URI scheme?

To be clear, nobody is arguing that this CHIP endorses the use of BIP69 anonymity transaction building.

The point is to accept that wallets do and will use BIP69 for transaction building. And at least some will not implement two codepaths for transactions. So a standard library that adds sorting of outputs to the signing of a transaction is an example usecase which we will definitely hit in the future. Better be ready for it.

I don't think denying that this will happen is going to stop it from happening.

the wallet is now giving the identity away as a change output!

That's an interesting observation, sounds sane at first, even.

The problem with the observation is that an update to the authchain is not a transfer of funds. I'd like to know where you see a 3rd party being involved in this kind of transaction at all. It will always be a payment from me to me. That's kind of the point in order to add info to the chain. Sure, some funds may be added, and change may be involved. But more likely its just going to be one UTXO moving. No addresses involved that are not owned by the authchain owner.

(we haven't solved the root problem: users sending identities to wallets that don't understand/handle them properly).

The same observation here, a user uses a wallet to send to their own wallet, but adding or updating some information on the chain.

So it seems like the more complete solution to this issue would be a standard scheme for signaling identity support in wallets via addresses/URIs/payment protocol/etc. Maybe just i=1 as a query parameter in the URI scheme?

I don't follow this line of thought. Can you explain?
Edit; where in the normal way of updating identities would there be a payment protocol involved? I don't see the need or even the use for that.

The problem with the observation is that an update to the authchain is not a transfer of funds. I'd like to know where you see a 3rd party being involved in this kind of transaction at all. It will always be a payment from me to me.

This is a blockchain-external standard so wallets mishandling these UTXOs is possible. If you receive an identity UTXO to Electron Cash, and because the wallet is not watching out for identities, then it would treat it like any other BCH UTXO... so when you do your normal spend you'd either:

accidentally send it to your recipient
accidentally send it back to yourself as change output

Electron Cash can also easily send to OP_RETURN (just add a OP_RETURN, 0 line to recipients text box) in which case you'd be burning the identity if current standard is applied.

The case would depend on what UTXOs you have in your wallet, the coin selection algo, etc. and sometimes you'd have to violate BIP-69 even if we defined the authchain as "1st non-0 output" because here both outputs would be non-0 because from the PoV of the BCMR standard this would be a key-rotation TX that made no attestations to the external data (no opreturn).

So... if OP_RETURN is omitted sometimes we have to violate BIP-69 anyway, right, because otherwise we'd be gifting the identity, or we'd have to freeze the identity UTXO. Also, if there's a BCMR OP_RETURN in the TX, then it's already marked so as "special" to external observer, so what's the point of BIP-69, I mean - identities are like the opposite of privacy, they're pseudonymous, sure, but the whole chain is linked to the same pseudonymous ID by design.

I wrote this in the Tg discussion, trying to make the argument for redefining it to "non-0", but it's not a strong argument:

even still... if the spec can work with bip69, I guess it's 0 cost and some little benefit for privacy

and it's not 0 cost, and the benefit of complicating BCMR to fit in with BIP69 is close to 0, too. So, I'm with Jason & Pat here, let's keep the standard simple.

The problem with the observation is that an update to the authchain is not a transfer of funds. I'd like to know where you see a 3rd party being involved in this kind of transaction at all. It will always be a payment from me to me.

This is a blockchain-external standard so wallets mishandling these UTXOs is possible. If you receive an identity UTXO to Electron Cash, and because the wallet is not watching out for identities, then it would treat it like any other BCH UTXO..

The sentence you replied to argues its a payment from me to me, no 3rd, or 2nd party present. So in what scenario would your electron cash receive this authchain-tip UTXO in a way it will show up in your coins-to-spend?

Nobody is suggesting we explicitly include BIP69 anonymity with this CHIP. The point is that we can't guarantee nobody will. And it will happen at one point. Aferall, the point of BIP69 is that all transactions look the same and can't be identified simply by looking at the outputs. So, when it eventually will happen, how to avoid that causing a loss of your identity chain?
Think about it, a nice wallet adds support for this stuff. Then a month or two later someone starts to care about anonymity and adds bip69 intended for their main usecase of payments. Deploys it and realized only later that their users now lose their identities when adding certain types of data to their auth-chain. Any developer will have to admit this is an entirely plausible scenario. Lets not be sorry, but be safe.

For a wallet I'd personally consider using a different derivation path for addresses associated to an auth-chain. Invisible to the blockchain, much easier to ensure the UTXOs don't get mishandled. You DO want specific wallet support when parsing and updating that auth-chain.

So this thread leaves me with several questions;

does anyone see any real-life risk of accidentally transferring auth-chain control when accidentally sorting the outputs?
This is in the context of real life usage where authchain updating transactions are almost always from me to me.
if anyone receives an entire auth-chain (full transactions), to find specific meta-data included in it, what is the cost of adding the "first non-0" rule? They needed to parse all transactions fully in either case in order to find things like a human-readable name and whatever they care about. I suspect the cost is near zero in all relevant implementations.
Jason's initial solution to use an extra i=1 option, how would that work together with something like a full auth-chain being shared for download? I don't see how it can be used to validate correctness if we hold onto the current rule except when the user asks for it...

Again, nobody is suggesting that this CHIP should include a recommendation to use the anonymity sorting of outputs. Arguing against that is not helpful to resolving the issue.

bitjson / chip-bcmr

zeroth-Descendant Transaction Chain and BIP69 #3