Topic: Making blockchains more accountable to buyers and sellers (Read 166 times)

I agree with your points.  A hash alone is not sufficient protection and the challenge with MFA over a decentralized setting is that everything is open.  This is the challenge.  The only way to address the points you raise is to provide details with checks for each point. 

The "recovery script" would need to be run on a reputable node.  This of course raises the problem of how to establish which nodes are reputable and which nodes are not since if money is on the line, malicious nodes will try to game the system to steal the funds.


Professionally, I am a backend Java/Spring Boot programmer.  I have done light front end development including some Kotlin work.  I would be interested in checking out your blockchain. 

Email and SMS don't seem to be more secure than a password, if the interaction transcript between the user and the node is not authenticated to the user (or at least his service provider). Here a malicious node impersonates an user.

Yes, the rate limit is what makes possible to use a low entropy secret for authentication. In centralized setting this is straightforward, because all data is private. In decentralized setting a hash of the secret is ought to be public, so an attacker can do rainbow/dictionary/brute-force locally and send the request only when he is ready.

Trusted execution environment refers to a special hardware that could try to prevent a node operator from malicious actions. Perhaps you want to limit "recovery scripts" to trusted hardware or reputable nodes, then I don't know.

Is there a chance you may be interested in writing in Kotlin or any other JVM language? On our blockchain an application can do really weird stuff like what you may need for reversing TX and networking MFA.

Thanks very much for your comments!   


Here's the flow that I am assuming.

