[ANN] New Piggycoin [PIGGY] | 3% interest | Web PiggyBank | Android PiggyBank

[greenmo]

Something seems to be wrong with https://chainz.cryptoid.info/piggy/#!extraction as the stats don't seem to be updating there. Perhaps it is related to the software update that came out overnight?

Thanks for spotting it.  Neurocis is asleep and the CryptoID guy is on a kind of holiday but hopefully they'll take a look at it when they notice my messages :8]

Fixed ;8]

[kangkangyo]

out of sync ,update stop in 609318 block

what can i do for it?

[piggycoin]

out of sync ,update stop in 609318 block

what can i do for it?

What version wallet?

[greenmo]

https://twitter.com/Poloniex/status/627647475638210560

Poloniex to cut off New York users starting 8th August 

[neurocis]

A post I think is long overdue from myself updating the community from a core perspective and the direction of PIGGY from a technical point of view.

The window for the swapping of coins has now closed for close to one month and requests to swap have been few and far between so I think it safe to announce PIG to PIGGY swaps are now officially CLOSED. That does leave what to do with the remaining unswapped, which is still being held across the team members. In post https://bitcointalk.org/index.php?topic=633803.msg11694570#msg11694570 a multisig wallet was suggested for holding of team funds, which I agree is the best solution over current cold storage. MultiSig works in PIGGY presently but is not user friendly in the slightest, I hope to (somewhat) address that with this short "Technical Roadmap".

This announcement will be spread over a few posts, each focusing on a particular deliverable on the roadmap, those being (in order of my priority):

1. "EasySend" implementation - The intent of "EasySend" is to eliminate the need to remember cumbersome PIGGY addresses and instead provide some type of directory to lookup names to addresses in a trustless, decentralized manner. "EasySend" name registration is operational once again on the website but is centralized and not presently integrated into the wallet. This deliverable will take a phased approach taking cues from a number of other projects, those being dnkey, keybase and current methods used for the publishing of PGP keys via DNS. My vision is to be able to setup in-wallet various name to address providers (directories) with the actual lookup being via the internet DNS system. Details of the specific phases of implementation will be in a further post.

2. MultiSig - This will also take on a phased approach. The largest hurdle in the implementation of multisig is the communication of the transaction between the parties which can legitimately sign it prior to it being submitted to the network for inclusion in a block. We have successfully tested multisig transactions using the console of the current wallet, but once again that is a cumbersome process. Initial proof-of concept will be by porting the coinb.in wallet to PIGGY making such transactions a bit more "friendly", but still not ideal. However this would be sufficient for the creation of a multisig wallet to hold team funds (after rigorous testing of course) with some added benefits of being an alternative web wallet and educationally giving a view "under the hood" for the more technically savvy. Once concept is proven porting of the co-pay and/or electrum would be the next phase of implementation. Vision being to first implement in a user-friendly web-wallet, then into the core wallet leveraging a bitcore-wallet service or electrum for inter-wallet communication of transactions awaiting signatures.

3. Colored Coins - With the porting of Coinb.in comes the ability to experiment with OP_RETURN messages on the PIGGY blockchain. Utilizing OP_RETURN a simple system of coloring coins will be (actually has been) created and tested. To keep things simple, effective and easy to convey, so called "rainbow coins" will not be supported. Once a group of coins is colored they remain that color until "bleached" by being mixed with coins not of the same color (or technically Unspent Transaction Outputs). Once again more details in a further post.

4. Hard Fork - May be needed as determined by discovery in the delivery of 1 through 3 together with bugfixes to improve the stability of the network. Ideally "easysend" name-address pairs would become encoded into the chain at this point.

Please bear in mind some of these deliverables are quite ambitious and will take time. I have tried my best to find the path of least resistance without "re-inventing the wheel". The more talent we can attract to the team the better. I would especially welcome those with an analytical mind, a passion for blockchain-tech, who wish to learn along side our team while delivering these and other projects.

More to come soon ...

#Oink!

[ebliever]

Sounds good! Just two questions:

1. I didn't understand the reference to "electrum" in point #2 above. Is that related to the Electrum bitcoin wallet somehow?

2. Any good links for information on the concept of coloured coins, and what they can be used for? What would be the basic intention in an educational environment, for example?

[neurocis]

Sounds good! Just two questions:

1. I didn't understand the reference to "electrum" in point #2 above. Is that related to the Electrum bitcoin wallet somehow?

2. Any good links for information on the concept of coloured coins, and what they can be used for? What would be the basic intention in an educational environment, for example?

