PtP, PtD, and/or Pt* Megathread - Pros and Cons

I would have expected farming would be far harder to game due to the requirement to provide verifiable resources to the network, gain age, and not misbehave in order to reveive rewards. If it were easy to game farming, it’d be a significant threat to the network.

Creating a bunch of new / zombie clients to get specific data in order to capture rewards intended for content creators, if not prevented, could make the rewards to genuine creators irrelevant, and hugely burden the network. The threat of this in a badly designed system is, I would think, a far bigger threat than relying on user controlled micropayments to support valued content.

Maybe such potentially damaging gaming could be reduced through methods such as preventing clients getting the same data frequently, but anything that generates reward without cost (e.g. data agnostic rewards on getting data) is going to be significantly more profitable / easy to game than something that provides rewards in exchange for providing value (farming).

I hope that can be avoided, e.g. by farmers rewards being aggregated across similar aged / performing nodes, rather than nay easily gamable mechanism. As you say, caching will help significantly, but certainly best to design out bad incentives if a healthy network economy is desired.

I also wouldn’t want to see the current way of doing things migrate to the Safe network, but the decentralised infrastructure and microoayments of the Safe Network will significantly help here.

Yes, seeking rapid adoption is important, but poor incentives that lead to misalocating resources and increasing strain on the network wouldn’t help adoption in a healthy way, and this is what would happen if a poorly designed Pt* system were used.

The concept is good, but gaming isn’t something to be shrugged off, as it could be actively harmful vs not having a Pt* system.

My worry is that if this is done without sufficient safeguards, there’s a real risk that Pt* will do more harm than good. If the gaming scenarios can be avoided / minimised, then I agree that it’s good to incentivise people to produce popular content, but I think it’s far more likely that people could incentivise content they like through micropayments.

I guess how BAT works with Brave is a good concept to consider. If BAT was given out to people based on bandwidth usage / frequency of access that bots could generate, it’d be pointless, and that’s likely the case here too.

1 Like

If that could counter the gaming it’d be great & remove the biggest threat I see from an automated Pt* system. Hopefully it wouldn’t also prevent the proportionate rewarding of genuinely popular data… a tricky balance perhaps?

I would expect farmers to have good incentives to promote quality / popular / valuable content & development because their rewards depend on a successful network (SNT rewards will be worth more if demand for network resources / SNT is higher).

Even if some big farmers have significant sway, they’re also contributing more and they will never own the infrastructure to be able to exert anything like the control Google has over its current ecosystem.

Just to pop in … Many here come with the assumption that our future society using SN without Pt* is going to mirror (to a large extent) the world we have now - that past malincentives will create the perceived problems we have now.

But nobody knows this to be true. It’s merely an assumption.

Better to start off without the complications … wait a decade or three to see how things play out … then make new changes if required.

Social change, if it is to be long lasting, is slow. Those that try to force things end up making things worse.

Let’s not be hasty with changes that could lead to more problems than they “might” potentially solve.

1 Like

That is what I’d expect, properly working farming devices which is required if gaming is to be done on farming payments.

I wrote more replying to the first post but reading your second it is redundant :wink:

Point is that gaming farming payment system is way more profitable. So why allow payments for farming, it will be gamed. Reason why allow it is that we understand it will be minimal and the reasons for that apply equally or more so for Pt*. To me gaming payments is common to all payments the network may make (except core devs which will likely involve the foundation to distribute) and the mitigating mechanisms that will be put in place will work for farming & Pt* payments.

So its not sweeping the gaming issue under the carpet, rather it is recognising that gaming any of farming or Pt* payments is the issue. Its not a Pt* issue but farming as well.

Caching will be one of the major mitigating mechanisms and reduces the effectiveness of large numbers of “zombies”

Point of payment system is that its an application layer system and will be essential for payments where Pt* is not enough. This is the case for such things where the work done to produce the App or content is not covered by the Pt*. This will often be the case for less popular content.

