21M4TW

#Bitcoin

Public Key

npub149v86624757a5l7vne09j3h2p7qajllnz7ecpvghl8ptzcg32hrscs567q

Profile Code

nprofile1qqs2jkrad92l20w60lxfuhjegm4qlqwe0le30vuqkytlns43vyg4t3cpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsuetwyg

Publishing to

relay.damus.io

nos.lol

public.relaying.io

Author Public Key

npub149v86624757a5l7vne09j3h2p7qajllnz7ecpvghl8ptzcg32hrscs567q

Show more details

Last Notes

2026-07-19 01:47:24 UTC

- reply

This is correct that both would not be independent. Passphrases could help to some extent, but it is not as good as separate entropy. Looks like there is no way around using multiple CCs. Multiple SSSPs on the same device would be ideal...

2026-07-19 01:42:55 UTC

So with the #Coldcard spending policies, is there a plan for spending rate support in the future? E.g. x sats/day, so multiple smaller spends would be possible instead of a single bigger one during a provided fixed period?

2026-07-19 01:35:31 UTC

- reply

For my onchain footprint I would like to stick to plain single sig + multisig txs

2026-07-19 01:34:10 UTC

- reply

It would not be a decoy though, I would use it as a regular single sig. It would just be a way to have an independent single sig wallet in addition to the SSSP

2026-07-19 01:28:34 UTC

- reply

It does seem that if I add a trick pin pointing to a dureas wallet, then I can use the regular pin to point to the SSSP enclave while using the trick pin to point to a separate (duress) wallet without a policy?

2026-07-19 01:24:53 UTC

- reply

I want to enforce a spending policy for a collaborative multisig wallet (using a single signature per CC), while retaining the ability to use a single sig wallet on each CC without a policy

2026-07-19 01:18:30 UTC

- reply

Anyway way so there is a way to use a different wallet without the policy?

2026-07-19 01:13:50 UTC

- reply

So the daily driver would be also stuck with the policy?

2026-07-19 01:09:36 UTC

- reply

Doesn't SSSP enforce the policy regardless of the passphrase? I wanted to delete the trick pin to enforce the policy for the multisig

2026-07-19 01:07:00 UTC

- reply

SSSP does sign multi-sig txs (just tested it). I saw that passphrases can be enabled for SSSP. What I want is for the user to for the user into the policy for the multi-sig, while allowing him to use a different wallet without a policy. Is this doable with a passphrase as you mentioned?

2026-07-19 00:31:55 UTC

Any way to have a spending policy on a #Coldcard for a multisig wallet where the master seed is not a part of while being able to use the master seed for unrestricted spending? CCC seems to requires the master seed to be part of the multisig and SSSP does not use a separate set of seed worrds for the policy?

2025-12-21 19:14:07 UTC

- reply

I think you are correct about the key path, but it can be disabled.

2025-10-30 18:40:49 UTC

- reply

@nprofile…wrn5 You should have a chat with these guys and the recent guests you have discussed decentralized directories with, to see if there is a better solution...

2025-10-24 13:35:39 UTC

- reply

I love and use both. OpenBSD for targetted systems with more limited functionalities, but where security is critical, and FreeBSD when more features are required and I still need a very stable environment. Neither have ever been very well suited for laptop use though.

2025-10-22 03:54:33 UTC

- reply

Has it ever recovered? I tried it for the first time today and I get an error for both the LLM and when trying to add funds via LN... Thanks!

2025-06-12 15:29:51 UTC

- reply

Would be great to have this accessible in Vanadium!

2025-06-11 03:55:12 UTC

I just sent a PR to add #bolt12 support to #NostrWalletConnect (#NWC, NIP-47) : https://github.com/nostr-protocol/nips/pull/1952
This would allow to leverage #NWC to create and use #Lightning #bolt12 offers and invoices.
#bolt12 enables reusable (static) payment requests (codes), increases receiver privacy and increased censorship resistance over #bolt11 (https://bolt12.org)
#NWC is a way for Lightning clients (apps, websites) and servers (nodes, wallets) to communicate through a standardized protocol using #Nostr relays. Many apps and wallets support #NWC. Many LN node implementations and apps support #bolt12. I think it would be great to extend #NWC for #bolt12 !
@nprofile…pyug @nprofile…4ph5 @nprofile…970s @nprofile…f224 @nprofile…f670

2025-06-10 20:43:38 UTC

- reply

He is also saying his company could be worth 10-40 times its earnings of a supply-capped asset, that there will not be a crypto winter until BTC hits 500k and then there will be only a 20% correction. Yeah... Maybe not

2025-06-09 21:20:35 UTC

#bolt12 support for #lnbits: https://github.com/lnbits/lnbits/pull/3092
#bolt12 support for #lnbits #NWC provider extension:
https://github.com/riccardobl/nwcprovider/pull/12

2025-06-03 19:33:20 UTC

@nprofile…pyug I would like to use @nprofile…7788 with Bolt12 offers, but currently there is no make_offer, lookup_offer, fetch_invoice, etc commands as part of NIP-47 . What is the way forward to have it added to the specs so it can be implemented by different wallets and clients? Thanks!

2025-05-27 23:05:43 UTC

- reply

Now let's properly implement Bolt12! Currently offers without node IDs are not supported by some nodes.

2025-05-16 10:59:41 UTC

- reply

There is some connectivity to it, but it returns the error: "Cryptograhic handshake: Operation timed out"

2025-05-16 10:46:48 UTC

- reply

I have not been able to connect to it for over a week, and mempool.space does not seem to be able either. Its IP addreas has not changed?

2025-05-16 02:13:31 UTC

- reply

When do you expect your ln.coinos.io node to be back online?

2025-05-06 03:01:34 UTC

- reply

The way I see it is that Knots can have some utility if you are a miner and want to exclude the spam from your block templates. Otherwise it does not do much useful besides being a sign of protest. Refusing to upgrade to the controversial version of Core would have a similar effect.

2025-05-05 20:06:13 UTC

I am thinking about switching my node to #Knots. Is it causing any issue when used by a Lightning node?

2024-05-06 13:21:12 UTC

- reply

Please someone correct me if I an wrong, but with JM it seems the on chain fees are paid by a single entity (single user with multiple market makers) for each tx, which is very costly?
Also the default behaviour in JM of consolidating all original input utxos is not ideal.
If a protocol could both share the txs between users and avoid tying the original input together, without impacting negatively the other characteristics, it would be awesome.

2023-11-17 23:03:00 UTC

- reply

I really appreciate SideSwap, but my only issue with it is that the peg-out fee rate (mandatory?) suggestions tend to stay stuck at very high values compared to the rates suggested by mempoopl.space . is there any workaround solution for this?

2023-05-30 01:44:30 UTC

- reply

This one was amazing, loved it! Right at the top with the Mandibles interview!