Re: [Bitcoin-development] Stealth Addresses

Re: [Bitcoin-development] Stealth Addresses

[joseph]

[-- Attachment #1: Type: text/plain, Size: 648 bytes --]

On naming, please allow consideration of "Confidential address".
Less conflation with "private key", connotes confidence, and as the address is known to the transacting parties, it is a precisely accurate name.
 
One of the use cases for these will be in multinational corporate internal international settlement.  For a company to use bitcoin for its internal settlement and maintain confidence that competitors will not be able to suss out its transactions, these confidential addresses will be of great use.
 
 
Stealth connotes stealing, theft, hiding, fear, sneakiness, stealth bombers.  Maybe it is a good name, but not the best name.

[-- Attachment #2: Type: text/html, Size: 750 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Dan Carter]

I think stealth addresses combined with zk-snarks would obviate the need 
for CoinJoin.  zk-snarks could be used to hide the coin's value and 
stealth addresses could be used to hide the recipient for payments and 
even mined coins.  More info on zero-knowledge snarks:

http://cs.tau.ac.il/~tromer/papers/vnsnark-20131230.pdf
http://cs.tau.ac.il/~tromer/papers/csnark-20131007.pdf

Start with a mined coin: generate a coin secret, create a coinbase 
transaction with an output to your stealth address and send 
hash(coin-secret + reward-value) + encrypt(coin-secret + reward-value) 
where only the recipient (you) can decrypt. (The reward value is known 
publicly but just assume it isn't here for generality). You also embed 
the 0.2KB zk-snark proof + 3KB verifying key that the hash result is in 
fact SHA256(coin-secret + reward-value), where your private witnesses 
are (coin-secret, reward-value).

Now you could split a coin into as many pieces as you want in a single 
transaction and send to multiple recipients, some pieces go to yourself 
(change) and others to the payee, every piece would have a different 
recipient address thanks to stealth addresses, and all values hidden 
thanks to zk-snarks.

So lets say you want to split the mined coin into two new ones.  You 
create a transaction where the input redeems the mined coin using mined 
tx out + your stealth address, and there are two new coins as outputs to 
your own stealth address each having: hash(new-coin-secret + 
new-hidden-value) + encrypt(new-coin-secret + new-hidden-value).  You 
also embed the zk-snark proof that the two new hidden values add up to 
the original hidden value, and that the two new hash results are in fact 
SHA256(new-coin-secret + new-hidden-value), where your private witnesses 
are (original-coin-secret, original-hidden-value, new-coin-secrets, 
new-hidden-values).

If you want to merge two coins into one it's just a split backwards, two 
inputs one output, zk-snark proof that two original hidden values add up 
to the new hidden value and that the new hash result is 
SHA256(new-coin-secret + new-hidden-value).

If you want to transfer ownership of a coin then just redeem at input, 
and output same as mined coin except using recipient stealth address 
(which is a public key) to encrypt(coin-secret + hidden-value).

- Dan



On 2014-01-06 4:03 AM, Peter Todd wrote:
> * Abstract
>
> A Stealth Address is a new type of Bitcoin address and related
> scriptPubKey/transaction generation scheme that allowers payees to
> publish a single, fixed, address that payors can send funds efficiently,
> privately, reliably and non-interactively. Payors do not learn what
> other payments have been made to the stealth address, and third-parties
> learn nothing at all. (both subject to an adjustable anonymity set)

Re: [Bitcoin-development] Stealth Addresses

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2098 bytes --]

On Sat, Jan 18, 2014 at 05:12:58PM -0600, Jeremy Spilman wrote:
> 
> 
> > On Fri, Jan 17, 2014 at 8:55 PM, Alan Reiner <etotheipi@gmail.com> wrote:
> >> Isn't there a much faster asymmetric scheme that we can use?  I've heard people talk about ed25519, though I'm not sure it can be used for encryption.
> > 
> > Doing ECDH with our curve is within a factor of ~2 of the fastest
> > encryption available at this security level, AFAIK.  And separate
> > encryption would ~double the amount of data vs using the ephemeral key
> > for derivation.
> > 
> > Using another cryptosystem would mandate carry around additional code
> > for a fast implementation of that cryptosystem, which wouldn't be
> > fantastic.
> > 
> > So I'm not sure much can be improved there.
> 
> In the case where payment is being sent only to Q1, and Q2 is for discovery only, perhaps we could use a 160-bit curve for d2/Q2 and e/P resulting in 20 byte vs 32 bytes in the OP_RETURN, and of course faster multiplication. 
> 
> 80-bits of security I assume still greatly exceeds the actual level of privacy you get with the overall solution, and since Q2 is never protecting actual funds...
> 
> But if it's a "real weakening" of the privacy then definitely not worth it, and even the added complexity of another curve seems possibly not worth it...

Keep in mind that Bitmessage uses the same ECDH mechanism as what
stealth addresses will use. They seem to get decent enough performance
from it for a use-case not-unlike that of a Bitcoin wallet.

In any case I'm interested in knowing actual performance numbers for it;
last I talked to Kyle Drake he said he was working on getting ECDH
numbers on Javascript, probably the slowest possible implementation of
the idea. As for send to stealth addresses using prefixes, he's
confirmed that you'll be able to do that will well under a second to
brute-force the prefixes with the proposed OP_RETURN mechanism even with
rather long 8-bit prefixes.

-- 
'peter'[:-1]@petertodd.org
000000000000000190a2900f1a25c507a999fa11116f7bd0126618c1ebc4f5fb

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Gregory Maxwell]

On Sat, Jan 18, 2014 at 3:12 PM, Jeremy Spilman <jeremy@taplink.co> wrote:
> In the case where payment is being sent only to Q1, and Q2 is for discovery only, perhaps we could use a 160-bit curve for d2/Q2 and e/P resulting in 20 byte vs 32 bytes in the OP_RETURN, and of course faster multiplication.
>
> 80-bits of security I assume still greatly exceeds the actual level of privacy you get with the overall solution, and since Q2 is never protecting actual funds...
>
> But if it's a "real weakening" of the privacy then definitely not worth it, and even the added complexity of another curve seems possibly not worth it...

Well super-fast hand optimized code for (your choice of) 160 bit curve
may not ever exist, making it slower in practice. Plus the extra code
to carry around even if it does exist…

Re: [Bitcoin-development] Stealth Addresses

[Jeremy Spilman]

> On Fri, Jan 17, 2014 at 8:55 PM, Alan Reiner <etotheipi@gmail.com> wrote:
>> Isn't there a much faster asymmetric scheme that we can use?  I've heard people talk about ed25519, though I'm not sure it can be used for encryption.
> 
> Doing ECDH with our curve is within a factor of ~2 of the fastest
> encryption available at this security level, AFAIK.  And separate
> encryption would ~double the amount of data vs using the ephemeral key
> for derivation.
> 
> Using another cryptosystem would mandate carry around additional code
> for a fast implementation of that cryptosystem, which wouldn't be
> fantastic.
> 
> So I'm not sure much can be improved there.

In the case where payment is being sent only to Q1, and Q2 is for discovery only, perhaps we could use a 160-bit curve for d2/Q2 and e/P resulting in 20 byte vs 32 bytes in the OP_RETURN, and of course faster multiplication. 

80-bits of security I assume still greatly exceeds the actual level of privacy you get with the overall solution, and since Q2 is never protecting actual funds...

But if it's a "real weakening" of the privacy then definitely not worth it, and even the added complexity of another curve seems possibly not worth it...

Re: [Bitcoin-development] Stealth Addresses

[Gregory Maxwell]

On Fri, Jan 17, 2014 at 8:55 PM, Alan Reiner <etotheipi@gmail.com> wrote:
> Isn't there a much faster asymmetric scheme that we can use?  I've heard people talk about ed25519, though I'm not sure it can be used for encryption.

Doing ECDH with our curve is within a factor of ~2 of the fastest
encryption available at this security level, AFAIK.  And separate
encryption would ~double the amount of data vs using the ephemeral key
for derivation.

Using another cryptosystem would mandate carry around additional code
for a fast implementation of that cryptosystem, which wouldn't be
fantastic.

So I'm not sure much can be improved there.

Re: [Bitcoin-development] Stealth Addresses

[Alan Reiner]

[-- Attachment #1: Type: text/plain, Size: 2625 bytes --]

*Avoiding ECDH calcs on every blockchain transaction (and avoiding the
prefix thing):*

Can we skip the whole ECDSA/ECDH thing, and use the second key pair for
encryption instead?  Then we don't need any ephemeral keys.  We use the
much simpler scheme like I mentioned before (just root keys and
multpliers), but instead of requesting a multiplier from the person
receiving the money, the payer can create their own multiplier and
encrypt it into an OP_RETURN msg (using the secondary public key of the
receiver).  When they do this, they append a deterministic identifier to
it, so that the receiver can immediately identify it upon decryption.

Basically, the receiver simply attempts decryption of every OP_RETURN
message, and if the identifier is there, they immediately know that the
tx is theirs, and that the other bytes of the decrypted message is the
multiplier used.

Of course, using something like ECIES and forcing the receiver to
attempt decryption of every OP_RETURN tx may not be any faster than the
ECDH we've already talked about here.  But with this, we are not tied to
any particular crypto.  Isn't there a much faster asymmetric scheme that
we can use?  I've heard people talk about ed25519, though I'm not sure
it can be used for encryption.  I'd bet money there is an asymmetric
_/encryption/_//algorithm that would be fast enough to not burden the
receiver.

Here's how I envision it:

--Alice gives out her business card that has public key X (BIP32 root),
and public key Y (fastCrypto)
--Bob generates a random 32-byte nonce, and EC-multiplies Alice's public
key by it.   He prepares a transaction sending coins to that address (Z)
--Bob also computes a deterministic identifier, perhaps hash(pubKeyX ||
addrZ)[8:].  Bob appends the those 8 bytes to the multiplier, and
encrypts all of it with Alice's fastCrypto key, Y.   He puts that
message in the OP_RETURN output.
--Alice's wallet will attempt decryption of every OP_RETURN message. 
First she computes hash(pubKeyX, addrZ)[8:], and then decrypts the
message with the fastCrypto private key.  If the tx is actually hers,
the last 8 bytes will match the identifier, and she knows to use the
other 32 bytes as a multiplier.  If it doesn't, it's irrelevant to her
and she moves on.

[**Should probably use 24-byte values for the multipliers (or hashes of
24-byte values), so that adding 8 bytes makes the whole message an even
32 bytes which is better for encryption]

Doesn't this have the exact same properties as the original proposal
(including compatibility with CoinJoin)?  But it all depends on having
fast asymmetric encryption.

-Alan




[-- Attachment #2: Type: text/html, Size: 3210 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Cameron Garnham]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

One of the possible words that haven't been proposed is 'personal' where
bitcoin addressed are commonly incorrectly called public address.

Maybe 'personal account' or even 'personal address' would imply that the
balance on such an account shouldn't be assumed to be public knowledge.

Cam.


On 17/01/2014 5:59 pm, Drak wrote:
> That could also work. Still, didn't we want to ditch the word address?
> Could be a privacy key...
> 
> On 17 Jan 2014 09:15, "Mike Hearn" <mike@plan99.net
> <mailto:mike@plan99.net>> wrote:
> 
>     I must say, this shed is mighty fine looking. It'd be a great place
>     to store our bikes. But, what colour should we paint it?
> 
>     How about we split the difference and go with "privacy address"? As
>     Peter notes, that's what people actually like and want. The problem
>     with stealth is it's got strong connotations with American military
>     hardware and perhaps thieves sneaking around in the night:
> 
>        https://www.google.com/search?tbm=isch&q=stealth
> 
>     But everyone loves privacy.
> 
> 
>     On Fri, Jan 17, 2014 at 8:49 AM, Drak <drak@zikula.org
>     <mailto:drak@zikula.org>> wrote:
> 
>         Peter I agree with you about  "reusable addresses", but aren't
>         we also trying to get away from the word "address" entirely?
>          How about calling it a "payment key" or "reusable payment key"
>         instead? using "stealth" is just asking for bad press imo.
> 
> 
>         On 16 January 2014 21:28, Peter Todd <pete@petertodd.org
>         <mailto:pete@petertodd.org>> wrote:
> 
>             On Wed, Jan 15, 2014 at 04:05:27PM -0800, Jeremy Spilman wrote:
>             > Might I propose "reusable address".
>             >
>             > I think that describes it best to any non-programmer, and
>             even more
>             > so encourages wallets to present options as 'one time use' vs
>             > 'reusable'.
>             >
>             > It definitely packs a marketing punch which could help drive
>             > adoption. The feature is only useful if/when broadly adopted.
> 
>             I'm very against the name "reusable addresses" and strongly
>             belive we
>             should stick with the name stealth addresses.
> 
>             You gotta look at it from the perspective of a user; lets
>             take standard
>             pay-to-pubkey-hash addresses: I can tell my wallet to pay
>             one as many
>             times as I want and everything works just great. I also can
>             enter the
>             address on blockchain.info <http://blockchain.info>'s search
>             box, and every transaction related
>             to the address, and the balance of it, pops up immediately.
> 
>             What is that telling me? A: Addresses starting with "1" are
>             reusable. B:
>             Transactions associated with them appear to be public knowledge.
> 
>             Now I upgrade my wallet software and it says I now have a
>             "reusable"
>             address. My reaction is "Huh? Normal addresses are reusable,
>             what's
>             special about this weird reusable address thing that my
>             buddy Bob's
>             wallet software couldn't pay." I might even try to enter in
>             a "reusable"
>             address in blockchain.info <http://blockchain.info>, which
>             won't work, and I'll just figure
>             "must be some new unsupported thing" and move on with my life.
> 
>             On the other hand, suppose my wallet says I now have
>             "stealth address"
>             support. I'm going to think "Huh, stealth? I guess that
>             means privacy
>             right? I like privacy." If I try searching for a stealth
>             address on
>             blockchain.info <http://blockchain.info>, when it doesn't
>             work I might think twig on "Oh right!
>             It said stealth addresses are private, so maybe the
>             transactions are
>             hidden?" I might also think "Maybe this is like
>             stealth/incognito mode
>             in my browser? So like, there's no history being kept for
>             others to
>             see?" Regardless, I'm going to be thinking "well I hear
>             scary stuff
>             about Bitcoin privacy, and this stealth thing sounds like
>             it's gonna
>             help, so I should learn more about that"
> 
>             Finally keep in mind that stealth addresses have had a tonne
>             of very
>             fast, and very wide reaching PR. The name is in the public
>             conciousness
>             already, and trying to change it now just because of vague bad
>             associations is going to throw away the momentum of that
>             good PR and
>             slow down adoption. Last night I was at the Toronto Bitcoin
>             Meetup and I
>             based on conversations there with people there, technical and
>             non-technical, almost everyone had heard about them and
>             almost everyone
>             seemed to understand the basic idea of why they were a good
>             thing. That
>             just wouldn't have happened with a name that tried to hide
>             what stealth
>             addresses were for, and by changing the name now we risk
>             people not
>             making the connection when wallet software gets upgraded to
>             support
>             them.
> 
>             --
>             'peter'[:-1]@petertodd.org <http://petertodd.org>
>             0000000000000001b0e0ae7ef97681ad77188030b6c791aef304947e6f524740
> 
>             ------------------------------------------------------------------------------
>             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=119420431&iu=/4140/ostg.clktrk
>             _______________________________________________
>             Bitcoin-development mailing list
>             Bitcoin-development@lists.sourceforge.net
>             <mailto:Bitcoin-development@lists.sourceforge.net>
>             https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> 
> 
>         ------------------------------------------------------------------------------
>         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=119420431&iu=/4140/ostg.clktrk
>         _______________________________________________
>         Bitcoin-development mailing list
>         Bitcoin-development@lists.sourceforge.net
>         <mailto:Bitcoin-development@lists.sourceforge.net>
>         https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> 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=119420431&iu=/4140/ostg.clktrk
> 
> 
> 
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREKAAYFAlLZj5cACgkQBJ8cMDO159YxKQEAh8QHHgMaL1IVvfYROU0yKG89
Ap1byTpAvt/+O5chTGQBAK4K+DfUOOkaMvUmssWIVsLQ56xKxsuzZiIJXF2yPI0g
=fcYD
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] Stealth Addresses

[Ben Davenport]

[-- Attachment #1: Type: text/plain, Size: 4027 bytes --]

Well, at least we don't have to worry about cache invalidation.

Ben


On Fri, Jan 17, 2014 at 6:46 AM, Peter Todd <pete@petertodd.org> wrote:

> On Fri, Jan 17, 2014 at 10:15:40AM +0100, Mike Hearn wrote:
> > I must say, this shed is mighty fine looking. It'd be a great place to
> > store our bikes. But, what colour should we paint it?
>
> I think we should paint it this colour:
>
>     They had uncovered what seemed to be the side of a large coloured
>     globule embedded in the substance. The colour, which resembled some
>     of the bands in the meteor's strange spectrum, was almost impossible
>     to describe; and it was only by analogy that they called it colour
>     at all.  Its texture was glossy, and upon tapping it appeared to
>     promise both brittle ness and hollowness. One of the professors gave
>     it a smart blow with a hammer, and it burst with a nervous little
>     pop. Nothing was emitted, and all trace of the thing vanished with
>     the puncturing. It left behind a hollow spherical space about three
>     inches across, and all thought it probable that others would be
>     discovered as the enclosing substance wasted away.
>
> I think it really gets to the core of my feelings about this naming
> discussion.
>
> > How about we split the difference and go with "privacy address"? As Peter
> > notes, that's what people actually like and want. The problem with
> stealth
> > is it's got strong connotations with American military hardware and
> perhaps
> > thieves sneaking around in the night:
> >
> >    https://www.google.com/search?tbm=isch&q=stealth
>
> WOW! AWESOME KICK-ASS PICS!
>
> Come to think of it, I could have called it "incognito addresses" - a
> term nice enough that Google and Firefox use it in their browsers - but
> what's done is done and any further discussion about this is just going
> to confuse the public. Remember that in the long run all this stuff will
> be hidden behind payment protocols anyway, and users *won't even know*
> that under the hood a stealth address is being used, making the name
> just a technical detail. For now though, lets use the good PR and get
> some early adopters on board.
>
> However, the term 'incognito' probably would be a good one to use within
> wallet software itself to describe what it's doing when the user clicks
> the "I want my transactions to be private" setting - there are after all
> fundemental bandwidth-privacy trade-offs in the threat model supposed by
> both prefix and bloom filters. In this instance the term isn't going to
> go away.
>
>
> Anyway, back to work: For the actual address format I strongly think we
> need to ensure that it can be upgrading in a backwards compatible way.
> This means we have to be able to add new fields - for instance if
> Gregory's ideas for different ways of doing the SPV-bait came to
> fruition. Given that "addresses" aren't something that should stay
> user-visible forever, thoughts on just making the actual data a protocol
> buffers object?
>
> Second question: Any performance figures yet on how efficient scanning
> the blockchain for matching transactions actually is? I'd like to get an
> idea soon for both desktop and smartphone wallets so we can figure out
> what kind of trade-offs users might be forced into in terms of prefix
> length.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000001c9b372ed519ecc6d41c10b42a7457d1ca5acd560a535596b
>
>
> ------------------------------------------------------------------------------
> 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=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 5220 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 3222 bytes --]

On Fri, Jan 17, 2014 at 10:15:40AM +0100, Mike Hearn wrote:
> I must say, this shed is mighty fine looking. It'd be a great place to
> store our bikes. But, what colour should we paint it?

I think we should paint it this colour:

    They had uncovered what seemed to be the side of a large coloured
    globule embedded in the substance. The colour, which resembled some
    of the bands in the meteor's strange spectrum, was almost impossible
    to describe; and it was only by analogy that they called it colour
    at all.  Its texture was glossy, and upon tapping it appeared to
    promise both brittle ness and hollowness. One of the professors gave
    it a smart blow with a hammer, and it burst with a nervous little
    pop. Nothing was emitted, and all trace of the thing vanished with
    the puncturing. It left behind a hollow spherical space about three
    inches across, and all thought it probable that others would be
    discovered as the enclosing substance wasted away.

I think it really gets to the core of my feelings about this naming
discussion.

> How about we split the difference and go with "privacy address"? As Peter
> notes, that's what people actually like and want. The problem with stealth
> is it's got strong connotations with American military hardware and perhaps
> thieves sneaking around in the night:
> 
>    https://www.google.com/search?tbm=isch&q=stealth

WOW! AWESOME KICK-ASS PICS!

Come to think of it, I could have called it "incognito addresses" - a
term nice enough that Google and Firefox use it in their browsers - but
what's done is done and any further discussion about this is just going
to confuse the public. Remember that in the long run all this stuff will
be hidden behind payment protocols anyway, and users *won't even know*
that under the hood a stealth address is being used, making the name
just a technical detail. For now though, lets use the good PR and get
some early adopters on board.

However, the term 'incognito' probably would be a good one to use within
wallet software itself to describe what it's doing when the user clicks
the "I want my transactions to be private" setting - there are after all
fundemental bandwidth-privacy trade-offs in the threat model supposed by
both prefix and bloom filters. In this instance the term isn't going to
go away.


Anyway, back to work: For the actual address format I strongly think we
need to ensure that it can be upgrading in a backwards compatible way.
This means we have to be able to add new fields - for instance if
Gregory's ideas for different ways of doing the SPV-bait came to
fruition. Given that "addresses" aren't something that should stay
user-visible forever, thoughts on just making the actual data a protocol
buffers object?

Second question: Any performance figures yet on how efficient scanning
the blockchain for matching transactions actually is? I'd like to get an
idea soon for both desktop and smartphone wallets so we can figure out
what kind of trade-offs users might be forced into in terms of prefix
length.

-- 
'peter'[:-1]@petertodd.org
0000000000000001c9b372ed519ecc6d41c10b42a7457d1ca5acd560a535596b

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Drak]

[-- Attachment #1: Type: text/plain, Size: 5451 bytes --]

That could also work. Still, didn't we want to ditch the word address?
Could be a privacy key...
On 17 Jan 2014 09:15, "Mike Hearn" <mike@plan99.net> wrote:

> I must say, this shed is mighty fine looking. It'd be a great place to
> store our bikes. But, what colour should we paint it?
>
> How about we split the difference and go with "privacy address"? As Peter
> notes, that's what people actually like and want. The problem with stealth
> is it's got strong connotations with American military hardware and perhaps
> thieves sneaking around in the night:
>
>    https://www.google.com/search?tbm=isch&q=stealth
>
> But everyone loves privacy.
>
>
> On Fri, Jan 17, 2014 at 8:49 AM, Drak <drak@zikula.org> wrote:
>
>> Peter I agree with you about  "reusable addresses", but aren't we also
>> trying to get away from the word "address" entirely?  How about calling it
>> a "payment key" or "reusable payment key" instead? using "stealth" is just
>> asking for bad press imo.
>>
>>
>> On 16 January 2014 21:28, Peter Todd <pete@petertodd.org> wrote:
>>
>>> On Wed, Jan 15, 2014 at 04:05:27PM -0800, Jeremy Spilman wrote:
>>> > Might I propose "reusable address".
>>> >
>>> > I think that describes it best to any non-programmer, and even more
>>> > so encourages wallets to present options as 'one time use' vs
>>> > 'reusable'.
>>> >
>>> > It definitely packs a marketing punch which could help drive
>>> > adoption. The feature is only useful if/when broadly adopted.
>>>
>>> I'm very against the name "reusable addresses" and strongly belive we
>>> should stick with the name stealth addresses.
>>>
>>> You gotta look at it from the perspective of a user; lets take standard
>>> pay-to-pubkey-hash addresses: I can tell my wallet to pay one as many
>>> times as I want and everything works just great. I also can enter the
>>> address on blockchain.info's search box, and every transaction related
>>> to the address, and the balance of it, pops up immediately.
>>>
>>> What is that telling me? A: Addresses starting with "1" are reusable. B:
>>> Transactions associated with them appear to be public knowledge.
>>>
>>> Now I upgrade my wallet software and it says I now have a "reusable"
>>> address. My reaction is "Huh? Normal addresses are reusable, what's
>>> special about this weird reusable address thing that my buddy Bob's
>>> wallet software couldn't pay." I might even try to enter in a "reusable"
>>> address in blockchain.info, which won't work, and I'll just figure
>>> "must be some new unsupported thing" and move on with my life.
>>>
>>> On the other hand, suppose my wallet says I now have "stealth address"
>>> support. I'm going to think "Huh, stealth? I guess that means privacy
>>> right? I like privacy." If I try searching for a stealth address on
>>> blockchain.info, when it doesn't work I might think twig on "Oh right!
>>> It said stealth addresses are private, so maybe the transactions are
>>> hidden?" I might also think "Maybe this is like stealth/incognito mode
>>> in my browser? So like, there's no history being kept for others to
>>> see?" Regardless, I'm going to be thinking "well I hear scary stuff
>>> about Bitcoin privacy, and this stealth thing sounds like it's gonna
>>> help, so I should learn more about that"
>>>
>>> Finally keep in mind that stealth addresses have had a tonne of very
>>> fast, and very wide reaching PR. The name is in the public conciousness
>>> already, and trying to change it now just because of vague bad
>>> associations is going to throw away the momentum of that good PR and
>>> slow down adoption. Last night I was at the Toronto Bitcoin Meetup and I
>>> based on conversations there with people there, technical and
>>> non-technical, almost everyone had heard about them and almost everyone
>>> seemed to understand the basic idea of why they were a good thing. That
>>> just wouldn't have happened with a name that tried to hide what stealth
>>> addresses were for, and by changing the name now we risk people not
>>> making the connection when wallet software gets upgraded to support
>>> them.
>>>
>>> --
>>> 'peter'[:-1]@petertodd.org
>>> 0000000000000001b0e0ae7ef97681ad77188030b6c791aef304947e6f524740
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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=119420431&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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=119420431&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 7726 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Natanael]

[-- Attachment #1: Type: text/plain, Size: 6179 bytes --]

So far I've only liked the original name "Stealth address" and the
suggestion "routing address".

Should we put this up for some kind of informal vote with comments allowed?
Like a Google docs form?

- Sent from my phone
Den 17 jan 2014 10:18 skrev "Mike Hearn" <mike@plan99.net>:

> I must say, this shed is mighty fine looking. It'd be a great place to
> store our bikes. But, what colour should we paint it?
>
> How about we split the difference and go with "privacy address"? As Peter
> notes, that's what people actually like and want. The problem with stealth
> is it's got strong connotations with American military hardware and perhaps
> thieves sneaking around in the night:
>
>    https://www.google.com/search?tbm=isch&q=stealth
>
> But everyone loves privacy.
>
>
> On Fri, Jan 17, 2014 at 8:49 AM, Drak <drak@zikula.org> wrote:
>
>> Peter I agree with you about  "reusable addresses", but aren't we also
>> trying to get away from the word "address" entirely?  How about calling it
>> a "payment key" or "reusable payment key" instead? using "stealth" is just
>> asking for bad press imo.
>>
>>
>> On 16 January 2014 21:28, Peter Todd <pete@petertodd.org> wrote:
>>
>>> On Wed, Jan 15, 2014 at 04:05:27PM -0800, Jeremy Spilman wrote:
>>> > Might I propose "reusable address".
>>> >
>>> > I think that describes it best to any non-programmer, and even more
>>> > so encourages wallets to present options as 'one time use' vs
>>> > 'reusable'.
>>> >
>>> > It definitely packs a marketing punch which could help drive
>>> > adoption. The feature is only useful if/when broadly adopted.
>>>
>>> I'm very against the name "reusable addresses" and strongly belive we
>>> should stick with the name stealth addresses.
>>>
>>> You gotta look at it from the perspective of a user; lets take standard
>>> pay-to-pubkey-hash addresses: I can tell my wallet to pay one as many
>>> times as I want and everything works just great. I also can enter the
>>> address on blockchain.info's search box, and every transaction related
>>> to the address, and the balance of it, pops up immediately.
>>>
>>> What is that telling me? A: Addresses starting with "1" are reusable. B:
>>> Transactions associated with them appear to be public knowledge.
>>>
>>> Now I upgrade my wallet software and it says I now have a "reusable"
>>> address. My reaction is "Huh? Normal addresses are reusable, what's
>>> special about this weird reusable address thing that my buddy Bob's
>>> wallet software couldn't pay." I might even try to enter in a "reusable"
>>> address in blockchain.info, which won't work, and I'll just figure
>>> "must be some new unsupported thing" and move on with my life.
>>>
>>> On the other hand, suppose my wallet says I now have "stealth address"
>>> support. I'm going to think "Huh, stealth? I guess that means privacy
>>> right? I like privacy." If I try searching for a stealth address on
>>> blockchain.info, when it doesn't work I might think twig on "Oh right!
>>> It said stealth addresses are private, so maybe the transactions are
>>> hidden?" I might also think "Maybe this is like stealth/incognito mode
>>> in my browser? So like, there's no history being kept for others to
>>> see?" Regardless, I'm going to be thinking "well I hear scary stuff
>>> about Bitcoin privacy, and this stealth thing sounds like it's gonna
>>> help, so I should learn more about that"
>>>
>>> Finally keep in mind that stealth addresses have had a tonne of very
>>> fast, and very wide reaching PR. The name is in the public conciousness
>>> already, and trying to change it now just because of vague bad
>>> associations is going to throw away the momentum of that good PR and
>>> slow down adoption. Last night I was at the Toronto Bitcoin Meetup and I
>>> based on conversations there with people there, technical and
>>> non-technical, almost everyone had heard about them and almost everyone
>>> seemed to understand the basic idea of why they were a good thing. That
>>> just wouldn't have happened with a name that tried to hide what stealth
>>> addresses were for, and by changing the name now we risk people not
>>> making the connection when wallet software gets upgraded to support
>>> them.
>>>
>>> --
>>> 'peter'[:-1]@petertodd.org
>>> 0000000000000001b0e0ae7ef97681ad77188030b6c791aef304947e6f524740
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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=119420431&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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=119420431&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
> 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=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 8817 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Mark Friedenbach]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/17/2014 01:15 AM, Mike Hearn wrote:
> I must say, this shed is mighty fine looking. It'd be a great place
> to store our bikes. But, what colour should we paint it?
> 
> How about we split the difference and go with "privacy address"?
> As

Too close to private key, IMHO.

> Peter notes, that's what people actually like and want. The problem
> with stealth is it's got strong connotations with American military
> hardware and perhaps thieves sneaking around in the night:

And ninjas.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS2PWHAAoJEAdzVfsmodw4QKoP/iCB62bthf+VyOAZFtP/LbU3
op//I06zOd6oj3zSM0B3Qwz0+H3L9OqWeo9yP1KzYb8YG7RelGf6KOh0LBQoo0bY
eEv8EqvJiW0JOi7gmMsaBgxtZ99TKibGVWMramAV+pSOkKbbbQ23O8a3Y2uopZIg
eypB9sUO9STTc/vwEKZRtefoXHWDUF8bXel/YfTGJQjOuxN/z6gsXRPp4xDvySL3
Ll3OvgEGrqIjIodvMZY+V5wzxj/TlU5kCKS6Vug/JEM1U0DmiBBikaR6Yus5m/fC
yyxEQH8jATLZVsAac4Z16rQXj1nTRh4w6X9KCTynEaba5Z8fz38habUNxyjT8JG+
cP+QDQac9Nnxuw6gzM4QRkOiQas5eVNRdzNJ48k2SGDLb7AYPBO/URAV8Cd05caY
Gx1ruC3MVGu7Fu1/9rtKeWMcNyAvpklzs9DhHfqNmYcRCl6NcoaCvxfq3NesI4Z9
uQrTfL9VBUXJJ2z8ZLe3ZAdBz46159JXCBKHIWwZ+fm0uPkelvoUo8oP+OdxwP1x
wGCYmfvuf8lSnud8WM5EDDGo4+7GUU5Pnh9p+o6Lyp4d0WoplUmSvz2XriiANQjq
z/Xo3B321sdLOEI/Nrqnn3S/hMveru7HO7xQx1aUATvYga4ZyFZh/Yp0bwOAESBZ
GoG0piwQbQhoQZMslV4T
=40o3
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] Stealth Addresses

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 5173 bytes --]

