### Re: [bitcoin-dev] Question about PayJoin effectiveness

Good morning again Mr. Lee, > > I am trying to learn about payjoin. I have a couple concerns on its > > effectiveness. Are my concerns valid or am I missing something? > > concern 1 > > If it is known to be a payjoin transaction anyone could determine the > > sender the recipient and amount

### [bitcoin-dev] Question about PayJoin effectiveness

I am trying to learn about payjoin. I have a couple concerns on its effectiveness. Are my concerns valid or am I missing something? concern 1 If it is known to be a payjoin transaction anyone could determine the sender the recipient and amount right? Lets assume that everyone has a single utxo

### Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

Good morning Mr. Lee, > > === Combining multi-transaction with routing === > > Routing and multi-transaction must be combined to get both benefits. If > > Alice owns multiple UTXOs (of value 6 BTC, 8 BTC and 1 BTC) then this is > > easy with this configuration: > > > > Alice > >

### Re: [bitcoin-dev] Question about PayJoin effectiveness

Good morning Mr. Lee, > I am trying to learn about payjoin. I have a couple concerns on its > effectiveness. Are my concerns valid or am I missing something? > > concern 1 > If it is known to be a payjoin transaction anyone could determine the > sender the recipient and amount right? > > Lets

### [bitcoin-dev] Tainting, CoinJoin, PayJoin, CoinSwap

The problem with CoinJoins is that desire for privacy is explicitly signalled by them, so adversaries can consider them "suspicious." PayJoin and CoinSwap solve this problem, because they are unnoticeable. I think this logic doesn't stand for scrutiny. >From here on let's use the terminology of a

### Re: [bitcoin-dev] Tainting, CoinJoin, PayJoin, CoinSwap

A major point of defeating the common input heuristic and others is to make "super-clusters". A small number of users that "don't care" about possibly touching tainted coins can render many chain analysis techniques unworkable in practice for enforcement. You don't need 100% coverage to defeat the

### Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

Hello Lee, Thanks for the review. On 10/06/2020 01:43, Mr. Lee Chiffre wrote: > >> >> === Combining multi-transaction with routing === >> >> Routing and multi-transaction must be combined to get both benefits. If >> Alice owns multiple UTXOs (of value 6 BTC, 8 BTC and 1 BTC) then this is >>

### Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

Hello ZmnSCPxj, On 10/06/2020 11:58, ZmnSCPxj wrote: > Good morning Chris, > >>> Let me propose an alternative: swap-on-receive+swap-on-change. >> >> That's an interesting point, thanks for the thought. This scheme might >> not be appropriate for every threat model and use case. >> For example,

### Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

Good morning ZmnSCPxj, On 06/06/2020 02:40, ZmnSCPxj wrote: > Good morning Chris, > >> I think I'm having trouble understanding this, does it work like this: >> >> Say we're in the 2-party coinswap case (Alice and Bob) >> >> We have Alice's funding transaction: >> Alice UTXO ---> 2of2 multisig

### Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

Good morning Chris, > > Let me propose an alternative: swap-on-receive+swap-on-change. > > That's an interesting point, thanks for the thought. This scheme might > not be appropriate for every threat model and use case. > For example, if someone wants to use bitcoin just as a foreign currency >

### Re: [bitcoin-dev] Tainting, CoinJoin, PayJoin, CoinSwap

Hello nopara73, On 10/06/2020 13:32, nopara73 via bitcoin-dev wrote: > The problem with CoinJoins is that desire for privacy is explicitly > signalled by them, so adversaries can consider them "suspicious." PayJoin > and CoinSwap solve this problem, because they are unnoticeable. I think > this

### Re: [bitcoin-dev] Question about PayJoin effectiveness

On 10/06/2020 05:01, Mr. Lee Chiffre via bitcoin-dev wrote: > I am trying to learn about payjoin. I have a couple concerns on its > effectiveness. Are my concerns valid or am I missing something? > > concern 1 > If it is known to be a payjoin transaction anyone could determine the > sender the

### Re: [bitcoin-dev] Tainting, CoinJoin, PayJoin, CoinSwap

Thought provoking. In my opinion bitcoin should be designed in a way to where there is no distinction between "clean" bitcoins and "dirty" bitcoins. If one bitcoin is considered dirty then all bitcoins should be considered dirty. Fungibility is important. And bitcoin or its users should not be

### Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network

Good morning Antoine and Gleb, One thing I have been idly thinking about would be to have a *separate* software daemon that performs de-eclipsing for your Bitcoin fullnode. For example, you could run this deeclipser on the same hardware as your Bitcoin fullnode, and have the deeclipser bind to

### Re: [bitcoin-dev] Tainting, CoinJoin, PayJoin, CoinSwap

Good morning nopara73 and Chris, > One way to resist a likely taint analysis attack is to involve other > parts of the bitcoin economy in your transactions. For example our > exchange thief could deposit and then withdraw his stolen coins through > a Bitcoin Casino or other bitcoin service hot