Pay server

Pourquoi pay() doit avoir lieu avant les autres signatures

Engagement de signature : Les signatures Bitcoin hachent l’intégralité de la structure de la transaction (inputs, outputs, montants, scripts). Modifier quoi que ce soit après la signature invalide les signatures (le hash change).

Dans les transactions multi-parties :
La fonction pay() modifie la transaction (elle ajoute des inputs/outputs pour les frais) → elle doit donc intervenir avant les signatures finales sur ces nouvelles parties.

Si une partie signe en premier, puis que pay() ajoute des inputs → les signatures sont cassées (elles s’étaient engagées sur l’ancien hash).

SIGHASH_ANYONECANPAY permettrait théoriquement au client de signer avant le pay(), mais voici pourquoi Run n’utilise pas SIGHASH_ANYONECANPAY dans son code par défaut :

Le protocole Run (avant RunCraft) utilise exclusivement SIGHASH_ALL pour garantir l’intégrité des jigs.

Sécurité et engagement :
SIGHASH_ANYONECANPAY permet à n’importe qui d’ajouter des inputs plus tard sans casser les signatures existantes. C’est très utile pour des transactions collaboratives comme les atomic swaps ou les coinjoins, mais c’est risqué pour le système de jigs de Run.

Les jigs/tokens sont stateful (propriété, méthodes, références dans OP_RETURN, etc.), donc Run veut un engagement total sur la transaction pour empêcher toute manipulation.

Si un client signait avec ANYONECANPAY, un PayServer malveillant (ou un intermédiaire) pourrait ajouter des inputs/outputs malveillants (ex. : voler des fonds).

SIGHASH_ALL garantit que le signataire accepte exactement la forme de la transaction telle qu’elle est au moment de la signature.# Markdown syntax guide