📅 Original date posted:2015-08-06
📝 Original message:On Thu, Aug 6, 2015 at 6:17 PM, Tom Harding via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> - Will the relay network at least validate block version numbers in the
> future?
It already validates block version numbers.
It only relays valid transactions.
Although, the block relaying itself is explicitly "unvalidated" and
the software client can only usefully be used with a mempool
maintaining full node (otherwise it doesn't provide much value,
because the node must wait to validate the things). ... but that
doesn't actually mean no validation at all is performed, many
stateless checks are performed.
On Thu, Aug 6, 2015 at 5:16 PM, Sergio Demian Lerner via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Is there any up to date documentation about TheBlueMatt relay network
> including what kind of block compression it is currently doing? (apart from
> the source code)
I don't know if Matt has an extensive writeup. But the basic
optimization it performs is trivial. I wouldn't call it compression,
though it does have some analog to RTP "header compression".
All it does is relay transactions verified by a local node and keeps a
FIFO of the relayed transactions in both directions, which is
synchronous on each side.
When a block is recieved on either side, it replaces transactions with
their indexes in the FIFO and relays it along. Transactions not in the
fifo are escaped and sent whole. On the other side the block is
reconstructed using the stored data and handed to the node (where the
preforwarded transactions would have also been pre-validated).
There is some more than basic elaboration for resource management
(e.g. multiple queues for different transaction sizes)-- and more
recently using block templates to learn transaction priority be a bit
more immune to spam attacks, but its fairly simple.
Much better could be done about intelligently managing the queues or
efficiently transmitting the membership sets, etc. It's just
basically the simplest thing that isn't completely stupid.
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 17:33:19
in reply to nevent1q…3vr6
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetPublished at
2023-06-07 17:33:19Event JSON
{
"id": "b968c983982591625b419e4cc315428981e667df447948647c590cf788eeadf9",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686159199,
"kind": 1,
"tags": [
[
"e",
"5ecbb8bb487379d9b1082997ca04a0c25f898e42d2a6e1c5aebe542ad1d89a07",
"",
"root"
],
[
"e",
"bf89b4c38dd9ac7197306dfa083f16070b901c5ec41c4d090f0f01e354998595",
"",
"reply"
],
[
"p",
"dc329a02c970aabf03b87185ef51c86afe4586fe3a148508af898af3fabc56a3"
]
],
"content": "📅 Original date posted:2015-08-06\n📝 Original message:On Thu, Aug 6, 2015 at 6:17 PM, Tom Harding via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e - Will the relay network at least validate block version numbers in the\n\u003e future?\n\nIt already validates block version numbers.\n\nIt only relays valid transactions.\n\nAlthough, the block relaying itself is explicitly \"unvalidated\" and\nthe software client can only usefully be used with a mempool\nmaintaining full node (otherwise it doesn't provide much value,\nbecause the node must wait to validate the things). ... but that\ndoesn't actually mean no validation at all is performed, many\nstateless checks are performed.\n\nOn Thu, Aug 6, 2015 at 5:16 PM, Sergio Demian Lerner via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e Is there any up to date documentation about TheBlueMatt relay network\n\u003e including what kind of block compression it is currently doing? (apart from\n\u003e the source code)\n\nI don't know if Matt has an extensive writeup. But the basic\noptimization it performs is trivial. I wouldn't call it compression,\nthough it does have some analog to RTP \"header compression\".\n\nAll it does is relay transactions verified by a local node and keeps a\nFIFO of the relayed transactions in both directions, which is\nsynchronous on each side.\n\nWhen a block is recieved on either side, it replaces transactions with\ntheir indexes in the FIFO and relays it along. Transactions not in the\nfifo are escaped and sent whole. On the other side the block is\nreconstructed using the stored data and handed to the node (where the\npreforwarded transactions would have also been pre-validated).\n\nThere is some more than basic elaboration for resource management\n(e.g. multiple queues for different transaction sizes)-- and more\nrecently using block templates to learn transaction priority be a bit\nmore immune to spam attacks, but its fairly simple.\n\nMuch better could be done about intelligently managing the queues or\nefficiently transmitting the membership sets, etc. It's just\nbasically the simplest thing that isn't completely stupid.",
"sig": "d409b0914d0c3117cf701dc266a839f2fec14f4d7682d6101215c4727438a01cdb1a809af9d7cb4783a21b3fdaaa3d577076144966f5f0175eb10ba37c1681ad"
}