Peter Todd [ARCHIVE] on Nostr: š Original date posted:2017-09-28 š Original message:On Thu, Sep 28, 2017 at ...
š
Original date posted:2017-09-28
š Original message: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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170928/04ab3f7f/attachment.sig>;
š Original message: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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170928/04ab3f7f/attachment.sig>;