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

[Gregory Maxwell via bitcoin-dev]

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.

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.
___
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] Bitcoin Assistance

[Tim Ruffing via bitcoin-dev]

Oh nevermind. I had a look at the history but missed that commit and
assumed the change was introduced when adding the text to
contrib/debian/copyright

Tim

On Wed, 2017-09-27 at 22:21 +, Gregory Maxwell wrote:
> On Wed, Sep 27, 2017 at 9:54 PM, Tim Ruffing via bitcoin-dev
>  wrote:
> > Also, even the old version lists some icons "based on Stephan
> > Hutchings
> > Typicons" as "License: MIT", which could be a violation of CC BY-SA 
> > if
> > I'm not mistaken.
> 
> Relicensed by the copyright holder:
> 
> https://github.com/bitcoin/bitcoin/commit/dae0a89d4b66f08c83ccc8c20cf
> 37521084b6257
> 
> (For future reference, git log -p  makes it easy to go find
> where some string was last in a file, so you can look at the commit
> that changed it.)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Assistance

[Gregory Maxwell via bitcoin-dev]

On Wed, Sep 27, 2017 at 9:54 PM, Tim Ruffing via bitcoin-dev
 wrote:
> Also, even the old version lists some icons "based on Stephan Hutchings
> Typicons" as "License: MIT", which could be a violation of CC BY-SA if
> I'm not mistaken.

Relicensed by the copyright holder:

https://github.com/bitcoin/bitcoin/commit/dae0a89d4b66f08c83ccc8c20cf37521084b6257

(For future reference, git log -p  makes it easy to go find
where some string was last in a file, so you can look at the commit
that changed it.)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Assistance

[Gregory Maxwell via bitcoin-dev]

On Wed, Sep 27, 2017 at 9:20 PM, Cory Fields via bitcoin-dev
 wrote:
>> License for A fast alternative to the modulo reduction
>
> This references a comment cuckoocache.h. No code from the site is used. The
> link to the site was added after the code, as the site provides a helpful
> explanation for the technique used.

As the author of that comment: the reference there is unrelated to the
code but just a found-on-the-internet explanation for an trivial, old,
and well known technique (which I've seen in code since at least the
80s) that manages to sometimes surprise people who aren't familiar
with fixed point signal processing.  I wrote and submitted the comment
after encountering people confused by our code in another project,
long after it was written.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Assistance

[Tim Ruffing via bitcoin-dev]

On Wed, 2017-09-27 at 17:20 -0400, Cory Fields via bitcoin-dev wrote:
> > Creative Commons Attribution Share Alike 3.0
> 
> I didn't manage to find any CC-licensed files. The match probably
> comes from our gui svg icons, which contain an xml tag with a link to
> creativecommons.org. This seems to be the default behavior of
> inkscape, which was used to create those icons. Any icons that we
> have not created ourselves are listed in contrib/debian/copyright
> (they're all expat/public domain).

This is somewhat weird. Back in 2014, most of icons were listed as
"CC BY-SA" (which is the correct license according to the original
source):
https://github.com/bitcoin/bitcoin/blob/31aac02446472ec5bfc4676ab190ec9d37056503/doc/assets-attribution.md

However the current docs list them as "Expat". A mistake?
https://github.com/bitcoin/bitcoin/blob/master/contrib/debian/copyright

Also, even the old version lists some icons "based on Stephan Hutchings
Typicons" as "License: MIT", which could be a violation of CC BY-SA if
I'm not mistaken.

Best,
Tim


___
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] Bitcoin Assistance

[Cory Fields via bitcoin-dev]

Hi Mark

Thank you very much for posting the findings. I took a look through our
repository and I think I can provide a bit of context.

I'll go through each one, annotating what I've found.

> Apache License 2.0

