📅 Original date posted:2015-07-21
📝 Original message:Le 20/07/2015 16:40, Mike Hearn a écrit :
>
> If we accept a single payment address i.e. no clever tricks around merge
> avoidance, such a QR code could look like this:
>
> bitcoin:1aBcD1234....?x=serialized_payment_request
>
> However this requires text mode and wastes bytes at the front for the URI
> type.
>
It is possible to be both backward-compatible and to avoid wasting space
in URIs, if we simply assume that the payment request is a single
standard output + amount (that scenario will probably cover 99% of the
cases, and the few other cases may not need QR codes). We generate a
serialized bip70 PR from the parameters found in the URI, sign that
string, and add the signature to the URI.
Example:
bitcoin:1H14AiSc4PqkK9VTmeutZU3edSy3HS5HL8?amount=1&message=here%20is%20a%20test&time=1437489571&exp=604800&name=ecdsa.net&sig=3Quot6m2RsR43NgV8VQQx3Ngf5u8wZY18mu523x3ViLrA3WLwSoQum2Znw3gRsTgfADpHuEiyyjnpxCLKWrkR4RQM
'time' is the timestamp of the request
'exp' is the duration of validity, 1 week here
(it saves a few bits to express it that way)
'name' is the domain name of the signer
'sig' is the signature
The QR code derived from that URI is perfectly scannable with a phone.
Thomas Voegtlin [ARCHIVE] /
npub10f…7ej47
2023-06-07 15:42:38
in reply to nevent1q…lmhf
Author Public Key
npub10f96gqrsu4qpygfgvuvzce47aavjvql703egfde0l2hua8dzpszs67ej47Published at
2023-06-07 15:42:38Event JSON
{
"id": "a481e5e69d47484a425753b0177576224c7cec362601c99a1bcb1d79e9b1f63c",
"pubkey": "7a4ba40070e54012212867182c66beef592603fe7c7284b72ffaafce9da20c05",
"created_at": 1686152558,
"kind": 1,
"tags": [
[
"e",
"2e17e6974cd72b01f995017facb76f9fd71444e7e6ca15a73a23fb9732ff9463",
"",
"root"
],
[
"e",
"9f840bfcc2e49cfd630a0fec3105535c7a4473114fd4e85286d5491f1b825db4",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2015-07-21\n📝 Original message:Le 20/07/2015 16:40, Mike Hearn a écrit :\n\u003e \n\u003e If we accept a single payment address i.e. no clever tricks around merge\n\u003e avoidance, such a QR code could look like this:\n\u003e \n\u003e bitcoin:1aBcD1234....?x=serialized_payment_request\n\u003e \n\u003e However this requires text mode and wastes bytes at the front for the URI\n\u003e type.\n\u003e \n\nIt is possible to be both backward-compatible and to avoid wasting space\nin URIs, if we simply assume that the payment request is a single\nstandard output + amount (that scenario will probably cover 99% of the\ncases, and the few other cases may not need QR codes). We generate a\nserialized bip70 PR from the parameters found in the URI, sign that\nstring, and add the signature to the URI.\n\nExample:\n\nbitcoin:1H14AiSc4PqkK9VTmeutZU3edSy3HS5HL8?amount=1\u0026message=here%20is%20a%20test\u0026time=1437489571\u0026exp=604800\u0026name=ecdsa.net\u0026sig=3Quot6m2RsR43NgV8VQQx3Ngf5u8wZY18mu523x3ViLrA3WLwSoQum2Znw3gRsTgfADpHuEiyyjnpxCLKWrkR4RQM\n\n'time' is the timestamp of the request\n'exp' is the duration of validity, 1 week here\n(it saves a few bits to express it that way)\n\n'name' is the domain name of the signer\n'sig' is the signature\n\nThe QR code derived from that URI is perfectly scannable with a phone.",
"sig": "76976ea29ff67e3e15142f3ecfd9b7fc9318260342694dc6318634aeb4ba3dc6a86396a5dd3f6c4a43206815cea6820a12fb179a6ad472373e713132d71b6878"
}