Last Notes
Can't reproduce the problem: https://github.com/openoms/joininbox/pull/201
Maybe you have something custom in your ~/.joinmarket/logs/yigen-statement.csv file. Try a fresh one.
Correct, tested with Bitcoin Core 31.1.
See the FAQ entry about the watch-only descriptor wallet migration: https://github.com/openoms/joininbox/blob/master/FAQ.md#migrating-from-legacy-walletdat-to-descriptor-wallet
Tagged a new release of Joininbox v0.9.0
https://github.com/openoms/joininbox/releases/tag/v0.9.0
Can update using the UPDATE option Joininbox on both #Raspiblitz and on standalone installs.
https://blossom.primal.net/70a0791a3ce7381c33822384f63773b2eb4c7159310cc052b561c9d8721f7ee1.png
https://blossom.primal.net/25b25c4f0b0ffec5eab9a6b72f7e43d3a412c253a882be7899517e9cb0a1d5fa.png
#joinmarket #joininbox
That tweet came with an explanation:
https://blossom.primal.net/f4e0f78db4c18bdc8a7e72bcff3d1122fdc84c57bc1e24c32a3494dd22a54aa0.jpg
This is the stated trust model.
At least there is not one operator, but 3 currently with more possible.
The operators can freeze the service, not the funds.
Exit txs are pre-signed: with a saved recovery bundle the unilateral exit needs zero operator involvement. That's exactly what we tested on mainnet.
Caveat, stated in the post: the bundle must be saved while they still serve you.
By "all operators colluding for theft" I mean all of these at once:
- every operator keeps its key share for a previous state of the leaf instead of deleting it
- all of them sign with those old shares - even combined, that is still not a full key
- they also need the previous owner of the leaf to sign, or to be that previous owner themselves
There are real cases where the SSP is the previous owner, so in practice it reduces to: you are trusting at least one operator to actually delete previous states. That is the stated trust assumption.
Not trustless, and the post does not claim it is.
The updated text says:
Operators can never spend your funds alone.
One operator is certainly insufficient.
Can you actually leave?
We tested it on mainnet: forced a 100k sat Blink wallet out of Spark, back onto Bitcoin.
No operators, just the seed and a saved recovery bundle.
Costs, lessons, code and txIDs onchain: https://www.blink.sv/blog/case-study-spark-unilateral-exit-on-bitcoin-mainnet
Trust model reiterated. In-app exit next.
https://blossom.primal.net/6b52378ae7021c536822009cf79e3529e5bbf2a33ba5384ab7798e72698937c3.png
You can exit with seed only if your wallet took care of saving the recovery bundle while operators were online and willing.
We will have this safeguard in Blink shortly and hope to see it in other Spark based wallets too.
Yes, fees to exit unilaterally should be comparable to Ark as it also uses this kind of transaction chain to be broadcasted.
There are many variables which can be tweaked:
- number and sie of the leaves/vTXOs
- depth of the chain to broadcast
- timelocks
- fee/rate
Ark solutions have this periodical onlineness requirement and ongoing fees for rounds as wrll which make them have different tradeoffs.
Spark works now, but no wallet should be locked in to it. Let it and the alternatives evolve. Our job is to keep our eyes open and assess the risks.
Yes, the feature was added to our tool today: https://github.com/blinkbitcoin/spark-unilateral-exit/pull/11
The consolidation comes with a tradeoff between efficient unilateral exit and fast transactions (lacking denominations will need more swaps with SSPs at payment time).
https://blossom.primal.net/64292f781d0778d13692bdb0f94521b4a16e92cb053734aa26ae6310e61b199b.png
Correction: "seed only, no operators" compressed two steps. The leaf data (recovery bundle) must be fetched while operators are online. The exit itself then needs nothing from them: seed + saved bundle is the accurate claim. Full mechanics and costs: https://github.com/blinkbitcoin/spark-unilateral-exit/blob/main/docs/mainnet-exit-case-study.md
Correction: "seed only, no operators" compressed two steps. The leaf data (recovery bundle) must be fetched while operators are online. The exit itself then needs nothing from them: seed + saved bundle is the accurate claim. Full mechanics and costs: https://github.com/blinkbitcoin/spark-unilateral-exit/blob/main/docs/mainnet-exit-case-study.md
Yes, correct, one either keeps a server up with their seed or the mobile does it.
In Blink we will have event-driven and likely also periodical refresh built in.
The data-availability dependency is real and worth stating exactly, so let's state it.
Operators never hold your key and can't move funds without your signature - that part is unconditional. Unilateral exit works through pre-signed refund txs that pay to a key only you control, and those txs plus their ancestors are the "leaf data" in question: your device co-signs them at claim time, ancestors come from a query. Until a wallet persists that data, forcing your funds on-chain depends on operator liveness. Grubles is right that no wallet ships this today. That gap is the entire reason I built and published this tooling instead of just claiming "non-custodial" in marketing copy.
What the dependency actually is, once you persist the data:
Bounded: everything covered by your last refresh exits without any operator, forever. Exposure is only what changed since then. With refresh wired into every claim, that window is one transaction.
Detectable: withholding means your refresh fails right after your claim succeeded. You notice, you stop receiving, you exit with what you have. - Compare a custodian, where withholding looks like normal operation until the withdrawal freeze.
So on the spectrum: weaker than Lightning, where your node holds channel state by construction. Much stronger than custodial, where they hold both keys and data and you detect nothing. "Self-custody of keys with a bounded, detectable data-availability dependency" is the honest label.
Wallets that don't manage that dependency for users are shipping the weak end of the spectrum. Mine included, today. That is what is being fixed, and the case study is the receipt that the exit half already works:
https://github.com/blinkbitcoin/spark-unilateral-exit/blob/main/docs/mainnet-exit-case-study.md
Alt link:
#nevent1q…9lqe
The only way to get the offchain data from the operators why they are online.
Wallets should (Blink will) implement periodic background polling for data.
Find the case study here if getting 404 from github:
https://njump.me/naddr1qvzqqqr4gupzp2kq0k2s388x4hcghy2k6s7p5j44jnrpxzmaevfwcxvsprzcrx30qythwumn8ghj7un9d3shjtnswf5k6ctv9ehx2ap0qy2hwumn8ghj7un9d3shjtnwdaehgu3wdp6j7qq4d9zy2h64tfmks7nctpmkg36v2e05x4nwty8vne59
The repo was just made public, might be lagging to show:
https://github.com/blinkbitcoin/spark-unilateral-exit
I just force-exited a non-custodial Blink wallet (using Spark) on Bitcoin mainnet.
Seed only - no operator cooperation: recovery bundle, fee funding, CPFP signing and sweep all derived from the wallet seed.
The honest numbers for a 100k sat wallet:
• 22 leaves, 253 tx packages to exit fully
• only 4 leaves (90% of the value) were worth exiting - fees would have eaten the other18
• ~9.4k sats in fees to recover 90.1k, one package per block per chain, then a ~2-week timelock
Non-custodial means you can always leave. But the fire escape is narrow - full case study with costs, failures and lessons:
https://github.com/blinkbitcoin/spark-unilateral-exit/blob/main/docs/mainnet-exit-case-study.md
https://blossom.primal.net/3771944c21849fd461b5a1a2cd13515755f1d232690ea5b633fd2b7c95f5135c.png
#joinmarket #joinmarket-ng
#nevent1q…9ncu
to add the special logging entries mentioned add these to your bitcoinconf:
debug=bench
debug=net
then restart sbitcoind:
sudo systemctl restart sbitcoind
If you are up for doing some Bitcoin research, you can join this experiment on the default signet chain on Wednesday:
https://delvingbitcoin.org/t/consensus-cleanup-demo-of-slow-blocks-on-signet/2367
Syncing signet on an RPi5 should take less than an hour (but allow a little more time just in case).
You can start the signet bitcoind instance on a Raspiblitz by running:
config.scripts/bitcoin.install.sh on signet
You will have these aliases set in terminal for easy monitoring and configuration:
alias sbitcoin-cli="sudo -u bitcoin /usr/local/bin/bitcoin-cli -rpcport=38332"
alias sbitcoinlog="sudo -u bitcoin tail -n 30 -f /mnt/hdd/app-data/bitcoin/signet/debug.log"
alias bitcoinconf="sudo nano /mnt/hdd/app-data/bitcoin/bitcoin.conf"
The systemd service is called: sbitcoind
so can check and restart with:
systemctl status sbitcoind
sudo systemctl restart sbitcoind
#raspiblitz #signet #bitcoin
https://image.nostr.build/fa32132bd4c857b592a5fe08c4e7d7ebd293dd22a27fa79194188a12b55ee9bf.png
Let's try the new Joinmarket implementation on signet first
PR for #Raspiblitz: https://github.com/raspiblitz/raspiblitz/pull/5240
#naddr1qq…8hlp
Is this USA₮ pronounced you-sat? https://tether.io/news/tether-announces-the-launch-of-usat-the-federally-regulated-dollar-backed-stablecoin-made-in-america/
Are you thinking what I am thinking?
#satsthestandard
Opencode web running as a systemd service, exposed via Tailscale is a great alternative to clawdbot if your main usecase is coding.
#nevent1q…ggrh
Google Pay is the only significant thing which does not work with GrapheneOS, but you can use a smartwatch.
Tested Garmin Pay so far, no problems.
Great track @npub1p2p…6rap, stuck on repeat: https://wavlake.com/track/a6094897-0a5c-49e3-b72b-08ba6bcb4f4d
Can't stop the algo to gaslight about the current thing.
I come to X only to unfollow people. Maybe mute too.
This is awesome!
Also please let us set a gap limit or specify the number of monitored addresses for both the deposit and change accounts.
Some well used wallets will thank you!
Looks all right in Amethyst.
Check out the Sparrow Server, it has a fully featured Terminal UI:
https://sparrowwallet.com/download/
Open source, bitcoin native soft fork betting without intermediaries 👌
#nevent1q…t863
True, but at least using the Free Open Source client Molly you can share between devices https://image.nostr.build/e91113ecaec178f4562b8da0154a971842257b4943dfd7a7293199b789ca72ab.jpg
Nothing more motivating to hold your own keys than a hard fork lined up.
Yes, there is a whole section in the docs about different scenarios: https://docs.raspiblitz.org/docs/community/storage_migration
#nevent1q…pl6w
You can always exit to the terminal with CTRL+C then type: `menu`
If you have no channels might need to add a lightning peer manually to progress from the startup sync screen.
Just because a block is mined by Ocean it is not guaranteed to be spam free exactly because they allow custom templates.
#nevent1q…svjk
a node was out of space 👾
(but now runs ok)
There are imges on github which need to be flashed on a small OS disk: https://github.com/raspiblitz/raspiblitz/tree/dev/alternative.platforms#amd64-image
and for now expects to have a second physical large (best 2 TB) disk for the blockchain and other data.
The next major release will support setting up on a single disk.
Currently still in testing phase, but close.
Can the supply of shielded zcash be verified?
How about the effect of past bugs on the shielded supply?
have a VPN exit node, but not in the UK
https://reclaimthenet.org/reddit-enforces-uk-digital-id-law
There is nothing like that mentioned. BCH was just moved first possibly to test the private key, no trade was done.
Great read: https://www.cyphertux.net/articles/en/research/bitcoin-80k-btc-mystere-opreturn
we are living the sci-fi.
#nevent1q…f26w
@nprofile…lzc5 do you have a status update?
Both the website and service is down.
www.isitdownrightnow.com/lnvps.net.html
Screenshot of the two commands needed to update BTCPayServer on a Raspiblitz:
https://image.nostr.build/e4b1628e16a4bac48575f15c679dba42584aff5c7b9ec92b26af799926a354ba.png
To update #BTCPayServer on a #Raspiblitz you will need the latest install script:
# download the latest script from the dev branch:
wget -O /home/admin/config.scripts/bonus.btcpayserver.sh https://github.com/raspiblitz/raspiblitz/blob/dev/home.admin/config.scripts/bonus.btcpayserver.sh
# To update use the UPDATE menu or run:
/home/admin/config.scripts/bonus.btcpayserver.sh update
This part has the fix:
https://image.nostr.build/4580416e3f5525dacfb27bf1cc50fb75271fde2e7241d2234032c09b6960a40a.png
#nevent1q…q7qx