1.  The user contacts the node with a request to change the public key associated with the account.  The request includes a public key for the requester and the account id.
2.  The node initiates  a script and passes the IP address, a public id of the requester, and the account id to the script.
3.  The script generates a private key/public key on the fly, opens a transaction on the blockchain with the following information, a fee charged to the requester (the user must have an account that can be used to pay the fee, the public key which will be used to validate that the requester received the secret over the channel, and the account id in question.
4.  Once the fee for the request has completed, the script builds a receipt of itself (including the full code, a hash related to the code, a signed receipt from the original node that the transaction has completed, and other details which still need to be worked out). 
5.  The user (most likely through a wallet application) will provide the channel detail (such as an email address) which can be matched against a hash that is associated with the account channel (to be clear, the hash is NOT for a password.  It is for the DETAILS associated with the channel such as the email address or in the case of SMS, the phone number.  In the case of a separate private key, it could be a hash of the exact name used to identify the public key.
6.  Once the script has the channel specific, it validates it against the hash and it passes the private key that was generated on the fly through the channel.  This transaction is not public is any way.  One OPEN issue is how to guarantee that the script does not leak the private key generated on the fly.  I am still working on this.
7.  The user now proceeds to respond to each request by the script to cover each channel registered with the account.  Each channel would be a separate transaction.  It is purposely time consuming and not too expensive so long as it is done infrequently.  There should be a pricing mechanism that penalizes multiple attempts.  It might be that you get 3 attempts or it might be that after 3 attempts, the price doubles unless you wait a longer period such as a month.  The exact circumstances that are most effective would need to be worked out.
8.  One the user has gathered all the private keys associated with each channel, they now make a request that includes the hash associated with the channel signed by the private key received.  This request can now be validated against the transaction that has previously been committed by the script.  If all signatures validate and all required hashes are included, then a new transaction is created with an additional fee that includes the fee, the account, all the signed hashes, and the new public key that should should be used from this time stamp (transaction id) on.

I hope that clarifies my assumptions.  The public key will only be accepted when the transaction for the change is accepted by the blockchain.  There are still open issues which I am working through. 


I agree.  The details for ensuring that script code runs reliably without being tampered with or leaking any private information is nontrivial.  I am still working through the details.  I will do another post with more details.  I have NOT worked out all issues. Thanks for your suggestions on approaches.  I have looked to zero-knowledge and reputation as the main strategy here.  I have not yet looked at homomorphic encryption.  I am not clear what you mean by trusted execution environment.  If you have any suggestions for establishing a trusted, decentralized execution environment, I would be very interested.  I have been primarily looking at solidity as an example scripting language.


No, here the knowledge of a hash is enough for the attack.
[/quote]

It sounds to me like you are understanding the hash to be associated with a password so that an attacker can guess the password and so break the hash.  Am I misunderstanding your point?

The hash represents the exact detail for the channel (the email address, the phone number for SMS, etc.) so even if they break the channel, they would still need to get ownership of the channel and further get ownership of all channels that are used to validate the identity.  My assumption is here is that a fee per request, a limit on the frequency of requests, and reasonable default settings should go a long way to preventing the attacks you describe.  The reasonable default settings is still an open issue.  MFA will never be completely secure.  My fallback is to rely on a notification when a change has gone through and a dispute process which will offer additional protections (the notification is available from the public blockchain itself, the dispute process needs to be detailed which I have not yet done).;

One node communicates with the user and so is convinced, but what about the rest of nodes? SMTP has DKIM, but it's optional. I'm not familiar with GSM, but I'd guess it's even worse there.


You said "compiled into byte code", but that doesn't guarantee anything. There are some techniques for this: homomorphic encryption, zero-knowledge proof, trusted execution environment.


No, here the knowledge of a hash is enough for the attack.

Yes, unconfirmed transactions that have the public key changed will fail.  I wouldn't say it invalidates them because they were never completed.  I think that implicit here is an important point. An ability to change public key only makes sense if transactions are relatively fast so that the use case that you describe should be quite rare.  The change process as I am envisioning it because it is part of the blockchain would always take longer than any standard transactions made before the request to change the public key completes.

I will detail below the process that I am assuming for changing the public key.  Even after the person validates the multi-factor authentication and makes the request, as long the transaction occurred before the request, it should be completed before the change occurs (the change is occurring in the same blockchain as the transaction).  The person would have to sign the transaction after they made the qualified request and in this case, it is no different than a person signing a transaction with the wrong private key.


There are three points where a bridge occurs between the User's Client Application (which I assume is a wallet) and the public blockchain which is managed by registered nodes.

(1)  When the user specifies the exact channel where only the hash is public.
(2)  When the user receives the secret (an on-the-fly generated private key) , they have the ability to temporarily save the private key until they have gathered the same number of secrets for each required channel to validate.
(3)  Having gathered all private keys, the user now makes the request to update the public key which includes the hash of each channel signed by the private key received.

The client application would have the channels privately stored that would match the public hash (the client application would be involved with the account set up when the hashes are generated in the first place)

The user requests to change the public key.  The request goes to a registered node which will have a reputation.  The request is two part.  The request starts without any of the channel details.  It should start with the request itself and the IP address of the requester.  The node now starts a script with public source code that has been compiled into byte code where the states are private.  The script would then interact with the client application, validate that the channel matches the hash, without persisting or sharing any of the channel details.  If the hash matches, then the application will run a separate script to validate the channel.  This second script will generate a private key on the fly and send this private key through the channel and publish that a validation attempt occurred, the user seeking to validate will be charged a fee, and the on-the-fly public key is added to the transaction which can be used to validate the secret was received through the channel.

When user has gathered all the private keys, a new request is made which can then be verified by a script.  The script then organizes all the information so the request can be validated by all nodes and hence the public key is changed.

This approach only works for channels such as email or SMS.

It could also be possible to use secrets specifically for validating identity.  These are private keys that are ONLY used for validation.  The public key is saved in the account and again and an id is used to identify this source.  The user then uses their private key to sign the id as part of the request.  The signed id is then validated using the public key.

I will write these use cases up in more detail at a future time.  Hopefully, this clarifies how a bridge would work.  It makes one BIG assumption.  It assumes that scripts can be run reliably without being tampered with.  If a script for example shared the private key generated on the fly outside of the channel, then it would make the validation worthless.  



Hopefully, the explanation above answers your questions here.  My assumption is that MFA would include channels (verification over email, verification over SMS) or private keys or other channels that could be defined at a future point.  The types of channels available would be limited to channels that can be effectively implemented through a script.


To be clear, my goal is to support multi-factor authentication over the blockchain.  If the approach I have detailed works, then it would not require a central authority for the MFA.  So, you are right, it would NOT BE the standard MFA which uses the centralized security model.

i agree with all your points.  I think that the only part of the dispute process that might be interesting (in light of your comments) is (3) and I would need to have detailed use cases clearly called out.  In order to be interesting, I would need to show the value behind adding a dispute system to the use cases and show how reputation formula that is resistant to gaming.   

I agree with your comment about the reputation formula that I provided before.  It could be gamed by a farm of accounts in good standing.  The reputation formula needs to address this use case.  Account activity would need to be part of being in good standing.

This period is not really necessary. Why do you have to make a transaction 24 hours in advance if you can cancel it anytime? The merchant would not be able to send the good until these 24 hours are over, if the transaction is cancelable.

The only reason I could imagine is a "proof of funds", for example as a anti-spam mechanism for merchants. You can do this proof of funds today with available Bitcoin technology - simply require the buyer to move coins to a different address, including a hash of some random number (so a buyer with bad intentions can't simply use a different transaction). You could even do this without any transaction at all: request the buyer to sign a random number you provide him with a private key of an address containing the funds, and then monitor the blockchain.

And even if you need something like this, you could implement it with Bitcoin as a part of a multisig-based contract with OP_CHECKLOCKTIMEVERIFY or OP_CHECKSEQUENCEVERIFY, where the receiver only can access the funds after 24 hours, while the sender can transfer it back at any time. It should of course be also possible with Ethereum and 99% of all other coins.

There is simply no way to verify misbehaving automatically without human intervention. It would require a lot of naivity and stupidity of an attacker to be detected by such an algorithm. So it's not really necessary.

This is simple to implement with Bitcoin: 2-of-3 multisig with an escrower. Very much what Bisq is about. Again, you don't need a special blockchain for this.

Why a second dispute period? Don't you need "evidence" in the 90 day period?

A similar system is used in Bisq. But take into account that (1) is gameable: they simply would transact in their "friends" circle for a long period, and could even let outsiders transact sometimes with them without scamming them ("selective scamming").

This strategy to build up a "farm" of old accounts to use them later in scams is even possible in Bisq. But in Bisq the "time in good standing" parameter, together with the hash of a bank account, is targeted at a specific kind of attack: to use fraudulently accessed (e.g. through password stealing/phishing) bank accounts to buy coins (an initially widespread scam mechanism in this kind of DEX). If you have a hash from the bank account of your counterparty, and it is already 6 months old, it's extremely unlikely it was accessed fraudulently because the victim would have reported the loss to the police. This attack prevention is however not adaptable to all kinds of transactions.

Thanks very much for your analysis and calling out Bisq.  I will explore the details behind the project which sounds very interesting.  

I agree that any verification of a physical good purchased through a decentralized currency, will need to be done outside the blockchain.  I am not proposing any solution to this problem.  

I am assuming that all verifications of product quality are done independently of the public blockchain (through pictures, meet ups if both parties are local, etc.) and that the transaction just represents the transfer of digital deed/fee.  The escrow mechanism that I am proposing is solely a switch that can triggered by either party for the period agreed upon.  The switch itself would trigger a reverse transaction that would be public in the blockchain.  (It is my assumption that since the cancellation is public, stats on cancellation will impact the buyers reputation over time if it is done too often.  I am also assuming that it will be too inconvenient to continually create a new account to hide the stats on can

I agree that the first case that you identify requires a central authority .  I am proposing a less ambitious approach.  Escrow is just a period when either party can hit cancel that would be specified in the buyer and seller conditions (human readable domain specific language that serves as the required conditions for the transaction to proceed).  

I am thinking of the "escrow period" literally as a period of time where either party can cancel the transaction.  It could be accompanied by an "escrow service" that handles the transfer of a good.  That would be independent of my suggestion.  For digital goods, the cancellation of the transaction would result in the return of the good (since the transaction has been cancelled).  

I am thinking that there might typically be 4 periods in the lifetime of a transaction:

(1)  Escrow Period (24 hours?):  Either side can cancel
(2)  Conditional Escrow Period (48 hours?):  Cancellation is allowed for qualified conditions (i.e. good failed an evidence-based validation)
(3)  Dispute Period (90 days?):  Dispute process can be initiated.  Transaction is not cancelled but the fee may need to be returned under conditions specified.
(4)  Conditional Dispute Period (180 days?):  With evidence, a dispute process can be initiated.

The protections would not be perfect and would not necessarily involve any central authority (it could involve a central authority as part of the smart contract -- but that is outside the scope of this discussion).  The protections would be managed by algorithm.  Only if evidence exists or if a person does not follow the dispute process in a reasonable amount of time, will a dispute be decided against someone.  If dispute process is followed within reason, then the transaction stands and there is no impact directly to reputation.  The record of the dispute would still be public so anyone who wishes to investigate a seller in good standing would be able to see them and there should be enough self-documented information to make future buyers or future sellers the ultimate judge.  


You make a great point about how straight forward it can be to game a reputation system.  I am still working on the reputation system I am thinking about reputation as consisting of these values:  (1)  Time in good standing, (2) Absence of unresolved disputes (3)  Absence of evidence of not following the exact rules of the system.  If you see a way to game any of these properties, let me know.  (1) punishes the user who closes and opens a new account.  (2) gives incentive to resolve any dispute and (3) doesn't prevent a new account being created but would require the new account to wait a certain period of time before it is in good standing again.

I like your suggestion about a "personal data hashing service".  It sounds a personalized Page Rank for the Blockchain.

As I have worked on this problem, I have found it very challenging to create multi-factored authentication and buyer protection without a central authority.  My assumption is that a registered node and a working reputation system can provide some of these services without a centralized authority.  My goal is to identify decentralized mechanisms that offer MFA, limited buyer and seller protections, and a voluntary, evidence-based dispute system that requires reasonable responses within a reasonable time.  The devil is in the details.  I will provide more details in a future post.

I agree.  Multi-factor authentication over blockchain may not be possible.  The approach that I have worked out may have more problems than value.  My purpose is to outline the approach and be open to issues that are called out on this forum.

The approach that I have worked out make a lot of assumptions about underlying systems which may not be valid.  As an example of what I am thinking, here is a proposed flow for email verification with assumptions. 

Assumptions about Underlying Systems Used For Email Verification

(1)  A scripting system exists that supports scripts that can generate private/public keys on the fly without revealing the private key outside the identified channel.
(2)  The scripting system can provide evidence that the script was run without tampering and without revealing the private key.  This evidence is added into the blockchain and can be verified.
(3)  The request to validate identity can go to a single node that passes the identified channel to the script in step (2) and the node that can provide a receipt that proves that the expected action was carried out.  
(4)  Nodes are registered which enables each node to have a reputation associated with it.  Only nodes with high reputation can validate or take requests from unknown sources.
(5)  If a node sends an update to n other nodes, then that is sufficient to broadcast to all nodes.

The Authentication Flow for Email Verification

(1)  The user sets up an account with a unique account id (a non-fungible token) , a public key, and a list of verification channels where only hashes are saved.

So, for an email address verification, only the hash of the email address would be publicly saved.

(2)  To validate against email, the user submits a request to any registered node  
 
The user must know the exact email address that had been set up (the node will validate against the hash) and the node will return a receipt with the hash signed and will also return receipts of n nodes that received the public receipt that the script was run and the public key that can be used to validate the secret passed over the channel.

(3)  The user receives the secret over email and then uses the secret to sign a request to update the account and includes in this request the new public key to use.

(4)  It is now possible for all nodes in the blockchain to validate that the authentication was valid.  This can be done by using the public key generated by the script to validate the signed request.

This same process (or something similar) can be done for all defined channels for authentication.

Updatable public keys come with a problem that they invalidate unconfirmed transactions. The sender has to be online to re-sign transactions when his key updates.


It's not clear how you intend to bridge federated email to decentralized blockchain.


The lost private key is a sort of text, isn't it?


A weak password can be brute forced.
A strong password is more akin to the private key. Do you know modern wallets give the user just a mnemonic string like as in BIP-39?


Using something of the same type doesn't sound helpful.


Dictionary attack.


The standard multi-factor authentication works in a different security model: the centralized one.

What you want to achieve would only work in a completely centralized setting, with a central (and trustable) authority controlling the blockchain.

The few ideas which are possible in a decentralized setting, are for example already used on Bisq, a decentralized exchange. They are based on pure Bitcoin Script so they don't need new blockchain functions/opcodes:

1) a security deposit for every transaction to prevent fraud, which can be used to punish a misbehaving party by an escrower
2) linking an account to a hash of personal data like a bank account number.

Both however still require human intervention. The escrow problem 1) can't be solved automatically because both sides could forge data. Let's have an example where you buy some item at a merchant. Here the problem is: if you don't get the product you bought, how do you prove that you didn't get it? The procedure would require a human escrower to interrogate the merchant, but the strategies the escrower could use are very different depending on the exact item and also the location: for example, for a digital item, it would require screenshots of a platform where the item was transferred, while for a physical item you would need a code for the (local!) postal service. Such screenshots and codes are also things you can't simply publish in a public data record like a blockchain, while if a trustable escrower is involved, they stay private.

Using the strategy 2) to determine trustable accounts requires also human intervention because you can increase your reputation by simply creating thousands of accounts and then transacting with yourself. The only really good strategy is to see if someone you trust has transacted successfully with an account linked to such a hash. Such a "personal data hashing service" could be simply created storing the hashes (e.g. of the bank account) in an OP_RETURN/data output and it will get linked to the address, so it would also not require a new blockchain or new opcodes.

It is the ability for anyone out there to secure their private keys and also making sure to manage their funds in the wallet responsibly so, there is no way a lost transaction could be reversed to the original address. The only accountability I know here is solely depending on the individuals who are able to maintain their keys and often take proper care of their system against any external attack. So, If there where ways I am sure by now it would had come to implementation.

The "account" identity would be represented by a non-fungible token (the permanent user account id) and associated with a timeline of public keys (each point in the timeline would be a blockchain block number where the validating public key was changed) with one of the public keys currently active.

So, all transactions would need to be signed by the "active" private key and each transaction would need to be associated with a buyer "account id" and a seller "account id".  


A user account would be associated with validation channels that would be specified by the user when they set up the account.  The validation channels would be hashed so in order to use the channel for validation, a person would need to know the exact channel.  The channels could be email, text, password, a digital signature from another account, personal questions, or anything else that can be defined.  It would be standard multi-factor authentication.


I agree.  The dispute process has to be exactly right or it is worthless.

There are two use cases that would need to be address by a dispute system:

(1) Dispute transaction by mistake.
(2) Dispute transaction by fraud.

Here is an outline of what I am thinking:

Dispute transaction by mistake can be handled by an escrow period.  An escrow period can be associated with an account by default or can be specific to a transaction.  During the escrow period, either buyer or seller can dispute the transaction and reverse it.  The escrow period would be enforced by the blockchain and the funds would not be available for use by seller until the escrow period completes.

