📅 Original date posted:2015-12-04
📝 Original message:1. Not relaying can cause problems. Gossip networks operate by
propagating new information (like a single new header), and refuse to
relay information if it's obviously invalid.
>From the POV of a full node, which will normally hear about the header
first, there's no point to not telling peers about this information.
It's likely in the interest of SPV wallets to hear about EVERY
contending chain, so they can go about their business deciding which is
correct.
2. The only difference between a block and it's header is the list of
transactions. There isn't anywhere else to put the flag but the header's
version. Which is good, because clients usually receive headers first.
3. "Signal would need to include some sort of proof" That's not the
point of this BIP. You can't prove the miner has or hasn't verified the
chain. What purpose would it even serve? If clients accepted this
'proof', they might ignore blocks they should pay attention to.
The BIP doesn't involve proof at all, it's just an indicator you can
chose to use or ignore.
On 04/12/15 12:44, Jannes Faber via bitcoin-dev wrote:
> nodes side by side, one of them doesn't validate in order to reduce latency
Thomas Kerin [ARCHIVE] /
npub1e4…nt5am
2023-06-07 17:45:31
in reply to nevent1q…9kch
Author Public Key
npub1e4azew50kk9xzvfpqxzlyftkjt6kken0kf9lnncpdj524f9y4cqsfnt5amPublished at
2023-06-07 17:45:31Event JSON
{
"id": "bfd5bad5e761c9b51afb81f7c0aa7517315fe8f53d96e63d153e716527cbb096",
"pubkey": "cd7a2cba8fb58a6131210185f2257692f56b666fb24bf9cf016ca8aaa4a4ae01",
"created_at": 1686159931,
"kind": 1,
"tags": [
[
"e",
"15a16192f3a989cab67f2ac617a2f0c8ac441d823789f63c6c25a5e7f0b7696c",
"",
"root"
],
[
"e",
"bd6aa108ae98965fb7e614d895f8363e97e43805a44c7e7683bf02ece752978a",
"",
"reply"
],
[
"p",
"f05699fae959fb582a8bd56a55b613bafd61c2c239a00bc5ea66faf0cb7a2aa8"
]
],
"content": "📅 Original date posted:2015-12-04\n📝 Original message:1. Not relaying can cause problems. Gossip networks operate by\npropagating new information (like a single new header), and refuse to\nrelay information if it's obviously invalid.\n\n\u003eFrom the POV of a full node, which will normally hear about the header\nfirst, there's no point to not telling peers about this information.\nIt's likely in the interest of SPV wallets to hear about EVERY\ncontending chain, so they can go about their business deciding which is\ncorrect.\n\n\n2. The only difference between a block and it's header is the list of\ntransactions. There isn't anywhere else to put the flag but the header's\nversion. Which is good, because clients usually receive headers first.\n\n\n3. \"Signal would need to include some sort of proof\" That's not the\npoint of this BIP. You can't prove the miner has or hasn't verified the\nchain. What purpose would it even serve? If clients accepted this\n'proof', they might ignore blocks they should pay attention to.\n\nThe BIP doesn't involve proof at all, it's just an indicator you can\nchose to use or ignore.\n\n\nOn 04/12/15 12:44, Jannes Faber via bitcoin-dev wrote:\n\u003e nodes side by side, one of them doesn't validate in order to reduce latency",
"sig": "5ad94f7472167b3354a8889bddd7d4601f5842830236f8996bcf6e0b58e6d1ca7cffb5bae1fe55a63d23e6edb0ad4a964e7770b2dce0078da3f9ff28a199af73"
}