I agree that Peter should review. He was the one who made me aware of
the version issue in the first place. We didn't discuss varying the
nonce - I cooked that up.

Can you explain why a variable length nonce would matter, in any
context? Is it simply the need to align keys? If so we could certainly
adopt a nonce of 0-32 bytes without introducing difficulty:

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

e

On 08/12/2014 06:10 PM, Amir Taaki wrote:
> 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
>>
>>
> _______________________________________________
> Libbitcoin mailing list
> Libbitcoin@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin
>