Dispute transaction by fraud would be protected by two factors: a common fund (a cumulative insurance fee) or a seller-margin requirement (sellers must always maintain a certain margin to address a potential dispute).  The dispute system for fraud works in this way:

(1)  Only a person with an account id and a reputation level (zero if the account was recently created) can raise a dispute.
(2)  A reason code for the dispute must be specified (for example, if the reason code is stolen private key, then the public key associated with the account must have been changed after the transaction)
(3)  A dispute must occur within  a certain period of time that is negotiable.  For example, it might be 90 days.
(4)  There needs to be clear criteria for proof that a dispute is legitimate or illegitimate.  (I am working on the details for this criteria which I will detail at a future time).
(5)  If all parties follow the expected dispute process, regardless of outcome, reputation is not impacted.  If any party does not follow the expected process, then reputation is impacted.  (Details on the expected dispute process and the dynamics of reputation will be detailed at a future time).
(6)  A dispute is specific to specific transaction and would not impact any other transactions.  It is not that the exact coin would be transferred back.  It is only that the equivalent of the "fee" would be returned to the buyer if the dispute is accepted.


The problem that I am working on is how to make decentralized currency more mainstream.  If the dangers that I outlined above are not preventing mainstream acceptance, then the paper has less value.        

You make a great point here about the consequences of a faulty implementation.  The MFA and dispute process need to be exactly right or they will introduce problems significantly greater than any value added by their use.  My gut feeling at this point is that both can be done in a way that greatly reduces the dangers already existing.  The devil is in the details.  Because these problems are hard, I think independently of anything else, it is worth attempting a solution.



  

