Re: [Bitcoin-development] Stealth Addresses

2014-03-06 Thread 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)


--
Subversion Kills Productivity. Get off Subversion  Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/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

2014-01-18 Thread Jeremy Spilman


 On Fri, Jan 17, 2014 at 8:55 PM, Alan Reiner etothe...@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...

--
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=119420431iu=/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

2014-01-18 Thread Gregory Maxwell
On Sat, Jan 18, 2014 at 3:12 PM, Jeremy Spilman jer...@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…

--
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=119420431iu=/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

2014-01-17 Thread Mike Hearn
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=ischq=stealth

But everyone loves privacy.


On Fri, Jan 17, 2014 at 8:49 AM, Drak d...@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 p...@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
 0001b0e0ae7ef97681ad77188030b6c791aef304947e6f524740


 --
 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=119420431iu=/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=119420431iu=/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

2014-01-17 Thread 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-

--
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=119420431iu=/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

2014-01-17 Thread Natanael
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 m...@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=ischq=stealth

 But everyone loves privacy.


 On Fri, Jan 17, 2014 at 8:49 AM, Drak d...@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 p...@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
 0001b0e0ae7ef97681ad77188030b6c791aef304947e6f524740


 --
 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=119420431iu=/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.

 

Re: [Bitcoin-development] Stealth Addresses

2014-01-17 Thread Drak
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 m...@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=ischq=stealth

 But everyone loves privacy.


 On Fri, Jan 17, 2014 at 8:49 AM, Drak d...@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 p...@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
 0001b0e0ae7ef97681ad77188030b6c791aef304947e6f524740


 --
 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=119420431iu=/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=119420431iu=/4140/ostg.clktrk
 ___
 Bitcoin-development 

Re: [Bitcoin-development] Stealth Addresses

2014-01-17 Thread joseph
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.
--
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=119420431iu=/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

2014-01-17 Thread Peter Todd
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=ischq=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
0001c9b372ed519ecc6d41c10b42a7457d1ca5acd560a535596b


signature.asc
Description: Digital signature
--
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=119420431iu=/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

2014-01-17 Thread Ben Davenport
Well, at least we don't have to worry about cache invalidation.

Ben


On Fri, Jan 17, 2014 at 6:46 AM, Peter Todd p...@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=ischq=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
 0001c9b372ed519ecc6d41c10b42a7457d1ca5acd560a535596b


 --
 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=119420431iu=/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=119420431iu=/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

2014-01-17 Thread 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 m...@plan99.net
 mailto:m...@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=ischq=stealth
 
 But everyone loves privacy.
 
 
 On Fri, Jan 17, 2014 at 8:49 AM, Drak d...@zikula.org
 mailto:d...@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 p...@petertodd.org
 mailto:p...@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
 

Re: [Bitcoin-development] Stealth Addresses

2014-01-17 Thread Gregory Maxwell
On Fri, Jan 17, 2014 at 8:55 PM, Alan Reiner etothe...@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.

--
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=119420431iu=/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

2014-01-16 Thread Wladimir
On Thu, Jan 16, 2014 at 7:26 AM, Gary Rowe g.r...@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
--
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=119420431iu=/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

2014-01-16 Thread Drak
On 16 January 2014 00:05, Jeremy Spilman jer...@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=119420431iu=/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

2014-01-16 Thread Mike Hearn
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 d...@zikula.org wrote:

 On 16 January 2014 00:05, Jeremy Spilman jer...@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=119420431iu=/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=119420431iu=/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

2014-01-16 Thread Peter Todd
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
0001b0e0ae7ef97681ad77188030b6c791aef304947e6f524740


signature.asc
Description: Digital signature
--
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=119420431iu=/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

2014-01-16 Thread Johnathan Corgan
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: johnathan.vcf

signature.asc
Description: OpenPGP digital signature
--
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=119420431iu=/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

2014-01-16 Thread 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? :-)

--
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=119420431iu=/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

2014-01-16 Thread Drak
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 p...@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
 0001b0e0ae7ef97681ad77188030b6c791aef304947e6f524740


 --
 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=119420431iu=/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=119420431iu=/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

2014-01-15 Thread Gregory Maxwell
On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport bendavenp...@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=119420431iu=/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

2014-01-15 Thread Mike Hearn
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 jgar...@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 gmaxw...@gmail.comwrote:

 On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport bendavenp...@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=119420431iu=/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=119420431iu=/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=119420431iu=/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

2014-01-15 Thread 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 r...@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/

--
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=119420431iu=/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

2014-01-15 Thread Roy Badami
On Wed, Jan 15, 2014 at 11:17:33PM +, 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.)

