📅 Original date posted:2017-03-08
📝 Original message:>> 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 at 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 at 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 at 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 at seebitcoin.com
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1]
>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
bfd at cock.lu [ARCHIVE] /
npub1md…gy6y7
2023-06-07 17:56:58
in reply to nevent1q…tnze
Author Public Key
npub1mdmqmt0prpddcexkljfzd40uf7nvrc56c7gsg2spn3lgcjghguxqwgy6y7Published at
2023-06-07 17:56:58Event JSON
{
"id": "8034fa3e9602cf45bbd5bffef6e6e9b22b86bd1a90b0e95e3a6ad413e94c7fdc",
"pubkey": "db760dade1185adc64d6fc9226d5fc4fa6c1e29ac791042a019c7e8c4917470c",
"created_at": 1686160618,
"kind": 1,
"tags": [
[
"e",
"9dd5ee30e00a8982beef06bc0de72f4df99da3649e3263091c6819d269e9eb1c",
"",
"root"
],
[
"e",
"9e3157bd1d3fb34e7cbb93ef8f12f903733256e05e3d55012c82e4635bb127c6",
"",
"reply"
],
[
"p",
"82205f272f995d9be742779a3c19a2ae08522ca14824c3a3b01525fb5459161e"
]
],
"content": "📅 Original date posted:2017-03-08\n📝 Original message:\u003e\u003e I feel you're conflating social identifiability with technical\n\u003e\u003e identifiability. Sure, a node operator must always be able to remain\n\u003e\u003e anonymous, but nodes themselves require a certain level of\n\u003e\u003e identifiability otherwise there would be no means to communicate\n\u003e\u003e between them.\n\nNodes running through networks like cjdns, onion, and i2p can\neffectively communicate with no knowledge of the counterparty\nwhatsoever. Bitcoin does make an assumption that you are connected to\nat least one non-partitioned peer, and that there is a cost in having\na large number of sybil nodes in many different ranges. Nothing\nsays you have to do your communication exclusively on one network or\nanother, so long as you have *some* source of information which is not\npartitioned.\n\n\n\nOn 2017-03-08 05:44, Eric Voskuil via bitcoin-dev wrote:\n\u003e On Mar 5, 2017, at 5:57 AM, John Hardy via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e\u003e\u003e Nodes are by design not supposed to be identifiable in any way\n\u003e \n\u003e This is of course my objection to BIP150 (\"a way for peers to ...\n\u003e guarantee node ownership\").\n\u003e \n\u003e\u003e I feel you're conflating social identifiability with technical\n\u003e\u003e identifiability. Sure, a node operator must always be able to remain\n\u003e\u003e anonymous, but nodes themselves require a certain level of\n\u003e\u003e identifiability otherwise there would be no means to communicate\n\u003e\u003e between them.\n\u003e \n\u003e Anonymous node identity is pointless, and is why I object to BIP151.\n\u003e It provides no actual security/privacy benefit and is a stepping stone\n\u003e to non-anonymous node identity (e.g. BIP150).\n\u003e \n\u003e\u003e I agree that absolute node counts have their limitations, but that\n\u003e\u003e doesn't stop them being used as a measure and even propaganda tool.\n\u003e\u003e If something like this is a way to help highlight the latter when it\n\u003e\u003e is occurring I think it has value. I 'm not convinced that node\n\u003e\u003e identifiers or identity persistence would have any meaningful impact\n\u003e\u003e on privacy, though am open to being convinced otherwise.\n\u003e \n\u003e Bitcoin does not require node counts, and this proposal is redundant\n\u003e with BIP150.\n\u003e \n\u003e e\n\u003e \n\u003e\u003e -------------------------\n\u003e\u003e \n\u003e\u003e FROM: Btc Drak \u003cbtcdrak at gmail.com\u003e\n\u003e\u003e SENT: Sunday, March 5, 2017 1:27 PM\n\u003e\u003e TO: John Hardy; Bitcoin Protocol Discussion\n\u003e\u003e SUBJECT: Re: [bitcoin-dev] Unique node identifiers\n\u003e\u003e \n\u003e\u003e Nodes are by design not supposed to be identifiable in any way,\n\u003e\u003e including persisting identities across IPs changes or when\n\u003e\u003e connecting over different networks (e.g. clearnet/tor). Anything\n\u003e\u003e that makes Bitcoin less private is a step backwards. Also absolute\n\u003e\u003e node count is pretty meaningless since only fully validating nodes\n\u003e\u003e that participate in economic activity really matter.\n\u003e\u003e \n\u003e\u003e As a side note, this should probably have started out as a\n\u003e\u003e bitcoin-discuss post.\n\u003e\u003e \n\u003e\u003e On Sat, Mar 4, 2017 at 4:04 PM, John Hardy via bitcoin-dev\n\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e \n\u003e\u003e\u003e The discussion of UASF got me thinking about whether such a method\n\u003e\u003e\u003e might lead to sybil attacks, with new nodes created purely to\n\u003e\u003e\u003e inflate the node count for a particular implementation in an\n\u003e\u003e\u003e attempt at social engineering.\n\u003e\u003e\u003e I had an idea for an anonymous, opt-in, unique node identification\n\u003e\u003e\u003e mechanism to help counter this.\n\u003e\u003e\u003e This would give every node the opportunity to create a node\n\u003e\u003e\u003e ‘address’/unique identifier. This could even come in the form\n\u003e\u003e\u003e of a Bitcoin address.\n\u003e\u003e\u003e The node on first installation generates and backs up a private\n\u003e\u003e\u003e key. The corresponding public key becomes that node’s unique\n\u003e\u003e\u003e identifier. If the node switches to a new software version or a\n\u003e\u003e\u003e new IP, the identifier can remain constant if the node operator\n\u003e\u003e\u003e chooses.\n\u003e\u003e\u003e Asking a node for its identifier can be done by sending a message\n\u003e\u003e\u003e the command ‘identify’ and a challenge. The node can then\n\u003e\u003e\u003e respond with its unique identifier and a signature for the\n\u003e\u003e\u003e challenge to prove it. The node can also include what software it\n\u003e\u003e\u003e is running and sign this information so it can be verified as\n\u003e\u003e\u003e legitimate by third parties.\n\u003e\u003e\u003e Why would we do this?\n\u003e\u003e\u003e Well, it adds a small but very useful piece of data when compiling\n\u003e\u003e\u003e lists of active nodes.\n\u003e\u003e\u003e Any register of active nodes can have a record of when a node\n\u003e\u003e\u003e identifier was “first seen”, and how many IPs the same\n\u003e\u003e\u003e identifier has broadcast from. Also, crucially, we could see what\n\u003e\u003e\u003e software the node operator has been seen running historically.\n\u003e\u003e\u003e This information would make it easy to identify patterns. For\n\u003e\u003e\u003e example if a huge new group of nodes appeared on the network with\n\u003e\u003e\u003e no history for their identifier they could likely be dismissed as\n\u003e\u003e\u003e sybil attacks. If a huge number of nodes that had been reporting\n\u003e\u003e\u003e as Bitcoin Core for an extended period of time started switching\n\u003e\u003e\u003e to a rival implementation, this would add credibility but not\n\u003e\u003e\u003e certainty (keys could be traded), that the shift was more organic.\n\u003e\u003e\u003e \n\u003e\u003e\u003e This would be trivial to implement, is (to me?) non-controversial,\n\u003e\u003e\u003e and would give a way for a node to link itself to a\n\u003e\u003e\u003e pseudo-anonymous identity, but with the freedom to opt-out at any\n\u003e\u003e\u003e time.\n\u003e\u003e\u003e Keen to hear any thoughts?\n\u003e\u003e\u003e Thanks,\n\u003e\u003e\u003e John Hardy\n\u003e\u003e\u003e \n\u003e\u003e\u003e john at seebitcoin.com\n\u003e\u003e\u003e \n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1]\n\u003e \n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n\u003e \n\u003e Links:\n\u003e ------\n\u003e [1] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "e6d2ae081e1d339eb5eacf3f93ebb56910af19636ccd5630627b495ee82872263221eac1934100195bd85c87fc7105c1806720f5823f05f2dc6f7d67426e926a"
}