Subset means, unlike the full SLIP-24 proposal, this commit does not implement:
support for multiple outputs per payment request
support for multiple payment requests per transaction
memo types other than text memo
non-empty nonces
The subset is sufficient to cover the first application: selling Bitcoin via PocketBitcoin.
The protobuf messages and code has been designed so that support for the above missing features can be added in a backwards compatible way. This is why there is a payment_request_index in the output, which has to be 0 if present, and where at most one output can attach to a payment request.
To allow a payment request to request payout to multiple addresses in the future, multiple outputs can have the same index, and the sighash computation (the outputs hash part of it) would need to be streamed and validation done at the end.
To allow multiple payment requests per transaction, the payment_request_index can be incremented.
SLIP-24 does not go much into how the trusted party is identified. For now we identify them by the recipient name with one hardcoded pubkey per recipient. We might want to extend this with a certificate chain (root key signs signing keys, possibly with expiry dates, which sign payment requests) - this is postponed until we finalize the design.
We implement a subset of the payment requests protocol described in SLIP-24: https://github.com/satoshilabs/slips/blob/master/slip-0024.md
Subset means, unlike the full SLIP-24 proposal, this commit does not implement:
The subset is sufficient to cover the first application: selling Bitcoin via PocketBitcoin.
The protobuf messages and code has been designed so that support for the above missing features can be added in a backwards compatible way. This is why there is a
payment_request_indexin the output, which has to be0if present, and where at most one output can attach to a payment request.To allow a payment request to request payout to multiple addresses in the future, multiple outputs can have the same index, and the sighash computation (the outputs hash part of it) would need to be streamed and validation done at the end.
To allow multiple payment requests per transaction, the payment_request_index can be incremented.
SLIP-24 does not go much into how the trusted party is identified. For now we identify them by the recipient name with one hardcoded pubkey per recipient. We might want to extend this with a certificate chain (root key signs signing keys, possibly with expiry dates, which sign payment requests) - this is postponed until we finalize the design.