Andreas Schildbach [ARCHIVE] on Nostr: 📅 Original date posted:2017-09-28 📝 Original message:On 09/28/2017 04:41 PM, ...
📅 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"?
📝 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"?