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

[Peter Todd via bitcoin-dev]

On Fri, Sep 29, 2017 at 02:45:32PM +0200, Andreas Schildbach via bitcoin-dev 
wrote:
> On 09/29/2017 11:55 AM, Peter Todd via bitcoin-dev wrote:
> 
> >>> I'm well aware. As the payment protocol hasn't caught on - and doesn't 
> >>> fully
> >>> overlap all the usecases that addresses do anyway - I think we should 
> >>> consider
> >>> bringing this important feature to Bitcoin addresses too.
> >>
> >> Hasn't caught on? It is used for virtually all merchant transactions,
> >> plus person to person transactions between Bitcoin Wallet users.
> > 
> > "Virtually all"?
> > 
> > I regularly pay with Bitcoin, and I haven't seen the payment protocol used 
> > in
> > ages.
> 
> I regularly pay with Bitcoin, and I haven't seen the payment protocol
> not being in use in ages.
> 
> > Can you name some users of it?
> 
> 15+ Mio Coinbase users

Lol, interesting mistake I made w/ Coinbase: my mobile wallets are all setup in
ways that don't support the payment protocol w/ Coinbase, probably because come
to think of it they were (still are?) rejecting payment protocol requests over
proxies and Tor. And on my desktop setups payment protocol URLs don't work for
various reasons, and I'd forgotten I'd manually disabled them ages ago.

Just checked and Bitfinex, BTCC, and Shapeshift all don't seem to use the
payment protocol.

Other than BitPay and Coinbase, do you have an example of a service supporting
the payment protocol?

> ~10 Mio BitPay users
> 8 Mio Bitcoin Wallet users
> Plus Bitcoin Core, Electrum, etc (sorry no numbers)
> 
> Probably the only usecase for naked addresses is paper wallets, right?
> I'm not sure if paper wallets can expire.

User-to-user payments pretty much always use naked addresses.

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


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Andreas Schildbach via bitcoin-dev]

On 09/29/2017 11:55 AM, Peter Todd via bitcoin-dev wrote:

>>> I'm well aware. As the payment protocol hasn't caught on - and doesn't fully
>>> overlap all the usecases that addresses do anyway - I think we should 
>>> consider
>>> bringing this important feature to Bitcoin addresses too.
>>
>> Hasn't caught on? It is used for virtually all merchant transactions,
>> plus person to person transactions between Bitcoin Wallet users.
> 
> "Virtually all"?
> 
> I regularly pay with Bitcoin, and I haven't seen the payment protocol used in
> ages.

I regularly pay with Bitcoin, and I haven't seen the payment protocol
not being in use in ages.

> Can you name some users of it?

15+ Mio Coinbase users
~10 Mio BitPay users
8 Mio Bitcoin Wallet users
Plus Bitcoin Core, Electrum, etc (sorry no numbers)

Probably the only usecase for naked addresses is paper wallets, right?
I'm not sure if paper wallets can expire.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Sjors Provoost via bitcoin-dev]

Op 29 sep. 2017, om 05:18 heeft Peter Todd  het volgende 
geschreven:
> 
> On Thu, Sep 28, 2017 at 03:43:05PM +0300, Sjors Provoost via bitcoin-dev 
> wrote:
>> Peter Todd wrote:
>> 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
> 
> This has been discussed many times before; there are *severe* downsides to
> making it possible for transactions to become invalid after the fact.

I've heard of that general principe, but I'm having trouble finding a good 
resource that describes it more precisely.

Is it a peer to peer or mempool issue? E.g a transaction might be accepted into 
the mempool and relayed at one point in time and suddenly become invalid before 
they're committed to a block? Or that a node receives a transaction, thinks 
it's invalid because the address already expired, but then receives an older 
block later which contains that transaction?

Once in a block, I don't see how it would become invalid later. But as a miner 
tries to find a block and updates the timestamp, they would have toss the 
transaction out at some point.

Another objection I can think of, is that the soft fork introducing this change 
would have to use a transaction type that's non-standard at the moment. This 
would make it difficult for a non-upgraded node to broadcast such a 
transaction. The recipient would have to know if the sender has upgraded before 
communicating an address, which sounds impractical at best.

>>> 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.
> 
> Note that "large range" is a requirement driven by the fact that expiry times
> will inevitably be specified absolutely, not relatively: when the range runs
> out you need to upgrade the standard. Better to use another character and use 
> a
> range that won't run out any time soon.
> 
> This wouldn't create a need for more checksum space.

