BitShares Forum
Other => Graveyard => Marketplace => Topic started by: bytemaster on December 31, 2013, 06:22:41 am
-
This bounty is very simple for all you altcoin developers out there:
1) Replace the proof-of-work with a signature verification for a ECC public/private key pair
2) Embed the first 64 bits of the most recent block into every transaction at the time it is created (Proof of Stake)
3) Transaction fees are 'destroyed' and money supply adjusted accordingly
4) Display all balances in the GUI as a percentage of the money supply * 1000000 as of the time they were SPENT... unspent TRX are displayed as percentage of the money supply as of the head block.
5) When entering amounts in the GUI, they should be entered in the same format they are displayed
6) The genesis block should be initialized by a .cpp containing a static array of PTS and BTC addresses and balances, this will require the network to support spending PTS and BTC addresses in the signature verification
7) Assuming a maximum of 100 GB per year in transactions, the minimum total cumulative transaction fees for the year should be 5% of the money supply. Calculate the minimum fee per byte accordingly. The 5% figure should be easily changed by adjusting a single constant.
8) Unspent outputs after 1 year expire and thus can be pruned because they cannot be spent, this forces people to spend their money once per year (Proof of Stake, and keeps the blockchain size to a maximum size).
The resulting alt-dac template will be added to our DAC developer toolkit as a quick way to bootstrap a dividend paying DAC. When the Ripple Consensus Implementation Bounty is completed then that will be integrated to replace the Signature POW used here to create a decentralized system.
A Test network must be launched and used successfully
Blocks should be produced as soon as there is at least one transaction, but no faster than once every 30 seconds
The code should be structured such that the NAME of the coin can be changed in a single place.
-
If anyone is planning on tackling this, I'd be interesting in helping out. Let me know.
-
I'll put it in a repository if anyone is willing to collaborate, let's do it!!
-
Following, add nmushegian to any githubs
-
https://github.com/Nameshar/Divsshares
ok i'll add you immediately. i'll make the basic changes now, then we'll see what it is with the bigger stuff.
done
-
Update the readme so we know what's done and what is left to do
-
Update the readme so we know what's done and what is left to do
cloned to desktop so i'll just push the changes soon
-
Im following this, see what I can do.
Git account (https://github.com/arcke)
Just pulled your repository.
-
Added one little detail:
8) Unspent outputs after 1 year expire and thus can be pruned because they cannot be spent, this forces people to spend their money once per year (Proof of Stake, and keeps the blockchain size to a maximum size).
-
Added one little detail:
8) Unspent outputs after 1 year expire and thus can be pruned because they cannot be spent, this forces people to spend their money once per year (Proof of Stake, and keeps the blockchain size to a maximum size).
Ok, would that be a literal year or coin year?
-
int64 GetAccountBalance(CWalletDB& walletdb, const string& strAccount, int nMinDepth)
{
int64 nBalance = 0;
// Tally wallet transactions
for (map<uint256, CWalletTx>::iterator it = pwalletMain->mapWallet.begin(); it != pwalletMain->mapWallet.end(); ++it)
{
const CWalletTx& wtx = (*it).second;
if (!wtx.IsFinal())
continue;
int64 nGenerated, nReceived, nSent, nFee;
wtx.GetAccountAmounts(strAccount, nGenerated, nReceived, nSent, nFee);
if (nReceived != 0 && wtx.GetDepthInMainChain() >= nMinDepth)
nBalance += nReceived;
nBalance += nGenerated - nSent - nFee;
}
// Tally internal accounting entries
nBalance += walletdb.GetAccountCreditDebit(strAccount);
return nBalance;
}
int64 GetAccountBalance(const string& strAccount, int nMinDepth)
{
CWalletDB walletdb(pwalletMain->strWalletFile);
return GetAccountBalance(walletdb, strAccount, nMinDepth);
}
Value getbalance(const Array& params, bool fHelp)
{
if (fHelp || params.size() > 2)
throw runtime_error(
"getbalance [account] [minconf=1]\n"
"If [account] is not specified, returns the server's total available balance.\n"
"If [account] is specified, returns the balance in the account.");
if (params.size() == 0)
return ValueFromAmount(pwalletMain->GetBalance());
int nMinDepth = 1;
if (params.size() > 1)
nMinDepth = params[1].get_int();
if (params[0].get_str() == "*") {
// Calculate total balance a different way from GetBalance()
// (GetBalance() sums up all unspent TxOuts)
// getbalance and getbalance '*' should always return the same number.
int64 nBalance = 0;
for (map<uint256, CWalletTx>::iterator it = pwalletMain->mapWallet.begin(); it != pwalletMain->mapWallet.end(); ++it)
{
const CWalletTx& wtx = (*it).second;
if (!wtx.IsFinal())
continue;
int64 allGeneratedImmature, allGeneratedMature, allFee;
allGeneratedImmature = allGeneratedMature = allFee = 0;
string strSentAccount;
list<pair<CTxDestination, int64> > listReceived;
list<pair<CTxDestination, int64> > listSent;
wtx.GetAmounts(allGeneratedImmature, allGeneratedMature, listReceived, listSent, allFee, strSentAccount);
if (wtx.GetDepthInMainChain() >= nMinDepth)
{
BOOST_FOREACH(const PAIRTYPE(CTxDestination,int64)& r, listReceived)
nBalance += r.second;
}
BOOST_FOREACH(const PAIRTYPE(CTxDestination,int64)& r, listSent)
nBalance -= r.second;
nBalance -= allFee;
nBalance += allGeneratedMature;
}
return ValueFromAmount(nBalance);
}
string strAccount = AccountFromValue(params[0]);
int64 nBalance = GetAccountBalance(strAccount, nMinDepth);
return ValueFromAmount(nBalance);
}
rpcwallet.cpp
I believe this is where we meddle with for the balance
-
Added one little detail:
8) Unspent outputs after 1 year expire and thus can be pruned because they cannot be spent, this forces people to spend their money once per year (Proof of Stake, and keeps the blockchain size to a maximum size).
Ok, would that be a literal year or coin year?
I think that would be a literal year based upon timestamp in the block header. With this chain there is no fixed number of blocks so you cannot estimate time by number of blocks.
-
In order to appease both sides, why not display both the actual money supply and the number of coins?
I am having difficulty wrapping my head around buying something for X%.
You will not have to think in terms of X% you will just see X BTS... from the user's perspective it is just a number. The only place shares matter is under the hood, but that is an implementation detail.
so balance is (walletbts/totalbts ) * 100. and the user just sees this, number? That is doable.
I'll think more into cleanly writting that in c++.
Tell me more about the Signature PoW that you want.
-
return ((nBalance/HashCash) * 100);
should suffice, I am now looking at getting the total supply from main.h
so since there is no recursion i have just added an include main.h
then int64 HashCash = nMoneySupply
-
I'm very interested in the results of this bounty. I'm creating a proprietary coin where the proof-of-work is non-computational, this would make a great transactional layer.
-
Tell me more about the Signature PoW that you want.
Every block is signed by one person. Difficulty of producing blocks is infinite for everyone but the person with the private key.
Replace the nonce with a ECC signature and the POW validation to make sure it was signed by one or more trusted keys.
-
I am increasing the bounty on this to 1500 PTS.
-
I am increasing the bounty on this to 1500 PTS.
lol, thanks.
-
Looking at this today
-
Here is verification
https://github.com/Nameshar/Divsshares/blob/master/src/main.cpp#L2047
Replace the place it calls CheckProofOfWork with a call to a custom CheckProofOfMasterSignature, which needs to access the master signature on a block
https://github.com/Nameshar/Divsshares/blob/master/src/main.h#L836
^ I recommend we add a new field of the right type rather than changing the nonce's type and setting it there, that lets us touch less code.
Creating a block:
https://github.com/Nameshar/Divsshares/blob/master/src/main.cpp#L3992
In the non-PoS case "mining" is just waiting until a new signature has been approved, we should let it try to mine so it builds up a valid block in the process
The interface for creating a master-signed block might be the longest part of this step. How about an rpc call which asks for the key, which will immediately publish whatever block the client is "mining" at that moment?
-
I would like the one 'mining' node to automatically build and publish blocks every 30 seconds if there is a new transaction. The private key for this node should be stored in a password protected file on the master miner machine.
-
only one mining machine, lol centralization!!! :P
ok, i''l see what i can do.
-
only one mining machine, lol centralization!!! :P
ok, i''l see what i can do.
One machine mining, but not earning anything for doing so. Everyone else is securing the network with every single transaction. To attack this network the "one miner" would also have to control the vast majority of the money supply... however, this one miner will not be anonymous and all double spend attacks would be obvious. In reality this network is less centralized than bitcoin which has GigaHash + 1 :)
-
Here is verification
https://github.com/Nameshar/Divsshares/blob/master/src/main.cpp#L2047
Replace the place it calls CheckProofOfWork with a call to a custom CheckProofOfMasterSignature, which needs to access the master signature on a block
https://github.com/Nameshar/Divsshares/blob/master/src/main.h#L836
^ I recommend we add a new field of the right type rather than changing the nonce's type and setting it there, that lets us touch less code.
Creating a block:
https://github.com/Nameshar/Divsshares/blob/master/src/main.cpp#L3992
In the non-PoS case "mining" is just waiting until a new signature has been approved, we should let it try to mine so it builds up a valid block in the process
The interface for creating a master-signed block might be the longest part of this step. How about an rpc call which asks for the key, which will immediately publish whatever block the client is "mining" at that moment?
thanks
-
ive gone ahead with secp256r1 32, the library is now in the src folder, it has these functions of interest
int ecc_make_key(
uint8_t p_publicKey[ECC_BYTES+1],
uint8_t p_privateKey[ECC_BYTES]
);
that creates a public/private key pair
int ecdsa_sign(
const uint8_t p_privateKey[ECC_BYTES],
const uint8_t p_hash[ECC_BYTES],
uint8_t p_signature[ECC_BYTES*2]
);
Generates an ECDSA signature for a given hash value.
int ecdsa_verify(
const uint8_t p_publicKey[ECC_BYTES+1],
const uint8_t p_hash[ECC_BYTES],
const uint8_t p_signature[ECC_BYTES*2]
);
Verifies an ECDSA signature.
credit goes to kmackay for this.
if anyone has an idea how to replace the nonce as required, just fork this repository https://github.com/Nameshar/Divsshares
and get to it. I'll be trying to figure it out as well but i'd appreciate a hand.
Why secp256r1 instead of secp256k1 as used in Bitcoin? There are concerns that secp256r1 was intentionally weakened by the NSA: https://bitcointalk.org/index.php?topic=151120.0
-
ive gone ahead with secp256r1 32, the library is now in the src folder, it has these functions of interest
int ecc_make_key(
uint8_t p_publicKey[ECC_BYTES+1],
uint8_t p_privateKey[ECC_BYTES]
);
that creates a public/private key pair
int ecdsa_sign(
const uint8_t p_privateKey[ECC_BYTES],
const uint8_t p_hash[ECC_BYTES],
uint8_t p_signature[ECC_BYTES*2]
);
Generates an ECDSA signature for a given hash value.
int ecdsa_verify(
const uint8_t p_publicKey[ECC_BYTES+1],
const uint8_t p_hash[ECC_BYTES],
const uint8_t p_signature[ECC_BYTES*2]
);
Verifies an ECDSA signature.
credit goes to kmackay for this.
if anyone has an idea how to replace the nonce as required, just fork this repository https://github.com/Nameshar/Divsshares
and get to it. I'll be trying to figure it out as well but i'd appreciate a hand.
Why secp256r1 instead of secp256k1 as used in Bitcoin? There are concerns that secp256r1 was intentionally weakened by the NSA: https://bitcointalk.org/index.php?topic=151120.0
Please use the same curve at bitcoin so all private/public keys in my libs are compatible.
-
ive gone ahead with secp256r1 32, the library is now in the src folder, it has these functions of interest
int ecc_make_key(
uint8_t p_publicKey[ECC_BYTES+1],
uint8_t p_privateKey[ECC_BYTES]
);
that creates a public/private key pair
int ecdsa_sign(
const uint8_t p_privateKey[ECC_BYTES],
const uint8_t p_hash[ECC_BYTES],
uint8_t p_signature[ECC_BYTES*2]
);
Generates an ECDSA signature for a given hash value.
int ecdsa_verify(
const uint8_t p_publicKey[ECC_BYTES+1],
const uint8_t p_hash[ECC_BYTES],
const uint8_t p_signature[ECC_BYTES*2]
);
Verifies an ECDSA signature.
credit goes to kmackay for this.
if anyone has an idea how to replace the nonce as required, just fork this repository https://github.com/Nameshar/Divsshares
and get to it. I'll be trying to figure it out as well but i'd appreciate a hand.
Why secp256r1 instead of secp256k1 as used in Bitcoin? There are concerns that secp256r1 was intentionally weakened by the NSA: https://bitcointalk.org/index.php?topic=151120.0
it is thus far unproven and besides a few fumbles and discussions untested. I'll try look around but when i first trid fiding an exploit there was no information.
-
ive gone ahead with secp256r1 32, the library is now in the src folder, it has these functions of interest
int ecc_make_key(
uint8_t p_publicKey[ECC_BYTES+1],
uint8_t p_privateKey[ECC_BYTES]
);
that creates a public/private key pair
int ecdsa_sign(
const uint8_t p_privateKey[ECC_BYTES],
const uint8_t p_hash[ECC_BYTES],
uint8_t p_signature[ECC_BYTES*2]
);
Generates an ECDSA signature for a given hash value.
int ecdsa_verify(
const uint8_t p_publicKey[ECC_BYTES+1],
const uint8_t p_hash[ECC_BYTES],
const uint8_t p_signature[ECC_BYTES*2]
);
Verifies an ECDSA signature.
credit goes to kmackay for this.
if anyone has an idea how to replace the nonce as required, just fork this repository https://github.com/Nameshar/Divsshares
and get to it. I'll be trying to figure it out as well but i'd appreciate a hand.
Why secp256r1 instead of secp256k1 as used in Bitcoin? There are concerns that secp256r1 was intentionally weakened by the NSA: https://bitcointalk.org/index.php?topic=151120.0
Amen.
-
perhaps you can weigh in bytemaster, should i change ?
-
perhaps you can weigh in bytemaster, should i change ?
Please use the same curve at bitcoin so all private/public keys in my libs are compatible.
-
perhaps you can weigh in bytemaster, should i change ?
Please use the same curve at bitcoin so all private/public keys in my libs are compatible.
got it
-
altough unrelated, i now have a functional PTS PoS coin.
i now have time to pay attention to Bounties again.
-
altough unrelated, i now have a functional PTS PoS coin.
i now have time to pay attention to Bounties again.
Nice... details?
-
altough unrelated, i now have a functional PTS PoS coin.
i now have time to pay attention to Bounties again.
Nice... details?
i'll pm you in a bit. I'm writing the instructions.
-
altough unrelated, i now have a functional PTS PoS coin.
i now have time to pay attention to Bounties again.
Nice... details?
check your inbox
the basics, are it uses the BTS PTS version of momentum. It's already complete and has been tested a few times now. I just finished writing the instructions for modifying it both basic and advanced. It can be used for BTS initiatives as is since it includes a custom license that tries to mimic the draft SCSL.
So its PoS
Momentum
Highly customize-able
Easy to modify and deploy.
:)
Now it just needs a valid use.
-
altough unrelated, i now have a functional PTS PoS coin.
i now have time to pay attention to Bounties again.
Nice... details?
check your inbox
the basics, are it uses the BTS PTS version of momentum. It's already complete and has been tested a few times now. I just finished writing the instructions for modifying it both basic and advanced. It can be used for BTS initiatives as is since it includes a custom license that tries to mimic the draft SCSL.
So its PoS
Momentum
Highly customize-able
Easy to modify and deploy.
:)
Now it just needs a valid use.
Very interesting... but it looks like it is using POW to decide the longest chain?
-
altough unrelated, i now have a functional PTS PoS coin.
i now have time to pay attention to Bounties again.
Nice... details?
check your inbox
the basics, are it uses the BTS PTS version of momentum. It's already complete and has been tested a few times now. I just finished writing the instructions for modifying it both basic and advanced. It can be used for BTS initiatives as is since it includes a custom license that tries to mimic the draft SCSL.
So its PoS
Momentum
Highly customize-able
Easy to modify and deploy.
:)
Now it just needs a valid use.
Very interesting... but it looks like it is using POW to decide the longest chain?
yes, it uses PoW for that, i'll think on the PoS could you point it out please?
-
Do you still need this?
-
Do you still need this?
It should use TaPOS rather than Signature... but yes, this would be nice.
-
Do you still need this?
It should use TaPOS rather than Signature... but yes, this would be nice.
looking into it, will report back soon.
The concept of Poof-of-Stake
Well, it seems in this case we need to change a lot, i'll take a good read of your paper. I want to ask though, signing tx with previous block hashes even truncated ones has the potential to bloat the blockchain way beyond what bitcoin is now in less than a year. the current hard limit of 7tps was put in place to temporarily forestall this issue. Also tx are made up of other tx, all of which is stored on the blockchain, this system makes for a slow and very bandwidth reliant blockchain.
We could resolve this by creating two types of clients, one that runs the full node and is heavily compensated and another "lite" client for the average user. This however brings up issue of DoS attacks targeting the back-bone nodes.
Let me keep reading and i'll see what i come up with, this however already looks like a pretty large project. I
-
i may have a ""testing"" version in two/3 days. wish i could make it in time for the snapshot.
-
I think you should be able to get the bounty with just signature POW. Was the TAPOS requirement added while the bounty was in [PENDING] or [ACTIVE]?
-
I think you should be able to get the bounty with just signature POW. Was the TAPOS requirement added while the bounty was in [PENDING] or [ACTIVE]?
[ACTIVE] but i find the TaPOS quite intriguing, i'll see what he says.
-
I've added block height into transactions, but now i need to figure out how to make a check for it.
-
I think you should be able to get the bounty with just signature POW. Was the TAPOS requirement added while the bounty was in [PENDING] or [ACTIVE]?
[ACTIVE] but i find the TaPOS quite intriguing, i'll see what he says.
indeed it would be really great if you could get bounty before snapshot! Knock on wood!
-
I've added block height into transactions, but now i need to figure out how to make a check for it.
Not the block height... the hash of the prior block.
-
I've added block height into transactions, but now i need to figure out how to make a check for it.
Not the block height... the hash of the prior block.
oh, ok done. but now i just need to write a check for it.
maybe
// TaPOS check if tx has correct block number
if (block.hash != (pblock->hashPrevBlock))
return state.DoS(10, error("CTransaction::CheckTransaction() : TaPoS failed"));
-
A transaction need not have the proper hash to be included..., but if it does have the proper hash then the coindays destroyed count toward the block.
-
A transaction need not have the proper hash to be included..., but if it does have the proper hash then the coindays destroyed count toward the block.
you want it to calculate coindays destroyed per transaction and use that to factor in as stake?
so if a tx destroys 1000 coin days, the PoW block gets an extra small % in coin representing the TaPoS?
-
A transaction need not have the proper hash to be included..., but if it does have the proper hash then the coindays destroyed count toward the block.
you want it to calculate coindays destroyed per transaction and use that to factor in as stake?
so if a tx destroys 1000 coin days, the PoW block gets an extra small % in coin representing the TaPoS?
There are no PoW blocks... if you look at the code in BitShares X you will see how I calculate it... but it comes down to this:
If a transaction includes the proper prior hash (one of the last 2 blocks) then its CDD are counted toward that block. Every block to be produced must have at least AVAILABLE_CDD / BLOCKS_PER_YEAR destroyed.
The AVAILABLE_CDD is calculated on a continuous basis as PREV_AVAILABLE_CDD - CDD_DESTROYED + MONEY SUPPLY every block.
Every block reserves the first transaction to be the 'miners transaction' in which the miner can contribute their own CDD. This transaction may only have one output.
Every block then contains a Miners Reward Transaction which must pay to the same address as the miners transaction and the amount paid is:
PAID_TO_MINER = TOTAL_FEES * MINERS_CDD / TOTAL_CDD (or less).
SHARE_SUPPLY -= TOTAL_FEES - PAID_TO_MINER
And that is the algorithm in a nutshell.
-
having a hard time
-
Is this still active?
-
Is this still active?
Given the state of DPOS I see no reason to maintain this. I'll close it down.