From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 07 Jan 2025 07:59:44 -0800 Received: from mail-yb1-f190.google.com ([209.85.219.190]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tVBzb-0006u4-8n for bitcoindev@gnusha.org; Tue, 07 Jan 2025 07:59:44 -0800 Received: by mail-yb1-f190.google.com with SMTP id 3f1490d57ef6-e549eac4ae6sf6502665276.1 for ; Tue, 07 Jan 2025 07:59:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1736265576; x=1736870376; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=dD9Lzfp39WmgjboSEkUZ667qBPKLSrjBhhYd/3hCTaM=; b=pT+yXhUKc6meTQJ47Uv+aIFjOnOwrrIy/CPqcQozdQ+EaB99ZNqj+GP7BRXI6hbDnM QV9FgWNNhWvDqLEY8G9NjLUJh0s7w94sUi3SjUyUQY2rkbSvuujpzl7DIikDI5DApwJK kmItkVpQ3+oSw9/ymbKJlvvRJtpiER9AT2HRhMHyYv1AhAbQnrJEBmObCI3sk5pQLvTC kd4dP5vkAz5R3+jtAaihwDdGd7UCAke6sbJRa1+1b79lZEvPyfOT+5nvIFnFVWO/zwN3 toYcSDNXKtiohO9nwiHZKuy/PPZ1juBTIfNLwggVIvTfOtmfPVeXNuZMifxrP4+rfny7 CzBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736265576; x=1736870376; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=dD9Lzfp39WmgjboSEkUZ667qBPKLSrjBhhYd/3hCTaM=; b=RZfqygOQeD+lUaSaQ1vEk2waeLn7QrZEarPOqPeV91+gRzvfT7IFAza9DPUCpv2OcZ M26oe2XTZGSMY44/Er+Scy+MmnfNa+pPttiNqyU8vdFvye0JRA3rfH8Bh00QWai44DM9 uYLpDJrc82iTHrfm8wWggD1gB7J325xmmw8MW4BFkVD4JSFzNDJzzSDLbZPa0Vpnb8xp /wSwzBYupaM2W6BXuF7vuHaozl+6giGf1KZ98EVPXs3EmDuWRfvHWojWwHEAeMpTEQTd AwA4KFU3fZiQ/QXZdI0/EaPC2wFU2wNTvyar0GSr6SV9M96lBXj1ZBzaatoOpXYIWW9U Iesg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736265577; x=1736870377; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=dD9Lzfp39WmgjboSEkUZ667qBPKLSrjBhhYd/3hCTaM=; b=Jsm4rPT/zEWvol1Cc4uFUuLlslQHDjgSC/iVZaclmV29ZB5XRHGiInnnYCcauzSsDE 61ffE5sPtgcWFJNxIYskftBEIwUx0weLJpTS7lbElc0rSbARMdTxxYYvT/8DsWeXUjuF RKCJdp/Cud9UBnjkoEye2bcCxiyp/jZ242H5etWzytDu7NHXLHWySTIAUnog4idxVFnD D3Ys0Svr9zjKiBE/tbUbvjJJ8dKU33qKXdfoJmgnrTrLD5rl910LT3wiM63u5VyUl/s5 UXPR2BtkHcv08/UJhtIieqbum/mEQKlPfZWdGKipxRTCvWGhk9lUB1q3qj4VOLCxpt3x H2bg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWnjTDnf21j0EbX1Uc/rZKNRLcMtCCqpQauOr4NKUcKf/il444b/gJvCZ+qaP3EExv+HfJOsp/IzSrX@gnusha.org X-Gm-Message-State: AOJu0Ywb3Dwj8aOpzWJ9t7J1yueH60qFPpO7IB5qSPIorXG8p+liFG4Y /cZa6UJ409yGjpRjykzwcLcYalKW746wzJamK5hqmTEQbxWOTW+K X-Google-Smtp-Source: AGHT+IFlUyzsFg3Yd51iPji5piQ6O3XyCgjdj3EFhbzJMFQEsEJJ43x/3+iyEAeZ/Qp1l+c+qXU7Lg== X-Received: by 2002:a05:6902:2e0c:b0:e53:5eca:de59 with SMTP id 3f1490d57ef6-e538c2328a7mr48081868276.13.1736265576517; Tue, 07 Jan 2025 07:59:36 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a25:ab85:0:b0:e47:56ee:7a99 with SMTP id 3f1490d57ef6-e549d7e3dc6ls604755276.0.-pod-prod-02-us; Tue, 07 Jan 2025 07:59:33 -0800 (PST) X-Received: by 2002:a05:690c:690b:b0:6e2:2600:ed50 with SMTP id 00721157ae682-6f3f813688dmr421643147b3.21.1736265573294; Tue, 07 Jan 2025 07:59:33 -0800 (PST) Received: by 2002:a81:ad03:0:b0:6ef:892f:89f3 with SMTP id 00721157ae682-6f3f57ea50dms7b3; Tue, 7 Jan 2025 07:56:02 -0800 (PST) X-Received: by 2002:a05:690c:f87:b0:6ef:4fba:8153 with SMTP id 00721157ae682-6f3f8106fd5mr408126037b3.10.1736265360925; Tue, 07 Jan 2025 07:56:00 -0800 (PST) Date: Tue, 7 Jan 2025 07:56:00 -0800 (PST) From: waxwing/ AdamISZ To: Bitcoin Development Mailing List Message-Id: <6a5ac106-6f8d-480d-91f6-0b9796977554n@googlegroups.com> In-Reply-To: References: Subject: Re: [bitcoindev] Reiterating centralized coinjoin (Wasabi & Samourai) deanonymization attacks MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_51232_470179013.1736265360588" X-Original-Sender: ekaggata@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_51232_470179013.1736265360588 Content-Type: multipart/alternative; boundary="----=_Part_51233_1321520125.1736265360588" ------=_Part_51233_1321520125.1736265360588 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello nothingmuch, Sjors, list, Thanks nothingmuch for the writeup on coinjoins with coordinators. This general topic is rarely covered and while people like me know about=20 it, we (well, I) are/am too lazy to get into the details of what kinds of= =20 problems exist. I think there are two distinct categories of weakness here: 1/ the ability of the coordinator to Sybil a targeted user by *not*=20 including other unknown-to-coordinator entities in the join. This can be=20 done by blocking access of those other entities, and/or Sybilling by adding= =20 their own entities. This first weakness is absolutely fundamental for all participants *except*= =20 the coordinator; you can't code/algorithm/crypto your way around it.=20 Justification of that: the essence of this coordination is that it must be= =20 anonymous for the participants, that is the whole point. Therefore the=20 ability to distinguish between Sybils and non-Sybils cannot exist, in pure= =20 form. However: The weakness is ameliorated, but not removed, by using decentralization of= =20 having oneself be the coordinator for a join. I say "not removed" because= =20 the Sybil risk still exists, but the bar is set much higher for the=20 attacker, since they have to Sybil the whole ecosystem, i.e. they have no= =20 control over who else takes part. It is also ameliorated, but not removed,= =20 by cost imposition (see Joinmarket fidelity bonds e.g.). What's clear is that this risk is far worse with a static central=20 coordinator for all joins rather than the "each new participant=20 coordinates" model. Also to correct a common imprecision (so not ofc=20 addressed to you nothingmuch, but to the reader): the taker-maker model is= =20 *not* incompatible with coordinator blinding. 2/ the ability of the coordinator to tag a targeted user by shenanigans=20 with the blinding key, roundID etc. The story you tell on this is interesting. In short, as per the=20 "fundamental weakness" paragraph above, it's the nature of these systems=20 that the user is anonymous and ephemeral and therefore the only "identity"= =20 they have is the coin they bring to the join. Given that, attestations=20 being verifiable requires blockchain access as the ground truth. For=20 similar things in Joinmarket's protocol (and rest assured, we had the same= =20 requirement, basically), we never had to bat an eye, because we could make= =20 calls on the utxo set at any time, since we *force* users to use full=20 nodes. But as you say, it *should* still be fully possible with various=20 kinds of light client ... so I am wondering why the people working on the= =20 Wasabi project didn't consider this a sine-qua-non. Why even bother with=20 blinding if you're not going to give the client a surety that the blinding= =20 is actually doing anything? On reflection, I can see at least one counter-argument: suppose user2 is=20 looking at user1's signature on the context of the round, and they are=20 given key P for user1's signature and just told "trust me" by the=20 coordinator, and they go ahead, because user2 only has a light client and= =20 no merkle proofs. Well, if the coordinator lies about P, the user2 can find= =20 out later that day, using a full node or block explorer to check user1's=20 utxo. Now, if the coordinator's message is *signed* so as to be=20 non-repudiable, then user2 can prove to the world that the coordinator=20 lied. Conditional on that signing, I think this counter-argument is strong;= =20 in the absence of signing, with repudiable messages instead, then I think= =20 it's weak. I guess all this comes into particularly sharp focus now that we have=20 various different Wasabi coordinators. They should all be assumed to be run= =20 by the Feds, so to speak, and analyzed from that perspective. (not that=20 that wasn't true with only 1, just that it's more true, now). A few more specific Qs/comments: On the Samourai issue: > Because the key is not announced a priori, nor is it signed by the=20 participants' spending keys before output registration or signing[^5], the= =20 server can provide each input with a unique RSA key. Since the unblinded=20 signatures are made by different keys, the server can learn the mapping=20 from inputs to outputs.=20 My gut reaction is to do "permanent key tweaked with context" here, so the= =20 client could easily verify, based on remembering the permanent key, that=20 the correct (hash of date plus round number plus whatever) had been=20 applied. But that works in Schnorr family, I don't know if a key tweak can= =20 be applied to RSA? Perhaps this question is academic, but I want to know=20 how easily this could have been fixed in practice. (I don't know why they= =20 were using RSA, but I could imagine various practical reasons; there were= =20 after all known attacks on Schnorr blinded signing). > 2. use of deterministic shuffling in the transaction, ensuring that=20 signatures can only be aggregated in the absence of equivocation (assuming= =20 the corresponding Lehmer code has enough bits of entropy)=20 That's an elegant idea; I presume it depends on tx size being large enough= =20 (yeah, bits of entropy), but that certainly isn't an issue for the=20 Wa(bi)sabi design. Couldn't a similar trick be played with the=20 coordinator's receiving address (assuming that wasabi still works like=20 that, with a coordinator fee address in the tx)? > it seems to me that if it was controlled by a rational attacker it would= =20 not use the overt key tagging attack when covert ways of deanonymizing are= =20 available and just as effective.=20 It seems I missed something, here. What covert attacks are possible except= =20 for Sybilling, excluding other users from the round? - which is only at=20 best semi-covert. Maybe stuff like timing and tor? Cheers, waxwing/AdamISZ On Monday, January 6, 2025 at 8:31:34=E2=80=AFAM UTC-6 Yuval Kogman wrote: > On Mon, 6 Jan 2025 at 14:08, Sjors Provoost wrote: > > > Do we know based on observations or published server-side code whether > > this key was: > > > 1) the same for all time; or > > 2) unique for each round; or > > 3) unique for each registration request > > > > In case of (1) and (2) it would have been possible to detect a targeted= *=20 > attack, > > of course only if you were on the lookout. > > Only (2) would be correct behavior. If (3) was performed, then that is > just the tagging attack. If (1) was done, then that would have allowed > clients to stockpile blind signatures in earlier rounds, and register > excess outputs during the output registration phase of later ones to > disrupt them (wasabi 1 had this bug FWIW). > > if the archived code is considered reliable, then it seems (2) was the > implemented behavior: > > > https://github.com/Archive-Samourai-Wallet/whirlpool-server/blob/develop/= src/main/java/com/samourai/whirlpool/server/beans/Mix.java#L67 > > > Perhaps if the app kept sufficient logs, it would still be possible to= =20 > retroactively > > check this. > > I'm not aware of any such observation efforts. They would require > modifying the client, at least with the archived version that I saw > the `blindingParams` member is not used that way (there are other > debug logs in the whirlpool client, but not with this data). > > However, since the public key is only given in response to input > registration, i.e. after the server has learned of the intended UTXO, > and because in many cases an xpub linking that coin may have also been > revealed to the server, and the server controls the grouping of coins > into sets of 5, it seems to me that if it was controlled by a rational > attacker it would not use the overt key tagging attack when covert > ways of deanonymizing are available and just as effective. > > > * =3D I=E2=80=99m thinking of an active attacker who wants to track spe= cific UTXOs. > > They could preemptively =E2=80=9Cpersuade=E2=80=9D the coordinator serv= er to provide > > a different RSA key or round ID if they ever try to join a round. > > While this is certainly possible, maintaining plausible deniability is > easier if the server merely maliciously control the placement of > UTXOs, ensuring that targeted UTXOs end up only with xpub-revealed > and/or adversary controlled peers. > > > Are these round IDs logged by clients? > > In the case of wasabi, both my recollection and a cursory search > indicates that yes: > > > https://github.com/WalletWasabi/WalletWasabi/blob/42e7963d7fffc7f8f37fd9b= 6e8973235859ee7fb/WalletWasabi/WabiSabi/LoggerTools.cs#L36 > > I did not check in detail where this information is logged, and I > don't think a list of all published round IDs is logged. > > I would not encourage users to share such logs, or their data, without > careful considerations. Even if logs were scrubbed, revealing a/the > set of rounds in which a user participated can significantly harm > privacy, especially since participation in rounds and coin selection > does not take into account history intersection attacks. See also > these issues re log scrubbing > https://github.com/WalletWasabi/WalletWasabi/issues/6770 > https://github.com/WalletWasabi/WalletWasabi/issues/6670 (first was > closed without fixing, deemed duplicate of 2nd - i'd say it isn't - > which is still open...). > > One of the developers still working on wasabi indicated that there > will finally be some efforts to mitigate this class of attack: > > 1. redundant queries from isolated tor circuits of the round status > information where round IDs are published, and consistency checks for > the data returned > 2. use of deterministic shuffling in the transaction, ensuring that > signatures can only be aggregated in the absence of equivocation > (assuming the corresponding Lehmer code has enough bits of entropy) > > Since round IDs are published ahead of time in the status requests, > and clients explicitly choose which round to join before revealing any > of their intended inputs, the first mitigation is straightforward and > would present a significant barrier. > --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 6a5ac106-6f8d-480d-91f6-0b9796977554n%40googlegroups.com. ------=_Part_51233_1321520125.1736265360588 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello nothingmuch, Sjors, list,

Thanks nothingmuch for the write= up on coinjoins with coordinators.
This general topic is rarely covere= d and while people like me know about it, we (well, I) are/am too lazy to g= et into the details of what kinds of problems exist.


I thi= nk there are two distinct categories of weakness here:

1/ the ab= ility of the coordinator to Sybil a targeted user by *not* including other = unknown-to-coordinator entities in the join. This can be done by blocking a= ccess of those other entities, and/or Sybilling by adding their own entitie= s.

This first weakness is absolutely fundamental for all partici= pants *except* the coordinator; you can't code/algorithm/crypto your way ar= ound it. Justification of that: the essence of this coordination is that it= must be anonymous for the participants, that is the whole point. Therefore= the ability to distinguish between Sybils and non-Sybils cannot exist, in = pure form. However:

The weakness is ameliorated, but not removed= , by using decentralization of having oneself be the coordinator for a join= . I say "not removed" because the Sybil risk still exists, but the bar is s= et much higher for the attacker, since they have to Sybil the whole ecosyst= em, i.e. they have no control over who else takes part. It is also ameliora= ted, but not removed, by cost imposition (see Joinmarket fidelity bonds e.g= .).

What's clear is that this risk is far worse with a static ce= ntral coordinator for all joins rather than the "each new participant coord= inates" model. Also to correct a common imprecision (so not ofc addressed t= o you nothingmuch, but to the reader): the taker-maker model is *not* incom= patible with coordinator blinding.

2/ the ability of the coordin= ator to tag a targeted user by shenanigans with the blinding key, roundID e= tc.

The story you tell on this is interesting. In short, as per = the "fundamental weakness" paragraph above, it's the nature of these system= s that the user is anonymous and ephemeral and therefore the only "identity= " they have is the coin they bring to the join. Given that, attestations be= ing verifiable requires blockchain access as the ground truth. For similar = things in Joinmarket's protocol (and rest assured, we had the same requirem= ent, basically), we never had to bat an eye, because we could make calls on= the utxo set at any time, since we *force* users to use full nodes. But as= you say, it *should* still be fully possible with various kinds of light c= lient ... so I am wondering why the people working on the Wasabi project di= dn't consider this a sine-qua-non. Why even bother with blinding if you're = not going to give the client a surety that the blinding is actually doing a= nything?

On reflection, I can see at least one counter-argument:= suppose user2 is looking at user1's signature on the context of the round,= and they are given key P for user1's signature and just told "trust me" by= the coordinator, and they go ahead, because user2 only has a light client = and no merkle proofs. Well, if the coordinator lies about P, the user2 can = find out later that day, using a full node or block explorer to check user1= 's utxo. Now, if the coordinator's message is *signed* so as to be non-repu= diable, then user2 can prove to the world that the coordinator lied. Condit= ional on that signing, I think this counter-argument is strong; in the abse= nce of signing, with repudiable messages instead, then I think it's weak.
I guess all this comes into particularly sharp focus now that we = have various different Wasabi coordinators. They should all be assumed to b= e run by the Feds, so to speak, and analyzed from that perspective. (not th= at that wasn't true with only 1, just that it's more true, now).

A few more specific Qs/comments:

On the Samourai issue:
> Because the key is not announced a priori, nor is it signed by the= participants' spending keys before output registration or signing[^5], the= server can provide each input with a unique RSA key. Since the unblinded s= ignatures are made by different keys, the server can learn the mapping from= inputs to outputs.

My gut reaction is to do "permanent key twe= aked with context" here, so the client could easily verify, based on rememb= ering the permanent key, that the correct (hash of date plus round number p= lus whatever) had been applied. But that works in Schnorr family, I don't k= now if a key tweak can be applied to RSA? Perhaps this question is academic= , but I want to know how easily this could have been fixed in practice. (I = don't know why they were using RSA, but I could imagine various practical r= easons; there were after all known attacks on Schnorr blinded signing).