You're right, relative time makes no sense. So it would take 5 characters to 
get roughly two minute resolution that lasts for 100 years.

Sjors



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Andreas Schildbach via bitcoin-dev]

On 09/29/2017 03:45 AM, Peter Todd via bitcoin-dev wrote:
> On Thu, Sep 28, 2017 at 12:09:59PM +0200, Andreas Schildbach via bitcoin-dev 
> wrote:
>> This feels redundant to me; the payment protocol already has an
>> expiration time.
> 
> I'm well aware. As the payment protocol hasn't caught on - and doesn't fully
> overlap all the usecases that addresses do anyway - I think we should consider
> bringing this important feature to Bitcoin addresses too.

Hasn't caught on? It is used for virtually all merchant transactions,
plus person to person transactions between Bitcoin Wallet users.


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Peter Todd via bitcoin-dev]

On Thu, Sep 28, 2017 at 03:43:05PM +0300, Sjors Provoost via bitcoin-dev wrote:
> Peter Todd wrote:
> 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

This has been discussed many times before; there are *severe* downsides to
making it possible for transactions to become invalid after the fact.

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

Note that "large range" is a requirement driven by the fact that expiry times
will inevitably be specified absolutely, not relatively: when the range runs
out you need to upgrade the standard. Better to use another character and use a
range that won't run out any time soon.

This wouldn't create a need for more checksum space.

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


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Gregory Maxwell via bitcoin-dev]

On Fri, Sep 29, 2017 at 1:50 AM, Peter Todd  wrote:
> What do you mean by "an embedded amount"?

I ask you to pay 1 Bitcoin to bc1blahblah.

...you make a typo, or a poorly placed cosmic ray switches it in your
ram to bc1blohblahbah.   No problem, it'll get rejected. (even if the
cosmic ray happens just before signing... if the software is robust
it'll reencode from the signed transaction and check against the
original input.

But if instead the typo converts it to 2 Bitcoins or the cosmic ray
converts it to 2.34217728... the payment will happily go through,
assuming your wallet had enough, and you're stuck asking me to refund
you the excess.

Sure, you can put amounts in URIs and whatnot, but they're not error
protected... so there will always be unprotected poritons where a
glitch can radically change the amount.

In many cases you know exactly what amount you're asking for when you
generate an address. There isn't any reason the amount couldn't be
covered by the addresses checksum in those cases.

There are a couple ways of doing that... e.g. adding it explicitly,
where the checksum includes it but not the address itself; so it
errors out if you get it wrong. But this is unfortunate because it
can't tell you the expected amount when its wrong.   Another way would
be to embed the amount in the address, and then the software can tell
you the amount the address was expecting and not let you proceed until
they match.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Peter Todd via bitcoin-dev]

On Thu, Sep 28, 2017 at 12:58:30AM +, Gregory Maxwell wrote:
> On Wed, Sep 27, 2017 at 4:06 PM, Peter Todd via bitcoin-dev
>  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


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Peter Todd via bitcoin-dev]

On Thu, Sep 28, 2017 at 12:09:59PM +0200, Andreas Schildbach via bitcoin-dev 
wrote:
> This feels redundant to me; the payment protocol already has an
> expiration time.

I'm well aware. As the payment protocol hasn't caught on - and doesn't fully
overlap all the usecases that addresses do anyway - I think we should consider
bringing this important feature to Bitcoin addresses too.

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


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Luke Dashjr via bitcoin-dev]

On Thursday 28 September 2017 2:13:48 PM Andreas Schildbach via bitcoin-dev 
wrote:
> On 09/28/2017 02:43 PM, Sjors Provoost via bitcoin-dev 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.
> 
> 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.
> 
> 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.

Payment requests don't use and don't overlap with addresses. Maybe you could 
have an argument for serialising BIP70 payment requests in Bech32 as the new 
address format itself, but it doesn't make sense to talk about putting a 
Bech32 address *into* a payment request...

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Sjors Provoost via bitcoin-dev]

Op 28 sep. 2017, om 18:06 heeft Andreas Schildbach via bitcoin-dev 
 het volgende geschreven:
> 
> 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.

Bech32 is just a replacement for Base58. It's not strictly SegWit related. If I 
understand correctly the only reason it won't be used for legacy addresses is 
to prevent confusion:

