Recent conversation about Channels implemented with Crypto Conditions. James does a quiz about how they’re secured, until the CC dev Mihailo writes his explanation. Showcase the power of this contract system:
Hi, I’m looking for all of the information I can get on Channels CC and would be grateful if you could point me towards some. I saw you mentioned a manual!
Updated by @Mihailo ChannelsCC doc with RPC calls description can be found here:
here is also a concept description in comments on top
Can anybody other than @Mihailo describe how it is possible for mempool tx to be dPoW protected?
First fund the Channels CC address of the recipient. Wait for the tx to be dPOW protected so it can’t be reorganized.
This funding utxo can only be claimed by the recipient if he can produce a secret.
So when the sender reveals a secret, the recipient can claim the funds that correspond to it. This funding will be valid until the channel close tx hits the mempool.
After tx that creates the channel tx goes into dPoW. The channel tx (split into 1000) can only be spent once.
what @gcharang said
Also the channel close will take effect after the next notarization. So all the funds whose secrets are revealed will be claimable even if there was a reorg attempt
Close, but not quite.
Each channelpayment is a different tx, and not necessarily in the same block
Even if any of them are invalidated by a reorg and double spend, the payment is still valid. How is it possible for a payment to survive an actual reorg that double spends all the inputs?
I wondered about having separate state hash for each channel. And this state hash notarising
The recipient node has to be online and take notice of the secret so that he can send the transaction?
Once the secret is revealed, that allows collection of payment. No need for the sender tx
so even if the payment is reorged and invalidated, the receiver just issues another spend using the secret.
Now if the receiver is not online, he would miss the chance to do this, but in this case the assumption is that the value transfer hasn’t been done
Yes. If the receiver is providing value online, he will have the ability to monitor the mempool
So both nodes don’t need to be online for this to work and all the tx are normal tx compatible with wallets and explorers, etc.
What is the format of this secret?
Is this a correct statement: the sender has “pre-spent” the funds into the channel. The channel is always available (until channel is closed) for recipient to reveal secret for that tx in the channel.
The sender can close the channel and reclaim funds
The channel is nothing but a output created by the sender. It will have the following constraints:
1) It will only be ever spendable either by the receiver or sender
2) receiver can only spend it by revealing a secret only the sender knows (so making a payment means, the sender is reveling a secret)
But the sender can’t reclaim the funds until after the close channel is notarized
So the sender has total control by releasing secrets and as soon as it hits the mempool, it is secured by dPoW that the receiver will receive payment
And all of it is blockchain enforced in a backward compatible way, this is why I say Channels CC is an improved LN
The method for secret revealing is via hashchain, very efficient encoding of hash secrets
And the receiver, in case of re-org, can just re-reveal the secret to receive the funds in the channel tx (lots of things to consider)
Hashchain – yes i recall reading it now. Clever/Efficient
Time from concept to initial release, less than a month, and by a new CC dev
I would describe the channel CC like this:
1) Sender “locks” funds in the Channel CC address that is spendable by sender or receiver ONLY!
2) Then sender make payments to receiver in new transactions, and in that payment tx also the secret for that amount is now known
3) If receiver wants to make a payment (this will usually be done only when the payment from sender some how did not reach receiver – for example chain reorg) he must provide the secret. This implies that receiver was online and saw the tx with payment from sender and noted the secret for that payment
4) If sender wants to withdraw fund from channel (he do not want to have channel to receiver anymore), then he first must do a close tx which will just mark that channel will be closed and receiver can see that, and then after close tx is confirmed he can issue refund tx and take the funds.
As jl777 mentioned the biggest advantage of Channel CC is that it has enabled to secure payments that are in mempool with dPoW. I first did not realized how, but with this explanation it gets a lot clearer:
– when the channel is opened and that open tx is notarised basically it means that the amount locked in channel address is known that it will definitively reach either receiver or back to sender. Now when payments are done, by the time they reach mempool, both sides can see them and the secret which is needed to spend them. So, it is not needed to wait the tx to end up in the chain or to be confirmed, because as soon the receiver has the secret for the payment he knows he will get those funds. In other words, you can say that when a payment is done it is immediately confirmed.
In the case that sender closes the channel, he still must wait for notarization to happen before he can withdraw funds. So the receiver will see that channel will be closed and no more funds will get to him.
It enables small chains to be used for point of sale instant payments and once Channels CC can pay assets, it can be KMD or even BTC equivalents being sent on the small chain, all secured by dPoW and valid in seconds. The combined power of channels, assets, oracles and gateways combined is hard to fully comprehend
And the sender cannot send the payment and close the channel in a quick enough time, because the closing of the channel requires notarization?
Sender cannot send payment and withdraw funds quickly, as to withdraw it first must be closed and then the close must be notarized which needs more time than the payment to reach receiver.
Likely some fancy whitepaper and ICO could have been made for the Channels CC, we just implemented it in a month instead. Of course we still need to find all the bugs and fix them and add support for tokens
You must think of Channel CC as instant payment where both sides are present because probably there will be some return from receiver in some form (goods, digital stuff …) . Good example is you are buying coffee in Starbucks, you send the payment to Starbucks and they see it instantly and give you coffee. If you do not send payment they will not give you coffee, if one side (usually the receiver) is not present then you would usually not use Channel CC for tx ( but you still can).
With LN, I think if you are not online all the time, your funds could be at risk
Could Channels be compared to a prepaid debit card? Bought with channelsopen?
Great for Starbucks, etc.
Smaller coins can get immediate and secure credit for purchases
I guess more like a Starbucks card, only usable at Starbucks. Need a different card for each business?
True, it is 100% p2p
Maybe some intermediary will setup some sort of hub service
I wonder there may be some hub with points
Which is possible, just not mandated like it is for LN
Like a rabbit card here in Thailand – you have card can pay in metro, mcdonalds, burgerkings and etc
A prepaid wallet app.
Yes, as long as the hub takes care of the backend, why not?
They can know their payment is securely received
So this seems the proper way to do LN
Make it 100% p2p at the low level, backward compatible and not require both nodes to be online
Then you can add a hub on top without requiring an entirely new set of daemons, wallets, explorers, payment processors, etc
Seems a nice clean and efficient design
And this is only one of the CCs.
Things sure are going to get exciting.
I’ll get back to trying it out.
Yes each CC is like an entire crypto project
Yes! And then starting to combine them. Seems like almost anything will become possible!