Nicolas Dorier (OP)
|
|
May 19, 2014, 04:50:23 PM |
|
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 ?
|
Bitcoin address 15sYbVpRh6dyWycZMwPdxJWD4xbfxReeHe
|
|
|
|
|
|
|
|
Once a transaction has 6 confirmations, it is extremely unlikely that an attacker without at least 50% of the network's computation power would be able to reverse it.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
piotr_n
Legendary
Offline
Activity: 2053
Merit: 1354
aka tonikt
|
|
May 19, 2014, 05:10:18 PM Last edit: May 19, 2014, 05:24:06 PM by 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.
|
Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.PGP fingerprint: AB9E A551 E262 A87A 13BB 9059 1BE7 B545 CDF3 FD0E
|
|
|
Nicolas Dorier (OP)
|
|
May 19, 2014, 10:05:23 PM |
|
I implemented it like that also. I hope miners will accept it.
|
Bitcoin address 15sYbVpRh6dyWycZMwPdxJWD4xbfxReeHe
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4158
Merit: 8382
|
|
May 20, 2014, 09:20:11 AM |
|
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
Legendary
Offline
Activity: 2053
Merit: 1354
aka tonikt
|
|
May 20, 2014, 09:53:59 AM |
|
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.
|
Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.PGP fingerprint: AB9E A551 E262 A87A 13BB 9059 1BE7 B545 CDF3 FD0E
|
|
|
Nicolas Dorier (OP)
|
|
May 20, 2014, 11:13:53 AM |
|
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.
|
Bitcoin address 15sYbVpRh6dyWycZMwPdxJWD4xbfxReeHe
|
|
|
genjix
Legendary
Offline
Activity: 1232
Merit: 1072
|
|
May 20, 2014, 02:03:46 PM |
|
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4158
Merit: 8382
|
|
May 20, 2014, 04:51:20 PM |
|
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
Legendary
Offline
Activity: 1232
Merit: 1072
|
|
May 20, 2014, 06:16:58 PM |
|
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 (OP)
|
|
May 20, 2014, 06:56:01 PM |
|
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 ?
|
Bitcoin address 15sYbVpRh6dyWycZMwPdxJWD4xbfxReeHe
|
|
|
Peter Todd
Legendary
Offline
Activity: 1120
Merit: 1150
|
|
May 21, 2014, 09:32:59 AM |
|
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
Moderator
Legendary
Offline
Activity: 4158
Merit: 8382
|
|
May 21, 2014, 08:15:43 PM |
|
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
Legendary
Offline
Activity: 1232
Merit: 1072
|
|
May 22, 2014, 10:43:41 AM |
|
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).
|
|
|
|
|