Yes, I would like to do so. But I would take it a step further. I
think the fixed-length metadata is also problematic for the same
reason. Only the payer and the holder of the corresponding spend key
should have a good chance of detecting whether a payment is stealth.
My recommendation would be to eliminate all three documented features
that make it possible to filter generally for stealth payments:

(1) The 0x06 version byte.
(2) The fixed length (4 byte) nonce.
(3) The requirement for ordering within a transaction.

To accomplish this I would propose that we change the format to:

[P:33][nonce:0..n]

As the nonce is arbitrary the length doesn't matter. Allowing it to
vary allows the metadata to lurk as arbitrary data, with the sole
exception of the min length requirement.

WRT the ordering question, it places a slightly higher computational
search cost on to clients but it really already exists. I think it
makes sense, once one has downloaded the tx, to simply test all RETURN
outputs of >= 33 bytes against all other outputs. Again, it's an
optimization question, but I think it's premature. Mining the prefix
into the hash is a pretty costly ed-optimization as well, but all in
the name of privacy.

Finally, I would ask what would be the purpose of a stealth database
if we made this change?

e

On 08/12/2014 05:00 PM, Amir Taaki wrote:
> Lets remove the version byte then. I didn't do it yet because I
> was busy. Is this what you're asking me? If so I'll communicate to
> other devs this is what we need to accomplish before public
> release.
>
> On 12/08/14 23:43, Eric Voskuil wrote:
>> Let's start with the assumption that the ability to identify a
>> set of outputs as a stealth payment reduces the stealthiness of
>> the payment. One can argue the *degree* to which that makes a
>> difference in real privacy, but it of course makes a difference.
>>
>> There are two aspects to detecting the existence of a potential
>> stealth payment. The pattern of transaction outputs (metadata
>> before spend):
>>
>> * out #1 - metadata for spend A * out #2 - stealth spend A * out
>> #3 - metadata for spend B * out #4 - stealth spend B ...
>>
>> https://wiki.unsystem.net/en/index.php/DarkWallet/Stealth#Transaction_format
>>
>>
>>
And the specific format of the outputs:
>>
>> -> RETURN <version:1=6> <nonce:4> <P:33> -> DUP HASH160 <pkh:20>
>> EQUALVERIFY CHECKSIG
>>
>> https://wiki.unsystem.net/en/index.php/DarkWallet/Stealth#Actual_output_form
>>
>>
at
>>
>> The spend (#2) output looks exactly like a very/most typical
>> non-stealth spend, which is great. The metadata output (#1) seems
>> problematic in that it can be easily used to identify all stealth
>> payments, with what would seem to be a very small false positive
>> rate.
>>
>> The two things that identify the metadata as probably stealth are
>> length (37 bytes) and a version byte (0x06). The odds of a 38
>> byte RETURN starting with 0x06 and immediately preceding the
>> required form of the spend script and *not* being a stealth
>> payment seem very low.
>>
>> This is of course a performance optimization. We can index this
>> pattern in obelisk. However, so can everyone else.
>>
>> Ideally we want stealth payments to look exactly like other
>> outputs, with no way to filter out the bulk of other information
>> on the blockchain apart from the prefices that people are
>> advertising in their stealth addresses and using in scans. We
>> could improve privacy by eliminating the version byte, the
>> ordering requirement, the fixed length (by adding a random length
>> of data to the metadata RETURN) and even encouraging other unused
>> random RETURN output in the transaction. By retaining a pattern
>> of 37 bytes minimum and at least two outputs there is still some
>> ability to narrow an attack, but this pattern would be so
>> commonplace as to effectively eliminate the value of such an
>> effort.
>>
>> Also, it would seem that prefix search for non-stealth payments
>> would eliminate any value gained in this optimization.
>>
>> So is the performance optimization worth the reduction in
>> privacy, for a system that is designed specifically for privacy?
>>
>> Thanks to Peter Todd for pointing out the issue of the stealth
>> version byte (and of prefix search for non-stealth) to me some
>> time ago.
>>
>> e
>>
>> _______________________________________________ Libbitcoin
>> mailing list Libbitcoin@???
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin
>>
>
>>
>
>
> _______________________________________________ Libbitcoin mailing
> list Libbitcoin@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin
>