Content in a youtube style of presentation will likely be covered by a number of Apps using the data supplied by the uploaders. And each of these Apps could incorporate a module to enable payments. Now if this can be done prior to the likes of Google then it will most likely prevent Google from successfully implementing their own.

The point I am trying to make is we need the concept of Apps incorporating micro payments modules in place before corporations start. Basically there will be different modules/libraries written so that an App developer can use one that suits them for their App.

I see App level payments covering the payments that are needed above what Pt* provides. You could say the Pt* are micro payments UBI style for providers of Apps/Content and the App level payments are the Tips, millipayments and standard payments.

This argument applies more to gaming farming than Pt*

The issue is more that the current popularity of the internet was born out of the commercialisation of the internet which started in the early 90’s. Without it the internet would be a business tool and education tool only. The population would only have it to do banking.education and email. But commercialisation allowed media providers to get paid along with hosting providers to make a living. Businesses going online is a part of commercialisation, entertainment companies providing content online is a part of commercialisation, and so on. The internet exploded in the 15 years since early 1990s and continues to this day.

Its not so much that SAFE may take off without fear of the evils going onto SAFE, but rather without adoption none of those enjoying commercialisation of the internet will want to go on. Nothing there for them, no businesses, no big media, etc.

We need adoption of the network. Providing a basic payment system for providers is just one small step to enable it. The arguments against Pt* apply as well to paying farmers. The arguments for paying farmers apply to Pt* as well. They all provide resources/services for the network to operate and be adoptable.

History is a good educator, and knowing the history of the internet allows us a window into how people will react to SAFE

In a decade with nothing being done payment wise (Pt* through tips/micropayment systems) will likely see SAFE not doing much at all. History is a good educator on that one.

Exactly and why people will see SAFE as just an alternative internet without the things they want and ignore it. History tells us that, just look at the evolution of social platforms. Implementing a basic payment system for providers is actually not changing what people expect (that is the society side) but it does change the way big corporations work (they try to manipulate society)

This is certainly not about that. Otherwise you could say the whole network project is doing exactly that, trying to solve issues that people “might” potentially want solved.

Pt* is solving a known problem. Quality content, quality Applications that the world as a whole want to use and enjoy is not cheap. Being cheap is not going to attract people. So Pt* is part of that solution. It will be enough for some to just get a little and it starts the ball rolling to adoption of the network. Then when micropayment systems at the App level exist then those who need more than what Pt* is proving them will come on board because there is already people adopting the network.

Pt* is not meant to be a solve it all, but a part of the solution enabling us to rid ourselves of the corporations keeping large amounts for their profit.

4 Likes

@neo, I appreciate the effort that went into those detailed replies. Main reason why I’m replying again one last time :slight_smile:

First, I’m not saying that the desire to rewards content providers is bad. My point is, given the potential risks to the network, should such content reward mechanisms be baked into the base layer or should it be left to upper layers to experiment with without jeopardizing the base layer?

That point then leads to mentioning some of the risks, but it’s important to not lose sight of that primary distinction, i.e., it isn’t “should content rewards be implemented at all” but rather “at what level of the network should content rewards be implemented and by whom”.

I said more in other posts re:infrastructure vs one social network (keeping in mind that many social networks with different incentives can be built on a great, agnostic infrastructure). It’s also worth considering that different flavors of such rewards will take place at the upper layers regardless, so is it really necessary to implement a redundant and potential risky version at the base layer (while delaying launch even further)?

As for the risks, I mentioned a few in other posts and fully stand by them.

4 Likes

lbry does pt by tips or charging for access to a media, also they use support and “staking” where the staking is for viewability and support is for the creator, all without algorithms all by manual offer by the people who consume the media.

I would say there is no or will be a algorithm to pt* that cannot be gamed. end of story for me. if we want we can implement in base or in a layer a way for people to assosiate files/media/content with wallet addresses and whoever wants to support the creator developer etc should do manually and with the amount they see fit!

