user2565: We are implementing the vesting contract from Plutus use cases via cardano-cli
In the validator script we have the pubKeyHash of the pubKey authorized to retrieve the funds.
When the owner of this key wants to retrieve funds, the validator script checks into TxInfo and compares the pubKeyHash of the signer with its hard coded pubKeyHash.
To build such a transaction with cardano-cli we have to use the --required-signer flag to tell cardano-cli we need this key to sign the Tx because the validator script requires it.
We successfully built transaction using "normal" Shelley keys "PaymentSigningKeyShelley_ed25519" (generated with cardano-cli address key-gen --normal-key).
But it doesn't work using extended keys "PaymentExtendedSigningKeyShelley_ed25519_bip32" (generated either using cardano-cli address key-gen --extended-key or converting a cardano-address key using cardano-cli key convert-cardano-address-key --shelley-payment-key).
cardano-cli excludes extended keys from required signers (https://discord.com/channels/826816523368005654/900330165941436427/900330567416029206)
As BIP 32 is THE standard for wallets we want users to be able to interact with the vesting smart contract using their BIP 32 wallets (such as Daedalus).
I have limited knowledge in cryptography so my questions are :

Why cardano-cli is excluding extended keys ?
Is it possible to derive a "normal" Shelley key from an extended one ?

EDIT
For now we have forked cardano-cli and authorized extended keys but it's a dirty hack and we are waiting for answers or solutions.
https://github.com/smart-chain-fr/cardano-node/pull/1

user7022: I'm working on similar problem, but i thing this answer should solve your problem: https://cardano.stackexchange.com/a/7428/7022

2565: <p>We are implementing the vesting contract from Plutus use cases via cardano-cli</p>
<p>In the validator script we have the pubKeyHash of the pubKey authorized to retrieve the funds.
When the owner of this key wants to retrieve funds, the validator script checks into TxInfo and compares the pubKeyHash of the signer with its hard coded pubKeyHash.</p>
<p>To build such a transaction with cardano-cli we have to use the --required-signer flag to tell cardano-cli we need this key to sign the Tx because the validator script requires it.</p>
<p>We successfully built transaction using &quot;normal&quot; Shelley keys &quot;PaymentSigningKeyShelley_ed25519&quot; (generated with cardano-cli address key-gen --normal-key).</p>
<p>But it doesn't work using extended keys &quot;PaymentExtendedSigningKeyShelley_ed25519_bip32&quot; (generated either using cardano-cli address key-gen --extended-key or converting a cardano-address key using cardano-cli key convert-cardano-address-key --shelley-payment-key).</p>
<p>cardano-cli excludes extended keys from required signers (<a href="https://discord.com/channels/826816523368005654/900330165941436427/900330567416029206" rel="nofollow noreferrer">https://discord.com/channels/826816523368005654/900330165941436427/900330567416029206</a>)</p>
<p>As BIP 32 is THE standard for wallets we want users to be able to interact with the vesting smart contract using their BIP 32 wallets (such as Daedalus).</p>
<p>I have limited knowledge in cryptography so my questions are :</p>
<ul>
<li>Why cardano-cli is excluding extended keys ?</li>
<li>Is it possible to derive a &quot;normal&quot; Shelley key from an extended one ?</li>
</ul>
<h2>EDIT</h2>
<p>For now we have forked cardano-cli and authorized extended keys but it's a dirty hack and we are waiting for answers or solutions.</p>
<p><a href="https://github.com/smart-chain-fr/cardano-node/pull/1" rel="nofollow noreferrer">https://github.com/smart-chain-fr/cardano-node/pull/1</a></p>
 7022: <p>I'm working on similar problem, but i thing this answer should solve your problem: <a href="https://cardano.stackexchange.com/a/7428/7022">https://cardano.stackexchange.com/a/7428/7022</a></p>
