Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.106 as permitted sender)
	client-ip=62.13.148.106; envelope-from=pete@petertodd.org;
	helo=outmail148106.authsmtp.co.uk; 
Date: Mon, 31 Mar 2014 11:23:09 +0200
From: Peter Todd <pete@petertodd.org>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20140331092309.GA19482@tilt>
References: <CANEZrP0AwR3WgHfwYWcrC9Z_MHPDwymWXAQwp7D8XZ+o2FsK8g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="9amGYk9869ThD9tj"
Content-Disposition: inline
In-Reply-To: <CANEZrP0AwR3WgHfwYWcrC9Z_MHPDwymWXAQwp7D8XZ+o2FsK8g@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP 70 refund field
Precedence: list


--9amGYk9869ThD9tj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 28, 2014 at 12:07:04PM +0100, Mike Hearn wrote:
> Though I am loathe to go back and redesign this part of BIP 70 so soon
> after we shipped v1, it seems to me like the refund feature may be hard to
> implement on phones if there's no time limit for when you can receive a
> refund. Otherwise a wallet has to be looking out for refunds for payments
> you may have made years ago. So perhaps we should add a new refund field
> that embeds a PaymentDetails structure instead of being just a list of
> outputs.
>=20
> We could try and solve this problem some other way purely internally, by
> doing a kind of wallet-specific swapping process in which things like Blo=
om
> filters are calculated without all keys in them being held in memory at
> once (perhaps caching filters for old parts of the key chain on disk), so
> you can have "infinite" wallets, but eventually the huge Bloom filters th=
at
> would result would hurt efficiency in other ways. So key expiry seems
> pretty fundamental to scalability.

One of the main goals of steath addresses is actually scalability. In
particular in the refund address case you would use stealth addresses
with a per-order UUID so that refunds can be detected cheaply by just
scanning for payments to your (single) stealth address, then when those
payments are detected, check the UUID against a on-disk database. A
64-bit "UUID" is probably fine, although unfortunately with OP_RETURN
quite unexpectedly dropped to 40 bytes the standard needs to change;
might have to compromise on privacy and re-use a txin pubkey to make
things fit.

--=20
'peter'[:-1]@petertodd.org
0000000000000000f4f5ba334791a4102917e4d3f22f6ad7f2c4f15d97307fe2

--9amGYk9869ThD9tj
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQGcBAEBCAAGBQJTOTP4AAoJEGJeboN5AaHK3BwL/2cufakUZftLPL7iC9E1R/Bd
Y2CleAYIpbfJ+vGRmFCw3hD0BMufGyU0HFvPBkz5s5vfsDtwZvDuiqENlH1JAU2I
qtG6hGmtPDEiQxlPSRpvgfy6sDMetkQsctZ1QjOI5bdyoztcub7CDPEVzYwW9u+w
26rlO56d8ygfasT1gUkGtFiAv7Ytn9MU7FeQrr9iufXb57VOeBAZjSstiWMc9QSX
RPIBEAB3n5S/MwOprKh5cB9x62eXiCsOxB+45UtRy/EJh8ht72QCuWmChVP2F0ZF
zmcvPjBp3Avwuftiv9Iipkit7Xg8qZiZxkD35JOTXGNN3bgcvoQKnMFNIf8BrviB
GERFHCIyv25wPznCsG9uyuLH0Wi3To+qyeo/7gxOSpctoxntV34rAjI2M66tSbvE
yO+mVW1kMJPfOzwldCzKgROPtyJjfLzlDTIs0g3AGGZycNlVU1Rvksc2OCgGJ+IB
a6QwD6gHg3qdPwYxAFd7Ku/FZ3n7NG6Qwi+8LbNkWA==
=N4Oj
-----END PGP SIGNATURE-----

--9amGYk9869ThD9tj--