BitShares Forum
Main => General Discussion => Topic started by: bytemaster on November 03, 2013, 07:10:22 pm
-
I am looking for talented developers to help incrementally build BitShares style features on top of the ProtoShares code base. The first feature is to implement a dividend paying crypto-currency. This will be the foundation for many different types of DAC.
BitShares pays dividends according to the following algorithm below:
1) The total money supply is tracked as MONEY_SUPPLY
2) 50% of mining rewards + transaction fees from each block are paid as DIVIDENDS
3) A dividend accumulation table is maintained that includes the total dividends per Satoshi paid for every block for the past year. Each block adds DIVIDENDS/MONEY_SUPPLY to every entry in the accumulation table. This table will require 128 bit 64.64 fixed-point precision so that dust can accumulate properly.
4) The dividends due a particular output can be calculated by looking up the coin-age in this dividend accumulation table and these dividends are part of the input value of the transaction when the output is spent. All dividends except the past 100 blocks are included. Dividends for the past 100 blocks are paid as part of the transaction fee because these dividends could be lost if there is a chain reorganization.
In addition to updating the block chain, the bitcoin wallet would have to be updated to reflect the current balance along with all dividends.
I have already implemented a proof-of-concept block chain based upon this dividend system, but am looking for a developer who can integrate such a system on top of the Bitcoin code base.
Bounty to be paid in BTC at the BitStamp price as of the time of payment.
-
Please explain the following,
1) Are dividends part of mineable TOTAL_MONEY_SUPPLY or they can surpass?
Number 3 is basically a modified block explorer that displays the relevant information
Number 4 is a calculator
give me a link to your proof of concept.
-
Please explain the following,
1) Are dividends part of mineable TOTAL_MONEY_SUPPLY or they can surpass?
Number 3 is basically a modified block explorer that displays the relevant information
Number 4 is a calculator
give me a link to your proof of concept.
Dividends are just a split of mining rewards. When mining rewards are still issuing new currency half of the new currency is paid as dividends. When mining rewards are 100% from trx fees, then the money supply no longer grows.
https://github.com/InvictusInnovations/BitShares/tree/master/src/blockchain
https://github.com/InvictusInnovations/BitShares/blob/master/src/blockchain/blockchain_db.cpp
-
Please explain the following,
1) Are dividends part of mineable TOTAL_MONEY_SUPPLY or they can surpass?
Number 3 is basically a modified block explorer that displays the relevant information
Number 4 is a calculator
give me a link to your proof of concept.
Dividends are just a split of mining rewards. When mining rewards are still issuing new currency half of the new currency is paid as dividends. When mining rewards are 100% from trx fees, then the money supply no longer grows.
https://github.com/InvictusInnovations/BitShares/tree/master/src/blockchain
https://github.com/InvictusInnovations/BitShares/blob/master/src/blockchain/blockchain_db.cpp
so block reward is actually mining reward+ dividends+ tx fees?
if that is the case, 2 factor reward system would solve that.
Say total intended reward is 50 bez tx fees.
we can say
include dividends.h
int64 static GetBlockValue(int nHeight, int64 nFees, int64 Dividends)
{
int64 nSubsidy = 50/2 * COIN;
return nSubsidy + nFees + Dividends;
}
-
BlockReward = (Subsidy + Fees)/2
DIVIDEND_PER_COIN = BlockReward / MONEY_SUPPLY -> this should be a 64.64 fixed point number because it is *VERY SMALL*
The balance of an output = (SUM DIVIDEND_PER_COIN for last COIN_AGE blocks) * output amount
Automatic fees for an output = (SUM DIVIDEND_PER_COIN for MIN(120,COIN_AGE) blocks) * output amount
-
Hmmm - how frequently are the dividends to be payed? What triggers a payment in the blockchain?
-
Hmmm - how frequently are the dividends to be payed? What triggers a payment in the blockchain?
Dividends are paid as part of every transaction. You can always calculate your balance as OUTPUT + Dividends Available Upon Spending.
So if you receive 100 PTS it will sit as an 'unspent output' for X blocks. Each block will pay Y dividends per PTS but these are not transferred to anyone yet. When you spend the output with 100 PTS you then calculate the dividends due and add it to the input value of a trx. In this way, dividends have 0 extra overhead in trx volume.
-
Dividends are paid as part of every transaction. You can always calculate your balance as OUTPUT + Dividends Available Upon Spending.
So if you receive 100 PTS it will sit as an 'unspent output' for X blocks. Each block will pay Y dividends per PTS but these are not transferred to anyone yet. When you spend the output with 100 PTS you then calculate the dividends due and add it to the input value of a trx. In this way, dividends have 0 extra overhead in trx volume.
So if I spend 100 PTS and have 10PTS waiting for me in dividends, the input is increased to 110PTS, and the recipient still gets 100PTS, but the 10 goes back to me as additional change?
-
Dividends are paid as part of every transaction. You can always calculate your balance as OUTPUT + Dividends Available Upon Spending.
So if you receive 100 PTS it will sit as an 'unspent output' for X blocks. Each block will pay Y dividends per PTS but these are not transferred to anyone yet. When you spend the output with 100 PTS you then calculate the dividends due and add it to the input value of a trx. In this way, dividends have 0 extra overhead in trx volume.
So if I spend 100 PTS and have 10PTS waiting for me in dividends, the input is increased to 110PTS, and the recipient still gets 100PTS, but the 10 goes back to me as additional change?
Depends upon how much money you are sending. If You want to pay someone 105, then you will spend that input, 105 will go to them, and 5 back to you.
-
Hmm - one issue I encountered with MemoryCoin voting was that it was never clear in the outputs which address was receiving the funds and which was the change address. You might have a similar issue here - how do you know which output address to award the dividend to?
If you start awarding the dividend to the sending address, then there may be no way to clear a balance to zero - there is always dust there.
-
Hmm - one issue I encountered with MemoryCoin voting was that it was never clear in the outputs which address was receiving the funds and which was the change address. You might have a similar issue here - how do you know which output address to award the dividend to?
If you start awarding the dividend to the sending address, then there may be no way to clear a balance to zero - there is always dust there.
Dividends are accumulated in the inputs. Inputs + Dividends must be greater than Output + Min Fees. Any amount not specified in an output address is automatically a fee. Transactions are constructed assuming the dividends as the inputs so the sum of the outputs includes the dividends. There is not a separate dividend output.
-
Okay I think I've got it - the dividends are funds which aren't explicitly recorded in the blockchain, but which can be inferred by examination of the blockchain. The cleanest implementation I can think of would be to add them as coinbase transactions that are immediately spendable and spent in the block in which they are added. Conceptually, it's very clean, but implementation would require very careful work. You'd have to be extra careful to avoid ruling out the possibility of a lightweight client in the future.
-
Okay I think I've got it - the dividends are funds which aren't explicitly recorded in the blockchain, but which can be inferred by examination of the blockchain. The cleanest implementation I can think of would be to add them as coinbase transactions that are immediately spendable and spent in the block in which they are added. Conceptually, it's very clean, but implementation would require very careful work. You'd have to be extra careful to avoid ruling out the possibility of a lightweight client in the future.
No need to add them to the coin base transaction. All you need to do is record 'dividends earned this block' in the block header. Everything else can be calculated on a per-transaction basis. Lightweight clients only need the block headers.
-
I am not sure if I understand what this "dividend paying protoshares" means..can someone please elaborate?
is it just an experiement? or is it a new developments/ a new DAC to solve a problem/serve a purpose? or what ?
how is it related to pts and bitshares?
-
I am not sure if I understand what this "dividend paying protoshares" means..can someone please elaborate?
is it just an experiement? or is it a new developments/ a new DAC to solve a problem/serve a purpose? or what ?
how is it related to pts and bitshares?
From time to time we offer bounties to build general purpose components for potential use in future offerings. Often we use an existing code base (Bitcoin or ProtoShares) as the starting point. Not every bounty implies a stand-alone future product. Sometimes they are for test or training purposes. Sometimes they constitute job interviews. :)
Once our own research has allowed us to understand a component well enough to spec it for someone else to build, we try to offer others a way to participate on some of the build-to-spec, integration and testing tasks. Building up a distributed, autonomous "Steely-Eyed-Geek" developer community is just as important to defending Free Space as Keyhotee and the DACs themselves.
-
From time to time we offer bounties to build general purpose components for potential use in future offerings. Often we use an existing code base (Bitcoin or ProtoShares) as the starting point. Not every bounty implies a stand-alone future product. Sometimes they are for test or training purposes. Sometimes they constitute job interviews. :)
Once our own research has allowed us to understand a component well enough to spec it for someone else to build, we try to offer others a way to participate on some of the build-to-spec, integration and testing tasks. Building up a distributed, autonomous "Steely-Eyed-Geek" developer community is just as important to defending Free Space as Keyhotee and the DACs themselves.
ok cool :)
-
I have dramatically simplified the implementation of this:
http://bitsharestalk.org/index.php?topic=1169.0
-
I have dramatically simplified the implementation of this:
http://bitsharestalk.org/index.php?topic=1169.0
+1
Agree - this is a much simpler way to implement. It's quite a beautiful paradigm shift. No hiding place for inflation.
-
is this 5k going to be added to the 500 PTS one? That would make me work even faster
-
is this 5k going to be added to the 500 PTS one? That would make me work even faster
This bounty is now expired and the new 500 PTS bounty takes its place.