https://www.youtube.com/watch?v=NqiN9VFE4CU
https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki

Regarding size I'm mostly curious how big it is on a screen or a physical 
paper, as text, not as a QR code. This would involve deserializing the protobuf 
and rendering the result in bech32.

I does sound like there's overlap between BIP-70 and BIP-173 that should be 
resolved.

Perhaps any payment request can be rendered as bech32 and any bech32 address 
can converted to a payment request. Maybe only for a limited set of fields 
(address, expiration, amount). This would be a matter of agreeing how the 
protobuf should be serialized and deserialized. In that case the protobuf would 
not contain the literal bech32 address as a string, but instead it would 
contain the underlying data (public key / script hash, network, etc).

Sjors


signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Andreas Schildbach via bitcoin-dev]

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"?

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Sjors Provoost via bitcoin-dev]

Op 28 sep. 2017, om 17:13 heeft Andreas Schildbach via bitcoin-dev 
 het volgende geschreven:
> 
> On 09/28/2017 02:43 PM, Sjors Provoost via bitcoin-dev 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.
> 
> 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?

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

Is it not allowed to scan the date even if it then sets the expires field to 
the same (redundant) value?

Sjors


signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Andreas Schildbach via bitcoin-dev]

On 09/28/2017 02:43 PM, Sjors Provoost via bitcoin-dev 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.

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.

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.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Sjors Provoost via bitcoin-dev]

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



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Mark Friedenbach via bitcoin-dev]

First, there’s been no discussion so far for address expiration to be part of 
“the protocol” which usually means consensus rules or p2p. This is purely about 
wallets and wallet information exchange protocols.

There’s no way for the sender to know whether an address has been used without 
a complete copy of the block chain and more indexes than even Bitcoin Core 
maintains. It’s simply not an option now, let alone as the blockchain grows 
into the future.

> On Sep 27, 2017, at 1:23 PM, Nick Pudar via bitcoin-dev 
>  wrote:
> 
> As a long term silent reader of this list, I felt compelled to comment on 
> this address expiration topic.  I don't believe that address expiration 
> should be part of the protocol.  I think instead that the "sending" feature 
> should by default offer guidance to request a fresh address from the 
> recipient.  Also allow the receiver of funds to be able to generate an 
> "invoice" that the sender acts on.
> 
> I also think that re-directs are fraught with privacy issues.  At the end of 
> the day, the ultimate burden is on the sender (with much self interest from 
> the receiver) that the correct address is being used.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[CryptAxe via bitcoin-dev]

I do agree with you to a degree, but address reuse is actually not even
supposed to work (it is a bug). Peter Todd is suggesting only to make
expiration a part of a new address format, and we could have a GUI
warning (but no protocol change) for the existing formats. What do you
think about that?


On 09/27/2017 01:23 PM, Nick Pudar via bitcoin-dev wrote:
>
> As a long term silent reader of this list, I felt compelled to comment
> on this address expiration topic.  I don't believe that address
> expiration should be part of the protocol.  I think instead that the
> "sending" feature should by default offer guidance to request a fresh
> address from the recipient.  Also allow the receiver of funds to be
> able to generate an "invoice" that the sender acts on.
>
>
> I also think that re-directs are fraught with privacy issues.  At the
> end of the day, the ultimate burden is on the sender (with much self
> interest from the receiver) that the correct address is being used.
>
>
>
> 
> *From:* bitcoin-dev-boun...@lists.linuxfoundation.org
> <bitcoin-dev-boun...@lists.linuxfoundation.org> on behalf of Chris
> Priest via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
> *Sent:* Wednesday, September 27, 2017 3:35 PM
> *To:* Peter Todd; Bitcoin Protocol Discussion
> *Subject:* Re: [bitcoin-dev] Address expiration times should be added
> to BIP-173
>  
> A better solution is to just have the sending wallet check to see if
> the address you are about to send to has been used before. If it's a
> fresh address, it sends it through without any popup alert. If the
> address has history going back a certain amount of time, then a popup
> comes up and notifies the sender that they are sending to a non-fresh
> address that may no longer be controlled by the receiver anymore.
>
> Also, an even better idea is to set up an "address expiration
> service". When you delete a wallet, you first send off an "expiration
> notice" which is just a message (signed with the private key) saying
> "I am about to delete this address, here is my new address". When
> someone tries to send to that address, they first consult the address
> expiration service, and the service will either tell them "this
> address is not expired, proceed", or "this address has been expired,
> please send to this other address instead...". Basically like a 301
> redirect, but for addresses. I don't think address expiration should
> be part of the protocol.
>
> On Wed, Sep 27, 2017 at 10:06 AM, Peter Todd via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto: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
> are multiple examples of exchanges getting hacked, with users
> continuing to
> lose funds well after the actual hack has occured due to
> continuing deposits.
> This also makes it difficult operationally to rotate private keys.
> I personally
> have even lost funds in the past due to people sending me BTC to
> addresses that
> I gave them long ago for different reasons, rather than asking me
> for fresh
> one.
>
> 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.
>
> Unfortunately, this proposal inevitably will raise a lot of UI and
> terminology
> questions. Notably, the entire notion of addresses is flawed from
> a user point
> of view: their experience with them should be more like "payment
> codes", with a
> code being valid for payment for a short period of time; wallets
> should not be
> displaying addresses as actually associated with specific funds. I
> suspect
> we'll see users thinking that an expired address risks the funds
> themselves;
> some thought needs to be put into terminology.
>
> 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
>
> Both options have the advantage of working well at the UI leve

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

