CHIP-0041: Streaming Puzzle

[Yakuhito]

No description provided.

[hoffmang9]

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.

[Rigidity]

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

[Yakuhito]

Excellent points - updated prefix to stream/tstream

[MichaelTaylor3D]

I like stream / tstream as well

[danieljperry]

Thanks, @Yakuhito! This CHIP is now a Draft. Please leave your reviews here.

[danieljperry]

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?

[danieljperry]

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?

[danieljperry]

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

[MichaelTaylor3D]

@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?

[MichaelTaylor3D]

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]

@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?

Added

[Yakuhito]

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?

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.

[Yakuhito]

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).

[danieljperry]

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.

[MichaelTaylor3D]

this is specifically how i intend to use this puzzle

[danieljperry]

We will discuss this CHIP in a public Zoom call on Feb. 20. See the #chips channel in our Discord for more info.

[Yakuhito]

Presentation slides can be found here

[danieljperry]

Here is the video from the public discussion of this CHIP:
https://youtu.be/QUvbveve3EU

[danieljperry]

This CHIP is now in Review. Please leave your reviews here. If no further changes are needed, the next step is Last Call.