I must say, this shed is mighty fine looking. It'd be a great place to
store our bikes. But, what colour should we paint it?

How about we split the difference and go with "privacy address"? As Peter
notes, that's what people actually like and want. The problem with stealth
is it's got strong connotations with American military hardware and perhaps
thieves sneaking around in the night:

   https://www.google.com/search?tbm=isch&q=stealth

But everyone loves privacy.


On Fri, Jan 17, 2014 at 8:49 AM, Drak <drak@zikula.org> wrote:

> Peter I agree with you about  "reusable addresses", but aren't we also
> trying to get away from the word "address" entirely?  How about calling it
> a "payment key" or "reusable payment key" instead? using "stealth" is just
> asking for bad press imo.
>
>
> On 16 January 2014 21:28, Peter Todd <pete@petertodd.org> wrote:
>
>> On Wed, Jan 15, 2014 at 04:05:27PM -0800, Jeremy Spilman wrote:
>> > Might I propose "reusable address".
>> >
>> > I think that describes it best to any non-programmer, and even more
>> > so encourages wallets to present options as 'one time use' vs
>> > 'reusable'.
>> >
>> > It definitely packs a marketing punch which could help drive
>> > adoption. The feature is only useful if/when broadly adopted.
>>
>> I'm very against the name "reusable addresses" and strongly belive we
>> should stick with the name stealth addresses.
>>
>> You gotta look at it from the perspective of a user; lets take standard
>> pay-to-pubkey-hash addresses: I can tell my wallet to pay one as many
>> times as I want and everything works just great. I also can enter the
>> address on blockchain.info's search box, and every transaction related
>> to the address, and the balance of it, pops up immediately.
>>
>> What is that telling me? A: Addresses starting with "1" are reusable. B:
>> Transactions associated with them appear to be public knowledge.
>>
>> Now I upgrade my wallet software and it says I now have a "reusable"
>> address. My reaction is "Huh? Normal addresses are reusable, what's
>> special about this weird reusable address thing that my buddy Bob's
>> wallet software couldn't pay." I might even try to enter in a "reusable"
>> address in blockchain.info, which won't work, and I'll just figure
>> "must be some new unsupported thing" and move on with my life.
>>
>> On the other hand, suppose my wallet says I now have "stealth address"
>> support. I'm going to think "Huh, stealth? I guess that means privacy
>> right? I like privacy." If I try searching for a stealth address on
>> blockchain.info, when it doesn't work I might think twig on "Oh right!
>> It said stealth addresses are private, so maybe the transactions are
>> hidden?" I might also think "Maybe this is like stealth/incognito mode
>> in my browser? So like, there's no history being kept for others to
>> see?" Regardless, I'm going to be thinking "well I hear scary stuff
>> about Bitcoin privacy, and this stealth thing sounds like it's gonna
>> help, so I should learn more about that"
>>
>> Finally keep in mind that stealth addresses have had a tonne of very
>> fast, and very wide reaching PR. The name is in the public conciousness
>> already, and trying to change it now just because of vague bad
>> associations is going to throw away the momentum of that good PR and
>> slow down adoption. Last night I was at the Toronto Bitcoin Meetup and I
>> based on conversations there with people there, technical and
>> non-technical, almost everyone had heard about them and almost everyone
>> seemed to understand the basic idea of why they were a good thing. That
>> just wouldn't have happened with a name that tried to hide what stealth
>> addresses were for, and by changing the name now we risk people not
>> making the connection when wallet software gets upgraded to support
>> them.
>>
>> --
>> 'peter'[:-1]@petertodd.org
>> 0000000000000001b0e0ae7ef97681ad77188030b6c791aef304947e6f524740
>>
>>
>> ------------------------------------------------------------------------------
>> 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=119420431&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
> 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=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 7309 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Drak]

