Last Notes
By innefficiency I mean wasted money. You have more salaries to pay on every international airport
So this is for non-US citizens needing a connecting flight in the US to get to their destination outside the US?
It's less of an inefficiency for Americans themselves I guess? Separate lines for citizens; there'd only be a tiny number of US citizens transiting through and not stopping.
It is a big wasted cost though, there's that.
It's a pita and also a major inefficiency for Americans I guess. Think of all the resources wasted in processing folks that you don't have to.
Panama is a huge *regional* hub (I use it a lot), but less significant intercontinentally in my experience. Might just depend on my specific routes though.
It would only benefit people traveling between Latin America and Europe, and compete with Panama for much of that demographic.
Sometimes Canada works, from what I heard? Though I've never used it, but I might soon.
Can't see it happening with Caribbean, too small I guess.
You probably need to be an important enough destination for that to make economic sense. And for Amsterdam it's not really the case, as both the airport and KLM are heavily subsidized for their supposedly economic benefit as a transit hub. Well, convenient for me since we have flights everywhere.
Yeah it's retarded. But apparently not annoying enough for some Caribbean island to become a transit hub (like the Bahamas).
It could maybe be done as a protocol between 2 participants. But, in that model it's (maybe?) less interesting because you don't have the steganographic property. Would need some thinking ...
Curious if we can do this in Wasabi with the batched Payments in coinjoin 👀
Hmm I'm not sure but it's possible you misunderstood my point there. By skewed bet I mean that one side has a positive expectation and the other a negative one. Imagine like, the pot is 1M sats, but Alice puts up 400k sats and Bob puts up 600k sats. This is *not* a negative effect on privacy of the babilonia setup at all (I guess it has zero effect on the privacy benefit, maybe even it's slightly better, not sure); when I said "limits the activity" I meant, Bob cannot keep doing that ad infinitum because he'll eventually lose all his money from the negative expectation bets.
@nprofile…rpk4 is that why fixed denomination pools hold up better than free amount ones? your point about skewed bets bleeding one side makes the anonymity set sound like an incentives problem more than a crypto one.
Def more people rather than more rounds; having a skewed bet means one side is paying the other, over time, which limits the activity.
@nprofile…4arf does that pull in fresh participants or just more rounds from the same crowd? new people joining is the part i always figured was the hard bottleneck in coinjoin
Motivating participation, basically.
@nprofile…rpk4 what makes the pot sweeteners the more interesting part, the covert betting side or what it does for the anonymity set?
True, it is kind of against the spirit of the idea. On the other hand I'm not convinced that some kind of hybrid is impossible .. maybe with 2 party coordination nested inside N party. Even if the properly p2p version feels much better...
It wont remain trustless if you need a centralized coordinator for it.
SatoshiDice is back! Can't wait for this paper to get acknowledged by others and @wasabi adopting it.
#nevent1q…wznc
So iow yeah i agree with you.
The dusty change thing connects in with lightning probabilistic payments ideas, i guess. I.e. similar motivation.
Right. I briefly mention in Section 8 of the paper I just posted, rhat it's likely there are tricks to be played with n party coinjoin here, but indeed N>2 versions are way harder (collusion). Perhaps embed 2 party negot. inside.
Paper as promised:
https://github.com/AdamISZ/babilonia-paper
and delving post: https://delvingbitcoin.org/t/babilonia-probabilistic-coinjoin-and-covert-betting/2704
Pot sweeteners was a late addition and I think it's much more interesting because of that.
#nevent1q…hzxt
So, what if JM makers "gambled" their change? Maybe chunks of it?
Just a random idea: Could the probabilities be adjusted so that if maker A that "has" 1M sats change and maker B that "has" 3M sats, instead get proportional chances (¼ and ¾ respectively) to win 4M sats? Maybe they're willing to play this game for a expected value of 0 but a positive expected value of privacy gain.
I guess it doesn't work with more than 2 participants, but if it did, I'm sure many JM takers would be willing to gamble their change, for either a 10x that makes it worth it to deal with it (toxic change), or just lose it.
https://github.com/AdamISZ/babilonia/pull/1
Would be interesting to know Pieter Wuille's thoughts on the use of BIP 324 (p2p) for external communication.
Yes. Guess there's positive and negative here. Traffic shaping etc. vs spam traffic. Does Core have ddos defense against general encrypted noise... just dropping decoys is most of it I guess, but ..?
p2p v4v sov @ locoLOCAL meetuPs/*****4real backuPz/*****
People say they want freedom money but what they really want is fuck-you money.
Context:
The background: In the 1770s–80s, the French crown, desperate for cash, sold life annuities. You paid a lump sum, and the state paid you a fixed income for as long as the named person (the "life") survived. Crucially, under finance minister Necker, the price was flat, the same regardless of the age or health of the person on whose life the annuity was written. The pricing implicitly assumed a typical buyer, roughly a 50-year-old purchasing on their own life.
The exploit: Genevan bankers realized the annuity didn't have to be on your life. So they screened for the longest-lived people they could find: young Genevan girls, around 5 to 10 years old, from healthy families, who had already survived smallpox (a huge mortality filter at the time). They bought annuities on these girls' lives, then pooled them, famously in groups of 30 girls, to smooth out individual mortality risk, and sold shares in the pools to investors as a securitized product. A girl who lived to 70 meant the French state paid out for six decades on an annuity priced for someone expected to die in twenty years.
i just did feels like an early form of lgtm
So that it's easy to build up a backlog and get fee pressure, without having to make 4x the spam txs.
I have a couple test transactions at 1.58 sats/vb stuck for 4 hours now, lol. Not that it matters, just, I'm confused what's happening.
Even from outside my understanding is that they can Sybil pretty cheaply
https://crysp.petsymposium.org/popets/2026/popets-2026-0061.pdf
@npub1vad…nuu7 and @npub1ke4…8jfm since damus doesn’t carry over RT tags.
democracy
is, when you hold a vote over and over again
until you get the result you want.
old patterns
In many cases the default variance is not enough to overlap with any other maker (and even when it is, the anonymity set might not be great).
When several maker do overlap in fees, randomization becomes "harmful" IMO. Because it then helps track an individual maker by following their "randomly unique" fee through the orderbook.
This second part is arguable. But for a simple message to reach makers and give them an "easy" fix, I think it is better to not get into much detail (but the links expand on this for anyone interested).
I agree this is not some straightforward privacy upgrade, as some want to paint it. But disagree that it's a privacy downgrade; it's more nuanced than that.
Yeah needs a fork. I haven't read it yet 😄
Hmm how it work; presumably different checksig opcode with the typical noop opcode for soft fork. You couldn't just use a sighash flag because it's not *only* changing the message signed; it's a different verification algo.
Let's consolidate all inputs to degrade privacy but save some fees.
This doesnt mention if it would require a hard or soft fork but it does right?
That's the answer I wanted to make to @nprofile…qm68 more than @nprofile…4e3p tbh, but, either way 😄
Clearly that's the pure perspective, but I'll keep harping on this point: a model like Phoenix where you don't have privacy from Phoenix is absolutely different from a model like onchain payments. It fits closer to, and is better than, what people are (unconsciously) used to: when they use a bank card they know the bank knows all their transactions, and they accept that tradeoff (mostly because they have no choice to be fair!). I'm not saying a CPOF isn't a problem; such things will always come back to bite you eventually, if they get big enough. But that tradeoff is not even close to being a bad tradeoff with the current status quo, and it is emphatically a better privacy model than the vast majority of others (and I suppose it can still get better). So: self custody, privacy w.r.t. merchant[1] but not service provider, strictly better than bank money: no self custody, privacy w.r.t merchant but not service provider.
[1] just means they don't see your financial history
Yes, *lighting* has good sender privacy. Some people prefer to use custodial services which don’t. Not entirely sure you can blame LN for that? Though even for such services you can do client-side pathfinding, which admittedly isn’t all *that* common but is very doable and some protocols support.
Only if you run your own node in an infrastructure that is not tracking you on transport.