ApplyTxError [LedgerFailure (UtxowFailure (MissingVKeyWitnessesUTXOW))]

Staking & Delegation Operate a Stake Pool
1

I had trouble registering our stake address (starting from here), getting the same error every time even though cross-checking against other instructions & scripts. Then I took it back a step to see if I could submit a transaction for our payments address (payment.addr in many documents) and got the same error, also every time:

Error while submitting tx: ApplyTxError [LedgerFailure (UtxowFailure (MissingVKeyWitnessesUTXOW (WitHashes (fromList [KeyHash "..."]))))]

I’ve been over this all day and I can’t see what we’re missing. If we can avoid that error message in the basic transaction, we should be able to do the rest of the registration tasks that require payment. I don’t know what part of the error message indicates the problem so I’ll quote our whole process, with apologies for a huge posting. I hope someone can please have a look & say what we might have missed.

Prerequisites (all without error):

payment-source.addr = one of the addresses from my own Daedalus wallet

core-nyc1$ cardano-cli shelley query utxo --address $(cat payment-source.addr) --mainnet
… shows a single transaction hash & index (calling below TxHash#TxIx) with 202796000 lovelace

cardano-cli shelley query protocol-parameters \
--mainnet \
--out-file protocol.json

cardano-cli shelley address key-gen \
--verification-key-file payment.vkey \
--signing-key-file payment.skey

cardano-cli shelley stake-address key-gen \
--verification-key-file stake.vkey \
--signing-key-file stake.skey

cardano-cli shelley address build \
--mainnet \
--payment-verification-key-file payment.vkey \
--stake-verification-key-file stake.vkey \
--out-file payment.addr

cardano-cli shelley stake-address build \
--mainnet \
--stake-verification-key-file stake.vkey \
--out-file stake.addr

cardano-cli shelley transaction build-raw \
--tx-in TxHash#TxIx \
--tx-out $(cat payment-source.addr)+0 \
--tx-out $(cat payment.addr)+0 \
--ttl 0 \
--fee 0 \
--out-file fund-payment-addr.tx.test

cardano-cli shelley transaction calculate-min-fee \
--tx-body-file fund-payment-addr.tx.test \
--tx-in-count 1 \
--tx-out-count 2 \
--witness-count 1 \
--byron-witness-count 0 \
--mainnet \
--protocol-params-file protocol.json

176413 Lovelace

202796000 (my UTXO) - 176413 (tx fee) - 2200000 (funding for payment.addr) = 200419587

set --ttl = current tip point + 600 or so (we’re not getting the “Expired” error)

cardano-cli shelley transaction build-raw \
--tx-in TxHash#TxIx \
--tx-out $(cat payment-source.addr)+200419587 \
--tx-out $(cat payment.addr)+2200000 \
--ttl 5352560 \
--fee 176413 \
--out-file fund-payment-addr.tx.raw

cardano-cli shelley transaction sign \
--tx-body-file fund-payment-addr.tx.raw \
--signing-key-file payment.skey \
--mainnet \
--out-file fund-payment-addr.tx.signed

Our transaction error (which we also get when submitting our certificate):

cardano-cli shelley transaction submit \
--tx-file fund-payment-addr.tx.signed \
--mainnet

Error while submitting tx: ApplyTxError [LedgerFailure (UtxowFailure (MissingVKeyWitnessesUTXOW (WitHashes (fromList [KeyHash "..."]))))]

1 Like
2

MissingVKeyWitnessesUTXOW means one or more of the required private keys didn’t sign.

The utxo you are querying is payment-source.addr and the build transaction is being funding by with “payment-source.addr” - these are consistent, but the transaction is being singed with payment.skey

Do you have a payment-source.skey you can sign the transaction with?

This transaction should fail:

also, be extra careful to avoid repeating any steps where you may accidentally overwrite existing keys

3 Likes
3

Thanks again @ADAfrog. When I woke up this morning after a night’s sleep, my first thought was that, if what I were doing above were possible, then any unprivileged surfer of the block explorer could simply pocket all the UTXOs they found there. :crazy_face:

I was focused on somehow providing authentication of the destination address, since the original purpose of this transaction was to register our stake address. So in this context it didn’t occur to me that I was doing nothing to authenticate the transfer from the source address.

Since it was a Daedalus UTXO it would be easier just to fund payment.addr from Daedalus. If it had to be done on the command line (e.g. for a registration) I guess we could get the Daedalus signing key as described here ( shelley_staking_gen.md ) but for this particular case it might be too much trouble.

Good advice, but I wanted to take this all the way back to the beginning each time since the signing keys were exposed on our server during the hours I was trying to research what was wrong. Until the point the stake pool registration certificate is paid for, both the above *.skey files are expendable… and should be deleted if possible on general principles if lying around in the clear for so long & not yet tied to any payments or registrations. :sunglasses:

2 Likes
4

this situations sounds serious. so what happens if you overwrite or lose existing keys as you say and in a few years want to retire your pool. don’t you need keys to retire the pool? Will the pool just keep lingering into infinity if keys not available when retiring pool?? Thanks

5

An extreme example of this problem would be:

  1. You run through the standard steps to create your payment keys, transfer the pledge into the payment address linked to those keys, create the stake cert, register the pool.
  2. You need to do some of the more recent step(s) again, like re-register the pool with different parameters, but go back too far in the procedure: e.g. all the way to the beginning & recreate one or more of the payment addresses using the same standard filenames.
  3. Since you have overwritten the file payment.addr and/or its payment.skey, you have just lost your pledge (unless those files are backed up somewhere else).

To keep yourself safe you must be very conscious of each file and its use. If you need to have multiple versions of a file, like for a new payment address you might use, then name it explicitly so they don’t get confused, or put it in a folder along with other files of the same purpose. Our own stake pool has been working on an environment to make this easier & @HighStakes if you’re interested then I’ll post a link here when it’s ready.

1 Like
6

Thanks for the input… I also asked a protocol governance hypothetical question in trying to retire a pool without keys. Do pools just become dormant and linger on the chain if not properly retired ? Or is there a kill switch or cleanup process in the cardano’s protocol that removes pools after a few months if there is no activity and the pool hasnt been retired properly due to no keys. Cheers!

7

Pools need to be retired or will remain active on the chain. The pool will cease to produce blocks when either the pool’s KES keys expire or when the pool ceases to operate. At this point any assigned slots will yield unminted blocks, which in-turn will impact chain density as long as enough stake remains in the pool to mint. There would be network health issues if enough pools with sizable stake cease producing blocks.

2 Likes
8

Cool thanks!

Speaking of keys… can I regenerate all new private keys without causing issues to my existing pool? All of my current private keys are intact however over the weekend two of my roommates had some friends over when I was out of the house (hhmmmm). Instead of creating a new pool, can I just write a transaction that regenerates all new coldkeys without breaking anything? Is there a guide for this?

As always, cheers and beers

9

If your pool cold keys are compromised, then no - you would need to register a new pool. Otherwise you can re-register your pool again (minus paying the 500 Ada deposit) using a new rewards and owner addresses (while keeping the old pledge address in the registration). Let the registration take effect and then move your pledge over to the new pledge address. Next re-register your pool removing the old pledge address.

1 Like
10

As they say, not your keys, not your stake pool… not compromised… perhaps just paranoid. Besides a dose of paranoia will keep you ALIVE.

THANKS again frog
And as always, cheers and beers

1 Like
11

Hello there, we’re running through the same issue here.
We created, funded and registrered a Daedalus wallet but we inappropriately made a 10 ADA out transaction through Daedalus a couple of days later using pool wallet. This changed our pledge wallet address, right? Am i going to see my pledge wallet not certified for the next epoch or so?

I was rebuilding pool certificate to add a relay when this error showed up, i traced balance and utxo and i found by Daedalus and cli query that:
Original pool wallet (top listed USED in daedalus) shows 0 ada and 0 tx (bit of a heart attack there…)
New daedalus address (second listed USED in daedalus) shows current correct balance (pledge + little margin) and 1 tx (possibly our 10 ada out)
First Receive address in daedalus (first white address, to be used) shows 0 and 0

My plan is to try and resend pledge and pool certificates using:

  • original pool keys
  • new daedalus address as payment address (the one showing correct stake and 1 utxo), and never make pool pledge wallet transactions through daedalus again
  • immutable reward address
    and that should be working fine without paying 500 ADA registration fee again, am i right? I should succeed without practically creating new wallet and retransfer pledge funds, correct?

My cold keys are not compromised nor ever overwritten, so i don’t think i need to recreate a new pool from scratch and all the regenerated certificates on cold machine could (and should) be overwritten without compromising anything, bux fixing everything instead…

Vig

12

Practically speaking, i would force base.addr and base.addr_candidate to be the same with my current funded daedalus address, re-create stake keys and re-register the pool.
Is it gonna work?
Vig

13

No one’s got any clues yet?
Looks to me as a very simple thing to be solved, just waiting for a go-no go confirmation…
Thanks in ADAvance!
Vig

14

This is absolutely terrifying. I am making multiple backups immediately after sending this message.

15

I don’t. Came here for answers.