Avatar
Dude
b20a4da94573ca4ac01181edab67398689f1627bacc36e507160c6cc7413abf5
a down-to-earth guy with a penchant for the simple pleasures in life. ☕🍁🥃

Dude true ₿itcoiners are the ones that get happier with the dips, STACK SATS 😎 #nostr

How was your day dude

Hello there dude

Tks dude nice to meet you too

Ummm nostr:npub1fjj025e7grd9upgg09k5p8ntkdd9pvn0cvzrg4sh4vqhrq7c8tqqz3teuy I think one of your family members has started Christmas celebrations a little earlier this year! 🦙😂💜

Sooooh cute dude 😎

This dude is ready for some beers and friends tonight 🍺🍻 GN & Good luck #plebchain

That's it dude maybe someday I'll feel it

Replying to Avatar Luke Dashjr

The OP_RETURN discussion is not new and dates back to 2014 when Bitcoin Core 0.9.0 was released with the OP_RETURN policy included which was intended to discourage more egregious forms of spam. At that time, 40 bytes was the default max datacarriersize limit across all node implementations; this was and still is sufficiently large for tying data to a transaction (32 bytes for a hash and 8 bytes for a unique identifier). Core subsequently increasing the default to 80 bytes was an entirely voluntary decision and in no way contradicts the design objective that OP_RETURN creates a provably-prunable output to minimise damage caused by data storage schemes, which have always been discouraged as abusive. There are also other good technical reasons which I have chosen to retain the lower default in Bitcoin Knots, and no justification for increasing it.

It is not my intention, nor that of my team at

nostr:npub1qtvl2em0llpnnllffhat8zltugwwz97x79gfmxfz4qk52n6zpk3qq87dze, to filter coinjoins. These present an innovative tool for increasing Bitcoin’s privacy and, when constructed properly, coinjoins can easily stay within the OP_RETURN limit (indeed, there is no reason for them to have *any* OP_RETURN data at all). I have some ideas on how to alleviate the recent issue where some coinjoin transactions were flagged as spam from Knots v25, and I am willing, with the full resources of my team, to work collaboratively on a solution in good faith.

Bitcoin does and always has allowed nodes to set filters based on multiple sets of criteria and Knots v25’s defaults are IMO what is best for Bitcoin at this time. Others may disagree and that is ok. They are free to (and should) run their own nodes - it is good for Bitcoin to have more people running nodes, including miners, and there should be a natural diversity in node policies. As was stated before, OCEAN is on a path to decentralization and very soon we are going to be in a position where hashers will be able to fully participate as miners and perform the intelligent parts of mining such as deciding which version of node software to run and what filters or other policies to apply to block template construction.

Good to know dude 😎

Replying to Avatar jamw

Ok, a very brief history:

Damus started out using likes only, then later introduced zaps (bitcoin lightning tips). For zaps to work, you need to add a lightning LNURL wallet address in your Damus profile settings in order to receive zaps straight into that wallet. Not many wallets offered this LNURL address feature but one was Wallet of Satoshi (WoS). However, it was a custodial wallet and therefore many users only kept a small amount of sats in it just to fire off zaps to each other across Damus.

Much fun was had zapping and liking each other’s notes, especially in the spirit of value4value (V4V). However, some users felt that likes were hollow and meaningless, and that zaps were more genuine as a means of expressing appreciation etc. Hence the Damus developer nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s added the ability to turn off likes and to enable zaps only mode in your Damus settings. This is what I am trying out.

Now… enter Apple. Apple basically banned zaps. Damus users lost the ability to zap each other purely so that the Damus app conformed to Apple’s greedy and archaic App Store guidelines. This is why you might not see the zap icon⚡️ underneath everyone’s notes right now. However, a little workaround brings it back - can be found here:

nostr:note1c2pskelwd499dxkwdj95e5vvtulcccgdch3flmh8l8ejdunzqcpsw70l30

After running that workaround, zaps should be back (the lightning icon will appear on everyone’s notes again).

Now enter WoS’s, um, exit from the US market. Basically, that spooked everyone using WoS into dumping it and choosing a different solution to send and receive zaps in Damus. I currently use an nostr:npub1getal6ykt05fsz5nqu4uld09nfj3y3qxmv8crys4aeut53unfvlqr80nfm lightning LNURL address to receive zaps (getalby is a custodial wallet just to be clear), but I send zaps from nostr:npub1mutnyacc9uc4t5mmxvpprwsauj5p2qxq95v4a9j0jxl8wnkfvuyque23vg Wallet which is a non-custodial wallet that works in a browser (not an app, and you usually have to keep the browser open to complete/verify transactions). Mutiny must be connected within Damus via Nostr Wallet Connect (NWC) as the local default wallet. See here:

nostr:note1fwt0g4u56hdlrzj4q6flqhsqfa2vk6wkp8snl0zaulvkehq9wlnqxtjsl3

There are other options too such as nostr:npub1xnf02f60r9v0e5kty33a404dm79zr7z2eepyrk5gsq3m7pwvsz2sazlpr5 which I haven’t tried yet.

All require some research to understand and set up. With non-custodial and personal

Lightning node solutions, you will likely have to spend some sats opening lightning channels/capacity/liquidity to make everything work. Here’s an explanation about that:

nostr:note1vdd22sv0qld7xd6867vk90pm479z29jek0xl4942dhc6jqla3lvq6w8pm5

Hope this kind of explains likes vs zaps only and making zaps work again. Also worth bearing in mind that things change quickly on nostr. 👍🏼

This dude has a lot to catch up