A tiny Cashu Spilman channel update; I should make these mor...

SatsAndSports

npub1zthq85gksjsjthv8h6rec2qeqs2mu0emrm9xknkhgw7hfl7csrnq6wxm56

hex

909829b5075bccaaa0e61deec2a3c9c52f3761c68e4af7996c928df7b4e4b8f4

nevent

nevent1qqsfpxpfk5r4hn925rnpmmkz50yu2tehv8rgujhhn9kf9r0hknjt3aqprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgsp9msr6ytgfgf9mkrmapuu9qvsg9d78ua3ajntfmt580t5llvgpescg0ewz

Kind-1 (TextNote)

2026-03-27T23:47:58Z

A tiny Cashu Spilman channel update; I should make these more often:

While the server side (i.e. payment receiver) code is in a reasonable state for now, in terms of flexibility and a clear state machine, I'm now catching up with a similar approach on the client side

Just today, I'm adding an 'Opening' state to the client, just before 'Open'. The client opens a channel by creating a 'funding token' with the mint, a token which is in a 2-of-2 multisig very similar to a Lightning channel. If the swap (or melt) which creates that fails (or appears to fail, from the client's point of view), then the client should probably try again or use NUT-09 to get the response. So I'm implementing and testing that now

https://github.com/cashubtc/nuts/blob/main/09.md

The code is now a library which depends on the CDK, i.e. no longer a (disorganized!) fork of the CDK:

https://github.com/SatsAndSports/cashu_spilman_channels/blob/main/ARCHITECTURE.md#channel-lifecycle-server-perspective

Raw JSON

{
  "kind": 1,
  "id": "909829b5075bccaaa0e61deec2a3c9c52f3761c68e4af7996c928df7b4e4b8f4",
  "pubkey": "12ee03d11684a125dd87be879c28190415be3f3b1eca6b4ed743bd74ffd880e6",
  "created_at": 1774655278,
  "tags": [
    [
      "t",
      "channel"
    ]
  ],
  "content": "A tiny Cashu Spilman channel update; I should make these more often:\n\nWhile the server side (i.e. payment receiver) code is in a reasonable state for now, in terms of flexibility and a clear state machine, I'm now catching up with a similar approach on the client side\n\nJust today, I'm adding an 'Opening' state to the client, just before 'Open'. The client opens a channel by creating a 'funding token' with the mint, a token which is in a 2-of-2 multisig very similar to a Lightning channel. If the swap (or melt) which creates that fails (or *appears* to fail, from the client's point of view), then the client should probably try again or use NUT-09 to get the response. So I'm implementing and testing that now\n\nhttps://github.com/cashubtc/nuts/blob/main/09.md\n\nThe code is now a library which depends on the CDK, i.e. no longer a (disorganized!) fork of the CDK:\n\nhttps://github.com/SatsAndSports/cashu_spilman_channels/blob/main/ARCHITECTURE.md#channel-lifecycle-server-perspective",
  "sig": "41294ae8ca61f365d6a766278d4f2160e581ce8f2e938e2283885a62f86f441411713b2ded6c8aa9f6f1048f723738819b1f782eddfee84fc503641c7abece69"
}