[-- Attachment #1: Type: text/plain, Size: 3946 bytes --]

Peter I agree with you about  "reusable addresses", but aren't we also
trying to get away from the word "address" entirely?  How about calling it
a "payment key" or "reusable payment key" instead? using "stealth" is just
asking for bad press imo.


On 16 January 2014 21:28, Peter Todd <pete@petertodd.org> wrote:

> On Wed, Jan 15, 2014 at 04:05:27PM -0800, Jeremy Spilman wrote:
> > Might I propose "reusable address".
> >
> > I think that describes it best to any non-programmer, and even more
> > so encourages wallets to present options as 'one time use' vs
> > 'reusable'.
> >
> > It definitely packs a marketing punch which could help drive
> > adoption. The feature is only useful if/when broadly adopted.
>
> I'm very against the name "reusable addresses" and strongly belive we
> should stick with the name stealth addresses.
>
> You gotta look at it from the perspective of a user; lets take standard
> pay-to-pubkey-hash addresses: I can tell my wallet to pay one as many
> times as I want and everything works just great. I also can enter the
> address on blockchain.info's search box, and every transaction related
> to the address, and the balance of it, pops up immediately.
>
> What is that telling me? A: Addresses starting with "1" are reusable. B:
> Transactions associated with them appear to be public knowledge.
>
> Now I upgrade my wallet software and it says I now have a "reusable"
> address. My reaction is "Huh? Normal addresses are reusable, what's
> special about this weird reusable address thing that my buddy Bob's
> wallet software couldn't pay." I might even try to enter in a "reusable"
> address in blockchain.info, which won't work, and I'll just figure
> "must be some new unsupported thing" and move on with my life.
>
> On the other hand, suppose my wallet says I now have "stealth address"
> support. I'm going to think "Huh, stealth? I guess that means privacy
> right? I like privacy." If I try searching for a stealth address on
> blockchain.info, when it doesn't work I might think twig on "Oh right!
> It said stealth addresses are private, so maybe the transactions are
> hidden?" I might also think "Maybe this is like stealth/incognito mode
> in my browser? So like, there's no history being kept for others to
> see?" Regardless, I'm going to be thinking "well I hear scary stuff
> about Bitcoin privacy, and this stealth thing sounds like it's gonna
> help, so I should learn more about that"
>
> Finally keep in mind that stealth addresses have had a tonne of very
> fast, and very wide reaching PR. The name is in the public conciousness
> already, and trying to change it now just because of vague bad
> associations is going to throw away the momentum of that good PR and
> slow down adoption. Last night I was at the Toronto Bitcoin Meetup and I
> based on conversations there with people there, technical and
> non-technical, almost everyone had heard about them and almost everyone
> seemed to understand the basic idea of why they were a good thing. That
> just wouldn't have happened with a name that tried to hide what stealth
> addresses were for, and by changing the name now we risk people not
> making the connection when wallet software gets upgraded to support
> them.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000001b0e0ae7ef97681ad77188030b6c791aef304947e6f524740
>
>
> ------------------------------------------------------------------------------
> 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=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 5297 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Jeremy Spilman]

I hear you, and I really don't care that much what it's called, as much as, does it work and how!

> I might even try to enter in a "reusable" address in blockchain.info, which won't work, and I'll just figure
> "must be some new unsupported thing" and move on with my life.
> 

Regardless of what it's called, Blockchain.info should tell the user, hey this address doesn't let the whole world see every single payment that's made to it! If you paid something to this address, only you know how to find the payment - look for the stealth address in your transaction list. 

So if we call the address that has the pubKeys the "reusable address" and the address that's generated from the shared secret the "stealth address" then is everyone happy? :-)

Re: [Bitcoin-development] Stealth Addresses

[Johnathan Corgan]

[-- Attachment #1.1: Type: text/plain, Size: 638 bytes --]

On 01/16/2014 01:28 PM, Peter Todd wrote:

> I'm very against the name "reusable addresses" and strongly belive we
> should stick with the name stealth addresses.

I agree wholeheartedly against using "reusable address".  I personally
am fine with "stealth address", but can see where there might be a
negative connotation.

Might I suggest "master address", which is neutral in connotation, but
indicates both that it is fixed and that payment addresses are generated
as needed from it.

But please, no "reusable address."

-- 
Johnathan Corgan, Corgan Labs
SDR Training and Development Services
http://corganlabs.com

[-- Attachment #1.2: johnathan.vcf --]
[-- Type: text/x-vcard, Size: 335 bytes --]

begin:vcard
fn:Johnathan Corgan
n:Corgan;Johnathan
org:Corgan Enterprises LLC dba Corgan Labs
adr:;;6081 Meridian Ave. Suite 70-111;San Jose;CA;95120;United States
email;internet:johnathan@corganlabs.com
title:Managing Partner
tel;work:+1 408 463 6614
x-mozilla-html:FALSE
url:http://corganlabs.com
version:2.1
end:vcard


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2979 bytes --]

On Wed, Jan 15, 2014 at 04:05:27PM -0800, Jeremy Spilman wrote:
> Might I propose "reusable address".
> 
> I think that describes it best to any non-programmer, and even more
> so encourages wallets to present options as 'one time use' vs
> 'reusable'.
> 
> It definitely packs a marketing punch which could help drive
> adoption. The feature is only useful if/when broadly adopted.

I'm very against the name "reusable addresses" and strongly belive we
should stick with the name stealth addresses.

You gotta look at it from the perspective of a user; lets take standard
pay-to-pubkey-hash addresses: I can tell my wallet to pay one as many
times as I want and everything works just great. I also can enter the
address on blockchain.info's search box, and every transaction related
to the address, and the balance of it, pops up immediately.

What is that telling me? A: Addresses starting with "1" are reusable. B:
Transactions associated with them appear to be public knowledge.

Now I upgrade my wallet software and it says I now have a "reusable"
address. My reaction is "Huh? Normal addresses are reusable, what's
special about this weird reusable address thing that my buddy Bob's
wallet software couldn't pay." I might even try to enter in a "reusable"
address in blockchain.info, which won't work, and I'll just figure
"must be some new unsupported thing" and move on with my life.

On the other hand, suppose my wallet says I now have "stealth address"
support. I'm going to think "Huh, stealth? I guess that means privacy
right? I like privacy." If I try searching for a stealth address on
blockchain.info, when it doesn't work I might think twig on "Oh right!
It said stealth addresses are private, so maybe the transactions are
hidden?" I might also think "Maybe this is like stealth/incognito mode
in my browser? So like, there's no history being kept for others to
see?" Regardless, I'm going to be thinking "well I hear scary stuff
about Bitcoin privacy, and this stealth thing sounds like it's gonna
help, so I should learn more about that"

Finally keep in mind that stealth addresses have had a tonne of very
fast, and very wide reaching PR. The name is in the public conciousness
already, and trying to change it now just because of vague bad
associations is going to throw away the momentum of that good PR and
slow down adoption. Last night I was at the Toronto Bitcoin Meetup and I
based on conversations there with people there, technical and
non-technical, almost everyone had heard about them and almost everyone
seemed to understand the basic idea of why they were a good thing. That
just wouldn't have happened with a name that tried to hide what stealth
addresses were for, and by changing the name now we risk people not
making the connection when wallet software gets upgraded to support
them.

-- 
'peter'[:-1]@petertodd.org
0000000000000001b0e0ae7ef97681ad77188030b6c791aef304947e6f524740

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1447 bytes --]

I think we have a winner in "reusable address". Yes an existing address can
be reused and will superficially appear to work, it just won't work well.
Calling them reusable addresses helps reinforce the idea in peoples mind
that the other kind shouldn't be reused.


On Thu, Jan 16, 2014 at 11:14 AM, Drak <drak@zikula.org> wrote:

> On 16 January 2014 00:05, Jeremy Spilman <jeremy@taplink.co> wrote:
>
>>  Might I propose "reusable address".
>>
>> I think that describes it best to any non-programmer, and even more so
>> encourages wallets to present options as 'one time use' vs 'reusable'.
>>
>
> The problem is all addresses are reusable and to an average user,
> addresses are already reusable so there is little to distinguish the
> address format.
> It might be better to call it a "public address" in common terminology.
>
> Drak
>
>
>
> ------------------------------------------------------------------------------
> 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=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 2630 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Drak]

