Are Stealth Address limited to one per transaction ?

[Nicolas Dorier]

I am reading here http://sx.dyne.org/stealth.html#uncloaking-payments:

In the output above, there are 2 outputs with the first containing the stealth metadata and the second containing the actual payment. Transactions can have multiple stealth payments but the metadata and payment always occurs in pairs.

But on the other side, there is a limit of one TxOut RETURN 0xDATA (40 bytes) per transaction imposed by bitcoin core isn'it ?

So, there is always, at most, one stealth payment per transaction or am I missing something ?

[1713874591]

1713874591

[1713874591]

1713874591

[1713874591]

1713874591

[1713874591]

1713874591

[1713874591]

1713874591

[piotr_n]

I believe "the metadata and payment always occurs in pairs", it means e.g.:

 * out #1 - metadata for spend A
 * out #2 - stealth spend A
 * out #3 - metadata for spend B
 * out #4 - stealth spend B
 * out #5 - regular spend C
 * out #6 - metadata for spend D
 * out #7 - stealth spend D
 * out #8 - regular spend E
 * out #9 - regular spend F
 * out #10 - metadata for spend G
 * out #11 - stealth spend G

something like that.
or at least I have it implemented like this

But on the other side, there is a limit of one TxOut RETURN 0xDATA (40 bytes) per transaction imposed by bitcoin core isn'it ?

Just on relaying transactions. I believe already today most miners would take it, if you just give it a sufficient fee and push it through.

[Nicolas Dorier]

I implemented it like that also. I hope miners will accept it.

[gmaxwell]

Gah, if its specified that way that sinks. There is no need to have a separate public point for every 'stealth' output.

Beyond the lack of need is unreasonable to have a separate DH nonce per output both for bandwidth reasons and also for performance ones (the scanning host having to do N point multiplies per transaction is ugly).  I recommend fixing the specification to get rid of this overhead.

Currently the IsStandard behavior limits transactions to a single OP_RETURN output.

[piotr_n]

There is no need to have a separate public point for every 'stealth' output.

I don't think it is meant to use multiple outputs of one transactions, for making payments to the same stealth address. I would not see much meaning in it.

I believe this approach makes much more sense, because it allows you to use one transaction for sending money to different stealth addresses. If not for such an approach, CoinJoin-ing of stealth outputs would not have been possible.

[Nicolas Dorier]

Gah, if its specified that way that sinks. There is no need to have a separate public point for every 'stealth' output.

Beyond the lack of need is unreasonable to have a separate DH nonce per output both for bandwidth reasons and also for performance ones (the scanning host having to do N point multiplies per transaction is ugly).  I recommend fixing the specification to get rid of this overhead.

Currently the IsStandard behavior limits transactions to a single OP_RETURN output.

There is a "bitfield" in a stealth address that you can use to scan transactions without having to do a multiply.

I am not sure about what you mean with your terminology, I call "Stealth Address" what the receiver share, and "public address" the standard bitcoin address the sender will send funds to.

The problem is not to send funds to different public addresses coming from the same stealth address (which is useless)
But to send to different public address coming from different stealth address. (2 differents stealth receiver in the same transaction)

I don't see how the specification can change to support that since all data in the OP_RETURN is needed.

[genjix]

thanks piotr, I clarified it on the Wiki

https://wiki.unsystem.net/index.php/DarkWallet/Stealth#Transaction_format

[gmaxwell]

There is a "bitfield" in a stealth address that you can use to scan transactions without having to do a multiply.
I am not sure about what you mean with your terminology, I call "Stealth Address" what the receiver share, and "public address" the standard bitcoin address the sender will send funds to.
The problem is not to send funds to different public addresses coming from the same stealth address (which is useless)
But to send to different public address coming from different stealth address. (2 differents stealth receiver in the same transaction)
I don't see how the specification can change to support that since all data in the OP_RETURN is needed.

I didn't say anything about coming from the same stealth address. I'm specifically talking about a sendmany.

