What is the correct Policy?

[n0price]

Dear Signatory Team,
I appreciate your help to share the correct policy to allow backer duties, voting, delegating, staking and unstaking and block transaction (ie: draining funds from consensus key). Thank you!

[michaelkernaghan]

The format in your signatory.yaml file would be

 block:
      preattestation:
      attestation:
      generic:
        - transaction
        - reveal
        - delegation

You can choose from the policy list for the rest:
[activate_account, attestation, attestation_with_dal, ballot, dal_publish_commitment, delegation, double_attestation_evidence, double_baking_evidence, double_preattestation_evidence, drain_delegate, failing_noop, finalize_unstake, increase_paid_storage, origination, preattestation, proposals, register_global_constant, reveal, seed_nonce_revelation, set_delegate_parameters, set_deposits_limit, signature_prefix, smart_rollup_add_messages, smart_rollup_cement, smart_rollup_execute_outbox_message,
smart_rollup_originate, smart_rollup_publish, smart_rollup_recover_bond, smart_rollup_refute, smart_rollup_timeout, stake,
transaction, transfer_ticket, unstake, update_consensus_key, vdf_revelation, zk_rollup_origination, zk_rollup_publish,
zk_rollup_update]

So you might choose:

 block:
      preattestation:
      attestation:
      unstake:
      finalize_unstake:    
      generic:
        - transaction
        - reveal
        - delegation
        - drain_delegate

[n0price]

Thanks, so something like this should work to allow baker duties, delegation and staking transactions only.

tezos:
  tz1ExamplePublicKeyHash:
    log_payloads: true
    allow:
      endorsement:
        - endorsement
        - preendorsement
      generic:
        - delegation
        - stake
        - unstake
        - ballot
        - reveal 
      block:
        - block
    deny:
      generic:
        - transaction   # Deny general transactions (e.g., Alice sending to Bob)
        - drain_delegate  # Specifically block draining of consensus key

[michaelkernaghan]

signatory is "closed by default" so there is no 'deny' block.

also, if you have 'unstake' you might want 'finalize_unstake' as well.

Finally, note as well that endorsement is now attestation and preendorsement is now preattestation

[n0price]

Thanks, the following example now is it correct?

tezos:
  tz1ExamplePublicKeyHash:
    log_payloads: true
    allow:
      block:
      preattestation:
      attestation:
      unstake:
      finalize_unstake:    
      generic:
        - transaction
        - reveal
        - delegation
        - drain_delegate

[michaelkernaghan]

That should work.

[n0price]

Thanks, Is the Ledger reliable to use? Specifically, can we store the backer signing key on the Ledger, and how does this usually work? Does the signer need to retrieve the signing key from the Ledger each time it performs backer duties?

[michaelkernaghan]

The Ledger hardware wallet provides excellent security for storing the signing key required for baking. It isolates the private key within its secure element, ensuring it cannot be extracted or used outside the Ledger's controlled environment. Details of how it works are in the documentation: https://signatory.io/docs/bakers

[n0price]

Thanks, my point does the signer needs to be connected always to the ledger to be able to perform duties?
My understanding as well the same private key that needed for the consensus is the same that control the self bond.

[michaelkernaghan]

The ledger device must always be connected and active as it signs attestations and blocks.

…

On Mon, Nov 18, 2024 at 7:01 AM n0price ***@***.***> wrote: Thanks, my point does the signer needs to be connected always to the ledger to be able to perform duties? My understanding as well the same private key that needed for the consensus is the same that control the self bond. — Reply to this email directly, view it on GitHub <#510 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASWO3VW345ULRO454CA22A32BH6LHAVCNFSM6AAAAABRGE664SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBTGMYDGOJWGQ> . You are receiving this because you commented.Message ID: ***@***.***>

[n0price]

Thanks. from the documentation I can not understand how does the remote signer really needs to be configured in practice.
Do we need to have 2 vms, both with the signer installed? one vm has the configuration to connect to the vault to sign the transaction, plus the hook configuration to connect the policy vm the policy configuration.

So my understanding the setup should something like the following:

The signer vm :

# config root
policy_hook:
    address: host:port
    # List of authorized keys in Tezos Base58 format
    authorized_keys:
        - pub1
        - pub2
        # ...
   
vaults:
  azure:
    driver: azure
    config:
      vault:    

The policy vm config:

tezos:
  tz1ExamplePublicKeyHash:
    log_payloads: true
    allow:
      block:
      preattestation:
      attestation:
      unstake:
      finalize_unstake:    
      generic:
        - transaction
        - reveal
        - delegation
        - drain_delegate

[n0price]

I have two questions:

• the following policy still correct with the new Tezos Protocol upgrade?, normally we want to baker duties without drain transaction, the config contains "drain_delegate" as was suggested by @michaelkernaghan
• The other question I have, how can I configure remote policy, can the following configuration be fetched remotely?

tezos:
  tz1ExamplePublicKeyHash:
    log_payloads: true
    allow:
      block:
      preattestation:
      attestation:
      unstake:
      finalize_unstake:    
      generic:
        - transaction
        - reveal
        - delegation
        - drain_delegate