Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1W2fXO-0004QD-Hm for bitcoin-development@lists.sourceforge.net; Mon, 13 Jan 2014 11:18:34 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.172 as permitted sender) client-ip=209.85.214.172; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f172.google.com; Received: from mail-ob0-f172.google.com ([209.85.214.172]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1W2fXN-0000Hl-GG for bitcoin-development@lists.sourceforge.net; Mon, 13 Jan 2014 11:18:34 +0000 Received: by mail-ob0-f172.google.com with SMTP id gq1so7587119obb.31 for ; Mon, 13 Jan 2014 03:18:28 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.87.42 with SMTP id u10mr20051075obz.22.1389611908086; Mon, 13 Jan 2014 03:18:28 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.76.99.112 with HTTP; Mon, 13 Jan 2014 03:18:28 -0800 (PST) In-Reply-To: References: Date: Mon, 13 Jan 2014 12:18:28 +0100 X-Google-Sender-Auth: CPtLVC7NLzrmIXYhrPzPYKFXeE0 Message-ID: From: Mike Hearn To: Jeremy Spilman Content-Type: multipart/alternative; boundary=089e013cba6228434c04efd83c53 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1W2fXN-0000Hl-GG Cc: "bitcoin-development@lists.sourceforge.net" Subject: Re: [Bitcoin-development] Stealth Payments - Sample Code / Proof of Concept X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 11:18:34 -0000 --089e013cba6228434c04efd83c53 Content-Type: text/plain; charset=UTF-8 Cool! On Mon, Jan 13, 2014 at 10:18 AM, Jeremy Spilman wrote: > I spent 1BTC on TestNet to a stealth address... > TxID: df092896c1347b303da299bc84c92bef1946f455dbdc80ffdb01a18ea4ed8b4c > ... but can you redeem it? > Code which generated this transaction is here: > https://gist.github.com/jspilman/8396495 That's rather interesting code. Is this using a private C# bitcoin implementation? > I wonder if the 0BTC OP_RETURN transactions should be hidden from the > Transaction List? > Yes, of course. The transaction list should just say something like "Payment received from Jeremy, 0.1 BTC" Maybe the simple way to punt on this is to just show 'Merchant' in the > address column if it is available and an address is not. I am surprised it's not already the case! Though "merchant" is perhaps a bit biased as a name, internally it perhaps should just be called "Recipient". There's no requirement for you to be a merchant to create payment protocol requests. > I can probably make the necessary changes to IsMine, but I don't know > where we should keep 'd2'/'Q2' unencrypted so it's available for doing the > necessary tests, but has no chance of ever be used as a stand-alone > private key? > The wallet format would need extending. I'd feel a lot more comfortable if the protocol was reviewed by a professional cryptographer though. I think think Gregory already brought up an issue to do with people able to detect such payments by testing if decrypted values are points on the curve, or something like that. --089e013cba6228434c04efd83c53 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Cool!

On Mon, Jan 13, 2014 at 10:18 AM, Jeremy Spilman <jeremy@= taplink.co> wrote:
I spent 1BTC on TestNet to a stealth address= ...
=C2=A0 =C2=A0 TxID: df092896c1347b303da299bc84c92bef1946f455dbdc80ffdb01a18= ea4ed8b4c

... but can you redeem it?
=C2=A0
Code which generated this transaction is here:
http= s://gist.github.com/jspilman/8396495

Th= at's rather interesting code. Is this using a private C# bitcoin implem= entation?
=C2=A0
I wonder if the 0BTC OP_RET= URN transactions should be hidden from the
Transaction List?

Yes, of course. The t= ransaction list should just say something like

=C2= =A0 =C2=A0 "Payment received from Jeremy, =C2=A00.1 BTC"

Maybe the simple way to punt on this is to j= ust show 'Merchant' in the
address column if it is available and an address is not.
<= br>
I am surprised it's not already the case! Though "me= rchant" is perhaps a bit biased as a name, internally it perhaps shoul= d just be called "Recipient". There's no requirement for you = to be a merchant to create payment protocol requests.
=C2=A0
I can probably make the nec= essary changes to IsMine, but I don't know
where we should keep 'd2'/'Q2' unencrypted so it's avai= lable for doing the
necessary tests, but has no chance of ever be used as a stand-alone
private key?

The wallet format would ne= ed extending.

I'd feel a lot more comfortable = if the protocol was reviewed by a professional cryptographer though. I thin= k think Gregory already brought up an issue to do with people able to detec= t such payments by testing if decrypted values are points on the curve, or = something like that.
--089e013cba6228434c04efd83c53--