Stealth-style address protocol for multisig used as buyer-seller escrow

[dev942]

I've just released a new, highly experimental market. Among other features, it implements stealth-style multisig for escrow. The protocol is that:

• Buyer, seller, and escrow agent all broadcast base public keys.
• When buyer wants to place an order:
  
  • Buyer generates a 256-bit nonce.
  • Buyer computes sha256 of all order details (nonce, products ordered, shipping address, etc.). This hash uniquely identifies the order to all parties.
  • Buyer computes e = sha256(nonce||orderHash), and adds e*G to each public key in the usual stealth way.

I think this has the properties that:

• The buyer can't place two orders with different hashes but identical payment addresses. This means that the seller doesn't need to keep any records to avoid getting tricked into shipping twice in exchange for one payment.
• No one except the buyer and seller for a particular transaction can find the payment in the blockchain. The escrow agent can't until the buyer or seller deliberately involves him.

Am I right? And is anyone doing this already? If the buyer and seller already can communicate privately off-blockchain (as they typically can, since they need to send addresses, tracking numbers, etc.), then why would anyone use BIP32-style keys instead of this?

Also, semi-Bitcoin-related: I've implemented a slight variation of ECIES on secp256k1 to support multiparty. I don't think I screwed it up, but any review is appreciated.

[1714891441]

1714891441

[1714891441]

1714891441

[piotr_n]

I think it's great, but also that people here will be rather reluctant to participate in a public engineering of this specific matter.
But yeah, it's good stuff.
Cheers

[dev942]

Thanks. It's unfortunate that most people can think of only frivolous reasons to care about privacy. You're probably right, though.

Any stealth that sends additional information through the blockchain is inherently less stealthy than stealth that doesn't (at least, unless a high volume of transactions uses it, and/or the information is placed in a transaction seemingly unrelated to the one that transfers the value). Perhaps that has limited interest in proposals so far.

I don't suppose you'd have a chance to look at my ECIES variant? No one has ever reviewed, rather bad for crypto.