[-- Attachment #1: Type: text/plain, Size: 488 bytes --]

On 16 January 2014 00:05, Jeremy Spilman <jeremy@taplink.co> wrote:

>  Might I propose "reusable address".
>
> I think that describes it best to any non-programmer, and even more so
> encourages wallets to present options as 'one time use' vs 'reusable'.
>

The problem is all addresses are reusable and to an average user, addresses
are already reusable so there is little to distinguish the address format.
It might be better to call it a "public address" in common terminology.

Drak

[-- Attachment #2: Type: text/html, Size: 988 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Wladimir]

[-- Attachment #1: Type: text/plain, Size: 344 bytes --]

On Thu, Jan 16, 2014 at 7:26 AM, Gary Rowe <g.rowe@froot.co.uk> wrote:

> I like "reusable address".
>

Simple and clear, I like it too.

I see the term is routing is used in finance in the USA, but as a Dutch
person I associate "routing address" with network routing, not with
banking. It's non-trivial to translate to a local term.

Wladimir

[-- Attachment #2: Type: text/html, Size: 770 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Gary Rowe]

[-- Attachment #1: Type: text/plain, Size: 3693 bytes --]

I like "reusable address".

It is very clear what the intended purpose is and gives a subtle hint that
other types of address should not be re-used.



On 16 January 2014 00:44, Eric Martindale <eric@ericmartindale.com> wrote:

> One variation of this, "recycled address", might avert misconceptions that
> the "re-use" is exclusive to one's own identity.
>
>
> Eric Martindale, relentless maker.
> http://www.ericmartindale.com
> +1 (919) 374-2020 | *BitMessage: *BM-2cWCmYBpV64FRSJpHHKWi1Cfc9W52jydwe
> *Note:* Beginning December 11th, 2013, I will only be intermittently
> available via email, SMS, and BitMessage.  As a courtesy, please leave a
> detailed message so that I can respond in kind.  Thanks!
>
>
> On Wed, Jan 15, 2014 at 7:05 PM, Jeremy Spilman <jeremy@taplink.co> wrote:
>
>>  Might I propose "reusable address".
>>
>> I think that describes it best to any non-programmer, and even more so
>> encourages wallets to present options as 'one time use' vs 'reusable'.
>>
>> It definitely packs a marketing punch which could help drive adoption.
>> The feature is only useful if/when broadly adopted.
>>
>> I think it meets all the criteria required:
>>
>>   - Communication between parties is a single message from the payee,
>> which may be public
>>   - Multiple payments to the same address are not publicly linkable on
>> the blockchain
>>   - The payee has explicitly designated they expect to receive more than
>> one payment at that address
>>   - Payer can publicly prove they made a payment to the reusable address
>> by revealing a secret
>>
>> I have high hopes for this feature. The war *against* address reuse may
>> soon be a distant memory.
>>
>> On Wed, 15 Jan 2014 12:44:17 -0800, Jeff Garzik <jgarzik@bitpay.com>
>> wrote:
>>
>> "static address" seems like a reasonable attempt at describing intended
>> use/direction.
>>
>> On Wed, Jan 15, 2014 at 3:38 PM, Gregory Maxwell <gmaxwell@gmail.com>wrote:
>>
>>> On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport <bendavenport@gmail.com>
>>> wrote:
>>> > But may I suggest we consider changing the name "stealth address" to
>>> > something more neutral?
>>>
>>> ACK.  Regardless of the 'political' overtones, I think stealth is a
>>> little cringe-worthy.
>>>
>>> "Private address" would be fine if not for confusion with private-keys.
>>>
>>> "Static address" is perhaps the best in my view. (also helps improve
>>>  awareness that normal addresses are intended to be more one-use-ness)
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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=119420431&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
> 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=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 6318 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Odinn Cyberguerrilla]

Yes. Good idea(s).

> Might I propose "reusable address".
>
> I think that describes it best to any non-programmer, and even more so
> encourages wallets to present options as 'one time use' vs 'reusable'.
>
> It definitely packs a marketing punch which could help drive adoption. The
> feature is only useful if/when broadly adopted.
>
> I think it meets all the criteria required:
>
>    - Communication between parties is a single message from the payee,
> which may be public
>    - Multiple payments to the same address are not publicly linkable on
> the
> blockchain
>    - The payee has explicitly designated they expect to receive more than
> one payment at that address
>    - Payer can publicly prove they made a payment to the reusable address
> by revealing a secret
>
> I have high hopes for this feature. The war *against* address reuse may
> soon be a distant memory.
>
> On Wed, 15 Jan 2014 12:44:17 -0800, Jeff Garzik <jgarzik@bitpay.com>
> wrote:
>> "static address" seems like a reasonable attempt at describing intended
>> use/direction.
>>
>> On Wed, Jan 15, 2014 at 3:38 PM, Gregory Maxwell <gmaxwell@gmail.com>
>> wrote:
>>> On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport
>>> <bendavenport@gmail.com> wrote:
>>>> But may I suggest we consider changing the name "stealth address" to
>>>> something more neutral?
>>>
>>> ACK.  Regardless of the 'political' overtones, I think stealth is a
>>> little cringe-worthy.
>>>
>>> "Private address" would be fine if not for confusion with private-keys.
>>>
>>> "Static address" is perhaps the best in my view. (also helps improve
>>> awareness that normal addresses are intended to be more
>>> one-use-ness)------------------------------------------------------------------------------
> 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=119420431&iu=/4140/ostg.clktrk_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

Re: [Bitcoin-development] Stealth Addresses

[Eric Martindale]

[-- Attachment #1: Type: text/plain, Size: 2778 bytes --]

One variation of this, "recycled address", might avert misconceptions that
the "re-use" is exclusive to one's own identity.


Eric Martindale, relentless maker.
http://www.ericmartindale.com
+1 (919) 374-2020 | *BitMessage: *BM-2cWCmYBpV64FRSJpHHKWi1Cfc9W52jydwe
*Note:* Beginning December 11th, 2013, I will only be intermittently
available via email, SMS, and BitMessage.  As a courtesy, please leave a
detailed message so that I can respond in kind.  Thanks!


On Wed, Jan 15, 2014 at 7:05 PM, Jeremy Spilman <jeremy@taplink.co> wrote:

>  Might I propose "reusable address".
>
> I think that describes it best to any non-programmer, and even more so
> encourages wallets to present options as 'one time use' vs 'reusable'.
>
> It definitely packs a marketing punch which could help drive adoption. The
> feature is only useful if/when broadly adopted.
>
> I think it meets all the criteria required:
>
>   - Communication between parties is a single message from the payee,
> which may be public
>   - Multiple payments to the same address are not publicly linkable on the
> blockchain
>   - The payee has explicitly designated they expect to receive more than
> one payment at that address
>   - Payer can publicly prove they made a payment to the reusable address
> by revealing a secret
>
> I have high hopes for this feature. The war *against* address reuse may
> soon be a distant memory.
>
> On Wed, 15 Jan 2014 12:44:17 -0800, Jeff Garzik <jgarzik@bitpay.com>
> wrote:
>
> "static address" seems like a reasonable attempt at describing intended
> use/direction.
>
> On Wed, Jan 15, 2014 at 3:38 PM, Gregory Maxwell <gmaxwell@gmail.com>wrote:
>
>> On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport <bendavenport@gmail.com>
>> wrote:
>> > But may I suggest we consider changing the name "stealth address" to
>> > something more neutral?
>>
>> ACK.  Regardless of the 'political' overtones, I think stealth is a
>> little cringe-worthy.
>>
>> "Private address" would be fine if not for confusion with private-keys.
>>
>> "Static address" is perhaps the best in my view. (also helps improve
>>  awareness that normal addresses are intended to be more one-use-ness)
>
>
>
> ------------------------------------------------------------------------------
> 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=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 4621 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Mark Friedenbach]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/15/2014 04:05 PM, Jeremy Spilman wrote:
> Might I propose "reusable address".

Say it like it is. This is the only suggestion so far that I really like.

No amount of finger wagging got people to stop using the block chain
for data storage, but news of the OP_RETURN change to relay rules in
0.9 got people to at least be less damaging in how they do it.

Having an officially named "reusable address" format won't stop people
from doing dumb things (e.g. vanity addresses), but at least maybe
they'll stop using traditional addresses for it.

Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS1yafAAoJEAdzVfsmodw40ccQAI0EFAyODzx7yXvlq9idctSd
xisH4xsOMlsW4lV7xReMnhQsCZ5A+qTMcCd7n7a0bveAxWg1srqBDONLXtHZfwiN
Px/TfoJKPt1oIHnCoyN8G6pcuHhbUbL3lV19sH02dGnM9Ystf9F4oeqwDTITYb5i
huqShMfaTdLEig76zPCLQcOT88deIWZgIxc3R4Do4aCDoyh//2LVZKfzQyEJzVms
njgxcVLVRlomofPW+a+60zm/iLsrbmDjwvWSH8IB4d5ik1aO3732pWgNz3X4HSLk
1s9hVEnpN3GLIWmCcPkbrE9RZtcitghjwrt/xOMKQaqprUuFW4COc0fsfzdLIRtP
bhrA/dnhVSxiUnjc7gLJBnB9+udVKdk2aTdJvSMB1PvhW9QKPjU/H4AW/yQYmism
rSr9imurbi3WosTewtwdcQD47SNS4ALMh//3MeHWOBUMEHP7Tki6i8qR+/xOK+vx
zMc4dnnTQsbgu9bKhrU7ia4eoe/UDvPoLck5cb2+PwYTInfdYBWn1ivbHO7S5ppP
R+/Tc8h3TyLLcPQmH0tpSX+C/YwvctiGsd+iXBRfSTe7o+0wLn8NcDNGi7QI0ipQ
iCHJup9K0FJqf9OuH9qYeaWht7cyuRJ5H4P/HNESGZaPSdTHDpStSmAzdtbBZOkI
qrFg7irL2+CxXwI4H6vC
=XEtz
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] Stealth Addresses

[Gregory Maxwell]

On Wed, Jan 15, 2014 at 4:05 PM, Jeremy Spilman <jeremy@taplink.co> wrote:
> Might I propose "reusable address".

I like this too.

Re: [Bitcoin-development] Stealth Addresses

[Jeremy Spilman]

[-- Attachment #1: Type: text/plain, Size: 1606 bytes --]

Might I propose "reusable address".

I think that describes it best to any non-programmer, and even more so  
encourages wallets to present options as 'one time use' vs 'reusable'.

It definitely packs a marketing punch which could help drive adoption. The  
feature is only useful if/when broadly adopted.

I think it meets all the criteria required:

   - Communication between parties is a single message from the payee,  
which may be public
   - Multiple payments to the same address are not publicly linkable on the  
blockchain
   - The payee has explicitly designated they expect to receive more than  
one payment at that address
   - Payer can publicly prove they made a payment to the reusable address  
by revealing a secret

I have high hopes for this feature. The war *against* address reuse may  
soon be a distant memory.

On Wed, 15 Jan 2014 12:44:17 -0800, Jeff Garzik <jgarzik@bitpay.com> wrote:
> "static address" seems like a reasonable attempt at describing intended  
> use/direction.
>
> On Wed, Jan 15, 2014 at 3:38 PM, Gregory Maxwell <gmaxwell@gmail.com>  
> wrote:
>> On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport  
>> <bendavenport@gmail.com> wrote:
>>> But may I suggest we consider changing the name "stealth address" to
>>> something more neutral?
>>
>> ACK.  Regardless of the 'political' overtones, I think stealth is a
>> little cringe-worthy.
>>
>> "Private address" would be fine if not for confusion with private-keys.
>>
>> "Static address" is perhaps the best in my view. (also helps improve
>> awareness that normal addresses are intended to be more one-use-ness)

[-- Attachment #2.1: Type: text/html, Size: 2369 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Roy Badami]

On Wed, Jan 15, 2014 at 11:17:33PM +0000, I wrote:
> How about just calling them 'type S addresses'?

(Assuming they're encoded in such as way that they actually start with 's'.
Otherwise whatever prefix is actually used, obviously.)

Re: [Bitcoin-development] Stealth Addresses

[Roy Badami]

How about just calling them 'type S addresses'?

Not sure any other name will in reality convey much more meaning than
that.

On Wed, Jan 15, 2014 at 06:07:28PM -0500, Jeff Garzik wrote:
> "Routing address" is pretty good too.  Unsure whether the synergy and
> familiarity with bank routing numbers improves the situation, or
> not...
> 
> 
> On Wed, Jan 15, 2014 at 6:04 PM, Roy Badami <roy@gnomon.org.uk> wrote:
> > On Wed, Jan 15, 2014 at 03:44:17PM -0500, Jeff Garzik wrote:
> >> "static address" seems like a reasonable attempt at describing intended
> >> use/direction.
> >
> > ...as opposed to an address configured by DHCP?
> >
> > More seriously, I don't think a typical user will understand anything from
> > the phrase "static address".  But it is a neutral name, and it is shorter
> > than "address-of-a-type-for-which-reuse-is-not-deprecated". :-)
> >
> > -roy
> 
> 
> 
> -- 
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
> 

Re: [Bitcoin-development] Stealth Addresses

[Jeff Garzik]

"Routing address" is pretty good too.  Unsure whether the synergy and
familiarity with bank routing numbers improves the situation, or
not...


On Wed, Jan 15, 2014 at 6:04 PM, Roy Badami <roy@gnomon.org.uk> wrote:
> On Wed, Jan 15, 2014 at 03:44:17PM -0500, Jeff Garzik wrote:
>> "static address" seems like a reasonable attempt at describing intended
>> use/direction.
>
> ...as opposed to an address configured by DHCP?
>
> More seriously, I don't think a typical user will understand anything from
> the phrase "static address".  But it is a neutral name, and it is shorter
> than "address-of-a-type-for-which-reuse-is-not-deprecated". :-)
>
> -roy



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] Stealth Addresses

[Roy Badami]

On Wed, Jan 15, 2014 at 03:44:17PM -0500, Jeff Garzik wrote:
> "static address" seems like a reasonable attempt at describing intended
> use/direction.

...as opposed to an address configured by DHCP?

More seriously, I don't think a typical user will understand anything from
the phrase "static address".  But it is a neutral name, and it is shorter
than "address-of-a-type-for-which-reuse-is-not-deprecated". :-)

-roy

Re: [Bitcoin-development] Stealth Addresses

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 2222 bytes --]

Do any people who aren't computer programmers or physicists ever use the
term "static"?

I liked routing address.


On Wed, Jan 15, 2014 at 9:44 PM, Jeff Garzik <jgarzik@bitpay.com> wrote:

> "static address" seems like a reasonable attempt at describing intended
> use/direction.
>
>
>
> On Wed, Jan 15, 2014 at 3:38 PM, Gregory Maxwell <gmaxwell@gmail.com>wrote:
>
>> On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport <bendavenport@gmail.com>
>> wrote:
>> > But may I suggest we consider changing the name "stealth address" to
>> > something more neutral?
>>
>> ACK.  Regardless of the 'political' overtones, I think stealth is a
>> little cringe-worthy.
>>
>> "Private address" would be fine if not for confusion with private-keys.
>>
>> "Static address" is perhaps the best in my view. (also helps improve
>> awareness that normal addresses are intended to be more one-use-ness)
>>
>>
>> ------------------------------------------------------------------------------
>> 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=119420431&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
>
>
> ------------------------------------------------------------------------------
> 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=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 3810 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Jeff Garzik]

[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]

"static address" seems like a reasonable attempt at describing intended
use/direction.



On Wed, Jan 15, 2014 at 3:38 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:

> On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport <bendavenport@gmail.com>
> wrote:
> > But may I suggest we consider changing the name "stealth address" to
> > something more neutral?
>
> ACK.  Regardless of the 'political' overtones, I think stealth is a
> little cringe-worthy.
>
> "Private address" would be fine if not for confusion with private-keys.
>
> "Static address" is perhaps the best in my view. (also helps improve
> awareness that normal addresses are intended to be more one-use-ness)
>
>
> ------------------------------------------------------------------------------
> 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=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

[-- Attachment #2: Type: text/html, Size: 2278 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Gregory Maxwell]

On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport <bendavenport@gmail.com> wrote:
> But may I suggest we consider changing the name "stealth address" to
> something more neutral?

ACK.  Regardless of the 'political' overtones, I think stealth is a
little cringe-worthy.

"Private address" would be fine if not for confusion with private-keys.

"Static address" is perhaps the best in my view. (also helps improve
awareness that normal addresses are intended to be more one-use-ness)

Re: [Bitcoin-development] Stealth Addresses

[Ben Davenport]

[-- Attachment #1: Type: text/plain, Size: 2350 bytes --]

Love what's happening here, and how quickly things are moving, from initial
concept, to first implementation, to first transaction.

But may I suggest we consider changing the name "stealth address" to
something more neutral?

Already, many people on Reddit and elsewhere are misinterpreting the
purpose of such addresses, whether for tax evasion, criminal activity, or
who knows what. Bitcoin already has plenty of political hurdles based
sheerly on the technology. We don't need to make life harder for ourselves.
Even forgetting about politics, the "stealth" association just seems to
imply something secretive going on. Is a Fortune 500 company or worldwide
charity going to want to use something called a "stealth address"?

I'd propose the alternate term "routing address".

- It's a descriptive, neutral term
- It accurately describes what the address is: it's a way to route payment
to a recipient, but not the actual final address
- It can be analogized to a bank's routing number: It is uniquely, publicly
and persistently tied to the receiving institution. The payor and payee
knows when payment is made using it, but it's not publicly visible.

That's the best I've got, but here are some alternate terms in case that
doesn't work:

- reusable public address
- permanent public address
- permanent address
- static address

I don't like these quite as much because they're not as clear. Normal
addresses are all reusable, permanent and static -- they just _shouldn't_
be used that way.

Ben


On Tue, Jan 14, 2014 at 4:19 PM, Drak <drak@zikula.org> wrote:

> Sorry this is possibly OT, but someone posted this thread to r/bitcoin and
> it's gone straight to position 1. People are really enthusiastic about this
> feature.
>
> Drak
>
>
> ------------------------------------------------------------------------------
> 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=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 3471 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Drak]

[-- Attachment #1: Type: text/plain, Size: 166 bytes --]

Sorry this is possibly OT, but someone posted this thread to r/bitcoin and
it's gone straight to position 1. People are really enthusiastic about this
feature.

Drak

[-- Attachment #2: Type: text/html, Size: 288 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Roy Badami]

On Mon, Jan 13, 2014 at 04:58:01PM +0100, Mike Hearn wrote:
> 
> Signing a payment request for an individual is easy, anyway, depending on
> the kind of ID you want. If you want to sign with an email address, just go
> here with a browser like Chrome/Safari/IE that uses the system keystore:
> 
>    http://www.comodo.com/home/email-security/free-email-certificate.php

Having now read that page, I'll just leave you with the first bullet
point from it:

 * Digital signature ensures confidentiality

(I'm not trying to make any particular point here - I just couldn't resist)


roy

Re: [Bitcoin-development] Stealth Addresses

[Jeremy Spilman]

On Tue, 14 Jan 2014 13:51:06 -0800, Adam Back <adam@cypherspace.org> wrote:
> I saw in the math version you had said Q'=Q+H(S) and I presumed it was a
> typo, but your code says the same thing.  I presume you meant Q'=Q+H(S)*G
> and therefore that Util.SingleSHA256() multiplies by G internally?
>
> Adam
>

Thanks for reviewing this. The relevant line:

    byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S1));

SingleSHA256 is a single application of SHA256 -- named so since 'SHA256'  
functions in many Bitcoin libraries too often actually run DoubleSHA256.  
32 bytes are returned.

The multiplication by 'G' that you mention is part of my EC.PointAdd...

I should probably just publish all my code as MIT and be done with it ;-)

Thanks,
Jeremy


public static byte[] PointAdd(byte[] point, byte[] scalar, bool compressed  
= true)
{
     var point1 = new OpenSSL.Crypto.EC.Point(EcGroup, point);

     var num = OpenSSL.Core.BigNumber.FromArray(scalar);
     var point2 = OpenSSL.Crypto.EC.Point.Multiply(EcGroup, num,  
EcBnContext);

     var result = point1.Add(point2, EcBnContext);

     if (compressed)
         return result.GetBytes(ConversionForm.Compressed);
     else
         return result.GetBytes(ConversionForm.Uncompressed);
}

Re: [Bitcoin-development] Stealth Addresses

