Bump for bitcoin2 sending support:
https://twitter.com/ryanxcharles/status/514224778052243456
Topic: [Tracker] Stealth Address Support (Read 4972 times)
Making stealth addresses "tip jar only" makes them far less interesting. There is no reason that all payments couldn't be done with this kind of address— assuming it was well constructed, and users would be much less private if only a narrow usecase uses them.
I agree. This, or something like it, needs widespread adoption. Before we have widespread adoption we need careful reveiw and massive testing. Before review we need a well written spec and for massive testing we need POC, alpha and beta software.
Thanks! I will read up on it.
gmaxwell: what is your opinion on this? Seems like you are saying that it is a good idea but not yet ready for prime time (needs more work)? Or, is the DW specification good enough to implement in other wallets and get this thing off the ground?
gmaxwell: what is your opinion on this? Seems like you are saying that it is a good idea but not yet ready for prime time (needs more work)? Or, is the DW specification good enough to implement in other wallets and get this thing off the ground?
If I want to actually use a stealth address right now, for example publish one in my signature, what are my options?
If I were to publish a stealth address in my signature would anyone be able send me BTC?
Right now I believe you'd have to be using Dark Wallet to receive stealth address payments.If I were to publish a stealth address in my signature would anyone be able send me BTC?
Also, only Dark Wallet is capable of sending to stealth addresses, but as noted above at least one other client is actively working to implement DW-compatible stealth addresses
Has the specification been completed or are the details still being hashed out? If there is a specification where can it be found?
It's complete enough to be implemented in Dark Wallet (which Works For Me, despite it's scary alpha warning)This the only documentation I know of:
https://wiki.unsystem.net/en/index.php/DarkWallet/Stealth
If I want to actually use a stealth address right now, for example publish one in my signature, what are my options?
If I were to publish a stealth address in my signature would anyone be able send me BTC?
Has the specification been completed or are the details still being hashed out? If there is a specification where can it be found?
I obviously really like this idea and I just want to get a sense of where we are at on it and learn more about the technical details with an eye to contributing in some way.
Privacy/fungibility is a hot topic item for me. I am a very experienced programmer (>30 years of experienced) with very good cryptographic and Bitcoin knowledge. Where is the most effective and current work being done on this idea? In other words, where would I go to be most effective in my contributions?
If I were to publish a stealth address in my signature would anyone be able send me BTC?
Has the specification been completed or are the details still being hashed out? If there is a specification where can it be found?
I obviously really like this idea and I just want to get a sense of where we are at on it and learn more about the technical details with an eye to contributing in some way.
Privacy/fungibility is a hot topic item for me. I am a very experienced programmer (>30 years of experienced) with very good cryptographic and Bitcoin knowledge. Where is the most effective and current work being done on this idea? In other words, where would I go to be most effective in my contributions?
"Stealth addresses" as currently proposed break what already works pretty severely— using a different address per user makes scanning have a quadratic cpu costs in the number of payments you receive. Bytecoin/monero/etc. have payment IDs which address the issue, though the don't have a way to serialize them with the address— so they get accidentally left out a lot, which seems like an easy-to-address shortcoming.
Seems to me that the payment protocol solves this problem. The merchant should look for tx(s) received in Payment messages, not for stealth payments.
can you explain payment ids? how do users make sense of the data?
say a website posts a single address, users send payments to it... at some point the user has to send something to the website so they know which payment is which... why don't they just transmit the decrypted shared secret that only the sender should have? that way the website knows it was them that sent the payment.
or if the website sends a nonce to the user so they can make repeating payments then the website can issue the same stealth address but with different prefixes for each user. that makes it highly efficient for the website to receive payments by scanning a single stealth address and separating based on their stealth_prefix into different users.
say a website posts a single address, users send payments to it... at some point the user has to send something to the website so they know which payment is which... why don't they just transmit the decrypted shared secret that only the sender should have? that way the website knows it was them that sent the payment.
or if the website sends a nonce to the user so they can make repeating payments then the website can issue the same stealth address but with different prefixes for each user. that makes it highly efficient for the website to receive payments by scanning a single stealth address and separating based on their stealth_prefix into different users.
There is no reason that all payments couldn't be done with this kind of address— assuming it was well constructed, and users would be much less private if only a narrow usecase uses them.
So the entire Bitcoin ecosystem should wait around for your NIH solution to be ready instead of taking advantage of the immediate improvement that's available right now? 
On the Payment Ids issue - if 2 people are sending to me anonymously why not create a "satoshi" string at the end.
For example
Justus owes me 1 BTC as does you for a service -
I work with Justus and have him send me 1.00001234 string and gmaxwell is 1.00001235
Thats pretty inefficient and not very private. It would be straightforward enough to just allow a suffix on addresses e.g. For example
Justus owes me 1 BTC as does you for a service -
I work with Justus and have him send me 1.00001234 string and gmaxwell is 1.00001235
B123456789BCDFG-00001 and encrypt the suffix using the negotiated ephemeral key and include it in the aux data.
Already we seem to have not learned from the experience with this kind of address in Bytecoin/Monero/etc.— Payment IDs are an important feature but also a usability challenge with the way they're implemented in BCN/XMR/.... Right now with the way dark wallet implements this if you ask two different parties to pay you with the same address and only one of them does, you cannot tell which one paid you.
How is this any different than the problem we have right now without stealth addresses?1) Some merchant uses a blockchain.info wallet containing a single address to accept payments (yes, people really do this).
2) They give the address to two customers.
3) Only one customer pays.
4) Merchant doesn't know which customer paid without asking them.
It doesn't make sense to delay stealth addresses because they don't solve every problem.
"Stealth addresses" as currently proposed break what already works pretty severely— using a different address per user makes scanning have a quadratic cpu costs in the number of payments you receive. Bytecoin/monero/etc. have payment IDs which address the issue, though the don't have a way to serialize them with the address— so they get accidentally left out a lot, which seems like an easy-to-address shortcoming.
Making stealth addresses "tip jar only" makes them far less interesting. There is no reason that all payments couldn't be done with this kind of address— assuming it was well constructed, and users would be much less private if only a narrow usecase uses them.
Already we seem to have not learned from the experience with this kind of address in Bytecoin/Monero/etc.— Payment IDs are an important feature but also a usability challenge with the way they're implemented in BCN/XMR/.... Right now with the way dark wallet implements this if you ask two different parties to pay you with the same address and only one of them does, you cannot tell which one paid you.
How is this any different than the problem we have right now without stealth addresses?1) Some merchant uses a blockchain.info wallet containing a single address to accept payments (yes, people really do this).
2) They give the address to two customers.
3) Only one customer pays.
4) Merchant doesn't know which customer paid without asking them.
It doesn't make sense to delay stealth addresses because they don't solve every problem.
Hi, sx supports stealth. I wrote these commands to aid developers as a debugging tool:
http://sx.dyne.org/stealth.html
for anonymity I don't want people to differentiate payments sent to me. If it's needed you can already shard payments by grinding the prefix to differentiate. https://wiki.unsystem.net/en/index.php/DarkWallet/Stealth#Comparing_prefixes
I prefer a simple proposal that does one thing rather than trying to second guess every possible future use case we're not aware of yet. It's the UNIX philosophy: https://en.wikipedia.org/wiki/Worse_is_better
http://sx.dyne.org/stealth.html
for anonymity I don't want people to differentiate payments sent to me. If it's needed you can already shard payments by grinding the prefix to differentiate. https://wiki.unsystem.net/en/index.php/DarkWallet/Stealth#Comparing_prefixes
I prefer a simple proposal that does one thing rather than trying to second guess every possible future use case we're not aware of yet. It's the UNIX philosophy: https://en.wikipedia.org/wiki/Worse_is_better
Maybe they need to be renamed to "tip addresses" or something to make sure people don't use them in situations where they are not appropriate.
Already we seem to have not learned from the experience with this kind of address in the Bytecoin/Monero space— the payment IDs are an important feature but also a usability challenge with the way they're implemented there. Right now with the way dark wallet implements this if you ask two different parties to pay you with the same address and only one of them does, you cannot tell which one paid you.
I don't think stealth addresses are ever going to be appropriate for anything other than online tip jars. They do a great job in that role.If you want to know who has paid you, then you should give them an xpub specific to them and let them use that from that point on.
See my comment on this gist:
https://gist.github.com/ryanxcharles/1c0f95d0892b4a92d70a
There are a great many things that can be done wrong— including the fact that a poorly done reusable-address proposal can preclude adoption of a good and usable one ("We've already got that, low priority to add another one", "We're not going to spent time on that— as you can see it's not widely used"). An early flaw was already avoided where it would be incompatible with having a third party scan for you or hardware wallets... lots of stuff to possibly get wrong in this space.
Already we seem to have not learned from the experience with this kind of address in Bytecoin/Monero/etc.— Payment IDs are an important feature but also a usability challenge with the way they're implemented in BCN/XMR/.... Right now with the way dark wallet implements this if you ask two different parties to pay you with the same address and only one of them does, you cannot tell which one paid you.
Already we seem to have not learned from the experience with this kind of address in Bytecoin/Monero/etc.— Payment IDs are an important feature but also a usability challenge with the way they're implemented in BCN/XMR/.... Right now with the way dark wallet implements this if you ask two different parties to pay you with the same address and only one of them does, you cannot tell which one paid you.
In addition, stealth addresses only need to be better than the current standard of "publish a static address that anyone can look up in blockchain.info" in order to represent an improvement. The only thing they could possibly get wrong and be worse than what we have now is leak private keys.
New address types should not see widespread use without extensive review for cryptographic and privacy weaknesses and functionality footguns. This really needs a clear specification.
All true, and at the same time we don't want this to turn into a Waiting for Godot situation."Inadequate review" could be a great excuse to pigeonhole the functionality indefinitely.
Petertodd claimed to be working on a BIP and reserved a number but hasn't proposed any text. https://github.com/bitcoin/bips/blob/master/bip-0063.mediawiki
New address types should not see widespread use without extensive review for cryptographic and privacy weaknesses and functionality footguns. This really needs a clear specification.
New address types should not see widespread use without extensive review for cryptographic and privacy weaknesses and functionality footguns. This really needs a clear specification.
Jump to: