Introducing ARCC

ARCC: Allowable Revocable Contract Chain System for Bitcoin Cash

An ARCC(I pronounce it as, arck/ärk) system lets the payer take back the money while still allowing the payee to withdraw some funds from the contract based on restrictions of time and amount. The design makes it possible for the contract to become aware of time and amount and provides the ability to partially spend, making a vast set of applications possible, including but not limited to Streaming Services, Pay as you use, Recurring payments, Milestone-based payouts, Project funding, Pocket money, Parking Tickers, bicycle rides, etc.

Journey

It's been a couple of months since I started to invest my full time in Bitcoin Cash, I wanted to dive deep into the inner workings of the Bitcoin Script and at the same time, I wanted to see for myself the limits to what is really possible.

Watching these awesome people on bitcoincashresearch.org, discussing anything and everything being thrown at them, and still coming up with incredible ideas is and always will be amazing. They made me realize the long and exciting journey that I have to travel!
I follow a concept called Ikigai(Ikigai is the art of doing something—and doing it with supreme focus and joy). I love building and discovering things, I do it with what I know best: Software Engineering!

Today, I would like to propose a solution to mimic a pull/revoke mechanism on Bitcoin Cash with a working demo.

Whitepaper

Whitepaper and CashScript Contracts: https://github.com/kiok46/arcc

• Whitepaper

• CashScript Contracts (Testing in progress)

PoC

Proof-Of-Concept demo: https://github.com/cashkit/arcc-poc

This demo's UX is far more complex than what I imagine a regular application would look like. It's a work in progress.

Features

• Pay to: An ARCC contract can pay to, P2SH or P2PKH.

• Partial Spending ability: The Payee of an ARCC contract can withdraw any amount with any number of transactions with each amount collectively adding up to the total being less than the max amount allowed per time frame (epoch).

• Accumulation: This version of ARCC gives you the ability to accumulate amounts from all missed time frames(epochs). The Payee must make a single transaction to fetch all the remaining amount from missed epochs and any remaining partial amount from the epoch which had the last transaction. contract

• No Accumulation: This version of ARCC won't allow the accumulation i.e as soon as the new epoch starts, the amount from the previously missed epoch cannot be fetched. contract

• A window of time:

  • Epoch

    • > 0, Epoch with a value greater than 0 means that payee can withdraw periodic or partially periodic payments.

    • = 0, Requires Trust, Contract is not bound by time but only by amount. This is the case where a concept of slots can be introduced, this concept will completely live on either a backend/frontend/legal layer. Since time is not the bound here, the amount can be withdrawn from the contract by referring to anything measurable in the real world.
      For example, A bicycle ride. The two parties here are Rider(Payer) and the company(Payee). The company has the policy to charge 20,000 satoshis per Km. Both parties decide to create an ARCC contract with epoch=0 and maxAmountPerEpoch = 20,000. The rider funds the contract with 60,000 satoshis enough for 3 km. After each km, the company can simply withdraw the 20,000 from the contract. It can also account for a case where the total ride is only 2.5 Km. So, the company withdraws 2*20,000 + 10,000 each = 50,000 satoshis. The remaining amount can be taken back by the payee.

• Awareness:

  • Remaining Time: Time after which the next time frame(epoch) starts.

  • Remaining Amount: The contract is aware of the remaining amount that can be spent by the payee during the present time window.

• Expiration: An ARCC contract with expiration can be created to preserve user privacy.

Understanding ARCC: More Technical Details.

https://read.cash/@kiok46/understanding-arcc-a-contract-chain-system-15475185

See some security issues or simply 'This doesn't work'?

Please do share it. Better to lose money now than in production! 😄

Feedback?

I still have a lot to learn and it's possible that there might be some improvements that can be made.

• Please open an issue on POC or Whitepaper Repository.

• or Comment here.

• or Message on telegram group: https://t.me/arccsystem

Special thanks to emergent_reasons and bitjson for improvement suggestions.

Thank you for reading, I hope it was worth your time.
Cheers!