Peerunity v0.2 Requirements - Feature Requests and Proposal Discussion

Projects
1

Moving on from the v0.1 release of PeerUnity, we’ll need to start to consider what features, fixes, and design modifications the community would like to see included in the v0.2 release.

If you have suggestions, please use this thread to post them for discussion. If the need arises, we can split off certain discussions into their own topic, for a deeper dive. If you have discovered a defect in PeerUnity v0.1, please create a new issue for it on Github, so the team can be notified of it’s existence, and to use as a reference for commits that address it.

Note: v0.2 must conform to the current Peercoin v0.4 reference protocol, so that means we’ll need to hold off on any changes that if implemented would result in a potential forking of the network.

2

It’s already on Github, but let’s post it here too for the people who don’t watch the Github account…

I made a pull request for v0.2 containing:

  • Raw transaction RPC, allowing making transactions from multi-signature addresses (and simple addresses too obviously), getting info on transactions, etc…
  • Batch JSON-RPC, allowing sending several JSON-RPC requests at once
3

[quote=“glv, post:2, topic:2293”]I made a pull request for v0.2 containing:

  • Raw transaction RPC, allowing making transactions from multi-signature addresses (and simple addresses too obviously), getting info on transactions, etc…
  • Batch JSON-RPC, allowing sending several JSON-RPC requests at once[/quote]
    +1
    glv is it possible to implement batch as ‘atomic’/consistent(option to lock everything from writing during batch execution)?
    If not: gettopblockhash would be nice.
4

[quote=“kac-, post:3, topic:2293”]glv is it possible to implement batch as ‘atomic’/consistent(option to lock everything from writing during batch execution)?
If not: gettopblockhash would be nice.[/quote]

I suppose you want the gettopblockhash function to return the hash of the most recent block. It can already be done by calling getblockcount and getblockhash; or do you want something else?

5

Yes, but I cannot call getblockcount/hash together in batch call, with gettopblockhash as first and last call in batch, requesting client can will be sure that subsequent results (with f.e. “confirmations:”) are representing same state, ~snapshot. From the other hand… a bit paranoid and probably not worth adding :slight_smile:

6

I would like to keep the discussion about 0.2 specifications open for a few days to week, after which we should lock down the feature set and commence coding items not already implemented. Now is the time to speak up about what you would like to see in Peerunity! Here is the incomplete list as it stands now:

  1. Raw transaction RPC (accepted and already code complete by glv)
  2. Batch JSON-RPC (accepted and already code complete by glv)
  3. Style sheet changes to improve Qt appeal (accepted; we will put a 100 PPC bounty on it and let Sentinelrv pick a winning entry)
  4. A new tab featuring a grid designed to show users details about their wallet’s minting capacity. It would have the following columns: Address, Age, Balance and Coin Days. It should be sortable by any column. Minting is done on a per output basis, so a single address may appear multiple times in the grid if it has multiple outputs. Users could easily see if they have outputs over 90 days old, in which case they are losing minting opportunities. Seeing whether coins are under or over the 30 day threshold lets users know if there is anything to be gained from minting. We may want to color code the rows: under 30 days, 30 to 90 days, and over 90 days. (under consideration)

What else should we be considering?

7

I realize cold wallet minting is likely to be requested, so I will talk about our plan for that. This feature is very important, but its implementation is not trivial. sigmike has produced a specification for this which I will post soon in the Development section for comment. The Peershares project will be funding the implementation of cold wallet minting and it will become part of the Peershares template. After it has been proven and refined in a Peershares implementation, we would like to use it in Peercoin. Doing so will require protocol changes and therefore broad community consensus.

8

I would like to suggest a systematic approach:

1 colllect features in the lastest bitcoin wallet
2 collect features in other POS coins – some of them have active developers and have made nice improvement of their wallets
3 brain storm to think of other features
4 prioritize all features to get a road map for 0.2, 0.3 … 1.0 2.0
5 review road map after 6 months and repeat from step 1 if necessary

0.2 requirements can come out before the first round (1-4) finishes

If I am only to propose one thing that peerunity could do, that would be somehow making minting process less mysterious:

Add a dashboard to show each (of top 10) unspent output’s coin age, eligibility of getting POS, and probability of getting a POS block per day, how much the reward would be, accumulated chance (sum up all wallet minting times since its 30 day jail time is up) to get a block to encourage more minting time, sum of all outputs of the above numbers for the wallet. Results are updated every 10min to save energy. Fuzzy’s POS calculator has already shown some of the functions with manual input.