[Adam Back]

I saw in the math version you had said Q'=Q+H(S) and I presumed it was a
typo, but your code says the same thing.  I presume you meant Q'=Q+H(S)*G
and therefore that Util.SingleSHA256() multiplies by G internally?

Adam

Re: [Bitcoin-development] Stealth Addresses

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2436 bytes --]

On Tue, Jan 14, 2014 at 11:12:40AM -0800, Jeremy Spilman wrote:
> Maybe you are saying:
> 
>   byte[] S = EC.DH(e, Q2);
>   byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S));
>   byte[] q2New = EC.PointAdd(Q2, Util.SingleSHA256(S));
> 
> But the payment would have (q2New - q1New) == (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 = EC.DH(e, Q2);
>   byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S || 1));
>   byte[] q2New = 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));
> 
> This is assuming we want to put q2New somewhere into the
> transaction, which, is it even required?
> 
>   byte[] S = EC.DH(e, Q2);
>   byte[] q1New = 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 = <payee root pubkeys>;
byte[] Q_Scan = <may or may not be provided in Q>
int m = <# of pubkeys required to redeem>;
byte[] S = EC.DH(e, Q_Scan);

byte[] qDerived[];
for (int = 0; i < len(Q); i++){
    qDerived[i] = EC.PointAdd(Q[i], Util.SingleSHA256(S || i));
}

// Best to have a single canonical order re: anonymity set.
qDerived = 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.

-- 
'peter'[:-1]@petertodd.org
00000000000000010c474cd4e25913535ec1c166b6d43fbdd9a5f2726711ced7

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Jeremy Spilman]

On Tue, 14 Jan 2014 06:19:08 -0800, Peter Todd <pete@petertodd.org> wrote:

> On Mon, Jan 13, 2014 at 02:02:00PM -0800, Jeremy Spilman wrote:
>> I decided to put both pubKeys in a 2-of-2 multisig, instead of keeping  
>> one of the pubKeys in the OP-RETURN, to prevent a malicious sender from  
>> triggering false positives on your online detection key when the funds  
>> are actually still fully controlled by the payer.
>>
>> You can still have a false positive (only 1 of 2 keys actually yours)  
>> but the funds would be trapped so it's unlikely anyone would do it.
>
> How would they trigger false positives? The payee recovers the nonce
> with ECDH from the payor's ephemereal pubkey and their online detection
> secret key. They use BIP32 public derivation with their offline spending
> pubkey(s), if the derived pubkeys match the actual scriptPubKey they
> know the output is spendable by them. I don't see how that can go wrong.
>

Right now I have this:

   byte[] e = EC.NewPrivateKey();
   byte[] P = EC.GetPublicKey(e, compressed: true);
   byte[] S1 = EC.DH(e, Q1);
   byte[] S2 = EC.DH(e, Q2);
   byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S1));
   byte[] q2New = EC.PointAdd(Q2, Util.SingleSHA256(S2));
   stealthTx.Vout.Add(TxOut.PayToMultiSig(Util.Amount(".995"), 2, 2, q1New,  
q2New));
   stealthTx.Vout.Add(TxOut.OpReturn(P));

In this case, you can scan with d2, calculate S2, and matching payments  
will have the right 'q2New'. But you need to check again offline with d1  
since it's a separate shared secret.

Maybe you are saying:

   byte[] S = EC.DH(e, Q2);
   byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S));
   byte[] q2New = EC.PointAdd(Q2, Util.SingleSHA256(S));

But the payment would have (q2New - q1New) == (Q2 - Q1), so I think not  
entirely stealth? OK, let's fix that by adding a counter to the hash  
function...

   byte[] S = EC.DH(e, Q2);
   byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S || 1));
   byte[] q2New = 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));

This is assuming we want to put q2New somewhere into the transaction,  
which, is it even required?

   byte[] S = EC.DH(e, Q2);
   byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S));
   stealthTx.Vout.Add(TxOut.PayToPubKeyHash(Util.Amount(".995"), q1New);
   stealthTx.Vout.Add(TxOut.OpReturn(P));

I'll wait for ACK and then update my sample code.

Re: [Bitcoin-development] Stealth Addresses

[Odinn Cyberguerrilla]

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=31837430

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 question
>> 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, and
>> forum signatures, etc. with new 'href=bitcoin:xSTL...' URIs. Convention
>> could be to require only transporting xSTL addresses within a URI, even
>> 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 that
>> people actually prefer using them for P2P payments which do not involve
>> 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 can
> 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? What
> happens when you want to use that with a multisig-protected wallet?
>
>> * PP Implementation Overview *
>>
>> The basic PaymentRequest>PaymentDetails is expecting 'output' containing
>> 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 one
>> 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 approach
>> is being used;
>>
>>     optional bytes stealthOnePubKey = 1000
>>     optional bytes stealthTwoPubKey = 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 identifiable
>> 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=119420431&iu=/4140/ostg.clktrk_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

Re: [Bitcoin-development] Stealth Addresses

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1368 bytes --]

On Mon, Jan 13, 2014 at 02:02:00PM -0800, Jeremy Spilman wrote:
> 
> > Uh while I'm responding again, what I'd discussed with Peter Todd in
> > IRC used two EC points in the stealth address. One for the payment and
> > one for the ECDH.  The reason to use two is that it makes delegating
> > detection possible and so you don't have to have you spending keys
> > online to even detect these payments.  Why'd that get dropped?
> 
> I think this is exactly what I've implemented.
> 
> I decided to put both pubKeys in a 2-of-2 multisig, instead of keeping one of the pubKeys in the OP-RETURN, to prevent a malicious sender from triggering false positives on your online detection key when the funds are actually still fully controlled by the payer.
> 
> You can still have a false positive (only 1 of 2 keys actually yours) but the funds would be trapped so it's unlikely anyone would do it. 

How would they trigger false positives? The payee recovers the nonce
with ECDH from the payor's ephemereal pubkey and their online detection
secret key. They use BIP32 public derivation with their offline spending
pubkey(s), if the derived pubkeys match the actual scriptPubKey they
know the output is spendable by them. I don't see how that can go wrong.

-- 
'peter'[:-1]@petertodd.org
000000007dd7a87aec311fb7fb13770f54edf628e6976f8c6091a5b2638878a7

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 4945 bytes --]

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 question  
> 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, and  
> forum signatures, etc. with new 'href=bitcoin:xSTL...' URIs. Convention  
> could be to require only transporting xSTL addresses within a URI, even  
> 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 that  
> people actually prefer using them for P2P payments which do not involve 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 can
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? What
happens when you want to use that with a multisig-protected wallet?

> * PP Implementation Overview *
> 
> The basic PaymentRequest>PaymentDetails is expecting 'output' containing  
> 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 one 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 approach  
> is being used;
> 
>     optional bytes stealthOnePubKey = 1000
>     optional bytes stealthTwoPubKey = 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 identifiable  
> as such.

Agreed.

-- 
'peter'[:-1]@petertodd.org
00000000bda8ab55740699711a11572c4eec9dc9f714e4896559aac310a115ff

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 3768 bytes --]

On Mon, Jan 13, 2014 at 03:20:15PM -0800, Jeremy Spilman wrote:
> On Mon, 13 Jan 2014 13:27:52 -0800, Peter Todd <pete@petertodd.org> wrote:
> 
> >There is a catch however: if you need the prefix to be against
> >H(scriptPubKey) rather than scriptPubKey directly the sender needs to
> >grind the OP_RETURN output at 2^len(prefix) cost. Fortunately that
> >grinding can be done with hash operations rather than ECC - even if we
> >needed 32-bit prefixes eventually computing 32-bit hash collisions is
> >plausible, and more reasonable 8-bit is quite doable now.
> 
> I'll be updating my test code to support a prefix on the OP_RETURN
> TxOut, for either where we expect to have an index on scriptPubKey,
> or where we have an index on H(scriptPubKey) and have to grind with
> a nonce.
> 
> Where do we say what prefix we are targeting, or how many bits
> should match with Q? I assume the only place to communicate this,
> dare I say it, is in the address string.

That's exactly where you need to put it.

Incidentally a prefix nonce, either direct or grind-style, is a bit of a
privacy leak by suggestion how long the prefix was in the original
stealth address. Code should be written such that grinding routines
start at a random nonce, and nonces of any length are accepted. The
easiest way to do that is to just stick the grind nonce at the end after
the 33 bytes of pubkey.

I dunno yet what hashing algorithm to target for grinding. I'd assume
SHA256^2 on the basis that it's identical to what the merkle tree uses
and thus will have the same security properties in a committed index,
but I can see people pushing for the shorter 20-byte HASH160 too.

> Also, for symmetric encryption of P in the OP_RETURN TxOut using a
> key H(Q), what cipher did you have in mind? Since P is ephemeral and
> random, I don't follow, why does encrypting it 'gives a slightly
> larger anonymity set'?

The idea was to make the anonymity set include other uses of OP_RETURN
txouts, however Gregory Maxwell pointed out that it'd easily lead to a
much reduced anonymity set because someone could trial decrypt the
encrypted P and check if it was a valid pubkey. If you encrypted the
full 33 bytes that'd be a total disaster - only 1/256 candidate stealth
keys would work. There are ways to do it right, but it's tricky and
there may be other attacks I don't know about, so I'm inclined to just
drop that idea for now unless a professional cryptographer wants to take
it on.

> You made an interesting point in the original post that payer should
> hold onto their ephemeral privKey 'e' corresponding to pubKey P if
> they need to later prove the payment was actually sent to Q.

Yup. You can even use that pubkey to disambiguate/prove payments with
Timo Hanke's pay-to-contract ideas by deriving it from some root and a
contract hash.

Conversely Amir Taaki pointed out on the unsystem list that once a nonce
is agreed on, it can be used directly with BIP32 derivation so that
future payments don't have to use an OP_RETURN txout. Interesting idea,
although I worry that the statelessness advantage of stealth payments
gets lost if you do that. Probably best to look at that one after an
initial implementation happens and we get some experience with them in
the real world - adding that can be done in a backwards compatible
fashion.

> Finally, I hope you can take a look at the Gist and sample Test-Net
> TXs I sent out this morning. I just went back and re-read your
> original post, and compared to what I implemented there are some
> differences, I'd like to make sure you think it's on track.

Will do.

-- 
'peter'[:-1]@petertodd.org
0000000000000001420349f2276e53e5b087faea67c7c40aa12383c416067364

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Jeremy Spilman]

> Uh while I'm responding again, what I'd discussed with Peter Todd in
> IRC used two EC points in the stealth address. One for the payment and
> one for the ECDH.  The reason to use two is that it makes delegating
> detection possible and so you don't have to have you spending keys
> online to even detect these payments.  Why'd that get dropped?

I think this is exactly what I've implemented.

I decided to put both pubKeys in a 2-of-2 multisig, instead of keeping one of the pubKeys in the OP-RETURN, to prevent a malicious sender from triggering false positives on your online detection key when the funds are actually still fully controlled by the payer.

You can still have a false positive (only 1 of 2 keys actually yours) but the funds would be trapped so it's unlikely anyone would do it. 

Can you take a look at the Gist and TXs on TestNet I sent out, and see if that's in line with what you expected?

I would also greatly appreciate if you could review the discussion around doing two ECDH operations with a single ephemeral key.

Thanks!
--Jeremy

Re: [Bitcoin-development] Stealth Addresses

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1483 bytes --]

On Mon, Jan 13, 2014 at 04:15:01PM -0500, Alan Reiner wrote:
> > I don't know if stealth addresses are the best solution to address
> > this use case, but AFAIK the only current solution to this use case is
> > to store a long-lived Bitcoin address in the addresss book.
> >
> > roy
> >
> 
> Fair enough.  I haven't spent much time thinking about that use case. 
> Though, I question the feasibility of anything that requires O(N) EC
> multiply operations/sec, where N is the total volume of transactions
> moving over the network.  But I guess if the prefix is big enough, the
> scanning operations will remain feasible forever.

Well that's the thing: the cost to find all stealth-address-using
payments to you isn't O(n) transaction volume, it's O(n) anonymity set
size. I think we can make a pretty good argument that the anonymity set
people need is mostly fixed in size and has nothing to do with overall
tx volume, so really we've got O(1) scaling.

There is a catch however: if you need the prefix to be against
H(scriptPubKey) rather than scriptPubKey directly the sender needs to
grind the OP_RETURN output at 2^len(prefix) cost. Fortunately that
grinding can be done with hash operations rather than ECC - even if we
needed 32-bit prefixes eventually computing 32-bit hash collisions is
plausible, and more reasonable 8-bit is quite doable now.

-- 
'peter'[:-1]@petertodd.org
00000000000000013f56c73dbb82447ba01e303648109b2e7ea0adf6ca53a7ff

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Alan Reiner]

On 01/13/2014 04:02 PM, Roy Badami wrote:
>> It's not public.  When I say "please pay me" I also say "use this
>> multiplier".
> Sending a "please pay me" message is really great for business
> transactions.
>
> But I think the use case that Peter Todd mentions is actually *the*
> most important currently under-addresesd use case:
>
>> With stealth addresses the user experience can be as simple as you
>> telling me on the phone "hey! send me that 0.234 BTC you owe me!",
>> me clicking on "Send to Alan Reiner (verified by PGP)" (perhaps
>> again on my off-line second factor device for a multi-sig wallet)
>> and tellling you "OK, sent".
> Lots of work is being done on handling consumer-to-merchant
> transactions.  BIP 70 does a good job of tackling the online purchase
> case, and the work that Andreas Schildbach is doing with Bluetooth and
> NFC will improve the options for a payer in a physical PoS transaction
> who might not have Internet connectivity on their smartphone.
>
> But relatively little work (that I know of) is being done on
> non-transactional personal payments - that is, being able to pay money
> to friends and other people that you have a face-to-face relationship
> with.
>
> What I want... no need... is to be able to open my wallet, select a
> friend from my address book, and transfer the $10 I owe them from the
> bar last night.
>
> I don't care - within reason - what process is involved in getting my
> friend set up in my address book.  That may well requires two way
> communication (e.g. over NFC).  But once it's set up, I should be able
> to just select the payee from the address book and send them some
> funds.  Anything else is just too complciated.
>
> I don't know if stealth addresses are the best solution to address
> this use case, but AFAIK the only current solution to this use case is
> to store a long-lived Bitcoin address in the addresss book.
>
> roy
>

Fair enough.  I haven't spent much time thinking about that use case. 
Though, I question the feasibility of anything that requires O(N) EC
multiply operations/sec, where N is the total volume of transactions
moving over the network.  But I guess if the prefix is big enough, the
scanning operations will remain feasible forever.

Re: [Bitcoin-development] Stealth Addresses

[Roy Badami]

> It's not public.  When I say "please pay me" I also say "use this
> multiplier".

Sending a "please pay me" message is really great for business
transactions.

But I think the use case that Peter Todd mentions is actually *the*
most important currently under-addresesd use case:

> With stealth addresses the user experience can be as simple as you
> telling me on the phone "hey! send me that 0.234 BTC you owe me!",
> me clicking on "Send to Alan Reiner (verified by PGP)" (perhaps
> again on my off-line second factor device for a multi-sig wallet)
> and tellling you "OK, sent".

Lots of work is being done on handling consumer-to-merchant
transactions.  BIP 70 does a good job of tackling the online purchase
case, and the work that Andreas Schildbach is doing with Bluetooth and
NFC will improve the options for a payer in a physical PoS transaction
who might not have Internet connectivity on their smartphone.

But relatively little work (that I know of) is being done on
non-transactional personal payments - that is, being able to pay money
to friends and other people that you have a face-to-face relationship
with.

What I want... no need... is to be able to open my wallet, select a
friend from my address book, and transfer the $10 I owe them from the
bar last night.

I don't care - within reason - what process is involved in getting my
friend set up in my address book.  That may well requires two way
communication (e.g. over NFC).  But once it's set up, I should be able
to just select the payee from the address book and send them some
funds.  Anything else is just too complciated.

I don't know if stealth addresses are the best solution to address
this use case, but AFAIK the only current solution to this use case is
to store a long-lived Bitcoin address in the addresss book.

roy

Re: [Bitcoin-development] Stealth Addresses

