[OLD] Cryptog's datafeeds - BETA

[SkullandHeadphones]

Yes he did, thanks.

[cryptog]

deleted motion: 6f361693a7b248730b41d4292f89dc6f6f166bc8

[Passed] Motion to Make the Nu Source Code Available

This is the finalize motion to make the Nu source code open to the public. For more information about this proposal, and to view discussions about what items some community members belived should be completed on the development roadmap before they will vote for this motion, see: Draft Motion to Adopt An Open-Source License Discussion on adopting an open source license Drafting a check-list to trigger the adoption of Open Source licence REMINDER: Once this motion is passed it will be non-rev…

because it passed.

[cryptog]

put some positive interest rates because of:Park Rate Voting

[cryptog]

reput open sourcing motion because of : Error in motion counting method found

[cryptog]

Modified the parking rates because:

• the buy liquidity has improved (at the time of this writing 50k, previously 20k)
• i mistook annual rates and rates for specific periods.

Previously I intended 5% of return rate for 1 month.
I now reduce that to 2% and I extend the reward period from 1.5 months to 3 months.

Voting for the final proposal for continuing developments on Android wallet from cybnate.
See this.

[cryptog]

Motions:

• Removed 387e7f6ffc7d69311ac2e1d0ca7cd98d4ecbdea9 (because Proposal for Transfer of Liquidity from Existing Grant Reserves passed)

• Added ed7b9fc65dc4e9d9acad61e528420c2690f599d2 (motion to end LPC operations of KTm, Jamie and NSR sales of Jordan Lee)

---

Custodian Votes:

• Removed BPuTsT9FiDLSDihCHxzaieVXoksXqoffHk, 1 (because the proposal for small liquidity by creon passed)
• Added BMKCHYVwRpoAS1iB5iiqqudYy7USctAbkd, 1 (New grant address for continuing liquidity operations)
• Added BRTkmQ7Fz6vkg48iadLD1WfzmF7vech22v, 1 (Bittylicious liquidity provision)

---

Park rates : no change

[cryptog]

Added: 876e10611809f3a90f2216fb61f107d3b7c9c469 : NSR auction

[cryptog]

Deleted 6f361693a7b248730b41d4292f89dc6f6f166bc8

[cryptog]

Deleted BCFQHtHjcisGVHY7sY2jERBHTYqZLhSxmM, 1
Deleted ed7b9fc65dc4e9d9acad61e528420c2690f599d2

[cryptog]

02MAR15 modification

• deleted BMKCHYVwRpoAS1iB5iiqqudYy7USctAbkd 1 because it passed

• deleted B6tBUhTuetuZezgoJCwwqkJNXNQXPCiand 27840 because it passed

[Hyena]

I’m subscribed to this datafeed right now without any political reasons. I don’t always have immediate access to my NSR miner so it’s better if it’s subscribed to a trusted representative. Is there any means to find out how many nushareholders use datafeeds and how much weight do these feeds have in the overall voting?

[cryptog]

Great questions. Probably better to ask @sigmike .

[sigmike]

Is there any means to find out how many nushareholders use datafeeds and how much weight do these feeds have in the overall voting?

No but someone could write a program that frequently downloads the data feed and count how many blocks are voting for the same thing. It would have to separate the vote parts because people can for example update only motions from the data feed.

[Hyena]

Would it somehow harm the network if each datafeed had a random identifier that is not actually a hash of a motion but instead carries the purpose to differentiate the datafeed from the others in the block chain by its weight? For example, in the case of ‘cryptog’, we would convert it to hex which is 63727970746f67 and append zero byte padding to the end getting this: 63727970746f6700000000000000000000000000.

Now cryptog’s data feed would include this arbitrary identifier and a bot could be built that would monitor the block chain and record the proportion of cryptog’s datafeed in the overall voting. What do you think?

[creon]

Yes this would work, the blockchain has no idea which motion is real an which not. However, note that anyone else could also add this motion just to fake the statistics.

[Hyena]

Yes but are all the motions going to the block or just one at a time? If all the motions go to the block then we could differentiate “fake statistics” from real ones programmatically. A real datafeed vote would include all the motions of the representative including their identifier.

[creon]

Its all motions, but also the data feed provider may change the content of the feed - theoretically on each block (which could even make sense to model a weighting of votes). So from the set of motions itself you can not be 100% sure about the origin.

[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.