[OLD] Cryptog's datafeeds - BETA

[Hyena]

I would disagree with it. If at any point of time we have a set of motions that includes the fingerprint of a representative then we can compare that set with the representative’s motions as given in their datafeed URL. This means that solely from the block chain we wouldn’t be able to reconstruct the history of the proportion of the datafeed in overall votes but we would be able to get the proportion at the current moment. Seeing the current state is better than having no knowledge at all. The history of the representative’s votes could be logged by means outside the block chain.

[creon]

then we can compare that set with the representative’s motions as given in their datafeed URL.

Ah got it. So you want to compare it to the live data. Yes that would certainly work! In this case I guess the data feed provider should ideally always add a random motion.

[Hyena]

Yes, adding a salt to the list of motions seems like a good idea.

[cryptog]

deleted 876e10611809f3a90f2216fb61f107d3b7c9c469 because it passed.

[sigmike]

Would it somehow harm the network if each datafeed had a random identifier

There are some issues:

• privacy: the data feed consumer may not want to reveal he’s using this data feed
• security: if it’s clear a data feed has a large consumer base then it becomes a target

The data feed system was designed with the goal that you can’t differentiate someone voting by himself from someone using a data feed. This is not completely achieved but adding an identifier would be a step in another direction.

[Hyena]

Ok that’s a good point, I guess. But from the attacker’s point of view, isn’t it possible to approximate a data feed’s popularity anyway? If that can be done then it’s easy to still target popular data feeds. Does this secrecy really solve a problem or is it just an easy obstacle for the attacker?

[sigmike]

There will probably always be a way to statistically identify data feed popularity. But there are ways to make that less reliable (maybe up to making it useless, or nearly equivalent to identifying popularity of the voted items).

[Hyena]

Or, we could take a conservative means to defend against a targeted attack on popular data feeds — by replicating the data feed. We could even go as far as to include the datafeed in the block chain itself. Then, an attack on the data feed would become equivalent to an attack on the whole nubits network.

[cryptog]

• Voting in favor of Nu Lagoon.

• Reduced parking rate from 25% to 10% because I believe Nu has increased buy liquidity sufficiently.

[cryptog]

• Deleted Nu Lagoon motion because it passed.

[cryptog]

• Reduced park rates from 10% to 5%

Reason: At the time of this writing Nu has 70k of parked NBTs.
The buy side and sell side are balanced around 50k each.
There is no selling pressure.

[cryptog]

• removed bittylicious custodian grant vote because it passed.

[cryptog]

• deleted 1ce96336ac866c29cbcbf0908b0752b0065a3af4 because it is not relevant any more.

[cryptog]

• added: c2096080fab25dc702424117e82d2e29a84c50c4

[cryptog]

• added: BNUpooLxGbHXSs7Qcwi5EBXzZ82BbWwsMN, 1800 : Trust-less liquidity pool operation on Bittrex

[crypto_coiner]

How many nushareholders are subscribed to this datafeed?
Is datafeed subscribing efficient?

[cryptog]

Good question.
I guess there are only a handful of suscribers.

[Hyena]

You can approximate it from the requests to your feed and perhaps count the number of different IP addresses making the requests periodically.

[cryptog]

Right.
I ll try to write a small script though i m not a programmer.
Github api should let you get this kind of info i guess.

[cryptog]

• deleted: trustless liquidity pool on bittrex because it passed.

• added: custodian grant to get NBT added on coinpayments because we need to do something about making nbt a currency for online payments.