ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2022-04-04 📝 Original message: Good morning pushd, > ...
📅 Original date posted:2022-04-04
📝 Original message:
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][1] 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.
>
> [1]: https://youtu.be/MfaqYeyake8
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
📝 Original message:
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][1] 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.
>
> [1]: https://youtu.be/MfaqYeyake8
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