How about we deprecate SIGHASH_UTXO?

Technical
#1

The cashtokens proposal was humongous in size and a new signing method slipped in without much discussion. I’m thinking most people assumed someone else vetted the idea. The dreadful “someone” :wink:

The tech:

SIGHASH_UTXOS does not in actual fact add any data hashed that wasn’t hashed before.
It adds all prev-outs (the transaction outputs collectively being spend in this tx) as a whole, but this is not extra information since signing with SignAllInputs (default) includes the txid’s of the previous transactions. A txid is a hash of the entire transaction, so it’s already there.

So this is not “more secure” in any cryptographic sense. The exact same amount of content is covered by the signature with or without this sighash.

As the proposal also states, this new signing method is about covering a certain type of wallets. Hints are made towards hardware wallets. Not sure why, the proposal doesn’t go into details.
Specifically, the proposal concedes, there is no benefit at all to this sighash type for wallets that have full information. Where ‘full information’ means the previous-transactions (being spent).

So, what is the entire point, you may ask?

Well, since introspection opcodes got introduced, what other inputs get funded with may be relevant to your script too. Signing input 1 you would want to check for correctness what that other guy is doing on input 2 and output 2. And that implies you need to have the full script (including token data) that is being spent in input 2. Can’t verify that otherwise.

The simple solution to that is you request that transaction from the party that signed input 2. They have it in their wallet, so they can share it with you. And since the input 2 includes the txid, you can trivially hash the transaction you received to verify they gave you the real info.

So, the entire point seems to be to avoid sending a full transaction but instead allow them to only send you a smaller amount of bytes (the utxo).

Downsides:

The SIGHASH_UTXOS is clearly trying to solve a problem that can be solved in multiple ways by end-user wallets. Case in point: if your payment protocol can send all utxos, your payment protocol can send a full transaction or two. It is merely a matter of more bytes. And designing your wallets well.
So, the main downside is that a tiny tiny percentage of unnamed wallets forced this new feature that the entire ecosystem has to care about.

The second downside is that those transactions stand out like a sore-thumb on the blockchain. (nobody uses this). This makes anonimity worse for them.

A 3rd downside is that dsproof does not work for them.

A 4th downside is that if introspection is unlikely to care about more than one or two other input/output pairs. Fetching the full transaction for those you care about scales to need. This signing method on the other hand forces you to fetch ALL utxo’s the transaction spends. This is almost always more of them, most of which you don’t care about.

Let’s deprecate this and make people build proper wallets instead.

The entire idea is based on the premise that some wallets are not capable of fetching the full transaction data from prev-outs they care about.
On top of that, this is only relevant for wallets that are used to build transactions in cooperation with multiple-parties (no need to distrust yourself).
On top of that, this is only relevant for transactions where you’d lose money if someone else lies. (coinjoin doesn’t have this problem, for instance).

I don’t think it makes sense to just blindly believe this is a relevant problem that actually exists. Backed up by only hand-waving statements on who would hit this issue. I mean, writing “hardware wallets” is just insulting our collective intelligence, that is simply not how they work. And, btw, if your internet-facing app is utterly compromised then this scheme doesn’t help you either. And, also, that internet facing part can just download the full transactions to feed the hardware.

I’d say we should make this transaction-type non-standard and give out the message to not use this as it has a lot of downsides.

And we really should be better at splitting massive CHIPs into smaller ones and avoiding the crap being enabled where it can never be removed.

#2

I don’t have time to argue every point, but my main take away is that this new signing algorithm could open the door for more future wallets to participate trustlessly with less requirements. It’s a small change that’s about removing an obstacle for future innovation.

1 Like
#3

You don’t have to care about it, you can just ignore it and only support SIGHASH_ALL for your wallet. Yeah, DSPs could care about it or they could just score them 0 and not care, either.

There’s no reason it can’t work, the time we spent arguing SIGHASH_UTXOS could’ve been better used to patch DSPs to add the optional 32 bytes to the proof data. /someone

