- Add ephemeral_public_key and requires_payment_message fields to EncryptedPaymentRequest + updated descriptions
- Update EncryptedPayment and EncryptedPaymentACK message descriptions to use ECDH-derived key for signature instead of each side's public key
- Slim down message content-types
- Add EncryptedPayment and EncryptedPaymentACK creation detail steps
- Add updated paymentrequest.proto to bip-ir/ directory
- Add additional flow diagrams for various mobile-to-mobile / Store & Forward scenarios
- Update InvoiceRequest notification_url definition to use SHOULD instead of MAY
- Capitalize MUST, SHOULD, etc.
- Update InvoiceRequest Message Creation steps to specifically define behavior for empty amount or amount out of bounds
- Add implementation section with references to Addressimo reference Store & Forward server and a client implementation in functest_ir.py
- Add flow diagrams for BIP70 extension and moble-to-mobile example with store and forward service
- Update InvoiceRequest to include nonce
- Remove ephemeral_public_key from ReturnPaymentRequest
- Update message validation and nonce usage in processes
- Make Abstract more readable
- Update Sender definition and acronym descriptions
- Added comments to ReturnPaymentRequest definition
- Bold ECDH and AES Setup notes and added "(see below)" for reference
- Removed Requestor/Responder definitions
- Seperated ECDH secret point generation and AES-256 (CBC Mode) setup from individual steps (listed twice) and created it's own section
- Added InvoiceRequest Validation section
All of BIP62's (including the only-new-transactions) are currently enforced
as standardness rules, but it seems hard to push it further. Every new type
of complex transaction may require new extra rules, and some important types
of malleability cannot be addressed by it (for example, a single participant
in a multisig spend creating a new signature with a different nonce).
It seems wiser to pursue normalized txid or segregated witness-based
solutions, which do solve this problem more fundamentally.
Previous wording was very confusing now that most people will associate
payment channels with CLTV-based payment channels rather than Jeremy
Spilman style payment channels.
