Memes

Meme Monday - Best Bitcoin Meme Gets 5,000 CCs

![](https://m.stacker.news/94566)
https://stacker.news/items/995306/r/kpa

bitcoin

![](https://m.stacker.news/94565)

I had created the first draft for a [bitcoin wiki page](https://en.bitcoin.it/wiki/Covenants_support) to gather evaluations from developers on different soft fork proposals and link was shared on [mailing list](https://groups.google.com/g/bitcoindev/c/fdxkE1Al4TI/m/CeEuls2IAQAJ). 32 developers have shared their opinion until now.

![](https://m.stacker.news/94564)

### OP\_CHECKCONTRACTVERIFY

No developers have objections with `OP_CCV` but its reviewed by very less developers. There could be multiple reasons for it, however this is the first thing that I noticed in the table.

![](https://m.stacker.news/94562)

### OP\_PAIRCOMMIT

5 developers have objections with this opcode and its also less reviewed. This opcode is a combination of `OP_CAT`, `OP_SHA256` and part of LNHANCE proposal.

![](https://m.stacker.news/94560)

### OP\_CHECKSIGFROMSTACK

It has the highest support in the table from all developers. Nobody wants to activate it alone but its a part of some proposals with other opcodes.

![](https://m.stacker.news/94559)

### OP\_INTERNALKEY

This seems to be a simple opcode that could save 32 bytes and part of `LNHANCE` proposal. However, 4 developers have some objections with it. Luke Dashjr had shared the reasons in a telegram group and on twitter. Rearden had responded to the concerns and its possible that re-evaluations would change this column.

![](https://m.stacker.news/94558)

### OP\_CAT

This seems to be a controversial opcode in the community hence you see multiple developers using ‘deficient’ option for it. Some developers have also marked ‘no’ and do not want `OP_CAT` because it enables too many things.

![](https://m.stacker.news/94556)

### SIGHASH\_ANYPREVOUT

This is another proposal with interesting evaluations in the table because it was perceived to have enough support in the community. With more rationales added in the table, it could become clear why developers do not prefer it anymore.

![](https://m.stacker.news/94555)

### OP\_VAULT, OP\_TXHASH

These 2 opcodes have mixed opinions and we will need rationale added in the last column by all developers to understand the reasons for this evaluation.

![](https://m.stacker.news/94554)

### OP\_CHECKTEMPLATEVERIFY

3 developers have objections with this opcode and 2 of them belong to [Zerosync](https://zerosync.org/). The bias is easy to understand if you go through the tweets of Robin Linus. None of them have added a rationale yet so we can only assume the reasons for it.

![](https://m.stacker.news/94552)

### Conclusion

This table has made it easier to analyze the opinion of different bitcoin developers on proposed soft forks. There is always room for improvement, however the primary goal to reach some technical consensus could be achieved with it and followed by further discussion on mailing list.  
  
[https://groups.google.com/g/bitcoindev/c/QOnpM4Ixmms/m/8m1\_l5RSDAAJ](https://groups.google.com/g/bitcoindev/c/QOnpM4Ixmms/m/8m1_l5RSDAAJ)

Hawk-eye - Observations from the covenants support wiki

![](https://m.stacker.news/94549)

BIP 119 OP\_CHECKTEMPLATEVERIFY allows users to restrict outputs by committing to nVersion, nLockTime, scriptSig hash, input count, sequences hash, output count, outputs hash and input index. In this post, we will focus on committing to multiple inputs because it could help in improving payjoin.

Example from the BIP:

        Path A: <+24 hours> OP_CHECKSEQUENCEVERIFY OP_CHECKTEMPLATEVERIFY <Pay Alice 1 Bitcoin (1 input) nLockTime for +24 hours>
        Path B: OP_CHECKTEMPLATEVERIFY <Pay Bob 2 Bitcoin (2 inputs)>

In this case, there are 24 hours for the output to, with the addition of a second input, pay Bob 2 BTC. If 24 hours lapses, then Alice may redeem her 1 BTC from the contract. Both input UTXOs may have the exact same Path B, or only one.

Let’s make some changes in this example so that it could work as payjoin:

        Path A: <+1 hour> OP_CHECKSEQUENCEVERIFY OP_CHECKTEMPLATEVERIFY <Pay Alice 0.01 Bitcoin (change) and Pay Bob 0.02 Bitcoin (1 input) nLockTime for +1 hour>
        Path B: OP_CHECKTEMPLATEVERIFY <Pay Bob 0.03 Bitcoin and Pay Alice 0.01 Bitcoin (change) (2 inputs)>

This will result in 3 transactions:

1.  Funding tx (sender)
    
2.  Funding tx (recipient)
    
3.  Spending tx
    

We can reduce it to 2 transactions by using P2A as described by stutxo in this repository: [https://github.com/stutxo/simple\_ctv](https://github.com/stutxo/simple_ctv) It would improve privacy for this protocol because P2A can be can spent by anyone along with their inputs.

Differences compared to normal payjoin:

1.  Less interaction
    
2.  Recipient broadcasts the transaction (path B)
    

Most importantly this protocol fixes the [UTXO probing attack](https://uncensoredtech.substack.com/p/utxo-probing-attack-using-payjoin).

Payjoin with CHECKTEMPLATEVERIFY

![](https://m.stacker.news/94408)

> Sybil attacks are an inherent threat to privacy in mixing schemes because a transaction between n apparent participants n − 1 of which are controlled by an attacker will fully link the victim’s coins on both sides of the coinjoin while giving the impression that the victim’s privacy has been improved.

![](https://m.stacker.news/94409)

  
Wabisabi
-------------

Section 7.2.2 in [Wabisabi paper](https://eprint.iacr.org/2021/206.pdf) describes sybil attacks although the implementation does not provide resistance to these attacks. The attacker would need enough inputs in a coinjoin transactions and pay fees.

The [coordinator](https://kruw.io/) with the highest liquidity currently does not charge a coordinator fee.

Since WabiSabi is a coinjoin implementation based on centralized coordinator, a user must also trust the coordinator not to link inputs and outputs.

  
Joinmarket
---------------

Joinmarket uses [fidelity bonds](https://joinmarket.sgn.space/fidelitybonds) for sybil resistance. This requires market makers to lock some bitcoin hence it increases the [cost of sybil attack](https://joinmarket.sgn.space/sybilresistance).

[Fidelity bonds](https://en.bitcoin.it/wiki/Fidelity_bonds) were proposed as a [solution](https://gist.github.com/chris-belcher/18ea0e6acdb885a2bfbdee43dcd6b5af) to sybil attacks by [Chris Belcher](https://x.com/chris_belcher_/status/1496577077751001093).

![](https://m.stacker.news/94410)

Joinstr
---------

Joinstr uses [aut-ct](https://github.com/AdamISZ/aut-ct) as the primary mechanism for sybil resistance, however fidelity bonds can also be used with aut-ct. There is an initiator who creates the pool and adds sybil requirements to join the pool. Everyone (maker and takers) needs to provide the proof for a successful coinjoin.

There is enough freedom for initiators to add different conditions for aut-ct. Example: Prove ownership of a UTXO with certain amount, age etc. This isn’t the UTXO which will be used for coinjoin. It isn’t possible in joinmarket with the protocol used right now. Another thing that makes it easier to provide liquidity while still resisting sybil attacks is that nobody needs to lock bitcoin.

Members need to pay a fee before joining a pool that uses paid nostr relay in joinstr. This isn’t the case with other coinjoin implementations.

Example:  
\- Alice creates a pool with `JM=True` because she already has a fidelity bond and using it for Joinmarket  
\- Bob and Carol join the pool  
\- Everyone shares aut-ct proof that proves they own a P2TR UTXO worth 0.1-0.2 BTC that is unspent until last block and aged more than 2016 blocks

I have shared other details in an earlier post:

[Market makers in joinstr](https://uncensoredtech.substack.com/p/market-makers-in-joinstr)

5 October 2024
![Market makers in joinstr](https://m.stacker.news/94411)
Joinmarket is based on maker-taker model and market makers offer liquidity for coinjoin. They get free coinjoin and earn fees from offers. Fidelity bonds are used for sybil resistance and makers lock some bitcoin while creating offers.

[Read full story](https://uncensoredtech.substack.com/p/market-makers-in-joinstr)

Conclusion
------------

Wabisabi is vulnerable to sybil attacks. Sybil resistance in joinmarket is good enough as it increases the cost of the attack. However, joinstr provides the best sybil resistance among all the coinjoin implementations.

Sybil resistance in coinjoin implementations - Joinmarket, Joinstr and Wabisabi

bitdevs

![](https://m.stacker.news/93641)

There has been a lot of debate recently about OP\_RETURN limits, and one of the restrictions limits the number of OP\_RETURN outputs that can be used in a transaction. Using Libre Relay, it's already possible to relay transactions that use more than one OP\_RETURN output.

### Can we use multiple OP\_RETURN in coinjoin transactions?

Coinjoin can be used by ordinals users to hunt sats. It doesn’t require the use of OP\_RETURN and there is an [open issue](https://github.com/ordinals/ord/issues/4051) to implement it in ord.  
  
Runes users can benefit from OP\_RETURN and coinjoin in 2 ways although it will require some changes in the [protocol](https://docs.ordinals.com/runes.html):

1.  Mint multiple runes in the same transaction. If multiple runes are minted in a bitcoin transaction it would look like this: ![](https://m.stacker.news/93642)

It will need some coordination between users however, improves privacy in minting and cost in some cases.

2.  Coinjoin can also be done while transferring mint. This is an example runes transfer transaction: [05e9c6b6c1b23ee6676d030090d64f7334f6f20c3d09f9878817a617d8233a14](https://mempool.space/tx/05e9c6b6c1b23ee6676d030090d64f7334f6f20c3d09f9878817a617d8233a14)
    

There is another degen protocol for minting tokens called OP-20 which uses OP\_RETURN however it does not allow more than one mint in a transaction.

Example transaction: [05e9c6b6c1b23ee6676d030090d64f7334f6f20c3d09f9878817a617d8233a14](https://mempool.space/tx/05e9c6b6c1b23ee6676d030090d64f7334f6f20c3d09f9878817a617d8233a14)

###   
What other use cases could benefit from multiple OP\_RETURN and coinjoin?

[OpenTimestamps](https://opentimestamps.org/) can also use multiple OP\_RETURN outputs in a single transaction. Batching would reduce the cost and coinjoin could improve privacy.

Here is an example OpenTimestamps transaction: [3371fa8d145d917c1f8f5f302f00ba9381570e927f02160032331c1f74d19e36](https://mempool.space/tx/3371fa8d145d917c1f8f5f302f00ba9381570e927f02160032331c1f74d19e36?mode=details)  

### Conclusion

Every protocol that uses OP\_RETURN would benefit from multiple OP\_RETURN outputs in the same transaction. They could either use batching or coinjoin depending on the priority of users.

Use of OP_RETURN in coinjoin transactions

lightning

How to censor users in cashu?

AGORA



![](https://m.stacker.news/63921)
# Take back your data with Tuta's encrypted email, calendar and contacts.
- - -

Dear Privacy Fan,

Tuta is thrilled to offer an exclusive Black Friday and Cyber Monday deal!

You can now upgrade to our Legend Plan with **62% off** for the first year and enjoy great privacy, more storage, and more email addresses for just €36/year (instead of €96) and enable everyone to use the web privately! 😍

What You’ll Get with the Legend Plan

✅ 500 GB secure storage (perfect for our upcoming import feature)
✅ 30 additional email addresses
✅ Support for up to 10 custom domains
✅ Priority customer support
✅ Extended search feature
✅ Offline mode for mailbox & calendar
✅ Smart filtering for incoming emails (inbox rules)
✅ Calendar Sharing
✅ Event invites
✅ Autoresponder
✅ Family option (ability to add family members to your plan)
✅ Upcoming: Unlimited labels

**[Get the deal](https://tuta.com/pricing)** from November 15 to December 4, 2024.

[Check out the announcement on the blog to learn more.](https://tuta.com/blog/black-weeks-at-tuta)

**🎉 Already on Tuta and ready to become a Legend? 🎉 **
[Upgrade to Legend Plan now under Settings > Plan!](https://app.tuta.com/settings/subscription)


Turn ON Privacy on your Email with Tuta.io's Black Friday Deal and Save 62%

food_and_drinks

https://www.youtube.com/watch?v=cFO9hXq4Vdo

# Summary

A personal story of coming to terms with a carnivorous diet. He talks about being born with a congenital birth defect in the lumbar and sacral vertebrae, which, he claims, causes chronic pain and discomfort throughout his life. David shared in his past that sugar addiction, poor eating habits, and self-medication with clonazepam. He narrates how he came to the carnivore diet from vegetarianism and veganism, following research by Dr. Anthony Chaffee, Dr. Ken Berry, and Professor Bart K. He focuses on the benefits he has gotten: reduced inflammation, improved sleep, and higher energy. He talks of the lack of human nutritional need for carbohydrates and the toxicity of sugar and plant-based food. It also includes a touch of morality in the consumption of animals versus plants and how gradual dietary changes are usually important.

# Highlights

**Introduction and Personal Background**
David introduces himself and the topic of the carnivore diet he has been on. He says he wants to reach out and help people who have been suffering from health conditions. David shares his personal history, which includes a congenital birth defect in the lumbar and sacral vertebrae that caused discomfort and pain for all his life. Then he shared how previously he was addicted to sugar and had poor eating habits.

**Carnivore Diet Journey**
Progression to a carnivore diet through vegetarianism and veganism. He mentions that one day, he passed out and got a concussion, which brought him into researching different diets. He references researchers such as Dr. Anthony Chaffee, Dr. Ken Berry, and Professor Bart K as influencing him to go on a carnivore diet.

**Carnivore Diet Benefits**

All the benefits he derived from a carnivore diet, which includes drastic decrease in chronic inflammation, increase in quality of sleep, high amount of energy, and feeling of youth rejuvenated. He also mentions enhanced lucid dreaming experiences as a bonus for which he was not expecting. 

**Nutritional Science and Physiology**

The science behind the carnivore diet, and makes an argument for the physiological design of humans as an apex predator and an obligate carnivore. He discusses the toxicity of sugar and carbohydrates to the human body, and dispels the notion that fruits and vegetables are needed for optimal health. David also covers the moral arguments put out about eating plant-based diets.

**Practical Aspects and Mistakes**

Some practical aspects of a carnivorous diet: how often in the day he eats, usually one to two meals, and his carbohydrate intake, which is 50-100 grams per week. He shared mistakes he made transitioning to such a diet, including changing the diet too fast and paying too little attention to electrolyte balance. David stresses that one should have a transition in stages and not unbalance themselves with one thing or another in their diet.

Coming Out As Carnivore 🥩 Why I've Embraced the "Carnivore Diet."

tech

Organic Maps and OpenStreetMaps

siggy47

Organics maps is great! That's what I'm using

Joinstr KMP: Kotlin implementation of joinstr for Android, iOS and web app

Rsync25

nostr

joinstr

TheWildHustle

has been there for a bit https://stacker.news/items/268773/r/kpa one year now

Introducing: JoinStr 🦃 A Decentralized CoinJoin Implementation using NOSTR

you right! I invite you to try out the electrum plugin and join if is something you are willing to try

Joinstr get added to the Coinjoins.org website

Definitely, having other wallets implementing it will help increase the user base. For now the only one is [Electrum with a dedicated plugin](https://gitlab.com/1440000bytes/joinstr/-/tree/main/plugin). On the roadmap mobile and webApp are WIP. Stay tuned!

### `What is Joinstr`
Joinstr is a coinjoin protocol with a decentralized coordinator model on Nostr relays. Participants can use multiple relays in the same coinjoin round.

Learn more about its Benefits and Trade Offs on [coinjoins.org](https://www.coinjoins.org/wallets/joinstr) or read more on [GH](https://gitlab.com/1440000bytes/joinstr/), [X](https://twitter.com/1440000bytes) and our [Website](https://joinstr.xyz/).

![joinstr.png](https://m.stacker.news/23822)



Finalizing latest details for [Joinstr electrum plugin](https://gitlab.com/1440000bytes/joinstr/-/tree/main/plugin?ref_type=heads). join the conversation [here on telegram](https://t.me/Joinstr) if you are interested to test it with real sats.



Joinstr electrum plugin ready, will you be interested to test it with real sats?

devs

Daily ~Devs Hangout

Hey Devs and Hackers! It's time for your daily rendezvous at the Daily Devs Hangout. 🛠️🔗

Pull up your ergonomic chair in our virtual realm and share a slice of your day. From triumphs over complex code, head-scratching bugs that make you wonder why you started coding in the first place - we're all here for it. 🐞💻

Cracked a tough algorithm? Encountered a Bitcoin brain-teaser? Or perhaps you've got a piece of sage advice that could save a fellow dev's sanity? This is the place to spill.


`#nostr` `#get-help` `#activity` `#milestone` `#legends-of-lightning`

![](https://imagedelivery.net/wyrwp3c-j0gDDUWgnE7lig/2a6f2ac4-6047-4028-a187-8ce9a6552f00/public)

Introduction
------------

In the ever-evolving world of bitcoin, privacy and security are a paramount standard. CoinJoin, a method for enhancing anonymity in Bitcoin transactions, largely depends on how it will be implemented, as it offers a unique approach. In this blog post, we'll delve into the best practices for using encrypted channels in each CoinJoin round within JoinStr, ensuring that your transactions are not just anonymous but also secure.

Understanding CoinJoin and JoinStr
----------------------------------

Before diving into the specifics, it's crucial to understand what CoinJoin is and how JoinStr fits into the picture. CoinJoin is a mechanism that combines multiple Bitcoin payments from several users into a single transaction, making it more difficult for outsiders to determine who paid whom. JoinStr indeed, is a coinjoin implemetation written in Python that utilizes `nostr` relays for the transaction coordination, adding an extra layer of security. To achieve this implementation, the implementation of private channels is mandatory and we are currentluy working on it to make it real.

We recently submitted a [0.0135 BTC bounty](https://github.com/coinkite/bountsr.org.pub/pull/46/files) to incentivize [the community](https://t.me/Joinstr) to participate and submit proposals, hopefully it will be published soon on [Bounstr.org](https://bountsr.org/joinstr-channels/) To explain how to implement private channels into Joinstr, we also need to understand a few key concepts:

1.  **CoinJoin Mechanism**: is a method for combining multiple Bitcoin payments from multiple spenders into a single transaction to increase privacy. It obscures the link between the input and output of a transaction, making it more difficult to trace individual transactions. Learn more about [Coinjoin](https://en.bitcoin.it/wiki/CoinJoin) since its [inception](https://bitcointalk.org/index.php?topic=279249.0)!
    
2.  **Joinstr's Implementation**: uses nostr relays for coordination. [Nostr](https://fiatjaf.com/nostr.html) (Notes and Other Stuff Transmitted by Relays) is a decentralized and censorship-resistant protocol. It's used in Joinstr to coordinate transactions between different parties. There's also plenty of info about the protocol on [Nostr.how](https://Nostr.how), check it out!
    
3.  **Private Channels Concept**: in the context of bitcoin on-chain, it refers to a method of conducting transactions or communications in a private, secure manner, often using encryption or other encryption techniques. You can learn more about it on [here](https://en.bitcoin.it/wiki/Privacy) and [here](https://thebitcoinmanual.com/articles/private-channel-lightning-network/) :)
    

The Role of Encrypted Channels
------------------------------

Encrypted channels in JoinStr play a vital role. They ensure that the details of the transaction, and the participants involved, remain confidential. This encryption is vital in protecting against potential threats, such as man-in-the-middle attacks or blockchain analysis techniques that could compromise privacy. This will enable Joinstr to solve its Denial of Service, an issue initially discussed on the bitcoin-dev [mailing list](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-August/020876.html). After drafting a [NIP](https://github.com/nostr-protocol/nips/blob/e24316e16b8f4ac50d0fec7cbdfe76fa936dfe8c/33.md) to try solve this problem we realized that using encrypted channels would be a muuuch better approach. There are some exisiting NIPs for encrypted channels that could be useful: NIP 38, NIP 48 and NIP 112, although some changes would be required to implement them on joinstr.

Best Practices for Using Encrypted Channels in JoinStr
------------------------------------------------------

1\. _Choose Strong Encryption_: Always opt for the strongest encryption settings available in JoinStr. This might mean taking a bit more time to set up your transaction, but the added security it's definitely worth for your anonymity.

2\. _Verify Your Counterparties_: While JoinStr does a lot to secure transactions, it's still important to verify whom you're transacting with (when possible). This doesn't mean you need to know their identity, but ensure they are legitimate participants in the CoinJoin.

3\. _Use Fresh Addresses_: Each time you participate in a CoinJoin round, use a new address. This practice prevents linking your transactions together, enhancing privacy.

4\. _Stay Updated_: Keep your JoinStr software up to date. Our comunity continuously work on improving security features and fixing vulnerabilities. Using the latest version ensures you have the best protection available.

5\. _Monitor CoinJoin Rounds_: Pay attention to the details of each CoinJoin round. If something seems off, such as a participant repeatedly trying to join with the same inputs, it might be a red flag.

6\. _Avoid Reusing Channels_: Just as with addresses, try not to reuse encrypted channels. New channels for each round minimize the risk of pattern recognition.

7\. _Be Cautious with Amounts_: When participating in CoinJoin, consider the amounts you're mixing. Large, unique amounts can sometimes be traced back. Aim for common denominations where possible.

8\. _Understand the Limits_: Remember that while CoinJoin and encrypted channels add privacy, they are not foolproof. Understanding their limitations helps in making informed decisions about your transactions.

### Ideal integration

![](https://imagedelivery.net/wyrwp3c-j0gDDUWgnE7lig/eab58f7d-9b0c-40af-f6a5-f025f6bf6100/public)

One user will create an encrypted channel, post output address in the channel and share info to join the channel as a public event. Other users will join the channel and register their outputs. Once the encrypted channel is full based on capacity defined by the first user, nobody should be able to join the channel.

Input registration would also use the same channel, followed by the coinjoin finalization and confirmation in the blockchain.

To integrate private channels into Joinstr, you would need to follow these general steps:

1.  **Understand Nostr Protocol**: Since Joinstr uses nostr for coordination, a deep understanding of how nostr works is crucial. This includes how it handles data transmission and ensures privacy and security using the NIPs: [38](https://github.com/nostr-protocol/nips/blob/master/38.md), [48](https://github.com/nostr-protocol/nips/blob/master/48.md) and [112](https://github.com/nostr-protocol/nips/pull/580).
    
2.  **Design the Private Channel**: Determine how the private channel will function within the Joinstr framework. This involves deciding on the encryption methods, how the channel will be established, and how it will interact with the existing `nostr` relay system.
    
3.  **Implement Encryption**: Implement robust encryption methods for the private channel. This is essential to ensure that the details of the transactions coordinated through Joinstr are kept confidential.
    
4.  **Modify Joinstr's Code**: Integrate the private channel functionality into Joinstr's existing Python codebase. This will involve coding the mechanisms for establishing and maintaining private channels and ensuring they work seamlessly with the nostr relay system.
    
5.  **Testing and Validation**: Rigorously test the implementation to ensure that it not only maintains privacy but also works efficiently and securely within the Joinstr framework.
    
6.  **Document the process and seek Community Feedback**: Update the Joinstr documentation to include information about the new private channel feature. Engage with the Joinstr and broader cryptocurrency community for feedback and improvements.
    

Conclusion
----------

Using encrypted channels in each [CoinJoin](https://bitcointalk.org/index.php?topic=279249.0) round within [JoinStr](https://JoinStr.xyz) is a powerful way to enhance your transaction privacy, anonymity and security. By following these best practices, you can ensure that you're making the most out of this innovative technology.

We invite all the participants to help us build this functionality applying to the bounty and ideally writing a public article to share and validate the process adopted. Remember to check [Joinstr documentation](https://docs.joinstr.xyz/) and share your thoughts and questions on our public [Telegram channel](https://t.me/Joinstr).

Looking forward to hearing from you all! Cheers 🤙