Avatar
waxwing
675b84fe75e216ab947c7438ee519ca7775376ddf05dadfba6278bd012e1d728
Bitcoin, cryptography, Joinmarket etc.

You maybe don't want to hear it, but a 30% tax on mining in the US is great, however disgracefully immoral it is (even on offgrid!?), since we need states to attack centralized mining before it gets too big. It needs to keep moving and fragmenting. Voskuil is good on this.

So you lost all your follows but not all your followers?

That sounds pretty bad yeah, which client though?

They absolutely are not ( they *are* 'immune' from the secondary point i made above, which relates to his suggested solution of repeated rounds; but that is about bitcoin having pruneable state, not really about CJ).

Very clear presentation from Vorick on why partial anonymity sets are problematic in privacy cryptocurrencies:

https://youtu.be/yq_cOVHr8Pg

An interesting nuance is that the suggested solution actually substantially worsens the big flaw with these systems: the unprunable state gets even larger.

Is threading completely borked for anyone else here? Or is it just snort.social?

Another example of why "identities are the problem, not the solution":

"On February 21, a UK court ordered Oasis to retrieve funds stolen during a $322 million attack on another protocol called Wormhole last year, according to a statement Oasis released that day and first reported by Blockworks. The hacker had deposited a portion of the heisted proceeds in Oasis to increase their Ethereum holdings."

A multisig quorum of people who can be criminally charged is not "decentralized" in any way that actually matters. It's actually even worse than "the DAO" in 2016 - at least in that case it was actually *hard* to confiscate the money.

https://www.dlnews.com/articles/defi/wormhole-hack-recovery-sets-a-very-dangerous-precedent-for-defi/

the website is a bit shitty but I strongly recommend reading, there are several other interesting quotes in there.

Hmm I might have to do some more testing but my reports were not only from my own experience, but also that of others. But, not scientific because: since I don't actually want to wait, I was recently only using Electrum with RBF switched off (since they have that toggle in their interface), never on.

Also I am using them only occasionally since as mentioned I don't actually trust them (which to my mind is like a 100x bigger issue than LN support! An ATM which randomly decides to not issue cash is not OK!).

Re: SIMs and so on, good point. Behaviour might change if you are using a foreign number.

Muun is sending it on chain. Chivo ATMs do not support LN (though of course, their mobile app does).

Muun is designed to make the difference between LN and on-chain opaque to the user.

This is a good example of why that's both a good and a bad thing 😄

Afaik it is still the case that if the transaction is not opt in RBF, you get the cash immediately (yes, you read that right!). It was certainly true a few weeks ago, i.e. last I checked.

Most wallets I know (apart from Electrum) opt in though and don't give their user the choice to opt out.

Otherwise I *believe* it waits for only 1 conf, could be wrong on the number.

Yes, on chain only at the moment, though I have heard rumours that might change soon(?).

Be careful about withdrawing large amounts, sadly there have been many stories of the machines not actually supplying the cash after taking BTC (it seems from reports, it's because the machine simply doesn't have the cash! yes, you read that right ...). You then have to go through a lengthy process to get a refund. In the city, look for the ones that have helpers stationed near them and ask if it has cash ("effectivo") before using it, if the amount is on the larger side.

A shame this warning has to be given, ATMs should never be unreliable in this particular way, being a bitcoin ATM is no excuse.

? That kind of domain separation tagging is very widely used in modern cryptography, who said it was invented by taproot/bip340?

The Alexey Pertsev case remains an extremely sobering one to consider, for those of us who've devoted some chunk of our lives to helping people get a bit more privacy and therefore sovereignty in their financial dealings.

This recent article is by a journalist/filmmaker who clearly (to me, anyway) doesn't quite "get it", but his perspective from delving into the details of the case is worth reading:

https://rekt.news/war-on-code/

Submarine swaps are not a new idea, but I've been thinking:

