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:

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

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

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

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

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

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

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

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

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.

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

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

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

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

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,

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

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

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

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

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

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

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

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.)

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

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

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

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

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,

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

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

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

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

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

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

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

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

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:

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

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

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

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 ..

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

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:

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

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

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

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

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

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

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):

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

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