Also for curiosity and debugging purpose, I would like to see for an output the CBigNum(hashProofOfStake) / (bnCoinDayWeight * bnTargetPerCoinDay) ratio every time the wallet tries to find a POS block. If the ratio is less than 1, you find a block basically). The ratio updates every second.

9

Since peershares are generally denominated in PPC and divs paid in PPC, I would suggest a distributed exchange feature on peerunity client.
The one DEx that I know is the MSC wallet:
http://www.mastercoinwallets.org/

10

[quote=“redlee, post:9, topic:2293”]Since peershares are generally denominated in PPC and divs paid in PPC, I would suggest a distributed exchange feature on peerunity client.
The one DEx that I know is the MSC wallet:
http://www.mastercoinwallets.org/[/quote]
Totally agree. Have been pushing for that for ages (well for some dex dealing with peercoins). But developer of MSC wallet has other priorities than adding Peercoin at least for now. I think adding this to Peerunity client would be truly innovative and an asset for the community. It won’t be simple though.

Edit: I would also appreciate a bit of a structured approach with a backlog, I think Ben identified already a lot of items on his scrap papers he published and I’ve got a similar list in my dreamwallet thread http://www.peercointalk.org/index.php?topic=1872 Just let’s sort out all those items, verify whether they can be done without hard forking and put them loosely against a release schedule without too much commitments.

11

I’m going to throw out a couple of items that may be better suited for a later release, but personally, I’d like to start conversations about them sooner, rather than later:

[ul][li]Deterministic wallet (BIP 0032)[/li]
[li]Even easier to use “m of n” multi-signature addresses*[/li][/ul]

  • with a stretch goal of enabling a usb-based “split signature” method for requiring both a manually entered passphrase and a separate file with the second signing key that is stored on a USB drive. I need to diagram what I had in mind, but basically it’s a way of enabling two-factor authentication without requiring an outside service or SMS vendor.
12

Heya,
I’m new over here, have been introduced this project by sigmike.
Just to let you know, I’ll be giving a try to the minting tab as it sound a good thing to get my hands under the hood. He will coach me on this :wink:

13

[quote=“Jordan Lee, post:6, topic:2293”]I would like to keep the discussion about 0.2 specifications open for a few days to week, after which we should lock down the feature set and commence coding items not already implemented. Now is the time to speak up about what you would like to see in Peerunity! Here is the incomplete list as it stands now:

  1. Raw transaction RPC (accepted and already code complete by glv)
  2. Batch JSON-RPC (accepted and already code complete by glv)
  3. Style sheet changes to improve Qt appeal (accepted; we will put a 100 PPC bounty on it and let Sentinelrv pick a winning entry)
  4. A new tab featuring a grid designed to show users details about their wallet’s minting capacity. It would have the following columns: Address, Age, Balance and Coin Days. It should be sortable by any column. Minting is done on a per output basis, so a single address may appear multiple times in the grid if it has multiple outputs. Users could easily see if they have outputs over 90 days old, in which case they are losing minting opportunities. Seeing whether coins are under or over the 30 day threshold lets users know if there is anything to be gained from minting. We may want to color code the rows: under 30 days, 30 to 90 days, and over 90 days. (under consideration)

What else should we be considering?[/quote]

Due to the suggestion of mhps above, I would like to amend #4 as follows (note that it is now accepted as a feature for 0.2, has a Mint Probability Per Day column added, and an aggregate Mint Probability Per Day):

  1. A new tab featuring a grid designed to show users details about their wallet’s minting capacity. It would have the following columns: Address, Age, Balance and Coin Days, Mint Probability Per Day. It should be sortable by any column. Minting is done on a per output basis, so a single address may appear multiple times in the grid if it has multiple outputs. Users could easily see if they have outputs over 90 days old, in which case they are losing minting opportunities. Seeing whether coins are under or over the 30 day threshold lets users know if there is anything to be gained from minting. We should to color code the rows: under 30 days (blue), 30 to 90 days (green), and over 90 days (red). A Cumulative Mint Probability Per Day should also be included. The column Mint Probability Per Day is per output, while the Cumulative Mint Probability Per Day is the chance that one or more blocks will be minted from any output in the wallet in the next day. Also include a legend indicating the meaning of the row coloring. The Address column should contain the user’s label of the address if one has been entered. (accepted)

