511
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
512
Marketplace / 1000 PTS - BitShares Trading GUI [CLOSED]
« on: January 02, 2014, 11:34:12 pm »
I would like to place people on notice that I will be creating a bounty for the Trading GUI used by BitShares. This GUI will have to support:
1) Transfer of funds between addresses (Bitcoin style) with multiple units.
2) Ability to place bids, asks, shorts
3) Ability to cover shorts
4) Market graphs that show depth and history for each asset pair.
We will have a low-level API that will actually implement these things that can be used by web wallets and GUI wallets alike. This bounty will be to develop code that works with our API and provides a solid, apple-quality, user experience.
The GUI must be implemented in Qt5 and work on Windows, Mac, Linux.
All open source libraries used must be compatible with the SCSL license under development, namely GPL is out.
Of course, like all bounties this one goes to the first one we opt to use. Those with UI design skills should team with those who know how to code and post your user interface concepts here.
Wallet should be designed as a standalone application that uses a QWidget as its base class. This way I can integrate it into Keyhotee when the time comes, but for your testing and development it can be launched standalone.
If you would like to work on this bounty, help me define the requirements so that I can turn it to PENDING/ACTIVE.
1) Transfer of funds between addresses (Bitcoin style) with multiple units.
2) Ability to place bids, asks, shorts
3) Ability to cover shorts
4) Market graphs that show depth and history for each asset pair.
We will have a low-level API that will actually implement these things that can be used by web wallets and GUI wallets alike. This bounty will be to develop code that works with our API and provides a solid, apple-quality, user experience.
The GUI must be implemented in Qt5 and work on Windows, Mac, Linux.
All open source libraries used must be compatible with the SCSL license under development, namely GPL is out.
Of course, like all bounties this one goes to the first one we opt to use. Those with UI design skills should team with those who know how to code and post your user interface concepts here.
Wallet should be designed as a standalone application that uses a QWidget as its base class. This way I can integrate it into Keyhotee when the time comes, but for your testing and development it can be launched standalone.
If you would like to work on this bounty, help me define the requirements so that I can turn it to PENDING/ACTIVE.
513
Meta / Forum Donation
« on: January 02, 2014, 08:59:09 pm »
I would rather announce a budget for this forum funded from the PTS Angels and then remove the forum specific donations. How many donations are you receiving right now?
514
Marketplace / Looking for someone to help answer Wallet Questions for Users
« on: January 02, 2014, 07:55:15 pm »
I would like to nominate someone to answer all basic questions about transactions, angel addresses, hidden change addresses, and wallet services as they keep coming up. I would like to create a SUPPORT sub forum that has people in every language that are able to answer questions for users.
I would like to award tips based upon the time it takes to respond and get the issue resolved.
You must be available for PM and respond to all support requests in a timely manner.
A FAQ section should be managed as well.
Thoughts?
I would like to award tips based upon the time it takes to respond and get the issue resolved.
You must be available for PM and respond to all support requests in a timely manner.
A FAQ section should be managed as well.
Thoughts?
515
General Discussion / BitSHares Update Thread
« on: January 02, 2014, 07:42:15 pm »
Posted over here: https://bitsharestalk.org/index.php?topic=1890.msg21785#msg21785
516
General Discussion / BitShares X Status Update
« on: January 02, 2014, 07:41:36 pm »
There has been an incredible amount of innovation over the past 2 months since we launched PTS and the ideas are scattered around the forum in many different threads. This thread is to bring it all home to one place and summarize what has changed over the past 2 months.
1) BitShares will no longer be mined nor will it use Proof of Work, instead it will use Consensus + Proof of Stake
a) This means that BTS will now pay 2x the dividend rate that the original spec called for.
b) This means that PTS holders stake in BTS will no longer be diluted by 45% due to mining rewards
c) This means that PTS holders benefit from allowing us to raise capital with the money previously spent on mining.
2) BitAssets will now receive a predictable, hardcoded 5% interest return, and short positions will pay a 5% borrowing cost.
3) Consensus algorithm means that confirmation times will be as quick as 30 seconds and no one node can manipulate the market.
4) We have identified a much simpler approach to implementing dividends
5) 50% of first BTS money supply will be allocated to PTS holders
6) 50% of first BTS money supply will be allocated to AGS holders.
7) Each BTS chain will support trading in about 16 assets
8) AGS and PTS will be used to initialize all BTS chains each trading in a subset of assets. Therefore, AGS and PTS is more valuable than owning a single BTS chain. They get you rights to all chains.
9) At the rate AGS is being funded we will have $3 million per month to spend developing BTS and are rapidly moving to accelerate the process.
Thanks everyone!
1) BitShares will no longer be mined nor will it use Proof of Work, instead it will use Consensus + Proof of Stake
a) This means that BTS will now pay 2x the dividend rate that the original spec called for.
b) This means that PTS holders stake in BTS will no longer be diluted by 45% due to mining rewards
c) This means that PTS holders benefit from allowing us to raise capital with the money previously spent on mining.
2) BitAssets will now receive a predictable, hardcoded 5% interest return, and short positions will pay a 5% borrowing cost.
3) Consensus algorithm means that confirmation times will be as quick as 30 seconds and no one node can manipulate the market.
4) We have identified a much simpler approach to implementing dividends
5) 50% of first BTS money supply will be allocated to PTS holders
6) 50% of first BTS money supply will be allocated to AGS holders.
7) Each BTS chain will support trading in about 16 assets
8) AGS and PTS will be used to initialize all BTS chains each trading in a subset of assets. Therefore, AGS and PTS is more valuable than owning a single BTS chain. They get you rights to all chains.
9) At the rate AGS is being funded we will have $3 million per month to spend developing BTS and are rapidly moving to accelerate the process.
Thanks everyone!
518
BitShares AGS / Angel Shares Sending 0.5 PTS per Minute with Script
« on: January 01, 2014, 06:25:38 am »
This kind of automation does not gain you anything. I would recommend sending just once per day if you want to use a script.
519
BitShares AGS / AngelShare Pay To Many - Be Careful!
« on: January 01, 2014, 06:15:59 am »
Who ever sent this payment to the Angel Address is probably not going to get the AGS they expect.
https://blockchain.info/tx/12969f176cb3866c444a260cd115918ff9f75583b6e805d00e2e2b1e60b0aaab
https://blockchain.info/tx/12969f176cb3866c444a260cd115918ff9f75583b6e805d00e2e2b1e60b0aaab
520
Marketplace / 10 PTS - C++ Developer Referral Bonus [ACTIVE]
« on: December 31, 2013, 08:12:46 pm »
If you refer a C++ developer who successfully completes one of our c++ bounties and the developer is NEW to the forum then you will receive a 10 PTS bonus.
Developer must confirm your referral when they make their first post.
Developer must confirm your referral when they make their first post.
521
Marketplace / 2000 PTS - Browser Based BitShares Wallet [TO BE DEFINED]
« on: December 31, 2013, 06:03:26 pm »
Heads up that we are working to define the requirements for a BitShares wallet like CryptoKit that enables you to buy/sell/short right from your browser without having to download a client. Start following this thread if you are interested in working on such a project and would like to help define the requirements.
We are going to produce the BitShares API against which this can be developed so development can occur in parallel.
We are going to produce the BitShares API against which this can be developed so development can occur in parallel.
522
Marketplace / 1000 PTS - BitShares Block/Market Explorer [TO BE DEFINED]
« on: December 31, 2013, 06:01:06 pm »
I just wanted to post a notice that we will be creating a bounty that allows people to view the markets in the BitShares blockchain with an advanced Block Explorer. The requirements are still waiting to be defined, but if you would be interested in such a thing post here and start the discussion.
523
Marketplace / 50 PTS - Lets Talk Bitcoin Radio Ad Bounty [ACTIVE]
« on: December 31, 2013, 07:35:03 am »
We would like to get the word out about our community including our Bountiful Bounty Campaign, Angel Shares, BitShares, etc. To do so we would like to purchase Ads on Lets Talk Bitcoin for every show. There are 30 second and 60 second ad slots.
Adam charges about $400 to produce Ads, so I am offering a bounty worth about $1000 to get the community to compete to produce the best Ads that invite people to learn more about Invictus the Movement and what we are doing here. Adam told me he would be competing for these bounties so the competition is on!
If we choose to air your Ad then we will pay you 50 PTS, otherwise not.
I would suggest that people cooperate to write the scripts and then compete on production quality and share the bounty with the script writers.
Bottom line, we want to communicate the community, philosophy, potential, and profit. This is not about advertising Invictus, but our movement.
Adam charges about $400 to produce Ads, so I am offering a bounty worth about $1000 to get the community to compete to produce the best Ads that invite people to learn more about Invictus the Movement and what we are doing here. Adam told me he would be competing for these bounties so the competition is on!
If we choose to air your Ad then we will pay you 50 PTS, otherwise not.
I would suggest that people cooperate to write the scripts and then compete on production quality and share the bounty with the script writers.
Bottom line, we want to communicate the community, philosophy, potential, and profit. This is not about advertising Invictus, but our movement.
524
Marketplace / 1500 PTS - Bitcoin clone with Dividends, POS, and Signature POW [CANCELED]
« 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.
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.
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.
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.
525
Marketplace / 1000 PTS - Ripple-Style Consensus Implementation [CLOSED]
« on: December 31, 2013, 05:14:13 am »
I am looking for someone to develop a flexible, reusable, ripple-style consensus implementation. This algorithm should be transaction content neutral. The purpose of the algorithm is to allow a group of trusted nodes (Unique Node List) to reach consensus about the content of a merkel tree and timestamp for the next block and should add new blocks as quickly as possible.
For the purpose of this general purpose algorithm a transaction is just a blob of data and a transaction ID (hash of data) is valid if the node merely has a copy of this blob of data and the TRX ID does not already exist in the block chain.
The UNL is a database of IP addresses and Public Keys and all nodes connect to all other nodes.
Blobs of data are distributed among the nodes in the UNL using bitcoin style INV and GET_INVENTORY and GET_MESSAGE messages.
This code should be built on top of the BitShares repository which already has primitives for the following:
1) Blob broadcast via the bitchat (email) system
2) Secure/encrypted sockets
3) JSON / Binary serialization
4) Elliptic Curve Utilities, etc....
This code should be built to follow coding conventions used in the bitshares code base.
This code should be built with the intention of being an API, a reusable component of a DAC toolkit.
This code must be developed in the open, on github
If a team of people work on it, then all participants must agree to the division of the bounty and github commits will track who did what.
For a video explanation of the algorithm:
http://www.youtube.com/watch?v=pj1QVb1vlC0
https://ripple.com/wiki/Unedited_Notes
The code must be complete with documentation and a working network of at least 20 nodes where new transactions are introduced to random nodes at random intervals at up to 1 MB of transaction data every 5 minutes with an average transaction size of 200 bytes.
Like all bounties, I am looking to purchase this as an off-the-shelf solution to the consensus problem with our code. It must build as part of the bitshares code base.
I will provide feedback on the API as it develops and steer this in the direction I want, but suspect that the time / cost to implement should be far less than the bounty!
For the purpose of this general purpose algorithm a transaction is just a blob of data and a transaction ID (hash of data) is valid if the node merely has a copy of this blob of data and the TRX ID does not already exist in the block chain.
The UNL is a database of IP addresses and Public Keys and all nodes connect to all other nodes.
Blobs of data are distributed among the nodes in the UNL using bitcoin style INV and GET_INVENTORY and GET_MESSAGE messages.
This code should be built on top of the BitShares repository which already has primitives for the following:
1) Blob broadcast via the bitchat (email) system
2) Secure/encrypted sockets
3) JSON / Binary serialization
4) Elliptic Curve Utilities, etc....
This code should be built to follow coding conventions used in the bitshares code base.
This code should be built with the intention of being an API, a reusable component of a DAC toolkit.
This code must be developed in the open, on github
If a team of people work on it, then all participants must agree to the division of the bounty and github commits will track who did what.
For a video explanation of the algorithm:
http://www.youtube.com/watch?v=pj1QVb1vlC0
https://ripple.com/wiki/Unedited_Notes
The code must be complete with documentation and a working network of at least 20 nodes where new transactions are introduced to random nodes at random intervals at up to 1 MB of transaction data every 5 minutes with an average transaction size of 200 bytes.
Like all bounties, I am looking to purchase this as an off-the-shelf solution to the consensus problem with our code. It must build as part of the bitshares code base.
I will provide feedback on the API as it develops and steer this in the direction I want, but suspect that the time / cost to implement should be far less than the bounty!
