Adding types of reversible transactions to NuBits network

AMA Bill Gates - why doesn’t Bitcoin work for him?
Earlier this week we saw the AMA with Bill Gates. There was a very interesting post in there which I think clearly covered the current issues with Bitcoin and most other crypto currencies:
https://www.reddit.com/r/IAmA/comments/2tzjp7/hi_reddit_im_bill_gates_and_im_back_for_my_third/co3qd
The volatility and lack of reversibility. Also note the value he contributes to have people receiving mobile payments in developing countries (the unbanked).

Why having reversible transactions?
The first issue regarding volatility we did fix with NuBits. Currency is pegged and not volatile against the dollar. He also talks about reversing transactions in case of mistakes. I think that is also a key functionality of a currency, but not always required. It should be available though to those who wish to have it. There are a few use cases which may require some slightly tailored solutions but the principle should be the same

  1. Transactions where you would like a confirmation that it is received by the intended recipient or recipients holding the keys. Especially by regular transactions to developing countries you want to make sure the money gets into the right hands.
  2. Transactions where a local Act requires consumers the ability to return the goods within 10 days. When the goods are returned to the merchant in time, the consumer is credited. When not the payment is released to the merchant.

Can we get rid of 3rd parties?
Currently the problem is that you would always need a 3rd party like a bank or some payment processor intervening when using crypto currencies. Reversible transactions are inherently impossible with blockchain transactions. My proposal is to practically circumvent that if desired and with that implement a type of reversible transaction into the NuBits network without introducing the need of a 3rd Party. I think it is possible to implement a smart contract with multi-sig capability where the network itself acts as the independent third party.

Use case
Recipient and sender of the payment agree to use this functionality. They choose to have a sender confirmation upon receiving the payment. When the confirmation is not received within 10 days the payment is reversed. This example would insure against the inability to access the keys (e.g. due to loss/deletion/forgotten password etc.) of the address used by the sender.

How would that technically look like:
The Nunet creates a multisig address upon reception of this payment type and the transaction. It provides one key to the sender, one key to the recipient and holds one key itself. This key can be held encrypted on the blockchain itself.
The transaction cannot be released without 2 out of the 3 keys signing it.
When the intended recipient is still in control of the address they can use their key to release the funds. Triggered by this event the network would sign with their key and transfer the funds to an address in control of the recipient but only if the number of blocks passed is smaller than agreed (e.g. 7200 blocks is about 10 days). If the number of blocks is larger than 7200 only the key from the sender would be accepted to transfer the funds to an address in control of the sender.

Variant 1 Multiple recipients and/or senders
A variant with multiple recipients and/or multiple senders can be thought off. This can be useful for large payments where multiple signatures are required for transactions. Similar can be the case on reception, although this can already be done by using a multisig address in control of the recipients as the final destination anyway.

Variant 2 User authentication
Another variant is to ensure that the recipient address is in control of the intended recipient. This can be useful when keys have been stolen unknowingly or recipients have been compromised in some way. This use case would require an exchange of a secret key in advance. This can be done with PKI key exchanges and signed messages. In this use case the network would not only require one key from the recipient upon receiving the transaction, but also the signing of a message confirming that they are who they say they are.

I think to be a usable currency for all types of transactions we need to implement a form of a reversible transactions for those who wish to use that. Ideally I like to see the main use case and both variants implemented later this year, but this can be separated out in releases. It is very important that the user interface is friendly and that the code can also be used for implementation in mobile wallets. Anyway, I think it would add a tremendous amount of value to NuBits as a currency.

Feedback and motion
Love to hear your thoughts, other use cases or technical analyses or improvements on this model. Shoot at will, I’m sure it is not yet perfect. When this is received well, I’m prepared to raise a motion to have the Nu developers implementing this and eventually adding it to the roadmap for the NuBits Android client.

1 Like

ok you can confirm payments, how to confirm if the product/service has been delivered? one of the problems with reversible transactions is that kind of fraud where they refund while they actually did receive the product

That is a dispute you can’t solve in the blockchain. That would require confirmation of the delivery by the delivering party. I think that is still a bridge too far in many cases, but not impossible e.g. when it is about postal deliveries to the door. You can imagine a variant on cash on delivery where the delivering party also signs the multi-sig payment transaction when handing over the parcel. You can’t solve it 100% as you would still have people sending bricks or fakes instead of the ordered goods etc. Disputes still require a 3rd Party to settle as long as the network can’t obtain the required information somewhere.

