nostr

The end of NIPs

Stacker Saloon

saloon

bitcoin

Sat grátis

Edwuards

Meet René, the legendary "vibe coder" https://stacker.news/items/1085175/r/kpa

Locked 1 BTC until 2030

chebibu

Memes

Meme Monday - Best Bitcoin Meme Gets 5,000 CCs

[^1]
![](https://m.stacker.news/105011)

[^1]: https://www.redhotcyber.com/post/non-so-programmare-ma-ha-vinto-200-hackathon-rene-turcios-la-leggenda-del-vibe-coder/

Google has added a note about non-custodial wallets

Link: https://support.google.com/googleplay/android-developer/answer/16329703

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



mempool

So Tight!

Introducing: Roxom — ego death capital

siggy47

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

![](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.

Footnotes