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

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

[Peter Todd]

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

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

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

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

[CryptAxe]

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

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


[-- Attachment #2: Type: text/html, Size: 3592 bytes --]

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

[Mark Friedenbach]

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

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

[Peter Todd]

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

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

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

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

[Chris Priest]

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

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

[-- Attachment #2: Type: text/html, Size: 4837 bytes --]

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

[CryptAxe]

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

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

[-- Attachment #2: Type: text/html, Size: 2189 bytes --]

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

[Nick Pudar]

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

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-bounces@lists.linuxfoundation.org <bitcoin-dev-bounces@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

[-- Attachment #2: Type: text/html, Size: 6712 bytes --]

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

[CryptAxe]

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

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-bounces@lists.linuxfoundation.org
> <bitcoin-dev-bounces@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
>     <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


[-- Attachment #2: Type: text/html, Size: 10739 bytes --]

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

[Mark Friedenbach]

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

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 <bitcoin-dev@lists.linuxfoundation.org> 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.


[-- Attachment #2: Type: text/html, Size: 2392 bytes --]

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

[Peter Todd]

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

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

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

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

[Gregory Maxwell]

On Wed, Sep 27, 2017 at 7:35 PM, Chris Priest via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> 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.

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

[Peter Todd]

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

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

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

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

[Gregory Maxwell]

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.

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). :(

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.

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.

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

[Peter Todd]

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

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

[Gregory Maxwell]

On Fri, Sep 29, 2017 at 1:50 AM, Peter Todd <pete@petertodd.org> 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.

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

[Andreas Schildbach]

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
> 

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

[Sjors Provoost]

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

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

[Andreas Schildbach]

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.

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

[Sjors Provoost]

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

Op 28 sep. 2017, om 17:13 heeft Andreas Schildbach via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> 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

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Andreas Schildbach]

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

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

[Sjors Provoost]

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

Op 28 sep. 2017, om 18:06 heeft Andreas Schildbach via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> 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

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Luke Dashjr]

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

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

[Peter Todd]

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

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

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

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

[Sjors Provoost]

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

Op 29 sep. 2017, om 05:18 heeft Peter Todd <pete@petertodd.org> 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


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[bitcoin-dev] Why the BIP-72 Payment Protocol URI Standard is Insecure Against MITM Attacks

[Peter Todd]

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

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

The BIP-70 payment protocol used via BIP-72 URI's is insecure, as payment qr
codes don't cryptographically commit to the identity of the merchant, which
means a MITM attacker can redirect the payment if they can obtain a SSL cert
that the wallet accepts.

For example, if I have a wallet on my phone and go to pay a
merchant, a BIP-72 URI will look like the following(1):

    bitcoin:mq7se9wy2egettFxPbmn99cK8v5AFq55Lx?amount=0.11&r=https://merchant.com/pay.php?h%3D2a8628fc2fbe

A wallet following the BIP-72 standard will "ignore the bitcoin
address/amount/label/message in the URI and instead fetch a PaymentRequest
message and then follow the payment protocol, as described in BIP 70."

So my phone will make a second connection - likely on a second network with a
totally different set of MITM attackers - to https://merchant.com

In short, while my browser may have gotten the correct URL with the correct
Bitcoin address, by using the payment protocol my wallet is discarding that
information and giving MITM attackers a second chance at redirecting my payment
to them. That wallet is also likely using an off-the-shelf SSL library, with
nothing other than an infrequently updated set of root certificates to use to
verify the certificate; your browser has access to a whole host of better
technologies, such as HSTS pinning, certificate transparency, and frequently
updated root certificate lists with proper revocation (see Symantec).

As an ad-hoc, unstandardized, extension Android Wallet for Bitcoin at least
supports a h= parameter with a hash commitment to what the payment request
should be, and will reject the MITM attacker if that hash doesn't match. But
that's not actually in the standard itself, and as far as I can tell has never
been made into a BIP.

As-is BIP-72 is very dangerous and should be depreciated, with a new BIP made
to replace it.

1) As an aside, it's absolutely hilarious that this URL taken straight from
   BIP-72 has the merchant using PHP, given its truly terrible track record for
   security.

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

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

Re: [bitcoin-dev] Why the BIP-72 Payment Protocol URI Standard is Insecure Against MITM Attacks

[Omar Shibli]

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

Thank you for sharing, this is indefinitely valuable.

I think that risk could be mitigated if instead of ignoring the bitcoin
address/amount/..., the wallet use this address for integrity checks.
Furthermore, I think this BIP could be improved by actually applying the
homomorphic property and deriving the bitcoin address from merchant pub key
and the hash itself. that would allow both the customer and merchant to be
able generate address independently.

On Fri, Sep 29, 2017 at 5:55 AM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, Sep 28, 2017 at 03:43:05PM +0300, Sjors Provoost via bitcoin-dev
> wrote:
> > 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.
>
> The BIP-70 payment protocol used via BIP-72 URI's is insecure, as payment
> qr
> codes don't cryptographically commit to the identity of the merchant, which
> means a MITM attacker can redirect the payment if they can obtain a SSL
> cert
> that the wallet accepts.
>
> For example, if I have a wallet on my phone and go to pay a
> merchant, a BIP-72 URI will look like the following(1):
>
>     bitcoin:mq7se9wy2egettFxPbmn99cK8v5AFq55Lx?amount=0.11&r=https://
> merchant.com/pay.php?h%3D2a8628fc2fbe
>
> A wallet following the BIP-72 standard will "ignore the bitcoin
> address/amount/label/message in the URI and instead fetch a PaymentRequest
> message and then follow the payment protocol, as described in BIP 70."
>
> So my phone will make a second connection - likely on a second network
> with a
> totally different set of MITM attackers - to https://merchant.com
>
> In short, while my browser may have gotten the correct URL with the correct
> Bitcoin address, by using the payment protocol my wallet is discarding that
> information and giving MITM attackers a second chance at redirecting my
> payment
> to them. That wallet is also likely using an off-the-shelf SSL library,
> with
> nothing other than an infrequently updated set of root certificates to use
> to
> verify the certificate; your browser has access to a whole host of better
> technologies, such as HSTS pinning, certificate transparency, and
> frequently
> updated root certificate lists with proper revocation (see Symantec).
>
> As an ad-hoc, unstandardized, extension Android Wallet for Bitcoin at least
> supports a h= parameter with a hash commitment to what the payment request
> should be, and will reject the MITM attacker if that hash doesn't match.
> But
> that's not actually in the standard itself, and as far as I can tell has
> never
> been made into a BIP.
>
> As-is BIP-72 is very dangerous and should be depreciated, with a new BIP
> made
> to replace it.
>
> 1) As an aside, it's absolutely hilarious that this URL taken straight from
>    BIP-72 has the merchant using PHP, given its truly terrible track
> record for
>    security.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 4510 bytes --]

Re: [bitcoin-dev] Why the BIP-72 Payment Protocol URI Standard is Insecure Against MITM Attacks

[Tomas]

On Fri, Sep 29, 2017, at 04:55, Peter Todd via bitcoin-dev wrote:
> The BIP-70 payment protocol used via BIP-72 URI's is insecure, as payment
> qr
> codes don't cryptographically commit to the identity of the merchant,
> which
> means a MITM attacker can redirect the payment if they can obtain a SSL
> cert
> that the wallet accepts.

By that reasoning, we also shouldn't go to https://coinbase.com or
https://kraken.com to buy any bitcoins? As a MITM can redirect the site
_if_ they obtain the coinbase or kraken certificate.

Obviously, HTTPS is secured under the assumption that certificates are
secure.  

Using the payment protocol simply means paying to a secure endpoint (eg
https://tomasvdw.nl/pay) instead of an address.

>  That wallet is also likely using an off-the-shelf SSL library,
> with
> nothing other than an infrequently updated set of root certificates to
> use to
> verify the certificate; your browser has access to a whole host of better
> technologies, such as HSTS pinning, certificate transparency, and
> frequently
> updated root certificate lists with proper revocation (see Symantec).

So we should not use HTTPS for secure transfer because the
implementation may not be good enough? This incorrectly conflates
implementation with specification. There is nothing stopping a developer
from using a proper implementation.

> 
> As an ad-hoc, unstandardized, extension Android Wallet for Bitcoin at
> least
> supports a h= parameter with a hash commitment to what the payment
> request
> should be, and will reject the MITM attacker if that hash doesn't match.
> But
> that's not actually in the standard itself, and as far as I can tell has
> never
> been made into a BIP.

Currently it is widely used by merchants, but not yet for light clients
_receiving_ money. If it becomes more wide spread,   it offers a range
of advantages as  the bitcoin-address of the URI can and should be
deprecated (made impossible with "h="). A payment address just becomes a
secure endpoint.

This means no more address reuse is possible. Also, it drops the need
for mempool synchronization among non-miners, solely as a "notification"
mechanism. In addition it means light clients know exactly when a
transaction is coming in, so they can efficiently rely on client-side
filtering a small set of blocks, improving their privacy.

In my opinion, the payment protocol is key to scaling.

> As-is BIP-72 is very dangerous and should be depreciated, with a new BIP
> made
> to replace it.

Sorry, but maybe you  could explain better how secure communication over
HTTPS is "very dangerous"? I think some websites would like to know :)

Tomas van der Wansem
bitcrust

Re: [bitcoin-dev] Why the BIP-72 Payment Protocol URI Standard is Insecure Against MITM Attacks

[Aymeric Vitte]

Everybody knows that https is broken and insecure, and everybody knows
that it's still better than nothing

Just reacting here because there is worse: you are quoting Kraken, did
not check for Coinbase but Kraken is proxying all of its https traffic
via Cloudflare, including the API traffic

This is crazy but that's how things are, that's what everybody is doing,
that's what we have

The https principles are obsolete, the concept of certificates tied to a
domain is a complete stupidity, because there are no concept of domains
in bitcoin for example (and webrtc, Tor, bittorrent, p2p systems, etc)
and should evolve to something like certificates tied to an entityID
managed by something like a blockchain system, and not a stupid domain or CA

Therefore specifying things for bitcoin à la web is not a good idea,
browsers can do far better than standard/usual web, and the "like
everybody is doing" argument is not a valid one


Le 29/09/2017 à 15:14, Tomas via bitcoin-dev a écrit :
> On Fri, Sep 29, 2017, at 04:55, Peter Todd via bitcoin-dev wrote:
>> The BIP-70 payment protocol used via BIP-72 URI's is insecure, as payment
>> qr
>> codes don't cryptographically commit to the identity of the merchant,
>> which
>> means a MITM attacker can redirect the payment if they can obtain a SSL
>> cert
>> that the wallet accepts.
> By that reasoning, we also shouldn't go to https://coinbase.com or
> https://kraken.com to buy any bitcoins? As a MITM can redirect the site
> _if_ they obtain the coinbase or kraken certificate.
>
> Obviously, HTTPS is secured under the assumption that certificates are
> secure.  
>
> Using the payment protocol simply means paying to a secure endpoint (eg
> https://tomasvdw.nl/pay) instead of an address.
>
>>  That wallet is also likely using an off-the-shelf SSL library,
>> with
>> nothing other than an infrequently updated set of root certificates to
>> use to
>> verify the certificate; your browser has access to a whole host of better
>> technologies, such as HSTS pinning, certificate transparency, and
>> frequently
>> updated root certificate lists with proper revocation (see Symantec).
> So we should not use HTTPS for secure transfer because the
> implementation may not be good enough? This incorrectly conflates
> implementation with specification. There is nothing stopping a developer
> from using a proper implementation.
>
>> As an ad-hoc, unstandardized, extension Android Wallet for Bitcoin at
>> least
>> supports a h= parameter with a hash commitment to what the payment
>> request
>> should be, and will reject the MITM attacker if that hash doesn't match.
>> But
>> that's not actually in the standard itself, and as far as I can tell has
>> never
>> been made into a BIP.
> Currently it is widely used by merchants, but not yet for light clients
> _receiving_ money. If it becomes more wide spread,   it offers a range
> of advantages as  the bitcoin-address of the URI can and should be
> deprecated (made impossible with "h="). A payment address just becomes a
> secure endpoint.
>
> This means no more address reuse is possible. Also, it drops the need
> for mempool synchronization among non-miners, solely as a "notification"
> mechanism. In addition it means light clients know exactly when a
> transaction is coming in, so they can efficiently rely on client-side
> filtering a small set of blocks, improving their privacy.
>
> In my opinion, the payment protocol is key to scaling.
>
>> As-is BIP-72 is very dangerous and should be depreciated, with a new BIP
>> made
>> to replace it.
> Sorry, but maybe you  could explain better how secure communication over
> HTTPS is "very dangerous"? I think some websites would like to know :)
>
> Tomas van der Wansem
> bitcrust
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

Re: [bitcoin-dev] Why the BIP-72 Payment Protocol URI Standard is Insecure Against MITM Attacks

[Andreas Schildbach]

Generally agreed. This is why I nack'ed BIP72 years ago when we
discussed about standardization.

However, there are many ways to use BIP70 without BIP72. BIP72 is just a
kludge to biggy-pack the payment protocol onto BIP21. And also, as you
note, BIP72 can be easily fixed using a hash parameter.


On 09/29/2017 04:55 AM, Peter Todd via bitcoin-dev wrote:
> On Thu, Sep 28, 2017 at 03:43:05PM +0300, Sjors Provoost via bitcoin-dev wrote:
>> 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.
> 
> The BIP-70 payment protocol used via BIP-72 URI's is insecure, as payment qr
> codes don't cryptographically commit to the identity of the merchant, which
> means a MITM attacker can redirect the payment if they can obtain a SSL cert
> that the wallet accepts.
> 
> For example, if I have a wallet on my phone and go to pay a
> merchant, a BIP-72 URI will look like the following(1):
> 
>     bitcoin:mq7se9wy2egettFxPbmn99cK8v5AFq55Lx?amount=0.11&r=https://merchant.com/pay.php?h%3D2a8628fc2fbe
> 
> A wallet following the BIP-72 standard will "ignore the bitcoin
> address/amount/label/message in the URI and instead fetch a PaymentRequest
> message and then follow the payment protocol, as described in BIP 70."
> 
> So my phone will make a second connection - likely on a second network with a
> totally different set of MITM attackers - to https://merchant.com
> 
> In short, while my browser may have gotten the correct URL with the correct
> Bitcoin address, by using the payment protocol my wallet is discarding that
> information and giving MITM attackers a second chance at redirecting my payment
> to them. That wallet is also likely using an off-the-shelf SSL library, with
> nothing other than an infrequently updated set of root certificates to use to
> verify the certificate; your browser has access to a whole host of better
> technologies, such as HSTS pinning, certificate transparency, and frequently
> updated root certificate lists with proper revocation (see Symantec).
> 
> As an ad-hoc, unstandardized, extension Android Wallet for Bitcoin at least
> supports a h= parameter with a hash commitment to what the payment request
> should be, and will reject the MITM attacker if that hash doesn't match. But
> that's not actually in the standard itself, and as far as I can tell has never
> been made into a BIP.
> 
> As-is BIP-72 is very dangerous and should be depreciated, with a new BIP made
> to replace it.
> 
> 1) As an aside, it's absolutely hilarious that this URL taken straight from
>    BIP-72 has the merchant using PHP, given its truly terrible track record for
>    security.
> 
> 
> 
> _______________________________________________
> 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]

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

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

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

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

[Andreas Schildbach]

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.

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

[Peter Todd]

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

On Fri, Sep 29, 2017 at 10:44:11AM +0200, Andreas Schildbach via bitcoin-dev wrote:
> 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.

"Virtually all"?

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

Can you name some users of it?

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

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

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

[Andreas Schildbach]

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.

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

[Peter Todd]

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

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

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

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

[Gregory Maxwell]

On Fri, Sep 29, 2017 at 12:45 PM, Andreas Schildbach via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 15+ Mio Coinbase users

Who's payment protocol SSL cert was expired for months without even
generating a post on reddit.  Not exactly convincing there.

The fact that someone supports it doesn't mean its being used.