[Dev] Private Blockchain Addresses (Dark Blockchain)
-
To describe / develop / prototype / test - encrypting coin addresses in the Blockchain.
The idea is that the “same” coin address is passed / viewed through different “encrypted keys” removing the leakage of private information to an outside observer. The wallet would search its normal open addresses in the blockchain, + it would search for the encrypted address of any private addresses. Your wallet would have the key to view the unencrypted private addresses in your wallet.
Only the sender owner and receiver will see the unencrypted amount and address in their wallet as their private address will be part of the multi-signature encryption of the address…
Initially it was envisaged that the address and amount of a designated private address would be encrypted in the blockchain. By using multi-signature and Public / Private key technology, you would pass that amount in the private address, to a public or private address based on the receivers preference. If public is chosen the last address will be made public.
Further enhancements, for instance say to send a viewing password to another user to prove funds, may be required to make the system production ready.
https://github.com/wrapperband/PrivateBlockchainAddress
I have started a Github and will be transferring some ideas from the Dark Blockchain / privacy discussion to a white paper / functional requirements document.
As this is obviously a quite big, multi-disciplinary development, and its an “open source” idea so other might develop an alternative first. It could also take a long time + might end up to be impossible to implement…
I am limited in what I can do and have already too many things Feathercoin related on my plate, + am physics and still a novice on Github. I will be very open to any collaborators, just ask and I’ll add you.
-
I am interested in your project, it is very important to work. Where do we start?
-
https://github.com/wrapperband/PrivateBlockchainAddress
I have set up a development thread [Dev] for PBAs . The idea would be to develop or discus what is technically feasible. To that end I’ve done some more work on developing a white paper and functional requirement document on GitHub for the idea of Private Blockchain addresses and what they might look like, the scope of work.
If another technology or idea is available on the open source space or a small change to the software could give say 50% more privacy, then that could be developed instead.
The development would will need a wide area of combined expertise, the first probably cryptographic, to work out the level of multi signature and “vanity address” cryptographic system. i.e. is that cutting edge or trivial? and how safe they would be ie a big change but small extra privacy = no…
Programming would come next if that was feasible.
I’m making good progress on learning how to manage Github, and it will be a viable project as it can be forked. I see these as long term work, that we help maintain and encourage with bounties. (If other members feel passionate about them).
Additional privacy is one of a number of projects that have been proposed in the Feathercoin forum.
There have been so many things happening in the rapid development of Blockchain / p2p technology, the Feathercoin forum is a historical resource of potential projects. As an ex lecturer, I know that Universities, schools and hobbyist are always looking for interesting project to contribute to and it is the combination of Github and forum resources that can engender the development of the wider open source environment.
Github is extremely powerful, and it does seem that learning the complexity of it, hints at the complexity of what you can do with it. Also, the “incredibly more work” that would be involved, if you don’t have a version control system.
-
The reason is that the design has some problems and I think the same effect can be achieved in a better way.
https://medium.com/@octskyward/ecdh-in-the-payment-protocol-cb2f81962c1b
-
I we want a mint, we should launch a new coin. A mint system that you are proposing is the opposite of blockchain. Blockchain was invented to dispose of the need for mint. Try to wrap your head around this. What we can have is laundering (dark) wallet. Dark wallet concern is separate from blockchain concern.
-
I mean, you could have launched a mint-based coin years ago. 20 years ago there were coins like that, they just didn’t get so much media attention.
-
I we want a mint, we should launch a new coin. A mint system that you are proposing is the opposite of blockchain. Blockchain was invented to dispose of the need for mint. Try to wrap your head around this. What we can have is laundering (dark) wallet. Dark wallet concern is separate from blockchain concern.
I mean, you could have launched a mint-based coin years ago. 20 years ago there were coins like that, they just didn’t get so much media attention.
A Feathercoin technical development thread is generally accepted as a for technical discussion of the development / invention of Feathercoin related systems / software, such as PBAs. At Feathercoin the technical forum acts like a “mailing list” for discussion between the contributors.
There are other reasons to persue a project apart from success. For instance, I am interested to learn more about cryptography, learn to use Github and pass on some software documentation skills (I used to have before I was ill). Apart from the addition code inspection and testing pro-typing such a system would enable and possible ways round problems or limitations of various possibilities.
As with other Feathercoin developments, like eHRC for the mining Difficulty change algorithm and the proposed Neo-scrypt hashing algorithm changes, they are areas of the code that are never changed in Bitcoin, so are good specialisation / niche to look at gaining expertise in. + Increase support skills & fun.
If you wish to discus the ethics of PBA’s or whether Feathercoin should adopt PBAs (should they be “invent able”), the Feathercoun discussion forum thread can be used.
https://forum.feathercoin.com/index.php?/topic/7523-proposed-anonimity-feature-the-dark-blockchain/
-
The reason is that the design has some problems and I think the same effect can be achieved in a better way.
https://medium.com/@octskyward/ecdh-in-the-payment-protocol-cb2f81962c1b
Very interesting. It just shows how PBAs design actually solves the problems of stealth addresses!.
1. The extra key - is not necessarily needed - the address and some other factor (eg, part of the private key or part of transaction amount) is used to create the encrypted address. If there is an extra key, it will be private and stored with the user.
2. Finding your coins. This is trivial, the wallet stores the address and the encrypted address and searches for either. + you send both at transaction.
3. It needs no extra central authority. at transfer the ability to decrypt the address is sent using the same cryptographic methods as used in the ability to transfer. It may be limitation that the addresses are exposed at transfer (mining the block)
-
Just reading thing in **electrum **Github:
Re: [electrum] Added ability to send TO stealth addresses. (#817)
That is not how the Stealth Address protocol works.
1 output to stealth requires 1 OP_RETURN directly before it. (so if stealth send p2kh/p2sh is vout 3 then OP_RETURN with that send’s ephemeral key MUST be vout 2. If 2 stealth sends are at vout 3 and vout 7, then vout 2 MUST be the ephemeral key for vout 3 and vout 6 MUST be the ephemeral key for vout 7.
https://wiki.unsystem.net/en/index.php/DarkWallet/Stealth#Transaction_format
referenceIn lib/wallet.py:
> if type == ‘op_return’:
> assert len(data) < 41, “string too long”
> assert value == 0
> if type == ‘address’:
> assert is_address(data), “Address " + data + " is invalid!”
> + if is_stealth_address(data):
> + newaddr, op_ret = get_stealth_send(data)
> + lst = list(outputs[i])
> + lst[1] = newaddr
> + outputs[i] = tuple(lst)
> + outputs.insert(i, [‘op_return’, op_ret, 0])
> + stealth_ops.append(i)â€"
Reply to this email directly or view it on GitHub.
-
The Dark wallet paper on Wiki shows how the cryptography might be used to acheive privcy via Multisig stealth and Dual-key stealth
Dual-key stealth
Say we want to keep our stealth spending key private, yet still be able to scan for payments to us. Normally to scan a stealth payment, we need to decrypt our stealth key to see if payments are received. This is unacceptable for wallets to do without user interaction as it risks compromising their wallet.
We can instead use a dual-key stealth scheme.
This is the scheme that DarkWallet implements as it’s main stealth functionality.
Receiver:
Q = public scan key (EC point, 33 bytes) d = private scan key (integer, 32 bytes) R = public spend key f = private spend key Q = dG R = fG stealth address:Sender (has Q, not d):
P = eGBy publishing P, only sender and receiver have access to c:
c = H(eQ) = H(dP)Sender:
R' = R + cGReceiver:
R' = R + cG [without decrypting wallet] = (f + c)G [after decryption of wallet] [Remember: mod curve.order and pad with 0x00s where necessary]In this scheme, we can use the scan keypair (Q, d) to generate the shared secret c, and then hence derive the address from the public part R.
Ref: https://wiki.unsystem.net/en/index.php/DarkWallet/Stealth#Dual-key_stealth
-
Electrum is doing some Github changes with Stealth Addresses.
As I understand it it, this implementation of privacy is a meta level above Bitcoin. The wallet itself adds any addition fields or processes and uses additional systems and Electrum code to store and initiate the process.
As such SAs are different to the PBA (Private Blockchain Address) possibility, which is intrinsic to the system.
The idea that the encrypted address is a “semi valid” or even a “valid Address”, and the investigation of how that could be implemented still seems novel. It gives an extra level of privacy to PBAs, it may be made be difficult to identify an Address is private.
If I print my stealth address on a business card, how do I know which of my clients paid the retainer?
I already mentioned that it is not for merchants. If it was a personally known business acquaintance, you could call him up on the phone or send an email and say “oh btw I send x BTC for y.” and that would suffice up to a certain amount, I’m sure. Not to mention if the self-proclaimed sender knows the txid, then he’s already slightly more likely to be telling the truth, as the only people knowing the txid with stealth are the sender and the receiver. (or anyone who can view their tx histories)
Asking this sounds like: “If one of my clients e-mails me, how do I know which client is the one that e-mailed me? He could be someone pretending to be my client with a spoofed mail address, or a co-worker that’s using his workstation.”
This is why we don’t use e-mail for earth shattering important conversations and we don’t use stealth addresses to transfer 30,000 bitcoins.
If you want to, Electrum 2.0 allows generic OP_RETURN message writing with OP_RETURN “TEXT” and the user could put some identifying number in there or their name if they want to.
If you’re trying to argue against the existence of static non-reusable address protocols, this is not the place. spesmilo/sx would be better place to voice concerns.
However, if you have a reason for this to not be merged that isn’t “This is dumb, so we don’t need it in Electrum” then I am all ears. Also, if you find something fundamentally wrong with my code, please feel free to say so.
Re: [electrum] Added ability to send to stealth addresses. (#817)
I’m not objecting merging this, rather suggesting it gain some additional functionality. That could very well be a future pull request, but it might make sense to add it on here.
-
This guy has really got my interest… Wrapper, do you think it’s worthwhile contacting him and seeing if he can help us do it?
From what I understand this is kinda what we want…
https://medium.com/@octskyward/ecdh-in-the-payment-protocol-cb2f81962c1b
Once the above is implemented, it would be useful to define more BIP70 extensions to let people put (unauthenticated) names/pseudonyms, pictures and contact details into a payment request. People can then populate their wallets address books by loading up such files, and community run directory sites can make paying someone as easy as looking them up online. This does not require ECDH/stealth addresses of course because a wallet can always just constantly upload new versions of the payment request whenever a payment is received, but it does simplify things and avoids small amounts of reuse that could occur if a wallet was offline for a while.
The infrastructure I just talked about can be easily implemented by any reasonable programmer one step at a time, in layers. If you’re interested in experimenting with this, drop me a line: mike@plan99.net
Also, is there a way we can tie light addresses into this project at the same time?
Could we ask “Mike” if he thinks it could be achievable at the same time?
-
If I have time, I will promote this work.
-
Cheers Calem - interesting read,
I agree with him (mike@plan99.net) in his critique of stealth addresses. He certainly has thought about the subject from a technical point of view.
https://medium.com/@octskyward/ecdh-in-the-payment-protocol-cb2f81962c1b
I’d be interested to see how quickly he can trash private addresses. Although, PAs do seem to get over many of the problems he sees with the very similar “large public key” method of privacy.
e.g. being able to index the address, so the wallet can find relevant transactions. Also, where one option is to make the private addresses indistinguishable from normal transaction addresses.
As you know, I’ve outlined the idea in the best detail I can and the next step would be to some test coding to see if it at all viable.
I’m just getting round to learning more about the history and state of multi-signature wallets and BIP’s. Although that is to look at whether we can change the multisignature address start values, doing that work would get us more up to speed on how private addresses might be implemented.
I sent Mike an email to see what he thinks.
-
The main thing we need with private addreses etc, is that there needs to be an Audit Key that can be used to give to tax agents accountants or tax agencies/gov etc.
-
Just thought I would mention, on the opposite end of the spectrum here…
https://github.com/opennamesystem/openname-directory
https://openname.org/aboutOVERVIEW
The Openname System (ONS) is a protocol that extends DNS by supporting the registration and resolution of:
- user handles on the blockchain (DNS for people)
- domains on the blockchain (decentralized DNS)
…all with full DNS backwards-compatibility.
ONS = ICANN DNS + blockchain handles + blockchain domainsONS currently uses namecoin as a key-value store but the system is blockchain-agnostic.
I don’t want to add yet another project, but this is something that we need to sort out in time as well.
-
Develop a wallet option to have individual addresses for each transaction.
Mike says he thinks you can’t encrypt the address, in order to make each transaction individual, (he doesn’t explain why), but that we could use the same idea to make transactions more private, without encryption.
We could just do the “make it easier to have individual addresses” part of private addresses white paper. I can’t quite see how this would work, as my mechanism was to have an extra layer, that the receiver and sender would have access to, via their keys, to show the link behind the encrypted address.
As with private addresses, if each transaction uses individual addresses then there is much less information leaked. This would make each transaction more like cash, as Satoshi envisaged. It would depend how the individual address could be made and decoded by the wallet whether it would remove the need for a cryptographer to be involved with the software development to make any progress.
https://medium.com/@octskyward/ecdh-in-the-payment-protocol-cb2f81962c1b
-
Is this what Bush is currently working on?
-
Yes, Stealth Address start , me and Bush.
-
Stealth Address will was created in wallet, The use of it in much the same way as normal. Stealth Address ,The length of more than 35 .