[Gregory Maxwell]

On Mon, Jan 13, 2014 at 12:41 PM, Alan Reiner <etotheipi@gmail.com> wrote:
> It's not public.  When I say "please pay me" I also say "use this
> multiplier".  The multiplier isn't published, and it's not publicly
> discoverable without my wallet (or access to my email).

If you have enough of a communications channel to do that you can just
give the person the finished address (authentication aside).

The idea here is to cover the cases where the communication is one way
or nearly so.  Consider a donation address on a fully static webpage,
in a forum signature or email address, or on a billboard. ... or where
users-being-users mean that the user isn't going to start up their
wallet software to compute a new multiplier every time they give out
an address no matter how much we whine at them.

Re: [Bitcoin-development] Stealth Addresses

[Alan Reiner]

[-- Attachment #1: Type: text/plain, Size: 2699 bytes --]


On 01/13/2014 03:14 PM, Peter Todd wrote:
> On Mon, Jan 13, 2014 at 02:59:08PM -0500, Alan Reiner wrote:
>> How is this different from the proposal I have made?
>>
>> You distribute the root public key (but not chaincode!) of a BIP32
>> branch.  You can put your root key on a business card if you want.  Then
>> when someone wants to pay you, you simply give them the multiplier and
>> root key (they already have the root key, but should verify).  The
>> multiplier does not reveal the chaincode, thus keeping it private, but
>> it does allow them to confirm that the final address they are paying is
>> derived from that root key they know belongs to you ("Please pay address
>> X; oh btw, X=rootKey*mult").
>>
>> You can /choose/ to reveal that a given payment address is linked to
>> your root key without any compromise of privacy.  Or you can choose to
>> ignore it and just give them a bare address the old way and still
>> maintain privacy.  What advantages does "stealth addresses" have over
>> this scheme?  You could extend it using some kind of deterministic
>> sub-branching and/or ECDH to create multiple payment addresses without
>> querying the payee.
>
> Basically stealth addresses *are* your scheme, using the blockchain as a
> low or even no overhead communication channel for the payor to give the
> payee that multiplier without bidirectional communication.
>
> In the business card example I can't easily take your business card and
> just send you some money without that transaction being linked to public
> information. (your business card)

It's not public.  When I say "please pay me" I also say "use this
multiplier".  The multiplier isn't published, and it's not publicly
discoverable without my wallet (or access to my email).  The address
remains private between you and me.  As you said, it could be
discoverable if the email is discoverable, but I'm not seeing how how
critical that really is.

There's a lot of complexity around this constraint (possibly involving
new/secondary private keys, extra outputs, relying on change outputs,
and/or using 3rd parties to help look for transactions).  I'm not
convinced that what is being gained is really worth that extra complexity.

By contrast, what I proposed, that does require sending sending the
payer a multiplier once, is easy to implement in any BIP 32 wallet,
doesn't require any special address formats, and achieves 98% of the
same benefits without any special computation.   I guess I'm just not
convinced that it's really necessary for people to be able to send
others payments without contacting them (and/or hiding the evidence a
payment was made even if they communications were discovered).

-Alan




[-- Attachment #2: Type: text/html, Size: 3652 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 614 bytes --]

On Mon, Jan 13, 2014 at 12:10:56PM -0800, Gregory Maxwell wrote:
> Uh while I'm responding again, what I'd discussed with Peter Todd in
> IRC used two EC points in the stealth address. One for the payment and
> one for the ECDH.  The reason to use two is that it makes delegating
> detection possible and so you don't have to have you spending keys
> online to even detect these payments.  Why'd that get dropped?

I mentioned it again in another email; I just forgot to include it in my
final write-up.

-- 
'peter'[:-1]@petertodd.org
00000000000000023d5a8bbe131414328a6c50a2741933ba03775afd3c3db395

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2684 bytes --]

On Mon, Jan 13, 2014 at 02:59:08PM -0500, Alan Reiner wrote:
> How is this different from the proposal I have made?
> 
> You distribute the root public key (but not chaincode!) of a BIP32
> branch.  You can put your root key on a business card if you want.  Then
> when someone wants to pay you, you simply give them the multiplier and
> root key (they already have the root key, but should verify).  The
> multiplier does not reveal the chaincode, thus keeping it private, but
> it does allow them to confirm that the final address they are paying is
> derived from that root key they know belongs to you ("Please pay address
> X; oh btw, X=rootKey*mult").
> 
> You can /choose/ to reveal that a given payment address is linked to
> your root key without any compromise of privacy.  Or you can choose to
> ignore it and just give them a bare address the old way and still
> maintain privacy.  What advantages does "stealth addresses" have over
> this scheme?  You could extend it using some kind of deterministic
> sub-branching and/or ECDH to create multiple payment addresses without
> querying the payee. 

Basically stealth addresses *are* your scheme, using the blockchain as a
low or even no overhead communication channel for the payor to give the
payee that multiplier without bidirectional communication.

In the business card example I can't easily take your business card and
just send you some money without that transaction being linked to public
information. (your business card)

> I had planned to implement this system and push for people to accept it
> because I don't see any downsides to it.  It can easily be integrated
> into a WoT (with signed root keys), or CA system piggybacking on SSL.

WoT is a perfect example of the problem: if you put BIP32 branch payment
info into my OpenPGP key I can't pay you securely and reliably without
making the transaction public. The best I can do is pick a nonce and pay
X=rootKey*nonce, communicating to you the nonce later - this isn't
reliable because if I or you lose the nonce the funds are lost.

With stealth addresses the user experience can be as simple as you
telling me on the phone "hey! send me that 0.234 BTC you owe me!", me
clicking on "Send to Alan Reiner (verified by PGP)" (perhaps again on my
off-line second factor device for a multi-sig wallet) and tellling you
"OK, sent".

Even if your phone has been wiretapped, the attacker still didn't learn
exactly what transaction was actually used to make the payment - a big
advantage over per-tx nonce stuff.

-- 
'peter'[:-1]@petertodd.org
00000000000000023d5a8bbe131414328a6c50a2741933ba03775afd3c3db395

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Roy Badami]

On Mon, Jan 13, 2014 at 04:58:01PM +0100, Mike Hearn wrote:
> Signing a payment request for an individual is easy, anyway, depending on
> the kind of ID you want. If you want to sign with an email address, just go
> here with a browser like Chrome/Safari/IE that uses the system keystore:
> 
>    http://www.comodo.com/home/email-security/free-email-certificate.php
> 

Ok, cool, I wasn't aware of such services, and I can certainly see
they could be useful.  But it's not that great for the business card
scenario.

As far as I can see, using it in that scenario would have to rely on
the payer scanning the QR code on the business card, and then check
that the email address displayed by their wallet matched the email
address printed on the business card.

roy

Re: [Bitcoin-development] Stealth Addresses

[Gregory Maxwell]

On Mon, Jan 13, 2014 at 11:59 AM, Alan Reiner <etotheipi@gmail.com> wrote:
> Then when someone
> wants to pay you, you simply give them the multiplier and root key (they
> already have the root key, but should verify).
[...]
> What
> advantages does "stealth addresses" have over this scheme?  You could extend
> it using some kind of deterministic sub-branching and/or ECDH to create
> multiple payment addresses without querying the payee.

The stealth address stuff is the ECDH to create multiple payment
addresses without querying the payee.


Uh while I'm responding again, what I'd discussed with Peter Todd in
IRC used two EC points in the stealth address. One for the payment and
one for the ECDH.  The reason to use two is that it makes delegating
detection possible and so you don't have to have you spending keys
online to even detect these payments.  Why'd that get dropped?

I don't think this is a good idea if you have to constantly keep your
spending key(s) online even to detect payments, even with the limited
use-cases envisioned.

Re: [Bitcoin-development] Stealth Addresses

[Roy Badami]

rOn Mon, Jan 13, 2014 at 08:57:33PM +0100, Mike Hearn wrote:
> >
> > On further reflection, I'm not sure I understand this use case of the
> > payment protocol.  Since a PaymentRequest currently contains the
> > Outputs that specify the addresses to send to, reusing a
> > PaymentRequest like this without using stealth addresses implies
> > address reuse.
> 
> 
> Yes indeed ...... which is why we're talking about extending the protocol
> (in a future version! the first version isn't even out yet!).

Yes, sorry, I miscontrued the thread here and now see that your
message was exactly talking about using stealth addresses within the
payment protocol.

Sorry for the confusion.

roy

Re: [Bitcoin-development] Stealth Addresses

[Alan Reiner]

[-- Attachment #1: Type: text/plain, Size: 2188 bytes --]

How is this different from the proposal I have made?

You distribute the root public key (but not chaincode!) of a BIP32
branch.  You can put your root key on a business card if you want.  Then
when someone wants to pay you, you simply give them the multiplier and
root key (they already have the root key, but should verify).  The
multiplier does not reveal the chaincode, thus keeping it private, but
it does allow them to confirm that the final address they are paying is
derived from that root key they know belongs to you ("Please pay address
X; oh btw, X=rootKey*mult").

You can /choose/ to reveal that a given payment address is linked to
your root key without any compromise of privacy.  Or you can choose to
ignore it and just give them a bare address the old way and still
maintain privacy.  What advantages does "stealth addresses" have over
this scheme?  You could extend it using some kind of deterministic
sub-branching and/or ECDH to create multiple payment addresses without
querying the payee. 

I had planned to implement this system and push for people to accept it
because I don't see any downsides to it.  It can easily be integrated
into a WoT (with signed root keys), or CA system piggybacking on SSL.

-Alan


On 01/13/2014 02:44 PM, Drak wrote:
> On 13 January 2014 19:40, Roy Badami <roy@gnomon.org.uk
> <mailto:roy@gnomon.org.uk>> wrote:
>
>     At the moment, I can give them a business card with a Bitcoin address.
>     Being able to give out a business card with a stealth address would be
>     a major advance.
>
>
> My thoughts exactly.
>
> Drak 
>
>
> ------------------------------------------------------------------------------
> 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=119420431&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[-- Attachment #2: Type: text/html, Size: 3941 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 422 bytes --]

>
> On further reflection, I'm not sure I understand this use case of the
> payment protocol.  Since a PaymentRequest currently contains the
> Outputs that specify the addresses to send to, reusing a
> PaymentRequest like this without using stealth addresses implies
> address reuse.


Yes indeed ...... which is why we're talking about extending the protocol
(in a future version! the first version isn't even out yet!).

[-- Attachment #2: Type: text/html, Size: 667 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Roy Badami]

> > Likewise, I could attach a payment request to an email and send it to you,
> > and now you can pay me whenever you want forever.
> 
> That certainly sounds like a plausible use case.  You do still have
> the problem that e-mail is an insecure channel, but it's no worse than
> exchanging Bitcoin addreses over e-mail as things stand at the
> moment.

On further reflection, I'm not sure I understand this use case of the
payment protocol.  Since a PaymentRequest currently contains the
Outputs that specify the addresses to send to, reusing a
PaymentRequest like this without using stealth addresses implies
address reuse.

(Granted there are alternative solutions to stealth addresses, such as
a BIP32-style derivation.)

roy

Re: [Bitcoin-development] Stealth Addresses

[Drak]

[-- Attachment #1: Type: text/plain, Size: 259 bytes --]

On 13 January 2014 19:40, Roy Badami <roy@gnomon.org.uk> wrote:

> At the moment, I can give them a business card with a Bitcoin address.
> Being able to give out a business card with a stealth address would be
> a major advance.


My thoughts exactly.

Drak

[-- Attachment #2: Type: text/html, Size: 664 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Roy Badami]

On Mon, Jan 13, 2014 at 01:52:25AM -0800, Gregory Maxwell wrote:
> On Sun, Jan 12, 2014 at 1:18 PM, Gavin Andresen <gavinandresen@gmail.com> wrote:
> > No, please. Make it easy for non-geeks, extend the payment protocol, or
> > we'll spend the next two years writing code that tries to ignore linebreaks
> > and spaces and changing <input> elements in HTML forms to <textarea> ....
> 
> However, if you're able to use the payment protocol then you probably
> don't need stealth addresses to prevent reuse.

I definitely think this is a case that should be addressed better than
at present.

To consider a concrete use case, imagine I wish to be able to give my
friends and acquaintances a paper business card with a QR code on it,
that they can use to make payments to me.  I don't own a domain or any
kind of X.509 certificate and I don't run an HTTP server.  I don't
feel comfortable with a solution that requires me to trust a third
party to complete the payments.

At the moment, I can give them a business card with a Bitcoin address.
Being able to give out a business card with a stealth address would be
a major advance.

roy

Re: [Bitcoin-development] Stealth Addresses

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1236 bytes --]

On Mon, Jan 13, 2014 at 2:37 PM, Roy Badami <roy@gnomon.org.uk> wrote:

> That does require trusting the third party not to later tamper with
> the payment request, though.


You have to trust the billboard owner too. If you're relying on a third
party to relay a payment instruction, that will always be an issue, hence
the signing.

Signing a payment request for an individual is easy, anyway, depending on
the kind of ID you want. If you want to sign with an email address, just go
here with a browser like Chrome/Safari/IE that uses the system keystore:

   http://www.comodo.com/home/email-security/free-email-certificate.php

They'll send you an email, you click the link to verify, and a cert will be
generated and installed by your web browser. It's actually easier than
signing up for a website. There are lots of other places that do it for
free too, I just picked the first one from a google search for [free email
certificate].

Once you've got that in your keystore, a wallet app can quite easily be
told to sign payment requests with your email address.

For a billboard I guess you'd probably be an organisation or company
instead, though an email address can work there too as long as you have a
well known domain name.

[-- Attachment #2: Type: text/html, Size: 1910 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Roy Badami]

> I was thinking that people could upload a payment protocol file somewhere
> once (like to their personal web page, or shared via dropbox or google
> drive or some custom new pastebin style service), and then just encode a
> regular bitcoin URI into the qrcode on the billboard.

That does require trusting the third party not to later tamper with
the payment request, though.  (I'm assuming that a signed payment
request is not always going to be all that useful in the case of
private individuals, even assuming the payee is willing to sign up for
one.)

> Likewise, I could attach a payment request to an email and send it to you,
> and now you can pay me whenever you want forever.

That certainly sounds like a plausible use case.  You do still have
the problem that e-mail is an insecure channel, but it's no worse than
exchanging Bitcoin addreses over e-mail as things stand at the
moment.

roy

Re: [Bitcoin-development] Stealth Addresses

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 667 bytes --]

>
> However, if you're able to use the payment protocol then you probably
> don't need stealth addresses to prevent reuse.
>

I was thinking that people could upload a payment protocol file somewhere
once (like to their personal web page, or shared via dropbox or google
drive or some custom new pastebin style service), and then just encode a
regular bitcoin URI into the qrcode on the billboard.

Likewise, I could attach a payment request to an email and send it to you,
and now you can pay me whenever you want forever.

Getting a little static piece of data to someone *once* should be something
we can make easy. Constantly refreshing it, on the other hand ...

[-- Attachment #2: Type: text/html, Size: 958 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Gregory Maxwell]

On Sun, Jan 12, 2014 at 1:18 PM, Gavin Andresen <gavinandresen@gmail.com> wrote:
> No, please. Make it easy for non-geeks, extend the payment protocol, or
> we'll spend the next two years writing code that tries to ignore linebreaks
> and spaces and changing <input> elements in HTML forms to <textarea> ....

However, if you're able to use the payment protocol then you probably
don't need stealth addresses to prevent reuse.

E.g. What can I put for a donation address on a totally static
webpage? or on a billboard?

At least thats what I understood these things were trying to solve—
fix privacy where realtime two way communication just isn't available.

Re: [Bitcoin-development] Stealth Addresses

[Jeremy Spilman]

On Sun, Jan 12, 2014 at 7:20 PM, Jeremy Spilman <jeremy@taplink.co> wrote:
> > I think for displaying the payment in the UI after it's been made via  
> PP, we have to fully
> > support sending to a new standard address type anyway.

On Sun, 12 Jan 2014 10:26:18 -0800, Mike Hearn <mike@plan99.net> wrote:
> Why? Showing an address is meaningless, especially if the user didn't  
> type it in or see
> it somewhere else. It's just an opaque random number, all putting it in  
> the UI can do is
> make it look scarier :)
>
> Part of the point of the payment protocol is it lets merchants provide  
> human readable text
> for transactions instead of addresses.

Of course you're right, moving away from addresses is definitely part of  
the point of PP.

On Sun, 12 Jan 2014 13:18:33 -0800, Gavin Andresen  
<gavinandresen@gmail.com> wrote:
> No, please. Make it easy for non-geeks, extend the payment protocol, or  
> we'll spend the next
> two years writing code that tries to ignore linebreaks and spaces and  
> changing <input> in HTML
> forms to <textarea>...

Agreed, it's long enough to be even more problematic than usual. If the  
general consensus is that there should not even be a standardized address  
form, then I can skip that entirely, and go straight to trying to extend  
PP.

It's a given this will be implemented for Payment Protocol. The question  
is whether it's also usable outside of PP.

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, and  
forum signatures, etc. with new 'href=bitcoin:xSTL...' URIs. Convention  
could be to require only transporting xSTL addresses within a URI, even  
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.

I think there are ways to make stealth addresses easy enough to use that  
people actually prefer using them for P2P payments which do not involve 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.

* PP Implementation Overview *

The basic PaymentRequest>PaymentDetails is expecting 'output' containing  
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 one 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 approach  
is being used;

    optional bytes stealthOnePubKey = 1000
    optional bytes stealthTwoPubKey = 1001

or just

    optional bytes stealth = 1000

* User Interaction / Flow *

Lets follow this through from the user perspective, starting with what it  
looks like today. I'm having a hard time finding screenshots of what PP  
looks like in BitcoinQT, so I built from HEAD and using Gavin's  
Handy-Dandy PaymentRequest Generator  
(https://bitcoincore.org/~gavin/createpaymentrequest.php):

Screenshots: http://imgur.com/a/k6j9D

Image 1 - 'Send' screen after clicking a PR URI with a small transaction  
and auto-calculated fee
Image 2 - System Tray notification after clicking 'Send'
Image 3 - Transaction List showing partially confirmed transaction
Image 4 - Transactions details popup

We see 'Pay To' (Common Name from the cert) and 'Memo' on the Send screen.  
The System Tray notification popup and Transaction List shows just the  
address string. The 'Transaction details' window shows 'Merchant' which I  
think is the same as 'Pay To'. You also have 'Copy address' option in the  
right-click menu.

Memo seems not to be saved, or at least not visible in the UI after  
sending a payment.

* Transaction Display *

The address string is fairly pervasive, which is why I was originally  
thinking it would make sense to implement all the address handling first,  
so all those screens would continue to work as specified, without trying  
to hack something different in those fields.

Without digging too far into the code, it looks like "address" displayed  
is derived from the TxOut -- e.g. script.cpp:ExtractDestination. This  
could be a bit problematic depending on what we really want to show to the  
user -- the stealth multisig, or the pubkeys?

Part of the point of stealth addresses is actually making them reusable.  
So if you're the originator of the payment, you might want the wallet to  
tag that transaction somehow with the pubkeys used to generate it.

Also, ideally I think I would want multiple different stealth payments  
within a single wallet to the same merchant / pubkeys to be identifiable  
as such.

* Sample Code *

Will follow in another email, to be sent shortly!

Re: [Bitcoin-development] Stealth Addresses

[Gavin Andresen]

[-- Attachment #1: Type: text/plain, Size: 706 bytes --]

On Sun, Jan 12, 2014 at 5:33 AM, Jeremy Spilman <jeremy@taplink.co> wrote:

> ...
> Now, you would need to get two pubkeys to the payer, throw in a prefix to
> help standardize it, and end up with addresses that could look like (for
> example):
>
>
> xSTLxsn59oaupR6ZKt2yddQ4dp5hcFinnTWkvsDiXtHgAEDg5ajNVzTY8MMQsmqnEn3ZMKxQzrfC3pDimfTWMkiUb7x3jX3J26JSX
>
> tSTLcpwzupCFL3maVZkSiB9ib3BXsCAfkhMLgckQEyoj8Tk83ANzofeuDdbX6bSPqNRfACLLFYK8EwVo1jdjxNDFNDWxhnQiAy4ba
>

No, please. Make it easy for non-geeks, extend the payment protocol, or
we'll spend the next two years writing code that tries to ignore linebreaks
and spaces and changing <input> elements in HTML forms to <textarea> ....

-- 
--
Gavin Andrese

[-- Attachment #2: Type: text/html, Size: 1093 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 562 bytes --]

On Sun, Jan 12, 2014 at 7:20 PM, Jeremy Spilman <jeremy@taplink.co> wrote:

>  I think for displaying the payment in the UI after it's been made via
> PP, we have to fully support sending to a new standard address type anyway.
>

Why? Showing an address is meaningless, especially if the user didn't type
it in or see it somewhere else. It's just an opaque random number, all
putting it in the UI can do is make it look scarier :)

Part of the point of the payment protocol is it lets merchants provide
human readable text for transactions instead of addresses.

[-- Attachment #2: Type: text/html, Size: 986 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Jeremy Spilman]

[-- Attachment #1: Type: text/plain, Size: 3384 bytes --]


> You can always just extend the payment protocol with the new fields as  
> well, vs making very long addresses.

I should have mentioned that as Task #4. Agree it could be an optional  
extension and backward compatible. I think for displaying the payment in  
the UI after it's been made via PP, we have to fully support sending to a  
new standard address type anyway. Probably easiest to implement in PP  
after the address and transaction building code is done.

So '4a' would be building a static PP file given the necessary inputs.  
When I get to that point, I'll send out a draft PP extension with  
fields/formats if someone else hasn't already. '4b' would be actually  
adding support for parsing those fields and generating the new transaction  
type into bitcoind.

Any thoughts on the prefix, and one vs two pubkey approach? First of all,  
do we try to support both equally, or favor one over the other? I was  
thinking we could have two different 4 byte prefixes but that both render  
as xSTL/tSTL in Base58 but correspond to the one vs two pubkeys expected.  
I think the chance of finding a single prefix which looks like xSTL for  
both address lengths is 1 in (58^4)^2, so that's probably not going to  
happen.

 From the payer/user perspective, short stealth vs. long stealth is  
irrelevant; they both have the same usability properties from the payer  
perspective. So giving them the same Base58 prefix seems like a good plan.

The full 4-byte prefix seems worth the usability trade-off versus 1-byte  
prefix, especially since it will impact the ability to lookup the  
transaction on an outside service, which I think a lot of people do to  
verify their payments. IMO a longer prefix isn't "wasting bytes" anywhere  
that it really counts.

We could save two bytes in the address if we required both pubkeys to  
start with '03', or save one byte if we required they both start with the  
same byte, but again doesn't seem worth it (to me) for the arbitrary  
restriction.

The actual internal wallet code for *receiving* STL payments and updating  
balances is more tricky and probably not something I can personally tackle  
for bitcoind. Assuming we even want first-class support for generating STL  
addresses and receiving STL payments in a standard user wallet, someone  
has to decide if the STL 'd' / 'd2' keys should be...

   1) Encrypted as usual, and then keep a list of blocks with interesting  
transactions, and go through them when the user enters their password?   
This would cause balances to update differently than how they do now, but  
perhaps be more secure.

   2) Kept unencrypted to allow live scanning as usual? Or keep just 'd2'  
unencrypted, with some new concept of 'unconfirmed' until the user enters  
their password to prove they can spend that TX? That kind of extra step  
seems OK for a merchant but sounds very scary for an average user.

   3) Kept encrypted under a separate password? Meh...

And last thought for now... At some point, we might want to decide on a  
convention to highlight these STL addresses as 'reusable' -- but similar  
questions around revocability remain. I hope we don't need anything like a  
UTC expiration time baked in to the address. A static PP file will have an  
expiration date either in the certificate or in 'expires' field, so I  
think if you want it to expire then use PP?

[-- Attachment #2.1: Type: text/html, Size: 3859 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 5991 bytes --]

You can always just extend the payment protocol with the new fields as
well, vs making very long addresses. If this technique can be made to work
well, it would have applicability in both fixed textual address context,
and for a fixed/upload-once payment protocol file. That has the advantage
of backwards compatibility as well - the new addresses would not be
clickable or acceptable by old wallets, but with the payment protocol you
can always craft a bitcoin URI that contains a regular current style
address, and a link to a fixed payment protocol file (uploaded to a
pastebin type site), and modern wallets would ignore the address and use
the ECDH based system instead.



On Sun, Jan 12, 2014 at 11:33 AM, Jeremy Spilman <jeremy@taplink.co> wrote:

> > Oh, sorry, I forgot to mention it in my first write-up but you can
> > easily make stealth addresses include a second pubkey for the purpose of
> > the communication that either isn't used in the scriptPubKey at all, or
> > is part of a n-of-m multisig. (n>=2) Interestingly that also means you
> > can give a third-party that key and out-source the effort of scanning
> > the blockchain for you.
>
> Great point. Even if it's not a 3rd party, I think it's really important
> to be able to scan for transactions with a key which can't actually spend
> the funds.
>
> The first approach is just one-pass ECDH. I think you're saying the second
> approach is two rounds of ECDH but re-using the same e/P (usually referred
> to as r/R in ECIES). I think this is safe, unlike reusing an ephemeral key
> for signing operations.
>
>    Payee: Publish Q, Q2                     [d, d2 are privkeys, Q, Q2 are
> pubkeys]
>    Payer: 1) Generate ephemeral key: e / P  [e is privkey, P is pubkey]
>           2) S = e * Q                      [first shared secret]
>           3) S2 = e * Q2                    [second shared secret, reusing
> 'e']
>           4) Q' = Q + H(S)                  [pay-to stealth address]
>           5) Q2' = Q2 + H(S2)               [stealth 'marker']
>
>    Watch: 1) Look for TxOut with OP_RETURN <P>
>           2) Q2' = Q2 + H(d2 * P)
>           3) Check for Q2' elsewhere in the Tx
>
> S/MIME for example, allows reuse of the ephemeral keypair. When reusing an
> ephemeral keypair where A reuses (x, X) to encrypt different messages to
> more than one user, A should verify the static public keys to prevent
> small-subgroup attacks.[1][2]
>
> Let's say you pay-to Q' and then Q2' value has to be somewhere else in the
> transaction. You could put it next to the shared P in OP_RETURN. OP_RETURN
> <P> <Q2'> would be 66 bytes.
>
> But then Mallory could generate transactions with the right Q2' but with
> his own pubkey in Step 2 instead of Q. So your scanner would detect a
> payment, but you wouldn't be able to spend it, and Mallory could.
>
> That's a good argument for putting Q2' in a 2-of-2 multisig so that
> pulling this trick would at least make the transaction unspendable for
> both parties, which may be good enough deterrent, but you're still going
> to want to check it against your 'd' before fulfilling a large order. Your
> online watch process could queue the matching transactions, which you
> could move to your offline machine, decrypt your key, and verify the
> transactions are spendable.
>
> Now, you would need to get two pubkeys to the payer, throw in a prefix to
> help standardize it, and end up with addresses that could look like (for
> example):
>
>
> xSTLxsn59oaupR6ZKt2yddQ4dp5hcFinnTWkvsDiXtHgAEDg5ajNVzTY8MMQsmqnEn3ZMKxQzrfC3pDimfTWMkiUb7x3jX3J26JSX
>
> tSTLcpwzupCFL3maVZkSiB9ib3BXsCAfkhMLgckQEyoj8Tk83ANzofeuDdbX6bSPqNRfACLLFYK8EwVo1jdjxNDFNDWxhnQiAy4ba
>
> Those addresses are 74 bytes:
> <Prefix><CompressedPubKey1><CompressedPubKey2><Checksum>
>
>    xSTL Prefix = 0xC0CB9270
>    tSTL Prefix = 0xB2E27D50
>    NOTE: I do NOT have the corresponding privkeys for these four pubkeys!
>
> Those just happened to be the first matching prefixes I found for 74 byte
> addresses. I could try to find ones which start with a specific byte if
> that's somehow better, like 0x04 to match BIP32.
>
> Unfortunately, I don't think you can just derive a second public key from
> the first to keep the address shorter, and still keep the first private
> key secure, even if the second private key is stolen. You only get
> equivalent security as BIP32 public derivation, where you can't lose a
> child private key.
>
> Do we also want xSTL (or whatever user friendly string) prefixes for
> single pubkey (41 byte) stealth addresses?
>
> I'll wait a couple days for feedback, then I'll try to implement the
> following prototypes:
>
> 1) Pay to STL addresses
> 2) Watcher process to detect and queue STL payments for a given d2/Q2
> 3) Offline verifier to take output from Watcher and verify spendable given
> encrypted d/d2
>
> Obviously extending QT directly for #1 would be ideal, I may even be able
> to do that since supporting a new address type should be fairly contained.
> But if not I'll punt to writing a node.js or python script which connects
> to bitcoind via RPC.
>
> Thanks,
> Jeremy
>
> [1] - On Reusing Ephemeral Keys in Diffie-Hellman Key Agreement Protocols
>        http://www.math.uwaterloo.ca/~ajmeneze/publications/ephemeral.pdf
>
> [2] - Validation of Elliptic Curve Public Keys
>        http://www.iacr.org/archive/pkc2003/25670211/25670211.pdf
>
>
>
> ------------------------------------------------------------------------------
> 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=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 7459 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Jeremy Spilman]

