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.
> 
> 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 Bloom
> 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 that
> 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.

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