I reeeally think you should discuss this stuff with Peter (although I
know he's on holidary right now) because I am implementing to his spec
(although he recommended against the version byte too but I'd already
implemented stealth).

Also variable length nonce is a problem for multisig stealth. It's
something we'll need in DW at some point.

There's been talk about using plain BTC addresses instead of OP_RETURN
because BitcoinQt mempool limits txs to have 1 single OP_RETURN output
per tx. That's a problem if you do CoinJoin. However with the huge
blockchain size, I need to find a scalable way to do this.

Right now I can keep tuning more performance from the blockchain and
investigating more data structures / optimisation techniques but at this
point I need to get moving, integrate the stuff, to reach the next
iteration of stability to things are working.
But yes it's good I know the issues so I can start thinking. Will need
to plan and ponder. Stealth database will need a rewrite.

On 13/08/14 02:22, Eric Voskuil wrote:
> 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
>
>