[Andreas Schildbach via bitcoin-dev]

This feels redundant to me; the payment protocol already has an
expiration time.


On 09/27/2017 06:06 PM, Peter Todd via bitcoin-dev 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
> are multiple examples of exchanges getting hacked, with users continuing to
> lose funds well after the actual hack has occured due to continuing deposits.
> This also makes it difficult operationally to rotate private keys. I 
> personally
> have even lost funds in the past due to people sending me BTC to addresses 
> that
> I gave them long ago for different reasons, rather than asking me for fresh
> one.
> 
> 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.
> 
> Unfortunately, this proposal inevitably will raise a lot of UI and terminology
> questions. Notably, the entire notion of addresses is flawed from a user point
> of view: their experience with them should be more like "payment codes", with 
> a
> code being valid for payment for a short period of time; wallets should not be
> displaying addresses as actually associated with specific funds. I suspect
> we'll see users thinking that an expired address risks the funds themselves;
> some thought needs to be put into terminology.
> 
> 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
> 
> 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.
> 
> Thoughts?
> 
> 
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Gregory Maxwell via bitcoin-dev]

On Wed, Sep 27, 2017 at 7:35 PM, Chris Priest via bitcoin-dev
 wrote:
> A better solution is to just have the sending wallet check to see if the
> address you are about to send to has been used before.

So every wallet needs all the addresses ever used and a fast index into them?
This seems pretty harmful for scalability.

> they first consult the address expiration service,

So you propose a best practice that requires contacting a service and
telling them what addresses you're planning on paying?  This seems
pretty harmful for privacy.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Peter Todd via bitcoin-dev]

On Wed, Sep 27, 2017 at 12:06:54PM -0400, Peter Todd via bitcoin-dev wrote:
> 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

Just remembered: it's notable how Coinbase has a 10 minute timeout on their
payment window, which is in effect a 10 minute expiry time for the address.
Presumably they'd make use of this feature if it existed.

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


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Peter Todd via bitcoin-dev]

On Wed, Sep 27, 2017 at 12:03:44PM -0700, Mark Friedenbach wrote:
> While there is a lot that I would like to comment on, for the moment I will 
> just mention that you should consider using the 17 bit relative time format 
> used in CSV as an offset from the birthdate of the address, a field all 
> addresses should also have.

Why should addresses have a birthdate? I don't see why that information would
be relevant to the person sending funds, and it could pose a privacy risk.

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


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Peter Todd via bitcoin-dev]

On Wed, Sep 27, 2017 at 01:35:33PM -0600, Chris Priest wrote:
> A better solution is to just have the sending wallet check to see if the
> address you are about to send to has been used before. If it's a fresh

My concern is not primarily people re-using addresses, but rather people using
stale addresses that the recipient would rather not be used anymore. This
situation often happens even if the stale address has never been used.

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


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Nick Pudar via bitcoin-dev]

As a long term silent reader of this list, I felt compelled to comment on this 
address expiration topic.  I don't believe that address expiration should be 
part of the protocol.  I think instead that the "sending" feature should by 
default offer guidance to request a fresh address from the recipient.  Also 
allow the receiver of funds to be able to generate an "invoice" that the sender 
acts on.


