[bitcoin-dev] Address expiration times should be added to BIP-173

[Sjors Provoost]

Op 28 sep. 2017, om 18:06 heeft Andreas Schildbach via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> het volgende geschreven:
> 
> 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.

Bech32 is just a replacement for Base58. It's not strictly SegWit related. If I understand correctly the only reason it won't be used for legacy addresses is to prevent confusion:

https://www.youtube.com/watch?v=NqiN9VFE4CU
https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki

Regarding size I'm mostly curious how big it is on a screen or a physical paper, as text, not as a QR code. This would involve deserializing the protobuf and rendering the result in bech32.

I does sound like there's overlap between BIP-70 and BIP-173 that should be resolved.

Perhaps any payment request can be rendered as bech32 and any bech32 address can converted to a payment request. Maybe only for a limited set of fields (address, expiration, amount). This would be a matter of agreeing how the protobuf should be serialized and deserialized. In that case the protobuf would not contain the literal bech32 address as a string, but instead it would contain the underlying data (public key / script hash, network, etc).

Sjors
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170928/c1597496/attachment-0001.sig>