> 2. use of deterministic shuffling in the transaction, ensuring= that signatures can only be aggregated in the absence of equivocation (ass= uming the corresponding Lehmer code has enough bits of entropy)

That's an elegant idea; I presume it depends on tx size being large enough= (yeah, bits of entropy), but that certainly isn't an issue for the Wa(bi)s= abi design. Couldn't a similar trick be played with the coordinator's recei= ving address (assuming that wasabi still works like that, with a coordinato= r fee address in the tx)?

> it seems to me that if it was con= trolled by a rational attacker it would not use the overt key tagging attac= k when covert ways of deanonymizing are available and just as effective.
It seems I missed something, here. What covert attacks are possib= le except for Sybilling, excluding other users from the round? - which is o= nly at best semi-covert. Maybe stuff like timing and tor?

Cheers= ,
waxwing/AdamISZ



On Monday, January 6, 2025 at 8:31:34= =E2=80=AFAM UTC-6 Yuval Kogman wrote:
On Mon, 6 Jan 2025 at 14:08, Sjors Provoost <sj...@sprovoost.nl> wrote:

> Do we know based on observations or published server-side code whe= ther
> this key was:

> 1) the same for all time; or
> 2) unique for each round; or
> 3) unique for each registration request
>
> In case of (1) and (2) it would have been possible to detect a tar= geted* attack,
> of course only if you were on the lookout.

