📅 Original date posted:2017-05-08
📝 Original message:Den 8 maj 2017 23:01 skrev "Sergio Demian Lerner via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org>:
I'll soon present a solution to encourage full nodes to store the
blockchain based on Proof-of-Unique-Blockchain-Storage (PoUBS)
Proving that you're holding your own copy of the blockchain, not shared
with other nodes? I don't think that's possible to do securely. It falls on
that the whole blockchain is both public and static, while any such proof
of independence needs to rely on unique capabilities per node.
All you can do with a challenge-response protocol is to prevent honest
nodes from being unwitting backends to dishonest transparent proxy nodes
(by binding the challenge to cryptographic node identities).
Even latency bounding protocols can't stop you from putting multiple
*seemingly independent* nodes in front of the same backend with one single
copy of the blockchain.
I believe best you can do is to force somebody to hold multiple copies
locally on multiple hardware units to not run out of memory I/O when
creating proofs for multiple remote nodes, through using memory heavy
functions for the proof of storage, forcing quick random access. However
somebody willing to put enough RAM in a server rack to hold the full
blockchain could still easily pretend to be multiple regular nodes with
independent copies.
Any kind of attempt at forcing the full copy of the blockchain to be in
memory close to the CPU will either rule out most nodes from passing or
will be cheatable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170508/fd49c403/attachment-0001.html>;
Natanael [ARCHIVE] /
npub179…lpmjt
2023-06-07 18:00:48
in reply to nevent1q…xsj3
Author Public Key
npub1798ncudyucap9jzzujjsgufx8tdykm8auzfledjcs6f6wf4ekqvq8lpmjtPublished at
2023-06-07 18:00:48Event JSON
{
"id": "45a64cc7d384dbc2d51d53a74141c5c710e0e237af3f567dd865f12f723fbc31",
"pubkey": "f14f3c71a4e63a12c842e4a50471263ada4b6cfde093fcb6588693a726b9b018",
"created_at": 1686160848,
"kind": 1,
"tags": [
[
"e",
"f1a95efbdac6335d0cd6694de02881d5a2d41c381de623952606610046b1a5ed",
"",
"root"
],
[
"e",
"4398bcd9b8bc6aaf0ecda408b9bb2161688090ace9bae9506092a0970868fceb",
"",
"reply"
],
[
"p",
"4b38603408f5be002091210e869a4ca86fc2aa1ffd0871036a0668068ee626ee"
]
],
"content": "📅 Original date posted:2017-05-08\n📝 Original message:Den 8 maj 2017 23:01 skrev \"Sergio Demian Lerner via bitcoin-dev\" \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e:\n\nI'll soon present a solution to encourage full nodes to store the\nblockchain based on Proof-of-Unique-Blockchain-Storage (PoUBS)\n\n\nProving that you're holding your own copy of the blockchain, not shared\nwith other nodes? I don't think that's possible to do securely. It falls on\nthat the whole blockchain is both public and static, while any such proof\nof independence needs to rely on unique capabilities per node.\n\nAll you can do with a challenge-response protocol is to prevent honest\nnodes from being unwitting backends to dishonest transparent proxy nodes\n(by binding the challenge to cryptographic node identities).\n\nEven latency bounding protocols can't stop you from putting multiple\n*seemingly independent* nodes in front of the same backend with one single\ncopy of the blockchain.\n\nI believe best you can do is to force somebody to hold multiple copies\nlocally on multiple hardware units to not run out of memory I/O when\ncreating proofs for multiple remote nodes, through using memory heavy\nfunctions for the proof of storage, forcing quick random access. However\nsomebody willing to put enough RAM in a server rack to hold the full\nblockchain could still easily pretend to be multiple regular nodes with\nindependent copies.\n\nAny kind of attempt at forcing the full copy of the blockchain to be in\nmemory close to the CPU will either rule out most nodes from passing or\nwill be cheatable.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170508/fd49c403/attachment-0001.html\u003e",
"sig": "2a58fdedb6dca904df9126673e850d671af9cf78cece62db99de6d548dd87bb4de7ad96b8c6bc2d4b056496f0fc90f65d250d63fc3a9b95b1538ed29abac461d"
}