To: bitcoin-dev@lists.linuxfoundation.org
From: Andreas Schildbach <andreas@schildbach.de>
Date: Thu, 28 Sep 2017 17:06:56 +0200
Message-ID: <oqj369$18u$1@blaine.gmane.org>
References: <20170927160654.GA12492@savin.petertodd.org>
	<oqihpf$5gc$1@blaine.gmane.org>
	<B5DE4E92-C5B3-4C01-A148-E3C46C897323@sprovoost.nl>
	<oqj02k$fj9$1@blaine.gmane.org>
	<14496C9C-E291-4415-B07E-859853579D20@sprovoost.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
	Thunderbird/52.3.0
In-Reply-To: <14496C9C-E291-4415-B07E-859853579D20@sprovoost.nl>
Content-Language: en-US
Subject: Re: [bitcoin-dev] Address expiration times should be added to
	BIP-173
Precedence: list

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"?