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
Basically the problem with that is that someone could setup a single
full node that has the blockchain and can answer those challenges and
then a bunch of other non-full nodes that just proxy any such challenges
to the single full node.
Rob
On 2015-03-26 23:04, Matt Whitlock wrote:
Maybe I'm
I agree that someone could do this, but why is that a problem? Isn't the goal
of this exercise to ensure more full nodes on the network? In order to be able
to answer the challenges, an entity would need to be running a full node
somewhere. Thus, they have contributed at least one additional
The main motivation is to try and stop a single entity running lots of
nodes in order to harvest transaction origin IPs. That's what's behind
this.
Probably the efforts are a waste of time.. if someone has to keep a few
hundred copies of the blockchain around in order to keep IP specific
On Friday, 27 March 2015, at 4:57 pm, Wladimir J. van der Laan wrote:
On Fri, Mar 27, 2015 at 11:16:43AM -0400, Matt Whitlock wrote:
I agree that someone could do this, but why is that a problem? Isn't the
goal of this exercise to ensure more full nodes on the network? In order to
be able
On Friday, 27 March 2015, at 4:57 pm, Wladimir J. van der Laan wrote:
On Fri, Mar 27, 2015 at 11:16:43AM -0400, Matt Whitlock wrote:
I agree that someone could do this, but why is that a problem? Isn't the
goal of this exercise to ensure more full nodes on the network? In order to
be able
On Mar 27, 2015, at 8:16 AM, Matt Whitlock b...@mattwhitlock.name wrote:
Isn't the goal of this exercise to ensure more full nodes on the network?
Basically we're talking about a form of Sybil defense and better quantifying
true blockchain resiliency by proof of storage.
In this case the
If the IP discovery is your main motivation, why don't you introduce some onion
routing into transactions? That would solve this problem easily, of course
there is an overhead which will slightly slow down the relay of transactions
but not significantly, also make it an option not enforced, for
If I understand correctly, transforming raw blocks to keyed blocks
takes 512x longer than transforming keyed blocks back to raw. The key
is public, like the IP, or some other value which perhaps changes less
frequently.
Yes. I was thinking that the IP could be part of a first layer of
Maybe I'm overlooking something, but I've been watching this thread with
increasing skepticism at the complexity of the offered solution. I don't
understand why it needs to be so complex. I'd like to offer an alternative for
your consideration...
Challenge:
Send me: SHA256(SHA256(concatenation
On Mon, 16 Mar 2015 09:29:03 -0700, Sergio Lerner
sergioler...@certimix.com wrote:
I proposed a (what I think) is better protocol for Proof of Storage that
I call Proof of Local storage here
https://bitslog.wordpress.com/2014/11/03/proof-of-local-blockchain-storage/
Thanks so much for
The problem of pseudo-nodes will come over and over. The cat and mouse
chase is just beginning.
It has been discussed some times that the easiest solution world be to
request some kind of resource consumption on each peer to be allowed to
connect to other peers.
Gmaxwell proposed Proof of Storage
12 matches
Mail list logo
