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

[Peter Todd <pete@petertodd.org>]

[-- Attachment #1: Type: text/plain, Size: 2872 bytes --]

On Thu, Sep 28, 2017 at 12:58:30AM +0000, Gregory Maxwell wrote:
> On Wed, Sep 27, 2017 at 4:06 PM, Peter Todd via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> 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; there
> 
> When Pieter and I were working on Bech32 we specifically designed for
> error correcting codes that had good performance for longer lengths
> than we technically needed specifically to incorporate things like
> dates and explicit amounts.
> 
> (explicit amounts so that typos and bit flips in amounts displayed or
> in memory couldn't result in sending the wrong amount)
> 
> But we also thought that also adding those features at the same time
> would retard adoption-- both due to debating over the encodings and
> because handling would result in different software requirements and
> layering, so you couldn't just drop them in.

Notably, even something as simple as adding a new type of confirmation window
that might be needed is a big chance to UI logic.

> Doubly unfortunately, people have even deployed BIP173 already (prior
> to it even having much peer review or being adopted by its own
> authors), so I think a rethink now wouldn't be timely (I mean as a
> replacement to BIP173 rather than an additional format). :(

Yeah, I just noticed Pieter Wuille's BIP173-including segwit pull-req - that's
a lot of code that would get touched by this proposal, so it's likely too late
in the process.

> But I do support the idea.
> 
> 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.

What do you mean by "an embedded amount"?

> 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.

I'm inclined to agree as well. Also, Bitcoin payments themselves are inherently
imprecise, because blocks aren't found on a regular interval - Coinbase's "10
minute" payment expiry window is odd from that point of view.

Having said that, you'd want a resolution more precise than what you'd expect
timeouts to be set at, to avoid UI "fencepost" oddity; if I want to set a 1 day
timeout, users shouldn't see either 1 or 2 days depending on exactly which way
it happened to be rounded that particular time..

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]