From: Andreas Schildbach <andreas@schildbach•de>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Address expiration times should be added to BIP-173
Date: Thu, 28 Sep 2017 17:06:56 +0200 [thread overview]
Message-ID: <oqj369$18u$1@blaine.gmane.org> (raw)
In-Reply-To: <14496C9C-E291-4415-B07E-859853579D20@sprovoost.nl>
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"?
next prev parent reply other threads:[~2017-09-28 15:07 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-27 16:06 Peter Todd
2017-09-27 18:15 ` CryptAxe
2017-09-27 19:03 ` Mark Friedenbach
2017-09-27 21:20 ` Peter Todd
2017-09-27 19:35 ` Chris Priest
2017-09-27 20:11 ` CryptAxe
2017-09-27 20:23 ` Nick Pudar
2017-09-27 20:19 ` CryptAxe
2017-09-27 21:09 ` Mark Friedenbach
2017-09-27 21:15 ` Peter Todd
2017-09-28 0:22 ` Gregory Maxwell
2017-09-27 21:33 ` Peter Todd
2017-09-28 0:58 ` Gregory Maxwell
2017-09-29 1:50 ` Peter Todd
2017-09-29 2:06 ` Gregory Maxwell
2017-09-28 10:09 ` Andreas Schildbach
2017-09-28 12:43 ` Sjors Provoost
2017-09-28 14:13 ` Andreas Schildbach
2017-09-28 14:41 ` Sjors Provoost
2017-09-28 15:06 ` Andreas Schildbach [this message]
2017-09-28 15:45 ` Sjors Provoost
2017-09-28 16:59 ` Luke Dashjr
2017-09-29 2:18 ` Peter Todd
2017-09-29 7:18 ` Sjors Provoost
2017-09-29 2:55 ` [bitcoin-dev] Why the BIP-72 Payment Protocol URI Standard is Insecure Against MITM Attacks Peter Todd
2017-09-29 4:21 ` Omar Shibli
2017-09-29 13:14 ` Tomas
2017-09-29 17:40 ` Aymeric Vitte
2017-09-30 15:33 ` Andreas Schildbach
2017-09-29 1:45 ` [bitcoin-dev] Address expiration times should be added to BIP-173 Peter Todd
2017-09-29 8:44 ` Andreas Schildbach
2017-09-29 9:55 ` Peter Todd
2017-09-29 12:45 ` Andreas Schildbach
2017-09-29 13:52 ` Peter Todd
2017-09-29 17:25 ` Gregory Maxwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='oqj369$18u$1@blaine.gmane.org' \
--to=andreas@schildbach$(echo .)de \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox