From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1W38Bk-0003XP-Gu for bitcoin-development@lists.sourceforge.net; Tue, 14 Jan 2014 17:54:08 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of riseup.net designates 198.252.153.129 as permitted sender) client-ip=198.252.153.129; envelope-from=odinn.cyberguerrilla@riseup.net; helo=mx1.riseup.net; Received: from mx1.riseup.net ([198.252.153.129]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1W38Bj-0004nI-A6 for bitcoin-development@lists.sourceforge.net; Tue, 14 Jan 2014 17:54:08 +0000 Received: from fulvetta.riseup.net (fulvetta-pn.riseup.net [10.0.1.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Gandi Standard SSL CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 63F6F50475; Tue, 14 Jan 2014 09:54:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: odinn.cyberguerrilla@fulvetta.riseup.net) with ESMTPSA id E7D9E18A Received: from localhost (127.0.0.1) (SquirrelMail authenticated user odinn.cyberguerrilla) by fulvetta.riseup.net with HTTP; Tue, 14 Jan 2014 09:54:01 -0800 Message-ID: <58e17f354c20e595f0cfeddfa47c2f3e.squirrel@fulvetta.riseup.net> In-Reply-To: <20140114141517.GA29950@savin> References: <20140106120338.GA14918@savin> <20140110102037.GB25749@savin> <20140114141517.GA29950@savin> Date: Tue, 14 Jan 2014 09:54:01 -0800 From: "Odinn Cyberguerrilla" To: bitcoin-development@lists.sourceforge.net User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.97.8 at mx1 X-Virus-Status: Clean Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [198.252.153.129 listed in list.dnswl.org] -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record -0.1 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines X-Headers-End: 1W38Bj-0004nI-A6 Subject: Re: [Bitcoin-development] Stealth Addresses 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: Tue, 14 Jan 2014 17:54:08 -0000 Hello Peter et. al. As I read more into this stealth discussion I am curious to know what you think of the background microdonation concept I posted recently. It is shown in full here http://sourceforge.net/mailarchive/message.php?msg_id=3D31837430 Given the lengthy nature of the concept as presented I would be happy to distill it further, but I am interested in your thoughts as to the idea generally and how to further present it. -Odinn > On Mon, Jan 13, 2014 at 01:13:08AM -0800, Jeremy Spilman wrote: >> It's a given this will be implemented for Payment Protocol. The questi= on >> is whether it's also usable outside of PP. > > I think what stealth addresses is showing is that the concept of an > address being "instructions on how to generate a txout/tx that results > in me getting Bitcoins" is actually quite valuable; it and > BIP32-derivation addresses with chaincodes are pretty clear cases where > just replacing address with scriptPubKey isn't sufficient. > >> I was kind of imagining that we could encourage people to replace all >> their static address text that live on Github pages, and README.me, an= d >> forum signatures, etc. with new 'href=3Dbitcoin:xSTL...' URIs. Convent= ion >> could be to require only transporting xSTL addresses within a URI, eve= n >> going so far as to not support them copy/pasted. 101 characters is not >> much longer (and sometimes shorter) than PaymentRequest URIs end up >> being. > > Yeah, I don't see anything wrong with stealth addresses whatever length > they wind up being. It's a good intermediate step, and without them > people will just pass around unsigned payment requests and other stuff. > >> I think there are ways to make stealth addresses easy enough to use th= at >> people actually prefer using them for P2P payments which do not involv= e >> a >> full-stack merchant. In that case, if it was a PaymentRequest it would >> almost certainly not be signed, and would be more easily shared over >> email >> or SMS as a URI than as a file attachment or, even worse, putting the >> unsigned PR file up on a third-party server which probably won't do a >> good >> job securing it. > > At the DarkWallet hackathon we had discussed how to integrate stealth > addresses into OpenPGP keys as a new user id type for instance, and > similarly into x.509 certs. > > The big advantage here is the identity of *who* you are paying is > important, not just "I got this signed payment request". Basically the > concept becomes "identity signed payment address" and the signature > binding the identity to the address is a one time and offline thing; an > issue with the payment protocol as it stands is that it encourages > signing keys to be kept online to issue payment requests. If you have a > scheme where the private keys that bound the identity to the address ca= n > be kept offline you're much better off, because the attacker can only > create a fake payment request, they can't divert the funds to > themselves. > > So with that in mind, I strongly suggest sticking with defining a > reasonable stealth address spec. But when you do, keep in mind that you > may want to upgrade it in the future, preferably in a backwards > compatible way. Also, it shouldn't be limited to exactly 2-of-2 > CHECKMULTISIG, there's no reason why n and m can't be picked as needed. > Sure, it means the addresses are not fixed length, but for something > that is mostly an internal detail and only occasionally visible to > advanced users, I see no issues there. > > Along those lines: what would a BIP32 chain code address look like? Wha= t > happens when you want to use that with a multisig-protected wallet? > >> * PP Implementation Overview * >> >> The basic PaymentRequest>PaymentDetails is expecting 'output' containi= ng >> one or more TxOuts with script and amount. I believe the general >> approach >> is to put a fallback address into 'output' for backward compatibility, >> and >> put Q and Q2 into an extension field. >> >> So we add a new optional field to PaymentDetails which contains the on= e >> or >> two PubKeys. Not sure if we want different protobuf tags, or if the >> difference in length of the value makes it obvious enough which approa= ch >> is being used; >> >> optional bytes stealthOnePubKey =3D 1000 >> optional bytes stealthTwoPubKey =3D 1001 > > I think you're missing the bigger picture here, not least of which is > that backwards compatibility is a bit of a misnomer for an unreleased > standard. :) > > Why put this into the PaymentDetails? That a stealth address is to be > used for the payment is a property of the outputs being requested, not > the payment itself. We're better off if that goes into the Output > message, and further more it suggests that the Output message shouldn't > contain raw scriptPubKey's but rather addresses. After all, IsStandard(= ) > means we have to inspect the scriptPubKey to see if we can even pay to > what the sender is requesting. > > Once you establish that it's addresses that Outputs specify, then it's > easy enough to make a stealth address type, or a BIP32-chain-code > address type, or whatever else comes up in the future. > > >> Also, ideally I think I would want multiple different stealth payments >> within a single wallet to the same merchant / pubkeys to be identifiab= le >> as such. > > Agreed. > > -- > 'peter'[:-1]@petertodd.org > 00000000bda8ab55740699711a11572c4eec9dc9f714e4896559aac310a115ff > -----------------------------------------------------------------------= ------- > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=3D119420431&iu=3D/4140/os= tg.clktrk_______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >