📅 Original date posted:2017-09-28
📝 Original message:On 09/28/2017 04:41 PM, Sjors Provoost via bitcoin-dev wrote:
>> The payment request message is just as one-way as an address is. It is
>> already being emailed and printed on an invoice, in fact it often acts
>> as the invoice.
>
> True and the more complicated fields, like a digital signature, are optional. Are you suggesting BIP-70 payment requests should be rendered with bech32? How long would those be if it's just the address and expiration date?
I've not yet progressed that far in segwit support, but I can't think of
a reason why not. You can request coins to any script using the payment
protocol.
Regarding size, I've had no problems putting (unsigned) payment request
messages into QR codes. I doubt paying to a native segwit address will
change much in size. Protobuf is very efficient.
>> Even more problematic, if you were to include an expiry date in a
>> BIP-173 address and put that into a payment request, wallets wouldn't be
>> allowed to parse that expiry date from the script without violating the
>> BIP70 spec.
>
> Do tools that generate BIP-70 payment requests generate addresses themselves or are those input manually by a user? In the former case, I assume it could avoid setting the optional expiration date?
The BIP70 spec doesn't limit you on this, I guess either does exist.
Having two (or more!) optional expiration date adds unnecessary
complexity to the specs and implementations. E.g. what if the two do not
match up?
> Is it not allowed to scan the date even if it then sets the expires field to the same (redundant) value?
What do you mean by "scan the date"?
Andreas Schildbach [ARCHIVE] /
npub1xg…adsv7
2023-06-07 18:06:25
in reply to nevent1q…uc02
Author Public Key
npub1xg2m84malu0cfm4444r0kysx4rgk27e75aj6sz6538kw8fcz627qeadsv7Published at
2023-06-07 18:06:25Event JSON
{
"id": "11c76c71cb1061dcb32186930759648f4767fcd61adb9d04dc23106eaab05989",
"pubkey": "3215b3d77dff1f84eeb5ad46fb1206a8d1657b3ea765a80b5489ece3a702d2bc",
"created_at": 1686161185,
"kind": 1,
"tags": [
[
"e",
"02d8c76b933e43bf4fbef62deb34ae55389c59e653682f6f8847f8910b9dcb32",
"",
"root"
],
[
"e",
"9a177edf13658f697d9a814f9d8bde4394a98b410aedc2f849e1abf6476e2095",
"",
"reply"
],
[
"p",
"e1ad0d0d83103f222425541294008149d215c1e1629b0bb37b98e19f698feb3e"
]
],
"content": "📅 Original date posted:2017-09-28\n📝 Original message:On 09/28/2017 04:41 PM, Sjors Provoost via bitcoin-dev wrote:\n\n\u003e\u003e The payment request message is just as one-way as an address is. It is\n\u003e\u003e already being emailed and printed on an invoice, in fact it often acts\n\u003e\u003e as the invoice.\n\u003e \n\u003e True and the more complicated fields, like a digital signature, are optional. Are you suggesting BIP-70 payment requests should be rendered with bech32? How long would those be if it's just the address and expiration date?\n\nI've not yet progressed that far in segwit support, but I can't think of\na reason why not. You can request coins to any script using the payment\nprotocol.\n\nRegarding size, I've had no problems putting (unsigned) payment request\nmessages into QR codes. I doubt paying to a native segwit address will\nchange much in size. Protobuf is very efficient.\n\n\n\u003e\u003e Even more problematic, if you were to include an expiry date in a\n\u003e\u003e BIP-173 address and put that into a payment request, wallets wouldn't be\n\u003e\u003e allowed to parse that expiry date from the script without violating the\n\u003e\u003e BIP70 spec.\n\u003e \n\u003e Do tools that generate BIP-70 payment requests generate addresses themselves or are those input manually by a user? In the former case, I assume it could avoid setting the optional expiration date?\n\nThe BIP70 spec doesn't limit you on this, I guess either does exist.\nHaving two (or more!) optional expiration date adds unnecessary\ncomplexity to the specs and implementations. E.g. what if the two do not\nmatch up?\n\n\u003e Is it not allowed to scan the date even if it then sets the expires field to the same (redundant) value?\n\nWhat do you mean by \"scan the date\"?",
"sig": "fcdd428510c1d066777c2d84a6af955891941f24c112a1abdc47e1b2b5ac8fafbbd14a3ffb1cd2f0e7944f23694fb0b7533e85bd1be6c3e3bd11ae1e1cc6b17c"
}