[bitcoin-dev] Preferential Treatment in AttemptToEvictConnection()
Hey Everyone, A lot of pressure rides on AttemptToEvictConnection() because it is used to limit the impact of eclipsing attacks. With continued centralization, fair connection formation becomes a bigger concern. I am curious how other members of the community feel about the preferential treatment and odd comments found in AttemptToEvictConnection(). In short, the concern is that an adversary which intends on providing the useful service of data-arbitrage will have preferential treatment in the formation of the network. https://github.com/bitcoin/bitcoin/blame/df2129a2349b1877049f250551f49a4592e73765/src/net.cpp#L946-L981 Line 948: // An attacker cannot predict which netgroups will be protected -> Perhaps not, but the attacker can have more netgroups than node slots, this can be optimized for. Simply being in different places does not mean the nodes are honest or safe. This is probably a good check to have, but it should not say an "attacker cannot", as this is misleading. Line 952: // An attacker cannot manipulate this metric without physically moving nodes closer to the target. -> Yes, that is exactly what the attacker will do. An attacker can run tcp-traceroute on the network to find where miners clump up, and run a malicious message-relay in a nearby datacenter. With a financial motive it is cheaper to run a low-cost message relay than a mining node. Line 955: // Protect 4 nodes that most recently sent us novel transactions accepted into our mempool. Add recently accepted blocks and txn to AttemptToEvictConnection. // An attacker cannot manipulate this metric without performing useful work .-> If an honest node sees an novel transaction from a new incoming connection, it will be less likely to remove it. A dishonest centralized-service can preemptively send novel-transactions as part of the handshake for new hosts, this will improve the odds of the connection staying open and cutting contact with an honest node. line 962: // Protect 4 nodes that most recently sent us novel blocks. // An attacker cannot manipulate this metric without performing useful work. -> This code has the assumption that an adversary will play by the rules. An attacker will manipluate this metric with the data-arbitrage of novel blocks. An attacker can move newly created blocks from the source (large mining pools) to all parts of the network which can be used to garner value within the connection pool of new hosts. All of the above checks, except for the one starting on 948 is subject to a race condition. All the best, Michael ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] A thought experiment on bitcoin for payroll privacy
Good morning Mr. Lee, > Lightning network is not much an option because they do not have > inbound balance to get paid. Why not? Your company can open a channel with each employee that has insufficient inbound liquidity. The employee is incentivized to reveal their node to your company so you can open a channel to them, since otherwise they would be unable to receive their salary. Your alternative is as you say: openly-visible salaries and throat-cutters who might decide to cut your throat. Let us say your company receives its income stream over Lightning. Let us say you hire a new throat-cutter, with a bi-weekly salary of 0.042 BTC. You ask the new hire if his or her Lightning node has that capacity. If not, you take some of your onchain Lightning funds, swap out say 0.043 BTC on Lightning Loop or Boltz Exchange or some other offchain-to-onchain swap. You use those swapped onchain funds to create a fresh channel to the new hire. If you are onboarding by batches (which your HR is likely to want to do, so they can give the onboarding employee seminars in groups) then you can save onchain fees by using C-Lightning `multifundchannel` as well. The occasional bonus can be a bit tricky, but similarly the employee can use Lightning Loop or Boltz Exchange or some other alternative to free up capacity for the bonus (and they have an incentive to do so, as they want to get the bonus). Permanent raises can justify permanently increasing the size of the channel with the employee. Even if the employee leaves your employ, that is no justification to close the channel with her or his node. You can earn forwarding fees from his or her new employer or income source. Because of the onion routing, it is hard for you to learn what the employee spends on, and in the future when they leave your employ, it is hard for you to figure out her or his new employer. If the employee is a saver, they can accumulate their funds, thus reducing their incoming capacity below their biweekly salary. If so, he or she can use an offchain-to-onchain swap, again, to move their accumulated savings to onchain cold storage. This is not perfect of course, if you run multiple nodes you can try correlating payments by timing and amount (and prior to payment points i.e. today, you can correlate by payment hashes). But this is still much better than the onchain situation, as you describe. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[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
Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap appendium
Good morning Chris, > > Looking at these equations, I realize that the incentives against > post-coinswap-theft-attempt still work even if we set K = 0, because the > extra miner fee paid by Bob could be enough disincentive. This made me pause for a moment, but on reflection, is correct. The important difference here relative to v1 is that the mining fee for the collateralized contract transaction is deducted from the `Jb` input provided by Bob. > Unlike the v1 protocol, each CoinSwap party knows a different version of > the contract transactions, so the taker Alice always knows which maker > broadcast a certain set of contract transactions, and so can always ban > the correct fidelity bond. Great observation, and an excellent property to have. Will go think about this more. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap appendium
Hello list, This email is an appendium or modification of the earlier CoinSwap protocol published on this list. It is intended to fix the problems found in review. (Original email quoted here too) On 11/08/2020 13:05, Chris Belcher via bitcoin-dev wrote: > I'm currently working on implementing CoinSwap (see my other email > "Design for a CoinSwap implementation for massively improving Bitcoin > privacy and fungibility"). > > CoinSwaps are special because they look just like regular bitcoin > transactions, so they improve the privacy even for people who do not use > them. Once CoinSwap is deployed, anyone attempting surveillance of > bitcoin transactions will be forced to ask themselves the question: how > do we know this transaction wasn't a CoinSwap? > > This email contains a detailed design of the first protocol version. It > makes use of the building blocks of multi-transaction CoinSwaps, routed > CoinSwaps, liquidity market, private key handover, and fidelity bonds. > It does not include PayJoin-with-CoinSwap, but that's in the plan to be > added later. > > == Routed CoinSwap == > > Diagram of CoinSwaps in the route: > > Alice > Bob > Charlie > Alice > > Where (>) means one CoinSwap. Alice gives coins to Bob, who gives > coins to Charlie, who gives coins to Alice. Alice is the market taker > and she starts with the hash preimage. She chooses the CoinSwap amount > and chooses who the makers will be. > > This design has one market taker and two market makers in its route, but > it can easily be extended to any number of makers. > > == Multiple transactions == > > Each single CoinSwap is made up of multiple transactions to avoid amount > correlation > > (a0 BTC) ---> (b0 BTC) ---> (c0 BTC) ---> > Alice (a1 BTC) ---> Bob (b1 BTC) ---> Charlie (c1 BTC) ---> Alice > (a2 BTC) ---> (b2 BTC) ---> (c2 BTC) ---> > > The arrow (--->) represent funding transactions. The money gets paid to > a 2-of-2 multisig but after the CoinSwap protocol and private key > handover is done they will be controlled by the next party in the route. > > This example has 6 regular-sized transactions which use approximately > the same amount of block space as a single JoinMarket coinjoin with 6 > parties (1 taker, 5 makers). Yet the privacy provided by this one > CoinSwap would be far far greater. It would not have to be repeated in > the way that Equal-Output CoinJoins must be. > > == Direct connections to Alice === > > Only Alice, the taker, knows the entire route, Bob and Charlie just know > their previous and next transactions. Bob and Charlie do not have direct > connections with each other, only with Alice. > > Diagram of Tor connections: > > Bob Charlie > | / > | / > | / > Alice > > When Bob and Charlie communicate, they are actually sending and > receiving messages via Alice who relays them to Charlie or Bob. This > helps hide whether the previous or next counterparty in a CoinSwap route > is a maker or taker. > > This doesn't have security issues even in the final steps where private > keys are handed over, because those private keys are always for 2-of-2 > multisig and so on their own are never enough to steal money. > > > === Miner fees === > > Makers have no incentive to pay any miner fees. They only do > transactions which earn them an income and are willing to wait a very > long time for that to happen. By contrast takers want to create > transactions far more urgently. In JoinMarket we coded a protocol where > the maker could contribute to miner fees, but the market price offered > of that trended towards zero. So the reality is that takers will pay all > the miner fees. Also because makers don't know the taker's time > preference they don't know how much they should pay in miner fees. > > The taker will have to set limits on how large the maker's transactions > are, otherwise makers could abuse this by having the taker consolidate > maker's UTXOs for free. > > == Funding transaction definitions == > > Funding transactions are those which pay into the 2-of-2 multisig addresses. > > Definitions: > I = initial coinswap amount sent by Alice = a0 + a1 + a2 > (WA, WB, WC) = Total value of UTXOs being spent by Alice, Bob, Charlie >respectively. Could be called "wallet Alice", "wallet >Bob", etc > (B, C) = Coinswap fees paid by Alice and earned by Bob and Charlie. > (M1, M2, M3) = Miner fees of the first, second, third, etc sets of >funding transactions. Alice will choose what these are >since she's paying. > multisig(A+B) = A 2of2 multisig output with private keys held by A and B > > The value in square parentheses refers to the bitcoin amount. > > Alice funding txes > [WA btc] ---> multisig (Alice+Bob) [I btc] > change [WA-M1-I btc] > Bob funding txes > [WB btc] ---> multisig (Bob+Charlie) [I-M2-B btc] >
