{"type":"rich","version":"1.0","author_name":"npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","author_url":"https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-09-28\n📝 Original message:On Thu, Sep 28, 2017 at 12:58:30AM +0000, Gregory Maxwell wrote:\n\u003e On Wed, Sep 27, 2017 at 4:06 PM, Peter Todd via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e Re-use of old addresses is a major problem, not only for privacy, but also\n\u003e \u003e operationally: services like exchanges frequently have problems with users\n\u003e \u003e sending funds to addresses whose private keys have been lost or stolen; there\n\u003e \n\u003e When Pieter and I were working on Bech32 we specifically designed for\n\u003e error correcting codes that had good performance for longer lengths\n\u003e than we technically needed specifically to incorporate things like\n\u003e dates and explicit amounts.\n\u003e \n\u003e (explicit amounts so that typos and bit flips in amounts displayed or\n\u003e in memory couldn't result in sending the wrong amount)\n\u003e \n\u003e But we also thought that also adding those features at the same time\n\u003e would retard adoption-- both due to debating over the encodings and\n\u003e because handling would result in different software requirements and\n\u003e layering, so you couldn't just drop them in.\n\nNotably, even something as simple as adding a new type of confirmation window\nthat might be needed is a big chance to UI logic.\n\n\u003e Doubly unfortunately, people have even deployed BIP173 already (prior\n\u003e to it even having much peer review or being adopted by its own\n\u003e authors), so I think a rethink now wouldn't be timely (I mean as a\n\u003e replacement to BIP173 rather than an additional format). :(\n\nYeah, I just noticed Pieter Wuille's BIP173-including segwit pull-req - that's\na lot of code that would get touched by this proposal, so it's likely too late\nin the process.\n\n\u003e But I do support the idea.\n\u003e \n\u003e One thing to keep in mind is that address format linked fields are\n\u003e most efficient if they're multiples of 5 bits.  Perhaps use 1 bit to\n\u003e indicate an embedded amount and 19 bits of 1 day precision, resulting\n\u003e in a 1435 year span.\n\nWhat do you mean by \"an embedded amount\"?\n\n\u003e Keep in mind that high precision of the expiration times is asking the\n\u003e sender to have a higher precision of idea of the time, date only is\n\u003e kinda nice.  I think shorter expiration times are unlikely to be\n\u003e useful due to clock skew-- you can't assume a signer has any access to\n\u003e the Bitcoin network at all.\n\nI'm inclined to agree as well. Also, Bitcoin payments themselves are inherently\nimprecise, because blocks aren't found on a regular interval - Coinbase's \"10\nminute\" payment expiry window is odd from that point of view.\n\nHaving said that, you'd want a resolution more precise than what you'd expect\ntimeouts to be set at, to avoid UI \"fencepost\" oddity; if I want to set a 1 day\ntimeout, users shouldn't see either 1 or 2 days depending on exactly which way\nit happened to be rounded that particular time..\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 455 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170928/04ab3f7f/attachment.sig\u003e"}