pull down to refresh
10 sats \ 1 reply \ @fanis 12 Jun \ on: CVE-2025-27586 Full Disclosure FBRE Attacks against a LN node bitcoin
The timeline is off: says disclosure on June 16th, and yet we're only the 12th.
Thanks for you kind words @DarthCoin :blush:
In that case I don't think they're anchor outputs. The 330 sats for anchors comes from the fact that it's the dust limit for this kind of output (i.e. the smallest standard amount). Here, they use the same amount to ensure standardness of their transaction, but from the look of it I'd wager they're encoding arbitrary data into the addresses (thus making the output unspendable).
42 sats \ 2 replies \ @fanis 29 Apr \ parent \ on: KYC / NON-KYC Coin Control Question bitcoin_beginners
Generally speaking adding a hop between a KYC exchange and your main wallet isn't going to do much privacy-wise. If you do
exchange ---> temporary wallet ---> main wallet, then any surveillance company with knowledge that the funds sent to the temporary wallet belong to you will be able to infer that those sent to the main wallet also do, especially if the transaction from the temporary wallet to the main wallet is trivial to interpret1.Additionally coin control, however sophisticated, will never alleviate the fact that the KYC exchange holds a record of how much corn you bought. For instance, if your worry re. KYC is expropriation a la 6102, then the State would still know that you own at least the amount reported by KYC exchanges, and could come take it.
I think a common practice is to keep KYC and non-KYC stacks hermetically separated. It has the added benefit that KYC coins might be useful in the future, e.g. for any transaction that requires proof of origin (such as buying a house).
Footnotes
-
For example this recent transaction is probably a self-transfer because it transforms exactly one input into exactly one output. The odds of a transaction between two parties not involving any change output are thin, since it'd require the sending party to possess a UTXO that is very close to the amount requested by the receiving party. ↩
I think in most cases the best way to go around this is to use separate accounts (e.g. different derivation paths). Sparrow lets you do that pretty easily.
If open your current wallet and head to the "Settings" tab, you'll probably see under the Keystores section that your derivation path is something like
m/84'/0'/0' (could also be something else depending on your setup). Using the same seed (eg the same hardware wallet, if you're using one) you should be able to create a new wallet, and specify a different derivation path (eg m/84'/0'/1'). You can give it a clear name (like "KYC wallet") for future reference.You now have 2 different accounts, backed by the same seed, but from which you cannot accidentally spend in the same transaction.
Hey @DarthCoin, thanks for sharing this!
Today will be an introduction to Lnbits core concepts, and we'll play a bit with the public v1 instance.
Interesting, thanks for pointing it out! It's a clever way to take the fee, although it has the drawback of not being atomic. But then if a merchant blocks the payment of the fee to Flash, they can terminate this merchant's account, and they can no longer use the service.
IIRC LNBits circumvented this by intercepting invoices before handing them to LND, and processing "to-self" invoices separately as database-only transfers. But it would indeed be nice if LND had it baked in, instead of everybody that has a use case for it reimplementing the feature.
Okay, 3 things:
- that's probably one of the best written FAQ I've ever read. Answers every question in an absolutely unequivocal fashion, and directly addresses questions that users are the most likely to ask first
- congrats for taking this path. It'll have its challenges, but Cowboy Credits might be the glue that make it work for everyone in the end, and I'm really interested in watching how it unfurls
- Nov. 5th is a very, very good choice of date for such a release.
Cowboy hats off!
I guess it depends on how much actual mint-to-mint transactions there are. If there are a lot, then audits are hidden in the crowd. Else, what you describe is indeed possible.
And yes, Bolt12's receiver privacy probably fixes this 🫡
By "blind", I mean that a mint doesn't know which user an ecash token "belongs" to. If they weren't blind, mints could always honor withdrawal requests from identified auditors, thus appearing trustworthy while rugging other users.
In other words, it works because a mint can either rug everyone, or rug no one. They can not rug one user in particular.
Also, some of the documentary's points on scalability were quite weird. Like when it stated something along the lines of "now, you can make everyday payments on Bitcoin, but only through companies that take a cut on each payment" ; and then hinting that it may have been Blockstream's secret master plan all along.
That's not how Lightning works ; and I didn't expect such Bilderberg-ish conspiracy theories to be dropped like that in an HBO documentary.
TL;DR:
- Kia didn't properly protect its endpoint for registering new dealers, allowing anyone to register as a car dealer
- with dealer privilege, you can access a car's owner personal details from Kia's API, using only their vehicle's VIN, which can be derived from their license plate
- you can even revoke their ownership of the vehicle, and put yourself as owner instead. Being owner means you can unlock, lock, or even start the car from the Kia app. You basically just stole the car, and there was no notification alerting the actual owner.
No go read the full thing, it's pretty well-written.
No worries, you always discover a myriad of bugs when you first open the thing to more people 😅Good that issues stem from too many users, that's a cool problem to have!