From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 78F41BAF for ; Fri, 29 Sep 2017 07:18:11 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9622B442 for ; Fri, 29 Sep 2017 07:18:10 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A0B2421A25; Fri, 29 Sep 2017 03:18:09 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 29 Sep 2017 03:18:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sprovoost.nl; h= cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=0iu/Q2GwYV3anPhGRyoLXYc8bVvi/Jyy0OpUJOVOf q8=; b=Ehl8b6YYQB9a3KV0NvfHhspA6e9x6Q8I8P2HXATkusCyamKtPWtLBEzmy 6cuOoTo8mcql4sbLn400DY5Qn/FsrFHoKcUPJ3KdkELyV4d9yPrYBJ5gAXw4ZTS4 9Rrn2/4y4XEj3m22NILAiGRjGZ7a4h5nECXu4LkqkEwE/Me93iXBt85m3dZT4Hwz j4shiKJ4oOg8pOymCVV26viGI+N3obmiPVoqkicix6kguU2j7paY75CP85DJ6OxF Or3K+UE9fcgSg9mp+5AxhE0SSMvBk6WmPQWMB7EOPDl+RuFlZYEb/PpM/4zHXgE1 gHEUv+9nUs8yZVq4JHpOJuMlbTDWg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=0iu/Q2GwYV3anPhGRy oLXYc8bVvi/Jyy0OpUJOVOfq8=; b=QnwoVDI/G2PDg4GXNxMS12qm/Hr2Gd76ip SMNzhp+m25KXehpNH2Dm9FKeELU4DMypwP4yRM6rZew+Z6gt5X88u88gws+IzWev 7XItkLM0NiWA8rYvYq3W+ey4M+yynfK/c8hUeFGF9wiWUV438LjRJxEsq7lSOCg1 OC5jTaay2HD1WC/+cCySk/ZyXkPjU6gQvlt8MN9IUToRMDR6mrthY4iE7t5fHOV+ QduVVWyNJtRdCrBGUs4UBMuHYwvnkpg8C6otGBx1BG1sT9QcfRGeGQM/RT8WMfXy +AQWxQdZTfxZXHavatM2+3D2SPv9usWmosxh+BLg0usitLZuUphg== X-ME-Sender: X-Sasl-enc: IygXh9lhxNGSG4aQP5Ozm4HVOrC4v7KGHQzJUssSNm7h 1506669489 Received: from [192.168.0.108] (unknown [78.96.80.234]) by mail.messagingengine.com (Postfix) with ESMTPA id AE4257E3BA; Fri, 29 Sep 2017 03:18:08 -0400 (EDT) From: Sjors Provoost Message-Id: <3CCFB7B0-10FC-4860-86C0-29472B76B129@sprovoost.nl> Content-Type: multipart/signed; boundary="Apple-Mail=_AC257C04-D50E-43E2-AECA-12FEBAD56983"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) Date: Fri, 29 Sep 2017 10:18:06 +0300 In-Reply-To: <20170929021846.GB12303@savin.petertodd.org> To: Bitcoin Protocol Discussion References: <20170927160654.GA12492@savin.petertodd.org> <20170929021846.GB12303@savin.petertodd.org> X-Mailer: Apple Mail (2.3445.1.6) X-Spam-Status: No, score=0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_WEB autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 29 Sep 2017 11:56:10 +0000 Subject: Re: [bitcoin-dev] Address expiration times should be added to BIP-173 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 07:18:11 -0000 --Apple-Mail=_AC257C04-D50E-43E2-AECA-12FEBAD56983 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Op 29 sep. 2017, om 05:18 heeft Peter Todd het = volgende geschreven: >=20 > 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. >>=20 >> 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 >=20 > 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: >>>=20 >>> 1) Hour resolution - 2^24 hours =3D 1914 years >>> 2) Month resolution - 2^16 months =3D 5458 years >>=20 >> 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. >=20 > 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. >=20 > 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 --Apple-Mail=_AC257C04-D50E-43E2-AECA-12FEBAD56983 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE7ZvfetalXiMuhFJCV/+b28wwEAkFAlnN864ACgkQV/+b28ww EAlPDhAAtLjb6pVImRmktnBPsPp+TVlb8k7tN+6PS5eyv6H+l890ogQzONLGFQJm 2uYFlfsrKAvya6lUDQQQoW7TWBlDawYJc/Ui3hXhT7aE+UjynlOVkuky3Zy2u/Jg DYdG5RIZOWRNERxkIeFW2rxjEZA6tBjMyuIFw9UNWVlFCWMs9ss6WOLR4Wg64mg3 REED2qvE2VS38zDBLb/2pgws463fOrNW/cfQ4Cd3cKPc0agLub7S/MgRzZUtn+n5 xfz/20tLEyaKhkFrU5BFQ8m32aCvHyscurn1OPx3t+Z1rQJ5GQAU4EucEoiXQ+F2 FAOw1S5omHK+6ZGWDtVMrALCrKmEBL8wlLKMRlGMKK3DdIx/YVcB2yA79zDdS0V7 3ezCX9lj/sJQ/sb+cY4GmO+3kztekzgX+gDncW9tFViMLstwbR6GIGSodDVbuWjK mioLSnagwMSbElaDh3TKACoZPYlOuCM1BID4v2JaKjXLXk4tGUP7ahV9n4lshsMI HVH4WdqmJZJ7uvqaOjaEz0lQSZqt2Q54gugrveUBnlRsqO+1RWYKgUshEfQr6EN5 ajZcyLxZ8oeiLw99e29zELxajX56/51Jzrt/valeffhxGiPmpUqgGi+HQHeLgv+X /1IQj5G/y/HBrwNQdQ18E2GG2ut9HjjNlu5x4QavuHHgTqJk+6M= =melJ -----END PGP SIGNATURE----- --Apple-Mail=_AC257C04-D50E-43E2-AECA-12FEBAD56983--