Skip to main content

credit_pool_output_only_extra_sighash_data_v0

Function credit_pool_output_only_extra_sighash_data_v0 

Source
pub fn credit_pool_output_only_extra_sighash_data_v0(
    bundle_tag: u8,
    owner: &[u8; 32],
) -> Vec<u8> ⓘ
Expand description

Version 0 layout of the credit pool’s outputs-only bundles — Shield, ShieldFromIdentity and ShieldFromAssetLock: bundle tag (1) || owner (32). Frozen: never mutate; a layout change requires a new credit_pool_bundle_binding version.

These bundles have no spends, so they carry no anchor to pin them to anything: the proof and the binding signature verify wherever they are submitted. Unbound, the authorized bundle bytes are a free-standing, self-verifying object: anybody can lift them out of the mempool into a transition of their own, funded by their own credits, and any bundle ever published can be replayed. The copier pays the full amount to the original recipient and gains nothing, but the copy lands a second note with the same commitment and the same nullifier in the credit pool, whose notes share one nullifier set, so only one of the two can ever be spent.

The owner is what a third party cannot authorize: the addresses, identity or asset lock whose signatures fund the original. The tag stops a bundle proved for one kind from being submitted as another, which the owner alone would not: the three kinds are otherwise indistinguishable to the proof, and an identity created from an asset lock has that lock’s identifier as its id.

This does not reach Faerie Gold. The rho of an outputs-only note is the nullifier of its bundle’s dummy spend, so a sender who builds and signs a fresh bundle reusing the same dummy spend note and rseed gets the same commitment and the same nullifier under any preimage, and a recipient counting deposits by commitment credits two where only one can be spent. Nor does it stop the funder landing their own bundle twice through a new transition, as a client that retries with a fresh nonce does — except for ShieldFromAssetLock, whose lock can fund one successful shield only (see shield_from_asset_lock_extra_sighash_data). Closing either would need the bundles’ dummy nullifiers recorded and checked, which consensus does not do.