2. Proof of work time IDs as timestamps: This doesn't work. It's trivial to backdate posts just by picking an earlier ID. (I don't care about this topic personally but people are concerned about backdating not forward-dating.)
N. Decentralized instances should be able to host partial data: This is where I got lost. If everybody is hosting their own data, why is anything else needed?
A 1-time fixed cost will not deter spam, it only encourages more spamming to lower the averaged per-spam cost. Email spamming requires some system set up, that's a 1-time fixed cost above $10/year but it does not stop spam.
It’s one time fixed cost per stream of messages, with some out of band mechanism to throttle posting per-stream. I’m not sure I agree with the original articles choice of throttling mechanism (binding to the universal Bitcoin clock), but the concept still makes sense: in order to scale up production of spam, you still need to buy additional domains, otherwise you’re limited to one post every n-minutes, and domain registration slow enough for block lists to keep up.
There was a psychological study that decided that community moderation tends to be self healing if, and only if, punishing others for a perceived infraction comes at a cost to the punisher.
I believe I have the timeline right that this study happened not too long before StackOverflow got the idea that getting upvoted gives you ten points and downvoting someone costs you two. As long as you’re saying something useful occasionally instead of disagreeing with everyone else, your karma continues to rise.
While interesting, this seems entirely tangential to the conversation to me. I’m not seeing the connection between paying for the right to participate and punishment. What am I missing?
If there’s no system to refute the uniqueness of a handful of identities (sock puppets used for griefing) then the system won’t scale. If anyone can issue a “takedown” for free, the system of moderation won’t scale.
Domain names are fine but they shouldn't be forced onto anyone. Nothing about DID or any other flexible and open decentralized naming/identity protocol will prevent anyone from using domain names if they want to.
Time services can help with these sorts of things. They aren’t notarizing the message. You don’t trust the service to validate who wrote it or who sent it, you just trust that it saw these bytes at this time.
Something that maintains a mapping between a signature+domain and the earliest seen timestamp for that combination? I think at that point the time service becomes a viable aggregated index for readers who use to look for updates. I think this also solves the problem for lowering the cost of participation… since the index would only store a small amount of data per-post, and since indexes can be composed by the reader, it could scale cost effectively.
I’ve only briefly worked with these but got a rundown from someone more broadly experienced with them. Essentially you treat trust as a checklist. I accept this message (and any subsequent transactions implied by its existence) if it comes from the right person, was emitted during the right time frame (whether I saw it during a separate time frame), and <insert other criteria here>. If I miss the message due to transmission errors or partitioning, I can still honor it later even though it now changes the consequences of some later message I can now determine to have arrived out of order.
I wonder if another way to think about this is as an authenticated vector clock. I think a merkle tree approach is probably too heavy weight as it’s not necessary to keep that information around. You kind of just need quorum (defined as appropriate to mitigate abuse) to update your local version of the vector clock, but unlike a merkle tree, you only need partial updates based on the subset of posters you care about and you basically only need to keep around the last few versions of each vector component.
I don’t recall if any of the signatures sign across any other signatures. I think in some cases it’s just a… Merkle List?
Merkle trees get weird if they’re done as signatures. With bitcoin everyone votes on the validity in a fairly narrow timeframe and the implausibility of spoofing a record and then spoofing the next n is what allows for the trust-in-the-blind to be practical (even if I don’t agree that the theory is sound).
For signatures, on data at rest, it gets complicated. Because at some point you’re trusting a payload that has signatures from expired certificates. You end up having/needing transitive trust, because the two signatures you care about are valid, and they signed the payload while the signatures they cared about were still valid. So now you need to look at signature timestamps, Cert validity range, Cert chain validity range, CRLs or OCSP, and you better make sure all your timestamps are in UTC…
It’s easier if the system has a maximum deliver-by date, and you just drop anything that shows up too out of band. I can use a piece of software that was created and signed over a year ago, but maybe I shouldn’t accept year-old messages.
I did a code signing system for avionics software, that supported chain of custody via countersigning (Merkle before anyone heard of bitcoin). The people who needed to understand it did but it broke some brains. I lost count of how many meetings we had where we had to explain the soundness of the transitivity. People were nervous, and frankly there weren’t enough people watching the watchers. Sometimes you only catch your own mistakes when teaching.
Hi, author here. Regarding backdating it is a valid concern. I did not mention in the article, but in my proposed architecture users could post links of others (consider that a retweet). For links that have reposts there could exist additional security checks implemented to check validity of post time.
Regarding hosting partial data: there should be an option to host just recent data for the past month or other time frames and not full DB of URLs. This would make decentralization better as each instance could have less storage requirements, but total information would be present on the network.
Recent events also taught us that proof of work is a serious problem for the biosphere when serious money is involved and everybody scales up.
Instead, it seems proof of stake is more what is required.
Comments
1. Domain names: good.
2. Proof of work time IDs as timestamps: This doesn't work. It's trivial to backdate posts just by picking an earlier ID. (I don't care about this topic personally but people are concerned about backdating not forward-dating.)
N. Decentralized instances should be able to host partial data: This is where I got lost. If everybody is hosting their own data, why is anything else needed?
If the data is a signed hash, why does it need the domain name requirement? One can host self-authenticating content in many places.
And one can host many signing keys at a single domain.
In the article, the main motivation for requiring a domain name, is to raise the barrier to entry above “free” to mitigate spamming/abuse.
A 1-time fixed cost will not deter spam, it only encourages more spamming to lower the averaged per-spam cost. Email spamming requires some system set up, that's a 1-time fixed cost above $10/year but it does not stop spam.
It’s one time fixed cost per stream of messages, with some out of band mechanism to throttle posting per-stream. I’m not sure I agree with the original articles choice of throttling mechanism (binding to the universal Bitcoin clock), but the concept still makes sense: in order to scale up production of spam, you still need to buy additional domains, otherwise you’re limited to one post every n-minutes, and domain registration slow enough for block lists to keep up.
One person per domain is essentially proof of $10.
There was a psychological study that decided that community moderation tends to be self healing if, and only if, punishing others for a perceived infraction comes at a cost to the punisher.
I believe I have the timeline right that this study happened not too long before StackOverflow got the idea that getting upvoted gives you ten points and downvoting someone costs you two. As long as you’re saying something useful occasionally instead of disagreeing with everyone else, your karma continues to rise.
While interesting, this seems entirely tangential to the conversation to me. I’m not seeing the connection between paying for the right to participate and punishment. What am I missing?
If there’s no system to refute the uniqueness of a handful of identities (sock puppets used for griefing) then the system won’t scale. If anyone can issue a “takedown” for free, the system of moderation won’t scale.
Domain names are fine but they shouldn't be forced onto anyone. Nothing about DID or any other flexible and open decentralized naming/identity protocol will prevent anyone from using domain names if they want to.
Time services can help with these sorts of things. They aren’t notarizing the message. You don’t trust the service to validate who wrote it or who sent it, you just trust that it saw these bytes at this time.
Something that maintains a mapping between a signature+domain and the earliest seen timestamp for that combination? I think at that point the time service becomes a viable aggregated index for readers who use to look for updates. I think this also solves the problem for lowering the cost of participation… since the index would only store a small amount of data per-post, and since indexes can be composed by the reader, it could scale cost effectively.
I’ve only briefly worked with these but got a rundown from someone more broadly experienced with them. Essentially you treat trust as a checklist. I accept this message (and any subsequent transactions implied by its existence) if it comes from the right person, was emitted during the right time frame (whether I saw it during a separate time frame), and <insert other criteria here>. If I miss the message due to transmission errors or partitioning, I can still honor it later even though it now changes the consequences of some later message I can now determine to have arrived out of order.
I wonder if another way to think about this is as an authenticated vector clock. I think a merkle tree approach is probably too heavy weight as it’s not necessary to keep that information around. You kind of just need quorum (defined as appropriate to mitigate abuse) to update your local version of the vector clock, but unlike a merkle tree, you only need partial updates based on the subset of posters you care about and you basically only need to keep around the last few versions of each vector component.
I don’t recall if any of the signatures sign across any other signatures. I think in some cases it’s just a… Merkle List?
Merkle trees get weird if they’re done as signatures. With bitcoin everyone votes on the validity in a fairly narrow timeframe and the implausibility of spoofing a record and then spoofing the next n is what allows for the trust-in-the-blind to be practical (even if I don’t agree that the theory is sound).
For signatures, on data at rest, it gets complicated. Because at some point you’re trusting a payload that has signatures from expired certificates. You end up having/needing transitive trust, because the two signatures you care about are valid, and they signed the payload while the signatures they cared about were still valid. So now you need to look at signature timestamps, Cert validity range, Cert chain validity range, CRLs or OCSP, and you better make sure all your timestamps are in UTC…
It’s easier if the system has a maximum deliver-by date, and you just drop anything that shows up too out of band. I can use a piece of software that was created and signed over a year ago, but maybe I shouldn’t accept year-old messages.
I did a code signing system for avionics software, that supported chain of custody via countersigning (Merkle before anyone heard of bitcoin). The people who needed to understand it did but it broke some brains. I lost count of how many meetings we had where we had to explain the soundness of the transitivity. People were nervous, and frankly there weren’t enough people watching the watchers. Sometimes you only catch your own mistakes when teaching.
that's too much tech for a trust problem it can't solve. just use a TimeStamp Authority like https://freetsa.org/index_en.php or https://knowledge.digicert.com/general-information/rfc3161-c...
Thanks for sharing! That RFC led me to this one, which helps fill in some of the other implementation details: https://datatracker.ietf.org/doc/html/rfc4998
Hi, author here. Regarding backdating it is a valid concern. I did not mention in the article, but in my proposed architecture users could post links of others (consider that a retweet). For links that have reposts there could exist additional security checks implemented to check validity of post time.
Regarding hosting partial data: there should be an option to host just recent data for the past month or other time frames and not full DB of URLs. This would make decentralization better as each instance could have less storage requirements, but total information would be present on the network.
Recent events also taught us that proof of work is a serious problem for the biosphere when serious money is involved and everybody scales up. Instead, it seems proof of stake is more what is required.
Yeah, a verifiable delay function is probably better for timestamping.