Try scrolling a bit, here is what I see:
I don't understand this condition:
> if using a single backup and index based derived key sets including BIP85 32bit hex keys used as nsec.
But if I could get away with ignoring it, I would only quote this part: "I think it is the only option" and then I would say "it's clearly not the only option because bitcoin core doesn't use bip39."
Sadly, I can't say that without doing an injustice to what you said
I'm not sure, but personally, I find the bip39 standard confusing, and I don't exactly blame them for not following it
I'm very happy to say:
It looks like one of the Ark teams has finally launched a publicly available wallet!
All the cool kids
Finally, the uint8array format in javascript natively supports hex encoding
TIL bitcoin has a native REST interface for public blockchain data. Sadly, I don't think anyone enables the rest interface AND exposes it to the public internet AND sets a browser-friendly CORS policy
If you know someone who does, share their node's ip address and REST port here
I finished the podcast, but it went pretty poorly. My connection cut out partway through the first question I was asked, and when I finally managed to reestablish it, no one could hear me. So I did not get to ask your questions to the author. I did, however, send him the questions on telegram again, so we'll see if he replies.
Not yet. I will try to ask him on the podcast today, which we start recording in an hour. Thank you for the reminder!
I'm on a quest to build a browser wallet based on Bip157, Compact Block Filters. And I hit my first roadblock: I can't find any servers that serve compact block filters with a web-friendly interface
So I've opened an issue on electrumx. Please support it! https://github.com/spesmilo/electrumx/issues/315
The privacy section of bitcoin's white paper applies to lightspark
If you avoid linking your identity to your pubkeys, then you have pseudonymous privacy
It is also wise to avoid sending to the same pubkey twice, and if you do so, you still should take steps to manage cospends
I forwarded your questions to the author via telegram (I don't think he is on nostr) and if he replies I will try to remember to post his replies
I will probably forget though
To be "fair," they are also still giving billions to (some) americans: section 8 housing and federally-funded Indian health insurance are both considered "essential services" and continue to receive funding during the shutdown
that would be neat to see
you've probably heard of hostile takeovers in the corporate world
maybe soon we'll see blockchains doing them
Funny how the government can be shut down, unable to find enough money to fund itself, but it can still find enough money to fund the economies of other countries
https://www.newsweek.com/donald-trump-money-argentina-bailout-marjorie-taylor-greene-10889577
The Bitcoin SSL paper is interesting. I will hopefully go on the Bitcoin Optech Podcast on Tuesday to discuss it with the author. He thinks he has a solution to the Vault problem that could give a lot of people peace of mind, and I think he is probably right. Here's why.
First, here's a link to the paper: https://github.com/ilghan/bssl-whitepaper/blob/main/B-SSL_WP_Oct_11_2025.pdf
Their model has users put funds into a vault with a timelock of max 15 days til they can spend it via the "cooperative" path, otherwise there is a "sad path" by which the user can unilaterally recover it after 1 year, or a "very sad" path by which a custodial service can sweep the funds for the user after 3 years.
The 15 day timelock on the "happy path" is meant to insure users against kidnappers, who are less likely to kidnap you for your bitcoins if they have to keep you captive for 15 days and convince a service provider to cosign your tx.
But this protection is undermined if you send your money into the vault around the time you sign up for the vault service and then let it sit there for 15+ days. If you did that, the timelock would expire, and kidnappers would not have to worry about keeping you captive for 15 days.
To fix this, you either have to stop your money from entering the vault until you are preparing to spend it, or you have to cycle it: every 15 days, you must send your money out of the vault and straight back into it again.
Thankfully, both options are doable with presigned transactions, which can be created and stored when you sign up for the service. So this problem is fixable without introducing extra liveness assumptions for the user.
Also, if cycling is used, there are regular mining fees to pay, but these can be rolled into the service fees charged by the vault service provider or VSP. The VSP can just charge their users a monthly or annual service fee and then use some of that money to broadcast/pay for their cycling transactions without further action needed by their customers.
Besides transaction cycling, I came up with another, cheaper solution and proposed it to the author, which is this: have the user's money start off in Key Q. Sign a transaction that moves the money into the vault, then delete Key Q, and store the signature with the service provider, as well as keeping a copy yourself.
As a result, if you get kidnapped, your money can *only* enter the vault, where it then has to wait 15 days. This method avoids the extra costs involved with transaction cycling, and is simpler. But it requires secure key deletion, which is difficult to do, though not impossible.
I think this vault proposal may give a lot of people peace of mind. I had a conversation with a nocoiner recently and his first question was, "what if someone kidnaps you and demands that you send them your bitcoins or they will kill you?"
I wish I had known about this idea so I could tell him how bitcoin fixes this.
Tune in to Optech Podcast on Tuesday for more!
Here is a link to the podcast feed in case you want to subscribe early: https://bitcoinops.org/en/podcast/
The Bitcoin SSL paper is interesting. I will hopefully go on the Bitcoin Optech Podcast on Tuesday to discuss it with the author. He thinks he has a solution to the Vault problem that could give a lot of people peace of mind, and I think he is probably right. Here's why.
First, here's a link to the paper: https://github.com/ilghan/bssl-whitepaper/blob/main/B-SSL_WP_Oct_11_2025.pdf
Their model has users put funds into a vault with a timelock of max 15 days til they can spend it via the "cooperative" path, otherwise there is a "sad path" by which the user can unilaterally recover it after 1 year, or a "very sad" path by which a custodial service can sweep the funds for the user after 3 years.
The 15 day timelock on the "happy path" is meant to insure users against kidnappers, who are less likely to kidnap you for your bitcoins if they have to keep you captive for 15 days and convince a service provider to cosign your tx.
But this protection is undermined if you send your money into the vault around the time you sign up for the vault service and then let it sit there for 15+ days. If you did that, the timelock would expire, and kidnappers would not have to worry about keeping you captive for 15 days.
To fix this, you either have to stop your money from entering the vault until you are preparing to spend it, or you have to cycle it: every 15 days, you must send your money out of the vault and straight back into it again.
Thankfully, both options are doable with presigned transactions, which can be created and stored when you sign up for the service. So this problem is fixable without introducing extra liveness assumptions for the user.
Also, if cycling is used, there are regular mining fees to pay, but these can be rolled into the service fees charged by the vault service provider or VSP. The VSP can just charge their users a monthly or annual service fee and then use some of that money to broadcast/pay for their cycling transactions without further action needed by their customers.
Besides transaction cycling, I came up with another, cheaper solution and proposed it to the author, which is this: have the user's money start off in Key Q. Sign a transaction that moves the money into the vault, then delete Key Q, and store the signature with the service provider, as well as keeping a copy yourself.
As a result, if you get kidnapped, your money can *only* enter the vault, where it then has to wait 15 days. This method avoids the extra costs involved with transaction cycling, and is simpler. But it requires secure key deletion, which is difficult to do, though not impossible.
I think this vault proposal may give a lot of people peace of mind. I had a conversation with a nocoiner recently and his first question was, "what if someone kidnaps you and demands that you send them your bitcoins or they will kill you?"
I wish I had known about this idea so I could tell him how bitcoin fixes this.
Tune in to Optech Podcast on Tuesday for more!
If they fork to a new mining protocol, it has to start with low difficulty since no one has any equipment for it yet, and that makes 51% attacks even easier