📅 Original date posted:2017-01-28
📝 Original message:Den 28 jan. 2017 05:04 skrev "Luke Dashjr via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org>:
Satoshi envisioned a system where full nodes could publish proofs of invalid
blocks that would be automatically verified by SPV nodes and used to ensure
even they maintained the equivalent of full node security so long as they
were
not isolated. But as a matter of fact, this vision has proven impossible,
and
there is to date no viable theory on how it might be fixed. As a result, the
only way for nodes to have full-node-security is to actually be a true full
node, and therefore the plan of only having full nodes in datacenters is
simply not realistic without transforming Bitcoin into a centralised system.
Beside Zero-knowledge proofs, which is capable of proving much so more than
just validity, there are multi types of fraud proofs that only rely on the
format of the blocks. Such as publishing the block header + the two
colliding transactions included in it (in the case of double spending), or
if the syntax or logic is broken then you just publish that single
transaction.
There aren't all that many cases where fraud proofs are unreasonably large
for a networked system like in Bitcoin. If Zero-knowledge proofs can be
applied securely, then I can't think of any exceptions at all for when the
proofs would be unmanageable. (Remember that full Zero-knowledge proofs can
be chained together!)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170128/faab5c67/attachment.html>;
Natanael [ARCHIVE] /
npub179…lpmjt
2023-06-07 17:55:50
in reply to nevent1q…7aey
Author Public Key
npub1798ncudyucap9jzzujjsgufx8tdykm8auzfledjcs6f6wf4ekqvq8lpmjtPublished at
2023-06-07 17:55:50Event JSON
{
"id": "18f0ace9c627d6a9c7e6171c55a5d07165a08f3cfac8d14fc4bedb875f36318d",
"pubkey": "f14f3c71a4e63a12c842e4a50471263ada4b6cfde093fcb6588693a726b9b018",
"created_at": 1686160550,
"kind": 1,
"tags": [
[
"e",
"b64df2ffa5964ebc2c2494c8a737d0410a8afb40f32e18bcfc4123842c995495",
"",
"root"
],
[
"e",
"0c09927f017beda8ec25254170bb506482b824490ad068cf3c271ab0638cd2d9",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 Original date posted:2017-01-28\n📝 Original message:Den 28 jan. 2017 05:04 skrev \"Luke Dashjr via bitcoin-dev\" \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e:\n\nSatoshi envisioned a system where full nodes could publish proofs of invalid\nblocks that would be automatically verified by SPV nodes and used to ensure\neven they maintained the equivalent of full node security so long as they\nwere\nnot isolated. But as a matter of fact, this vision has proven impossible,\nand\nthere is to date no viable theory on how it might be fixed. As a result, the\nonly way for nodes to have full-node-security is to actually be a true full\nnode, and therefore the plan of only having full nodes in datacenters is\nsimply not realistic without transforming Bitcoin into a centralised system.\n\n\nBeside Zero-knowledge proofs, which is capable of proving much so more than\njust validity, there are multi types of fraud proofs that only rely on the\nformat of the blocks. Such as publishing the block header + the two\ncolliding transactions included in it (in the case of double spending), or\nif the syntax or logic is broken then you just publish that single\ntransaction.\n\nThere aren't all that many cases where fraud proofs are unreasonably large\nfor a networked system like in Bitcoin. If Zero-knowledge proofs can be\napplied securely, then I can't think of any exceptions at all for when the\nproofs would be unmanageable. (Remember that full Zero-knowledge proofs can\nbe chained together!)\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170128/faab5c67/attachment.html\u003e",
"sig": "293ae375e69c85821dd35aa3c7e9907574cca0e97957e55188b45aa0bf918a1b3e9df69581016115a156c1e4e2e49402f5e610395f63143da45687eaac52405d"
}