Pigeoncoin

On March 21st 2018 Pigeoncoin was launched as a proof-of-concept network for a new algorithm called X16S (shuffle). Pigeoncoin is a forked-fork of Bitcoin. We do everything on Discord. https://discord.gg/SZcf63h

I didn’t want a big richlist so I tried to bring CPU miners in on day one while handling the to-do list. On day five, I asked our group of twelve to start onboarding more miners... the word spread like wildfire through the Ravencoin community. Hashrate jumped from 1.5 MH to 20 MH in an hour, and membership jumped to 100.

The next day, last night, a GPU randowhale nearly burned down the network. @brianmct bailed everyone out with his quickly patched nevermore Nvidia GPU miner. We have one pool up and more are coming. We wanted more time on CPU mining but it just wasn’t in the cards. Hashrate is now 9600 MH and we have ~300 members.

The network has been active for six days. We’ve been out straight since launch. I apologize for not posting sooner. The last 24 hours have caught us with our pants down. After posting this [ANN] I’m going to bed. I hope everyone else is, too.

Why did all this happen so fast?

Some history:

I was an early miner on the x16r (random) Ravencoin network. x16r uses the last sixteen digits of the previous block hash to call its sixteen sub-algos. This pseudo-randomness is said to improve ASIC resistance.

I noticed that x16r GPU miners experience fluctuating power and hashrate. I figured this was because each algo used different amounts of power, and if the hashcycle composition was majority high power algos by chance, it would cause the power to rise. I found the uncertainty made it hard for miners to tune their system, while reducing the efficiency and potentially the lifespan of power supplies. I felt the total cost of mining with x16r could be improved.

My solution was to use the same last sixteen digits to reorder a list of all sixteen algos, and then use that “shuffled” list to call the sixteen sub-algos. The result is a hashcycle with every sub-algo represented once. The composition would be constant, but the randomness would be preserved.

This gave birth to X16S (shuffle) which maintains the legendary randomness of x16r while providing consistency for hashrate and power demand.



Hashrate consistency comparison between x16r and X16S (shuffle).

X16S Whitepaper: https://github.com/Pigeoncoin/pigeonbrand/blob/master/X16S-whitepaper.pdf



Blockchain Stats

We have a 1 minute block time, 5000 PGN reward, 21B cap, 2016 block retarget, 16 shuffled algorithms (X16S shuffle). There was no genesis block reward. There was no premine.

Timestamp reads "Reuters 21/Mar/2018 China stays on the sidelines as Venezuela spirals downward.”


Roadmap

Our initial goal was to prove the algorithm works as intended. Well, we proved success two weeks ahead of schedule thanks to our community, so now we get to try to catch up in all other areas! Expect an official announcement regarding roadmap very soon.


Links

Discord: https://discord.gg/SZcf63h
Whitepaper: https://github.com/Pigeoncoin/pigeonbrand/blob/master/X16S-whitepaper.pdf
Core wallet: https://github.com/Pigeoncoin/pigeoncoin/tree/master/binaries
Nvidia GPU miner: https://github.com/brian112358/nevermore-miner-x16s/releases/tag/v0.1-alpha
Explorer: http://explorer.pigeoncoin.org
Website: http://pigeoncoin.org But, we've been too busy to make one. Everything is on Discord.


Social Media

In order of use...

Discord: https://discord.gg/SZcf63h
Github: https://github.com/Pigeoncoin
Twitter: https://twitter.com/Pigeoncoin
Telegram: https://t.me/Pigeoncoin
Medium: https://medium.com/@pigeoncoin
Reddit: https://reddit.com/r/Pigeoncoin
 

Addendums

As I was writing this [ANN], Enemyminer announced an alternative X16S (shuffle) Nvidia miner.

Also, I have no idea why IMG tags aren't working.

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

Flamingo Social Protocol: Introduction

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

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.

OK Kool ...

So what do you seriously propose for PGN? All that has been stated earlier is simple enough, though you want to push forward with a coin that was in reference to the MGT CodeBase back when MGT was one of the hottest mining coins? It would take a lot more than just a push in the right direction as I see it, and I can see you know this also. What is it you really need to get going, and what is it that should be achieved by all this effort, that many many MANY other coins have already done?

Not an attack here. I am seriously intrigued by what you are aiming at here.

#crysx

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 encrypted social data for the end users to be available 24/7.  Masternode collateral is also used to provide simple currency services like performing coinjoins to provide some privacy of end-users of the currency.  A new function will be added to masternodes which will provide storage for social 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, flamingo masternodes will have a relatively low coin count at 250,000 required to run a node.  For every masternode, there must be a 10GB partition dedicated to that node.  To put this into perspective, at the time of writing, the network would be able to serve a theoretical max of 60TB of storage and adding about 144GB 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 you can run as many masternodes on a single daemon as you are capable of with your hardware.  This drastically tips the scales of running a node in favor of the operator compared to traditional masternodes where each node will need a separate VPS.  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 effected by them.  With our low collateral amount, we are encouraging operators to run multiple nodes on their masternode server.

Don't bite the hand that feed you!  I've spent a couple of months on PGN's discord by the way... Very low level of technical discussion there and lots of non-sense.

Really? ...

So you decided to use a new fresh profile to do this with ONE post AND expect people to take this seriously? Come on mate!

#crysx