This is used by a few java files in the libsecp256k1 project. That library
(which lives here: https://github.com/bitcoin-core/secp256k1) is a
sub-module created and maintained by Bitcoin Core developers. The files in
question are bindings that allow other applications to use libsecp256k1
from Java. Bitcoin Core makes no use of them.

> Boost Software License 1.0

This comes from tinyformat.h. Bitcoin Core indeed uses it.

> BSD 2-clause "Simplified" License

I'm unable to find any 2-clause BSD licensed files.

> BSD 3-clause "New" or "Revised" License

This comes from leveldb, which is database software used by Bitcoin Core.
Because database software version inconsistencies can cause accidental
forks (this actually happened in 2013), we include these files in our
repository and use them rather than linking to arbitrary versions at
runtime.

There are a few non-upstream files we use in our leveldb tree to provide
windows support. Quoting from src/leveldb/util/env_win.cc:
  This file contains source that originates from:

http://code.google.com/p/leveldbwin/source/browse/trunk/win32_impl_src/env_win32.h

http://code.google.com/p/leveldbwin/source/browse/trunk/win32_impl_src/port_win32.cc
  Those files don't have any explicit license headers but the
  project (http://code.google.com/p/leveldbwin/) lists the 'New BSD License'

> Creative Commons Attribution Share Alike 3.0

I didn't manage to find any CC-licensed files. The match probably comes
from our gui svg icons, which contain an xml tag with a link to
creativecommons.org. This seems to be the default behavior of inkscape,
which was used to create those icons. Any icons that we have not created
ourselves are listed in contrib/debian/copyright (they're all expat/public
domain).

> Expat License

See MIT.

> GNU General Public License v2.0 or later

The debian folder, which holds the files used to create debian/ubuntu
packages is licensed gplv2+. These are packaging resources only,
unnecessary for use of the code.

Additionally, some gplv2 m4 macros are used to bootstrap the code that is
used to build the Bitcoin code. These contain the additional exception:

   As a special exception, the respective Autoconf Macro's copyright owner
   gives unlimited permission to copy, distribute and modify the configure
   scripts that are the output of Autoconf when processing the Macro. You
   need not follow the terms of the GNU General Public License when using
   or distributing such scripts, even though portions of the text of the
   Macro appear in them. The GNU General Public License (GPL) does govern
   all other use of the material that constitutes the Autoconf Macro.

> GNU General Public License v3.0 or later

The macdeploy script, useful for creating DMG files for macOS is gplv3. It
is not necessary for any other platform, and is only used during the build
process. Additionally, it is not the only way to create DMG files (apple's
native tools can be used as well).

Additionally, config.guess and config.sub are gplv3 scripts used to build
our buildsystem.

> GNU Lesser General Public License v2.1 or later

authproxy.py, A python script used in our test suite is licensed lgpl
v2.1+. It is only necessary for running optional tests during development.

> License for A fast alternative to the modulo reduction

This references a comment cuckoocache.h. No code from the site is used. The
link to the site was added after the code, as the site provides a helpful
explanation for the technique used.

> License for atomic by Timm Kosse

Another m4 file. As explained with the others above, this is a macro which
builds code which builds code. It is used in the build process only.

> MIT License

The primary and default license for all contributions.

> Public Domain

> University of Illinois/NCSA Open Source License

clang-format-diff.py, a python script optionally used by developers to
clean up code changes.

tl;dr: Best I can tell, all source files that comprise Bitcoin Core
binaries are licensed (excluding the public domain ones) as MIT, BSD, or
Boost.

It's also worth repeating Omar's point that many of the files in the
Bitcoin Core repository are used for optional programs/libraries. None of
the artwork, for example, is needed for the primary bitcoin daemon.

Hope that helps!

Regards,
Cory
___
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 
 on behalf of Chris Priest via 
bitcoin-dev 
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 
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

___
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] Revising BIP 2 to expand editorial authority

[Sjors Provoost via bitcoin-dev]

Op 27 sep. 2017, om 22:01 heeft Bryan Bishop via bitcoin-dev 
 het volgende geschreven:
> 
> On Wed, Sep 27, 2017 at 1:56 PM, Luke Dashjr via bitcoin-dev 
>  > wrote:
> What do people think about modifying BIP 2 to allow editors to merge these
> kinds of changes without involving the Authors? Strictly speaking, BIP 2
> shouldn't be changed now that it is Active, but for such a minor revision, I
> think an exception is reasonable.
> 
> Even minor revisions can not change the meaning of text. Changing a single 
> word can often have a strange impact on the meaning of the text. There should 
> be some amount of care exercised here. Maybe it would be okay as long as 
> edits are mentioned in the changelog at the bottom of each document, or 
> mention that the primary authors have not reviewed suggested changes, or 
> something as much; otherwise the reader might not be aware to check revision 
> history to see what's going on.

Perhaps it's enough to @mention authors in the PR and give them a week to 
object before merging?

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

[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] Revising BIP 2 to expand editorial authority

[Bryan Bishop via bitcoin-dev]

On Wed, Sep 27, 2017 at 1:56 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> What do people think about modifying BIP 2 to allow editors to merge these
> kinds of changes without involving the Authors? Strictly speaking, BIP 2
> shouldn't be changed now that it is Active, but for such a minor revision,
> I
> think an exception is reasonable.
>

Even minor revisions can not change the meaning of text. Changing a single
word can often have a strange impact on the meaning of the text. There
should be some amount of care exercised here. Maybe it would be okay as
long as edits are mentioned in the changelog at the bottom of each
document, or mention that the primary authors have not reviewed suggested
changes, or something as much; otherwise the reader might not be aware to
check revision history to see what's going on.

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Revising BIP 2 to expand editorial authority

[Luke Dashjr via bitcoin-dev]

Many pull requests to the BIPs repository are spelling corrections or similar, 
which are obvious to merge. Currently, the BIP process requires the Author of 
the affected BIPs to ACK any changes, which seems inefficient and unnecessary 
for these kind of editorial fixes.

What do people think about modifying BIP 2 to allow editors to merge these 
kinds of changes without involving the Authors? Strictly speaking, BIP 2 
shouldn't be changed now that it is Active, but for such a minor revision, I 
think an exception is reasonable.

I've prepared a draft PR for BIP 2 here:
https://github.com/bitcoin/bips/pull/596

If you oppose this change, please say so within the next month.

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

[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