pushd [ARCHIVE] on Nostr: 📅 Original date posted:2022-04-05 📝 Original message: Good morning ZmnSCPxj, ...
📅 Original date posted:2022-04-05
📝 Original message:
Good morning ZmnSCPxj,
> No amount of onchain confidential transactions can hide this fact.
On-chain confidential transaction that I mentioned in my email was in this context:
If someone holds a large sum of BTC or any amount associated with an incident or an old UTXO from 2010, any transaction that spends these UTXOs will be observed by lot of chain analysts.
If this transaction was confidential, nobody can track amounts. Example: https://liquid.network/testnet/tx/4c8b1615109a29ad0fc9e4b40cdab1da3fe83447547806ee3c60e6dc337d9325
> This reduction in liquidity translates to a reduction in anonymity set, meaning it is probably more likely that Alice will be running most of the nodes that *do* support your OmniBOLT-based asset and even if you try to route your funds elsewhere, if you use OmniBOLT, it is likely that Alice will be able to track where you moved your funds.
I agree, liquidity and anonymity set will be less in this case. Second part can be fixed if the project was decentralized and Alice allows anyone to run nodes for providing liquidity.
> You are better off with this scheme if you want to "clean" 1000 BTC:
Tried the steps on testnet and swap transaction was https://mempool.space/testnet/tx/2505145b76c978860ee8061f5cf8a59f38d2a25ecacdd2b17f706a67e6a65287
> Source routing means that Boltz Exchange can report your onchain address, but cannot correlate it with your published node.
I used boltz onion link: http://tboltzzrsoc3npe6sydcrh37mtnfhnbrilqi45nao6cgc6dr7n2eo3id.onion however I still need to trust boltz that no logs are saved for swaps. Maybe running own boltz backend can be helpful.
Thanks for responding to the email and sharing steps that could be used to break links between UTXOs using lightning. I plan to make this process easier with better UI/UX in a mobile app if this works better than coinjoin.
pushd
---
parallel lines meet at infinity?
------- Original Message -------
On Monday, April 4th, 2022 at 1:53 PM, ZmnSCPxj ZmnSCPxj at protonmail.com wrote:
> Good morning pushd,
>
>> Good morning,
>>
>> Things that affect privacy particularly when large sums of money are involved in bitcoin:
>>
>> Liquidity, Anonymity set, Amounts, Type of addresses/scripts, Block, Locktime and Version
>>
>> I have left out things that aren't part of bitcoin protocol or blockchain like KYC. It is difficult for users to move large sums of BTC without being observed because bitcoin does not have confidential transactions to hide amounts. Coinjoin implementations have their own issues, trade-offs, some might even censor transactions and big amounts will still be a problem. Coinswap might be an alternative in future however I wanted to share one solution that could be helpful in improving privacy.
>>
>> Synonym did first stablecoin transaction in a lightning channel using Omni BOLT. Consider Alice starts a bitcoin project in which a lightning channel is used for assets like stablecoin. Bob wants to use 1000 BTC linked with an incident. He opens channels with Alice, gets stablecoin which can be used in any project that supports Omni BOLT assets.
>>
>> Questions:
>>
>> What is the lightning channel capacity when using Omni BOLT?
>>
>> What else can be improved in this setup? Anything else that I maybe missing?
>>
>> I added 'fifty shades of privacy' in subject because it was the first thing that came to my mind when I look at privacy in bitcoin and lightning.
>
> I am not quite sure that using OmniBOLT and a stablecoin (I ssume you mean an asset ostensibly pegged to traditional currency) improves the privacy here.
>
> Even if you have onchain confidentiality, your counterparty has to know how much of the funds are theirs, and by elimination, since there are only the two of you on that channel, the remainder of the funds is yours.
> No amount of onchain confidential transactions can hide this fact.
> And if the channel is unpublished, then the counterparty knows that any send from you is your own payment, and any receive to you is your own received funds.
>
> Using a non-Bitcoin assett(whether pegged to a traditional currency or not) simply reduces the likelihood that you will be able to use the rest of the network, since most of the network only works with Bitcoin.
> This reduction in liquidity translates to a reduction in anonymity set, meaning it is probably more likely that Alice will be running most of the nodes that do support your OmniBOLT-based asset and even if you try to route your funds elsewhere, if you use OmniBOLT, it is likely that Alice will be able to track where you moved your funds.
>
> You are better off with this scheme if you want to "clean" 1000 BTC:
>
> * Set up a published LN node with already-clean funds (or just clean a small amount of BTC using existing CoinJoin methods).
> * Leave it running for a while, or use your existing one.
> * Make all or at least most of its channels published!
> * Make sure it has at least some incoming capacity, use the swap-to-onchain trick or buy incoming liquidity.
> * Set up a throwaway LN node using your dirty 1000 BTC.
> * On your throwaway, create channel(s) to randomly-selected LN nodes.
> * Send amounts from the throwaway to your published LN node.
> * At a later time, send from your published LN node to e.g. Boltz Exchange offchain-to-onchain swap to get funds back onchain and get more incoming capacity to your published LN node.
> * Repeat until you have drained all the funds from your throwaway node.
> * Close the channels of your throwaway node and destroy all evidence of it having ever existed.
>
> This provides privacy:
>
> * By using an intermediate published node to temporarily hold your funds:
> * You disrupt timing correlation from the outgoing payments of your dubious throwaway node to the Boltz Exchange payment: first you pay to your published node, let the funds stew a bit, then send to the Boltz Exchange.
> * Published node has deniability: payments to that node could conceivably be destined elsewhere i.e. the published node can claim it was just forwarding to someone else.
> * Source routing means that Boltz Exchange can report your onchain address, but cannot correlate it with your published node.
>
> Regards,
> ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220405/9506edbb/attachment.html>;
📝 Original message:
Good morning ZmnSCPxj,
> No amount of onchain confidential transactions can hide this fact.
On-chain confidential transaction that I mentioned in my email was in this context:
If someone holds a large sum of BTC or any amount associated with an incident or an old UTXO from 2010, any transaction that spends these UTXOs will be observed by lot of chain analysts.
If this transaction was confidential, nobody can track amounts. Example: https://liquid.network/testnet/tx/4c8b1615109a29ad0fc9e4b40cdab1da3fe83447547806ee3c60e6dc337d9325
> This reduction in liquidity translates to a reduction in anonymity set, meaning it is probably more likely that Alice will be running most of the nodes that *do* support your OmniBOLT-based asset and even if you try to route your funds elsewhere, if you use OmniBOLT, it is likely that Alice will be able to track where you moved your funds.
I agree, liquidity and anonymity set will be less in this case. Second part can be fixed if the project was decentralized and Alice allows anyone to run nodes for providing liquidity.
> You are better off with this scheme if you want to "clean" 1000 BTC:
Tried the steps on testnet and swap transaction was https://mempool.space/testnet/tx/2505145b76c978860ee8061f5cf8a59f38d2a25ecacdd2b17f706a67e6a65287
> Source routing means that Boltz Exchange can report your onchain address, but cannot correlate it with your published node.
I used boltz onion link: http://tboltzzrsoc3npe6sydcrh37mtnfhnbrilqi45nao6cgc6dr7n2eo3id.onion however I still need to trust boltz that no logs are saved for swaps. Maybe running own boltz backend can be helpful.
Thanks for responding to the email and sharing steps that could be used to break links between UTXOs using lightning. I plan to make this process easier with better UI/UX in a mobile app if this works better than coinjoin.
pushd
---
parallel lines meet at infinity?
------- Original Message -------
On Monday, April 4th, 2022 at 1:53 PM, ZmnSCPxj ZmnSCPxj at protonmail.com wrote:
> Good morning pushd,
>
>> Good morning,
>>
>> Things that affect privacy particularly when large sums of money are involved in bitcoin:
>>
>> Liquidity, Anonymity set, Amounts, Type of addresses/scripts, Block, Locktime and Version
>>
>> I have left out things that aren't part of bitcoin protocol or blockchain like KYC. It is difficult for users to move large sums of BTC without being observed because bitcoin does not have confidential transactions to hide amounts. Coinjoin implementations have their own issues, trade-offs, some might even censor transactions and big amounts will still be a problem. Coinswap might be an alternative in future however I wanted to share one solution that could be helpful in improving privacy.
>>
>> Synonym did first stablecoin transaction in a lightning channel using Omni BOLT. Consider Alice starts a bitcoin project in which a lightning channel is used for assets like stablecoin. Bob wants to use 1000 BTC linked with an incident. He opens channels with Alice, gets stablecoin which can be used in any project that supports Omni BOLT assets.
>>
>> Questions:
>>
>> What is the lightning channel capacity when using Omni BOLT?
>>
>> What else can be improved in this setup? Anything else that I maybe missing?
>>
>> I added 'fifty shades of privacy' in subject because it was the first thing that came to my mind when I look at privacy in bitcoin and lightning.
>
> I am not quite sure that using OmniBOLT and a stablecoin (I ssume you mean an asset ostensibly pegged to traditional currency) improves the privacy here.
>
> Even if you have onchain confidentiality, your counterparty has to know how much of the funds are theirs, and by elimination, since there are only the two of you on that channel, the remainder of the funds is yours.
> No amount of onchain confidential transactions can hide this fact.
> And if the channel is unpublished, then the counterparty knows that any send from you is your own payment, and any receive to you is your own received funds.
>
> Using a non-Bitcoin assett(whether pegged to a traditional currency or not) simply reduces the likelihood that you will be able to use the rest of the network, since most of the network only works with Bitcoin.
> This reduction in liquidity translates to a reduction in anonymity set, meaning it is probably more likely that Alice will be running most of the nodes that do support your OmniBOLT-based asset and even if you try to route your funds elsewhere, if you use OmniBOLT, it is likely that Alice will be able to track where you moved your funds.
>
> You are better off with this scheme if you want to "clean" 1000 BTC:
>
> * Set up a published LN node with already-clean funds (or just clean a small amount of BTC using existing CoinJoin methods).
> * Leave it running for a while, or use your existing one.
> * Make all or at least most of its channels published!
> * Make sure it has at least some incoming capacity, use the swap-to-onchain trick or buy incoming liquidity.
> * Set up a throwaway LN node using your dirty 1000 BTC.
> * On your throwaway, create channel(s) to randomly-selected LN nodes.
> * Send amounts from the throwaway to your published LN node.
> * At a later time, send from your published LN node to e.g. Boltz Exchange offchain-to-onchain swap to get funds back onchain and get more incoming capacity to your published LN node.
> * Repeat until you have drained all the funds from your throwaway node.
> * Close the channels of your throwaway node and destroy all evidence of it having ever existed.
>
> This provides privacy:
>
> * By using an intermediate published node to temporarily hold your funds:
> * You disrupt timing correlation from the outgoing payments of your dubious throwaway node to the Boltz Exchange payment: first you pay to your published node, let the funds stew a bit, then send to the Boltz Exchange.
> * Published node has deniability: payments to that node could conceivably be destined elsewhere i.e. the published node can claim it was just forwarding to someone else.
> * Source routing means that Boltz Exchange can report your onchain address, but cannot correlate it with your published node.
>
> Regards,
> ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220405/9506edbb/attachment.html>;