Topic: [ANN] Pigeoncoin (PGN) – a cryptocurrency network with a new X16S (shuffle) algo - page 3. (Read 618621 times)

The bull market is coming and I am sure the latest news about this will also push the price and hit $2 each soon.
 

Happy April fools !!!

interesting to see a btc talk thread ann so inactive that youre moving onto a different project yet named on the OP lol

oh bear market

One year ago Pigeoncoin was publicly launched.  I have been very interested in Ravencoin since it was just an idea being passed around at Bitcoin conferences.  PGN was a fork of RVN and I only noticed it due to that fact. Immediately after PGN project was public knowledge I noticed what most experienced crypto folks would, that the project was premined (~100,000,000 coins) by a group before giving the public a chance to get in on the ground floor.  The response to pointing this unfairness out was very hostile but also a barely believable admission 'We were young in experience and naive'.  I believe bringing this up might have been among the first reasons given to ban me from that community.  I evaded the ban, because I had mined a little PGN to play around with and wanted to have some fun advising these newcomers on how to run a project I have a small investment in.  

Crypto is a well paying hobby to me.  I've learned a lot from my time building market tools for PGN that will help me in all of my market activities.  I am very grateful that I've spent the time learning more of the economics of PoW mining with the PGN parties (wild difficulty swings due to the Satoshi difficulty retarget system that they waited FOREVER to fix against my advice) and later on with mining arbitrage.  I've been involved with almost a dozen crypto projects and have seen quite a bit of both good and bad ideas.  I've advised crypto projects both big and small in market capitalization under various pseudonyms for the past 4 years of my life in official and unofficial capacities.  This is by far the most inexperienced group I have worked with to date, but I was still having a lot of fun sharing my opinions and watching them come true despite being banned repeatedly for sharing them.  

Eventually the bans stopped and I decided to help their lead developer with an introductory paper to the idea of a decentralized social network built on top of masternodes.  Unfortunately they never had any time to put into it, and while we both had different ideas about how the protocol should look, the only idea that ended up on paper was my own.  Just prior to me publishing the paper for my own idea, The Flamingo Social Protocol, I became a PGN community representative.  I thought this may give me a platform for my ideas to better be heard and hopefully to help the project, but it became very symbolic in nature after seeing how my objections were so easily disregarded by the a majority of reps without much discussion concerning an upcoming release.  They wanted to rush it, and it ended up being a shit show like I had said it would be.  'At least the project didn't die' they said.  It was pretty infuriating watching these folks so nonchalantly almost kill our meager investment in the project.

The lead developer claimed that the Flamingo developers wouldn't be able to build their vision for the protocol due to a concern over a very minor part of the protocol, which ironically enough has since been solved by choosing the correct code base to start with and protocol architecture.  The work has already been done for us thanks to open source software and a bit of creative thinking.  I tried getting them to discuss the objection further to no avail.  The leading voice in the reps group took the objections as the gospel instead of applying any logic or trying to understand the objection better.  This was an unwinnable debate, from my view.  I volunteered the past year of my life to PGN because it was fun, and it's only common sense that I leave when that aspect of the project is gone, so this is my goodbye.

You can follow how the Flamingo Social Protocol evolves on our discord: https://discord.gg/qnxmHcM
Or follow our Bitcointalk PRE-ANN to stay current on our completely fair and public main-net launch here: https://bitcointalksearch.org/topic/pre-ann-flamingo-social-protocol-decentralized-social-networking-5118193

Here is an older post for solo mining. I did it for a while and hit a couple of coins.
If you can't work through the conf file and set up code, then try BSOD.PW. They have a Solo option that is available for PGN.

Congrats!

So solo mining is not disabled for this coin. You just need to connect to your wallet through your LAN instead of the 'localhost', hence using 192.168.x.x instead of 127.0.0.1.

Thanks for sharing your findings here!

I’d like to start this article off with a big thanks to Satoshi Nakamoto and the cypherpunk community for creating viable decentralized replacements for monolithic actors. Thank you. You have given us more efficient, open, and fair systems by leveraging decentralized cryptography. You are an inspiration to freedom activists everywhere and history will forever be changed by what you’ve built. It is a hope that the Flamingo protocol will provide a viable option for the public to replace the social media companies who leak our otherwise private data to the highest bidder as a business model.

