From: Sjors Provoost <sjors@sprovoost•nl>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Address expiration times should be added to BIP-173
Date: Thu, 28 Sep 2017 15:43:05 +0300 [thread overview]
Message-ID: <B5DE4E92-C5B3-4C01-A148-E3C46C897323@sprovoost.nl> (raw)
In-Reply-To: <oqihpf$5gc$1@blaine.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4118 bytes --]
Peter Todd wrote:
>
> Re-use of old addresses is a major problem, not only for privacy, but also
> operationally: services like exchanges frequently have problems with users
> sending funds to addresses whose private keys have been lost or stolen;
[...]
>
> To help combat this problem, I suggest that we add a UI-level expiration time
> to the new BIP173 address format. Wallets would be expected to consider
> addresses as invalid as a destination for funds after the expiration time is
> reached.
[...]
Perhaps outside the scope of BIP173, but what about baking it into the protocol? That way a transaction that's sent too late, simply won't get confirmed. This removes the need for refund logic or asking a customer to pay just a few extra cents. You could also disallow a second payment.
Two downsides I can think of:
* privacy, as differences in expiration policy would be visible on chain
* miners might be able to game it in their interaction with brokers
> Being just an expiration time, seconds-level resolution is unnecessary, and
> may give the wrong impression. I'd suggest either:
>
> 1) Hour resolution - 2^24 hours = 1914 years
> 2) Month resolution - 2^16 months = 5458 years
So that's 4.8 characters for hours, or 3.2 for years, plus checksum space? The shorter the better. Perhaps one or two bits can be used to specify an exponent; a large range seems more useful than high precision. For instance a merchant doesn't care if the customer pays within 10:00:00 minutes or 10:00:01 minutes and you wouldn't care if your address is valid 50 years or 50 years and 3 minutes. This point may be mute if minute level resolution is not practical.
> Both options have the advantage of working well at the UI level regardless of
> timezone: the former is sufficiently short that UI's can simply display an
> "exact" time (though note different leap second interpretations), while the
> latter is long enough that rounding off to the nearest day in the local
> timezone is fine.
>
> Supporting hour-level (or just seconds) precision has the advantage of making
> it easy for services like exchanges to use addresses with relatively short
> validity periods, to reduce the risks of losses after a hack. Also, using at
> least hour-level ensures we don't have any year 2038 problems.
Greg Maxwell wrote:
> One thing to keep in mind is that address format linked fields are
> most efficient if they're multiples of 5 bits. Perhaps use 1 bit to
> indicate an embedded amount and 19 bits of 1 day precision, resulting
> in a 1435 year span.
Is this because 5 bits are one bech32 character (2^5=32) or there is another reason? And does that include the space needed for the checksum?
Hopefully one day addresses can be abstracted away, because they really aren't what people intuitively think they are, but I don't see that happen on short notice. Until then they shouldn't exhibit "surprising" behavior.
Embedding amounts in an address could confuse people when they reuse it. Wallets would e.g. have to ignore the amount value if they previously sent money, but without changing the address string displayed in the UI.
> Keep in mind that high precision of the expiration times is asking the
> sender to have a higher precision of idea of the time, date only is
> kinda nice. I think shorter expiration times are unlikely to be
> useful due to clock skew-- you can't assume a signer has any access to
> the Bitcoin network at all.
Many merchant services and exchanges use 10-15 minute expiration though. At the wallet level, all sender and recipient need to agree on is their relative time. Fallback behavior for a signer with no access to time could be to ignore the deadline.
Andreas Schildbach wrote:
>
> This feels redundant to me; the payment protocol already has an
> expiration time.
The BIP-70 payment protocol has significant overhead and most importantly requires back and forth. Emailing a bitcoin address or printing it on an invoice is much easier, so I would expect people to keep doing that.
Sjors
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2017-09-28 12:43 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 [this message]
2017-09-28 14:13 ` Andreas Schildbach
2017-09-28 14:41 ` Sjors Provoost
2017-09-28 15:06 ` Andreas Schildbach
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=B5DE4E92-C5B3-4C01-A148-E3C46C897323@sprovoost.nl \
--to=sjors@sprovoost$(echo .)nl \
--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