Avatar
waxwing
675b84fe75e216ab947c7438ee519ca7775376ddf05dadfba6278bd012e1d728
Bitcoin, cryptography, Joinmarket etc.
Replying to Avatar Max

In the early days of ecash a common narrative was that it provides "theoretically perfect anonymity", but there's more nuance to this.

It's correct that when the client presents an unblinded signed message, the mint cannot link this to any specific blinded cyphertext that it signed previously.

However, there is still three pieces of critical metadata that the client does reveal:

1. The number of inputs and outputs of the ecash transaction. Transactions with many inputs reveal that the same user got paid many times in the past. Transactions with many outputs reveal that one user is making many payments.

2. The value of each input and output. The mint uses a different key for each denomination value of the tokens. Thus a token worth 5 units is easily differentiated from a token worth 10 units. The anonymity set of a token depends on the number of tokens generated, so if a user is the only one with that specific denomination he has no privacy.

3. The IP address that connects to the mint to send the transaction api request. If the same IP address makes multiple payments, it's likely the same user, and his geolocation is also revealed.

Problems 1 and 2 can be mitigated on client side, but this adds substantial complexity in utxo management and transaction structure. If these mitigation are not specified and different clients have slightly different solutions, this opens up additional client fingerprinting attacks.

WabiSabi is designed to solve problems 1 and 2 on a protocol level. A WabiSabi transaction is required to have exactly two inputs and two outputs, and homomorphic value commitments hide the amounts of each input and output. The tradeoff is that the mint has to issue 0 value credentials, a user needs to make more transactions to prepare his desired amounts, and the proof size and creation time is larger.

Problem 3 is addressed by a client side networking anonymity layer. A VPN at least hides the actual users IP address, but if only one client uses this VPN to talk to this mint, it's still one IP per user. Tor is incredibly useful here, as it allows the creation of anonymous onion routes through the network with different exit IP addresses. A client can get a new IP for each api request! This does however increase bandwidth and latency cost.

We should assume "everyone knows what the mint knows", and so we need to be hardcore about privacy protections best baked into the protocol. If the protocol doesn't ensure the security of the user, client devs have to do an exponentially larger amount of research and development to fix the issues client side.

Interesting point about zcash that most people missed is that it retained problem 1. (Also 3. but everyone knew that!)

This page wouldn't have been out of place in a 1980s cyberpunk novel by Gibson/Stephenson/Sterling:

https://en.wikipedia.org/wiki/Anonymous_Sudan

Possibly, though of course it could be many txs not one.

But the exact nature and motivation of an attack is hard to predict. Another motivation might be to try to kill bitcoin by making it unreliable. That attack is quite hard to reason about.

There's no guarantee that the price will move in the same direction as the hash rate.

But you're of course right that the incentive to create an attack like a double spend (you pay for something with btc, then fork the blockchain using hashpower, you change history so that your spend is 'cancelled', then you have the thing and still have the btc) increases as the purchasing power of btc increases.

Yeah. Your point about spending limits is a very good one, maybe an interesting area for research. Not being able to spend specific chunks of your balance is a limitation (though the model of discrete denominations is also problematic, in other ways!). Didn't people try to address that with cosigning for onchain? Could we do that for LN? Have an agent that cosigns your channel updates with ecdsa 2pc or musig when we finally get taproot ln (umm nested musig blah blah).

The scenario that seems really difficult is: customer arrives in new town/region and needs Internet access at a 'tienda' (or bodega to use the US vernacular!).

I think nontech answers like fd0's : nostr:nevent1qqsfkm5vamze9mnqdpnuf6ykehegl8mc85d8p9dwe9yu48ls62d2cwgpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygrxsyng4nj8fr2p5n8uc8nyqphmjddmcdvhs2eajcglvn23ce6jmypsgqqqqqqsz5vzal