Considering that the biggest problem with on-chain privacy is change addresses (they are the biggest element of clustering analysis), how about:

Service S offers to do a swap any time you make a payment: you give them your change in the payment transaction and they swap it out to you via Lightning.

P payer, S service provider, merchant M.

P gets receiving address for payment from M, and change pubkey C and hash H from S.

S sets up route to pay P using H's preimage.

P pays out the change to address which is HTLC((H,C) or to-self with delay). The usual.

While it won't be applicable in all circumstances (e.g. very large change output), it'd be really cool for a high powered LN+onchain wallet to have this seamlessly built in, minimising onchain tracing and also for rebalancing perhaps.

But, let's be a bit more ambitious 😉

Remember the model of the old greenaddress wallet: 2 of 2 or 2 of 3 between user and wallet service normally, with a fallback key for the user after a long time as a get-out clause, so that it's still trustless. As long as you accept a "wallet service" being involved at all, this is a very cool and high security model to use.

Now, imagine it uses taproot and imagine it also has LN built in. You can get the same as the traditional submarine swap, but more private and powerful: S gives an adaptor on their co-sign of your spend out to (merchant destination address, change address owned by S), such that when you give your sig and they co-sign the 2 of 2, you get the preimage for your LN payment. Same effect but no on-chain HTLC footprint. (note: this *only* works when spending a multisig).

People like this are doing really valuable work helping underprivileged people trying to learn (e.g. here in El Salvador):

https://annas-archive.org

This was formerly known as z-library but got shut down.

however their donate page:

https://annas-archive.org/donate has only a legacy BTC address which apparently is from bitcoin.com (according to the blog, somewhere)🤦‍♂️ .. and no Lightning.

I wonder if we can convince them to run btcpayserver.

Interesting points, thanks.

I agree re: real world anchor, see this that I wrote a few years ago:

https://reyify.com/blog/pow-a-pictorial-essay

The game theory basis of pow for consensus is about as simple as it gets, it's like "minimally game theory dependent" somehow. I don't think it's really correct that bitcoin consensus depends on non-real world identity in the same way as PoS; yes miners mine coins to addresses, but they are purely ephemeral. With stake, it's really not quite like that; those ephemeral identities/accounts are used as *inputs* to consensus.

It's kind of amusing to me: using SIGHASH_SINGLE|SIGHASH_ANYONECANPAY for coinjoin is one of those ideas that crosses everyone's mind at some stage, and then they have that 🤦‍♂️ moment when they realize it enforces in-out utxo mapping, making the coinjoin pointless.

But in this suggestion, where the fiction of in-out satoshi mapping (even though it's entirely false and satoshis don't exist) is the whole *point* of the system - then it kinda makes sense!

https://github.com/casey/ord/issues/802

h/t @niftynei

An interesting essay from Vitalik Buterin a few years ago, that I missed at the time:

https://vitalik.ca/general/2019/04/03/collusion.html

In the first half he nicely elucidates concrete reasons behind an intuition I've always had: that using game theory to build decentralized financial systems always suffers because they have a dependency on identity (and how I'd put it: the problem with that fundamentally, comes from the fact that identity is a fiction, an arbitrary and unanchored construct).

This problem manifests as the impossibility of avoiding collusion in various forms.

Quote:

"But in the version of game theory that allows for the possibility of coalitions working together, called cooperative game theory, there are large classes of games that do not have any stable outcome that a coalition cannot profitably deviate from."

This is the problem - a lot of academic game theory posits isolated actors, however that is *never* the real world (see: sockpuppets or simply, communication!). That's why I've always told people, just like Nick Szabo did to Manfred Karrer back in the days of bitsquare, "don't rely on game theory, replace it with cryptographic verification").

He then correctly identifies, in the middle of the article, the best solution to the collusion problems described: proof of work, because it is identity-less.

The remaining part of the article feels like a reach, looking for increasingly Byzantine (pun intended) partial solutions to what he clearly understands to be an insoluble problem.