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; 
Message-ID: <58e17f354c20e595f0cfeddfa47c2f3e.squirrel@fulvetta.riseup.net>
In-Reply-To: <20140114141517.GA29950@savin>
References: <20140106120338.GA14918@savin>
	<op.w9c5o7vgyldrnw@laptop-air.hsd1.ca.comcast.net>
	<20140110102037.GB25749@savin>
	<op.w9kkxcityldrnw@laptop-air.hsd1.ca.comcast.net>
	<CANEZrP0Np_FGhw=m6OffijByzz9r4D2AA78jCkzh=NZh=xrbjQ@mail.gmail.com>
	<op.w9k6j4xryldrnw@laptop-air.hsd1.ca.comcast.net>
	<CANEZrP06EiiY+5hL05bxzdcFXS8V7S1KOiZj86a_ZP5EcoaMKA@mail.gmail.com>
	<op.w9mbv6dcyldrnw@laptop-air.hsd1.ca.comcast.net>
	<20140114141517.GA29950@savin>
Date: Tue, 14 Jan 2014 09:54:01 -0800
From: "Odinn Cyberguerrilla" <odinn.cyberguerrilla@riseup.net>
To: bitcoin-development@lists.sourceforge.net
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Importance: Normal
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Bitcoin-development] Stealth Addresses
Precedence: list

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
>