From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XaPMD-00020r-UG for bitcoin-development@lists.sourceforge.net; Sat, 04 Oct 2014 13:26:45 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.218.42 as permitted sender) client-ip=209.85.218.42; envelope-from=mh.in.england@gmail.com; helo=mail-oi0-f42.google.com; Received: from mail-oi0-f42.google.com ([209.85.218.42]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XaPMC-0004a6-Mo for bitcoin-development@lists.sourceforge.net; Sat, 04 Oct 2014 13:26:45 +0000 Received: by mail-oi0-f42.google.com with SMTP id a141so1898166oig.15 for ; Sat, 04 Oct 2014 06:26:39 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.94.167 with SMTP id dd7mr14171689oeb.4.1412429199253; Sat, 04 Oct 2014 06:26:39 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.69.135 with HTTP; Sat, 4 Oct 2014 06:26:39 -0700 (PDT) In-Reply-To: References: Date: Sat, 4 Oct 2014 15:26:39 +0200 X-Google-Sender-Auth: csM1CYuWwcyOrd365tfrPDrzqLI Message-ID: From: Mike Hearn To: Kristov Atlas Content-Type: multipart/alternative; boundary=089e01183cbab128fd050498ccc3 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: 1XaPMC-0004a6-Mo Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] bitcoinj 0.12 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: Sat, 04 Oct 2014 13:26:46 -0000 --089e01183cbab128fd050498ccc3 Content-Type: text/plain; charset=UTF-8 Hey Kristov, > I hate to reply to a release that includes a huge number of new features > with yet another feature request, so -- with apologies -- any plans for > bitcoinj to support stealth address sending and/or receiving? > Stealth addresses and SPV don't mix well, so no. I wrote up a description of how to do something similar with the payment protocol here: https://medium.com/@octskyward/ecdh-in-the-payment-protocol-cb2f81962c1b Because you can send data around outside the block chain on private channels, with the pp the same issues don't crop up. At the moment there are no concrete plans what goes into the next release. I will be focusing on fully launching Lighthouse and crowdfunding for decentralisation/crypto related projects, so I won't be doing any major feature work on bitcoinj. Luckily it's become quite an active project now and there are lots of contributors, so things won't stand still. If I were to tackle a big project the next one would not be privacy related. It'd be refactoring the wallet so it doesn't store transactions directly anymore, just unspent outputs. Bitcoinj has always been largely driven by the needs of Andreas' mobile app, and right now the top user reported problem there is people hitting the scalability limits of the current design (e.g. they are mining directly into their phone's wallet). --089e01183cbab128fd050498ccc3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Kristov,

I hate to reply to a release that i= ncludes a huge number of new features with yet another feature request, so = -- with apologies -- any plans for bitcoinj to support stealth address send= ing and/or receiving?

Stealth addresses and SPV don= 9;t mix well, so no. I wrote up a description of how to do something simila= r with the payment protocol here:

https:= //medium.com/@octskyward/ecdh-in-the-payment-protocol-cb2f81962c1b
<= /div>

Because you can send data around outside the block= chain on private channels, with the pp the same issues don't crop up.<= /div>

At the moment there are no concrete plans what goe= s into the next release. I will be focusing on fully launching Lighthouse a= nd crowdfunding for decentralisation/crypto related projects, so I won'= t be doing any major feature work on bitcoinj. Luckily it's become quit= e an active project now and there are lots of contributors, so things won&#= 39;t stand still.

If I were to tackle a big projec= t the next one would not be privacy related. It'd be refactoring the wa= llet so it doesn't store transactions directly anymore, just unspent ou= tputs. Bitcoinj has always been largely driven by the needs of Andreas'= mobile app, and right now the top user reported problem there is people hi= tting the scalability limits of the current design (e.g. they are mining di= rectly into their phone's wallet).

--089e01183cbab128fd050498ccc3--