What are the identities that are linked to the user's key? Also, what are the multifactor authentic methods that the system going to use?


This is where it needs to be scrutinized, the dispute processes.
What kind of dispute process? Who governs or controls it? And on what criteria that a transaction would be categorized to be accepted to be reversed? Don't you think it rather enables censorship?

---

I understand that what you wrote is only an introduction, but I think the premise why you design it because of simply users not caring about their own key ownership and it enables ransomware attacks is a lame reason. At least not a strong enough problem that urgently needs to be addressed, because I rather think about the consequences of what it may lead to. Say identity theft or faulty dispute processes.

In a previous topic, I asked about the best way to present a blockchain idea:  https://bitcointalksearch.org/topic/looking-for-feedback-on-an-idea-accountable-blockchain-5455261

I have started working on a white paper.  Here is Draft 0.1 of the introduction to what I am calling  "Accountable Blockchain".  

Please post any comments.

Introduction

Using cryptocurrency is filled with dangers.  Purchasing cryptocurrency depends on the trustworthiness and network security of the exchange providing the coin.  Managing the private key associated with an account is another level of potential danger:  losing the private key when a hard drive crashes, accidentally sharing the key with a third party, or falling victim to a network attack that leaks the private key.  Even securing the private key, it is still buyer beware since all transactions are irreversible.  Irreversible transactions enable ransomeware attacks, fraud, and protect scammers once the transaction completes.  There is no way to dispute a transaction and smart contracts, while a potential protection, require the services of a software engineer to create and update the contract code.  

For the cryptocurrency enthusiast, these dangers are the price of admission.  The valuation of cryptocurrencies, while having declined in recent years, are still in the billions of dollars.  

It is my view that these dangers are preventing cryptocurrency from making deeper inroads into mainstream finance.  It is also my view that many of these dangers can be greatly minimized by making the public blockchain more accountable:  by making identity based on multi-factor authentication over the blockchain instead of solely linked to a private key, by decentralizing the exchange service so that it is no longer dependent on central authorities, by adding self-declared transaction categories to each transaction, by making contracts a union of human readable conditions that can be specified and modified independently of a script, and finally, by adding a dispute process which breaks the irreversibility of transactions.  I call a blockchain that supports these features an Accountable Blockchain.