See Peter's reply. Very plausibly new EU regs are involved, though I'm just guessing.
Could not fetch invoice from https://getalby.com/lnurlp/redsun63681/callback: Recipient wallet error. Please contact the recipient.
Yeah sorry can't fix it rn.
Bit too much, prefer not to say more.
No, at least, they never did. Just email.
Yes, I am 90% sure this was the cause - though as you know, we are forced to guess!
about the LN fees: it's a bit more than a nice starter I think! it would make the system an order of magnitude more useful imo (no fee fingerprint on chain) but I'm curious what you have in mind for how it could work. The way I saw it you essentially would need something equivalent to a submarine swap but with privacy, which means adaptors, which means PTLC and taproot and Schnorr (I'm thinking: payment secret is revealed by publishing signature for coinjoin). Even if that line of thinking is coherent, it's not only complex to implement, but relies on things that don't exist. Perhaps it could be done with ECDSA adaptors, which do exist, but .. well I hope it's already obvious why I always saw it as kind of "out there". Do you have something simpler (or just, better) in mind?
Good question! After. I see what you mean, new regs right?
Onchain, indeed.
Ah some nice stuff in the README, like it!
Thoughts on Lightning network integration that you mentioned alongside CJXT, there? A number of different things are possible, I'm curious what you're most interested in.
I wish I could say no company in the past did this ... but at least you didn't use to hear about it so much with retail services like this. Sigh.
JoinMarket NG
Announcing today a full rewrite of all JoinMarket components in modern Python. Focusing on performance, maintainability, and extensibility. While maintaining compatibility with the existing JoinMarket network.
https://github.com/m0wer/joinmarket-ng
Why JoinMarket? Has no central coordinator: most censorship resistant and peer to peer.
Why a rewrite? The reference implementation has served the community well for years, and we're deeply grateful for all that the contributors have done. However, the project is no longer actively developed (181 open issues and 41 open pull requests) and had architectural limitations such as relying on Bitcoin Core's BerkeleyDB wallets (deprecated since v26.0.).
New features:
- Support for light clients using Neutrino
- Rate limiting to prevent logs flooding
- Extensive protocol and implementation documentation
- Realistic E2E tests including reference implementation makers and takers
Future plans:
- Nostr relay integration
- Lightning Network integration (CoinJoinXT) to hide roles and eliminate fee traces
- A lot more ideas
Help wanted:
- Funding: Applied to HRF Bitcoin Dev Fund and soon to OpenSats. Other grant ideas or direct donations welcome.
- Security: Need sponsorship or a volunteer for external security audit.
- Contributors: Peer review, testing, documentation.
Entrypoint for migrating makers: https://github.com/m0wer/joinmarket-ng/tree/master/maker#migrating-from-joinmarket-reference-implementation
The reference JoinMarket served us well for a decade. Let's make sure the protocol thrives for the next one.
Nice to see! Apart from the code itself, did you have ideas about changing things architecturally? Thinking especially about the communication layer.
Well anyway I will read your repo a bit :)
Warning: do NOT use travala.com any more, if you did.
They directly stole my money.
Here is my response to the customer service agent:
(Customer service agent),
> Sorry for the delay, im ahmed from compliance department, for refund or either processing the booking, the verification is a mandatory step, we require the minimum and basic info for that, and you can pass it easily through the following link :
Let's establish the facts: I have been a regular customer of Travala for years, have done probably a hundred or more bookings through your site - mentioning this *not* to claim some status as a customer (which I do not want, and do not have), but to point out that ZERO times on the website or through any of those transactions was it mentioned that you could simply keep my money and provide no service - i.e. STEAL my money - if I did not pass a verification process -handing over extensive and intrusive personal documents - that you never documented anywhere. And indeed for this booking, again, no such advance warning was given.
So you (that is to say Travala, not you personally!) act exactly as a kidnapper: to give me back the money which is mine, you insist that I hand over security sensitive information. Which I will not do. There are an endless stream of documented violent theft events of cryptocurrency holders, so spreading one's personal information is stupid, and any claim you make to "keep my data safe" is ridiculous, given the equally endless stream of reported hacking events. I do not trust your company with my personal information because I don't trust *any* company with it.
I have been doing Bitcoin development work for over a decade, I will make sure that a lot of people in the community know that Travala steals its customers money, directly, with no apology.
Feel free to pass this message to any management, I would appreciate that.
(me)
Right, understood. I think it's enough to just document the choice, though personally I think desktop wallets should always have an encryption option, I do understand that Liana is principally targeting HW signing, right.
Also, on reflection, I don't really agree with the characterization "only defends against a narrow set of attacks". To me, it's a broad and significant set of attacks that are defended against with encryption at rest: the most likely way to get your secrets stolen is for someone to get access to your physical hardware (stolen laptop; evil maid attack), or perhaps getting access to backups of your filesystem. True that someone actually taking control remotely is a big risk too, especially on Windows, but that is such a catastrophic failure mode that nothing matters .. not a good excuse to have zero defences imo - people regularly assume some level of security at least on MacOS and Linux and they should be able to, I think. A desktop is not a phone.
Anyway all arguable I guess. But not giving the option or any warning - I don't see a justification of it, really.
I agree that an unencrypted wallet is a defensible *option* - e.g. Electrum iirc allow you to not set a password (many wallet don't allow it). But I can't see a rational reason to just not offer the option? It's not like the user is warned that their mnemonic is sitting in plaintext on disk.
Question for nostr:nprofile1qqsvetzrdtkpc8kz4eg54hstse8rx7cye5cvcgw9p4e7pt4s6nadw9gpzamhxue69uhky6t5vdhkjmn9wgh8xmmrd9skctcpzdmhxue69uhkummnw3ezu7nzvshxwee0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj72chw44 : why is the mnemonic stored unencrypted on the hard disk?
Yes, all good points, but even technical or somewhat technical people seem to think it should be essentially free. I've never quite understood why that mentality is so prevalent.
On the first part:
Bitcoin itself isn't a product .. but I'll guess you agree with me there and say "but a lightning wallet is, kind of, a product". I can agree at least in general that you have to or want to think like that. But then it's a matter of what's reasonable. There's that old saying "if you're not paying you're the product". I believe it applies here. What is wrong with paying $2 to get access to something that you can permanently use for sovereign, private, immediate payments? In reality that $1-2 is part of the series of fees you're going to pay over time. It's trivial. I honestly can't understand this point of view, at all.
On 'more than visa or square', lots to unpack, but, merchant pays and overall way more is paid. It's not sovereign, it's not private, and it doesn't settle for days. Completely censored. Only cheap because regulators corrupted to literally rob poor people without cards and give it to their customers. Not even available in some places.
If a person prefers 10c instead of 30c fee (or w/e) despite *all* of those things, then why are you 'pitching' to them?
Phoenix can't be mentioned in the same sentence as the others. It's an actual self-custodial lightning wallet that works, seamlessly. "Outrageous fees": as an experiment, I went through my last 5 transactions. Tx1: $2.22 fee: 14 sats 2: $142 fee: 643 sats 3: $141 fee: 641 sats 4: $586 fee: 2644 sats 5: (deposit on chain) $1555 fee: 210 sats. Does that seem outrageous to you? The $586 payment had a high fee of a little over $2, which is like 0.3%; Lightning is like that, it's percentage based. But "high": this is way lower than many other payment methods, and it's instant, sovereign and mainly private.
Overall it's crazy to me that for years now, every time I recommend Phoenix, saying the actual tradeoff is a slightly worse privacy model (but really not bad), I hear people dismiss it as "crazy fees". Just because immediate onboarding (which is a one-time event) to an actually self sovereign wallet costs a couple of bucks doesn't mean "crazy fees"! You don't get everything working perfectly for zero dollars, sheesh.
I don't necessarily disagree but you *can* make an opposite, or at least different, case: subjects based on physics, math and related are a lot more exposed to the possibility of AI-made redundancy, than services jobs (so like your oil and gas example, but think of all the things like medical and educational 'care' expertise). I think maybe the most exposed to danger are in the "middle" between extremes: call it "office work" perhaps.
Yes, very true, but your standard here is "don't use fiat money". It's a good standard! But it's one that literally no country meets.
I do agree it's reasonable to criticize Milei for not taking non-fiat money more seriously, but he actually put the government in surplus and did *not* print money to finance govt activities, despite what people apparently believe (choosing to believe western media is just incredibly stupid here, but apparently if it suits your bias, it's fine!)
Thanks. Not sure if it's Amethyst or I'm just being dumb!
There has to be a really strong motivation not to be in a client-server relationship. Bitcoin and bittorrent both have/had that.
Tax and house purchase are 2 different things right. For the latter, I can only say that I know that in several countries, providing evidence for the source of funds is, nowadays, a requirement. But it doesn't need to be perfect evidence, just, evidence that is plausible enough for e.g. notaries, lawyers. I *think* this is true (nowadays) across basically all "developed" countries, but I'm not sure.
I just tried chatgpt(5) on a tough cryptography coding challenge with a very limited prompt [1] and its response was basically perfect.
We're screwed.
[1] In case you're curious it was: "Implement the inner product argument as described in Bulletproofs 2017 (authored by Benedikt Bunz et al), in Python".
As long as we're talking hundreds, not millions of keys, the more basic ring signature designs should work fine. It sounds like you don't even need linkability, so e.g Abe Ohkubo Suzuki 2002.
For huge keysets see Curve Trees which fit very nicely with bip340 keys.
Yeah i figured you meant that. I just have that kneejerk "not proper cryptography" reaction. The reaction is definitely out of place here š
Interesting thought. But I'd say they are more an efficient *encoding*, not encryption.
I somehow missed this back at the time of the frozen heart vulnerability announcement, but this blog post is *so* good at explaining the interaction of fiat-shamir with ZK proofs (at the very most basic level, e.g. just identification protocols), even using a very nice "tennis analogy" for the Fiat Shamir transform I'd never seen before.
https://blog.trailofbits.com/2021/02/19/serving-up-zero-knowledge-proofs/
#cryptography
Btw "Maybe the verifier is bad at tennis" should read "Maybe the prover is bad at tennis".
An unfortunate typo as that's the essential part of the analogy.
#asknostr
Does anyone know how to set up a start9? I have a friend who's not very tech knowledgeable but was gifted one and wants to run it as a node in their office. I believe it's already assembled (it might even have bitcoin core already installed), but I have no idea how to "bootstrap" it (unfortunately they are also on Windows, but the question stands even if they weren't). How does one connect to it to start with? If it's on the LAN, do you search for the device by IP and then .. what? I saw some general description of steps on the net but it seems to say "access it via embassy.local" but that (unsurprisingly) didn't work immediately. BTC sessions tutorial says "put http://" at the front in the browser and it will work, but I'm having a hard time believing, is that it all it takes, if it's on the LAN? How would that name resolution work without any configuration?
OK, then you can ignore the other part.
For utxos (outputs), vbytes == bytes, because there is no witness discount.
You'd want to look up utxo sizes for each type: p2pk, p2pkh, p2sh, p2wpkh, p2wsh, p2tr. As above i think p2tr is 43? Maybe p2wpkh is 1 byte less? I forget.
Ok i just created a new connection in alby hub and now it works ... kind of annoying i couldn't diagnose it, but, w/e
Seems sensible. Looks like I'm running with "info" level only right now.