--
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=119420431iu=/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

2014-01-15 Thread Jeremy Spilman

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 secretI 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 jgar...@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 gmaxw...@gmail.com wrote:
On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport bendavenp...@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 improveawareness 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=119420431iu=/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

2014-01-15 Thread Gregory Maxwell
On Wed, Jan 15, 2014 at 4:05 PM, Jeremy Spilman jer...@taplink.co wrote:
 Might I propose reusable address.

I like this too.

--
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=119420431iu=/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

2014-01-15 Thread 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-

--
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=119420431iu=/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

2014-01-15 Thread 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 jgar...@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 gmaxw...@gmail.com
 wrote:
 On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport
 bendavenp...@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=119420431iu=/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=119420431iu=/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

2014-01-15 Thread Eric Martindale
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 jer...@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 jgar...@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 gmaxw...@gmail.comwrote:

 On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport bendavenp...@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=119420431iu=/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=119420431iu=/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

2014-01-15 Thread Gary Rowe
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 e...@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 jer...@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 jgar...@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 gmaxw...@gmail.comwrote:

 On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport bendavenp...@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=119420431iu=/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=119420431iu=/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=119420431iu=/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

2014-01-14 Thread Peter Todd
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 PaymentRequestPaymentDetails 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
bda8ab55740699711a11572c4eec9dc9f714e4896559aac310a115ff


signature.asc
Description: Digital signature
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.

Re: [Bitcoin-development] Stealth Addresses

2014-01-14 Thread Peter Todd
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
7dd7a87aec311fb7fb13770f54edf628e6976f8c6091a5b2638878a7


signature.asc
Description: Digital signature
--
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=119420431iu=/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

2014-01-14 Thread 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 PaymentRequestPaymentDetails 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.

Re: [Bitcoin-development] Stealth Addresses

2014-01-14 Thread Jeremy Spilman
On Tue, 14 Jan 2014 06:19:08 -0800, Peter Todd p...@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.


--
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=119420431iu=/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

2014-01-14 Thread Peter Todd
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
00010c474cd4e25913535ec1c166b6d43fbdd9a5f2726711ced7


signature.asc
Description: Digital signature
--
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=119420431iu=/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

2014-01-14 Thread 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


--
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=119420431iu=/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

2014-01-14 Thread Jeremy Spilman
On Tue, 14 Jan 2014 13:51:06 -0800, Adam Back a...@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);
}






--
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=119420431iu=/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

2014-01-14 Thread 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


--
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=119420431iu=/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

2014-01-14 Thread Drak
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=119420431iu=/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

2014-01-13 Thread 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

--
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=119420431iu=/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

2014-01-13 Thread 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

--
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=119420431iu=/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

2014-01-13 Thread Mike Hearn

 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!).
--
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=119420431iu=/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

2014-01-13 Thread Gregory Maxwell
On Mon, Jan 13, 2014 at 11:59 AM, Alan Reiner etothe...@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.

--
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=119420431iu=/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

2014-01-13 Thread 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

--
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=119420431iu=/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

2014-01-13 Thread Peter Todd
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
00023d5a8bbe131414328a6c50a2741933ba03775afd3c3db395


signature.asc
Description: Digital signature
--
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=119420431iu=/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

2014-01-13 Thread 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.

--
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=119420431iu=/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

2014-01-13 Thread Peter Todd
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
00013f56c73dbb82447ba01e303648109b2e7ea0adf6ca53a7ff


signature.asc
Description: Digital signature
--
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=119420431iu=/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

2014-01-12 Thread 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:  
PrefixCompressedPubKey1CompressedPubKey2Checksum

   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=119420431iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list

Re: [Bitcoin-development] Stealth Addresses

2014-01-12 Thread Mike Hearn
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 jer...@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:
 PrefixCompressedPubKey1CompressedPubKey2Checksum

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

 

Re: [Bitcoin-development] Stealth Addresses

2014-01-12 Thread Mike Hearn
On Sun, Jan 12, 2014 at 7:20 PM, Jeremy Spilman jer...@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.
--
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=119420431iu=/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

2014-01-12 Thread Gavin Andresen
On Sun, Jan 12, 2014 at 5:33 AM, Jeremy Spilman jer...@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
--
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=119420431iu=/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

2014-01-10 Thread Peter Todd
On Fri, Jan 10, 2014 at 11:28:33AM +, Drak wrote:
 On 10 January 2014 10:20, Peter Todd p...@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
00028a5c9edabc9697fe96405f667be1d6d558d1db21d49b8857


signature.asc
Description: Digital signature
--
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=119420431iu=/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

2014-01-08 Thread 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 p...@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


--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development