@m0wer
JoinMarket NG
Relays (5)
- wss://nos.lol/ – read & write
- wss://nostr.bitcoiner.social/ – read & write
- wss://relay.damus.io/ – read & write
- wss://relay.snort.social/ – read & write
- wss://nostr.sgn.space/ – read & write
Recent Notes
Age Verification: legislation map
https://proton.me/age-verification
https://stacker.news/items/1527063
https://proton.me/age-verification
https://stacker.news/items/1527063
🧐
https://nostr.media/10c12aced4d3e3a55fa8a56ecb50f321a18621fc06fe6171eb7f4aaac3ae6d9b.jpg
Satoshi also mentioned that address reuse should be avoided (in the white paper in fact), and that's no argument for changing the consensus rules to reject address reuse transactions. Not saying either one is a good idea, just pointing out the difference between "shouldn't" and "can't".
Also, Satoshi is not a god. Definitely an awesome person or group of people. But not something to follow blindly.
Also, Satoshi is not a god. Definitely an awesome person or group of people. But not something to follow blindly.
Ambitious! My first concern is that this fragments liquidity even further. 5 mix depths is already restrictive, having (long lived) LN channels is somewhat of a counter-incentive.
The problem of over...
Yeah... It does.
I do hope that a more active ecosystem also attracts more liquidity.
The channels don't need to be long lived. Makers can use them as inputs for CJs (cooperative close directly into a CJ). So it's not really locked liquidity as long as the peer is online. They can also close them, ideally after the balance has shifted.
The problem I see with the automatic sweep and many other similar ideas, is that they lack the incentive to do so. They would be paying fees for something that's good for future takers privacy, but only costs them money. And takers don't know the "quality" of makers UTXOs. Apart from that, they would leak a lot of info by consolidating so many UTXOs at once...
The incentives are a bit tricky. I thought that the taker "forcing" them to get change as channel opens, or at least having takers prefer makers that do support that, is a nice "trick". Then they can do whatever they want with it. Ideally, being swap providers, lnproxy providers, and being able to just use that shared UTXO as their CJ inputs, is enough of a motivation to keep it (instead of paying fees out of their own pocket to close the channel as soon as they get it).
I do hope that a more active ecosystem also attracts more liquidity.
The channels don't need to be long lived. Makers can use them as inputs for CJs (cooperative close directly into a CJ). So it's not really locked liquidity as long as the peer is online. They can also close them, ideally after the balance has shifted.
The problem I see with the automatic sweep and many other similar ideas, is that they lack the incentive to do so. They would be paying fees for something that's good for future takers privacy, but only costs them money. And takers don't know the "quality" of makers UTXOs. Apart from that, they would leak a lot of info by consolidating so many UTXOs at once...
The incentives are a bit tricky. I thought that the taker "forcing" them to get change as channel opens, or at least having takers prefer makers that do support that, is a nice "trick". Then they can do whatever they want with it. Ideally, being swap providers, lnproxy providers, and being able to just use that shared UTXO as their CJ inputs, is enough of a motivation to keep it (instead of paying fees out of their own pocket to close the channel as soon as they get it).
1
nostr:nprofile1qy88wumn8ghj7mn0wvhxcmmv9uq36amnwvaz7tmwdaehgu3wvf5hgcm0d9hx2u3wwdhkx6tpdshsqgr5t8fn8tmxqehsvm8cw7twdyxm82t073f5l8klf64hfhe0ypegnvzfpjkv does giving makers a reason to spend through LN ...
Nice catch 😜
Takers might need to "fake" a swap whenever they want to spend. But if they do so, the onchain fingerprint is "perfect". A maker could give an equal amount P2TR otuput to a swap claim address (onchain could look like a 1 input 2 outputs tx). The "maker" has change from the swap, but the other "branch" of that swap are now someone else's. That might do whatever with it. How could you tell if it was a real swap or not?
But there are other ways. Takers can also get channel opens as change outputs. Which could then be spent in part (splice, swap out, rebalance, ...) or fully (ideally cooperatively as well). And of course, makers can also eventually spend!
Probably by the time we get there we can come up with simpler ideas though.
The challenge definitely is complexity.
Takers might need to "fake" a swap whenever they want to spend. But if they do so, the onchain fingerprint is "perfect". A maker could give an equal amount P2TR otuput to a swap claim address (onchain could look like a 1 input 2 outputs tx). The "maker" has change from the swap, but the other "branch" of that swap are now someone else's. That might do whatever with it. How could you tell if it was a real swap or not?
But there are other ways. Takers can also get channel opens as change outputs. Which could then be spent in part (splice, swap out, rebalance, ...) or fully (ideally cooperatively as well). And of course, makers can also eventually spend!
Probably by the time we get there we can come up with simpler ideas though.
The challenge definitely is complexity.
1
Decentralized lnproxy (provider discovery through Nostr) working on signet :-)
PR: https://github.com/lnproxy/lnproxy-relay/pull/31
Try it at: https://m0wer.github.io/lnproxy-webui2/?network=signet
BTW this is a nice web LN wallet for testing on signet: https://ln.signet.coinbin.org/
PR: https://github.com/lnproxy/lnproxy-relay/pull/31
Try it at: https://m0wer.github.io/lnproxy-webui2/?network=signet
BTW this is a nice web LN wallet for testing on signet: https://ln.signet.coinbin.org/
ambitious. change as taproot channels would blind subset sum. i'd worry about liquidity—small channels usually rot. how are you handling scid privacy when makers actually need to route?
The idea for now is that they have their own public channels for that. They can use the private ones they know of if they want to route for LN->onchain swaps. Or they could pick a neighbor to wrap an LN invoice of theirs for a onchain->LN swap, the swap requester then pays to the other nodes pubkey and the emitter receives it through the private channel they share, shifting the balance from the original CJ change.
There are many things to keep in mind though, but let's see how it unfolds.
There are many things to keep in mind though, but let's see how it unfolds.
❤️1
Let me present you what could be the future of JoinMarket and hopefully a great tool for Bitcoin privacy and fungibility.
First of all, there is the motivation. JM makers have an onchain fingerprint, that although it's hard to follow, limits the privacy achieved by the takers. The full details are at https://gist.github.com/m0wer/a228c625fcb6a27c32e298ec903dfc44
But to save you some time, here the main problems described there are: unique enough maker fees, co-spending of inputs, makers never spending, ... Which in the worst case scenario, would mean that a pure onchain observer could potentially cluster some makers across mixdepths and reduce the anonymity set by one of CoinJoins where they participate.
So what can we do? Well, we can use this chance to bring JM to the next level. And create such a transaction graph "mess" that becomes a chain analyst nightmare :-)
Let me explain. We can't ever get fully rid of the links between UTXOs onchain, or at least not without a way more complex multi taker model that leads to Knapsack "dense" transactions. But we can strive for something, that is that no single party ever has all the information.
The idea is the following. JM makers could become Lightning Network swap providers. Like Boltz, like SwapMarket, like electrum swapserver. Using Taproot swaps and advertising through Nostr. LN swap users get a simple and trustless client side web UI, makers get "fresh" UTXOs from onchain->LN swaps and the opportunity to "spend" CJ outputs for LN->onchain swaps. Oh, and another source of fees. LN swap users get cheaper swaps from the increased competition.
But this is not enough. We need to break the subset sum analysis onchain. We want to stop maker clustering from the root. Here is the next idea, JM CJ participants (makers and taker) could get their change as an LN channel open. Or two, with random other peers and the change amount split randomly between both channels. So a maker that has a 10 M sats input in a 5 M sats CJ no longer gets just a clear ~5M sats change, instead, two LN channel opens where the balance is hidden. Maybe 2M sats in one and 3M sats in the other. But an external observer wouldn't know. Not even which channel is whose!
You could say, well, but an active attacker could probe those channels balance. Maybe, but not really. Those channels would be private simple taproot (HTLC based, not PTLC yet unfortunately), so not advertised to the network. And, BTW, onchain they look like any other P2TR output BTW. Advertised only when needed with a SCID alias that does not reveal the onchain UTXO. But hey, who knows, maybe some peer node that gets the SCID could try to probe it. Fear not! There's another ingredient coming to the mix.
lnproxy is a great service to hide the destination node of an LN BOLT11 invoice by having a relay/proxy node wrap it. The payment hash is the same, only the recipient can settle the payment. But whoever sees the wrapped invoice sees the relay/proxy pubkey instead of the destination one.
Why not decentralize lnproxy through Nostr and then makers can be lnproxy providers as well? Just to add a little bit more noise to their LN activity and help move the balances around. So that if these change as channels ever close (cooperatively) the onchain fingerprint those not help understand what happened in the opening CJ. Or that UTXO can still be used as CJ inputs if signed cooperatively. Or, of course, as LN channels for swaps of lnproxy. Some kind of noisy spin of CoinjoinXT.
What we need for this and what we're currently working on at jm-ng:
- A JM taproot only pit.
- Decentralized lnproxy.
- Decentralized LN swap providers.
- Protocol wiring for the change as channel CJ coordination.
- People to actually use this and not be overwhelmed by the complexity.
But if we manage to make this work, we will have awesome onchain and LN privacy. And a way for service providers to earn money anonymously by providing privacy to others. So it's definitely worth a try :-)
First of all, there is the motivation. JM makers have an onchain fingerprint, that although it's hard to follow, limits the privacy achieved by the takers. The full details are at https://gist.github.com/m0wer/a228c625fcb6a27c32e298ec903dfc44
But to save you some time, here the main problems described there are: unique enough maker fees, co-spending of inputs, makers never spending, ... Which in the worst case scenario, would mean that a pure onchain observer could potentially cluster some makers across mixdepths and reduce the anonymity set by one of CoinJoins where they participate.
So what can we do? Well, we can use this chance to bring JM to the next level. And create such a transaction graph "mess" that becomes a chain analyst nightmare :-)
Let me explain. We can't ever get fully rid of the links between UTXOs onchain, or at least not without a way more complex multi taker model that leads to Knapsack "dense" transactions. But we can strive for something, that is that no single party ever has all the information.
The idea is the following. JM makers could become Lightning Network swap providers. Like Boltz, like SwapMarket, like electrum swapserver. Using Taproot swaps and advertising through Nostr. LN swap users get a simple and trustless client side web UI, makers get "fresh" UTXOs from onchain->LN swaps and the opportunity to "spend" CJ outputs for LN->onchain swaps. Oh, and another source of fees. LN swap users get cheaper swaps from the increased competition.
But this is not enough. We need to break the subset sum analysis onchain. We want to stop maker clustering from the root. Here is the next idea, JM CJ participants (makers and taker) could get their change as an LN channel open. Or two, with random other peers and the change amount split randomly between both channels. So a maker that has a 10 M sats input in a 5 M sats CJ no longer gets just a clear ~5M sats change, instead, two LN channel opens where the balance is hidden. Maybe 2M sats in one and 3M sats in the other. But an external observer wouldn't know. Not even which channel is whose!
You could say, well, but an active attacker could probe those channels balance. Maybe, but not really. Those channels would be private simple taproot (HTLC based, not PTLC yet unfortunately), so not advertised to the network. And, BTW, onchain they look like any other P2TR output BTW. Advertised only when needed with a SCID alias that does not reveal the onchain UTXO. But hey, who knows, maybe some peer node that gets the SCID could try to probe it. Fear not! There's another ingredient coming to the mix.
lnproxy is a great service to hide the destination node of an LN BOLT11 invoice by having a relay/proxy node wrap it. The payment hash is the same, only the recipient can settle the payment. But whoever sees the wrapped invoice sees the relay/proxy pubkey instead of the destination one.
Why not decentralize lnproxy through Nostr and then makers can be lnproxy providers as well? Just to add a little bit more noise to their LN activity and help move the balances around. So that if these change as channels ever close (cooperatively) the onchain fingerprint those not help understand what happened in the opening CJ. Or that UTXO can still be used as CJ inputs if signed cooperatively. Or, of course, as LN channels for swaps of lnproxy. Some kind of noisy spin of CoinjoinXT.
What we need for this and what we're currently working on at jm-ng:
- A JM taproot only pit.
- Decentralized lnproxy.
- Decentralized LN swap providers.
- Protocol wiring for the change as channel CJ coordination.
- People to actually use this and not be overwhelmed by the complexity.
But if we manage to make this work, we will have awesome onchain and LN privacy. And a way for service providers to earn money anonymously by providing privacy to others. So it's definitely worth a try :-)
67❤️9❤️2👀2♥️1🤙1
Introducing Muse Spark 1.1
https://ai.meta.com/blog/introducing-muse-spark-meta-model-api/
Sad that it's not open weights :(
https://stacker.news/items/1525344
https://ai.meta.com/blog/introducing-muse-spark-meta-model-api/
Sad that it's not open weights :(
https://stacker.news/items/1525344
BTW release notes now include a section with the config.toml template diff.
No need to apply everything everytime, just whatever new settings or default changes you're interested in (if you had set them, otherwise the new defaults automatically apply).
No need to apply everything everytime, just whatever new settings or default changes you're interested in (if you had set them, otherwise the new defaults automatically apply).