I also think that re-directs are fraught with privacy issues.  At the end of 
the day, the ultimate burden is on the sender (with much self interest from the 
receiver) that the correct address is being used.



From: bitcoin-dev-boun...@lists.linuxfoundation.org 
<bitcoin-dev-boun...@lists.linuxfoundation.org> on behalf of Chris Priest via 
bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Sent: Wednesday, September 27, 2017 3:35 PM
To: Peter Todd; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Address expiration times should be added to BIP-173

A better solution is to just have the sending wallet check to see if the 
address you are about to send to has been used before. If it's a fresh address, 
it sends it through without any popup alert. If the address has history going 
back a certain amount of time, then a popup comes up and notifies the sender 
that they are sending to a non-fresh address that may no longer be controlled 
by the receiver anymore.

Also, an even better idea is to set up an "address expiration service". When 
you delete a wallet, you first send off an "expiration notice" which is just a 
message (signed with the private key) saying "I am about to delete this 
address, here is my new address". When someone tries to send to that address, 
they first consult the address expiration service, and the service will either 
tell them "this address is not expired, proceed", or "this address has been 
expired, please send to this other address instead...". Basically like a 301 
redirect, but for addresses. I don't think address expiration should be part of 
the protocol.

On Wed, Sep 27, 2017 at 10:06 AM, Peter Todd via bitcoin-dev 
<bitcoin-dev@lists.linuxfoundation.org<mailto: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
are multiple examples of exchanges getting hacked, with users continuing to
lose funds well after the actual hack has occured due to continuing deposits.
This also makes it difficult operationally to rotate private keys. I personally
have even lost funds in the past due to people sending me BTC to addresses that
I gave them long ago for different reasons, rather than asking me for fresh
one.

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.

Unfortunately, this proposal inevitably will raise a lot of UI and terminology
questions. Notably, the entire notion of addresses is flawed from a user point
of view: their experience with them should be more like "payment codes", with a
code being valid for payment for a short period of time; wallets should not be
displaying addresses as actually associated with specific funds. I suspect
we'll see users thinking that an expired address risks the funds themselves;
some thought needs to be put into terminology.

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

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.

Thoughts?

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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev




--
Chris Priest
786-531-5938
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[CryptAxe via bitcoin-dev]

See https://github.com/bitcoin/bitcoin/pull/9722

What still needs to be done is that during the first start up after
updating with this popup, the wallet needs to scan for addresses that
have been used in the past. That way the popup isn't only shown for
addresses that are reused after updating.


On 09/27/2017 12:35 PM, Chris Priest via bitcoin-dev wrote:
> A better solution is to just have the sending wallet check to see if
> the address you are about to send to has been used before. If it's a
> fresh address, it sends it through without any popup alert. If the
> address has history going back a certain amount of time, then a popup
> comes up and notifies the sender that they are sending to a non-fresh
> address that may no longer be controlled by the receiver anymore.
>
> Also, an even better idea is to set up an "address expiration
> service". When you delete a wallet, you first send off an "expiration
> notice" which is just a message (signed with the private key) saying
> "I am about to delete this address, here is my new address". When
> someone tries to send to that address, they first consult the address
> expiration service, and the service will either tell them "this
> address is not expired, proceed", or "this address has been expired,
> please send to this other address instead...". Basically like a 301
> redirect, but for addresses. I don't think address expiration should
> be part of the protocol.
>
...
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Chris Priest via bitcoin-dev]

A better solution is to just have the sending wallet check to see if the
address you are about to send to has been used before. If it's a fresh
address, it sends it through without any popup alert. If the address has
history going back a certain amount of time, then a popup comes up and
notifies the sender that they are sending to a non-fresh address that may
no longer be controlled by the receiver anymore.

Also, an even better idea is to set up an "address expiration service".
When you delete a wallet, you first send off an "expiration notice" which
is just a message (signed with the private key) saying "I am about to
delete this address, here is my new address". When someone tries to send to
that address, they first consult the address expiration service, and the
service will either tell them "this address is not expired, proceed", or
"this address has been expired, please send to this other address
instead...". Basically like a 301 redirect, but for addresses. I don't
think address expiration should be part of the protocol.

