Sergio Lerner [ARCHIVE] on Nostr: 📅 Original date posted:2015-03-31 📝 Original message:Matt is right: the goal is ...
📅 Original date posted:2015-03-31
📝 Original message:Matt is right: the goal is to prove digital copies of a public file.
Nothing more, nothing less.
Regarding the IP, I don't claim that every machine should provide the
protocol. Mobiles phones shouldn't. But machines that what to be
prioritized in some way or that want to be rewarded for hosting a node
should use a fixed IP. That's the cost of prioritization/reward. The
protocol could be a service bit, advertised in the version message.
My response to your comment below:
On 27/03/2015 03:40 p.m., Jeremy Spilman wrote:
>
> It would be extremely impressive to achieve a reliable mechanism for discerning a local copy exists under these constraints, particularly without false positives and false negatives, and without imposing very substantial one-time encoding costs, e.g. on par with doubling the verification cost.
I see it differently. The asymmetric-time protocol is quite reliable. If
can be made to have almost no false positives/false negatives (not
considering rare communication problems, such as congestion and packet
loss for more than 5 seconds).
These are my back-of-the-envelope calculations:
Bitcoind takes approximately 1 second to serve a 1 Mb block (seek time,
but mostly transfer time)
Then decryption of a block can take 150 msec without problem (15%
overhead). The last N blocks could be cached so they don't need to be
decrypted to be sent.
In 150 msec a PC can decrypt a 1MB of data split over 1024-bit blocks
decrypted by modexp 3 (0.2 msec for 3 bigint multiplications), so a full
block can be decrypted.
Encrypting such block would take approximately 15 seconds (which is much
less than the 10 minutes available to encrypt each block)
Then the protocol works with a security margin of approximately 50x.
A communication problem during 5 seconds would be needed to disturb a
protocol of that takes 100 msec for the prover.
Regards,
Sergio.
Published at
2023-06-07 15:32:17Event JSON
{
"id": "7d3a95b1f3ab5c23879fb7a5d2b4819fc920c0dc04c70a7823e2b750b039ff92",
"pubkey": "60f7a1f85420f38fa26db24af48330bd1800ed3bef3168454263dcfcef62a8ce",
"created_at": 1686151937,
"kind": 1,
"tags": [
[
"e",
"3122a69d6f01a9c9fbf696fd5399c04585ab3d284cf87076ac941980c05588d8",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2015-03-31\n📝 Original message:Matt is right: the goal is to prove digital copies of a public file.\nNothing more, nothing less.\n\nRegarding the IP, I don't claim that every machine should provide the\nprotocol. Mobiles phones shouldn't. But machines that what to be\nprioritized in some way or that want to be rewarded for hosting a node\nshould use a fixed IP. That's the cost of prioritization/reward. The\nprotocol could be a service bit, advertised in the version message.\n\nMy response to your comment below:\n\nOn 27/03/2015 03:40 p.m., Jeremy Spilman wrote:\n\u003e\n\u003e It would be extremely impressive to achieve a reliable mechanism for discerning a local copy exists under these constraints, particularly without false positives and false negatives, and without imposing very substantial one-time encoding costs, e.g. on par with doubling the verification cost. \nI see it differently. The asymmetric-time protocol is quite reliable. If\ncan be made to have almost no false positives/false negatives (not\nconsidering rare communication problems, such as congestion and packet\nloss for more than 5 seconds).\nThese are my back-of-the-envelope calculations:\nBitcoind takes approximately 1 second to serve a 1 Mb block (seek time,\nbut mostly transfer time)\nThen decryption of a block can take 150 msec without problem (15%\noverhead). The last N blocks could be cached so they don't need to be\ndecrypted to be sent.\nIn 150 msec a PC can decrypt a 1MB of data split over 1024-bit blocks\ndecrypted by modexp 3 (0.2 msec for 3 bigint multiplications), so a full\nblock can be decrypted.\nEncrypting such block would take approximately 15 seconds (which is much\nless than the 10 minutes available to encrypt each block)\nThen the protocol works with a security margin of approximately 50x.\nA communication problem during 5 seconds would be needed to disturb a\nprotocol of that takes 100 msec for the prover.\n\nRegards,\n Sergio.",
"sig": "c2628c73a7e4388d0dd00ceb4aea5d9248a48b9a0f41cd19e35306d43c0cd4a5b4236a1713b51f81e45ca946bae9e59a1262da92ab5a53c61fbdbdd54100f3a9"
}