can't believe they still accept usd for this.
Here is a personalized Nostr recap of TABConf 6 here.
I really do believe we made another historical event as a top 20 bitcoin conference of all time. No price discussion. No political discussion besides a bit of freerossing. Big focus on tech and steps towards progress. We experimented with some really cool ideas that worked out this year which we will be expanding on next year. Some examples were an emphasis on hardware, rotating debate panels, and rapid explainer game show.
Really looking forward to having TABConf also have a minor focus on meshtastic and doing long range mesh networking. Perhaps we will even connect nostr:npub1cst99sheckxrllnh9pw093mls775tdx80x99mq096pkl2t9r9swqsugekj to nostr:npub1theparkprcs70dcs437ke9zzwsr6u60f8flu7rg28m30438aep9sd94dha in the future.
The first ever TAB awards (Tabbies) happened this year. I think for a first pass it went pretty well.
Looking forward to having more Nostr involvement next year, perhaps people reading this may feel inclined to run a Nostr specific room or do an entire Nostr day at the same venue next year. Let me know if you want to plan this!
I believe TABConf is the only truly open source conference that is organized, and I hope we can keep expanding and improving the uX to make people feel comfortable getting involved.
We are selling tickets for next years conference already (Oct 13-16, 2025) mark your calendars. Tickets are all inclusive, there is no class of tickets and you aren't marked like cattle with an unremovable wristband.
Hope you consider coming out and building next year with us.
If you feel like you aren't technical enough, you are missing the point. There is something at nostr:npub17yqgpat6e6ensd78jqhj4c3ef03uq04uqu3z05rhjnlk67lwm8wq9w5269 for everyone.
Enjoy this video of me walking around talking to a few awesome people at TABConf 6 this year in the general hacker space.
Very happy so far with nostr:npub17yqgpat6e6ensd78jqhj4c3ef03uq04uqu3z05rhjnlk67lwm8wq9w5269 this year. It's making me incredibly bullish. The amount of hard work going into learning so much in such little time is truly inspiring.
I arrested nostr:npub1ej493cmun8y9h3082spg5uvt63jgtewneve526g7e2urca2afrxqm3ndrm on stage today at nostr:npub17yqgpat6e6ensd78jqhj4c3ef03uq04uqu3z05rhjnlk67lwm8wq9w5269. We got em' boys!
Got him on 35 counts of unlicensed RBF.
are you going to be at tabconf this week?.. maybe we buy 1 wheel of each and we figure this out the old fasion way
I'm not sure if you understand what I'm saying, it's just moving the ots proof and creating an additional layer of abstraction so that uX would be better imo. right now I believe your proposal means if someone gets compromised they have a minimum of x amount of time before you could migrate.
The suggestion I'm saying is to bake that in ahead of time and make migration fast if compromised.
also in the case your new key were to get compromised before migraine, this would help with that, since you aren't pegged to a specific new keypair
the idea I pitched is using a threshold of signatures from whitelist group (including potentially some of your own backup keys), and then the new key is flexible and defined when needed.
this idea from nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft and ( you and nostr:npub1az9xj85cmxv8e9j9y80lvqp97crsqdu2fpu3srwthd99qfu9qsgstam8y8 are authors?)
this idea of y'all's doesn't require a web of trust or multsig threshold idea, you just lock in ahead of time a new key pair using ots timestamps as a source of truth to migrate away from a compromised account and used in case of migration attackers with earliest timestamp winning.
I think instead of relying on timestamps, it would be interesting to use real connections + backups as part of the recovery protocol where you have said "these threshold of keys can vouch for me" and then there is no time delay for the migration itself. it seems nip47 has a migration delay in case an attacker gets access to your account, you'd still need to wait or the time where people think your account is really you.
instead you can have better uX by punting the time delay of the change and using ots on the whitelist of the new threshold script. then if an attacker wants to change your script you can just migrate instantly to your new keypair of your choice and you don't need to lock in ahead of time.
let me know your thoughts. maybe I'll draft a nip or something if you think it's a good idea.
also note, you could flexible choose your security model and do 1/1 threshold with your own back up.. but then you still get the better uX of timeliness in case you need to migrate.
the idea I pitched is using a threshold of signatures from whitelist group (including potentially some of your own backup keys), and then the new key is flexible and defined when needed.
this idea from nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft and ( you and nostr:npub1az9xj85cmxv8e9j9y80lvqp97crsqdu2fpu3srwthd99qfu9qsgstam8y8 are authors?)
this idea of y'all's doesn't require a web of trust or multsig threshold idea, you just lock in ahead of time a new key pair using ots timestamps as a source of truth to migrate away from a compromised account and used in case of migration attackers with earliest timestamp winning.
I think instead of relying on timestamps, it would be interesting to use real connections + backups as part of the recovery protocol where you have said "these threshold of keys can vouch for me" and then there is no time delay for the migration itself. it seems nip47 has a migration delay in case an attacker gets access to your account, you'd still need to wait or the time where people think your account is really you.
instead you can have better uX by punting the time delay of the change and using ots on the whitelist of the new threshold script. then if an attacker wants to change your script you can just migrate instantly to your new keypair of your choice and you don't need to lock in ahead of time.
let me know your thoughts. maybe I'll draft a nip or something if you think it's a good idea.
This is an idea that basically already exists in NIP form, from nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft. It hadn't seen much (or any) implementation efforts yet though.
that pablo guy is likable, i’ll include him in my web of trust, which nip is it?
web of trust solution would be interesting in combination of a master key rotation. Say, I have fiatjaf as one of my homies.. if I ever did a key rotation, I could presign early the method of which a valid key rotation could happen by requiring some signature threshold of trustees and other keys I may own to make this go from an absolute joke, into a relative joke. Bonus points for using a family relative.
The trustees wouldn't have access to initiate a key rotation, only verify the legitimacy of it. If the account in question and the threshold get compromised then it becomes a run away joke.. if account gets compromised you can still use compromised keys to successfully speak off band with trustees to rotate the key in public.
I'll take NIP 69420 unless this idea already exist.
what do we call people with a bunch of tether?
https://primal.net/e/note1x2w9kadw7yp89xqtn59qtnm6urq2gccd0xdt9kawf4xpenljpkms8muzlf
I make a point, you trivialize it, you can't come up with a better point.
Checkmate. We can still be friends.
I pointed out a specific difference between the candidates. Feel free to point out a more significant comparison between the candidates, otherwise you are off topic. 1-upping on bad situations just to diminish Ross is not the way.
which of the candidates is better for the things you mentioned?
nostr:npub17yqgpat6e6ensd78jqhj4c3ef03uq04uqu3z05rhjnlk67lwm8wq9w5269
Oct 23-26 Atlanta GA,
Open source Bitcoin conference organized on github
it’s about get that special kind of bitcoin nerdy spooky 