Seems to me you want everyone to do something just to avoid this little work to extend DSP protocol (which is still a beta protocol btw).

That is the point, because then, you get to see the contents, and can be sure your co-signer is not trying to sneak in some co-owned UTXO that you could inadvertently unlock with your signature meant for the input you’re actually signing.
The UTXOs could just be provided to you by your co-signer or dapp, you already suggested the same thing but for whole source output TXs:

With SIGHASH_ALL this is optional, because you can generate a valid signature without doing any of this.

With SIGHASH_UTXOS your wallet is forced to request the whole UTXO getting spent as input 2 from the party that signed input 2. They have it in their wallet, so they can share it with you. And if they lie, the signature you generate will be invalid by consensus, so there’s no risk in just trusting it, and you don’t have to fetch the whole source transaction to actually verify it against the input 2’s TXID.

Of course, the signer chooses which sighash to use, so you could just continue signing with SIGHASH_ALL and not be bothered with SIGHASH_UTXOS. But, if you’re being asked to sign a multi-party TX you should insist on using SIGHASH_UTXOS and being given the missing UTXOs.

You’re doing the hand-waving. It was good foresight to add SIGASH_UTXOS. Now, wallets and dapps interacting through WalletConnect are appreciative of it, as it makes signing requests both compact and secure and reduces the needed number of API calls required to fully validate a signing request.

Once we get big enough for the likes of Trezor wallet to care, thanks to SIGHASH_UTXOS they will be able to securely support way more BCH transaction types than they do now.

If in the future we get historyless wallets (those that don’t keep any history, just their UTXOs) - this will make it possible for them to safely interact (exchange involved UTXOs as part of payment protocol, and then do the signing) without being forced to fetch any history.

It is not a new problem, BTC-ers, too, have known about it for at least 6 years:

I think it would be good add a few things
to the sighash by default that were overlooked in BIP143:

  • Committing to the absolute transaction fee (in addition to just the
    amount being spent in each input) would categorically remove concerns
    about wallets lying about fees to HW devices or airgapped signers.
  • Committing to the scriptPubKey (in addition to the scriptCode) would
    prevent lying to devices about the type of output being spent, even
    when the scriptCode is correct. As a reminder, the scriptCode is the
    actually executed script (which is the redeemscript in non-segwit
    P2SH, and the witnesscript in P2WSH/P2WPKH).

As this implies additional information that may not be desirable to
commit to in all circumstances, it makes sense to make these optional.

(source)

Any non-typical-p2pkh stands out: SIGHASH_SINGLE, SIGHASH_NONE, SIGHASH_ANYONECANPAY, interaction with any P2SH input… nothing new here.

#4

How about this for example:
Imagine a wallet that just hands a fully validating node a pubkey.
The node run scantxoutset and returns all utxos matching the pubkey.
The wallet can now safely spend each coin.

Bonus point: the node can be pruned.

#5

This is the kind of comment that honestly doesn’t belong on this forum.

This is a forum about research, not about attacking people and aiming at the knees to “win” an argument.

The facts are clear, they are stated in the proposal from Jason. Nobody is arguing them. All discussion is about fluffy stuff that is completely besides the point. And indeed ad-hominem level at times.

There are literally no actual usecases that are enabled with this tech, as hard as people try to come up with them in the most creative ways. The plain fact is that a party spending a utxo will need the full transaction he is spending. Therefore it is present and can be shared between participants.

I understand the main used protocol (WC) for this does not actually support that today, which is fine and is a good attention point. I think there has been push to design a new payment protocol for years, so this is solvable. It may even be solvable with an update. And if I’ve been misinformed and it is actually possible to send the full data, then what on earth are we even discussing this for.

And as to the actual motivation: this is a new protocol feature. In bitcoin cash the protocol is the lowest level, the building blocks for everything. Adding a new buildingblock is sometimes needed to add a new capability for the entire system. Most of the time it is not needed and permissionless innovation, which builds new features without altering the protocol, is always preferred.