there could be though a system that takes that amount of donations and split it through out all the participating parties, like if you like an app and you donate to it the system could compesate a fraction to all the underlying code/content creators/ etc that is part of the app you donated to!

2 Likes

The biggest techical drawback on to Pt* mentioned is the possibility for gamification or malicious parasitic exploitation. Could be true for a Pay on Put ( PoP) or a Pay on Get (PoG) reward model. This includes farming payments. Caching has been mentioned as a way to mitigate this, but is best used for transient spikes in demand imo. I think it would be good to recap or brainstorm a few attack scenarios. What would an ideal Pt* gaming rig look like? For example, consider the following:

  1. An adversary secures adecent size array of (1000) mobile or other devices each having a unique ip.

  2. Junk content is uploaded to the network with their Pt* address for receiving payment.

  3. Adversary then accesses their own content with their iwn app to receive app and content rewards.

  4. They must then dump the data or clear browser caches as it is received. Each requested chunk is randomly and intermittenly selected to not trigger caching.

  5. Rinse and repeat.

Another possibility is that an adversary could use malware to create a botnet to achieve the same thing for lower cost (no need to pay for bandwidth, electricity, or the devices). Please add any other suggestions or better ways to game/exploit the reward sysrem for profit. Once we can visualize what the attack methods are, it will be easier to devise defense mechanisms against bad actors.

It may not be possible to eliminate parasitic activity, but as long as their effects to the system are minimized, the net benefit could yield a network that is orders of magniture larger than one without Pt*.

5 Likes

A way to mitigate such gaming is to keep the benefits low wrt to the cost, or perhaps the benefits of farming. So cost each scenario, and ensure farming is more profitable than cheating.

3 Likes

I don’t think that tactic works here, consider a zombie botnet working at near zero cost to the adversary.

This is where pay on put mitigates such behaviour. You pay what the farmer gets, so a zero sum game. Just an FYI

5 Likes

Well the network keeps costs (thus payments) to the minimum, its not a profit making system. The minimum obviously will be regulated by farmers coming/going.

So this mitigation is already part of the system when finalised since its something mentioned that is to be aimed for in the algorithm. The network is meant for all and minimum costs is essential to help in that.

Considering the tactic is a stated goal to keep costs (thus payments) at a minimum.

This is a myth that zombie botnets have near zero cost. There are those who capture the zombies to do as they are command and there are those who buy the services of these zombies. Even if its a inhouse affair there are costs to capture the zombies and replace them when cleaned which happens regularly with microsoft’s malware removal with the updates.

Excellent point. And combined with the algorithm keeping costs low anyhow, that zero sum game is potent.

3 Likes

You mean Pay on Put for farming reward right? This doesn’t appear to work well for PtP though. The goal is to reward popular content, not junk, so you need to reward via Pay on Get, no? I believe there are ways to do Pay on Get using DBCs without having elders keep network state.

1 Like

Yes

It would not work well for PtP.

For PtP Get is probably a bad metric I think. We need to find mechanisms to “value” data. Get was a great initial idea, but I am unconvinced it’s a winner. With video now so popular, there is a ton more data on a video than on any scientific paper. They both though have only one root dagta_map and perhaps we can consider that?

But it still leaves the question of a vid or image that’s a meme or viral outpacing other data in perhaps an unfair manner?

Spitballing here for sure.

4 Likes

Everything has a cost, to setup, maintain and manage. But with a botnet there’s also a lost opportunity cost. For this attack, all we have to do is ensure there are more profitable things to do with a botnet than cheat Pt*.

1 Like

Would it not be simply including those Pt* accesses in the division of the Pay on Put.

If you are using the access to the datamap as the indicator of access to APP or file then this greatly reduces the tallies the section needs to keep.

So tally the number of Gets from last payment for farmer rewards and tally public file accesses (that have a pay ID).

