108 sats \ 0 replies \ @conduition OP 25 Apr \ parent \ on: PSA: coins held in samourai may be doxxed (but are still secure for now) bitcoin
Whether you want to sweep all your UTXOs at once or one at a time is up to you, and depends on your specific situation and how you manage your coins.
I don't believe the samourai devs would be stupid enough to write their wallet to upload xpubs to their servers. Most wallets just upload single addresses, and have a hard-coded lookahead for derived addresses (e.g 50) on which they detect activity.
So while your whole xpub is not at risk here, your next 25/50/100 derived receive/change addresses could be, and practically speaking that is pretty sketch. If you launched Samourai recently, I would just sweep money and ditch the whole seed, then clean any coins you had on samourai.
As I explained in many other guides, when you receive sats, is better to use a decoy, that will not reveal the real destination of the funds.
In my case, this isn't a problem for my threat model. I would rather have full control and per-payment privacy. I don't need to hide the destination node from people who want to zap me. But that's just me
(I listed them here).
Thanks! I wish I had found some of those earlier :P
A very clever use of connector logic.
I'm curious how you envision routed payments fitting into this paradigm. What you're describing in the Hedgehog repo is analagous to key-sending in Lightning: Paying your channel partner directly with no expectation of receiving anything in return. To make this useful, you'd need to be able to route payments over multiple hops like Lightning using HTLCs or PTLCs, or perhaps even something wilder like Blitz payments. Consideration of network-driven scaling seems to be missing.
Thus, instead of sending a revocation secret to revoke a prior state, the sender merely sends a signature authorizing their counterparty to consume the revocable connector and the rest of the funds so long as both inputs are consumed in a transaction that creates the latest state.
It's not 100% clear what you mean by 'creates the latest state'. This seems incredibly crucial to the protocol, as otherwise revealing the revocation secret is completely unsafe for the sender. Here's what i'm assuming you mean.
Say I'm Bob, at the beginning of this section (state 2). I want to send 1000 sats to Alice. Alongside my two signatures needed for Alice to be able to unilaterally close the channel with her 9000 sat balance (state 3), i would need to provide a signature which lets her fairly distribute the channel balances according to State 3 if I (bob) try to broadcast the first TX from State 2. That way, if I broadcast state 2, Alice can come online and follow up by 'correcting' me with the latest state, without actually punishing me, similar to how Eltoo Channels work.
However this seems unscaleable. By doing this, i have only revoked state 2 if Alice can reply by broadcasting state 3. To maintain the revocation of state 2, Alice would need me to sign similar 'correction' transactions every time i send her money. This quickly becomes impractical because every time I send Alice money, I will need to include such a correction TX signature for every previous state I might be able to broadcast.
The obvious fix for that is to do this:
For even better safety, the old revocation script – (counterparty && revocation_secret) – should still be kept as a third tapleaf in the new revocation taptree, so that a sender can “conditionally” revoke their most recent state using (counterparty && sender) but “absolutely” revoke the state before that using the old revocation script.
This way, Bob can reveal the revocation secret for state 2 once Alice acknowledges receipt and shares her signatures for State 3. Bob no longer needs to sign new correction transactions for State 2 because Alice can instead just sweep the whole channel balance if Bob broadcasts State 2.
But in the readme you pitch that technique as an optional safety improvement, not an essential scaling requirement. Without it, I would have to sign
n
transactions if there are n
previous states I could have broadcast - not practical for high-frequency channels.I feel like this is referencing that ridiculous article posted by bitcoin magazine a couple days ago. Talk about fearmongering. There's paranoia, and then there's.. whatever that article is.
The sound of ignorance is the prevailing noise on both sides of the pro/anti bitcoin fence. Unfortunately, hot-heads tend to be louder than the cool ones who would provide better feedback.
I for one have been very fortunate to be able to build on the work of the core devs over my career. The steadfast reliability of core is an incredibly fertile soil for other projects to sprout from. It's thankless work most of the time, so let me say: Thank you, and that goes for any other core devs who are reading this too.
In the event i or other stackers want to donate BTC to support the work of the core devs, what is the best way to do so in a responsible and transparent way?
Once you get some intuition for how curve point operations work in relation to scalars, it's very friendly to work with compared to RSA! The big advantage is everything is much faster so it's easy to play around with simple libraries to get a grip on the basics. I'm actually dreading have to relearn everything when post-quantum crypto becomes the norm.
If you wanna try out some code to see the inner workings of ECC, one of the best is actually the BIP340 (schnorr signatures) reference implementation. Although it's neither secure nor performant, and shouldn't be used in production, the reference code there is the simplest possible correct secp256k1 implementation i've ever seen. Most of it is captured in just two functions.
i also have some more higher-level ECC reading sources here for the next time you feel curious =)
While Big Tech sites like Spotify claim they’re “democratizing” culture, they instead demand artists engage in double the labor to make a fraction of what they would have made under the old model.
At least for me, "democratizing" something means turning it into a popularity contest, and I think that's exactly what platforms like Spotify are doing.
Democratic leaders don't want to market themselves - They have to. They're in a popularity contest. If they win, the prize is a fat pay cheque and the power to run the government - ostensibly the actual job. But they can't do the actual job until they get hired by the voters.
Similarly, a musician's job is supposedly to produce music, but until they get hired (i.e. become "famous"), it's a popularity contest against their peers, just like the politician.
This is how self-employment fundamentally differs from salaried employment. Your employer is your listeners, viewers, customers, clients, etc, collectively. Until you establish a base of reliable customers, the popularity contest will never end.
So yes, you have to market yourself, because who else will?
Whether this is a "Good Thing" for the species or not, well... that's still TBD.
They just want to stop reselling and corner the market. But that doesn't sound as good as preventing ticket fraud.
This, 1000%. I'd bet dollars to doughnuts that Ticketmaster used ticket-fraud as justification for SafeTix even internally. It's the line they would feed to all their PMs and devs to motivate them. But behind closed doors, the suits knew exactly what they were doing.
p2p bets arent really practical because they need a channel with their counterparty, to route them we need PTLCs which is a far ways away
Agreed on that point. I wasted spent wayyy too much time thinking about how to make P2P DLCs practical. I think SuredBits has something cooking with Barrier Escrows but it's still a lot of work to get right.
you need a central market maker that is extremely capital intensive
With the approach linked above, it's not capital intensive at all. The market maker has to front the full value of the DLC (on-chain), but they're immediately paid back (off-chain) when the participants buy in via lightning. Fees can be charged to account for no-shows.
So the next evolution will be to use Fedimint for DLCs to enable smaller, and even more private bets.
@benthecarman Why wait for fedimint? You can enable off-chain DLCs using lightning today with an untrusted market maker (which could be mutiny).