Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds
Hello list, Two points: * The V^2 term is the only thing in the whole scheme that provides any sybil protection. I've already gone through the reasoning in an earlier email and the maths is clear; in a scheme with linear V honest makers have no economic advantage over sybil attackers. This is because only a sybil attacker needs to split up their money into multiple fidelity bonds, and that comes with a penalty under the V^2 rule. It's worth reiterating that including a single evil maker in a JoinMarket coinjoin does not ruin it's privacy. Privacy is only ruined if *all* makers in a coinjoin are controlled by the same entity. So if takers use one maker who has rented TXOs, then its no big deal as long as the other included makers are controlled by other people. Therefore when balancing the harms, consolidation into fewer makers is not as bad as having no sybil protection (which as a reminder means that *all* makers are controlled by one entity), and so the V^2 term does more good than harm. We can't condemn the V^2 rule because of consolidation without acknowledging the good it does in penalizing sybil attacks. * Regarding entities like exchanges running makers. They can also do this today with JoinMarket, the proposed fidelity bond scheme doesn't make that worse. It's an underlying assumption of JoinMarket that coinjoining power is proportional to bitcoin ownership (in a similar way that an underlying assumption of bitcoin is that transaction confirmation power is proportional to hashpower). If those big exchanges find that coinjoins involving them included just one maker controlled by someone else then their aim of deanonymization will have failed. And then those exchanges have to explain to their regulators why they helped hide the origin and destination of some black market money. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds
Good morning Dmitry, Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Thursday, August 8, 2019 7:37 PM, Dmitry Petukhov wrote: > В Thu, 08 Aug 2019 09:35:24 + > ZmnSCPxj zmnsc...@protonmail.com wrote: > > > OP_CHECKSIGVERIFY > > OP_CHECKSIG > > This anti-snitch protection won't work if there are two snitches, which > is concievable in the case of a large-scale consolidated bonds (one > entity can pretend to be two independent entities with two different > TXO). The snitch co-conspirator will refuse to sign the punishment > transaction. > > If you change the MuSig(all_except_snitch) to 1-of-n multisig > construction so that anyone other than the actual 'snitch' can > confiscate the snitch-bond, then there's possibility that that a > co-conspirator can get that bond before others - even before > the sntich transaction is distributed to takers. The correct way to do this, as with any offchain technique, is to have the punishment transactions signed by the MuSig-of-everyone-other-than-punishment-target before you even sign the funding transaction. If consolidation is subsidized by paying rent out to the consolidators, then the lessee of the UTXOs adds its rent payment in the same transaction that atomically instantiates the fidelity bond and all revocable bonds as a single CoinJoined transaction. If any participant refuses to sign the punishment transactions of their co-consolidators, then the lessee refuses to sign the funding transaction and nobody earns any rent and the lessee goes look for another set of UTXO owners (or just kicks out the participant who refuses to sign and lives with the smaller fidelity bond, no big deal). Of course, anyone renting consolidated bonds can themselves be unironic victims of sybil attackers who split up their funds to smaller parts so that their liability when later snitching is reduced, possibly to a level that is comfortable to them. The sybil attacker then pretends to be lessors of UTXOs. > > It seems that to reasonably protect from more than one snitch with this > punishment scheme, you want to make a multitude of taproot leaves where > each leaf can be spent by cooperation of N entities, where N is the > size of expected non-snitch participant set. > > > Finally, aggregation is still possible to insure by off-blockchain > > agreements, possibly with legal consequences, and thus entities like > > exchanges might still be able to aggregate funds and acquire an > > undeservedly large weight in the fidelity bond system. > > This seems to me like the most immediate problem for the discussed > system. > > Since the centralized exchanges or other custodial services already > control TXOs of their customers who sent their funds there, they can > use them to make extra profit with joinmarket, and create fidelity > bonds out of these TXO with (or without) consent of the customers, and > pay them (or not) the amount according to their UTXO, while getting the > consolidation benefit of V^2 for themselves. It is also more probable > that such centralized custodial services would be willing to > participate in a deanonymization efforts, so that they can explain > their participation in coinjoins to regulators. Yes, down with the V^2 superlinearity, it is too strongly centralizing. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds
В Wed, 7 Aug 2019 20:10:17 +0500 Dmitry Petukhov via bitcoin-dev wrote: > In shared ownership rent scheme that ZmnSCPxj described in [1], > the 'TXO rentier' has a signed timelocked 'backout' transaction that > spends the locked TXO, and assigns the reward to rentier. > > If we say that any transaction that spends any TXO in the bond > (ignoring the timelock), invalidates the bond when presented to > takers, then TXO rentier can revoke the bond by simply > publishing this transaction (not to the blockchain, but by some other > means so that takers can receive it). > > The transaction validity can be verified, with the relaxed rules that > ignores the timelock. After it is verified, takers mark the whole > bond as revoked and will not consider it when chosing makers. The backout transaction might not be timelocked itself, but can depend on another timelocked transaction (made specifically to avoid the backout transaction be timelocked). That extra transaction will need to be broadcast before the backout transaction. To account for that possibility, takers would need to either use more relaxed verification rules (do not check if the inputs of the 'snitch transaction' exist), or would need to check the whole package of dependent transactions in which the last one spends the bond. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds
В Thu, 08 Aug 2019 09:35:24 + ZmnSCPxj wrote: > OP_CHECKSIGVERIFY > OP_CHECKSIG This anti-snitch protection won't work if there are two snitches, which is concievable in the case of a large-scale consolidated bonds (one entity can pretend to be two independent entities with two different TXO). The snitch co-conspirator will refuse to sign the punishment transaction. If you change the MuSig(all_except_snitch) to 1-of-n multisig construction so that anyone other than the actual 'snitch' can confiscate the snitch-bond, then there's possibility that that a co-conspirator can get that bond before others - even before the sntich transaction is distributed to takers. It seems that to reasonably protect from more than one snitch with this punishment scheme, you want to make a multitude of taproot leaves where each leaf can be spent by cooperation of N entities, where N is the size of expected non-snitch participant set. > Finally, aggregation is still possible to insure by off-blockchain > agreements, possibly with legal consequences, and thus entities like > exchanges might still be able to aggregate funds and acquire an > undeservedly large weight in the fidelity bond system. This seems to me like the most immediate problem for the discussed system. Since the centralized exchanges or other custodial services already control TXOs of their customers who sent their funds there, they can use them to make extra profit with joinmarket, and create fidelity bonds out of these TXO with (or without) consent of the customers, and pay them (or not) the amount according to their UTXO, while getting the consolidation benefit of V^2 for themselves. It is also more probable that such centralized custodial services would be willing to participate in a deanonymization efforts, so that they can explain their participation in coinjoins to regulators. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds
Good morning Dmitry, and list, > > > I wonder if there's a cryptographic way to prove that muSig and > > > 2P-ECDSA have not been used to create a certain pubkey/signature. > > > > In the second scheme, to revoke/spoil the bond, the entity that > > controls one TXO participating in this bond needs to simply prove that > > it somehow controls/have the ability to spend that TXO. > > In shared ownership rent scheme that ZmnSCPxj described in [1], > > the 'TXO rentier' has a signed timelocked 'backout' transaction that > > spends the locked TXO, and assigns the reward to rentier. > > If we say that any transaction that spends any TXO in the bond > > (ignoring the timelock), invalidates the bond when presented to > > takers, then TXO rentier can revoke the bond by simply > > publishing this transaction (not to the blockchain, but by some other > > means so that takers can receive it). > > The transaction validity can be verified, with the relaxed rules that > > ignores the timelock. After it is verified, takers mark the whole > > bond as revoked and will not consider it when chosing makers. > > One inconvenience here is that takers need to store the > > data about revoked bonds. But it seems to me that there's no need > > for that information to be synchronized between the participants > > instantly. It is enougth for takers to get the revoked-set eventually. > > The rentier are still incentivized to not spoil the bond, to receive > > the profit. Their funds are locked anyway. > > But if the goal of the 'rentier' is to attack the attacker, the > > opportunity cost of these locked funds is the cost of the attack. > > If the renter rents TXOs from several entities to include in one bond, > > revocation by one rentier spoils whole bond, and the total loss for all > > participants is bigger than the oportunity cost of locked funds of a > > single rentier that made the revocation. > > The possibility of such revocation increases risk for the renter and > > would-be co-rentiers, and is likely limit the possible scale of such > > TXO-renting operation. > > This is quite a clever solution. > > Let me then attempt to break it. > > It is possible to encrypt data in such a way that it requires sequential > operations in order to decrypt. > https://www.gwern.net/Self-decrypting-files I apologize, I was being daft. There is a simpler way to break this, involving such Lightning Network tropes as revocation and punishment schemes. Truly, Lightning Network is a great great thing. First, we should always consider, that due to the V^2, consolidated bonds are always higher weight than unconsolidated bonds. Thus, even without considering motives to spy on CoinJoins, the existence of the V^2 tweak implies that there will be fewer larger makers and thus easier to take over the JoinMarket system. So, let us focus on the backout transaction. Under a consolidated bond, this requires an n-of-n. Now, suppose we want to identify the snitch who reports our consolidation scheme to the takers. This can be done easily by performing n MuSig n-of-n rituals, with each ritual using different `r` nonces. We arrange this by having each of the n consolidators be the last signers in the second round of the MuSig, and have each signer keep their own unique version of the signature for the backout, with their own unique `r` nonce. Each participant will want to keep its own version of the signature private, because if it gives out this signature to another participant in the consolidated bond scheme, the other participant can frame them for snitching. We can now identify the snitch, by recognizing which signature was used in the transaction that was reported to the takers. But we have not yet identified how we can punish the snitch. As it happens, MuSig allows Scriptless Script. This means, it is possible for one participant in the MuSig to provide an adaptor signature. This adaptor signature commits to a particular point. When the MuSig is completed and the participant (who is the last signer in the second round of MuSig) reveals the completed signature, the scalar that generates the commited point can be computed by anyone who knows the adaptor signature. This is our next step in our scheme to identify and punish snitches. In addition to putting up their funds in a consolidated bond, each of the participants in the consolidation scheme put up a fraction of the value into revocable bonds. This revocable bond is a Taproot with a known-NUMS point as internal Taproot key, and the script alternatives below: OP_CHECKLOCKTIMEVERIFY OP_DROP OP_CHECKSIG and OP_CHECKSIGVERIFY OP_CHECKSIG A punishment transaction spends from the revocable bond via the second alternative above, and divides it equally among the *other* participants. THis is signed using the MuSig above (where all participants except the owner of this revocable bond are part of). Then, before starting the n rituals to sign the backoff transaction, th
