Re: [Bitcoin-development] Stealth Addresses
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
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
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
-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
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
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
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
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
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
-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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
-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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
