public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd.org>
To: Gregory Maxwell <greg@xiph.org>
Cc: 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 21:50:48 -0400	[thread overview]
Message-ID: <20170929015048.GC11956@savin.petertodd.org> (raw)
In-Reply-To: <CAAS2fgRpMXdqKXeYSOtVBQQ9fmu=nQ9anEO6Wrc_5rms1Y2B2w@mail.gmail.com>

[-- 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 --]

  reply	other threads:[~2017-09-29  1:51 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-27 16:06 [bitcoin-dev] Address expiration times should be added to BIP-173 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 [this message]
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
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=20170929015048.GC11956@savin.petertodd.org \
    --to=pete@petertodd.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=greg@xiph.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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