📅 Original date posted:2011-12-22
🗒️ Summary of this message: Nodes in a network have the option to choose what work to do, and should have a way of forwarding the results of that work to other nodes. Transaction verification is the main one. However, it requires a web of trust as well as a web of connections.
📝 Original message:On 2011 December 22 Thursday, Joel Joonatan Kaartinen wrote:
> On Thu, 2011-12-22 at 11:52 +0000, Andy Parkins wrote:
> > 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.
>
> a node that is not doing any checking themselves can not reliably
> forward failed verifications without getting the blame for doing faulty
> work. Those nodes would then have the incentive not to relay the failed
> verifications. This ends up making it important to know which nodes will
> be checking transactions or not so you don't isolate yourself from other
> nodes that are also checking transactions.
Yes; I appreciate that. It's the very point I'm making. A node can choose
what work to do, and should have a way of forwarding the results of that work
to other nodes. Transaction verifification is the main one.
Once a negative-announce message exists, it wouldn't be hard to have the other
two you need as well: positive-announce and neutral-announce. At present we
have only neutral-announce. However, as the need for super nodes and
distributed verification gets bigger, having the forwarder able to offer an
opinion on the quality of a transaction seems ideal to me. Dishonesty will
get you isolated pretty quickly if you use positive-announce and negative-
announce to lie.
The problem with this is that it requires a web of trust as well as a web of
connections. The only way to gain an advantage from this classified
forwarding is if you have some way of assigning enough trust so that you can
forward a classified transaction _without_ checking it yourself. That doesn't
sound like an easy problem though.
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/49edfc8b/attachment.sig>;
Andy Parkins [ARCHIVE] /
npub1nx…7wjrv
2023-06-07 02:50:51
in reply to nevent1q…rgyd
Author Public Key
npub1nxlvf9mj3jzgue25n5d9y47s3h5hvg0ded9hwpejdxj9mtrs34vs97wjrvPublished at
2023-06-07 02:50:51Event JSON
{
"id": "c5f9da69aa6bd8040fdc279a7cc446cb6402f124800acb810eed91c2fdd7ed3f",
"pubkey": "99bec497728c848e65549d1a5257d08de97621edcb4b77073269a45dac708d59",
"created_at": 1686106251,
"kind": 1,
"tags": [
[
"e",
"4af0205fae641367dcfd78e02a7a0b6f75f880a1f702affe5d70f7b792eb8207",
"",
"root"
],
[
"e",
"0cd4baf121d8ed29bb8de6425a9d27ddcf03e73cb957e3e4cb6cae1e0a916d18",
"",
"reply"
],
[
"p",
"a277336e95d2d0a831fff67fc80d8082322689a88ede9f877fa246a02629a43f"
]
],
"content": "📅 Original date posted:2011-12-22\n🗒️ Summary of this message: Nodes in a network have the option to choose what work to do, and should have a way of forwarding the results of that work to other nodes. Transaction verification is the main one. However, it requires a web of trust as well as a web of connections.\n📝 Original message:On 2011 December 22 Thursday, Joel Joonatan Kaartinen wrote:\n\u003e On Thu, 2011-12-22 at 11:52 +0000, Andy Parkins wrote:\n\u003e \u003e Why should they have to? Joining the network as a node is very low cost\n\u003e \u003e to the other nodes. You can't force any node not to be lazy, since\n\u003e \u003e their option is to disconnect themselves. As to maliciousness, that is\n\u003e \u003e defended against because when a node negative announces a transaction,\n\u003e \u003e that transaction is going to be checked (note that there is still no\n\u003e \u003e implicit trust) -- if a node is incorrectly negative-announcing then it\n\u003e \u003e can justifiably be kicked.\n\u003e \n\u003e a node that is not doing any checking themselves can not reliably\n\u003e forward failed verifications without getting the blame for doing faulty\n\u003e work. Those nodes would then have the incentive not to relay the failed\n\u003e verifications. This ends up making it important to know which nodes will\n\u003e be checking transactions or not so you don't isolate yourself from other\n\u003e nodes that are also checking transactions.\n\nYes; I appreciate that. It's the very point I'm making. A node can choose \nwhat work to do, and should have a way of forwarding the results of that work \nto other nodes. Transaction verifification is the main one.\n\nOnce a negative-announce message exists, it wouldn't be hard to have the other \ntwo you need as well: positive-announce and neutral-announce. At present we \nhave only neutral-announce. However, as the need for super nodes and \ndistributed verification gets bigger, having the forwarder able to offer an \nopinion on the quality of a transaction seems ideal to me. Dishonesty will \nget you isolated pretty quickly if you use positive-announce and negative-\nannounce to lie.\n\nThe problem with this is that it requires a web of trust as well as a web of \nconnections. The only way to gain an advantage from this classified \nforwarding is if you have some way of assigning enough trust so that you can \nforward a classified transaction _without_ checking it yourself. That doesn't \nsound like an easy problem though.\n\n\n\nAndy\n\n-- \nDr Andy Parkins\nandyparkins at gmail.com\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 198 bytes\nDesc: This is a digitally signed message part.\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111222/49edfc8b/attachment.sig\u003e",
"sig": "84c18a0c791b4d99de5bb5061e9a1ff1ad5c9228fd4f06d44930b3420ec429d3b3800fd0ed0e5c37e5c8e45ea603875a904802c7bf26631b41a2ca1ec7157370"
}