[bitcoin-dev] A thought experiment on bitcoin for payroll privacy
Lets pretend that I have a company. I'll call it cut throat industries. We are a box cutter testing firm. HR pays the employees biweekly Fridays. In the current way. Cut throat industries pays a single transaction with the company's treasury as the input and each employee payroll as an output. There is no address reuse because HR has a xpub provided by each employee for their payroll wallet. I have 120 employees. The problem The concern is the competition of my precious company and employees seeing our worth and amount in our treasury account. This also exposes how many employees we have and an idea of what the average payroll is. One of my employees is Frank. Frank gets paid then a couple days later he buys some random thing that should not be talked about from a coworker. The coworker can observe Franks input and know what Frank makes. There is another time where cut throat industries is in a temporary financial clamp down. To save money my company is not giving bonuses for the rest of the fiscal year. But one employee of mine has done a very good job at cutting and I was afraid he was going to leave my agency if I did not make an exception for him. So I gave him a raise but not others. Employees notice that one of the 120 biweekly outputs is higher than usual. So they know someone got a raise. Problem summary I am paranoid because I run a company with my finances transparent to my competition and my employees. And my employees are starting to get concerned because their income is transparent to everyone also. These employees are dangerous and professional cutters. I don't want to upset them. What can I do to use bitcoin with privacy to eliminate these concerns? Lightning network is not much an option because they do not have inbound balance to get paid. I cannot front up funds of my own to give them inbound balance because it would consume all of my treasury to lock up funds. So it seems that I have to do payroll on chain. What do I do? -- lee.chif...@secmail.pro PGP 97F0C3AE985A191DA0556BCAA82529E2025BDE35 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Lightning - Is HTLC vulnerable? And mention of Channel Factories
Sorry. Re-sending with correction to CC bitcoin-dev I am sorry if this was already brought up in previous threads. If I know lightning network correctly then HTLC is used to enforce settlements on blockchain if there is a dispute. Could a person lose money if their HTLC does not get confirmed in the timeframe or if an older HTLC gets confirmed first? I see different ways this could happen. One, if the blockchain is very saturated with other transactions. The reason we need lightning network is why it might have troubles with settlements? Two, competition from a different conflicting HTLC. A newer HTLC might not get confirmed before an older HTL. Three, denial of service the lightning router so they never have a chance to send a settlement HTLC. I found out about a recent attack technique that sounds like it might be similar called "flood and loot". Is this a concern on lightning network? I humbly say that I do not fully understand all of lightning network yet. I am working to grasp the idea. These are questions I look to find answer for. Another question I have. I did read the paper Scalable Funding of Bitcoin Micropayment Channel Networks. Would channel factories be better and eliminate my concern? I am sending this to lightning-dev mailing list. I do not see lightning-dev emails because google recaptcha blocks me from the subscribe. Please CC me if you reply so I can read it. -- lee.chif...@secmail.pro PGP 97F0C3AE985A191DA0556BCAA82529E2025BDE35 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
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 concerned with pleasing governments. Bitcoin should be or remain neutral. The term "clean" or "dirty" is defined by whatever government is in power. Bitcoin is not to please government but to be independent of government control and reliance on government or any other centralized systems. To act as censorship resistant money to give people freedom from tyranny. I'm just saying that if anyone can determine if a bitcoin is clean or dirty then I think we are doing something wrong. What is great with certain protocols like coinjoin coinswap and payjoin there is that plausible deniability that hopefully would spread the entire "taint" of bitcoin collectively either for real or just as a possibility to any blockchain analysis entities (with no real way to tell or interpret with accuracy). Bitcoin should be designed in a way where the only way to stop "dirty" bitcoins is to reject all bitcoins. If "dirty" bitcoins is actually a real thing then I guess I could have fun by polluting random peoples bitcoin addresses with "dirty" coins right? No way to prove if it is a self transfer or an unsolicited "donation". I just do not see how any bitcoin UTXO censorship could work because of plausible deniability. If any company actually used UTXO censorship then customers can just use services that are respecting of freedom and do not use censorship. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[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 because payjoin becomes common use and payjoin consolidates utxos through "snowballing". If Alice has a UTXO of 0.05 btc and Bob has a UTXO of 1.15 btc. Bob can be assumed to have more balance because he is a merchant and his customers payjoin him payments alot. If Alice and Bob do a payjoin with Alice paying 0.01 btc to Bob, it would probably look like this right? 0.05---> |>1.16 1.15---> |>0.04 It is very obvious here the amount sent and the sender. Even if Alice did combine another input it would still be very obvious. In this case Alice has another utxo with 0.4 BTC 0.40---> | 0.05---> |>1.16 1.15---> |>0.44 This is still obvious that Alice paid Bob 0.01 BTC isn't it? concern 2 If there is just one consolidated utxo after each payjoin, would it be easy to break the privacy of transaction chains? Alice---payjoin--->Bob Clark---payjoin--->Bob or Alice---payjoin--->Bob---payjoin--->Clark For exmaple, lets say that Alice payjoins to Bob. Then later on Clark payjoins with Bob. Based on the payjoin between Clark and Bob, Clark now knows what UTXO was actually Bob's. And can then know which one was actually Alices. By transacting a payjoin with someone, they could decloak the payjoins before them right? If so, how far back the chain can they go? The issue is not that someone knows the utxos of themselves and the entity they payjoined with. The issue is that someone can figure out the payjoins of others before them with the same entity. I surely must be missing something here. What am I not understanding? -- lee.chif...@secmail.pro PGP 97F0C3AE985A191DA0556BCAA82529E2025BDE35 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility
> > === 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 > (6 BTC) (8 BTC) (1 BTC) >| | | >| | | >v v v > Bob > (5 BTC) (5 BTC) (5 BTC) >| | | >| | | >v v v > Charlie > (9 BTC) (5 BTC) (1 BTC) >| | | >| | | >v v v > Dennis > (7 BTC) (4 BTC) (4 BTC) >| | | >| | | >v v v > Alice > Great work Chris and you have my respects for your contributions to Bitcoin. A concern I have with bitcoin is scalability and privacy. Both are important. The reasons people bash on Monero is also the same issue Bitcoin has. The very large transaction size to achieve acceptable privacy on a distributed financial network. Im not shilling Monero here. I am only saying that bitcoin transactions with similar privacy properties are at least equally as large as Monero transactions. Coinjoin on Monero can be compared to ring signatures in Monero from the view of using decoys to help conceal the source. From this proposal is this to say that transactions will be at least 12 times larger in size to achieve the property of privacy that bitcoin is currently missing? Another thing to consider is that if coinswaps cannot be sent as a payment then a coinswap needs to take place after every transaction to keep the privacy and unlinkability from your other bitcoin transactions. I always thought that CoinSwap would be and is a very much needed thing that needs developed. The ability to swap coins with other people in a trustless way and way that is not linkable to the public blockchain. But how can this be scalable at all with the multiple branches and layers? This is a good idea in theory but my concern would be the scalability issues this creates. Do you have any comments on this? Thank you -- lee.chif...@secmail.pro PGP 97F0C3AE985A191DA0556BCAA82529E2025BDE35 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility
> Coinjoin on Monero can be > compared to ring signatures in Monero from the view of using decoys to > help conceal the source. From this proposal is this to say that > transactions will be at least 12 times larger in size to achieve the > property of privacy that bitcoin is currently missing? > This was a typo. Coinjoin on BITCOIN, can be compared to ring signatures in Monero form the view of using decoys to help conceal the source. The same thing that makes monero transactions large and a scalability concern is the same thing that bitcoin suffers from with using privacy focused transactions. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] v3 onion services
Right now bitcoin client core supports use of tor hidden service. It supports v2 hidden service. I am in progress of creating a new bitcoin node which will use v3 hidden service instead of v2. I am looking at bitcoin core and btcd to use. Do any of these or current node software support the v3 onion addresses for the node address? What about I2P addresses? If not what will it take to get it to support the longer addresses that is used by i2p and tor v3? -- lee.chif...@secmail.pro PGP 97F0C3AE985A191DA0556BCAA82529E2025BDE35 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
