Proof of Storage/Space/Replication/Etc? #1426

New Issue

2019-01-18T18:34:44+01:00

iljah commented

2019-01-18 18:34:44 +01:00

(Migrated from github.com)

Has anyone investigated whether some type of proof of space would be suitable for bm? It should narrow the gap between phones and desktops/GPUs/FPGAs. There are lots of pdfs on eprint.iacr.org about this topic. Latest ones seem to deal with proofs of replicated storage but that wouldn't be required for bm.

PeterSurda commented

2019-01-18 18:54:24 +01:00

(Migrated from github.com)

I'm skeptical that this is suitable for Bitmessage.

stman commented

2019-01-18 18:54:24 +01:00

(Migrated from github.com)

could you develop please and give a few links on related articles ?

Thank you.

Stman.

Ilja:

Has anyone investigated whether some type of proof of space would be suitable for bm? It should narrow the gap between phones and desktops/GPUs/FPGAs. There are lots of pdfs on eprint.iacr.org about this topic. Latest ones seem to deal with proofs of replicated storage but that wouldn't be required for bm.

could you develop please and give a few links on related articles ? Thank you. Stman. Ilja: > Has anyone investigated whether some type of proof of space would be suitable for bm? It should narrow the gap between phones and desktops/GPUs/FPGAs. There are lots of pdfs on eprint.iacr.org about this topic. Latest ones seem to deal with proofs of replicated storage but that wouldn't be required for bm. >

iljah commented

2019-01-20 16:47:49 +01:00

(Migrated from github.com)

Here are some random ones:
https://eprint.iacr.org/2016/035
https://eprint.iacr.org/2013/796
https://eprint.iacr.org/2018/194
https://eprint.iacr.org/2018/678
https://eprint.iacr.org/2018/702
https://eprint.iacr.org/2018/654
https://eprint.iacr.org/2011/529
https://eprint.iacr.org/2014/395

Here are some random ones: https://eprint.iacr.org/2016/035 https://eprint.iacr.org/2013/796 https://eprint.iacr.org/2018/194 https://eprint.iacr.org/2018/678 https://eprint.iacr.org/2018/702 https://eprint.iacr.org/2018/654 https://eprint.iacr.org/2011/529 https://eprint.iacr.org/2014/395

iljah commented

2019-01-20 17:03:00 +01:00

(Migrated from github.com)

Proof of storage or similar would be easier if sender or recipient were known, in which case spam protection could be (probably partially) based on number of messages to or from someone.

I think there are types of proof of storage that can be verified without two-way communication which would be suitable for BM. In case offline proofs aren't possible online proofs could also be generated whenever two nodes exchange messages. Either each one would prove that they're storing some older messages or that they're storing messages they just received.

Naturally these aren't immune to attacks, especially when sender and receiver are unknown, but I suspect these would be more difficult to attack than sha512 PoW.

Proof of storage or similar would be easier if sender or recipient were known, in which case spam protection could be (probably partially) based on number of messages to or from someone. I think there are types of proof of storage that can be verified without two-way communication which would be suitable for BM. In case offline proofs aren't possible online proofs could also be generated whenever two nodes exchange messages. Either each one would prove that they're storing some older messages or that they're storing messages they just received. Naturally these aren't immune to attacks, especially when sender and receiver are unknown, but I suspect these would be more difficult to attack than sha512 PoW.

iljah commented

2019-01-20 17:09:12 +01:00

(Migrated from github.com)

One aspect of private sender & receiver is that verifiable delay functions and similar, as well as some/most? proofs of space, don't help as they only prevent parallelization of pow for one message and attackers can instead send several messages simultaneously.

stman commented

2019-01-20 17:09:58 +01:00

(Migrated from github.com)

Thank you for these informations, it is very interesting.

Kind regards,

Frederic.
a.k.a stman.

Le 20 janv. 2019 à 17:03, Ilja notifications@github.com a écrit :

Proof of storage or similar would be easier if sender or recipient were known, in which case spam protection could be (probably partially) based on number of messages to or from someone.

I think there are types of proof of storage that can be verified without two-way communication which would be suitable for BM. In case offline proofs aren't possible online proofs could also be generated whenever two nodes exchange messages. Either each one would prove that they're storing some older messages or that they're storing messages they just received.

Naturally these aren't immune to attacks, especially when sender and receiver are unknown, but I suspect these would be more difficult to attack than sha512 PoW.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

Thank you for these informations, it is very interesting. Kind regards, Frederic. a.k.a stman. > Le 20 janv. 2019 à 17:03, Ilja <notifications@github.com> a écrit : > > Proof of storage or similar would be easier if sender or recipient were known, in which case spam protection could be (probably partially) based on number of messages to or from someone. > > I think there are types of proof of storage that can be verified without two-way communication which would be suitable for BM. In case offline proofs aren't possible online proofs could also be generated whenever two nodes exchange messages. Either each one would prove that they're storing some older messages or that they're storing messages they just received. > > Naturally these aren't immune to attacks, especially when sender and receiver are unknown, but I suspect these would be more difficult to attack than sha512 PoW. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub, or mute the thread.

PeterSurda commented

2019-01-20 19:51:19 +01:00

(Migrated from github.com)

I would have to read through all of that, those that I looked at explained how miners compete with each other, which makes sense for a blockchain, but isn't the case with Bitmessage.

iljah commented

2019-01-26 17:38:50 +01:00

(Migrated from github.com)

https://eprint.iacr.org/2018/702 looks like a good one to start from, they don't discuss blockchains. Miner competition might be good to see discussed though since in that case proof of space is non-interactive meaning it might be easier to implement in bm as messages could include everything needed for PoSpace. Otherwise some back and forth would be required when messages are relayed in the network.

PeterSurda commented

2019-01-27 15:11:20 +01:00

(Migrated from github.com)

"A PoS is an interactive protocol between a prover and verifier in which the prover use a minimum specified amount of space in order to pass verification." In other words, this isn't suitable for Bitmessage as it would have to be asynchronous.

PeterSurda commented

2020-08-27 20:51:20 +02:00

(Migrated from github.com)

I think that this may be worth researching some time in the future but there is no urgency.

This repo is archived. You cannot comment on issues.