1. It is completely related to the electrum wallet and the stratum protocol it employs to enable a lightweight wallet as well as facilitating the communication of multisig transactions via it's "cosigner pool plugin". Ref: http://electrum.orain.org/wiki/Multisig_Wallets. In all honesty however, co-pays implementation of the "bitcore-wallet service" looks much more robust and user-friendly.

2. Probably the best link is https://en.bitcoin.it/wiki/Colored_Coins, which has other links. In so far as application within the mandate of PIGGY think of a set of colored coins representing merit badges, or virtual collectibles (Possibly a PIGGY-PokeMon cards online game using colored coins to represent in-game assets). GreenMo posted a great use-case where a teacher colors a set of coins and those are used as currency in-class during a lesson in trade / economics. They can also have great impact in the management of the coin itself as a digital asset, representing voting ability in the distribution and use of team-held funds.

[fairglu]

1. "EasySend" implementation - The intent of "EasySend" is to eliminate the need to remember cumbersome PIGGY addresses

The external repositories can be simpler to curate (in case non-kid-friendly stuff gets in there), however what about having some way to store a "friendly name" in the blockchain rather than involving an external repository? (ala namecoin)

The "friendly name" could be restricted to a "friendly reference", like a profile page from selected social networks, in order to ensure curation.

[kangkangyo]

out of sync ,update stop in 609318 block

what can i do for it?

What version wallet?

version v1.2.2.1 ，now stop in 632851 block.don`t know what this!

[neurocis]

out of sync ,update stop in 609318 block

what can i do for it?

What version wallet?

version v1.2.2.1 ，now stop in 632851 block.don`t know what this!

Try adding the following lines to your newpiggycoin.conf:

Code:

connect=94.23.186.186       #Piglet
connect=192.210.139.104     #Sceptre
connect=198.23.155.143      #VENOM - neurocis
connect=172.245.32.43       #VORTEX - neurocis

That will force you to connect only to our main nodes until you load the entire chain. Afterword you can stay with those nodes or remove the lines and go back true P2P.

neurocis.

[neurocis]

1. "EasySend" implementation - The intent of "EasySend" is to eliminate the need to remember cumbersome PIGGY addresses

The external repositories can be simpler to curate (in case non-kid-friendly stuff gets in there), however what about having some way to store a "friendly name" in the blockchain rather than involving an external repository? (ala namecoin)

The "friendly name" could be restricted to a "friendly reference", like a profile page from selected social networks, in order to ensure curation.

The end-goal would be to have some form of name resolution encoded onto the chain, however initial stages will be exactly as you suggest - using external repositories for curation.

Easysend will be implemented with the concept of a "Name Resolution Provider (NRP)" which will resolve a name to a list of possible PIGGY addresses, each potentially from a different provider. For example if there were Twitter, Facebook, Freenode and DNKey NRPs the user may be presented with 4 addresses, 3 of which are the same, I would select one of the 3 same to send to as it would be less likely that all three providers were compromised. The 3 same would likely be displayed in the selection dialogue as having a rank of 3 vs the other with a rank of 1.

So the user flow would be:

Enter a name in the address box ... I enter neurocis{at}piggy-coin.com ... Upon clicking send (an address which fails validation triggers a lookup) or lookup each provider is queried by the client wallet directly.

1. In the case of the Twitter NRP, it would strip after the @ and perform a search on "from:neurocis #MYPIGGYADDR" https://twitter.com/search?q=from%3Aneurocis%20%23MYPIGGYADDR&src=typd.
2. In the case of DNKey a DNS lookup TXT lookup on neurocis.dnkey.piggy-coin.com would result in https://mxtoolbox.com/SuperTool.aspx?action=txt%3aneurocis.dnkey.piggy-coin.com&run=toolpage. The us of the subdomain dnkey deviates from the dnkey standard but lends more flexibility in management of the TXT records by the domain holder.
3. Cycle through other NRPs and aggregate results.
4. User is presented with a list, in this case one address " (+2) poixahFnMBaBwJGrDTPqyNzzKesQghauQ7" potentially with links to the NRP specific lookup result.
5. Address is selected and User is presented with an option to save in local address book.
6. Transaction proceeds as usual.

Additional NRPs can be added as developed and "plugged-in" to the wallet.

The first NRPs that will be developed would target DNKey and Twitter, with others to follow, eventually including a blockchain based NRP.

The DNKey NRP for the domain Piggy-Coin.com would serve as a boot-strap with public registration (valid email address for verification requested).

