Damus
Open in Damus

Recent Notes

jdlcdl profile picture
I think it's worth recording and timestamping the`whois` reports for these domains today. Many were updated -- within minutes or hours of each other. It feels like they're all controlled by the same decision maker. If you don't timestamp these as they are right now, will lose that this activity occurred in response to this post since someone can decide to update later in a less suspicious manner.
jdlcdl profile picture
On Sunday, June 29th 2025, I built and verified the following images for SeedSigner release v0.8.6:

```
file: seedsigner_os.0.8.6.pi0.img
sha256: da32ce21f185404ccefd58e76e55ae7f1ac9fe2df2100bc7bbab3e03c5d71b6d

file: seedsigner_os.0.8.6.pi02w.img
sha256: d1669ad3aec6046dc43a673056a258e00c389ce23fa0ff754378cd0267516888

file: seedsigner_os.0.8.6.pi2.img
sha256: 029ecacc6ba45ae23cb953d7111cf98b0689f1eefb1cee101300acb10167b098

file: seedsigner_os.0.8.6.pi4.img
sha256: 47879ded57a91ecf46dbb44825699c53550bbf5aa6aa7c5b6519913a8863d157
```

Others have also verified binary reproducibility; you can too.

https://github.com/SeedSigner/seedsigner/releases/tag/0.8.6
~
jdlcdl profile picture
Couldn't the same result be achieved -- over time with an option for opting-out, by doubling the -datacarriersize default with each future release?

It might leave the choice (at least the perception of choice) with the individual node runner.

It might offer the chance to learn over time that it is, or is not making things any worse.

It might not be so much different than node runners upgrading slowly.

It might not provoke node runners who are worried about this change to considering ditching bitcoin-core right now, many years before this merge would even make a difference (since many won't upgrade immediately).
jdlcdl profile picture
If those file contents don't each hash to their name and they're not empty contents: Is it possible that there is some common "seed" that they were hashed with and you just need to find that seed? Or some common xor that is needed but not known that makes them appear "corrupted"? If they're not empty contents, I wouldn't ditch them just yet.
jdlcdl profile picture
What does "corrupted" mean?

Does it really the case that those files' contents don't each hash to their name?
jdlcdl profile picture
While github's SeedSigner/seedsigner-translations repo, a submodule of seedsigner, will be the target for pull-requests, the idea is to organize all translators and one validator per language within transifex. The validator for each language would then issue the pull request once translations are polished.

So all translations for untranslated strings, and suggestions for already-translated strings can be done exclusively in transifex.

Thank you in advance for taking a look. No matter how many times a single translator looks at a translation catalog, another translator can almost always easily identify improvements.

I'll let Ace/BitcoinPrecept know to look out for you.
jdlcdl profile picture
OMG -- how kind! I cannot resist such an offer.

Hoping to have more eyes on the french translation of seedsigner v0.8.5 soon. Currently there is a natural francophone translating and validating at transifex -- and myself (qui parle le français comme une vache espagnole, "Mooo").

Latest screenshots are in my fork:
https://github.com/jdlcdl/seedsigner-screenshots/blob/v0.8.5%2Bfr/fr/README.md
Note that these screenshots are static, but the app on device is not. Where you see overruns in screenshots (text running past the right side of the screen) at least for the PageTitleLines and Buttons... that text will gently scroll back and forth on a seedsigner device so that all text is readable.

...while the project is:
https://github.com/SeedSigner/seedsigner/blob/dev/README.md

...and translators (and validators) organize per language at:
https://explore.transifex.com/seedsigner/