Change Details

Depends on D18846 The current approach works locally, but is impractical for real-world postage as we are not able to serialize a signatory and send it to a server. The correct workflow is - Create a partially signed tx with defined outputs and no any required token inputs - Serialize this (so it can be sent to a server) Then, the postage payer - Receives and deserializes the tx to a PostageTx - Calls `addFuelAndSign` to add postage and create a tx that will broadcast There are some general postage "gotchas" that require either more iterative experience in this lib or are left to the discretion of the implementer. For example, the partially signed tx must have finalized outputs. So, it is not trivial for the postage payer to receive change, or to exactly hit a 1 sat/byte tx fee. This lib could be extended to support this, but it would not be a universal use case (sender needs to know postage servers utxo size, availability, change address, etc). This diff makes postage usable for a client-server workflow, making it easy to build apps that use 0-fee token txs (or in-kind-fee token txs).

The current approach works locally, but is impractical for real-world postage as we are not able to serialize a signatory and send it to a server. The correct workflow is - Create a partially signed tx with defined outputs and no any required token inputs - Serialize this (so it can be sent to a server) Then, the postage payer - Receives and deserializes the tx to a PostageTx - Calls `addFuelAndSign` to add postage and create a tx that will broadcast There are some general postage "gotchas" that require either more iterative experience in this lib or are left to the discretion of the implementer. For example, the partially signed tx must have finalized outputs. So, it is not trivial for the postage payer to receive change, or to exactly hit a 1 sat/byte tx fee. This lib could be extended to support this, but it would not be a universal use case (sender needs to know postage servers utxo size, availability, change address, etc). This diff makes postage usable for a client-server workflow, making it easy to build apps that use 0-fee token txs (or in-kind-fee token txs).

Depends on D18846 The current approach works locally, but is impractical for real-world postage as we are not able to serialize a signatory and send it to a server. The correct workflow is - Create a partially signed tx with defined outputs and no any required token inputs - Serialize this (so it can be sent to a server) Then, the postage payer - Receives and deserializes the tx to a PostageTx - Calls `addFuelAndSign` to add postage and create a tx that will broadcast There are some general postage "gotchas" that require either more iterative experience in this lib or are left to the discretion of the implementer. For example, the partially signed tx must have finalized outputs. So, it is not trivial for the postage payer to receive change, or to exactly hit a 1 sat/byte tx fee. This lib could be extended to support this, but it would not be a universal use case (sender needs to know postage servers utxo size, availability, change address, etc). This diff makes postage usable for a client-server workflow, making it easy to build apps that use 0-fee token txs (or in-kind-fee token txs).