Autor: Amir Taaki Data: A: libbitcoin Assumpte: Re: [Libbitcoin] stealth not as stealthy as could be
Ahh yes that would work indeed.
On 13/08/14 03:27, Eric Voskuil wrote: > 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 >>
>
::
Re: [Libbitcoin] stealth not as ste…