.. are more likely to be what is chosen; though i think physical cards representing LN funds is a nice idea too, just that spendinglimit problem to fix ... If we want people to pay with tokens to bootstrap, the unfortunate reality is they'll tend to use the tokens of the strongest mafia in their jurisdiction (that's what makes bitcoin a little bit magical, it isn't a token ultimately redeemable with some authority).

More hashrate means it's more difficult for someone to rewrite the history of bitcoin transactions that are agreed on globally. It defends against attacks on the system's consistency. This is the central idea behind bitcoin.

Got a lot of good answers here, thanks.

My (I'm sure not even a tiny bit novel) summary of playing with current gen LLM tools is that they're likely very useful in three main situations:

One is when your task is more synthetic/creative: writing a letter, generating ad copy or creating a game, story etc etc where you need some flow of interesting human concepts (written well where that matters). I haven't tried any image stuff only text but i guess it'll be very useful there too now, since it's getting better. To be clear, I'm only guessing about this use case. Maybe creative people will find it useless, but seems unlikely.

The other is where you're doing something and aren't yet expert: an example might be learning a foreign language at intermediate level; it'll be a great practice tool. Or very similarly, learning a computer language or framework but you're not fully comfortable in it yet. The problem is that when you are expert in a technical thing, especially a less common one, then the kinds of questions you have are too difficult, and it will confidently give you answers that are *very* likely to be flat out wrong.

The third is the "donkey work" case: imagine having an intern who just graduated and remembers *all* the basics and theory but doesn't know much about the gotchas of real life in your field. You can give them tasks that would take time but are not easy to screw up. For example, writing unit tests for code (it dies seem like they are *particularly* good at software, unsurprisingly). You might still need to review the work to double check it but you saved a bunch of your time. I guess this is going to be the *main* use case until/unless AI has another quantum leap.

nostr:nevent1qqsghq5lypcd2xlfzlxur6xzv944r5rafapm6xd0k93zulygn9pg50cpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygr8twz0ua0zz64eglr58rh9r898wafhdh0stkklhf3830gp9cwh9qpsgqqqqqqs6kleh9

Def leaning that way, though it's obviously more work.

Nice option, thanks! Best aspect is LN pay as you go.

I'm curious, did you compare this with lmstudio.ai ?

Looks like a great option, thanks!

Replying to Avatar remyers

I assume you're aware of https://chat.bitcoinsearch.xyz/

It's not general purpose but a great dev resource.

Interesting search tool, thanks!

The first point is that when I said "technically you don't" I meant that even if it seems crazy, there is no rule that says you *couldn't* implement systems where say you had a LN channel from earlier setup and you logged in with credentials that convert to a signing key.

Consider credit cards; the earliest security model which still exists, is magstripe and it's 100% insecure in the sense that you must trust the vendor's terminal not to skim your private data. The most recent version of this tech signs from a chip as well as using a PIN. While we have nothing like this for LN usage, I'd have to ask: is there a reason it couldn't work? I mentioned bolt cards, that's a step in that direction.

One reason that the credit card (old, insecure) model is more uncomfortable here is because LN is a self-custodial and privacy focused tech, i.e. more cash and not account/custodial; that's more autonomy but harder for resource-limited users, right.

The nicer thing about ecash based systems is the interop with LN so that you can have money passed between mints but that could end up quite complex/fragile (and arguably worse trust model than single mint!), while the more easily imagined case: merchant and customer use the same mint, means that you're back to the limitations that you'd have if some channel or channel topology had to be pre-existent beforehand (possible of course, but more limited than we'd like to imagine). With both a trust requirement, *and* "topology"/"coordination" requirement, I believe an awful lot of very clever setups could be made to work. Though I suspect an ecash mint would beat them all in terms of privacy model, that's where it shines. Doubt that the targeted users would prioritize that, though.

Second is right for sure. My point was that ecash is already custodial. You realistically have to have an account with someone, with LN technically you don't, and there are variations on the basic idea. People have come up with several somewhat offline, somewhat trustless LN payment methods, right. Like bolt cards etc.

Oh nice. Will def take a look.

Interesting. How does one use it?