> Oh, sorry, I forgot to mention it in my first write-up but you can
> easily make stealth addresses include a second pubkey for the purpose of
> the communication that either isn't used in the scriptPubKey at all, or
> is part of a n-of-m multisig. (n>=2) Interestingly that also means you
> can give a third-party that key and out-source the effort of scanning
> the blockchain for you.

Great point. Even if it's not a 3rd party, I think it's really important  
to be able to scan for transactions with a key which can't actually spend  
the funds.

The first approach is just one-pass ECDH. I think you're saying the second  
approach is two rounds of ECDH but re-using the same e/P (usually referred  
to as r/R in ECIES). I think this is safe, unlike reusing an ephemeral key  
for signing operations.

   Payee: Publish Q, Q2                     [d, d2 are privkeys, Q, Q2 are  
pubkeys]
   Payer: 1) Generate ephemeral key: e / P  [e is privkey, P is pubkey]
          2) S = e * Q                      [first shared secret]
          3) S2 = e * Q2                    [second shared secret, reusing  
'e']
          4) Q' = Q + H(S)                  [pay-to stealth address]
          5) Q2' = Q2 + H(S2)               [stealth 'marker']

   Watch: 1) Look for TxOut with OP_RETURN <P>
          2) Q2' = Q2 + H(d2 * P)
          3) Check for Q2' elsewhere in the Tx

S/MIME for example, allows reuse of the ephemeral keypair. When reusing an  
ephemeral keypair where A reuses (x, X) to encrypt different messages to  
more than one user, A should verify the static public keys to prevent  
small-subgroup attacks.[1][2]

Let's say you pay-to Q' and then Q2' value has to be somewhere else in the  
transaction. You could put it next to the shared P in OP_RETURN. OP_RETURN  
<P> <Q2'> would be 66 bytes.

But then Mallory could generate transactions with the right Q2' but with  
his own pubkey in Step 2 instead of Q. So your scanner would detect a  
payment, but you wouldn't be able to spend it, and Mallory could.

That's a good argument for putting Q2' in a 2-of-2 multisig so that  
pulling this trick would at least make the transaction unspendable for  
both parties, which may be good enough deterrent, but you're still going  
to want to check it against your 'd' before fulfilling a large order. Your  
online watch process could queue the matching transactions, which you  
could move to your offline machine, decrypt your key, and verify the  
transactions are spendable.

Now, you would need to get two pubkeys to the payer, throw in a prefix to  
help standardize it, and end up with addresses that could look like (for  
example):

xSTLxsn59oaupR6ZKt2yddQ4dp5hcFinnTWkvsDiXtHgAEDg5ajNVzTY8MMQsmqnEn3ZMKxQzrfC3pDimfTWMkiUb7x3jX3J26JSX
tSTLcpwzupCFL3maVZkSiB9ib3BXsCAfkhMLgckQEyoj8Tk83ANzofeuDdbX6bSPqNRfACLLFYK8EwVo1jdjxNDFNDWxhnQiAy4ba