Because the bait must be small to prevent deanonymization, and so there would still be a large amount of DH overhead if the transaction contained multiple nonces, plus doubling the size of the marginal txout data.

The bloom bait should be in separate pushes in a single OP_RETURN, the addr_index patch to Bitcoin core was setup to index  separate push operations for this sort of reason.  So there should be one 33 byte public point in the push, and 1 to N bait.

This is compatible with CoinJoin too— the participants just share a random value.

[genjix]

no, because you need sharding for different stealth address prefixes which is computed based on the metadata output. each output needs its own metadata.

[Nicolas Dorier]

There is a "bitfield" in a stealth address that you can use to scan transactions without having to do a multiply.
I am not sure about what you mean with your terminology, I call "Stealth Address" what the receiver share, and "public address" the standard bitcoin address the sender will send funds to.
The problem is not to send funds to different public addresses coming from the same stealth address (which is useless)
But to send to different public address coming from different stealth address. (2 differents stealth receiver in the same transaction)
I don't see how the specification can change to support that since all data in the OP_RETURN is needed.

I didn't say anything about coming from the same stealth address. I'm specifically talking about a sendmany.

Because the bait must be small to prevent deanonymization, and so there would still be a large amount of DH overhead if the transaction contained multiple nonces, plus doubling the size of the marginal txout data.

The bloom bait should be in separate pushes in a single OP_RETURN, the addr_index patch to Bitcoin core was setup to index  separate push operations for this sort of reason.  So there should be one 33 byte public point in the push, and 1 to N bait.

This is compatible with CoinJoin too— the participants just share a random value.

If I understand you correctly, in dark wallet terminology, it means that we would have only one Ephem Key (what you call the public point) shared between all receiver, and the bait is for scanning purpose of the receiver.

no, because you need sharding for different stealth address prefixes which is computed based on the metadata output. each output needs its own metadata.

genjix, if I understand what gmaxwell is saying is that we would have 33 bytes for the EphemKey, and use the rest for one prefix per destination.
So we would have one metadata for several destination.
But one question I have : currently, to calculate the prefix, you hash the OP_RETURN data in one hash 256, and the scanner will check if the first resulting bytes match the bitfield.
Why doing that ?
Why not having the prefix as a seperate push in the OP_RETURN, and the scanners will just check if these match their bitfield ?

[Peter Todd]

Sharing ephemeral keys between senders isn't a good idea; the ephemeral key can be used to prove you sent the funds without showing what exact inputs were used. Secondly having separate pushes is both non-standsrd right now, and unlikely to ever be made into a miner committed index.

genjix: putting the op-return prior to the txout In the standard is a good idea, though may conflict with merge avoidance techniques; need to think about that some more prior to releasing v1.0

 I'm working on getting rid of the restrictive IsStandard() rules too, which would let us do things like put the ephemeral key in the txout directly too.

[gmaxwell]

I think forcing people to use distinct ephemeral keys is a very poor design.

In the limit it doubles output sizes— and even on single output transactions it doubles the size since you would immediately need to include two just to make the change output indistinguishable, it would greatly expand the problematic side-channel bandwidth for non-bitcoin information which is intentionally limited in the current network behavior, and it makes the scanner's computation scale with the number of outputs instead of the number of transactions.

[genjix]

I think forcing people to use distinct ephemeral keys is a very poor design.

In the limit it doubles output sizes— and even on single output transactions it doubles the size since you would immediately need to include two just to make the change output indistinguishable, it would greatly expand the problematic side-channel bandwidth for non-bitcoin information which is intentionally limited in the current network behavior, and it makes the scanner's computation scale with the number of outputs instead of the number of transactions.

I've bench-marked this a lot and can do millions and millions of rows with no problems. I've documented my database design on the Wiki and it isn't complicated. Also there's several optimisation techniques that can be adopted.

The real problem is addresses in Bitcoin not sharing the same prefix (like stealth supports).