The goal of this paper is to be an introduction to the Flamingo protocol, a decentralized social network protocol for anyone in the globe to use and interact with their friends and followers on. This paper will answer some of the initial questions about the protocol and it precedes a higher technical level white paper. Hopefully it inspires some questions for the reader, too, and we’d love to have you share them with us on our discord. There is a lot of work that needs to be done. If you have an interest or passion for ideas that expand human freedom, or you desire to make tools that guarantee privacy, and you want to work to make Big Social obsolete, stop by and hang out.

A Regiment of Flamingos
The masternode protocol was chosen as the platform to build the Flamingo protocol on top of. It is an ideal candidate for a number of reasons, but mainly because there is a need to encourage the nodes storing the social data to be available 24/7. Masternode collateral is used to provide simple currency services, like enabling coin-joins, to give some privacy to end-users of the currency. A new function will be added to masternodes which will provide storage for data on the network. We will continue to refer to these as masternodes, but they will have noticeable differences for those accustomed to operating masternodes.

First, with 250,000 collateral and 5000 coins mined every minute Flamingo masternodes will have a relatively low collateral count compared to most masternode blockchains. For every masternode, there must be a 10GB partition dedicated for storage by that node. To put this into perspective, at the time we anticipate the network will start ‘accepting users’ (around 420,000 blocks from launch), the network should be able to serve a theoretical max of 84 TB of storage while adding about 288 GB to that total everyday. The storage requirements may change depending on community and network demand, but the coin collateral amount should never be changed, especially to try and react to temporary economic factors.

Another difference from traditional masternodes is that you can run as many Flamingo masternodes on a single daemon as you are capable of with your hardware. Typically only a single daemon will be necessary for all of your Flamingo protocol masternodes. There are legitimate concerns with other masternode networks having a concentration of masternodes on a single server, but our unique use case is not affected by them. With our low collateral amount, we are encouraging many operators to run multiple nodes on their Flamingo masternode servers.

The specifications and modifications were inspired by our use case for masternodes, not to make a quick profit. Often we hear comments about how the ‘collateral is too low’ and ‘what about ROI??’. The “desired” specifications of many users are often what turns many other people off to masternodes as they lead to a short-lived pump and dumps. It’s our opinion that having responsible masternode specifications which are structured to support our use case will allow for organic creation of economic rewards in the event of meaningful adoption. In other words, a fairly incentivized and sustainable model.

A Social Network
API/RPC calls will be added to the reference client to manage social data which users control the keys for. Social data includes the content of your posts, but also who your friends or followers are, and your pseudonyms. As there will no doubt be a demand for it, data can also be public. Data will also come with an expiration date after which the data will be removed from the network.

It’s very likely that the most common user interface for social data will be a small, possibly client-side, java script front end, which will be maintained alongside the core client. Instead of trying to add the full set of social features to a clunky qt wallet which will see little use for actual social networking, the reference client will be unchanged and mostly used by developers, miners, traders, and masternode operators.

Since we are specifically modifying the masternode protocol to serve our use case, it makes sense to allow people who want to host their own content to also do so. To that end, we will allow a special kind of masternode to join the network who will likely still require some collateral, but it will be a negligible amount compared to the 250,000 tokens mentioned above. They also will not get paid from the block reward like masternodes that have this 250,000 token collateral, but there’s much more to come on this topic later. It’s important enough to mention for the scope of this article.

Social data that is not public will be encrypted on the client side and then uploaded to the network. The normal user would basically load their profile from a synced node, and then fetch the data for the freshest ‘timeline’ from the masternode network. How that data is stored on the masternode network is a hot topic in our discord, so please stop by if it piques your interest.

Data will need to be stored redundantly to accommodate masternodes activating/deactivating without the data being completely lost. The level of redundancy will be the result of an equation that divides total masternode network capacity by total data to be stored. The result will be a useful indicator to show how the network is handling the load and will likely be the motivation for any discussion about the storage requirements of masternodes.

They aren’t going to build it
The large social media corporations know exactly what they are doing with our data, and it’s likely that the general public won’t shift easily from the status quo. Success will only come if the general public lets it, but building a trust-less platform for social media where the user is in complete control of their privacy is worth the risk of time. If you are interested in helping to build this tool and community, please join us: https://discord.gg/qnxmHcM

Thanks for your calm and kind response. Good luck in your project too. From what I saw when I was on that discord, I got to say that you, Nick Kliesen and neonnexus were in the few that raised the quality of discussions. What turned me off is some other members that were just spewing non-sense all day long as if they were waiting for PGN to get rich.