This sighash_utxo solves a minor inconvenience, for a super tiny and niche set of users, in the wrong place. It can be solved, as Jason also wrote, by simply providing them with the data they need. Instead it chose to change the protocol.

The precedent has been set, we should now respond to that adequately. Be honest about this, which is something that has been SEVERELY lacking on this topic, and be technical and practical about how we deal with this.

It is here, it has downsides. Nobody today benefits from it, people in future have alternative solutions they can aim for. So let’s deprecate it and solve the downsides.

#6

The only current downside is no DSP support, which can be fixed if someone™ adds the 32 bytes to DSP protocol, then there will be no more downsides.

Everyone who uses WalletConnect benefits from it because they don’t have to waste API calls and bandwidth.

In the future, when historyless wallets become a thing, even more will benefit, because they will never need to request any historical TX.

#7

Actually…
the fact is that you need LESS bytes with the main signing method because that just signs only data in your output/input pair.

So, no, your claim is catagorically false because there is no wallet in production status that is capable of creating transactions with multiple people signing. And that is the only situation where the extra data may be useful.

No, this is also false. That makes no sense either. Seems to be the exact same mistake as the above statement.

If you mean that “historyless” means not having the current tx, but only the output, then you’re still wrong.

Basic signing doesn’t require other data because you don’t need to trust other people.

If you have more questions, feel free to ping me on Telegram, ok? Or read the spec, you might know which page as you edited it some time ago.

#8

You’re wrong here.

I’m an indexer, you ask me to fetch your UTXOs for your address A.
I find them, and return just the TXID:n and the amount. Can you spend this without looking up the source TX? Yes, you can.
What if I lied about the amount? Then you can’t, the TX will just fail, because the sighash algo covers the amount of the UTXO the input you’re signing is spending.
Or, I’m a wallet actually processing blocks directly from P2P network. I only keep my UTXOs and don’t keep TXs. I can trust myself, I don’t need the history. I just spend and update my wallet’s UTXO state, throw away the history after 10 confs.

There’s another user with the same kind of wallet, I want us to construct a 2-in-1-out TX, I send them the TX template with input refs filled in and ask them to sign input1. They have their UTXOs so they can check input1 references their UTXO and they will have the info on amount and locking script because they logged it as belonging to their wallet.

But, they won’t have any other info about my UTXO getting spent as input0. They have no idea what they’re interacting with (without looking up the TX). With sighash_all, that could be risky.
They could ask for the UTXO’s details, but they can’t trust it because even if wrong, their sighash_all sig would be valid because it covers only the TXID:n of the sibling input(s).

With sighash_utxo, they’d need the correct UTXO details to be able to provide signature, and the other party can provide just that. No need for either party to keep or look up whole TXs.

#9

How about we deprecate SIGHASH_UTXO?

Depends.

  • Is this tech being used right now?
  • How widely is it being used?
  • Does removing it actually solve any kind of problem?
  • Does removing it introduce a new kind of problem?

Depending on what is the answer to these questions, we can logically proceed with deciding an outcome.

@tom

#10

Is this tech being used right now?

There are wallets that use it, but they are not getting any of the benefits from it because the benefits are very specific and nobody is doing anything like that.
It is as simple as to stop using the flag and nothing bad will happen to those wallets.

How widely is it being used?

I have not investigated which wallets do this, it is not a big amount of transaction we see flowing into new blocks but it does mean a coordination needs to take place.

Does removing it actually solve any kind of problem?

Nobody wants to remove the feature at this time. The point is to correct any messaging given in the past that this is what people should use. While it is not.
People expect the new signing method to be an improvement while in actual fact it degrades the experience (more data to transfer, no dsp support, worse anonimity).
So the main point is to tell people “hey, our bad, please stop using this”.

