Chia-Network
CHIP-0041: Streaming Puzzle
Darn cool.
My only comment so far is that "s" may be too short to be good UX for the bech32m encoding.
Maybe "sub" or "stp"?
Not sold on any specific thing but I think one character doesn't do a good job disambiguating it from the encoding itself.
Not sold on any specific thing but I think one character doesn't do a good job disambiguating it from the encoding itself.
Same, I'd even say a whole word like stream would be a good prefix, it works well for offers
Thanks, @Yakuhito! This CHIP is now a Draft. Please leave your reviews here.
It's not immediately clear who can call the clawback puzzle. The first point this is clarified is in the Rationale section ("Giving the sender the ability"). Can you briefly mention the "who" part a bit earlier?
It's also not totally clear where the blockchain fees will come from. Assuming they have to be paid from an external source, can you include some info about this as well?
It also appears that a tradeoff with this coin is that the person creating it must commit funds to it before they are owed. Assuming I understand it correctly, can you add some more info regarding this tradeoff?
For example, if a subscription costs 1 XCH per month, then
- Old way: using the standard puzzle, the payer could send 1 XCH per month to the payee
- Positive: payer doesn't need to lock up any funds in advance
- Negative: payee must collect each month, payer must remember to pay each month
- New way: using the puzzle from this CHIP, the payer creates a streaming coin worth 12 XCH
- Positive: payer doesn't need to remember to make a new payment each month, payee can collect the current amount due at any time
- Negative: payer must lock up 12 XCH in advance, and cannot access those funds without clawing back the coin
@Yakuhito, could you clarify whether setting clawback to null or empty effectively disables the clawback mechanism? I’m exploring use cases that require a permanent commitment to the stream, which we’ve discussed previously. At the time, I was uncertain about the level of effort needed to support both clawback and no-clawback scenarios. However, based on my recent review of the code, it seems feasible to enable both options. Could you share your perspective on whether this approach is viable?
It also appears that a tradeoff with this coin is that the person creating it must commit funds to it before they are owed. Assuming I understand it correctly, can you add some more info regarding this tradeoff?
For example, if a subscription costs 1 XCH per month, then
Old way: using the standard puzzle, the payer could send 1 XCH per month to the payee
- Positive: payer doesn't need to lock up any funds in advance
- Negative: payee must collect each month, payer must remember to pay each month
New way: using the puzzle from this CHIP, the payer creates a streaming coin worth 12 XCH
- Positive: payer doesn't need to remember to make a new payment each month, payee can collect the current amount due at any time
- Negative: payer must lock up 12 XCH in advance, and cannot access those funds without clawing back the coin
This design choice was intentional. The primary objective was to pre-mint the total token supply and distribute it to various parties under controlled emission schedules. By doing so, we can avoid releasing too many tokens into the market prematurely. Instead of transferring full ownership of the tokens outright, we commit to an emission schedule that gradually releases the supply over time.
This approach takes inspiration from Bitcoin’s fixed supply of 21 million coins and its transparent, predictable issuance. By using a puzzle-based model, we can similarly guarantee a consistent emission schedule, ensuring that the market knows exactly when and how many tokens will be introduced. Such predictability allows for more stable token economics and a reliable framework with provably immutable emissions assuming the clawback is disabled.
@Yakuhito, could you clarify whether setting
clawbacktonulloremptyeffectively disables the clawback mechanism? I’m exploring use cases that require a permanent commitment to the stream, which we’ve discussed previously. At the time, I was uncertain about the level of effort needed to support both clawback and no-clawback scenarios. However, based on my recent review of the code, it seems feasible to enable both options. Could you share your perspective on whether this approach is viable?
Added
It's not immediately clear who can call the clawback puzzle. The first point this is clarified is in the
Rationalesection ("Giving the sender the ability"). Can you briefly mention the "who" part a bit earlier?
Added. The creator of the stream would usually set one of their puzzle hashes as the 'clawback puzzle hash' (the puzzle hash that can stop the stream early). As Michael mentioned above, the clawback puzzle can also be (), in which case no one will be able to stop the stream early.
It's also not totally clear where the blockchain fees will come from. Assuming they have to be paid from an external source, can you include some info about this as well?
Either the receiver or the claw back puzzle have to send a message to spend a stream coin. The fees would either come directly from the party interested in claiming the funds (i.e., party initiating the transaction) or from a 'sponsor' (such as a fee service).
This design choice was intentional. The primary objective was to pre-mint the total token supply and distribute it to various parties under controlled emission schedules. By doing so, we can avoid releasing too many tokens into the market prematurely. Instead of transferring full ownership of the tokens outright, we commit to an emission schedule that gradually releases the supply over time.
This approach takes inspiration from Bitcoin’s fixed supply of 21 million coins and its transparent, predictable issuance. By using a puzzle-based model, we can similarly guarantee a consistent emission schedule, ensuring that the market knows exactly when and how many tokens will be introduced. Such predictability allows for more stable token economics and a reliable framework with provably immutable emissions assuming the clawback is disabled.
Interesting, I wasn't thinking of it being used in this way. It would be good to have a few use cases, along with the advantage of using this CHIP for said use cases, spelled out explicitly in the CHIP. Especially since there are probably several ways this type of coin could be used.
We will discuss this CHIP in a public Zoom call on Feb. 20. See the #chips channel in our Discord for more info.
Here is the video from the public discussion of this CHIP: https://youtu.be/QUvbveve3EU
This CHIP is now in Review. Please leave your reviews here. If no further changes are needed, the next step is Last Call.
You can create, view, and claim streams via Sage (WalletConnect) at streaming.fireacademy.io. Here's an example stream: stream138c950ha8vnu4ckhjkzn5qfusrlz47ug909wznn498mr77ml23yq3ww7nc
This CHIP is now in Last Call. If no further changes are required in the next two weeks, it will become Final.
I know it is late but I think I spotted possible code optimizations
- Replace
(if (= to_pay (/ (* my_amount (- payment_time LAST_PAYMENT_TIME)) (- END_TIME LAST_PAYMENT_TIME)))with(if (= (* to_pay (- END_TIME LAST_PAYMENT_TIME)) (* my_amount (- payment_time LAST_PAYMENT_TIME)) )
Multiplication is slightly cheaper than division. Moreover, division produces rounding errors while multiplication does not.
- Instead of currying in END_TIME curry in the difference of END_TIME and LAST_PAYMENT_TIME (and update the above line of code accordingly) so that we save some cost on subtraction.
Thank you very much for your comment! Both changes would indeed make the code slightly more efficient.
Given that the optimizations are minor, that this CHIP should've been Final a week ago, and that there are already streams on mainnet using the current code (supporting two standards is a lot of trouble), I think the best path forward is to keep the code as it currently is.
But, again, thank you very much for the comments - both changes could be turned into more general optimization methods, which I now have in my toolbox.
Sorry for the delay. This CHIP is now Final. No further changes are allowed.