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"? _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
