Re: [bitcoin-dev] Libre/Open blockchain / cryptographic ASICs
Good morning Luke, Another thing we can do with scan mode would be something like the below masking: input CLK, RESET_N; input TESTMODE; input SCANOUT_INTERNAL; output SCANOUT_PAD; reg gating; wire n_gating = gating && TESTMODE; always_ff @(posedge CLK, negedge RESET_N) begin if (!RESET_N) gating <= 1'b1; /*RESET-HIGH*/ elsegating <= n_gating; end assign SCANOUT_PAD = SCANOUT_INTERNAL && gating; The `gating` means that after reset, if we are not in test mode, `gating` becomes 0 permanently and prevents any scan data from being extracted. Assuming scan is not used in normal operation (it should not) then inadvertent ESD noise on the `gating` flip-flop would not have an effect. Output being combinational should be fine as the output is "just" an AND gate, as long as `gating` does not transition from 0->1 (impossible in normal operation, only at reset condition) then glitching is impossible, and when scan is running then `TESTMODE` should not be exited which means `gating` should remain high as well, thus output is still glitch-free. Since the flip-flop resets to 1, and in some technologies I have seen a reset-to-0 FF is slightly smaller than a reset-to-1 FF, it might do good to invert the sense of `gating` instead, and use a NOR gate at the output (which might also be smaller than an AND gate, look it up in the technology you are targeting). On the other hand the above is a tiny circuit already and it is unlikely you need more than one of it (well for large enough ICs you might want more than one scan chain but still, even the largest ICs we handled never had more than 8 scan chains, usually just 4 to 6) so overoptimizing this is not necessary. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
On Fri, Feb 12, 2021 at 9:36 AM Dmitry Petukhov wrote: > If HUMAN_READABLE_TITLE is the additional secret, the user would need > to enter it on the device in addition to the nonce, wouldn't it defeat > the advantage in UX that was gained by using (relatively) short nonce ? > > Is 64 bit nonce not enough ? > > Good question. If we don't need the extra entropy, we can fix the HUMAN_READABLE_TITLE string. Something like "No SPOF". (No Single Point Of Failure). > It seems that to crack this with fixed Pwd and 64 bit nonce, the > attacker will need to be about 10^15 more powerful than 80Mhz MCU: > (2^64)/(0.3*10^15)/3600 = 17 hours. I don't know if 10^15 is realistic > scale. Average desktop cpu seems to be about 10^3 more powerful than > the mentioned MCU for this task. > > Maybe for the UX it would be better to choose the number of rounds to > use in PBKDF2, instead of using variable Pwd. Number of rounds will be > easier to enter on the device (or just choose it from a set of > pre-defined values). The more money is at stake, the higher number of > rounds could the coordinator choose (taking into account the > characteristics of the participant devices) > > Or simply allow bigger entropy (more than 6 mnemonic words), if > the coordinator feels that 64 bit of entropy is not enough. That could work. Allowing variable iteration count is probably better UX-wise. Best, Hugo > > В Fri, 12 Feb 2021 08:55:55 -0800 > Hugo Nguyen wrote: > > > Thanks everyone who has provided inputs so far! > > > > This is the new proposal for the encryption aspect of the scheme, > > based on all the feedback. > > > > The key derivation function would be PBKDF2, with PRF = SHA512. This > > should be readily available on today's hardware already, as they are > > used for BIP39. > > > > DK = PBKDF2(PRF, Password, Salt, c, dkLen) > > PRF = SHA512 > > Pwd = HUMAN_READABLE_TITLE > > Salt = NONCE > > c = 2048 > > dkLen = 256 > > > > HUMAN_READABLE_TITLE is in ASCII format, minimum length = 8, maximum > > length = 20. > > NONCE is a 64-bit number. > > > > Reason for going with SHA512 is due to legacy support on some > > hardware. c=2048 also mimics BIP39. It takes about ~3 seconds to > > derive the encryption key on a 80Mhz MCU. We feel like this is a good > > enough tradeoff for this use case. The assumption here is that the > > secure session is only needed temporarily for a few hours, maybe up > > to one day. > > > > The Coordinator and Signers agree and exchange these 2 secrets prior > > to the setup. The NONCE can be converted to either: > > (a) a 6-word phrase using BIP39 wordlist > > (b) a 20-digit decimal number > > (c) a QR code > > > > Depending on the vendor. This flexibility in the data format allows > > each vendor to customize the UX based on their respective device > > capabilities. > > > > Best, > > Hugo > > > > On Thu, Feb 11, 2021 at 8:25 AM Dmitry Petukhov via bitcoin-dev < > > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > > В Thu, 11 Feb 2021 05:45:33 -0800 > > > Hugo Nguyen via bitcoin-dev > > > wrote: > > > > > > > > > ENCRYPTION_KEY = SHA256(SHA256(TOKEN)) > > > > > > > > > > This scheme might be vulnerable to rainbow table attack. > > > > > > > > > > > > > Thank you for pointing this out! Incidentally, Dmitry Petukhov > > > > also told me the same privately. > > > > > > My thought was that if TOKEN has the characteristics of a password > > > (short ASCII string), then it would be better to use key derivation > > > function designed for passwords, like PBKDF2. > > > > > > The counter-argument to this is that this adds another code > > > dependency for vendors, if the device firmware does not already > > > have the required key derivation function. > > > > > > Maybe this could be solved by going into opposite direction - make > > > the "token" even longer, use the mnemoic. > > > > > > The issue is that entering long data of the shared key into the > > > device manually is difficult UX-wise. > > > > > > Hww vendors that allow to enter custom keys into their device > > > already have to face this issue, and those who allow to enter > > > custom keys via mnemonic probably tackled this somehow. > > > > > > Maybe the shared key for multisig setup can be entered in the same > > > way ? (with maybe additional visual check via some fingerprint). > > > > > > Although we would then have another issue of potential confusion > > > between two procedures (entering the main key and entering the > > > shared key for multisig setup), and the measures has to be taken to > > > prevent such confusion. > > > > > > The approaches can be combined - specify a key derivation function > > > suitable for passwords; via secure channel, share a password and/or > > > the derived key. If hww supports derivation function, it can derive > > > the key from password. If hww supports only keys, the key can be > > > entered raw or via mnemonic. > > > ___ > > > bitcoin-dev mailing list > > >
Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
If HUMAN_READABLE_TITLE is the additional secret, the user would need to enter it on the device in addition to the nonce, wouldn't it defeat the advantage in UX that was gained by using (relatively) short nonce ? Is 64 bit nonce not enough ? It seems that to crack this with fixed Pwd and 64 bit nonce, the attacker will need to be about 10^15 more powerful than 80Mhz MCU: (2^64)/(0.3*10^15)/3600 = 17 hours. I don't know if 10^15 is realistic scale. Average desktop cpu seems to be about 10^3 more powerful than the mentioned MCU for this task. Maybe for the UX it would be better to choose the number of rounds to use in PBKDF2, instead of using variable Pwd. Number of rounds will be easier to enter on the device (or just choose it from a set of pre-defined values). The more money is at stake, the higher number of rounds could the coordinator choose (taking into account the characteristics of the participant devices) В Fri, 12 Feb 2021 08:55:55 -0800 Hugo Nguyen wrote: > Thanks everyone who has provided inputs so far! > > This is the new proposal for the encryption aspect of the scheme, > based on all the feedback. > > The key derivation function would be PBKDF2, with PRF = SHA512. This > should be readily available on today's hardware already, as they are > used for BIP39. > > DK = PBKDF2(PRF, Password, Salt, c, dkLen) > PRF = SHA512 > Pwd = HUMAN_READABLE_TITLE > Salt = NONCE > c = 2048 > dkLen = 256 > > HUMAN_READABLE_TITLE is in ASCII format, minimum length = 8, maximum > length = 20. > NONCE is a 64-bit number. > > Reason for going with SHA512 is due to legacy support on some > hardware. c=2048 also mimics BIP39. It takes about ~3 seconds to > derive the encryption key on a 80Mhz MCU. We feel like this is a good > enough tradeoff for this use case. The assumption here is that the > secure session is only needed temporarily for a few hours, maybe up > to one day. > > The Coordinator and Signers agree and exchange these 2 secrets prior > to the setup. The NONCE can be converted to either: > (a) a 6-word phrase using BIP39 wordlist > (b) a 20-digit decimal number > (c) a QR code > > Depending on the vendor. This flexibility in the data format allows > each vendor to customize the UX based on their respective device > capabilities. > > Best, > Hugo > > On Thu, Feb 11, 2021 at 8:25 AM Dmitry Petukhov via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > В Thu, 11 Feb 2021 05:45:33 -0800 > > Hugo Nguyen via bitcoin-dev > > wrote: > > > > > > > ENCRYPTION_KEY = SHA256(SHA256(TOKEN)) > > > > > > > > This scheme might be vulnerable to rainbow table attack. > > > > > > > > > > Thank you for pointing this out! Incidentally, Dmitry Petukhov > > > also told me the same privately. > > > > My thought was that if TOKEN has the characteristics of a password > > (short ASCII string), then it would be better to use key derivation > > function designed for passwords, like PBKDF2. > > > > The counter-argument to this is that this adds another code > > dependency for vendors, if the device firmware does not already > > have the required key derivation function. > > > > Maybe this could be solved by going into opposite direction - make > > the "token" even longer, use the mnemoic. > > > > The issue is that entering long data of the shared key into the > > device manually is difficult UX-wise. > > > > Hww vendors that allow to enter custom keys into their device > > already have to face this issue, and those who allow to enter > > custom keys via mnemonic probably tackled this somehow. > > > > Maybe the shared key for multisig setup can be entered in the same > > way ? (with maybe additional visual check via some fingerprint). > > > > Although we would then have another issue of potential confusion > > between two procedures (entering the main key and entering the > > shared key for multisig setup), and the measures has to be taken to > > prevent such confusion. > > > > The approaches can be combined - specify a key derivation function > > suitable for passwords; via secure channel, share a password and/or > > the derived key. If hww supports derivation function, it can derive > > the key from password. If hww supports only keys, the key can be > > entered raw or via mnemonic. > > ___ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
В Fri, 12 Feb 2021 18:42:31 +0100 Dmitry Petukhov wrote: > Maybe for the UX it would be better to choose the number of rounds to > use in PBKDF2, instead of using variable Pwd. Number of rounds will be > easier to enter on the device (or just choose it from a set of > pre-defined values). The more money is at stake, the higher number of > rounds could the coordinator choose (taking into account the > characteristics of the participant devices) Or simply allow bigger entropy (more than 6 mnemonic words), if the coordinator feels that 64 bit of entropy is not enough. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
Thanks everyone who has provided inputs so far! This is the new proposal for the encryption aspect of the scheme, based on all the feedback. The key derivation function would be PBKDF2, with PRF = SHA512. This should be readily available on today's hardware already, as they are used for BIP39. DK = PBKDF2(PRF, Password, Salt, c, dkLen) PRF = SHA512 Pwd = HUMAN_READABLE_TITLE Salt = NONCE c = 2048 dkLen = 256 HUMAN_READABLE_TITLE is in ASCII format, minimum length = 8, maximum length = 20. NONCE is a 64-bit number. Reason for going with SHA512 is due to legacy support on some hardware. c=2048 also mimics BIP39. It takes about ~3 seconds to derive the encryption key on a 80Mhz MCU. We feel like this is a good enough tradeoff for this use case. The assumption here is that the secure session is only needed temporarily for a few hours, maybe up to one day. The Coordinator and Signers agree and exchange these 2 secrets prior to the setup. The NONCE can be converted to either: (a) a 6-word phrase using BIP39 wordlist (b) a 20-digit decimal number (c) a QR code Depending on the vendor. This flexibility in the data format allows each vendor to customize the UX based on their respective device capabilities. Best, Hugo On Thu, Feb 11, 2021 at 8:25 AM Dmitry Petukhov via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > В Thu, 11 Feb 2021 05:45:33 -0800 > Hugo Nguyen via bitcoin-dev > wrote: > > > > > ENCRYPTION_KEY = SHA256(SHA256(TOKEN)) > > > > > > This scheme might be vulnerable to rainbow table attack. > > > > > > > Thank you for pointing this out! Incidentally, Dmitry Petukhov also > > told me the same privately. > > My thought was that if TOKEN has the characteristics of a password > (short ASCII string), then it would be better to use key derivation > function designed for passwords, like PBKDF2. > > The counter-argument to this is that this adds another code dependency > for vendors, if the device firmware does not already have the required > key derivation function. > > Maybe this could be solved by going into opposite direction - make the > "token" even longer, use the mnemoic. > > The issue is that entering long data of the shared key into the device > manually is difficult UX-wise. > > Hww vendors that allow to enter custom keys into their device already > have to face this issue, and those who allow to enter custom keys via > mnemonic probably tackled this somehow. > > Maybe the shared key for multisig setup can be entered in the same way > ? (with maybe additional visual check via some fingerprint). > > Although we would then have another issue of potential confusion > between two procedures (entering the main key and entering the shared > key for multisig setup), and the measures has to be taken to prevent > such confusion. > > The approaches can be combined - specify a key derivation function > suitable for passwords; via secure channel, share a password and/or the > derived key. If hww supports derivation function, it can derive the key > from password. If hww supports only keys, the key can be entered raw or > via mnemonic. > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
Hard no to this idea: On Thu, Feb 11, 2021 at 02:29:46PM -0800, Christopher Allen proposed: ... > /48'/0'/0'/3'/PBKDF(complex string)' As someone who has helped people find UTXO at key paths they didn't know/want, this is a terrible idea. Key derivation paths should be small, sequential integers, so they can be searched in reasonable time. Of course when things are working it doesn't matter, but the stakes can be very high when they stop working. This is true for multisig and single signer. --- Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG: A3A31BAD 5A2A5B10 On Thu, Feb 11, 2021 at 02:29:46PM -0800, Christopher Allen wrote: > I think the key issue here is avoiding xpub key reuse in multisig. Not only > in the future with Schnorr, but we need it today! > > Current common practice by hardware wallets is the 48'/0'/0'/2' derivation > for segwit multsig ( e.g. > [90081696/48'/0'/0'/2']xpub6DYLEkDfCdHzh5FHGHDJksQvFqu6kYANa1sfo6fA8n5ZWkSwyCRVVzyq9LY2eNGB6T9BKDeGJp2ZarjRZHd7WB95nSaFEDhFMK6zSV6D49b > ) is the only one used for ALL multisigs offered by that hardware wallet. > > As Pieter said, leveraging a HD path parameters can help, but we need a > better, less reusable path for the index. > > I personally suggest a simpler solution, which is to create an index using > a PBKDF of the Account Policy (a descriptor with all xpubs and keys > removed), plus optional notes. (BTW, I think double sha256 or HMAC is > overkill). > > Example: for the reference bit descriptor that might result in: > > ``` > wsh(sortedmulti(2,xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB/1/0/*,xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH/0/0/*)) > ``` > > What Blockchain Commons (and the Airgapped Wallet Community) call a policy > map would be > > ``` > wsh(sortedmulti(1,,,)) > ``` > > A PBKDF of that as would be unique for all 2 of 3 segwig transactions. With > the addition of the addition of the Policy Map creators optional note, it > would be truly unique. The Policy Map and/or PBKDF are small and could > easily added to existing APIs. > > So for legacy hardware, we can use existing 48' subtree, but 3' as the > format for this form (2' is segwit), then the desktop can just ask for the > /48'/0'/0'/3'/PBKDF' when it requests a new xpub from the hardware token. > More sophisticated Airgapped apps you can send > "wsh(sortedmulti(1,,,))"+label and let the cosigner app do the PBKDF, and > optionally allow it return something different in a full keyset (i.e. > "[90081696/48'/0'/0'/3'/af3948cg…'/]xpub6DYLEk…", and then the requesting > app, knowing that it is different from the PBKDF can know what to do if it > needs to what to ask for in the future. > > The other advantage of this technique is that the cosigner app can know > what policy it is participating in, before the descriptor is completed. It > may decide it doesn't want to participate in some funky 4:9 with a weird > script, and not return an xpub at all. > > Long term I think a commitment scheme should be used, so that you don't > reveal what xpub you offered until all the parties xpubs are shared, but as > Pieter said, we can do that at the same time we do the musig. But we need > to prevent xpub reuse NOW, and I think my proposal easy and could the job. > > -- Christopher Allen, Blockchain Commons signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
On Thu, Feb 11, 2021 at 3:05 PM Christopher Allen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > What Blockchain Commons (and the Airgapped Wallet Community) call a policy > map would be > > ``` > wsh(sortedmulti(1,,,)) > ``` > > A PBKDF of that as would be unique for all 2 of 3 segwig transactions. > With the addition of the addition of the Policy Map creators optional note, > it would be truly unique. The Policy Map and/or PBKDF are small and could > easily added to existing APIs. > > So for legacy hardware, we can use existing 48' subtree, but 3' as the > format for this form (2' is segwit), then the desktop can just ask for the > /48'/0'/0'/3'/PBKDF' when it requests a new xpub from the hardware token. > More sophisticated Airgapped apps you can send > "wsh(sortedmulti(1,,,))"+label and let the cosigner app do the PBKDF, and > optionally allow it return something different in a full keyset (i.e. > "[90081696/48'/0'/0'/3'/af3948cg…'/]xpub6DYLEk…", and then the requesting > app, knowing that it is different from the PBKDF can know what to do if it > needs to what to ask for in the future. > Thanks Christopher, very interesting ideas... A couple of thoughts: 1/ Generating the path index using the policy is clever. However, I think it has 2 problems. Number #1 is with the above scheme now you have a hard dependency on (policy map + note) - losing (policy map + note) means that you will lose access to PBKDF', and hence the funds permanently. At least with the current soluttions, you can look up what the most common derivation paths and indices are to recover funds in the worst case. 2/ Number #2 is that this wouldn't necessarily prevent XPUB reuse. It seems like the above scheme depends on (a) the Coordinator keeping track accurately of all the existing PBKDF-ed indices and (b) the Signer truthfully gives the XPUB at the path that the Coordinator asks for. In reality, neither of these conditions can be guaranteed. For example, the Signer could lie about the XPUB at /48'/0'/0'/3'/PBKDF' when it just keeps reusing the XPUB at /48'/0'/0'/2' 3/ Preventing XPUB reuse is an interesting problem, but IMHO it is beyond the scope of the current proposal. Maybe worth a separate BIP? Best, Hugo On Thu, Feb 11, 2021 at 3:05 PM Christopher Allen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I think the key issue here is avoiding xpub key reuse in multisig. Not > only in the future with Schnorr, but we need it today! > > Current common practice by hardware wallets is the 48'/0'/0'/2' derivation > for segwit multsig ( e.g. > [90081696/48'/0'/0'/2']xpub6DYLEkDfCdHzh5FHGHDJksQvFqu6kYANa1sfo6fA8n5ZWkSwyCRVVzyq9LY2eNGB6T9BKDeGJp2ZarjRZHd7WB95nSaFEDhFMK6zSV6D49b > ) is the only one used for ALL multisigs offered by that hardware wallet. > > As Pieter said, leveraging a HD path parameters can help, but we need a > better, less reusable path for the index. > > I personally suggest a simpler solution, which is to create an index using > a PBKDF of the Account Policy (a descriptor with all xpubs and keys > removed), plus optional notes. (BTW, I think double sha256 or HMAC is > overkill). > > Example: for the reference bit descriptor that might result in: > > ``` > > wsh(sortedmulti(2,xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB/1/0/*,xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH/0/0/*)) > ``` > > What Blockchain Commons (and the Airgapped Wallet Community) call a policy > map would be > > ``` > wsh(sortedmulti(1,,,)) > ``` > > A PBKDF of that as would be unique for all 2 of 3 segwig transactions. > With the addition of the addition of the Policy Map creators optional note, > it would be truly unique. The Policy Map and/or PBKDF are small and could > easily added to existing APIs. > > So for legacy hardware, we can use existing 48' subtree, but 3' as the > format for this form (2' is segwit), then the desktop can just ask for the > /48'/0'/0'/3'/PBKDF' when it requests a new xpub from the hardware token. > More sophisticated Airgapped apps you can send > "wsh(sortedmulti(1,,,))"+label and let the cosigner app do the PBKDF, and > optionally allow it return something different in a full keyset (i.e. > "[90081696/48'/0'/0'/3'/af3948cg…'/]xpub6DYLEk…", and then the requesting > app, knowing that it is different from the PBKDF can know what to do if it > needs to what to ask for in the future. > > The other advantage of this technique is that the cosigner app can know > what policy it is participating in, before the descriptor is completed. It > may decide it doesn't want to participate in some funky 4:9 with a weird > script, and not return an xpub at all. > > Long term I think a commitment scheme should be used, so that you don't > reveal what xpub you offered until all the parties xpubs are shared, but as > Pieter said, we can do that at the same time we do t
Re: [bitcoin-dev] Proposal to stop processing of unrequested transactions in Bitcoin Core
Hi Jeremy, If I understand correctly your concern, you're worried that change would ease discovery of the node's tx-relay topology ? I don't scope transaction origin inference, if you suppose the unrequested-tx peer sending is the attacker it must have learnt the transaction from somewhere else which is more likely to be the tx owner rather than the probed node. As far I can think of this change, a peer might send an unrequested transaction to this node and observe that it's either a) processed, the node has learnt about the txid from another peer or b) rejected, the node has never learnt about the txid. The outcome can be queried by sending a GETDATA for the "is-unrequested" txid. I think the same result can already be achieved by sending an INV and observing if a GETDATA is replied back to guess the presence of another peer with already the knowledge of the txid. Or alternatively, just connect to this other peer and wait for an announcement. What else can we think of ? >From my side, compared to the already-existing heuristics, I don't see how this change is easing attackers' work. That said, I don't deny our transaction announcements/requests logic is worthy of more study about its privacy properties, especially when you acknowledge the recent overhaul of the transaction request and the upcoming Erlay changes. Cheers, Antoine Le jeu. 11 févr. 2021 à 16:15, Pieter Wuille a écrit : > > I'm not sure of the existing behavior is of when we issue a getdata > request, but noting that there could be a privacy implication of this sort > of change. Could you (or someone else) expand on why this is not a concern > here? > > > What kind of privacy concern are you talking about? I'm not sure I see how > this could matter. > > Cheers, > > -- > Pieter > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
