Avatar
dankswoops
20ed9331673df584362a43709dd29de705a1bb58f3cd2af8e8c0b5f82c54c099
Nostr Dev, client releasing in July. 7 world first stunts, 2 harness innovations. Created the 13th discipline in skydiving, Mixed Vertical Piloting.

HOW SECURE IS YOUR BITCOIN WALLET?

Are you afraid of getting hacked by quantum computers?!

I'm an entrepreneur / cyber security enthusiast risking my entire net-worth and time by building a bitcoin start up, so I had to do the math for myself. Buckle in because it's more secure than you can fathom.

Possible Combinations of BTC wallets per type:

Legacy Address: 25 commas

BIP-39 (12 word): 13 commas

BIP-39 (24 word): 26 commas

Legacy wallets (256-bit private keys):

2^256 = 115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936

(This is approximately 1.16 x 10^77)

BIP-39 12-word seeds:

2048^12 = 5,444,517,870,735,015,415,413,993,718,908,291,383,296

(This is approximately 5.44 x 10^39)

BIP-39 24-word seeds:

2048^24 = 29,642,774,844,752,946,028,434,172,162,224,104,410,437,116,074,403,984,394,101,141,506,025,761,187,823,616

(This is approximately 2.96 x 10^79)

The math above demonstrates that 12 word seed phrases are the least secure of all three wallet types. If there's 200 million bitcoin wallets and 160m of those are using 12 word seeds, this is the odds below of you getting hacked.

Let's say we have a supercomputer that can check 1 trillion (1,000,000,000,000 or 10^12) seed phrases per second. This is far beyond current capabilities but helps illustrate the scale.

We'll assume you're using this computer 24/7 for an entire lifetime. Let's say that's 100 years.

Now, let's do the math:

Seconds in 100 years:

100 years * 365 days * 24 hours * 60 minutes * 60 seconds = 3,153,600,000 seconds

Total number of seed phrases we could check in 100 years:

3,153,600,000 * 1,000,000,000,000 = 3,153,600,000,000,000,000,000 (about 3.15 * 10^21)

Probability of finding the correct seed phrase:

3.15 * 10^21 / 34,028,236,692,093,846,346,337,460,743,176,821 ≈ 9.26 * 10^-14

This means that even after 100 years of continuous checking at this incredible rate, the probability of finding a single valid seed phrase is about 0.0000000000000926 or about 1 in 10 trillion.

To put it another way:

If you had 10 trillion of these supercomputers running for 100 years each, you'd have about a 63% chance of finding one valid seed phrase.

To have a 99.99% chance of finding a valid seed phrase, you'd need to run this process for about 460 billion years - that's about 33 times the current age of the universe.

In conclusion, The number of possible legacy private keys is greater than the estimated number of atoms in the observable universe (which is around 10^80) 🤯🤯🤯

If you've heard this last statement before, they weren't exaggerating.

BITCOIN = HOPE

I met your friend Gary at the con today and found out about mentors. I'm excited to bump into you one day too.

This is the first post from the human rights super app that will innovate communications and finance on a global level. Our mission is to raise the collective human consciousness by building the required digital infrastructure of the future. Our founding focus is human rights for all people, and we vow to build software that makes it impossible to compromise anyone's freedom of speech and privacy for as long as this technology operates.

"This Nation was founded by men of many nations and backgrounds. It was founded on the principle that all men are created equal, and that the rights of every man are diminished when the rights of one man are threatened." - John F. Kennedy June 11, 1963

hey, Lyn. Do you have an alt account and is this npub you? PS. I love your book.

npub1498f4ya5laqfp53vt02ewqnhe94tvnl0ek7gn2tu6qeppr2pzk2sllz3y7

Replying to Avatar JeffG

Ok – so Signal is great. Good encryption, etc. Obviously, the main thing that we want to improve there is the centralized coordinator in the middle.

My original proposal was an adaptation of the Signal protocol for Nostr. https://github.com/nostr-protocol/nips/blob/2169fab971591d0b4a450ef08aeb6301c5d2a0da/104.md

But I got lots of feedback on that one that 1) group messaging needs to be first class and 2) multiple device support needs to be first class. Both of these are actually the same thing - supporting groups.

With the signal protocol, the way that the symmetric encryption works, when you're in a group, you're effectively creating a DM to every member of the group, encrypting it separately, and sending it out. Signal makes this feel like less of a big deal because they do some tricks on the server side to make it less heavy for the client.

In the nostr version of the signal protocol, you have no server to do work for you, so your device has to do all that work itself.

With MLS, because it's using a different data structure (binary trees) for managing encryption keys and users in a group, you go from a situation where group scaling is a linear problem (each new user in a group adds the same amount of work for all clients) to a log problem (where each new user in a group adds wayyyy less work for all clients).

There are also other benefits of MLS.

1) it's about to be an internet standard (like TLS, etc) so we conceivably get interoperability with other networks/clients

2) it's built to allow for the use of multiple ciphersuites and the graceful change/upgrade of the ciphersuites over time.

The only drawback is that it's very complex and very new. My work so far on getting MLS to Nostr has been focused on updating dependency libraries to allow for support of schnorr signatures over the secp256k1 curve (what nostr - and bitcoin - uses). I'm very convinced this is the right long-term solution for private messaging on Nostr but it's going to take a bit longer to get it probably ready for implementation.

If you haven't see it already, you can follow along with what I'm doing in my weekly posts. Also, if you're interested in working with me on all this, that'd be awesome.

nostr:naddr1qvzqqqr4gupzq9eemymaerqvwdc25f6ctyuvzx0zt3qld3zp5hf5cmfc2qlrzdh0qqxnzdejxy6rzwf5xvmnwveh25uk9n

nostr:npub1tx5ccpregnm9afq0xaj42hh93xl4qd3lfa7u74v5cdvyhwcnlanqplhd8g, check this thread out. we got some studying and work to do. :)

Hey, Jeff! I'm a nostr dev working on fusing signal and nostr currently. I might propose a NIP. What is MLS and please tell me more about why you think it doesn't scale with group chats. I'm able to do conference calls with signal client but I still don't understand enough to know why it's not the best solution or what else to be looking at. thanks

When creating a nostr client, how do I retrieve each users selected relays? If adding relays is a nostr event, do I have to hard code a client relay/s to find that nsec event of which relays they follow so the client can initiallize which relays to connect to on a per nsec basis?

what's comes first, the chicken or the egg here?

nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s nostr:npub16c0nh3dnadzqpm76uctf5hqhe2lny344zsmpm6feee9p5rdxaa9q586nvr nostr:npub18ams6ewn5aj2n3wt2qawzglx9mr4nzksxhvrdc4gzrecw7n5tvjqctp424

New Nostr Client Incoming!

This isn't your typical nostr clone, I'm building something completely novel.

I've almost finished the login system and I'll start updating my journey on here.

#NostrLayer2