Additionally these may be extended to support trust signature(s) as well as instead of the PIGGY address, a link to an address generator (HD wallet?) uncoupling an identity from the address used.

[fairglu]

Sounds good!

One option for blockchain-based validation could be to use an OP_RETURN: you would make a transaction to yourself, with an OP_RETURN output containing info about the account, f.i.

   vin: pMyPiggyAddress 100
   vout: pMyPiggyAddress 100, op_return twitter:awesomePiggy

the vin would ensure that the person controls pMyPiggyAddress, the op-return would tell this person's twitter account is "awesomePiggy", at this point this is of course not enough (you could claim to be anybody else), so the client would still have to lookup twitter like you outlined.

The idea would be avoid someone falsely claiming that an account is his, which if you only trust external repositories is easy. This would avoid someone claiming an existing stash is his, in case the actual stash owner is gone/offline/not aware.
Could be useful for kids, as they have a tendency to go for "mine is bigger than yours", or for whatever nefarious purposes

Also it could optionally serve as a "money sink" if the above mechanism requires to burn some piggy in the op_return for it to be taken into account, even just a token amount.

[alexius89]

A post I think is long overdue from myself updating the community from a core perspective and the direction of PIGGY from a technical point of view.

The window for the swapping of coins has now closed for close to one month and requests to swap have been few and far between so I think it safe to announce PIG to PIGGY swaps are now officially CLOSED. That does leave what to do with the remaining unswapped, which is still being held across the team members. In post https://bitcointalk.org/index.php?topic=633803.msg11694570#msg11694570 a multisig wallet was suggested for holding of team funds, which I agree is the best solution over current cold storage. MultiSig works in PIGGY presently but is not user friendly in the slightest, I hope to (somewhat) address that with this short "Technical Roadmap".

This announcement will be spread over a few posts, each focusing on a particular deliverable on the roadmap, those being (in order of my priority):

1. "EasySend" implementation - The intent of "EasySend" is to eliminate the need to remember cumbersome PIGGY addresses and instead provide some type of directory to lookup names to addresses in a trustless, decentralized manner. "EasySend" name registration is operational once again on the website but is centralized and not presently integrated into the wallet. This deliverable will take a phased approach taking cues from a number of other projects, those being dnkey, keybase and current methods used for the publishing of PGP keys via DNS. My vision is to be able to setup in-wallet various name to address providers (directories) with the actual lookup being via the internet DNS system. Details of the specific phases of implementation will be in a further post.

2. MultiSig - This will also take on a phased approach. The largest hurdle in the implementation of multisig is the communication of the transaction between the parties which can legitimately sign it prior to it being submitted to the network for inclusion in a block. We have successfully tested multisig transactions using the console of the current wallet, but once again that is a cumbersome process. Initial proof-of concept will be by porting the coinb.in wallet to PIGGY making such transactions a bit more "friendly", but still not ideal. However this would be sufficient for the creation of a multisig wallet to hold team funds (after rigorous testing of course) with some added benefits of being an alternative web wallet and educationally giving a view "under the hood" for the more technically savvy. Once concept is proven porting of the co-pay and/or electrum would be the next phase of implementation. Vision being to first implement in a user-friendly web-wallet, then into the core wallet leveraging a bitcore-wallet service or electrum for inter-wallet communication of transactions awaiting signatures.

3. Colored Coins - With the porting of Coinb.in comes the ability to experiment with OP_RETURN messages on the PIGGY blockchain. Utilizing OP_RETURN a simple system of coloring coins will be (actually has been) created and tested. To keep things simple, effective and easy to convey, so called "rainbow coins" will not be supported. Once a group of coins is colored they remain that color until "bleached" by being mixed with coins not of the same color (or technically Unspent Transaction Outputs). Once again more details in a further post.

4. Hard Fork - May be needed as determined by discovery in the delivery of 1 through 3 together with bugfixes to improve the stability of the network. Ideally "easysend" name-address pairs would become encoded into the chain at this point.

Please bear in mind some of these deliverables are quite ambitious and will take time. I have tried my best to find the path of least resistance without "re-inventing the wheel". The more talent we can attract to the team the better. I would especially welcome those with an analytical mind, a passion for blockchain-tech, who wish to learn along side our team while delivering these and other projects.

More to come soon ...

#Oink!

Do you have any estimated Dates?

[neurocis]