Those addresses are 74 bytes:  
<Prefix><CompressedPubKey1><CompressedPubKey2><Checksum>

   xSTL Prefix = 0xC0CB9270
   tSTL Prefix = 0xB2E27D50
   NOTE: I do NOT have the corresponding privkeys for these four pubkeys!

Those just happened to be the first matching prefixes I found for 74 byte  
addresses. I could try to find ones which start with a specific byte if  
that's somehow better, like 0x04 to match BIP32.

Unfortunately, I don't think you can just derive a second public key from  
the first to keep the address shorter, and still keep the first private  
key secure, even if the second private key is stolen. You only get  
equivalent security as BIP32 public derivation, where you can't lose a  
child private key.

Do we also want xSTL (or whatever user friendly string) prefixes for  
single pubkey (41 byte) stealth addresses?

I'll wait a couple days for feedback, then I'll try to implement the  
following prototypes:

1) Pay to STL addresses
2) Watcher process to detect and queue STL payments for a given d2/Q2
3) Offline verifier to take output from Watcher and verify spendable given  
encrypted d/d2

Obviously extending QT directly for #1 would be ideal, I may even be able  
to do that since supporting a new address type should be fairly contained.  
But if not I'll punt to writing a node.js or python script which connects  
to bitcoind via RPC.

Thanks,
Jeremy

[1] - On Reusing Ephemeral Keys in Diffie-Hellman Key Agreement Protocols
       http://www.math.uwaterloo.ca/~ajmeneze/publications/ephemeral.pdf

[2] - Validation of Elliptic Curve Public Keys
       http://www.iacr.org/archive/pkc2003/25670211/25670211.pdf

Re: [Bitcoin-development] Stealth Addresses

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]

On Fri, Jan 10, 2014 at 11:28:33AM +0000, Drak wrote:
> On 10 January 2014 10:20, Peter Todd <pete@petertodd.org> wrote:
> 
> > Oh, sorry, I forgot to mention it in my first write-up but you can
> > easily make stealth addresses include a second pubkey for the purpose of
> > the communication that either isn't used in the scriptPubKey at all, or
> > is part of a n-of-m multisig. (n>=2) Interestingly that also means you
> > can give a third-party that key and out-source the effort of scanning
> > the blockchain for you.
> 
> 
> That seems pretty exciting to me. What is the chance of this becoming a BIP?

Needs a prototype implementation first. The version with no prefix is
the simple one and doesn't have any other dependencies; the prefix
version is harder because it isn't clear yet what's the best way to
force the prefix, or for that matter whether scriptPubKey or
H(scriptPubKey) indexes will be available.

It's on my todo list, but as you've probably noticed my todo list is
rather long. :)

-- 
'peter'[:-1]@petertodd.org
00000000000000028a5c9edabc9697fe96405f667be1d6d558d1db21d49b8857

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Drak]

[-- Attachment #1: Type: text/plain, Size: 540 bytes --]

On 10 January 2014 10:20, Peter Todd <pete@petertodd.org> wrote:

> Oh, sorry, I forgot to mention it in my first write-up but you can
> easily make stealth addresses include a second pubkey for the purpose of
> the communication that either isn't used in the scriptPubKey at all, or
> is part of a n-of-m multisig. (n>=2) Interestingly that also means you
> can give a third-party that key and out-source the effort of scanning
> the blockchain for you.


That seems pretty exciting to me. What is the chance of this becoming a BIP?

Drak

[-- Attachment #2: Type: text/html, Size: 962 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2331 bytes --]

On Wed, Jan 08, 2014 at 02:20:57AM -0800, Jeremy Spilman wrote:
> Thanks Peter for the paper!
> 
> I'm just going to restate your 'simple explanation' to make sure I
> got it...
> 
> The payee publishes a public key of theirs, which will be a
> long-standing identifier, public key = 'Q', corresponding private
> key = 'd'.
> 
> To pay them, payee generate a keypair, private key = 'e' public key
> of 'P'. Publish 'P' in the transaction.
> 
> The payer can calculate S = eQ, where S is a shared secret between
> payer/payee. The payee calculates the same S as S = dP. So the payee
> sees 'P' in a transaction, and multiplies by their private key, to
> get S.
> 
> Now that we have the shared secret, either side can calculate an
> offset to Q which becomes the pay-to-address. When you say
> BIP32-style derivation, Q' = H(S) + Q, does this mean Q +
> SHA256(33-byte S)?

I think that's correct, but my ECC math is a bit shakey... In any case,
what's important is that you can derive a pubkey such that only the
recipient has the privkey, and without knowledge of the shared secret
you can't determine what the recipients master pubkey was.

> A payee has to check each transaction (or every transaction of a
> fixed prefix) with 'P', calculate Q' = Q + H(dP) and see if that
> transaction pays to Q'. If the address matches, then the payee can
> spend it with private key of d + H(dP).

Yup, you're understanding matches mine. (no guarantee if my
understanding is correct!)

> One downside is that you have to hold your private key in memory
> unencrypted in order to identify new payments coming in. So
> stealth-addresses may not be suitable for receiving eCommerce
> payments, since you can't implement a corresponding watch-only
> wallet, e.g. there's no way to "direct-deposit into cold storage."

Oh, sorry, I forgot to mention it in my first write-up but you can
easily make stealth addresses include a second pubkey for the purpose of
the communication that either isn't used in the scriptPubKey at all, or
is part of a n-of-m multisig. (n>=2) Interestingly that also means you
can give a third-party that key and out-source the effort of scanning
the blockchain for you.

-- 
'peter'[:-1]@petertodd.org
00000000000000028a5c9edabc9697fe96405f667be1d6d558d1db21d49b8857

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Jeremy Spilman]

Thanks Peter for the paper!

I'm just going to restate your 'simple explanation' to make sure I got  
it...

The payee publishes a public key of theirs, which will be a long-standing  
identifier, public key = 'Q', corresponding private key = 'd'.

To pay them, payee generate a keypair, private key = 'e' public key of  
'P'. Publish 'P' in the transaction.

The payer can calculate S = eQ, where S is a shared secret between  
payer/payee. The payee calculates the same S as S = dP. So the payee sees  
'P' in a transaction, and multiplies by their private key, to get S.

Now that we have the shared secret, either side can calculate an offset to  
Q which becomes the pay-to-address. When you say BIP32-style derivation,  
Q' = H(S) + Q, does this mean Q + SHA256(33-byte S)?

A payee has to check each transaction (or every transaction of a fixed  
prefix) with 'P', calculate Q' = Q + H(dP) and see if that transaction  
pays to Q'. If the address matches, then the payee can spend it with  
private key of d + H(dP).

One downside is that you have to hold your private key in memory  
unencrypted in order to identify new payments coming in. So  
stealth-addresses may not be suitable for receiving eCommerce payments,  
since you can't implement a corresponding watch-only wallet, e.g. there's  
no way to "direct-deposit into cold storage."

Hope I got that right...

On Mon, 06 Jan 2014 04:03:38 -0800, Peter Todd <pete@petertodd.org> wrote:

> Using Elliptic curve Diffie-Hellman (ECDH) we can generate a shared
> secret that the payee can use to recover their funds. Let the payee have
> keypair Q=dG. The payor generates nonce keypair P=eG and uses ECDH to
> arrive at shared secret c=H(eQ)=H(dP). This secret could be used to
> derive a ECC secret key, and from that a scriptPubKey, however that
> would allow both payor and payee the ability to spend the funds. So
> instead we use BIP32-style derivation to create Q'=(Q+c)G and associated
> scriptPubKey.
>
> As for the nonce keypair, that is included in the transaction in an
> additional zero-valued output:
>    RETURN <P>

[Bitcoin-development] Stealth Addresses

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 9862 bytes --]

* Abstract

A Stealth Address is a new type of Bitcoin address and related
scriptPubKey/transaction generation scheme that allowers payees to
publish a single, fixed, address that payors can send funds efficiently,
privately, reliably and non-interactively. Payors do not learn what
other payments have been made to the stealth address, and third-parties
learn nothing at all. (both subject to an adjustable anonymity set)


* Acknowledgments

Credit goes to ByteCoin for the original idea.(1) Gregory Maxwell, Adam
Back, and others on #bitcoin-wizards contributed valuable input on the
implementation. Finally thanks goes to Amir Taaki for input on the
general idea of stealth addresses and use-cases.


* Background

Viewed generally a Bitcoin address is a mechanism by which a payee
instructs a payor to create a transaction such that the payee can spend
one or more of the transaction outputs. Of course, typically the address
is simply the hash of a pubkey, and the mechanism by which the funds are
made available to the payee is to simply create a scriptPubKey of the
following form:

    DUP HASH160 <pubKeyHash> EQUALVERIFY CHECKSIG

The problem however is address reuse: it is convenient for payees to
give one or more payor a single address and use it multiple times for
various purposes. This results in all those payments becoming trivially
linkable to each other by an attacker - a threat not only to the privacy
of the user, but also to all users of Bitcoin.(2)

BIP32 hierarchical deterministic wallets are frequently proposed as a
solution. Now an address is a chain code and the mechanism by which a
scriptPubKey is generated is to derive a one-time-use pubkey from that
chain code and some index i. However, this quickly runs into two main
problems:

1) Lack of privacy: While someone not in possession of the address can't
   link payments together, someone who is can.

2) State: If the index is not to be re-used wallets must either maintain
   per-address state, or somehow query for already used indexes, or
   somehow generate them in a sufficiently small range that the payee
   can recover the indexes. All these solutions are problematic.

A good example of where the BIP32-derivation solutions fails come up at
the Dark Wallet Hackathon where it was suggested by the author that for
the purpose of securing person-to-person payments OpenPGP public keys
and X.509 certificates be extended with a new user-id field containing a
Bitcoin address. Wallet software could then use either certificate
system to ensure funds were being sent to the intended recipients -
essentially a non-interactive way of solving what the BIP70 payment
protocol solves interactively. Of course, without stealth addresses the
scheme would likely have little or no privacy.


* Requirements

1) Generated scriptPubKey must be globally unique

2) Must be only spendable by payee

3) scriptPubKey and associated transaction must be indistinguishable to
   third-parties from other transactions in some anonymity set.

4) Method must be fully deterministic and funds recoverable from a
   wallet seed and blockchain data for both payee and payor.

5) Funds must be efficiently recoverable by payee with reasonable, and
   configurable, computation and bandwidth costs.

6) Must be compatible with CoinJoin/Must not leak information to payee
   about what txins were used to pay them.

7) Must be compatible with multisig-protected wallets.

8) Must not make assumptions about txin scriptSig form.

9) Must be possible to prove to third parties that payment was made in
   accordance to instructions without revealing any other information.


** Payment Reliability

Schemes for making payments by transmitting nonces to the recipient
through some other medium, such as Bitmessage, were discussed at the
Dark Wallet Hackathon. However using any medium but the blockchain
itself for the communication means that the reliability of the payment
getting to the recipient is less than that of a standard transaction.
For instance Bitmessage nodes only keep messages for two weeks. We
decided that anything less than reliable atomic transactions was
unacceptable.


* Applying encryption to payments, simple explanation

Using Elliptic curve Diffie-Hellman (ECDH) we can generate a shared
secret that the payee can use to recover their funds. Let the payee have
keypair Q=dG. The payor generates nonce keypair P=eG and uses ECDH to
arrive at shared secret c=H(eQ)=H(dP). This secret could be used to
derive a ECC secret key, and from that a scriptPubKey, however that
would allow both payor and payee the ability to spend the funds. So
instead we use BIP32-style derivation to create Q'=(Q+c)G and associated
scriptPubKey.

As for the nonce keypair, that is included in the transaction in an
additional zero-valued output:

    RETURN <P>

The payee recovers the funds by scanning the blockchain for candiate P's
in transactions, regenerating the scriptPubKey, and finally checking if
any txouts in the transactions match. Note the close similarity of this
technique to how the Bitmessage network functions - an initial
implementation of the idea will find the Bitmessage code a suitable
starting point.


* Trading off anonymity set size for decreased bandwidth/CPU

By taking advantage of prefix filters(3) we can choose a tradeoff
between anonymity set size and bandwidth/CPU usage if the payee
specifies that payments to them are to match some short prefix k. There
are a few possibilities for how the prefix is to the applied - the most
simple is if per-block indexes of scriptPubKeys are available:

    RETURN <k> <P>

Alternatively if per-block indexes of H(scriptPubKeys) are only
available the wallet software can grind the scriptPubKey with nonce i
until it matches the specified prefix:

    RETURN <i> <P>

Furthermore as symmetric ciphers are quite cheap we might as well hide
the purpose of the OP_RETURN txout and encrypt the pubkey P using H(Q)
as a symmetric key. This gives us a slightly larger anonymity set.


* Advantages of using a separate output

An alternative would be to either re-use a pubkey or signature nonce
value from a transaction input, saving about 45 bytes per txout. An
absolute minimum sized Bitcoin transaction is 166 bytes(4) so at best we
have a 27% savings in tx fees, and more typically around ~15%. (modulo
mass-payments from a single txin)

However using an explicit prunable OP_RETURN output to store the pubkey
rather than re-using one from a txin or txin signature has a number of
advantages:

1) The txin's owned by the payor are not revealed to the payee. In fact,
   they could be held by a third-party who simply makes a transaction
   with the appropriate txouts on behalf of the payee.

2) Less information about the txouts is leaked. The statistical
   distribution of txouts remains unchanged - not possible in re-use
   schemes because they need to grind the payee scriptPubKey's for the
   sake of the prefix filters.

3) If required the nonce secret can be revealed to prove that a payment
   was made to a third-party, e.g. for dispute resolution.


* Bare CHECK(MULTI)SIG output alternative

An alternative with better efficiency could be to use bare
OP_CHECK(MULTI)SIG outputs to hold the nonce pubkey - generally a second
output is needed anyway for change. The most simple would be to use Jeff
Garzik's OP_DROP proposal(5) for the prefix:

  <prefix> DROP n <pubkey>...<pubkey> m CHECKMULTISIG

  or

  <prefix> DROP <pubkey> CHECKSIG

The payor pubkey is in the *change* txout, and the payee's ECDH-derived
pubkey in the other txout. By setting the prefix to be the same on both
txouts and using the same basic scriptPubKey form the relationship of
change and payment is still hidden; CoinJoin-using implementations can
adopt even more sophisticated approaches.

If IsStandard() rules remain the same and using OP_DROP is impractical,
we can also grind the change pubkey to match the prefix in a
deterministic manner so the wallet can still be recovered from a seed.
More costly, but maybe still acceptable for reasonably short prefixes.
Either way the result is transactions that are actually smaller and
cheaper than standard transactions, although without the advantage of
pushing scriptPubKey size payment to the receiver. (a pity we didn't
spend the extra time to adopt OP_EVAL)

A disadvantage is that revealing the nonce secret to prove a payment was
made is more problematic - either the txout needs to be spent first, or
we need a CHECKMULTISIG.


* Address format

To be decided. To support mulisig we probably want the ability to
specify n-of-m master pubkeys, using the nonce to generate derived ones.
For the single pubkey case the addresses will be a little longer than
standard Bitcoin addresses:

  s9KND3vfXjs3YqfZp86Acce3bM7Mhuptwh6mjeDnThsDei9Z2ZZcU

  vs.

  1LZn91ynrA6BCmoUKwnV3Ygk4FQMfPxLbg


1) ByteCoin, Untraceable transactions which can contain a secure message
   are inevitable, https://bitcointalk.org/index.php?topic=5965.0

2) Gregory Maxwell, Dark Wallet Certification discussions, also
   http://snowdenandthefuture.info/PartIII.html

3) Peter Todd, [Bitcoin-development] Privacy and blockchain data,
   http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03612.html

4) Bitcoin Wiki, Maximum transaction rate,
   https://en.bitcoin.it/w/index.php?title=Maximum_transaction_rate&oldid=36983

5) Jeff Garzik, Add small-data OP_DROP transactions as standard
   transactions, https://github.com/bitcoin/bitcoin/pull/1809

-- 
'peter'[:-1]@petertodd.org
0000000000000002861ee0919fc86990573ac360820766dc1b9ba580e5ccf7b6

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]