Author Topic: 2 x 800 PTS - Generate Unspent Output Set every day at midnight GMT [PAID]  (Read 28291 times)

0 Members and 1 Guest are viewing this topic.

Offline bytemaster

By the way, what about rounding errors when distributing AGS daily? It's tiny but existing.

Ideally everything would be calculated with integer math and thus the rounding errors will be deterministic.  They are what they are and I will consider two outputs to be identical if they are within 100 satoshis of each other.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline BrownBear

  • Full Member
  • ***
  • Posts: 51
    • View Profile
By the way, what about rounding errors when distributing AGS daily? It's tiny but existing.

Offline bytemaster

For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.



Offline bytemaster

The inputs to generate the genesis block should be:

1) Total Share Supply
2) % allocated to PTS
3) % allocated to AGS
4) It would be really awesome, but not required, if the user could specify a JSON object of balances to be divided up for a 3rd category (custom to their DAC)

The result should be a JSON object with all of the balances calculated and ready to use. 
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline BrownBear

  • Full Member
  • ***
  • Posts: 51
    • View Profile
I've changed the algorithm now to do it like this:

When the first change in day in the blockchain appears the AGS file is written. If another block comes along later with a reverse day change (day -1), it's scanned for AGS updates and written if required.

This means, there will be output at 0:06 every day, but it can change for up to 2 hours later. The ProtoShares are counted to the first forward day change (day +1) in the chain. Afaik DreKrob is also working on it using this approach, since he found a way to use RPC after all. My implementation can be pulled into protosharesd/-qt and run via command line parameter (-unspent).

My webinterface will be a using html/javascript. This keeps setup easy.

Please tell me if I got this right:
You can input the day you want to calculate the genesis data for and the percentage of the total money supply for the new currency that is supposed to be distributed amonst AGS holders. The script then allocates 10% of the new currency to all PTS addresses according to their balance and x% (the previously set amount) of the new currency to all AGS holders according to the size of their donations.

The result will be a json file that contains each PTS address and the percentage that they are supposed to get. ( [ { "address": number between 0 and 1 }, ... ] )

Offline bytemaster

They are partially related through the BTS genesis block that we're asked to create, which should include AGS and unspent PTS TX (if I understood that correctly). But I guess this inconsistency is tolerable. It could happen that somebody for example send money to AGS on the last day and gets more BTS because in the first "new day" block he still has unspent PTS while the AGS he gets from a later block with an earlier timestamp is counted.

The only hard requirement in my book is that the AGS donations are counted based upon timestamp of the block and that both independent implementations agree as to which block constitutes 'midnight' on a given day.    This means that your production of the block and stats probably has to wait until 2 hours after midnight to be sure no blocks are produced with an old timestamp.

If two independent implementations agree to a deterministic block (first or last time change) for the end of the day then that is fine with me.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline BrownBear

  • Full Member
  • ***
  • Posts: 51
    • View Profile
I wouldn't mind a bit of an increase ^_^ it's way more work than 3x a wallet implementation. But maybe you're lucky and I'm pot committed already ;)

Offline bytemaster

Good luck! This bounty turned out to be quite more complicated than anticipated. If you have questions, just ask.

Looks like I priced it well then :)
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline BrownBear

  • Full Member
  • ***
  • Posts: 51
    • View Profile
Good luck! This bounty turned out to be quite more complicated than anticipated. If you have questions, just ask.

Offline seeekr

  • Newbie
  • *
  • Posts: 1
    • View Profile
Hey everybody,

just wanted to let you guys know that I'm also working on an implementation for this, and have been for a couple days now. I'm not done by any means yet, but I like what I have so far. I've uploaded the work in progress to a github repo at

https://github.com/seeekr/pts-unspent

So far what's implemented (with a couple bugs still left, like the issue that's been discussed here regarding "flapping blocktimes") is the calculation of unspent pts by day, as originally requested. It outputs the info in the desired format, but doesn't contain anything beyond that yet, not even a server to have some kind of web UI for requesting and navigating the information.
It's built in node.js and is using protosharesd/bitcoind to get blockchain information and works with that to calculate unspent outputs and the balance by address.

There's still a bunch of work to do until it meets the bounty criteria and I intend to keep at it 'til it's done. I'm new to BTC/PTS development so it took some time to figure out how to navigate this environment, but I'm starting to understand stuff which is good :)

As of now I can't add anything to the discussion here, other than to agree with the last posts here regarding the desired rule for which block should constitute the last one of the day. I don't care much about how we should do this specifically and I don't have a strong opinion on this since I don't fully understand AGS and the connection of the PTS balance to it.
I do have a couple of questions that I'll need answered that I think are irrelevant for the other active devs here since I'm new to the cryptocurrency/equity thing here and have some learning and catching up to do :)

Offline BrownBear

  • Full Member
  • ***
  • Posts: 51
    • View Profile
Yeah, it's either first or last determining the day. I'd like to stay with first tho, since I've already implemented this now. ;)

Offline BrownBear

  • Full Member
  • ***
  • Posts: 51
    • View Profile
They are partially related through the BTS genesis block that we're asked to create, which should include AGS and unspent PTS TX (if I understood that correctly). But I guess this inconsistency is tolerable. It could happen that somebody for example send money to AGS on the last day and gets more BTS because in the first "new day" block he still has unspent PTS while the AGS he gets from a later block with an earlier timestamp is counted.

Offline BrownBear

  • Full Member
  • ***
  • Posts: 51
    • View Profile
I just realized this brings up yet another issue:

I implemented AGS to be counted by the date resulting from the blocks time as discussed above, BUT:
The unspent TX out for protoshares has the same problem due to AGS: when does the day officially end? In this case, we cannot account blocks with a lagging date to the date it says it would be since obviously blocks depend upon each other, so ignoring the blocks with a newer date doesn't (reliably) work.

Example:
Block 1234 - Jan 6th: A sends B 10PTS
Block 1235 - Jan 7th: B sends C 5PTS
Block 1236 - Jan 6th: B sends A 5PTS

Result by ignoring 1235:
A got 5 PTS
B got 5 PTS

Actual data:
A got 5 PTS
B got 0 PTS
C got 5 PTS

It can also lead to inconsistencies where somebody would have negative PTS.