{"type":"rich","version":"1.0","author_name":"npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","author_url":"https://nostr.ae/npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2012-11-26\n📝 Original message:This is the next big \"lets all agree to do things the same way\" thing\nI think we should tackle. I'm particularly looking for feedback from\nother bitcoin client developers, even if it is just a quick \"looks\nreasonable, if everybody else is going to do it then I will\n(eventually) too...\"\n\nThanks to Pieter Wuille and Mike Hearn for lots of feedback and\nsuggestions and brainstorming.\n\nThis document is online at https://gist.github.com/4120476\n\nIf you respond to this message, please be considerate of people who\nsubscribe to the digest version of this mailing list and trim your\nresponse.\n\n\nInvoices, Payments and Receipts for Bitcoin Transactions\n========================================================\n\nThis document proposes protocol buffer-based formats for signed,\nauthenticated \"invoices\" and \"receipts\" -- requests for payment, and\nproof-of-payment.\n\nSeparate documents propose an extension to the Bitcoin URI syntax and\nnew MIME types to support them.\n\nMotivation\n==========\n\nThe idea of a \"payment protocol\" to improve on Bitcoin addresses has\nbeen around for over a year. Users have been asking for some features\nin this proposal (like the ability to provide a refund address so\noverpayments or refunds can be returned to customers without the need\nto ask them for their address) for two or three years, and have\nstarted to work around shortcomings in the Bitcoin payment process\nwith creative (but inefficient) uses of transactions.\n\nThe key features of this proposal are:\n\n+ Requests for payment (Invoices) are tied to authenticated identities\nusing the only widely-deployed identity authentication system we have\nright now (X.509 certificates signed by root certificate authorities)\n+ Invoices include a user-friendly description of what the payment is for\n+ Payments include where refunds should be sent\n+ At the end of the payment process, the customer holds a\ncryptographically signed Receipt that can be used as proof-of-payment\nif there is any dispute with the merchant.\n\n\nSpecification\n=============\n\nInvoice/SignedInvoice\n---------------------\n\nAn Invoice is a request for payment from a merchant to a customer:\n\n::\n\n    message Output {\n\toptional uint64 amount = 1;\n\trequired bytes script = 2;\n    }\n\namount: Number of satoshis (0.00000001 BTC) to be paid. If not given\nor zero, then the customer will be asked how much to pay.\n\nscript: a \"TxOut\" script to which the customer should direct payment.\nThis will normally be one of the standard Bitcoin transaction script\n(e.g. pubkey OP_CHECKSIG).\n\n::\n\n    message Invoice {\n        repeated bytes x509chain = 1;\n        repeated Output outputs = 2;\n        required uint64 time = 3;\n        optional uint64 expires = 4;\n        optional bool single_use = 5 [default = true];\n        optional string memo = 6;\n        optional string receiptURI = 7;\n        optional bytes merchant_data = 8;\n    }\n\noutputs: one or more outputs where Bitcoins are to be sent.\n\nx509chain: one or more DER-encoded X.509 certificates that identifies\nthe merchant. See the \"Certificates\" section below for details.\n\ntime: Unix timestamp (seconds since 1-Jan-1970) when the Invoice was created.\n\nexpires: Unix timestamp after which the Invoice should be considered\ninvalid. If not given, the Invoice may be re-used until the earliest\ncertificate expiration date in the X509chain.\n\nsingle_use: If true, this Invoice should be used for only one payment.\nIf false, it may be added to the user's address book and used\nrepeatedly until it expires (e.g. for donations or a recurring\npayment).\n\nmemo: UTF-8 encoded, plain-text (no formatting) note that should be\ndisplayed to the customer, explaining what this Invoice is for.\n\nreceiptURI: Secure (https) URI where a Payment message (see below) may\nbe sent to obtain a SignedReceipt as proof-of-payment.\n\nmerchant_data : Arbitrary data ignored by the client that may be used\nby the merchant to identify the Invoice.\n\n::\n\n    message SignedInvoice {\n        required Invoice invoice = 1;\n        required bytes signature = 2;\n    }\n\nA SignedInvoice is an Invoice signed using the private key\ncorresponding to the public key in the first certificate in the\nx509chain and the HMAC SHA-256 algorithm.\n\nWhen a Bitcoin client receives a SignedInvoice, it must authorize\npayment by doing the following:\n\n1. Validate the x509chain certificate chain up to it's list of root\ncertificate authorities\n2. Validate that the time on the customer's system is before Invoice.expires\n3. Display the \"Common Name\" (CN) string from the first x509chain\ncertificate and ask the customer if they would like to submit payment\n\nPayment\n-------\n\n::\n\n    message Payment {\n        required Invoice invoice = 1;\n        repeated bytes transactions = 2;\n        repeated Output refund_to = 3;\n        optional string memo = 4;\n    }\n\ninvoice : the invoice received from the merchant. A merchant must\nvalidate the Invoice and may reject the Payment if the Invoice was\naltered by the customer.\n\ntransactions : One or more valid, signed Bitcoin transactions that\nfully pay the Invoice\n\nrefund_to : One or more outputs where the merchant may return funds,\nif necessary.\n\nmemo : UTF-8 encoded, plain-text note from the customer to the merchant.\n\nIf the customer authorizes payment, then the Bitcoin client:\n\n1. Creates and signs a transaction with one output sending the Invoice.script\n2. If there is no Invoice.receiptURI, then the transaction is\nbroadcast on the Bitcoin p2p network.\n3. Else POST a Payment message to Invoice.receiptURI and expect a\nSignedReceipt in response.\n\nInvoice.receiptURI must be secure against man-in-the-middle attacks\nthat might alter Payment.refund_to.\n\n*Note: an alternative would be a SignedPayment message that ties the\nsignatures in Payment.transactions to a signature for the entire\nPayment message. Spending multisig inputs that may be controlled by\nmore than one person or spending arbitrary non-standard transactions\nmakes that non-trivial.*\n\nReceipt/SignedReceipt\n---------------------\n\n::\n\n    message Receipt {\n        required Payment payment = 1;\n        required bool accepted = 2;\n        optional string memo = 3;\n    }\n\naccepted : true if the Payment is accepted and will be broadcast on\nthe Bitcoin p2p network.\n\nmemo : UTF-8 encoded note that should be displayed to the customer\nindicating that the transaction is complete.\n\n::\n\n    message SignedReceipt {\n        required Receipt receipt = 1;\n        required bytes signature = 3;\n    }\n\nA SignedReceipt is a Receipt signed using the private key\ncorresponding to the public key in the first certificate in the\nReceipt-\u003ePayment-\u003eInvoice.x509chain and the HMAC SHA-256 algorithm.\n\nUpon receiving a SignedReceipt, a Bitcoin client should validate the\nsignature and, if valid, display the Receipt.memo and store the\nSignedReceipt as proof-of-payment.\n\nIf a SignedReceipt is not received for any reason (timeout, error) and\nPayment.transactions has not been broadcast by the merchant on the\nBitcoin p2p network, then the Bitcoin client should assume that the\npayment failed, inform the customer that the payment failed, and\nreturn coins involved in the transaction to the customer's wallet.\n\n\nCertificates\n============\n\nThe Invoice.x509chain (X.509 Certificate Chain) field contains the\nX.509 public key certificate or certificate chain [RFC5280]\ncorresponding to the key used to digitally sign the Invoice and\nReceipt. The certificate or certificate chain is represented as an\narray of DER [ITU.X690.1994] PKIX certificate value. The certificate\ncontaining the public key of the entity that digitally signed the\nInvoice MUST be the first certificate. This MAY be followed by\nadditional certificates, with each subsequent certificate being the\none used to certify the previous one. The recipient MUST verify the\ncertificate chain according to [RFC5280] and reject the payment\nrequest if any validation failure occurs.\n\n*What should we say about root certificates and certificate management\nin general? Any requirements, or leave it up to each Bitcoin client to\ndetermine which root CA's are trustworthy, as happens with web\nbrowsers? Gavin suggests trusting only (say) ten of the Extended\nValidation authorities:\nhttp://en.wikipedia.org/wiki/Extended_Validation_Certificate#Extended_Validation_certificate_identification\n*\n\n*X.509 is widely criticised for doing too much. However, it is the\nPublic Key Infrastructure (PKI) system we're stuck with. Do web\nbrowsers / certificate authorities support the full X.509 spec, or\nonly a subset? Should Bitcoin clients only support some well-defined\nsubset of X.509 ? More research needed here... *\n\nUse Cases\n=========\n\nMerchant Payment Service\n------------------------\n\nA merchant payment service (like Paysius or bit-pay.com) would use\nInvoices and Receipts as follows:\n\n1. Merchant pays for a certificate from a certificate authority, and\nthen gives the payment service the certificate and their private key.\nThis could be the same certificate and private key as is used for the\nmerchant's web site, but best security practice would be to purchase a\nseparate certificate for authenticating Invoices. Very successful\nmerchant payment services might act as intermediate certificate\nauthorities, issuing certificates for their merchants.\n2. Customer goes through the checkout process on either the merchant's\nor payment service's web site.\n3. At the end of the checkout process, a SignedInvoice is generated\nand sent to the customer's Bitcoin client.\n4. Customer's Bitcoin client displays the Invoice, showing that the\npayment is for the merchant.\n5. On customer approval, a Payment is sent to the payment service's\npaymentURI. The merchant is notified of the payment, and the customer\nreceives a SignedReceipt as proof-of-payment.\n\nSatoshiDice\n-----------\n\nSatoshiDice (www.satoshidice.com) is an extremely popular game that\nuses tiny transactions for some customer/service communications. In\nparticular, customers can add an extra output to their transactions to\nindicate where winnings should be sent. And SatoshiDice creates tiny\ntransactions to let their customers know that a bet was received, but\nlost.\n\nAssuming Bitcoin clients upgrade to support this proposal, a bet on\nSatoshiDice would proceed as follows:\n\n1. Customer clicks on a link on SatoshiDice.com and their Bitcoin\nclient receives a SignedInvoice.\n2. Customer authorizes payment, and their Bitcoin client creates a\nPayment message and submits it directly to\nhttps://satoshidice.com/something\n3. The SatoshiDice web server checks to make sure the transaction is\nvalid, broadcasts it, and determines whether the customer wins or\nloses. It returns a SignedReceipt with either a \"You win\" or \"You\nlost\" memo.\n4. If the customer won, it broadcasts a transaction to pay them using\nPayment.refund_to\n5. Customer's Bitcoin client displays the win/lose memo, and if they\nwon the winnings appear in their wallet when received over the p2p\nnetwork.\n\nMultiperson Wallet\n------------------\n\nThis use case starts with a multi-signature Bitcoin address or wallet,\nwith keys held by two different people (Alice and Bob). Payments from\nthat address/wallet must be authorized by both Alice and Bob, and both\nare running multi-signature-capable Bitcoin clients.\n\nAlice begins the payment process by getting a SignedInvoice from a\nmerchant that needs to be paid. She authorizes payment and her Bitcoin\nclient creates a Payment message with a partially-signed transaction,\nwhich is then sent to Bob any way that is convenient (email\nattachment, smoke signals...).\n\nBob's Bitcoin client validates the SignedInvoice and asks Bob to\nauthorize the transaction. He says OK, his Bitcoin client completes\nthe transaction by providing his signature, submits the payment to the\nmerchant, and then sends a message to Alice with the SignedReceipt he\nreceived from the merchant, completing the payment process.\n\n\nDesign Notes\n============\n\nWhy X.509 Certificates?\n-----------------------\n\nThis proposal uses X.509 certificates as the identity system for\nmerchants because most of them will have already purchased a\ncertificate to secure their website and will be familiar with the\nprocess of proving their identity to a certificate issuing authority.\n\nImplementing a better global PKI is outside the scope of this\nproposal. If a better PKI is adopted, the only change to this proposal\nwould be to replace the Invoice.x509chain with whatever that better\ninfrastructure uses to identify entities.\n\n\nWhy not JSON?\n-------------\n\nInvoice, Payment and Receipt messages could all be JSON-encoded. And\nthe Javascript Object Signing and Encryption (JOSE) working group at\nthe IETF has a draft specification for signing JSON data.\n\nBut the spec is non-trivial. Signing JSON data is troublesome because\nJSON can encode the same data in multiple ways (whitespace is\ninsignificant, characters in strings can be represented escaped or\nun-escaped, etc.), and the standards committee identified at least one\nsecurity-related issue that will require special JSON parsers for\nhandling JSON-Web-Signed (JWS) data (duplicate keys must be rejected\nby the parser, which is more strict than the JSON spec requires).\n\nA binary message format has none of those complicating issues. Which\nencoding format to pick is largely a matter of taste, but Protocol\nBuffers is a simple, robust, multi-programming-language,\nwell-documented, easy-to-work-with, extensible format.\n\nWhat about a merchant-pays-fee feature?\n---------------------------------------\n\nIt is desireable to allow a merchant to pay the cost of any Bitcoin\nnetwork transaction processing fees, so if a customer is paying for a\n1 BTC item they pay exactly 1 BTC.\n\nOne way of accomplishing that is to add a 'maxfee' field to the\nInvoice, and have the Bitcoin client construct a transaction that pays\nthe merchant (amount-maxfee).\n\nAnother way of accomplishing that is to change the transaction\nselection code used by Bitcoin miners, so that dependent transactions\nare considered as a group. Then a merchant with several unconfirmed\nzero-fee transaction from customers can create a pay-to-self\ntransaction with a large enough fee to pay for the set of transactions\nto be confirmed.\n\nA third way of accomplishing that is for the Bitcoin client to sign\nPayment.transactions[0] using the SIGHASH_ANYONECANPAY flag, and for\nthe merchant to add an additional, small-BTC-value input to the\ntransaction before broadcasting it. That additional input would go\ndirectly to miners as a fee. *Note: Gavin is not sure if he loves or\nhates this idea.*\n\nChecking for revoked certificates\n---------------------------------\n\nThe Online Certificate Checking Protocol (OCSP) is supposed to be a\nquick and easy way for applications to check for revoked certificates.\n\nIn practice, it doesn't work very well. Certificate Authorities have\nno financial incentive to support a robust infrastructure that can\nhandle millions of OCSP validation requests quickly.\n\nIdeally, Bitcoin clients would use OCSP to check certificate statuses\nevery time they received or re-used an Invoice. But if that results in\nlong pauses or lots of false-positive rejections (because an OCSP\nendpoint is offline or overwhelmed, perhaps) then merchants and\ncustomers might revert to just using \"never fails\" Bitcoin addresses.\n\n\n\nReferences\n==========\n\nPublic-Key Infrastructure (X.509) working group :\nhttp://datatracker.ietf.org/wg/pkix/charter/\n\nRFC 2560, X.509 Internet Public Key Infrastructure Online Certificate\nStatus Protocol - OCSP : http://tools.ietf.org/html/rfc2560\n\nProtocol Buffers : https://developers.google.com/protocol-buffers/\n\nSee Also\n========\n\nJavascript Object Signing and Encryption working group :\nhttp://datatracker.ietf.org/wg/jose/\n\nsipa's payment protocol proposal: https://gist.github.com/1237788\n\nThomasV's \"Signed Aliases\" proposal : http://ecdsa.org/bitcoin_URIs.html"}