Proposed anonimity feature : The Dark Blockchain
-
… where you send an decoding address to the Tax office, or an auditor so they can view your books.
You can always send your coins to a new private address - once you have released a viewing address, to make them dark again…
This idea is growing. I like it.
If we can increase anonymity whilst still been able to be fully transparent, I can’t see a problem with it. As long as we have a secure way for the gov to audit our dark transactions, then we have a winner.
-
http://www.coindesk.com/australian-bitcoin-industry-unhappy-tax-office-issues-guidelines/
Personal and business compliance
To comply, Australian tax-domiciled businesses and individuals involved in bitcoin transactions will be required to keep records of:
(a) dates of transactions;
(b) the value in Australian dollars as listed on a “reputable online exchangeâ€;
© the purpose of the transaction; and
(d) who the other party is (a bitcoin address will suffice).Australia has just issued tax guidance on how it plans on regulating bitcoin… Specifically…
Titled Tax treatment of crypto-currencies in Australia â€" specifically Bitcoin, the four-page guideline document is a “general in nature†draft version only, and not yet legally binding.
So if there’s a way we could implement a super easy way for people to comply with the first quote, then I can see people opting for ftc over btc simply because we make it super easy for them to declare tax with their accountant or respective government.
-
Build in some kind of export function in the Qt…
-
Hi,
Name suggestion - Batcoin - because they fly in the dark.
Hmm. maybe too close to Bitcoin.
Cheers
Dave
-
Hi all,
OK - so I’ve just caught up on the conversation over the past few days. I’m a little bit confused so maybe I can recap and see if I have got what is being proposed?
Changes
-
The blockchain stays as is, a public ledger showing all transactions, values, etc - So no dark blockchain (encrypted, mixing, etc).
-
Add the ability to have a white address. A white address links to and identifies a “standard” address (Name, Address? facebook account? twitter?).
-
At the same time we reuse the tech for 2) to add the ability to have an encrypted “dark address”. This encrypted address would replace the “standard” address in any blockchain transactions. Only the address on the blockchain would be encrypted, so amount, txid would remain the same, hence no additional double spend issues.
3a) When dark addresses are created, an associated dark address “viewkey” (to borrow from Monero-speak) would be created. This viewkey could be sent to a third party for auditing purposes (e.g. accountant, government, etc).
Proposal
The proposal is to create (and publicly launch?) a new coin as a testbed for the above, and once properly tested and debugged, incorporate the features of the new coin back into feathercoin.
Is the above correct?
Initial thoughts/issues/questions (again I am still learning the specifics of exactly how blockchain transactions work).
-
What would the white address consist of (actual realworld name/address, facebook account, or could be many different things)
-
Would the new coin be launched publicly and traded? or be a private experiment. Risk for real world launch would be that it would take the place of FTC?
-
Would we have one “dark address viewkey” per dark address created, or one for many dark addresses created?
-
Handling of change addresses, for dark transactions, would the client automatically create dark change addresses when transactions are made?
-
Ability to sign a message using a dark address?
Cheers
Dave
-
-
Yeah that pretty much sums it up so far!
I’m in favour of the white address. As far as I’m aware it would just be a separate website/service that would contain an address/multiple address which point or are associated with a real world person.
So in theory you could look me up the the “feather pages”(do you have yellow pages?) and find my address and send me a tip or whatever. This could be a global address book integrated into the wallet? Or just a website.Does this sound about right?
-
I would call it an Audit Key.
I think dark address are 100% all go provided it is easy to generate an Audit Key to supply to gov/tax accountants or say if an organisation is accused of wrong doing. *cough* gox *cough, cough*
We could build a global address book on the website I think. But there’s no reason a search function couldn’t be built into the Qt
But yeah that sounds right… I think that’s where this idea is heading.
-
Sorry, I’m late . I agree the dark blockchain , willing to join the work.
-
I’ve added some of the comments and ideas to the functional requirement / white paper on Github.
https://github.com/wrapperband/PrivateBlockchainAddress
Any comments, particularly on how to use Github to update the project. Github is so dense and powerful to learn, especially as this is just documentation at the moment…
-
I happened to scoop up DarkBlockchain.com. If thats of any use here
-
I’ve added some of the comments and ideas to the functional requirement / white paper on Github.
It would be a breakthrough, because Nakamoto in his paper states that the transactions must be publicly announced in such way that all nodes are aware of the true nature of all the transactions. To me, it seems like trying to invent perpetuum mobile, but on the other hand, perpetuum mobile inventors did contribute to the technological progress, so I don’t want to completely discourage this. Let’s just not get involved in it too much, or it might reflect bad on us.
-
I am a Physicist with a PhD and if I thought that there was any slight chance of PBAs not being feasible, I would not be bothering to ask for comments let alone document it. (although I am learning Github).
i.e. the whole reason I think it will work is that it is doing nothing new to achieve it, it is just an extra layer of encryption which hides which address is linked to which, when a transaction is made…
I have even explained more in the paper how encrypted address could look exactly like a normal address, so all other parts of the software would work the same. The more I look it it the less work might be involved, if it is done cleverly and carefully.
As far as Nakamoto is concerned the transactions are publicly announced. With PBAs, it isn’t public which address they came from. If you don’t encrypt the coin amount then there is absolutely no conflict.
What Nakamoto states in his paper is more about trusting the system and the need to validate the system. We now accept the system is validated, so only need to know the software has proceed a valid transaction. We don’t manually inspect every transaction (any more) and as I have pointed out, the sender and receiver can still validate the (private) transaction.
Also, it is only the action of the software during mining that validates and address or transaction and other miners who validate it, we have no other way of knowing. That is the public nodes Nakamoto was referring to. Particularly as he initially envisaged CPU mining and each (mining) wallet to be a node.
And, even with unencrypted addresses, it is still only the sender and receiver who can fully validate that the correct transaction has occurred.
-
But is it not true that any node with a full block chain (mining or not) would not pass on a transaction it thought was invalid? Would it not check that the inputs actually exist?
-
What Nakamoto states in his paper is more about trusting the system and the need to validate the system. We now accept the system is validated, so only need to know the software has proceed a valid transaction. We don’t manually inspect every transaction (any more) and as I have pointed out, the sender and receiver can still validate the (private) transaction.
Also, it is only the action of the software during mining that validates and address or transaction and other miners who validate it, we have no other way of knowing. That is the public nodes Nakamoto was referring to. Particularly as he initially envisaged CPU mining and each (mining) wallet to be a node.
That’s centralization. Nakamoto calls it a mint. ACP is a mint, but white, under public scrutiny. You are proposing a dark mint.
-
That’s centralization. Nakamoto calls it a mint. ACP is a mint, but white, under public scrutiny. You are proposing a dark mint.
I have proposed a system which can be implemented as “dark addresses” but a “light Mint”. It is only proposed as a possible enhancement that coin amounts or the mining payout amounts would be encrypted.
Partly to assuage your concerns, I am personally happy that the software now performs correctly (within its specification) and don’t feel necessary to inspect every block for correct action, except (to some extent depending on the software changes) during testing.
That is not to say there are not external influences i.e. opening up new areas for exploit by hackers. However, this “investigation” is to fix the possible exploitation of privacy leakage, which already opens you up to hackers. I suggested the “Dark Blockchain” idea as a discussion focus.
If it is possible to link your IP to an blockchain address, then it is possible to link your transactions and inventory. That starts to become worth exploiting. The final hack might end up being in meatspace (steal you PC or USB sticks), especially as more wealth gets stored in coins.
Also, my understanding of ACP is that it is to prevent double spending. Unfortunately, it does not validate the address. ACP did not help with timewarp attacks and had to be turned down to avoid a increased vulnerability.
The way the mining works it is possible for large exchanges to compile transactions blocks. But that can be used (sometimes inadvertently) by large actors in the network to invalidate the “correct fork” of the blockchain.
So, ACP is not a Mint, more an extra check on your bank balance before fund transfer.
-
An open protocol to allow **secure authorization ** in a simple and standard method from web, mobile and desktop applications.
OAuth is an open standard for authorization. OAuth provides client applications a ‘secure delegated access’ to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials. Designed specifically to work with Hypertext Transfer Protocol (HTTP), OAuth essentially allows access tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner, or end-user. The client then uses the access token to access the protected resources hosted by the resource server.[1] OAuth is commonly used as a way for web surfers to log into third party web sites using their Google, Facebook or Twitter accounts, without worrying about their access credentials being compromised.[2]
-
Could that be usefull?