Only (2) would be correct behavior. If (3) was performed, then that is
just the tagging attack. If (1) was done, then that would have allowed
clients to stockpile blind signatures in earlier rounds, and register
excess outputs during the output registration phase of later ones to
disrupt them (wasabi 1 had this bug FWIW).

if the archived code is considered reliable, then it seems (2) was the
implemented behavior:

https://github.com/Archive-Samourai-Wallet/whir= lpool-server/blob/develop/src/main/java/com/samourai/whirlpool/server/beans= /Mix.java#L67

> Perhaps if the app kept sufficient logs, it would still be possibl= e to retroactively
> check this.

I'm not aware of any such observation efforts. They would require
modifying the client, at least with the archived version that I saw
the `blindingParams` member is not used that way (there are other
debug logs in the whirlpool client, but not with this data).

However, since the public key is only given in response to input
registration, i.e. after the server has learned of the intended UTXO,
and because in many cases an xpub linking that coin may have also been
revealed to the server, and the server controls the grouping of coins
into sets of 5, it seems to me that if it was controlled by a rational
attacker it would not use the overt key tagging attack when covert
ways of deanonymizing are available and just as effective.

> * =3D I=E2=80=99m thinking of an active attacker who wants to trac= k specific UTXOs.
> They could preemptively =E2=80=9Cpersuade=E2=80=9D the coordi= nator server to provide
> a different RSA key or round ID if they ever try to join a ro= und.

