We have recently disabled the ability to zap nostr:npub1xnf02f60r9v0e5kty33a404dm79zr7z2eepyrk5gsq3m7pwvsz2sazlpr5 wallet users from Mutiny. You may still pay their invoices or LN addresses normally but a big problem we were seeing was force closed channels due to stuck payments to Zeus due to their work arounds with locked payments. Which harm both the user experience and other lightning nodes on the network.
Since nostr users are mostly unaware if they're zapping Zeus users or not, we are taking this step proactively to protect users from having a 10 sat zap costing them serious on chain channel closing (and reopening) fees.
The approach we are working on for solving lightning addresses on mobile wallets is a fedimint hybrid approach where the sats end up at a federation if you are offline but get swept to your self custodial channel when you come online. Payments will settle instantly with the federation and it won't lock up unnecessary HTLCs on the network.
Ideally we get the ability to do offline receives normally on LN but that future is looking really grim with LND's continued priorities on shitcoins instead of features, and offline receives depends on a network wide upgrade.
We petition Zeus to move to a more responsible node implementation like LDK unless their plan is to add shitcoins or break LN further.
their taproot code is taken from decred's codebase, for one thing. it doesn't have full implementation of BIP-340, despite this, it fails on the last 4 tests in the suite, and i fixed it and pointed them to it in an issue but i got some dodge from roasbeef about why they didn't properly implement the tests. (for irregular length message signing).
as a Go dev trying to work with bitcoin and lightning their BTCD and LND codebases are a shitstorm of stupid. the damn btcd has dependencies to prior versions of itself, just for starters. the configuration system on both btcd and lnd doesn't work. i've tried to put some PRs up to get a few things fixed but they never merge them. even tried to chase an actual issue they had filed, that issue is still there, the patch is still dangling, and would take about two hours to merge in.
hooray for beta testing. zeus is doing a new thing with offline receiving no surprise there's glitches occurring.
not sure why mutiny needs to make this a big public deal when it only affects its users though.
it can also build towards paid work ultimately.
i'm not sure what to say, first feed yourself. i can also advise: stick to something you already have experience in if you are on the bones of your arse. and third point: bitcoin meetups can be a good place to find contacts that could lead you to work, a lot of bitcoiners are entrepreneurs and finding good workers is hard.
there is bounties for fairly simple tasks and some projects offer rewards for bugs found if they turn out to be big ones with monetary impact.
many of the devs in this space are just web devs and they are relative beginners, and have usually been fairly strictly directed when they were working on projects.
this is why if you aren't keeping it in the cooler you should mix it with yoghurt seed culture. it stays good for a week ~22''C if sealed well.
i'd do it with a big boat but not a small one. thing is you gotta grow a load of plants or gather them stuff to nibble on, that's a hassle too, especially the weight of the soil.
funny cos i'm on an island now and it's a subject that comes up. i'm not so keen on it because i want to have a herd of dairy goats, i'm not that fond of fish as a staple food and it'd be quite an epic boat to keep goats on it.
sailing boats is the new lambo?
this is why i don't install any social apps on it. 🤝🏻
all shitcoins are directly or indirectly spawned from fiat. fiat is the category, shitcoin is the example.
no coins in the house???
the next big area of development of #bitcoin will be around the mempool.
currently it uses a naive gossip protocol to distribute transactions, but it would be possible to add new mechanisms to this while not affecting those that don't adopt it, but adding solutions for problems introduced by segwit and RBF.
it also could potentially lead to solutions for LN and other L2/L3 systems that are badly affected by the simple gossip protocol used by the mempool.
LN showed that two party transaction update games can become relatively secure. there should be ways to make multiparty transaction update schemes secure as well, which would enable some parts of LNs benefits directly in the bitcoin network instead of at a second layer.
mmm like the one in Interstellar, or the backstory of Myst games. The hindus called it "the akashic records" and the abrahamic religions "the book of life".
essentially segwit made it possible to stuff large inscriptions on chain where before segwit there was major limits on this.
you may recall an incident where a massive transaction blocked up btcd and stalled many LND/BTCD based lightning nodes. this was because the segwit spec does not place a limit on witness size, it can literally fill the full 4mb of a block.
it was my opinion at the time of that incident, that it was just the beginning of a flood of garbage scams exploiting this vulnerability, and i've been thoroughly proven correct in the meantime.
i believe it would be possible to essentially soft fork segwit back off but the miners won't stop running segwit support, because full blocks means more fees for them. it only takes a few full nodes supporting it for the transactions to get to the miners and end up in the blocks.
unfortunately, the pandora's box is open.
taproot is allowing us to potentially write wallet/transaction schemes now that are massively compressed compared to prior protocols, anything involving multiparty can now be greatly shrank because only one signature is needed, 64 bytes, whereas before there had to be a signature for each address involved and this also was bad for opsec.
taproot schnorr signatures allow lightning transactions to be smaller also, and to be indistinguishable from normal transactions and for coinjoin and payjoins to also go under the radar. we are just waiting for this to be supported by applications basically, and for nodes to support it.
it's my opinion that someone should go through the old bitcoin core versions and backport taproot onto them, because it doesn't introduce vulnerabilities, unlike segwit, and encourage old node runners to patch to support taproot.
it's always a good day when someone understands that the engineering is far from settled and needs a lot more eyes on the task.
#segwit is the spawn of satan.
we didn't need it for lightning, lightning already had all the tools required.
it enabled the current spam scamming ordinals and bitmap theory bullshit.
it was underspecified, it gave no limitations on the size of transaction witnesses.
schnorr signatures and a sane nonce-based signature protocol would have fixed malleability better than segwit. literally could have just been an extra 8 bytes with a fixed 64 byte signature.
it would have obsoleted multisig transactions completely
it would make lightning and other layer 2/3 anchoring transactions indistinguishable from others
it would have made coinjoin and payjoin protocols more private and easy to implement.
all of this is of course wishful thinking. we have got taproot now, which can enable most of that, but we have got a huge problem of miner-beneficial spammy transactions that are diminishing the utility of on chain transactions by inflating fees, and increasing the data size requirement of the chain.
when the bull run comes, it's not gonna matter so much, but the halving is still 3-4 months away and at that point the miner driven pumping of scams to fill blocks will start to slow down until next time.
and maybe someone will come up with ways to defeat the scammy shit.
i personally have my eyes on working on changes in the soft consensus of the mempool, changes that will be compelling and lead to a shift in focus away from the chain and more into the live transaction stream.
i didn't want the changes. i was against segwit fwiw. as a developer, i hate how complicated the whole thing has got.
the biggest problem with it is that segwit doesn't set a limit on how much witness a transaction can use. in theory, one can jam one transaction into one block, if one has the several bitcoin fee required to displace all competing tx's.
the problem doesn't really hurt miners, so we can't find a solution that benefits them and prevents the spam. users could do things to reduce it, but at best they would only slow the ingress of these garbage transactions to the nodes feeding miners block templates.
the pandora's box is already open now, and lightning is still in beta and shit is just gonna be messy for a while.
money touches everyone's life, so it's an unfortunate consequence that it also is of far greater interest to psychopaths wanting to indulge themselves in ill gotten wealth for the various services it provides, that the fight is extra intense.
also, this is why i don't follow calle, his marinating in statist riddled academia has stewed his mind.