Edit, slightly off-topic: More based on classic solutions, you could introduce another variant where you introduce a custodian as the 3rd party. The custodian can either be trusted and make a decision themselves based on evidence provided and/or e.g. raise a kind of motion to a selected group of Shareholders who will act as an instant Jury for Disputes and vote for or against the motion raised by the disputing Party. Having a selected group of Shareholders vote would not be possible withing the current voting system without making changes (e.g. have a kind of colored voting shares which only work for Jury services). It would be an interesting step in decentralised governance though. The colored shares could e.g. mint a higher reward for the provided Jury services. Anyway this would be a topic in itself.

2 Likes

Hi, very interesting thoughts.

I’m afraid this won’t be possible. The third key is a secret that has to be hold by someone who doesn’t expose it. A public ledger is not an appropriate place to store such a secret. Key encryption doesn’t solve the problem, because you still have to store the passphrase of the key :wink:

I’d like to address the two scenarios you posted.

The blockchain provides all this information. Or do you mean the scenario where the user recognizes that an unintended or malicious transaction occurred?

The problem is, that it is not possible to revert a single transaction without rolling back the whole blockchain up to the block where the transaction took place. Of course, if the theft is huge, you can make a motion and ask the shareholders to roll back the blockchain (therefore reverting all transaction that people assumed to be confirmed), but you will need to provide a very good reason why the shareholders should do that.

This is a trust problem. You essentially are in the same position as if you would have paid in cash. There are many trustless / blockchain based solutions in development right now, open bazaar etc. The most intuitive way to solve the dilemma is to make a double escrow method, where both parties deposit at least twice the value of the trade in a multisignature account which both will get back if and only if both agree on the completion of the trade within a certain time window. This gives a monetary incentive to play fair.

Good shot. Keeping passphrase in blockchain is not a good idea indeed. Keeping the secret somewhere else is possible but I think it would make the implementation a bit more difficult. Maybe it can be signed by the solver of the block the smart contract ends as defined in the contract?

No not really, this scenario is about sending transactions to addresses where no-one have access to the keys e.g. due to loss or deletion of the private keys or those who forgot the passphrase. It is not about reverting the blockchain just signing another multi-sig transaction so the sender can regain access to the otherwise lost funds. This is especially useful for large transactions.

Agree that is a trust problem. However your proposed solution is not widely recognised as such. There is a lot of discussion about the complications and the cost of doing so. When I’m selling something I will also have to pay cash the value of what I’m selling. Not very useful for those cash strapped trying to get some cash by selling.

My proposal doesn’t solve this and was not intended to do so. It is just adding a way where a transaction is temporarily locked-up according to a contract (with time expiration and confirmation from recipient ) and released by one of the Parties involved.
Edit: this only covers consumer protection

1 Like

very interesting. I think it is posible in some extend, at least to be sure that you have sent the coins in the correct
address recipient. Perhaps it can be done with smart contracts (like ethereum) or a dependent mechanism inside the wallets.
A very general example: with the sending of coins, to send together a signed “something” and provide the key with other means to recipient. Then if recipient can decypher this “something” with the received key, the transacrion is completed or
else it is cancelled ater an amount of time.

In fact with pure proof of stake system like Nu you could do the following:

  • The user requests a reversible transaction over N blocks from address A to address B over an amount of X via motion.
  • Once the motions passes, the user can send the corresponding transaction, and shareholders who voted on it will recognize it (through A, B and X) and create two forks, one with the transaction and another one without it, and continue to stake on both forks for up to N blocks.
  • If the user wants to revert the transaction, the shareholders will select the fork without the transaction as best chain and ignore the other one. If N block have passed without a reversal request the transaction is considered as confirmed and the alternative fork without the transaction is omitted.

As long as the majority of staking weight cooperates, the new fork will be confirmed and the transaction will be reversed. Problem here is scalability: For P concurrent reversible transactions the shareholders would need to generate 2^P different forks and stake on all of them. Although staking isn’t a hard task, the exponential explosion makes this method infeasible for large transaction volumes.

Interesting mental exercise, but as you say the exponential explosion with larger volumes makes this unfeasible to maintain in the blockchain. So I’m afraid we are stuck with smart contracts based on multi-sig which create further transactions in the blockchain to move keys around according to instructions to simulate reversible transactions from an end-user point of view.

This might be relevant (sorry, inevitably looong) : https://www.youtube.com/watch?v=r8JopZWlvtw

1 Like