rich1.0npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2njumphttps://nostr.ae📅 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>