Open readcash opened 4 years ago
monsterbitar
commented
4 years ago I haven't looked into details of the exact structure setup, but I think the "Rate Oracle" structure is likely to be different from our Price Oracle. I think both would work, but the cashchannel struture would need to be adapted to the actual oracle structure the user wants.
bitjson
commented
4 years ago Hey – thanks for the mention – I think it would be great to get CashChannels implemented in Mainnet. (For anyone curious – CashChannels: Recurring Payments for Bitcoin Cash.)
As far as I understand - it's a P2SH wallet that has two unlocking methods so to say - spend by owner and spend by external entity where you want to pay to, correct?
Yes, it can be unlocked by either Owner Spend or Execute Authorization. 👍
Does it work well if I have multiple UTXOs in this P2SH address?
No, only one UTXO should be used per-channel, so it's a bit different than a typical "wallet":
Implementation note: a single authorization can be used to withdraw from any channel UTXO. In most cases, authorizations are meant to be used only once, so wallets should never hold more than one unspent UTXO per channel. To “top up” the wallet, the existing UTXO should be spent back to itself, adding funds as necessary.
(^ Some detail from the template description.)
If we step up - what arguments do I need to create this P2SH address?
This is easiest to see in Bitauth IDE: https://ide.bitauth.com/import-gist/ca13abf369b5ecace6437cb86afa331f – click through the entities on the left (e.g. Owner) to read descriptions of each variable.
At address/channel creation time, all that is needed are the public keys for Owner, Rate Oracle, and Receiver.
Then (without needing to fund the address), the owner can create any number of payment authorizations – each requires: Authorized Amount, Denominating Asset, Maximum Authorized Satoshis, Payment Number, and Payment Time.
For each authorization, the parties need to share the required variables, and the owner needs to provide a signature over the Payment Authorization serialization. Once the Payment Time is met, the Rate Oracle needs to provide a signature over the Rate Claim message, then either the Rate Oracle or Receiver can construct the final transaction.
Generally, it's going to be pretty complicated to implement this protocol by hand – there are a lot of moving pieces, and depending on your setup, at least 3 message types that need to be transmitted between entities at various times. As some new features get added to the BCH VM, the scripts will also become simpler (approaching the byte size of a 3-of-3 multisig transaction), so it will be important to consider CashChannel "versions" and an upgrade path.
I'm currently working on a lightweight JS implementation (using Libauth) and a CLI which implement a CashChannel protocol (with JSON format messages being passed between entities). Maybe it would be best for Mainnet to expose an API which uses that implementation under-the-hood?
I'll come back and comment here when it's ready. 🚀
readcash
commented
4 years ago No, only one UTXO should be used per-channel, so it's a bit different than a typical "wallet":
What happens if an adversary sends some random amount to that P2SH output, creating a second UTXO? I assume nothing bad? Can it be spent?
the existing UTXO should be spent back to itself, adding funds as necessary.
Do I understand correctly that if I have 1 BCH in bitcoincash:qq123 (which is a CashChannel), and I want to top it up - I need to move that 1 BCH, add another input and send the total amount again to the same bitcoincash:qq123, right?
Maybe it would be best for Mainnet to expose an API which uses that implementation under-the-hood?
I think it's possible, yes. But generally I still need to understand some characteristics of this so that we can provide a consistent API
Great work, Jason! Really love what you're doing!
@bitjson @chaintip
chaintip
commented
4 years ago bitjson
commented
4 years ago What happens if an adversary sends some random amount to that P2SH output, creating a second UTXO? I assume nothing bad? Can it be spent?
Nothing bad: the owner can claim it whenever they like – also, if it is sent to a previously used address (where the payment_number is lower than the payment_number on the "real" cash channel) the receiver could also "re-execute" any previous payment_authorizations and oracle rate_claims to withdraw from the newly created channel. (Payment authorizations have a payment_number which prevent them from being used more than once, but if you send money to an old covenant address, they can be used again.)
Do I understand correctly that if I have 1 BCH in bitcoincash:qq123 (which is a CashChannel), and I want to top it up - I need to move that 1 BCH, add another input and send the total amount again to the same bitcoincash:qq123, right?
Yes, that's exactly right.
Great work, Jason! Really love what you're doing!
Thank you! I'm hoping to have something ready in the next month or two. 👍
@bitjson Would you mind helping me understand whether CashChannels is a good candidate to be included in Mainnet (https://mainnet.cash)?
As far as I understand - it's a P2SH wallet that has two unlocking methods so to say - spend by owner and spend by external entity where you want to pay to, correct?
If we step up - what arguments do I need to create this P2SH address? Some private key, it's corresponding public key hash, public key hash of the entity that we want to be able to spend it, amount monthly(?), maximum amount and ... a price oracle in form of it's public key (or hash)?
Does it work well if I have multiple UTXOs in this P2SH address?
Is it possible to use AnyHedge's(?) price oracle here from (cc @monsterbitar, I guess)?