What is Nostr?
Andy Parkins [ARCHIVE] /
npub1nxl…wjrv
2023-06-07 02:50:39
in reply to nevent1q…xah0

Andy Parkins [ARCHIVE] on Nostr: 📅 Original date posted:2011-12-22 🗒️ Summary of this message: A node should ...

📅 Original date posted:2011-12-22
🗒️ Summary of this message: A node should not be forced to do any work it doesn't want to, but it should be truthful about the work it chooses to do.
📝 Original message:On 2011 December 22 Thursday, Michael Grønager wrote:

> 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.

Why should they have to? Joining the network as a node is very low cost to
the other nodes. You can't force any node not to be lazy, since their option
is to disconnect themselves. As to maliciousness, that is defended against
because when a node negative announces a transaction, that transaction is
going to be checked (note that there is still no implicit trust) -- if a node
is incorrectly negative-announcing then it can justifiably be kicked.

> Besides from that, I like a setup where we scream about failed
> verifications, but keep a low profile on things that actually verifies...

Me too. It's important though to distinguish between "you must be verifying"
and "if you do verify, you must be honest about it". No node should be forced
to do any work it doesn't want to; but they should be forced to be truthful
about the work they choose to do.



Andy

--
Dr Andy Parkins
andyparkins at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111222/c6e7a6da/attachment.sig>;
Author Public Key
npub1nxlvf9mj3jzgue25n5d9y47s3h5hvg0ded9hwpejdxj9mtrs34vs97wjrv