Looking for Feedback on an idea: "Accountable Blockchain"

[larryisme]

It has seemed to me that one of the challenges to making cryptocurrencies more mainstream is the dependence on the private key as the sole source of identity.  The management of private keys either requires a user to rely on a trusted third-party or subjects them to the dangers of potentially losing the private key if their hard drive fails or having it stolen if they trust the wrong person.  Even if they protect the private key, the irreversibility of transactions means that there's no protection against scams or if a merchant misrepresents the product sold.  Even after a person learns to deal with all these dangers, there is still the challenge of save versus spend.  Those first pizzas purchased by bitcoin are perhaps the most expensive pizzas of all time.  A currency that is saved and never spent is going against the whole purpose of a currency.

I have been thinking about the above problems and it occurred to me that there may be a way to do a self-service, decentralized multi-factor authentication on the blockchain as an alternative to  relying on private keys for identity.  The private key would still be the primary source of identity but if its privacy is compromised or if it is lost, it would be possible to change the private key associated with a user.  I also have some ideas for providing greater buyer and seller protection of transactions without relying on a centralized authority to settle a dispute.  The approach relies on a willingness to supply more details of user identity up to the point where if both parties are willing to provide full identity, users can reach out to standard legal mechanisms to settle the issue .  It also involves a reputation system where being in good standing for a year gives certain privileges that will be lost if a dispute is not settled and a person is not willing to reveal full identity.

It occurred to me that there may be a simple way to remove the cost of spend versus save.  A decentralized currency can be a "smart currency" in that it is possible to do some special accounting to protect value.  It occurred to me that it could be possible to add intelligence to the blockchain to divide up all money into "coins" and "tokens".  Coins are limited in how they are created and can only be purchased by individuals in good standing using tokens.  Tokens can be purchased by fiat currencies with the guarantee that if they are not spent, they can be returned within a given time for the amount purchased (no different than a standard purchase of credits at an arcade).  Tokens are purchased for cash and for users in good standing can be used to purchase coins.  Coins have a given value in terms of tokens.  When a coin is spent, the amount spent is credit loaned (as a percentage of the coin) to the user.  Assuming the coins rises in worth over time, the credit borrowed will reduce as a percentage.  If the value of the coin goes down or goes below the amount loaned, there is no change.  The impact of this is that there is disadvantage to spending a coin because you are never spending the coin, you are spending a percentage of the coin.  Only if you sell the coin, do you lose its value.  You can only spend up to 99% of the coin.  Once this limit is reached, the coin can no longer be spent unless the coin goes up in value.

My goal is to take these ideas and organize them into a white paper.  I call this idea "Accountable Blockchain" since the main idea is to make the decentralized currency easier to manage for the mainstream consumer.  

Anyway, that's the essence of the potential white paper.  I am new to the altcoin discussions so I am very curious if there is any meat to these ideas.  Would anyone have suggestions on existing technical papers that cover these topics?  Would this be the appropriate place to present the first draft of a white paper in order to get feedback, questions, and suggestions?  Is there another place that would be more appropriate for the first draft?

If all this sounds good, I will post the first draft of the paper on this thread.

[rat4]

A backup of keys is a must-have. The ability to restore the access to funds when keys are lost may be interesting, but we need more details to know.

The irreversibility of transactions is a technical need. How would you reverse a transaction when coins have changed 10 hands already? It is there not to prevent you from building smart contracts that aim to dispute an intra-chain buyer-seller transaction.

Not everyone is willing to disclose their identity, and a burden of legal mechanisms may not worth the amount being disputed. I see this as quite limiting.

Perhaps you want to call it "Distributed Ledger for Banks"? They can restore your account if password is forgotten, can reverse transactions in case of scam, and identities are known. Just kidding. 

This is a good place to get feedback.

[larryisme]

Thanks very much for your comments!  These are great points.

Yesterday, I spent time thinking through each of the issues that you raised.  As I worked through each point, I realized that I am making a lot of assumptions that really need to be clearly detailed.  There really needs to be a technical draft with my assumptions that can be referenced in my reply.

I realized that perhaps the most nonstandard feature of my approach are my assumptions behind a unique, identifiable "coin" which is a vehicle for saving or investing versus a "token" which is really a credit that is used for "spending".  A user would buy "tokens" directly with the assumption that if the token is not used, it can be returned to get one's money back.  So, a token, in this sense, is like a postage stamp.  You will probably need more tokens as prices go up but the tokens themselves, in theory, should not change value too drastically.

As I write this, I realize that this distinction between "coin" and "token" is very much based on a set of rules that at this point are only in my head.  So, the next step is to detail my idea about this distinction in a white paper and also in reference code to show this distinctions I am assuming so that others can kick the tires and make sure that the car can can actually run at least on test road.

My next step is to write draft 0.1 of a paper which will focus primarily on two topics:  1) Accountable Blockchain: a proposal for offering buyer and seller protections.  2)  Protected Coin: a proposal for distinguishing "savings" versus "spending" by distinguishing a unique, identifiable, mineable, "coin" from a quantified, account-based, credit which is used in transactions.  

With the idea that more information will be coming soon, I will attempt to address each of your points.  

A backup of keys is a must-have. The ability to restore the access to funds when keys are lost may be interesting, but we need more details to know.

The ability to change private key does not require that the private key is backed up (how the private is secured is handled by users independent of this proposal). As long as a blockchain timestamp and a public key are stored in the blockchain, that should be enough.  When a user validates their identity through multi-factored authentication, they can invalidate the previous public key for all future transactions and can register a new public key to be used.

The irreversibility of transactions is a technical need. How would you reverse a transaction when coins have changed 10 hands already? It is there not to prevent you from building smart contracts that aim to dispute an intra-chain buyer-seller transaction.

The ability to reverse a transaction becomes possible when the assumptions about "coin" versus "token" are better explained.  In my proposal, a "coin" would not be transferred through 10 transactions.  Only a "credit" would be transferred so that each transaction could be reversed independently of the others.  The reversal would mean that any digital good would go back to the seller and any "credit" spent would be recovered by the buyer.  This protection is not perfect and is not a guarantee.  It has limits which would be specified in the contract (each transaction would be qualified by a smart contract).  The constraints which are negotiable and the protections for this reversibility would depend on a specified escrow period (before the transaction completes) or a margin (which is the amount that a seller agrees not to spend in order to provide the reversibility guarantee).  I have some ideas on how the system can encourage escrows and margins which I will detail in a future draft of the paper.

Not everyone is willing to disclose their identity, and a burden of legal mechanisms may not worth the amount being disputed. I see this as quite limiting.

The willingness to reveal identity is meant as the final escalation in the dispute system if the dispute has not yet been resolved by the agreed upon contract.  No one would be forced to reveal any private information and it is assumed that in most cases, there is no need to dispute a transaction.  My assumption here is that the rules of dispute would be specified in the contract when the potential buyer sets up their "spending" account and will be part of the "offer" that the potential seller sets up in a marketplace.  If a person wishes to accuse another person of a "crime" and feels that the dispute system has failed because  of "fraud" or "theft", then they would have a process available to reveal information about their identity.  If the other person (buyer or seller) wishes, they can block this escalation by revealing additional information about themselves.  The idea here is not to limit anyone but rather to provide a protection against scams, frauds, and theft.  Once an identity is revealed, standard legal channels can be appealed to.  I am assuming that a scammers, fraudsters, and thieves will prefer to reverse the transaction rather than reveal their identity and I am further assuming that this process of revealing identity in a public way would be rarely done rather than commonly done.