2. MultiSig - This will also take on a phased approach. The largest hurdle in the implementation of multisig is the communication of the transaction between the parties which can legitimately sign it prior to it being submitted to the network for inclusion in a block. We have successfully tested multisig transactions using the console of the current wallet, but once again that is a cumbersome process. Initial proof-of concept will be by porting the coinb.in wallet to PIGGY making such transactions a bit more "friendly", but still not ideal. However this would be sufficient for the creation of a multisig wallet to hold team funds (after rigorous testing of course) with some added benefits of being an alternative web wallet and educationally giving a view "under the hood" for the more technically savvy. Once concept is proven porting of the co-pay and/or electrum would be the next phase of implementation. Vision being to first implement in a user-friendly web-wallet, then into the core wallet leveraging a bitcore-wallet service or electrum for inter-wallet communication of transactions awaiting signatures.

Things are progressing well on this and I will be pushing out Piggy-Coinb.in by the end of the month. It is also about 85% that I will also have transaction loading as well as submit to network working by that time. EasySend and MultiSig seem to be converging with one another when I look at speed-of-delivery as I can implement a javascript in-browser version hooked into coinbin and/or copay much faster than delivery in the wallet GUI.

With the transaction loading in Piggy-Coinb.in I have ported most of BitPay's Insight block explorer, and with that comes PiggyCore. PiggyCore is a foundation block for delivering PiggyPay across all platforms, the port of copay for iOS, Android and Web. This will be a PiggyCoin exclusive as no other PoS coin presently has a functional bitcore (aka PiggyCore) to build features upon. There is lots of development happening on top of bitcore and the bitcore wallet service which would be opened up to PiggyCoin. Thats above and beyond having a best-in-class MultiSig wallet cross-platform.

So approx. timeline:

1. Piggy-Coinb.in - End of month.
2. Piggy-Insight, Insight-API and PiggyCore - Mid Sept.
3. EasySend Twitter and DNKey for Piggy-Coinb.in - Early Oct.
4. PiggyCore Wallet Service and built on that PiggyPay MultiSig web wallet - Early Nov.

Further timelines TBA.

Note: With the PiggyCore Wallet Service the largest barrier to development of PIGGY-based games and apps is removed; Dear Team, lets get our gears turning on PiggyTasks!!

neurocis.

[neurocis]

So approx. timeline:

1. Piggy-Coinb.in - End of month.
2. Piggy-Insight, Insight-API and PiggyCore - Mid Sept.

I will be pushing the current revision of coinb.in out to the main website tonight, it is in the Team repos. Note that the UTxO (for transaction inputs) lookup and submit to chain will be inoperable until:

 a) The insight-api is fully ported.
 b) Someone decides to write to, say, Crypto.id's API (at least for the UTxOs).

However the Insight port is coming along nicely, X11 has been integrated into the PiggyCore (bitcore) port, it is reading blocks via RPC and direct from DAT file, just addressing CoinStake transactions now. So this one looks like it will be out the door before Mid-Sept.

#Oink!

EDIT: PiggyCoinbin is now available at https://piggy-coin.com/PiggyCoinbin/#home. This a BETA release and features like loading unspent (balance) and broadcast have not been implemented so they have to be manually entered, and the transaction broadcast via the piggycoin wallet console. I also need to update references from bitcoin to piggycoin.

[J1mb0]

How do you do staking on newpiggtcoind daemon?

[neurocis]

How do you do staking on newpiggtcoind daemon?

See reply @ https://bitcointalk.org/index.php?topic=1168904.msg12311252#msg12311252

#Oink!

[neurocis]

So approx. timeline:

1. Piggy-Coinb.in - End of month.
2. Piggy-Insight, Insight-API and PiggyCore - Mid Sept.
3. EasySend Twitter and DNKey for Piggy-Coinb.in - Early Oct.
4. PiggyCore Wallet Service and built on that PiggyPay MultiSig web wallet - Early Nov.

Further timelines TBA.

Update:

Things are looking good on this timeline and I expect to be making some updates and releases the beginning of next week.

Neurocis.

[neurocis]

So approx. timeline:

1. Piggy-Coinb.in - End of month. - DELIVERED.
2. Piggy-Insight, Insight-API and PiggyCore - Mid Sept.
3. EasySend Twitter and DNKey for Piggy-Coinb.in - Early Oct.
4. PiggyCore Wallet Service and built on that PiggyPay MultiSig web wallet - Early Nov.

Further timelines TBA.

Update:

Beta release of Piggy-Insight, Insight-API and PiggyCore are complete. I will be deploying these over this week together with updates to coinb.in for unspent transaction retrieval and transaction broadcast to the network.

I believe PIGGY will be the first coin to have a successful port of bitcore for an X11/Proof of Stake coin.

Neurocis.

[ebliever]

Sounds good!