From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 354A5B1F for ; Thu, 28 Sep 2017 15:07:16 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from blaine.gmane.org (unknown [195.159.176.226]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 027B847E for ; Thu, 28 Sep 2017 15:07:14 +0000 (UTC) Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1dxaOx-00010J-OC for bitcoin-dev@lists.linuxfoundation.org; Thu, 28 Sep 2017 17:06:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bitcoin-dev@lists.linuxfoundation.org From: Andreas Schildbach Date: Thu, 28 Sep 2017 17:06:56 +0200 Message-ID: References: <20170927160654.GA12492@savin.petertodd.org> <14496C9C-E291-4415-B07E-859853579D20@sprovoost.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@blaine.gmane.org 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 X-Spam-Status: No, score=2.4 required=5.0 tests=DKIM_ADSP_ALL,RDNS_NONE autolearn=disabled version=3.3.1 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Address expiration times should be added to BIP-173 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 15:07:16 -0000 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"?