Wladimir [ARCHIVE] on Nostr: ๐
Original date posted:2014-08-18 ๐ Original message:> The optimal strategy for ...
๐
Original date posted:2014-08-18
๐ Original message:> The optimal strategy for avoiding linkages (ignoring tor, again), is
> to randomly pick a different peer for each transaction and relay the
> transaction only to that peer. This can (and probably should) be
> distinct from your normal network connectivity.
It already happens with 8 peers that if you have lousy peers, the
transaction doesn't reach the network on the first broadcasting. When
sending to only one random peer it will likely be even worse.
I guess the wallet could send out the transaction 'staggered' over
time. It could pick a random new node, broadcast the transaction, wait
a bit, pick a new node, broadcast the transaction until it is comes
back through one of the other peers.
Separating the transaction broadcasting (of the wallet) from, for
example, the nodes used to request blocks from could make sense. Maybe
doubly so if bloom filters are involved.
Wladimir
Published at
2023-06-07 15:25:17Event JSON
{
"id": "3ba582b4ea035f56bf81004083eace8806cbe7242a2757b2fc37b1bf9405b523",
"pubkey": "30217b018a47b99ed4c20399b44b02f70ec4f58ed77a2814a563fa28322ef722",
"created_at": 1686151517,
"kind": 1,
"tags": [
[
"e",
"e6c404fd858836a0d121570d430c31334c7f9506574c3afe9220b83bd385159d",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "๐
Original date posted:2014-08-18\n๐ Original message:\u003e The optimal strategy for avoiding linkages (ignoring tor, again), is\n\u003e to randomly pick a different peer for each transaction and relay the\n\u003e transaction only to that peer. This can (and probably should) be\n\u003e distinct from your normal network connectivity.\n\nIt already happens with 8 peers that if you have lousy peers, the\ntransaction doesn't reach the network on the first broadcasting. When\nsending to only one random peer it will likely be even worse.\n\nI guess the wallet could send out the transaction 'staggered' over\ntime. It could pick a random new node, broadcast the transaction, wait\na bit, pick a new node, broadcast the transaction until it is comes\nback through one of the other peers.\n\nSeparating the transaction broadcasting (of the wallet) from, for\nexample, the nodes used to request blocks from could make sense. Maybe\ndoubly so if bloom filters are involved.\n\nWladimir",
"sig": "9e22ed99761d6823c8069d9f0ccc7b0f57e21cbaeb4fa4a0f361bb5aad5b5a77647c53b1726c59053aa9c757cc38217c7f1dff7bd80d289dcd75623ff13f858f"
}