garlonicon



Offline



Activity: 4

Merit: 3







NewbieActivity: 4Merit: 3

Re: CoinJoin: Bitcoin privacy for the real world July 04, 2019, 01:10:51 AM #747 Quote deanonymization could be easier I didn't think mainly about deanonymization, rather I thought about confirming more transactions per block without increasing the maximum block size. It could be especially useful when we have something like this in mempool:



A -> B -> C -> D -> E -> F -> G



Then, the miner could create a "CoinJoin proposal" like this:



A -> G



And if A will sign it, the miner will save some space. If not, the miner could propose something else, for example:



A -> B -> G



Of course, when we have N transactions in mempool, there are 2^N-(N+1) possible combinations of such "CoinJoin proposals". To avoid spam, we can add some nonce and difficulty to them (since such proposals are "not-yet-signed-by-all-participants" transactions). And if the miner won't collect all needed signatures, it can still use the original non-CoinJoin transactions. I didn't think mainly about deanonymization, rather I thought about confirming more transactions per block without increasing the maximum block size. It could be especially useful when we have something like this in mempool:A -> B -> C -> D -> E -> F -> GThen, the miner could create a "CoinJoin proposal" like this:A -> GAnd if A will sign it, the miner will save some space. If not, the miner could propose something else, for example:A -> B -> GOf course, when we have N transactions in mempool, there are 2^N-(N+1) possible combinations of such "CoinJoin proposals". To avoid spam, we can add some nonce and difficulty to them (since such proposals are "not-yet-signed-by-all-participants" transactions). And if the miner won't collect all needed signatures, it can still use the original non-CoinJoin transactions.