So incoming payment (on quote) is distributed (as a possibility)

  • get total Gets weighted. Say farmer gets have weight of 10 and Pt* file header gets weighted with one.
  • total.weighted.gets == 10 * farm.gets + file.header.gets
  • farmers portion == 10 * farm.gets / total.weighted.gets
  • Pt* portion == file.header.gets / total.weighted.gets

I realise this needs static data kept on the files Got and count. But if paying on each Put then this will always be small. Also if this was used then the Pt* is the same for Apps and files and file bloat is meaningless. OR If number of chunks in the file is important for Pt* reward then a log of size could be used to “weight” the file header, and using log stops a 10GB movie being paid 10 times a 1 GB movie

And if use the above example then Pt* would be a lot less than the 10% of farmers reward rate. This is because the Pt* is on file header and not the individual gets for chunks in the file. And the game of repetitive access of file header needs mitigation. Perhaps the count for any file is kept to 2 times the average of all file headers. And since this is happening on each Put (or set of Puts) you would expect that file header Get counts would be tiny anyhow.

1 Like

It’s not feasible to assess the value of a piece of data, not for the network, not for me, not for humanity.

Life has the same problem, so maybe we can learn from the solutions there. What’s the value of a gene, a genome etc? How does evolution choose which genes to value, which genomes? Things like reuse, longevity, diversity spring to mind. It also appears that we don’t know what much of each genome does, or that much of it is redundant, noise (unlikely IMO!).

We need some knowledgeable input to understand the lessons available from evolutionary genetics, but I’m mindful that science really doesn’t understand this yet, and that what understanding we have may still change dramatically. For example with the theory that genes were seeded from space rather than life having always to start from molecules. That’s always seemed plausible to me but even as mounting evidence points towards the cosmic origin of life in earth, the scientific community are resistant to the idea.

3 Likes

I am in a similar place right now, but wondering … there is an angle and it may not be data or put/get but something else? What though I have only fog right now, but that’s normal.

6 Likes

The current web is largely based on something similar to get paid per get, though the income is from ads instead of the network its running on.

Loading a website is cheap, so inevitably people try to use bots to keep reloading pages and clicking on ads. What’s done about this is using extensive tracking and various measure of real user behaviour to try to determine what is a bot and what’s not. This is an ongoing cat and mouse game.

It seems pretty clear that as long as the cost of doing a GET is less than the potential payment for that GET, someone will load up cloud instances fetching pages they’ve uploaded over and over and then use the revenue to load up more even cloud instances, fetching the pages over and over ad infinitum. If the payment for the GET is less than the cost of doing a GET, it will be very little indeed.

Perhaps some kind of valuing based on links could be used, something like PageRank, that would pay based on the number of links, importance rank of the links and the freshness of links.

2 Likes

In my opinion, the network and AI (at least not for foreseeable future) will not be able or would we want it to be able to assess value. Society’s are too diverse and fields of education too and maybe a song/band will bring world peace, there was a movie about that LOL.

But value is best left to the beholder and in more general sense the society one wishes to belong to.

The type of data though could be assessed as having more or less value in terms of reward, maybe not too.

But one metric for a general assessment is length. A movie will in general have more work or effort in producing or even providing to the network than a snapshot of the landscape. A long file will generate more Gets/usage of the network and in a general sense more adoption. Yes there are outliers and its on a scale, but in the more general/common situation. But so does multiple files. Movie compared to picture album. Or cat videos compared to a 2 hour movie.

I would suggest that any Pt* using only per file is as bad as a Pt* using chunks. The in between that brings some balance is to use a log function on number of chunks and the file header has the number of chunks so easy enough to use in my suggestion above.

1 Like

This is of course an application layer solution and useful in automatic tipping that one might set up for their account when they browse sites. Optional of course to if and levels of tipping

Caching kills this once you get to the level you might actually earn enough to pay for your cloud. Using cloud services to farm would be more profitable and grow your farm collective faster. Considering farming pays a whole lot better. Remember you have the world accessing farms not a relatively small cloud services.

1 Like