While this is certainly possible, maintaining plausible deniability is
easier if the server merely maliciously control the placement of
UTXOs, ensuring that targeted UTXOs end up only with xpub-revealed
and/or adversary controlled peers.

> Are these round IDs logged by clients?

In the case of wasabi, both my recollection and a cursory search
indicates that yes:

https://github.com/WalletWasabi/WalletWasabi/blob/42e79= 63d7fffc7f8f37fd9b6e8973235859ee7fb/WalletWasabi/WabiSabi/LoggerTools.cs#L3= 6

I did not check in detail where this information is logged, and I
don't think a list of all published round IDs is logged.

I would not encourage users to share such logs, or their data, without
careful considerations. Even if logs were scrubbed, revealing a/the
set of rounds in which a user participated can significantly harm
privacy, especially since participation in rounds and coin selection
does not take into account history intersection attacks. See also
these issues re log scrubbing
https://github.com/WalletWasabi/WalletWasabi/issues/6770<= /a>
https://github.com/WalletWasabi/WalletWasabi/issues/6670<= /a> (first was
closed without fixing, deemed duplicate of 2nd - i'd say it isn'= ;t -
which is still open...).

One of the developers still working on wasabi indicated that there
will finally be some efforts to mitigate this class of attack:

1. redundant queries from isolated tor circuits of the round status
information where round IDs are published, and consistency checks for
the data returned
2. use of deterministic shuffling in the transaction, ensuring that
signatures can only be aggregated in the absence of equivocation
(assuming the corresponding Lehmer code has enough bits of entropy)

Since round IDs are published ahead of time in the status requests,
and clients explicitly choose which round to join before revealing any
of their intended inputs, the first mitigation is straightforward and
would present a significant barrier.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/6a5ac106-6f8d-480d-91f6-0b9796977554n%40googlegroups.com.
------=_Part_51233_1321520125.1736265360588-- ------=_Part_51232_470179013.1736265360588--