From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1W3AuM-0004kI-LN
for bitcoin-development@lists.sourceforge.net;
Tue, 14 Jan 2014 20:48:22 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.82 as permitted sender)
client-ip=62.13.149.82; envelope-from=pete@petertodd.org;
helo=outmail149082.authsmtp.co.uk;
Received: from outmail149082.authsmtp.co.uk ([62.13.149.82])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1W3AuL-00038P-C5 for bitcoin-development@lists.sourceforge.net;
Tue, 14 Jan 2014 20:48:22 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt14.authsmtp.com (8.14.2/8.14.2) with ESMTP id s0EKmEVP022726;
Tue, 14 Jan 2014 20:48:14 GMT
Received: from petertodd.org (petertodd.org [174.129.28.249])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s0EKm6P5030400
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Tue, 14 Jan 2014 20:48:09 GMT
Date: Tue, 14 Jan 2014 15:48:06 -0500
From: Peter Todd <pete@petertodd.org>
To: Jeremy Spilman <jeremy@taplink.co>
Message-ID: <20140114204806.GA20546@petertodd.org>
References: <op.w9kkxcityldrnw@laptop-air.hsd1.ca.comcast.net>
<CABsx9T2G=yqSUGr0+Ju5-z9P++uS20AwLC+c3DnFMHtcQjQK6w@mail.gmail.com>
<CAAS2fgTz0TaGhym_35V3N2-vHVzU9BeuV8q+QJjwh5bg77FEZg@mail.gmail.com>
<20140113194049.GJ38964@giles.gnomon.org.uk>
<CANAnSg30V01B_3LCJ09sTwcsYa4_WOg3sKd-=p6COZS6w0b-uA@mail.gmail.com>
<52D4458C.6010909@gmail.com>
<CAAS2fgTzVWUF_B_-1jkRs3WZ8Um_CcHeH7uFU0eLncgEqQ01HQ@mail.gmail.com>
<19AE1549-16E0-4119-8BE9-8F4DFD3381C1@taplink.co>
<20140114141908.GB29950@savin>
<op.w9oybextyldrnw@laptop-air.hsd1.ca.comcast.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="BOKacYhQ+x31HxR3"
Content-Disposition: inline
In-Reply-To: <op.w9oybextyldrnw@laptop-air.hsd1.ca.comcast.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 2dc56bab-7d5d-11e3-b802-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdwYUElQaAgsB AmIbWVReVFV7WGM7 ag1VcwRfa1RMVxto
VEFWR1pVCwQmQhx0 fUMYMhxydAVCeH4+ ZEFgV3YVXhApcEAv
ExxJEjkDMXphaTUc TRJQdwFJcANIexZF O1F6ACIKLwdSbGoL
NQ4vNDcwO3BTJTpY RgYVKF8UXXNDJSIx ThQeHX0GEUEfSj4o IgdO
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 174.129.28.249/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.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 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1W3AuL-00038P-C5
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Stealth Addresses
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 14 Jan 2014 20:48:22 -0000
--BOKacYhQ+x31HxR3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Jan 14, 2014 at 11:12:40AM -0800, Jeremy Spilman wrote:
> Maybe you are saying:
>=20
> byte[] S =3D EC.DH(e, Q2);
> byte[] q1New =3D EC.PointAdd(Q1, Util.SingleSHA256(S));
> byte[] q2New =3D EC.PointAdd(Q2, Util.SingleSHA256(S));
>=20
> But the payment would have (q2New - q1New) =3D=3D (Q2 - Q1), so I think
> not entirely stealth? OK, let's fix that by adding a counter to the
> hash function...
Good catch, yeah, use the master shared secret to derive per-pubkey
secrets.
> byte[] S =3D EC.DH(e, Q2);
> byte[] q1New =3D EC.PointAdd(Q1, Util.SingleSHA256(S || 1));
> byte[] q2New =3D EC.PointAdd(Q2, Util.SingleSHA256(S || 2));
> stealthTx.Vout.Add(TxOut.PayToMultiSig(Util.Amount(".995"), 2, 2,
> q1New, q2New));
> stealthTx.Vout.Add(TxOut.OpReturn(P));
>=20
> This is assuming we want to put q2New somewhere into the
> transaction, which, is it even required?
>=20
> byte[] S =3D EC.DH(e, Q2);
> byte[] q1New =3D EC.PointAdd(Q1, Util.SingleSHA256(S));
> stealthTx.Vout.Add(TxOut.PayToPubKeyHash(Util.Amount(".995"), q1New);
> stealthTx.Vout.Add(TxOut.OpReturn(P));
Well like I said, you shouldn't force the txout to be exactly a 2-of-2
multisig - the recipient might be using a multi-factor wallet for
instance. So, if I understand your code, what you want is the following:
byte[] Q =3D <payee root pubkeys>;
byte[] Q_Scan =3D <may or may not be provided in Q>
int m =3D <# of pubkeys required to redeem>;
byte[] S =3D EC.DH(e, Q_Scan);
byte[] qDerived[];
for (int =3D 0; i < len(Q); i++){
qDerived[i] =3D EC.PointAdd(Q[i], Util.SingleSHA256(S || i));
}
// Best to have a single canonical order re: anonymity set.
qDerived =3D sorted(qDerived);
if (len(Q) > 1){
stealthTx.Vout.Add(TxOut.PayToMultiSig(amount, m, len(Q), qDerived));
} else {
stealthTx.Vout.Add(TxOut.PayToPubKeyHash(amount, qDerived[0]);
}
stealthTx.Vout.Add(TxOut.OpReturn(P));
Finally, it would probably be better if the multisig output was wrapped
in a P2SH output to better match the behavior of other wallets for the
sake of a bigger anonymity set - seems that stuff that is implementing
multifactor wallets and escrow is using P2SH to do it rather than bare
multisig. Also there's quite a bit of support for making bare multisig
not IsStandard() to discourage data-storage applications.
--=20
'peter'[:-1]@petertodd.org
00000000000000010c474cd4e25913535ec1c166b6d43fbdd9a5f2726711ced7
--BOKacYhQ+x31HxR3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJS1aKGAAoJEBmcgzuo5/CFfegIAKS4AB6/alcIhc18ALsjCC5A
QXjJeJ+GHAfhbS6sn+e0cRveAi7/UccS++N6rurZS7c7/gwW1sm17wpU9MEu4/q7
Bprd/ZWExqMGfpz8wW8qPk9dgd/lk+GzhFj65YW+raXggXWdAcEfpYjS6gGzjSZP
a7HG3SrcRMj+dOSV/POfAZrVRCHIZ00Ch5CxJ8ULqA+RU8juhpJTCdv54Fo5xojl
EAUNNa8lfx4JEmB4napqkYsgr4o39ayp+fd2oEVaH5IUQpKqw37EOFVB6tUd/9f1
o0cPQnT678fs6HB02A4CsxCvOGM2lIDmQUca2ExPgNVD+4KWN+rxt0aVfPA/FMM=
=7VUT
-----END PGP SIGNATURE-----
--BOKacYhQ+x31HxR3--