Edit: Let’s label this tab Minting

14

@Jordan: Is #4, above, related to the enhancement request that I proposed here, “Method to retrieve list of mature transactions (w/details),” or are they different components? If they are different, I’d like to add it to the list of enhancements considered for Peerunity v0.2.

15

Mint Probability Per Day might have too many leading zeros for most stakes. For example 100PPC after 60 days have 0.006 probability/day. I think 4%/week would be easier to the senses.

Ben’s proposal of an API for matural UTXOs makes it easier to to write external mint info display application.

16

Yes, it is. I had failed to articulate that. Thank you Ben. Here is an additional accepted specification of release 0.2:

  1. A new RPC should be added called listminting, as detailed here: Cryptoblog - notícias sobre bitcoin e criptomoedas! Completion of the Minting tab user interface (item #4) is dependent upon the completion of this specification as it should make use of this new method. (accepted)

jmzeidner is working on the listminting method and DaeMOn is working on the UI implementation of the Minting tab, so please be aware of the need for the two of you to coordinate the completion of items #4 and #5.

Also, as mhps suggested, it makes sense to display the Mint Probability Per Day as a percent.

17

I still think per week is better for most people.

18

please direct technical concerns re. Listminting here: https://github.com/Peerunity/Peerunity/issues/37

thanks! -jmz

19

Is this the same feature as cold-locked minting? If so, if you’re going to be implementing your own version of this, what happens when Sunny finally implements his own version? The last time he mentioned it was in the link below. He said it was still under evaluation for future releases…

http://www.peercointalk.org/index.php?topic=2473.msg20924#msg20924

20

[quote=“MeBeingAwesome, post:129, topic:2203”][quote=“Jordan Lee, post:128, topic:2203”]Please do not interpret this as an offer for a bounty or prize. It is a suggestion tossed out for community comment and revision

I was thinking about 100 PPC for 1st place because we will only use one (they can be swapped out like sigmike indicated but this is too cumbersome for an end user). I can see how a second and third prize would prompt broader participation. But smaller prizes may make top talent say it isn’t worth a try.

Another question is duration. This would be slated for the 0.2 release. My guess is a contest length of three weeks would pose zero risk of delaying or complicating the 0.2 release. It is probably plenty of time to attract entrants and have them complete their work. We could go lengthen the contest if people think that would be helpful.

The final question is how to determine a winner. I’m inclined to name Sentinelrv, not as the judge of what is the best entry, but as the judge of what the community consensus is of what is the best entry. There really isn’t a definitive way to gauge community consensus (a poll result can be easily rigged).

Thoughts? Suggestions?[/quote]

I would support Sentinelrv being the lead on selecting the best entry. He’s shown in the past that he can work well with designers and get results.

If other people support his involvement, I might suggest Sentinel utilize 99Designs again. It has contest sections available for website development as well as mobile app development, and it’s possible you might find talented people there. If that site is used, the prize put up does not have to be guaranteed, so that in the event an external designer performs better, no funds will have been wasted.[/quote]

When we did the original Peercoin logo contest on 99designs, I believe we got the silver package to ensure more and better quality designs, which was $499. I also paid a couple hundred dollars more out of my pocket to advertise it better on the website. I also guaranteed the prize because it shows the designers your commitment. If you don’t guarantee the prize, you get less design submissions.

Now I just checked and the pricing for app design using 99designs appears to be even more expensive than regular logo design. The most basic package “bronze” is $599 according to this page and silver is $899. This is all without advertising your contest on the site. See the pricing here…

http://99designs.com/pricing/other-website-app-design

If you wanted to go the 99designs route again and have serious designers try out, it’s going to cost us some money. I would suggest maybe using 99designs as a last option. We should first try organizing a community contest and advertise it on this forum, Reddit, Facebook, Twitter and BitcoinTalk to get interest. 100 PPC doesn’t sound like enough to interest top talent in my opinion. I’d say at least 200, but it’s not my money so I guess Jordan would have to decide this. The higher the reward, the more and better quality submissions we’re going to get.

You might also want to put in a disclaimer about us reserving the right to not hand out a reward in case the community doesn’t like any of the submissions, or the chance that we don’t get enough quality submissions to choose from. If a community contest doesn’t work out in the end, then we may need to consider 99designs as a last option.

And one question I need answered. Is this theme going to be implemented in everything, Peerunity, Peershares and Peercoin, or just certain ones?