No? But actually I have no ideological objection to doing that.
I've heavily reduced how much I interact with banks over the years, they're incredibly dangerous and risky things imo. But it's hard to avoid them 100%.
Interesting. It didn't load on android/brave, but did load on chrome.
See thread, with guidance i got nostr.wine working. Will try the other suggestions later.
Oh, interesting. After they declared that policy I never even tried, with my hsbc account.
So far it's very smooth. Haven't yet tried your other suggestions, but i will.
I've never run stuff like umbrel, but I'm guessing even there, they let you know how to edit your conf file or change a daemon startup flag.
I mean he's still wrong (at least technically!) even for stuff that isn't exposed that way.
Ironically this is actually harder than drug markets. Because the service being sold is in a fixed location, with ownership publically registered.
Yes it worked, thanks!
Up there with the best cryptography paper titles: 'The Dining cryptographers at the disco', 1989.
That tortured analogy in full 😄:
Some younger cryptographers are spending the evening in a disco. They are feeling quite relaxed and decide to tell each other who they think are the most fascinating dancers and the best cryptographers among them. However, they haven't lost all inhibitions yet and decide to say their opinions anonymously, remembering that their three bosses once invented a nice protocol for such purposes in a three-star restaurant [Chau_88].
They have some difficulties: The music is loud, and the darkness only broken by flashlights, hence their only way of communicating is to scream into each other's ears. But the admission to the disco was expensive, so they don't want to leave it for a more quiet conversation. They also fear that some of them, afraid that nobody will mention them, might disrupt the conversation. Luckily, their bosses also mentioned ideas of how disrupters could be excluded from the dinner-table.
Now one cryptographer, who thought he was at least a good dancer and therefore did not disrupt the conversation, is excluded. He is so indignant that he leaves the disco and, in the sudden silence outside, notices that the noise may have been the reason for his humiliation. Therefore, he invents a protocol which allows him to simulate the dinner-table broadcast in the disco, which will protect him from such experiences in the future, even if cryptography is wrong and any number of his colleagues are cheaters.
So take e.g. filtr.nostr.wine : how would i set that up on amethyst, do you know? I see 'add relay' but how would i pay for it?
HSBC has had this policy since 2018, btw.
Any tips on how to choose or find the best paid nostr relays?
This is largely my take. It is a 'purist' take, though.
It's from 2004. Yes it does not apply to bitcoin. Whether this line of reasoning does apply to anti-spam/dos use cases like Tor, LN is more relevant but, anyway, well-trodden ground.
nostr:npub1vadcfln4ugt2h9ruwsuwu5vu5am4xaka7pw6m7axy79aqyhp6u5q9knuu7 merci! Is your pfp a gift wrap algo?
No it's just some diagram i drew for a talk last year. You're welcome :)
Right, I forgot about 1/ and the fact it has a different tradeoff, again. 2/ feels a lot closer to the spirit of unlinkability but you're right it's less practical, that much is clear.
I am not very optimistic about the ZKP idea; I tried to look at it for a few hours a few days ago, and this morning, kind of forgot how unpleasant it is ... it may not be possible with only classic DL-based sigma protocols, because it's not enough to prove something about 'r' but also about 'a' and you can't really malleate the proof you get from the mint without redefining the DLEQ in a way that violates its security.
I could be wrong though; it remains at least interesting to think about.
(Technical note: I use A/G as short hand for DL of A w.r.t. G).
By the way you can surely get more compact and powerful proofs of the type I describe above, by using bilinear pairings. But it is a lot of extra machinery. I think it's doable with just discrete log. (which is also nice because you can stick with secp256k1 and compatibility with btc/ln. you can't do that with pairings).
Having recently looked at this, the construction is really cool but you don't yet have a solution for the proofs that (a) avoids time correlation between requests on the blinded token vs requests on the unblinded token, or (b) avoids requiring receiver to contact mint, right?
In an ideal world you could take a DLEQ (C'->B', A->G) and convert it (without mint's interaction) into a proof for C->Y instead ... the more naive ways of trying to do that involve making the DLEQ's security broken, I don't think it works. But in principle I think some (rather involved) ZKP, just using the discrete log primitives, *might* be possible. Essentially the sender claiming "Here is C, x, (and Y) and here is a ZKP that: I know a value r such that (C+rA)/(Y + rG) == A/G" without revealing r (all else is known/given to receiver).
Again, I'm not sure but, if it is indeed possible then I think it ticks all the boxes you're looking for.
Cool. That first line is hard to understand from a non-user.
So it gives you latest (in this case I believe 0.4.8.6) without manual intervention? That's great if so.
On Ubuntu focal it was stuck at 0.4.7.2.
I love using Linux (yes I am a normie and I use Ubuntu most of the time because it's easier) ... but a simple thing like "I want the latest Tor update which the developers put **strongly recommend updating** on is way too much hassle.
Look at this nonsense I have to do:
https://ubuntuhandbook.org/index.php/2021/01/install-tor-tor-browser-ubuntu-20-10-20-04/
Got on a sidetrack this morning and found this interesting little paper from 2004: "why proof of work doesn't work".
https://www.cl.cam.ac.uk/~rnc1/proofwork.pdf
(from a quick read of the conclusion, their argument doesn't appear that strong, but the basic idea is well known - attackers are prepared to spend a ton more to specialize, than ordinary users are, etc. etc.)
This paper might seem quaint to Bitcoiners who are convinced that PoW *does* work, but bear in mind: they are thinking of the spam problem specifically, and so their analysis could still be very relevant today, e.g. in the case of using PoW for systems like Tor or Lightning.
Interesting tidbit, the first author Ben Laurie is the guy, iirc, that invented "Lucre" an ecash system that is an early precursor of privacypass and cashu.
The truth is Dillinger was shown Bitcoin right at the start on the cryptography mailing list, and gave a long list of reasons (all wrong) why it didn't work. To be fair he did not 100% dismiss it as some did, but his tone was just as patronising. I'm then presuming he was shown an early draft of the source code (this fits in with Satoshi's behaviour at the time, and his own report). But then you hear absolutely nothing positive about Bitcoin from Dillinger for 8 years. (I think he said it was bad in various places .. don't recall .. he also called it a disaster about a year *after* this quote).
In 2017 at the height of the bubble he retconned this into "I was one of the insiders" in some long blog post (iirc) of which this quote is a part. IMO it just stinks of bullshit. No surprise all the scammers like CSW tried to use his "first hand account" to bolster their own pack of lies.
Sorry for being a wet blanket.
Meanwhile, in Canada, school libraries are removing all books published before 2008
https://www.cbc.ca/news/canada/toronto/peel-school-board-library-book-weeding-1.6964332
Canada seems to have something special about it, so many Canadians here, even some that aren't bitcoiners ...
(though the UK is very similar in this regard).
The local electricity company (CAESS) stopped accepting bill payments via Bitrefill. Que desastre!
I think I just found a Bitcoin equivalent of a "first world problem" , lol.
Oh, no Alice wouldn't explicitly reveal even the combination of k values.
Back to the single signer case: s = k + ex. You never reveal k, only R (the "commitment" to k, as discussed before). You publish R and s, so revealing k would expose the key (x). It's the fact that there are *two* secret unknowns (k and x) on the RHS that provides the security against leakage. If I give you the number 41 and say it's the sum of two numbers (mod 43), I'm not telling you anything (it could be any sum of 2 numbers in range).
Same here; Alice will give Bob s_alice, the partial signature of Alice, which is: k_{A1} + bk_{A2} + hashes * x_alice. But she would never separately hand over just k_{A1} + bk_{A2} ; that's her secret nonce.
About notation like k_{A1} I'm just doing the same as in LaTeX, it means everything in the curly braces is the subscript of the thing before _ .
I don't agree, if you are just talking about how objectionable those two posts are.
I don't think the reason community moderation, or something similar, is needed, is because people post objectionable things using foul language.
I think the only valid reason for censorship is to stop spam which destroys people's ability to communicate.
Usenet used to be full of crap like this. It was still useful. Its failure was only the overwhelming *amount* of crap.
2 of 3 multisig does not remove counterparty risk.