* [bitcoin-dev] Unique node identifiers @ 2017-03-04 16:04 John Hardy 2017-03-05 6:29 ` Marcel Jamin 2017-03-05 13:27 ` Btc Drak 0 siblings, 2 replies; 16+ messages in thread From: John Hardy @ 2017-03-04 16:04 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 2198 bytes --] The discussion of UASF got me thinking about whether such a method might lead to sybil attacks, with new nodes created purely to inflate the node count for a particular implementation in an attempt at social engineering. I had an idea for an anonymous, opt-in, unique node identification mechanism to help counter this. This would give every node the opportunity to create a node ‘address’/unique identifier. This could even come in the form of a Bitcoin address. The node on first installation generates and backs up a private key. The corresponding public key becomes that node’s unique identifier. If the node switches to a new software version or a new IP, the identifier can remain constant if the node operator chooses. Asking a node for its identifier can be done by sending a message the command ‘identify’ and a challenge. The node can then respond with its unique identifier and a signature for the challenge to prove it. The node can also include what software it is running and sign this information so it can be verified as legitimate by third parties. Why would we do this? Well, it adds a small but very useful piece of data when compiling lists of active nodes. Any register of active nodes can have a record of when a node identifier was “first seen”, and how many IPs the same identifier has broadcast from. Also, crucially, we could see what software the node operator has been seen running historically. This information would make it easy to identify patterns. For example if a huge new group of nodes appeared on the network with no history for their identifier they could likely be dismissed as sybil attacks. If a huge number of nodes that had been reporting as Bitcoin Core for an extended period of time started switching to a rival implementation, this would add credibility but not certainty (keys could be traded), that the shift was more organic. This would be trivial to implement, is (to me?) non-controversial, and would give a way for a node to link itself to a pseudo-anonymous identity, but with the freedom to opt-out at any time. Keen to hear any thoughts? Thanks, John Hardy john@seebitcoin•com [-- Attachment #2: Type: text/html, Size: 5702 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] Unique node identifiers 2017-03-04 16:04 [bitcoin-dev] Unique node identifiers John Hardy @ 2017-03-05 6:29 ` Marcel Jamin 2017-03-05 12:55 ` John Hardy 2017-03-05 13:27 ` Btc Drak 1 sibling, 1 reply; 16+ messages in thread From: Marcel Jamin @ 2017-03-05 6:29 UTC (permalink / raw) To: John Hardy, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3119 bytes --] > This could even come in the form of a Bitcoin address. Wouldn't this actually *need* to be a bitcoin address that is included in a block to get any real assurances about the age if this node id? Otherwise malicous nodes could lie and claim to have seen a brand new node id years ago already. Even if included in a block, people could sell their aged IDs (if we were to rely on those for anything). Also funding that ID address would might tie your economic activity (or even identity) to a node. On 4 March 2017 at 17:04, John Hardy via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > The discussion of UASF got me thinking about whether such a method might > lead to sybil attacks, with new nodes created purely to inflate the node > count for a particular implementation in an attempt at social engineering. > > I had an idea for an anonymous, opt-in, unique node identification > mechanism to help counter this. > > This would give every node the opportunity to create a node > ‘address’/unique identifier. This could even come in the form of a Bitcoin > address. > > The node on first installation generates and backs up a private key. The > corresponding public key becomes that node’s unique identifier. If the node > switches to a new software version or a new IP, the identifier can remain > constant if the node operator chooses. > > Asking a node for its identifier can be done by sending a message the > command ‘identify’ and a challenge. The node can then respond with its > unique identifier and a signature for the challenge to prove it. The node > can also include what software it is running and sign this information so > it can be verified as legitimate by third parties. > > Why would we do this? > > Well, it adds a small but very useful piece of data when compiling lists > of active nodes. > > Any register of active nodes can have a record of when a node identifier > was “first seen”, and how many IPs the same identifier has broadcast from. > Also, crucially, we could see what software the node operator has been seen > running historically. > > This information would make it easy to identify patterns. For example if a > huge new group of nodes appeared on the network with no history for their > identifier they could likely be dismissed as sybil attacks. If a huge > number of nodes that had been reporting as Bitcoin Core for an extended > period of time started switching to a rival implementation, this would add > credibility but not certainty (keys could be traded), that the shift was > more organic. > > This would be trivial to implement, is (to me?) non-controversial, and > would give a way for a node to link itself to a pseudo-anonymous identity, > but with the freedom to opt-out at any time. > > Keen to hear any thoughts? > > Thanks, > > John Hardy > > john@seebitcoin•com > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 8225 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] Unique node identifiers 2017-03-05 6:29 ` Marcel Jamin @ 2017-03-05 12:55 ` John Hardy 0 siblings, 0 replies; 16+ messages in thread From: John Hardy @ 2017-03-05 12:55 UTC (permalink / raw) To: Marcel Jamin, bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 4520 bytes --] > Wouldn't this actually *need* to be a bitcoin address that is included in a block I think it being a bitcoin address probably makes the most sense. The address could even be used for donations to incentivise identifier use. I had not really envisaged this having any blockchain presence though. It was just an easy way to give third party node monitors like coin.dance and bitnodes.21.co a few more metrics. That said, it would allow the creation of a 'nodepool', where each node could broadcast its latest status like a transaction, and every node has a register of active nodes. Like a mempool, but for nodes. By leveraging the randomness of node identities, it could be that a deterministic subset of nodes randomly check that a new node status update is legitimate by querying the node directly (a small enough subset to not cause a DDOS). If a threshhold of those random checking nodes reports that the node either doesn't exist or is responding with conflicting information, this will become evident to the network and can be flagged. This should paint a pretty accurate picture of the state of the network, and might also prove useful for developing lightning routing? ________________________________ From: Marcel Jamin <marcel@jamin•net> Sent: Sunday, March 5, 2017 6:29 AM To: John Hardy; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Unique node identifiers > This could even come in the form of a Bitcoin address. Wouldn't this actually *need* to be a bitcoin address that is included in a block to get any real assurances about the age if this node id? Otherwise malicous nodes could lie and claim to have seen a brand new node id years ago already. Even if included in a block, people could sell their aged IDs (if we were to rely on those for anything). Also funding that ID address would might tie your economic activity (or even identity) to a node. On 4 March 2017 at 17:04, John Hardy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote: The discussion of UASF got me thinking about whether such a method might lead to sybil attacks, with new nodes created purely to inflate the node count for a particular implementation in an attempt at social engineering. I had an idea for an anonymous, opt-in, unique node identification mechanism to help counter this. This would give every node the opportunity to create a node ‘address’/unique identifier. This could even come in the form of a Bitcoin address. The node on first installation generates and backs up a private key. The corresponding public key becomes that node’s unique identifier. If the node switches to a new software version or a new IP, the identifier can remain constant if the node operator chooses. Asking a node for its identifier can be done by sending a message the command ‘identify’ and a challenge. The node can then respond with its unique identifier and a signature for the challenge to prove it. The node can also include what software it is running and sign this information so it can be verified as legitimate by third parties. Why would we do this? Well, it adds a small but very useful piece of data when compiling lists of active nodes. Any register of active nodes can have a record of when a node identifier was “first seen”, and how many IPs the same identifier has broadcast from. Also, crucially, we could see what software the node operator has been seen running historically. This information would make it easy to identify patterns. For example if a huge new group of nodes appeared on the network with no history for their identifier they could likely be dismissed as sybil attacks. If a huge number of nodes that had been reporting as Bitcoin Core for an extended period of time started switching to a rival implementation, this would add credibility but not certainty (keys could be traded), that the shift was more organic. This would be trivial to implement, is (to me?) non-controversial, and would give a way for a node to link itself to a pseudo-anonymous identity, but with the freedom to opt-out at any time. Keen to hear any thoughts? Thanks, John Hardy john@seebitcoin.com<mailto:john@seebitcoin•com> _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists•linuxfoundation.org> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Type: text/html, Size: 11530 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] Unique node identifiers 2017-03-04 16:04 [bitcoin-dev] Unique node identifiers John Hardy 2017-03-05 6:29 ` Marcel Jamin @ 2017-03-05 13:27 ` Btc Drak 2017-03-05 13:57 ` John Hardy 1 sibling, 1 reply; 16+ messages in thread From: Btc Drak @ 2017-03-05 13:27 UTC (permalink / raw) To: John Hardy, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3077 bytes --] Nodes are by design not supposed to be identifiable in any way, including persisting identities across IPs changes or when connecting over different networks (e.g. clearnet/tor). Anything that makes Bitcoin less private is a step backwards. Also absolute node count is pretty meaningless since only fully validating nodes that participate in economic activity really matter. As a side note, this should probably have started out as a bitcoin-discuss post. On Sat, Mar 4, 2017 at 4:04 PM, John Hardy via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > The discussion of UASF got me thinking about whether such a method might > lead to sybil attacks, with new nodes created purely to inflate the node > count for a particular implementation in an attempt at social engineering. > > I had an idea for an anonymous, opt-in, unique node identification > mechanism to help counter this. > > This would give every node the opportunity to create a node > ‘address’/unique identifier. This could even come in the form of a Bitcoin > address. > > The node on first installation generates and backs up a private key. The > corresponding public key becomes that node’s unique identifier. If the node > switches to a new software version or a new IP, the identifier can remain > constant if the node operator chooses. > > Asking a node for its identifier can be done by sending a message the > command ‘identify’ and a challenge. The node can then respond with its > unique identifier and a signature for the challenge to prove it. The node > can also include what software it is running and sign this information so > it can be verified as legitimate by third parties. > > Why would we do this? > > Well, it adds a small but very useful piece of data when compiling lists > of active nodes. > > Any register of active nodes can have a record of when a node identifier > was “first seen”, and how many IPs the same identifier has broadcast from. > Also, crucially, we could see what software the node operator has been seen > running historically. > > This information would make it easy to identify patterns. For example if a > huge new group of nodes appeared on the network with no history for their > identifier they could likely be dismissed as sybil attacks. If a huge > number of nodes that had been reporting as Bitcoin Core for an extended > period of time started switching to a rival implementation, this would add > credibility but not certainty (keys could be traded), that the shift was > more organic. > > This would be trivial to implement, is (to me?) non-controversial, and > would give a way for a node to link itself to a pseudo-anonymous identity, > but with the freedom to opt-out at any time. > > Keen to hear any thoughts? > > Thanks, > > John Hardy > > john@seebitcoin•com > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 6755 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] Unique node identifiers 2017-03-05 13:27 ` Btc Drak @ 2017-03-05 13:57 ` John Hardy 2017-03-07 18:44 ` Eric Voskuil 0 siblings, 1 reply; 16+ messages in thread From: John Hardy @ 2017-03-05 13:57 UTC (permalink / raw) To: Btc Drak, bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 4019 bytes --] > Nodes are by design not supposed to be identifiable in any way I feel you're conflating social identifiability with technical identifiability. Sure, a node operator must always be able to remain anonymous, but nodes themselves require a certain level of identifiability otherwise there would be no means to communicate between them. I agree that absolute node counts have their limitations, but that doesn't stop them being used as a measure and even propaganda tool. If something like this is a way to help highlight the latter when it is occurring I think it has value. I 'm not convinced that node identifiers or identity persistence would have any meaningful impact on privacy, though am open to being convinced otherwise. ________________________________ From: Btc Drak <btcdrak@gmail•com> Sent: Sunday, March 5, 2017 1:27 PM To: John Hardy; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Unique node identifiers Nodes are by design not supposed to be identifiable in any way, including persisting identities across IPs changes or when connecting over different networks (e.g. clearnet/tor). Anything that makes Bitcoin less private is a step backwards. Also absolute node count is pretty meaningless since only fully validating nodes that participate in economic activity really matter. As a side note, this should probably have started out as a bitcoin-discuss post. On Sat, Mar 4, 2017 at 4:04 PM, John Hardy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote: The discussion of UASF got me thinking about whether such a method might lead to sybil attacks, with new nodes created purely to inflate the node count for a particular implementation in an attempt at social engineering. I had an idea for an anonymous, opt-in, unique node identification mechanism to help counter this. This would give every node the opportunity to create a node ‘address’/unique identifier. This could even come in the form of a Bitcoin address. The node on first installation generates and backs up a private key. The corresponding public key becomes that node’s unique identifier. If the node switches to a new software version or a new IP, the identifier can remain constant if the node operator chooses. Asking a node for its identifier can be done by sending a message the command ‘identify’ and a challenge. The node can then respond with its unique identifier and a signature for the challenge to prove it. The node can also include what software it is running and sign this information so it can be verified as legitimate by third parties. Why would we do this? Well, it adds a small but very useful piece of data when compiling lists of active nodes. Any register of active nodes can have a record of when a node identifier was “first seen”, and how many IPs the same identifier has broadcast from. Also, crucially, we could see what software the node operator has been seen running historically. This information would make it easy to identify patterns. For example if a huge new group of nodes appeared on the network with no history for their identifier they could likely be dismissed as sybil attacks. If a huge number of nodes that had been reporting as Bitcoin Core for an extended period of time started switching to a rival implementation, this would add credibility but not certainty (keys could be traded), that the shift was more organic. This would be trivial to implement, is (to me?) non-controversial, and would give a way for a node to link itself to a pseudo-anonymous identity, but with the freedom to opt-out at any time. Keen to hear any thoughts? Thanks, John Hardy john@seebitcoin.com<mailto:john@seebitcoin•com> _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists•linuxfoundation.org> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Type: text/html, Size: 8625 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] Unique node identifiers 2017-03-05 13:57 ` John Hardy @ 2017-03-07 18:44 ` Eric Voskuil 2017-03-08 2:01 ` bfd 2017-03-08 19:47 ` Jonas Schnelli 0 siblings, 2 replies; 16+ messages in thread From: Eric Voskuil @ 2017-03-07 18:44 UTC (permalink / raw) To: John Hardy, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 4707 bytes --] > On Mar 5, 2017, at 5:57 AM, John Hardy via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > > > Nodes are by design not supposed to be identifiable in any way This is of course my objection to BIP150 ("a way for peers to ... guarantee node ownership"). > I feel you're conflating social identifiability with technical identifiability. Sure, a node operator must always be able to remain anonymous, but nodes themselves require a certain level of identifiability otherwise there would be no means to communicate between them. Anonymous node identity is pointless, and is why I object to BIP151. It provides no actual security/privacy benefit and is a stepping stone to non-anonymous node identity (e.g. BIP150). > I agree that absolute node counts have their limitations, but that doesn't stop them being used as a measure and even propaganda tool. If something like this is a way to help highlight the latter when it is occurring I think it has value. I 'm not convinced that node identifiers or identity persistence would have any meaningful impact on privacy, though am open to being convinced otherwise. Bitcoin does not require node counts, and this proposal is redundant with BIP150. e > > From: Btc Drak <btcdrak@gmail•com> > Sent: Sunday, March 5, 2017 1:27 PM > To: John Hardy; Bitcoin Protocol Discussion > Subject: Re: [bitcoin-dev] Unique node identifiers > > Nodes are by design not supposed to be identifiable in any way, including persisting identities across IPs changes or when connecting over different networks (e.g. clearnet/tor). Anything that makes Bitcoin less private is a step backwards. Also absolute node count is pretty meaningless since only fully validating nodes that participate in economic activity really matter. > > As a side note, this should probably have started out as a bitcoin-discuss post. > >> On Sat, Mar 4, 2017 at 4:04 PM, John Hardy via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: >> The discussion of UASF got me thinking about whether such a >> method might lead to sybil attacks, with new nodes created purely to inflate the node count for a particular implementation in an attempt at social engineering. >> >> I had an idea for an anonymous, opt-in, unique node identification >> mechanism to help counter this. >> >> This would give every node the opportunity to create a node >> ‘address’/unique identifier. This could even come in the form of a Bitcoin address. >> >> The node on first installation generates and backs up a private >> key. The corresponding public key becomes that node’s unique identifier. If the node switches to a new software version or a new IP, the identifier can remain constant if the node operator chooses. >> >> Asking a node for its identifier can be done by sending a message >> the command ‘identify’ and a challenge. The node can then respond with its unique identifier and a signature for the challenge to prove it. The node can also include what software it is running and sign this information so it can be verified as legitimate >> by third parties. >> >> Why would we do this? >> >> Well, it adds a small but very useful piece of data when compiling >> lists of active nodes. >> >> Any register of active nodes can have a record of when a node >> identifier was “first seen”, and how many IPs the same identifier has broadcast from. Also, crucially, we could see what software the node operator has been seen running historically. >> >> This information would make it easy to identify patterns. For >> example if a huge new group of nodes appeared on the network with no history for their identifier they could likely be dismissed as sybil attacks. If a huge number of nodes that had been reporting as Bitcoin Core for an extended period of time started switching >> to a rival implementation, this would add credibility but not certainty (keys could be traded), that the shift was more organic. >> >> This would be trivial to implement, is (to me?) non-controversial, >> and would give a way for a node to link itself to a pseudo-anonymous identity, but with the freedom to opt-out at any time. >> >> Keen to hear any thoughts? >> >> Thanks, >> >> John Hardy >> john@seebitcoin•com >> >> _______________________________________________ >> 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 [-- Attachment #2: Type: text/html, Size: 10365 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] Unique node identifiers 2017-03-07 18:44 ` Eric Voskuil @ 2017-03-08 2:01 ` bfd 2017-03-08 19:47 ` Jonas Schnelli 1 sibling, 0 replies; 16+ messages in thread From: bfd @ 2017-03-08 2:01 UTC (permalink / raw) To: bitcoin-dev >> I feel you're conflating social identifiability with technical >> identifiability. Sure, a node operator must always be able to remain >> anonymous, but nodes themselves require a certain level of >> identifiability otherwise there would be no means to communicate >> between them. Nodes running through networks like cjdns, onion, and i2p can effectively communicate with no knowledge of the counterparty whatsoever. Bitcoin does make an assumption that you are connected to at least one non-partitioned peer, and that there is a cost in having a large number of sybil nodes in many different ranges. Nothing says you have to do your communication exclusively on one network or another, so long as you have *some* source of information which is not partitioned. On 2017-03-08 05:44, Eric Voskuil via bitcoin-dev wrote: > On Mar 5, 2017, at 5:57 AM, John Hardy via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org> wrote: > >>> Nodes are by design not supposed to be identifiable in any way > > This is of course my objection to BIP150 ("a way for peers to ... > guarantee node ownership"). > >> I feel you're conflating social identifiability with technical >> identifiability. Sure, a node operator must always be able to remain >> anonymous, but nodes themselves require a certain level of >> identifiability otherwise there would be no means to communicate >> between them. > > Anonymous node identity is pointless, and is why I object to BIP151. > It provides no actual security/privacy benefit and is a stepping stone > to non-anonymous node identity (e.g. BIP150). > >> I agree that absolute node counts have their limitations, but that >> doesn't stop them being used as a measure and even propaganda tool. >> If something like this is a way to help highlight the latter when it >> is occurring I think it has value. I 'm not convinced that node >> identifiers or identity persistence would have any meaningful impact >> on privacy, though am open to being convinced otherwise. > > Bitcoin does not require node counts, and this proposal is redundant > with BIP150. > > e > >> ------------------------- >> >> FROM: Btc Drak <btcdrak@gmail•com> >> SENT: Sunday, March 5, 2017 1:27 PM >> TO: John Hardy; Bitcoin Protocol Discussion >> SUBJECT: Re: [bitcoin-dev] Unique node identifiers >> >> Nodes are by design not supposed to be identifiable in any way, >> including persisting identities across IPs changes or when >> connecting over different networks (e.g. clearnet/tor). Anything >> that makes Bitcoin less private is a step backwards. Also absolute >> node count is pretty meaningless since only fully validating nodes >> that participate in economic activity really matter. >> >> As a side note, this should probably have started out as a >> bitcoin-discuss post. >> >> On Sat, Mar 4, 2017 at 4:04 PM, John Hardy via bitcoin-dev >> <bitcoin-dev@lists•linuxfoundation.org> wrote: >> >>> The discussion of UASF got me thinking about whether such a method >>> might lead to sybil attacks, with new nodes created purely to >>> inflate the node count for a particular implementation in an >>> attempt at social engineering. >>> I had an idea for an anonymous, opt-in, unique node identification >>> mechanism to help counter this. >>> This would give every node the opportunity to create a node >>> ‘address’/unique identifier. This could even come in the form >>> of a Bitcoin address. >>> The node on first installation generates and backs up a private >>> key. The corresponding public key becomes that node’s unique >>> identifier. If the node switches to a new software version or a >>> new IP, the identifier can remain constant if the node operator >>> chooses. >>> Asking a node for its identifier can be done by sending a message >>> the command ‘identify’ and a challenge. The node can then >>> respond with its unique identifier and a signature for the >>> challenge to prove it. The node can also include what software it >>> is running and sign this information so it can be verified as >>> legitimate by third parties. >>> Why would we do this? >>> Well, it adds a small but very useful piece of data when compiling >>> lists of active nodes. >>> Any register of active nodes can have a record of when a node >>> identifier was “first seen”, and how many IPs the same >>> identifier has broadcast from. Also, crucially, we could see what >>> software the node operator has been seen running historically. >>> This information would make it easy to identify patterns. For >>> example if a huge new group of nodes appeared on the network with >>> no history for their identifier they could likely be dismissed as >>> sybil attacks. If a huge number of nodes that had been reporting >>> as Bitcoin Core for an extended period of time started switching >>> to a rival implementation, this would add credibility but not >>> certainty (keys could be traded), that the shift was more organic. >>> >>> This would be trivial to implement, is (to me?) non-controversial, >>> and would give a way for a node to link itself to a >>> pseudo-anonymous identity, but with the freedom to opt-out at any >>> time. >>> Keen to hear any thoughts? >>> Thanks, >>> John Hardy >>> >>> john@seebitcoin•com >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists•linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1] > >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > Links: > ------ > [1] 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] Unique node identifiers 2017-03-07 18:44 ` Eric Voskuil 2017-03-08 2:01 ` bfd @ 2017-03-08 19:47 ` Jonas Schnelli 2017-03-08 21:09 ` Eric Voskuil 2017-03-08 21:25 ` [bitcoin-dev] Unique node identifiers (and BIP150) Tom Zander 1 sibling, 2 replies; 16+ messages in thread From: Jonas Schnelli @ 2017-03-08 19:47 UTC (permalink / raw) To: Eric Voskuil, Bitcoin Protocol Discussion [-- Attachment #1.1: Type: text/plain, Size: 527 bytes --] > >> >> > Nodes are by design not supposed to be identifiable in any way > > This is of course my objection to BIP150 ("a way for peers to ... guarantee node ownership“). Please Eric. Stop spreading FUD. BIP150 has a fingerprint-free **OPTIONAL** authentication. It’s designed to not reveal any node identifier/identity without first get a crypto.-proof from other peer that he already knows your identity. **Peers can’t be identified without having the identity-keys pre shared by the node operators.** [-- Attachment #1.2: Type: text/html, Size: 2679 bytes --] [-- Attachment #2: Message signed with OpenPGP --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] Unique node identifiers 2017-03-08 19:47 ` Jonas Schnelli @ 2017-03-08 21:09 ` Eric Voskuil 2017-03-08 21:20 ` Jonas Schnelli 2017-03-08 21:25 ` [bitcoin-dev] Unique node identifiers (and BIP150) Tom Zander 1 sibling, 1 reply; 16+ messages in thread From: Eric Voskuil @ 2017-03-08 21:09 UTC (permalink / raw) To: Jonas Schnelli, Bitcoin Protocol Discussion; +Cc: Libbitcoin Development [-- Attachment #1: Type: text/plain, Size: 1426 bytes --] On 03/08/2017 11:47 AM, Jonas Schnelli wrote: >>> Nodes are by design not supposed to be identifiable in any way >> >> This is of course my objection to BIP150 ("a way for peers to ... >> guarantee node ownership“). > > Please Eric. Stop spreading FUD. I'm always willing to debate this issue. I'm generally a little suspicious of one who demands another person to stop arguing. I got at least one such demand (along with a threat) on this subject privately last summer from a notable Core dev. There is a lengthy thread on this subject in which I raised these issues. Everyone is free to review that discussion. > BIP150 has a fingerprint-free **OPTIONAL** authentication. It’s designed > to not reveal any node identifier/identity without first get a > crypto.-proof from other peer that he already knows your identity. > **Peers can’t be identified without having the identity-keys pre shared > by the node operators.** The "presharing" of keys is how provable identity works, and is precisely what this new proposal is also promoting. And in response to that, the above statement was made by a Core dev (and not disputed): >>> Nodes are by design not supposed to be identifiable in any way... I'm calling out the obvious relationship between BIP150 and this new proposal. Restating how identity works, or that its use is optional does not refute my position. It's not FUD. e [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] Unique node identifiers 2017-03-08 21:09 ` Eric Voskuil @ 2017-03-08 21:20 ` Jonas Schnelli 2017-03-08 23:12 ` Pieter Wuille 2017-03-09 1:08 ` Eric Voskuil 0 siblings, 2 replies; 16+ messages in thread From: Jonas Schnelli @ 2017-03-08 21:20 UTC (permalink / raw) To: Eric Voskuil; +Cc: Bitcoin Protocol Discussion, Libbitcoin Development [-- Attachment #1: Type: text/plain, Size: 1078 bytes --] > Am 08.03.2017 um 22:09 schrieb Eric Voskuil <eric@voskuil•org>: > > On 03/08/2017 11:47 AM, Jonas Schnelli wrote: >>>> Nodes are by design not supposed to be identifiable in any way >>> >>> This is of course my objection to BIP150 ("a way for peers to ... >>> guarantee node ownership“). >> >> Please Eric. Stop spreading FUD. > > I'm always willing to debate this issue. I'm generally a little > suspicious of one who demands another person to stop arguing. I got at > least one such demand (along with a threat) on this subject privately > last summer from a notable Core dev. There is a lengthy thread on this > subject in which I raised these issues. Everyone is free to review that > discussion. What you did say in the sentence above (and I think is FUD) is, that BIP150 will lead to every node being identifiable. This is just completely wrong. There is nothing to say against a technical debate (and we had this), but I will ask you to stop if I see you attacking BIP150/151 at every occasion with FUDish arguments like this. </jonas> [-- Attachment #2: Message signed with OpenPGP --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] Unique node identifiers 2017-03-08 21:20 ` Jonas Schnelli @ 2017-03-08 23:12 ` Pieter Wuille [not found] ` <6a5a6a8f-d689-260a-76a9-a91f6bda56c5@voskuil.org> 2017-03-09 1:08 ` Eric Voskuil 1 sibling, 1 reply; 16+ messages in thread From: Pieter Wuille @ 2017-03-08 23:12 UTC (permalink / raw) To: Jonas Schnelli, Bitcoin Protocol Discussion; +Cc: Libbitcoin Development On Wed, Mar 8, 2017 at 1:20 PM, Jonas Schnelli via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > >> Am 08.03.2017 um 22:09 schrieb Eric Voskuil <eric@voskuil•org>: >> >> On 03/08/2017 11:47 AM, Jonas Schnelli wrote: >>>>> Nodes are by design not supposed to be identifiable in any way >>>> >>>> This is of course my objection to BIP150 ("a way for peers to ... >>>> guarantee node ownership“). I believe this discussion is getting sidetracked. There is a difference between identification/fingerprinting (who are you?) and proving identity (prove that you are who I think you are?). BIP150 only facilitates the second, not the first. I don't think you disagree about that, but I want to make it clear for anyone else following the discussion. The question is whether it encourages people to establish known and pre-shared identities for nodes. Perhaps, but not in any way that IP/onion addresses don't already. Think about it: * If you know an IP/onion address, you can verify whether some node has it. If you know an IP/onion address + BIP150 PSK, you can verify whether some node has it. * If you know 2 IP/onion addresses, you cannot figure out whether they correspond to the same node (and if you can, that is a bug, not by design). If you know 2 (IP/onion addresses, BIP150 PSK) pairs, you cannot figure out whether they correspond to the same node (and if you can, that is a bug, not by design). * If you receive a connection from a node, you cannot know what their onion address is. If you receive a connection from a node, you cannot figure out what their PSK is. In that way, I see BIP150 as an extension of IP addresses, except more secure against network-level attackers. If you believe the concept of people establishing links along existing trust lines is a problem, you should be arguing against features in Bitcoin software that allows configuring preferred IP addresses to connect to as well (-addnode and -connect in Bitcoin Core, for example). Cheers, -- Pieter ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <6a5a6a8f-d689-260a-76a9-a91f6bda56c5@voskuil.org>]
* Re: [bitcoin-dev] Unique node identifiers [not found] ` <6a5a6a8f-d689-260a-76a9-a91f6bda56c5@voskuil.org> @ 2017-03-09 1:55 ` Pieter Wuille 2017-03-09 11:01 ` Aymeric Vitte 0 siblings, 1 reply; 16+ messages in thread From: Pieter Wuille @ 2017-03-09 1:55 UTC (permalink / raw) To: Eric Voskuil; +Cc: Bitcoin Protocol Discussion, Libbitcoin Development On Wed, Mar 8, 2017 at 5:16 PM, Eric Voskuil <eric@voskuil•org> wrote: > On 03/08/2017 03:12 PM, Pieter Wuille wrote: >> In that way, I see BIP150 as an extension of IP addresses, except more >> secure against network-level attackers. If you believe the concept of >> people establishing links along existing trust lines is a problem, you >> should be arguing against features in Bitcoin software that allows >> configuring preferred IP addresses to connect to as well (-addnode and >> -connect in Bitcoin Core, for example). > > Weak identity is insufficient to produce the problem scenario that is at > the heart of my concern (excluding people). It is this "[same] except > more secure" distinction that is the problem. You brush past that as if > it did not exist. So you're saying that a -onlyacceptconnectionsfrom=IP option wouldn't be a concern to you because it can't exclude people? Of course it can exclude people - just not your ISP or a state-level attacker. Please, Eric. I think I understand your concern, but this argument isn't constructive either. The proposal here is to introduce visible node identities on the network. I think that's misguided as node count is irrelevant and trivial to fake anyway. But you bringing up BIP150 here isn't useful either. I know that you equate the concept of having verifiable identity keys in the P2P with a step towards making every node identifiable, but they are not the same. It's just a cryptographic tool to keep a certain class of attackers from bypassing restrictions that people can already make. -- Pieter ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] Unique node identifiers 2017-03-09 1:55 ` Pieter Wuille @ 2017-03-09 11:01 ` Aymeric Vitte 0 siblings, 0 replies; 16+ messages in thread From: Aymeric Vitte @ 2017-03-09 11:01 UTC (permalink / raw) To: bitcoin-dev As stated in this thread and as I see it the use of BIP150 is optional, so if some parties want to trust each others and use it, then they can, if they don't like it and don't want to use it, then they don't use it Unless I misread, some statements in this thread involving the Tor network are wrong, the Tor network is a centralized network, each node (except the bridges) have a long term identity key and have to prove periodically to the authority servers that they are the owners of this key, if not the other nodes will never extend circuits to them, then they will be of course quite difficult to reach Unfortunately the original proposal starting this thread seems to be reinventing this system that probably can only lead to something centralized which cannot apply for the bitcoin network (the Tor network is centralized because the team want to control what is happening: sybils, bugs, attacks, blacklist etc) Unless some peers/nodes have decided to trust each others (BIP150) I don't think it's a good idea at all that bitcoin nodes have anything similar to long term nodeIDs (see https://gist.github.com/Ayms/aab6f8e08fef0792ab3448f542a826bf , already posted, not final, not finished, and the title does not really reflect what would be the proposal today, but it carefully avoids any possibility for a full node to have a long term ID) Le 09/03/2017 à 02:55, Pieter Wuille via bitcoin-dev a écrit : > On Wed, Mar 8, 2017 at 5:16 PM, Eric Voskuil <eric@voskuil•org> wrote: >> On 03/08/2017 03:12 PM, Pieter Wuille wrote: >>> In that way, I see BIP150 as an extension of IP addresses, except more >>> secure against network-level attackers. If you believe the concept of >>> people establishing links along existing trust lines is a problem, you >>> should be arguing against features in Bitcoin software that allows >>> configuring preferred IP addresses to connect to as well (-addnode and >>> -connect in Bitcoin Core, for example). >> Weak identity is insufficient to produce the problem scenario that is at >> the heart of my concern (excluding people). It is this "[same] except >> more secure" distinction that is the problem. You brush past that as if >> it did not exist. > So you're saying that a -onlyacceptconnectionsfrom=IP option wouldn't > be a concern to you because it can't exclude people? Of course it can > exclude people - just not your ISP or a state-level attacker. > > Please, Eric. I think I understand your concern, but this argument > isn't constructive either. > > The proposal here is to introduce visible node identities on the > network. I think that's misguided as node count is irrelevant and > trivial to fake anyway. But you bringing up BIP150 here isn't useful > either. I know that you equate the concept of having verifiable > identity keys in the P2P with a step towards making every node > identifiable, but they are not the same. It's just a cryptographic > tool to keep a certain class of attackers from bypassing restrictions > that people can already make. > -- Peersm : http://www.peersm.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] Unique node identifiers 2017-03-08 21:20 ` Jonas Schnelli 2017-03-08 23:12 ` Pieter Wuille @ 2017-03-09 1:08 ` Eric Voskuil 1 sibling, 0 replies; 16+ messages in thread From: Eric Voskuil @ 2017-03-09 1:08 UTC (permalink / raw) To: Jonas Schnelli; +Cc: Bitcoin Protocol Discussion, Libbitcoin Development [-- Attachment #1: Type: text/plain, Size: 3470 bytes --] On 03/08/2017 01:20 PM, Jonas Schnelli wrote: > >> Am 08.03.2017 um 22:09 schrieb Eric Voskuil <eric@voskuil•org>: >> >> On 03/08/2017 11:47 AM, Jonas Schnelli wrote: >>>>> Nodes are by design not supposed to be identifiable in any way >>>> >>>> This is of course my objection to BIP150 ("a way for peers to ... >>>> guarantee node ownership“). >>> >>> Please Eric. Stop spreading FUD. >> >> I'm always willing to debate this issue. I'm generally a little >> suspicious of one who demands another person to stop arguing. I got at >> least one such demand (along with a threat) on this subject privately >> last summer from a notable Core dev. There is a lengthy thread on this >> subject in which I raised these issues. Everyone is free to review that >> discussion. > What you did say in the sentence above (and I think is FUD) is, that BIP150 will lead to every node being identifiable. My argument against BIP150 (and 151) is based on the very real concern that it provides a built-in mechanism to partition the network (while also providing no meaningful privacy benefit). > This is just completely wrong. The only actual argument that I have seen from *anyone* to date is that this is *unlikely* to happen. That was specifically Pieter's position last summer. That argument is not technical but instead based on blind trust in people. The common refrain, which Pieter has penned again in a follow-up to this post, is that we already have identity in terms of IP addresses, so what's the harm. I find this argument ironic given that one of the arguments in favor of this proposal is that IP address identification is insufficient to establish identity. I assume that you both understand there is a very meaningful distinction between strong identity and weak identity. The other argument that is often given is that, because we are talking about privately shared as opposed to published identifiers, there is no reason for concern. This entirely misses the point. The ability to establish strong identity makes it trivial for someone to (strongly) require the identity of anyone with who he/she allows a connection. This is the *stated purpose* of BIP150. This turns the Bitcoin security model on its head. Instead of validating content this validates people. Given the current level of economic and hash power centralization it is not at all hard to imagine that through fear/consequences of regulatory controls or even poor scalability, that these points of centralization will eventually start by establishing private connections, and eventually require anyone connecting to them to "preshare" an identifier (which of course identifies the person). At that point Bitcoin P2P will have become a private network. I know you have the right motivation, but I do not understand why you would ignore this risk in exchange for a false sense of privacy. There is a very clear path to this happening. So please explain to me how this concern is "wrong". This is *not* a technical question, I know perfectly well how the scheme works. > There is nothing to say against a technical debate (and we had this), but I will ask you to stop if I see you attacking BIP150/151 at every occasion with FUDish arguments like this. Take a step back and consider that there may in fact be serious consequences to what you are proposing. Calling may arguments "attacking" and "FUD" is unproductive. e [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] Unique node identifiers (and BIP150) 2017-03-08 19:47 ` Jonas Schnelli 2017-03-08 21:09 ` Eric Voskuil @ 2017-03-08 21:25 ` Tom Zander 2017-03-08 21:31 ` Jonas Schnelli 1 sibling, 1 reply; 16+ messages in thread From: Tom Zander @ 2017-03-08 21:25 UTC (permalink / raw) To: bitcoin-dev, Jonas Schnelli On Wednesday, 8 March 2017 20:47:54 CET Jonas Schnelli via bitcoin-dev wrote: > Please Eric. Stop spreading FUD. > BIP150 has a fingerprint-free **OPTIONAL** authentication. It’s designed > to not reveal any node identifier/identity without first get a > crypto.-proof from other peer that he already knows your identity. > **Peers can’t be identified without having the identity-keys pre shared > by the node operators.** Do you know the trick of having an open wifi basestation in a public street and how that can lead to tracking? Especially if you have a network of them. The trick is this; you set up an open wifi base station with a hidden ssid and phones try to connect to it by saying “Are you ssid=xyz?” This leads the basestation to know that the phone has known credentials with another wifi that has a specific ssid. (the trick is slightly more elaborate, but the basics are relevant here). Your BIP is vulnarable to the same issue, as a node wants to connect using the AUTHCHALLENGE which has as an argument the hash of the person I’m trying to connect with. Your BIP says "Fingerprinting the requesting peer is not possible”. Unfortunately, this is wrong. Yes the peer is trivial to fingerprint. Your hash never changes and as you connect to a node anyone listening can see you sending the same hash on every connect to that peer, whereever you are or connect from. Just like the wifi hack. I think you want to use industry standards instead, and a good start may be https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] Unique node identifiers (and BIP150) 2017-03-08 21:25 ` [bitcoin-dev] Unique node identifiers (and BIP150) Tom Zander @ 2017-03-08 21:31 ` Jonas Schnelli 0 siblings, 0 replies; 16+ messages in thread From: Jonas Schnelli @ 2017-03-08 21:31 UTC (permalink / raw) To: Tom Zander; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1320 bytes --] Hi Tom > Do you know the trick of having an open wifi basestation in a public street > and how that can lead to tracking? Especially if you have a network of them. > The trick is this; you set up an open wifi base station with a hidden ssid > and phones try to connect to it by saying “Are you ssid=xyz?” > This leads the basestation to know that the phone has known credentials with > another wifi that has a specific ssid. (the trick is slightly more elaborate, > but the basics are relevant here). > > Your BIP is vulnarable to the same issue, as a node wants to connect using > the AUTHCHALLENGE which has as an argument the hash of the person I’m trying > to connect with. This thread is not about BIP150/151. The hash includes the encryption session which makes it impossible to distinct identities. > > Your BIP says "Fingerprinting the requesting peer is not possible”. > Unfortunately, this is wrong. Yes the peer is trivial to fingerprint. Your > hash never changes and as you connect to a node anyone listening can see you > sending the same hash on every connect to that peer, whereever you are or > connect from. Not true. The hash includes the encryption session which is based on a ephemeral ECDH/HKDF per connection-session. Have you read the BIP? </jonas> [-- Attachment #2: Message signed with OpenPGP --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2017-03-09 11:02 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-04 16:04 [bitcoin-dev] Unique node identifiers John Hardy
2017-03-05 6:29 ` Marcel Jamin
2017-03-05 12:55 ` John Hardy
2017-03-05 13:27 ` Btc Drak
2017-03-05 13:57 ` John Hardy
2017-03-07 18:44 ` Eric Voskuil
2017-03-08 2:01 ` bfd
2017-03-08 19:47 ` Jonas Schnelli
2017-03-08 21:09 ` Eric Voskuil
2017-03-08 21:20 ` Jonas Schnelli
2017-03-08 23:12 ` Pieter Wuille
[not found] ` <6a5a6a8f-d689-260a-76a9-a91f6bda56c5@voskuil.org>
2017-03-09 1:55 ` Pieter Wuille
2017-03-09 11:01 ` Aymeric Vitte
2017-03-09 1:08 ` Eric Voskuil
2017-03-08 21:25 ` [bitcoin-dev] Unique node identifiers (and BIP150) Tom Zander
2017-03-08 21:31 ` Jonas Schnelli
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox