* [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; 17+ 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] 17+ 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; 17+ 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] 17+ 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; 17+ 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] 17+ 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; 17+ 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] 17+ 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; 17+ 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] 17+ 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; 17+ 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] 17+ 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; 17+ 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] 17+ 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; 17+ 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] 17+ 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; 17+ 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] 17+ 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; 17+ 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] 17+ 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; 17+ 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] 17+ 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; 17+ 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] 17+ 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; 17+ 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] 17+ 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; 17+ 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] 17+ messages in thread
* 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; 17+ 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] 17+ 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; 17+ 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] 17+ messages in thread
* Re: [bitcoin-dev] Unique node identifiers
[not found] <7c5020dd-5259-9954-7bf1-06fa98124f8f@voskuil.org>
@ 2017-03-22 0:04 ` Eric Voskuil
0 siblings, 0 replies; 17+ messages in thread
From: Eric Voskuil @ 2017-03-22 0:04 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Reposting this response since this made it neither to distribution nor
to the moderation archive.
- -------- Forwarded Message --------
Subject: Re: [bitcoin-dev] Unique node identifiers
Date: Wed, 8 Mar 2017 18:59:42 -0800
From: Eric Voskuil <eric@voskuil•org>
To: Pieter Wuille <pieter.wuille@gmail•com>
CC: Jonas Schnelli <dev@jonasschnelli•ch>, Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>, Libbitcoin Development
<libbitcoin@lists•dyne.org>
On 03/08/2017 05:55 PM, Pieter Wuille wrote:
> 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.
You seem to look at this from only one perspective. Put yourself on the
other end of the wire (web wallets, APIs, exchanges, miners). Is an IP
address strong enough for them to prove to the state that they are
getting connections only from authorized "customers" that they know? Is
it sufficient for them that they may think they know their customer but
in reality it may be some ISP spoofing their customer (or some state)?
Obviously it is not sufficient, which is why IP addresses do not produce
this problem. They will need another mechanism, and BIP150 just happens
to be it.
> Please, Eric. I think I understand your concern,
I assume you do. The question is ultimately whether the P2P protocol is
an anonymous network of public information or it is a private network
(of private information). Too many arguments have been based on the idea
that the information is private (bloom filters, tainting). There are
anonymizing networks, Bitcoin P2P is not one of them.
Consensus rules exist to validate information obtained from the
anonymous public. That includes your ISP and the state. The rules
validate everything that matters except whether there is a stronger
chain - and seeing the strongest chain cannot be guaranteed by
encryption, unless of course we are all strongly tied to the majority
hash power and trust them.
Making the network private so that we can detect denial/disruption of
service is pointless if the the only threat is your own ISP or the state
.
> but this argument isn't constructive either.
I don't need to continue it, I've made my case. It's up to others to
decide whether it has been constructive and what to do with it. I hope
it is understood that I do not question the motivation of anyone involve
d.
> 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.
Agreed.
> I know that you equate the concept of having verifiable identity
> keys in the P2P with a step towards making every node
> identifiable,
There is no question that is a step toward making every person who
connects to the more centralized network identifiable. The next step
doesn't even require a software change. A "bitcoin provider" will only
need to provide you a secret to use when connecting. And they have every
reason to want to control this access.
e
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBCAAGBQJY0b+SAAoJEDzYwH8LXOFOzskH/Ak4xTVWuY02dpA7Xcna0/lG
pLCYz5aFOoCRDokHf2uxtZptNaXMcz5eNBwhxRyXL9cMQ1ewME9nWDiM0x7Is0zC
0haiFW1bi81Tak6ELhA7+BwCQNYH4MBWirFo/T91veiaOx3Ttn5Nf8p+kYfbcvCC
eANxCsPM8s9ul7CzpfDtO+K7S9rV/mEZYDsogKT7P3JPbgH4kRWcyt1AcFfw74LU
Z68XkZL6aCl+nymupZR72z/oxykljjPegkZxIkoguNSybZR9dOLRRmkyiPplX+OU
szOlGnwuePxOq/BQE8ouAlfSgAmBHqMj6lnYCgbBUIWrTzjYlpZVA4dWTj/FVCM=
=um+z
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2017-03-22 0:04 UTC | newest]
Thread overview: 17+ 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
[not found] <7c5020dd-5259-9954-7bf1-06fa98124f8f@voskuil.org>
2017-03-22 0:04 ` [bitcoin-dev] Unique node identifiers Eric Voskuil
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox