Michael Grønager [ARCHIVE] on Nostr: 📅 Original date posted:2011-12-22 🗒️ Summary of this message: A decentralized ...
📅 Original date posted:2011-12-22
🗒️ Summary of this message: A decentralized system where every node randomly chooses whether to verify any particular transaction, with negative-announce transactions to flag invalid ones.
📝 Original message:It is analog to getting assigned a random part (based on IP) of the hashspace and then only verify transactions within this fraction.
But, there is in fact a subtle difference: If anyone can choose to verify at random, you will see lazy implementations where random means none, and as it is random you cannot, from the outside, judge if a node is taking part in the validation work or if it just benefitting from others announcements. In the hash space part, you can monitor peers and see if they did not tell you about a failed validation and then disconnect from them as they are either malicious or lazy.
Besides from that, I like a setup where we scream about failed verifications, but keep a low profile on things that actually verifies...
/M
On 22/12/2011, at 11:12, Andy Parkins wrote:
> On 2011 December 21 Wednesday, Christian Decker wrote:
>
>> Supernodes will be those nodes that verify all transactions and make them
>> available to miners. Since miners will become more and more specialized
>> these supernodes are likely to be owned by the miners themself. To be a
>> miner either you need to verify all the transactions you include (otherwise
>> others might be able to find an error in your block and thus drop it) or
>> have someone that verifies them for you. In the end I think we'll end up
>> with a hierarchical network, with the miners/supernodes tighly
>> interconnected at the top and the lightweight clients that simply verify
>> transactions (or their inputs to be precise) that are destined for them at
>> the bottom.
>
> A thought occurred to me. We already run a decentralised system, but it's
> done by making everyone duplicate all other work. There is no fundamental
> reason why all work needs to be duplicated though. What about this: every
> node randomly chooses whether to verify any particular transaction. If we
> assume the network is large and the random factor is correctly chosen, then we
> can still guarantee that every transaction is verified. Then, we simply add a
> protocol message that is a negative-announce transaction. That is to say, we
> give nodes a way of telling other nodes that they think a transaction is
> invalid. The other nodes are then free to verify _that_ assertion and forward
> the negative-announce.
>
> Miners can then listen for negative-announcements and use them to decide were
> to dedicate their verification efforts. They then don't need to verify all
> (or perhaps even any) transactions themselves and can dedicate their
> processing power to mining.
>
> (I've actually mentioned this idea before, but that time I was using it as a
> double-spend prevention method).
>
>
>
> Andy
>
> --
> Dr Andy Parkins
> andyparkins at gmail.com
Published at
2023-06-07 02:50:35Event JSON
{
"id": "c2c14b81b8fa5a3dccc9a371744d386a92991030bfbc1a9bae91216eebacd48c",
"pubkey": "a277336e95d2d0a831fff67fc80d8082322689a88ede9f877fa246a02629a43f",
"created_at": 1686106235,
"kind": 1,
"tags": [
[
"e",
"4af0205fae641367dcfd78e02a7a0b6f75f880a1f702affe5d70f7b792eb8207",
"",
"root"
],
[
"e",
"55145b0817aad4a0d8768deb460f74a41545a3f4433bf6fb5f4148e1a0b758ef",
"",
"reply"
],
[
"p",
"99bec497728c848e65549d1a5257d08de97621edcb4b77073269a45dac708d59"
]
],
"content": "📅 Original date posted:2011-12-22\n🗒️ Summary of this message: A decentralized system where every node randomly chooses whether to verify any particular transaction, with negative-announce transactions to flag invalid ones.\n📝 Original message:It is analog to getting assigned a random part (based on IP) of the hashspace and then only verify transactions within this fraction.\n\nBut, there is in fact a subtle difference: If anyone can choose to verify at random, you will see lazy implementations where random means none, and as it is random you cannot, from the outside, judge if a node is taking part in the validation work or if it just benefitting from others announcements. In the hash space part, you can monitor peers and see if they did not tell you about a failed validation and then disconnect from them as they are either malicious or lazy.\n\nBesides from that, I like a setup where we scream about failed verifications, but keep a low profile on things that actually verifies...\n\n/M\n\n\nOn 22/12/2011, at 11:12, Andy Parkins wrote:\n\n\u003e On 2011 December 21 Wednesday, Christian Decker wrote:\n\u003e \n\u003e\u003e Supernodes will be those nodes that verify all transactions and make them\n\u003e\u003e available to miners. Since miners will become more and more specialized\n\u003e\u003e these supernodes are likely to be owned by the miners themself. To be a\n\u003e\u003e miner either you need to verify all the transactions you include (otherwise\n\u003e\u003e others might be able to find an error in your block and thus drop it) or\n\u003e\u003e have someone that verifies them for you. In the end I think we'll end up\n\u003e\u003e with a hierarchical network, with the miners/supernodes tighly\n\u003e\u003e interconnected at the top and the lightweight clients that simply verify\n\u003e\u003e transactions (or their inputs to be precise) that are destined for them at\n\u003e\u003e the bottom.\n\u003e \n\u003e A thought occurred to me. We already run a decentralised system, but it's \n\u003e done by making everyone duplicate all other work. There is no fundamental \n\u003e reason why all work needs to be duplicated though. What about this: every \n\u003e node randomly chooses whether to verify any particular transaction. If we \n\u003e assume the network is large and the random factor is correctly chosen, then we \n\u003e can still guarantee that every transaction is verified. Then, we simply add a \n\u003e protocol message that is a negative-announce transaction. That is to say, we \n\u003e give nodes a way of telling other nodes that they think a transaction is \n\u003e invalid. The other nodes are then free to verify _that_ assertion and forward \n\u003e the negative-announce.\n\u003e \n\u003e Miners can then listen for negative-announcements and use them to decide were \n\u003e to dedicate their verification efforts. They then don't need to verify all \n\u003e (or perhaps even any) transactions themselves and can dedicate their \n\u003e processing power to mining.\n\u003e \n\u003e (I've actually mentioned this idea before, but that time I was using it as a \n\u003e double-spend prevention method).\n\u003e \n\u003e \n\u003e \n\u003e Andy\n\u003e \n\u003e -- \n\u003e Dr Andy Parkins\n\u003e andyparkins at gmail.com",
"sig": "d8cc226e2c534217e1dd107435645cdb8f5bf0887d2f4213694294d830ca9738ce040df335c442cb4bf7add1975daeda480c9ae9bb9e12d5cbaacd4720b49b23"
}