After we coordinate with wallets that now send this and make them stop, we can make transactions non-standard to avoid anyone else in the future falling in the same trap. Simple, cheap and effective.

Does removing it introduce a new kind of problem?

No, it does not.

#11

Well, since you said that wallets use it, then above is not true.

Removing it does cause problems, because wallet developers will have to change their code.

Also we do not exactly know what is the precise list of wallets using it.

Another huge problem.

More data to transfer? How much data are we talking about?

Does the data need to be stored on the blockchain forever?

If yes, can it be pruned?

#12

Even though Tom prefixed this claim with “in actual fact” it is nevertheless wrong.
Signing with SIGHASH_UTXOS requires* a wallet to retrieve and inspect the spent UTXOS. Signing with SIGHASH_ALL (the default) requires* a wallet to retrieve and inspect the spent transactions. Since UTXOS are a subset of the transactions it is mathematically less data.

*) For wallets that don’t care (for whatever reason) they can just sign with SIGHASH_ALL and no data had to be fetched at all.

Of course very few wallets are using this (over 1 million inputs signed with it so far) – it was just activated a little over a year ago.

No. It’s just what data that wallet was using while creating the signature.

1 Like
#13

I expected you to read the context, you removed the “After we coordinate with wallets” part and quoted me out of context.

It was actually super clear in my post, you misreading it actually took skill. Congrats!

#14

This is a research site, not reddit…

for everyone reading along, no, Jonas seems to have no clue.

To all the people replying so far, people this was labelled “technical” for a reason. The docs are available, the sources are available. You probably will get a better result from a grok/chatgpt!

#15

So yes, this is a research site.

In quoted post, you used a lot of words yet you did not even directly confirm whether Jonas is right or wrong. You also did not specify how much and how specifically he is wrong (or right).

Please be more technical about what it is you actually mean.

Honestly Jonas has posted more technical details than you.

Code snippets for SIGHASH_ALL and SIGHASH_UXTO is fine, I can read code. Don’t be shy.

1 Like
#16

Yes, let’s! It’s all there in the rationale.

SIGHASH_UTXOS eliminates a set of potential vulnerabilities in light wallets and offline signing devices including unexpected fee burning, unexpected token burning, theft, or unexpected actions in decentralized applications.

Alternatively, signers could download and verify the spent output of each transaction referenced by each input prior to signing vulnerable transactions, but this approach would require significantly higher bandwidth, memory, and/or storage requirements for many light wallet and offline signing devices, impeding support for interacting with tokens or decentralized applications.

1 Like
#17

The “storage requirement” isn’t just for the wallet and if it fetches/saves the referenced transaction or a subset thereof. It could very well be the storage requirement difference for the dapp of having a full node with txindex versus a pruned node initialized via fastsync.

1 Like
#18

I write a technical post and 3 people so far have posted critique.
Now, I can deal with critique, that is not an issue.

What has become very apparant here is that the only active posters here on this forum are agressive while being clueless. This is not a good combination.
If you don’t understand the tech, be humble and ask. But being agressive while being completely wrong doesn’t obligate ME to explain, it makes me very much not want to engage. Drop the attitude if you want something from me, ok?

Saying that sighash_all requires you to fetch and fully hash previous transactions is so utterly wrong that it boggles the mind. Imagine that for a moment, it would completely destroy the option to do pruning. Yet, we’ve had that for years…

If you want to learn, be kind and open to being wrong.
If you want to agressively tell the guy that did the research and posts their results here that he’s wrong, while being confidently wrong yourself, then you’re irrelevant. :man_shrugging:

#19

you’re the one wanting something here, and failing to convince anyone, so you’re throwing a fit

#20

Clueless?

Maybe, partially. So far, I am only asking questions and drawing obvious conclusions from your own answers.

Notice I did not claim I have any knowledge on the topic whatsoever. I just used simple logical deduction to analyze your knowledge.

But aggressive?

No. This is stil my “chill” level.

I am just curious on whether your idea to remove this feature makes any sense.