On Wed, Sep 27, 2017 at 10:06 AM, 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
> are multiple examples of exchanges getting hacked, with users continuing to
> lose funds well after the actual hack has occured due to continuing
> deposits.
> This also makes it difficult operationally to rotate private keys. I
> personally
> have even lost funds in the past due to people sending me BTC to addresses
> that
> I gave them long ago for different reasons, rather than asking me for fresh
> one.
>
> 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.
>
> Unfortunately, this proposal inevitably will raise a lot of UI and
> terminology
> questions. Notably, the entire notion of addresses is flawed from a user
> point
> of view: their experience with them should be more like "payment codes",
> with a
> code being valid for payment for a short period of time; wallets should
> not be
> displaying addresses as actually associated with specific funds. I suspect
> we'll see users thinking that an expired address risks the funds
> themselves;
> some thought needs to be put into terminology.
>
> 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
>
> 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.
>
> Thoughts?
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>


-- 
Chris Priest
786-531-5938
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Mark Friedenbach via bitcoin-dev]

While there is a lot that I would like to comment on, for the moment I will 
just mention that you should consider using the 17 bit relative time format 
used in CSV as an offset from the birthdate of the address, a field all 
addresses should also have.

This would also mean that addresses cannot last more than a year without user 
override, which might actually be a plus, but you could also extend the field 
by a few bits too if that was deemed not acceptable. An address should not be 
considered valid longer than anticipated lifetime of the underlying 
cryptosystem in any case, so every address should have an expiry.

> On Sep 27, 2017, at 9:06 AM, Peter Todd via bitcoin-dev 
>  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
> are multiple examples of exchanges getting hacked, with users continuing to
> lose funds well after the actual hack has occured due to continuing deposits.
> This also makes it difficult operationally to rotate private keys. I 
> personally
> have even lost funds in the past due to people sending me BTC to addresses 
> that
> I gave them long ago for different reasons, rather than asking me for fresh
> one.
> 
> 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.
> 
> Unfortunately, this proposal inevitably will raise a lot of UI and terminology
> questions. Notably, the entire notion of addresses is flawed from a user point
> of view: their experience with them should be more like "payment codes", with 
> a
> code being valid for payment for a short period of time; wallets should not be
> displaying addresses as actually associated with specific funds. I suspect
> we'll see users thinking that an expired address risks the funds themselves;
> some thought needs to be put into terminology.
> 
> 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
> 
> 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.
> 
> Thoughts?
> 
> -- 
> https://petertodd.org 'peter'[:-1]@petertodd.org
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[CryptAxe via bitcoin-dev]

I think we need something like this. Hour resolution seems like the
correct choice to me.

Please someone steal whatever code you can from this PR when
implementing the UI for BIP173 expiration:

https://github.com/bitcoin/bitcoin/pull/9722

I have a rebased version as well if anyone wants it.


On 09/27/2017 09:06 AM, Peter Todd via bitcoin-dev 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
> are multiple examples of exchanges getting hacked, with users continuing to
> lose funds well after the actual hack has occured due to continuing deposits.
> This also makes it difficult operationally to rotate private keys. I 
> personally
> have even lost funds in the past due to people sending me BTC to addresses 
> that
> I gave them long ago for different reasons, rather than asking me for fresh
> one.
>
> 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.
>
> Unfortunately, this proposal inevitably will raise a lot of UI and terminology
> questions. Notably, the entire notion of addresses is flawed from a user point
> of view: their experience with them should be more like "payment codes", with 
> a
> code being valid for payment for a short period of time; wallets should not be
> displaying addresses as actually associated with specific funds. I suspect
> we'll see users thinking that an expired address risks the funds themselves;
> some thought needs to be put into terminology.
>
> 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
>
> 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.
>
> Thoughts?
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Peter Todd via bitcoin-dev]

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
are multiple examples of exchanges getting hacked, with users continuing to
lose funds well after the actual hack has occured due to continuing deposits.
This also makes it difficult operationally to rotate private keys. I personally
have even lost funds in the past due to people sending me BTC to addresses that
I gave them long ago for different reasons, rather than asking me for fresh
one.

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.

Unfortunately, this proposal inevitably will raise a lot of UI and terminology
questions. Notably, the entire notion of addresses is flawed from a user point
of view: their experience with them should be more like "payment codes", with a
code being valid for payment for a short period of time; wallets should not be
displaying addresses as actually associated with specific funds. I suspect
we'll see users thinking that an expired address risks the funds themselves;
some thought needs to be put into terminology.

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

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.

Thoughts?

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


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev