Care to say who the other members of the project are. You kept referencing "we".
Future proofing and to be inclusive to you all who are giving feedback. For now it's just me coding and specifying. But I consider myself more of a lead developer managed and guided by the community, also with contributions from the community. So I'll just flip between saying I and we for a while I guess!
|
|
|
Does this mean these tasks are likely to be completed by next weekend and we can start testing the reference daemon on the testnet?
Yes, step one entails recreating litecoin from the latest stable bitcoin branch, adjusting as needed, renaming things, and putting in the block chain configuration. It isn't a major amount of work, but will need extensive testing to ensure no bugs have been introduced. Any testing, feedback, bug reports during the week will be gratefully received.
|
|
|
Eta?
Uncertain. Targets for this working week are to have: - chosen & secured a name + domain
- base reference daemon ready for testing and running on the testnet
- developed and tested instamine prevention
|
|
|
Start using Bitcoin instead of dreaming of getting rich and making something "new".
Please take the time to read the overview, I've taken every step I can to try and engage the community whilst making it clear that this isn't about getting rich. It's a programming / standardization project, not an alt coin get rich quick scheme. One I see a need for precisely because I have used Bitcoin extensively for a number of years. I don't want your money, just some feedback or discussion, if you have the time to give it. Hopefully that's a reasonable request.
|
|
|
Yeah I think it's almost always necessary to have at least some funds at the start so that there are enough resources to get the launch going properly.
if an IPO or similar is ever established, i would like to suggest a ROI over 12 or more months later to reduce investors dumping coins
I'm very keen to avoid any kind of IPO, debt, or false expectation. Some funds may be necessary for a dedicated server (development / website / resources / main node), domain names, some templates and graphic resources, and some leased mining for the testnet so we can switch between 10mh and 200mh. All of that together is probably only 1-2 BTC per month max. This thread seems to have worked and attracted some good people to the discussion, so I'm confident that as a need for each resource arises we'll be able to come to a reasonable solution. Since this is the opposite of new most coins in here (no rush to launch, inflate price, scam, dump on markets and so forth) the considerations are quite different, and also the problems. As an example you don't really see Bitcoin or Litecoin suffering from huge negative changes in difficulty due to multipools, or clambering to be added to an exchange or pool as soon as possible. This coin will be the same, if an exchange see's merit of adding it due to demand then so be it, if somebody wants to set up a pool, then great, but we won't be pushing for it. Organic natural growth based on adoption and utility is the goal. I'm perfectly happy for the coin to have negligible value at the start.
|
|
|
Developer Earnings Calculation --------------------- If we pin a milestone target of $ parity on the value of the coin, and assume no coins are touched, then after a year the developer will have ~$6500-$13000 worth of coin from block rewards. Assuming a 100 hour per month commitment to the project, that equates to an hourly rate of $5.5-$11 per hour of work.
This seems really low to me. But I'd like to hear what other people think. There is potential for higher rewards but dollar parity after a year would be a 5.25 million dollar market cap(if I calculated that right) which wouldn't be a failure at all and I would think the devs would deserve more than that. It's all relative. If the project picks up to an $84m cap instead, and the developer has earned $200k worth of coins, without transaction fees, and with the assumption that they'll mine or buy a few hours worth of blocks themselves over the year. Then people may feel that's high. I'd like to avoid being in a position where people feel those working on the project are excessively remunerated.. complaints of "not enough" are far nicer to deal with than complaints of "too much!". This would be a very healthy experiment. I still consider the IPO model (paying the developer up-front) to be fair still. This would be a lot more fair than that.
I have an alternative to the IPO model and donation model which I may need to turn to in order to buy some resources for the project (templates, servers, leased rigs for testnet). If we follow the notion that the developer is hired by the community, then developer days (monthly developer reward / 25) = ~52.5 coins could be auctioned or sold in advance at an agreed rate, and only for a reasonable amount of time, say an "advance" of "next weeks wages" at an agreed amount in return for ~250 coins. It seems a reasonable approach to funding the early stage resources. Not quite as nice as blind donations, and not as risky as IPO.
|
|
|
Thank you both, and mymenace for your kind feedback in my previous discussion threads. I understand a 50% transaction fee tax to attract miners and the fact it reduces to a small 0.125-0.250% tax, I am just unsure for the user how this correlates.
e.g. If i send 2 coins to user, do I then have to pay 1 coin to the network
if so another great idea as it will reduce people taking advantage of arbitrage during early development, but unsure if the tax applies to buying the coin on exchanges or from other people
did i get this right
I will add a Taxation section which clarifies this to the wiki, after this conversation. The Taxation / Developer funding works as follows: precursor: The block tax rate has not been decided yet, somewhere in the region of 0.125% to 0.25%. Mining ---------------------- If you mine a block the miner will receive: 20 coin (the full reward) The developer will receive: 0.025-0.05 coin. This equates to 0.9 to 1.8 blocks per day to the development team, or 18-36 coins per day. Out of a total of 14,400 new coins created each day. There is no trickery in this, no premine of that percentage, on every block mined the the stated percentage of reward is also sent to the development team. Transaction Fee --------------------- Traditional transaction fees apply, during the first 18 months: 50% of the fee is given to the developers, 50% to the miners. Every 18 months the developer tax % halves, and the miner fee increases correspondingly. So after 3 years the developer will get 12.5% and the miner 87.5%. This fee is to encourage the developers to focus on user adoption, the sooner they get it right, the more money they make (even though it's a marginal amount). Examples --------------------- You mine 10 blocks in a day. you will receive 20*10 coins, 200. The developers will receive 0.25-0.5 coins. The total coins minted per block will be 20.025 to 20.05. You send 120 coins to a friend, the applicable transaction fee is 0.004. You will send 120.004 as expected. The miner will claim 0.002 from the fee. The developer will claim 0.002 from the fee. Your friend will receive 120 coins. Developer Earnings Calculation --------------------- If we pin a milestone target of $ parity on the value of the coin, and assume no coins are touched, then after a year the developer will have ~$6500-$13000 worth of coin from block rewards. Assuming a 100 hour per month commitment to the project, that equates to an hourly rate of $5.5-$11 per hour of work. It's fair to presume I'm hoping the coin achieves a bit higher than $ parity over time, and the incentive is there. If $9 is achieved by ethical growth of the user base then this project becomes a successful full time job, or a small organization with paid staff. Sorry for being so verbose, I just want it to be clear.
|
|
|
Project BitmarkProject Bitmark is an initiative to create an every day use alternative currency. No premine, no IPO, nothing unfair, no scam, no clone, no old code bases, no untested code, no token features, just what you need. - Bitmark - a stable and balanced cryptographic currency. Its primary objectives are to be safe, secure, fast, actively developed, and easy to integrate for services and adopters. (read more...)
- Marking - our massive adoption program which fuses reputation+currency, the primary focus of Project Bitmark. Marking enables people to apply crypto currency simply to every aspect of their lives. (read more...)
Bitmark v0.9.4 has been released, please update your clients to keep our network secure. LinksWallet for all platforms, and actively developed source. Summary of Project BitmarkFull Specification of MarkingWiki and Extensive InformationBranding and LogosBitmark Block Explorer alternative blocktree.ioProject Bitmark uses VPS and hosting from CryptoCloudHosting - a physical server company accepting crypto payments, including BTM. Contact and CommunityProject Management on Trello : #bitmark on IRC : @ProjectBitmark on Twitter : @RobotMarkus our automated agent : /r/bitmark on RedditPoolsBitmark is balanced so you receive a fair reward wherever you mine. Active Pools: poolwarz : suprnova : minep.it : xhash.net : hash-to-coins : p2poolDetailed info for Solo Miners : Mining CalculatorExchangesCryptoShop (PayPal -> BTM) : Poloniex : BittrexStatsCoinMarketCap : World Coin Index : Coin Finance : Cryptonator : Cryptrader : Crypto Coin Charts : Network API : Network Health Charts : Steady Price API for services which use BTM pricingCoin SpecsAlgorithm: Scrypt Block Reward: 20 BTM ( visual) Block Time: 120 SecondsBlock Maturity: 720 Blocks (~1 day) to discourage multipools Block Halving: Reward halves every 3 years, with intermediate decrease every 18 months (20 coins initially, 15 after 1.5 years, 10 after 3 years, etc...) Difficulty Retargeting: 720 Blocks (~1 day) Total Coin Supply: ~27.58 million (27,579,894.73108000 exactly)Timeline and HistoryCheckpoints last updated at block 46519 1. Project Named: Bitmark detail and rationale2. Notes on the Bitmark, Block Reward, Monetary Supply, and (Network+Coin) Distribution3. Requests for Community Discussion on Third Party Innovations4. Development Fund / Taxation in Detail5. Development Started & Initial Funding Request6. Microtransactions and Microtrust (Migrating to Sidechain)7. Allocation of Variables8. Scratchpad of thoughts9. First test build released10. temporary mainnet added, unit tests passing, unconditional support for several BIPs11. v2 block chain, testnet available, checkpoints, miner testing12. clone-able reference implementation is underway, stratum-mining support, branding?13. bitmark core user interface (qt) technically complete, reference implementation technically complete14. new logo and branding added to bitmark core15. Project Bitmark Organisation16. Pfennig/Bitmark Pre-Release17. Pfennig/Bitmark Pre-Release tested on linux and windows, pending osx build and testing18. OS-X build requires further testing19. Pre-Release successfully tested on all platforms20. Discarded the taxation proposal21. IPM suggestion22. Dedicated server budget acquired, we can launch23. All resources purchased, foundation, funding, status24. Release time poll25. Release scheduled for 2014-07-13 at 18:00 UTC26. Release ready with some hours to spare.27. RELEASED28. The Bitmark Foundation - first donation.29. Launch analysis, mining, block chain configuration determined to be reasonable.30. We propose Investor Public Mining (IPM) to the community. 31. IPM Pool 3 Day Test. 32. What makes Bitmark distinct. 33. Decentralization of Supply and Distribution and Spreading out the Bitmark Network. 34. Investor Public Mining (IPM) Pool Test Update35. P2Pool and Checkpoints36. Get Marked37. A significant modification to IPM38. getMarked.org39. One Week Old40. GPU Mining41. Areas where help is needed42. Comparison of the Currency Supply of Bitcoin, Bitmark, and Litecoin43. Bitmark's Value, 13 Day Review44. Evaluating the effect of Exchanges, NOMP, Service Ideas45. Marking46. Support added to inuit, a very neat cold storage application 47. bitcore, insight-api, insight support48. @ProjectBitmark and /r/bitmark49. bitmark.co collaboratively specified50. BTM lands on it's first exchange, Poloniex51. Project Bitmark adopt's open transparent project management52. Project Bitmark Status Overview 153. Network Health Charts54. New Identity, Prototype Marking / Giving / Payment Buttons55. Pfennig ready to fork, Cryptonator, hash-to-coins, crypto-prices, checkpoints56. new block explorer57. network difficulty over 20058. new bitmark branding59. Bitmark v0.9.2.2 Released60. Bitmark Innovation and the API61. Pfennig updated to 0.9.2.262. Brain Wallet and Address Generator63. The mark (₥) is 1⁄1000 of a BTM64. Marking visualized in image65. Marking - DACs and Multi Signatures66. This week marks history for GridSeed Wholesale, it is the first time we feature a non-altcoin concept as the coin of the week.67. We will be working to support identifi and merge it in with marking, giving us a big open p2p trust network as another backbone for our system 68. The team has migrated to an integrated team environment on slack.com. Contact for an invite. 69. The first marking implementations have begun, jurassic mark - primitive marking implementations. 70. Our team is now in double digits, including the addition of another committed developer. 71. Technical specifications of data related to marking are being defined on the marking wiki. 72. Our first non human agent joined the team, markus a hubot integrated in to most of our tools now also works hard for us. 73. Markus is on twitter @RobotMarkus - he will provide team updates The Bitmark FoundationThe Bitmark Foundation is to be specified over the coming months, to be launched fully funded on the 2015-07-13, our one year anniversary. The Foundation will model an autonomous organisation, and oversee the work on Project Bitmark, with members who specialize in multiple sectors. We have decided to lower our funding goal for the Bitmark Foundation to 5000 BTM, and we will not actively seek to raise funds after this amount is reached. Together we are creating Marking, the technology which solves funding issues for every person and project in the world. The Bitmark Foundation and work done by this umbrella project will be funded in this way too. The Foundation funds will be held as a reserve and will not be touched until after 2015-07-13, in the future they will be used to mark worthy projects and charities. Donation can be made to bQmnzVS5M4bBdZqBTuHrjnzxHS6oSUz6cG. Donations towards current development over the first year are also accepted, in the form of BTC. The donation address is 1KsbYk2rMvwg456PyPmLuEgERPwyuxtGRL. We are entirely community funded. previous addressClone us with PfennigWe have released and are maintaining Pfennig as a community service, so that new scrypt based clones can be created from a modern, tested, and secure code base, instead of using outdated and copy-pasted legacy code. Our rationale is that people will create clones, so we may as well ensure those who use the clones have a good code base to back up any perceived value the clones may have. Pfennig is kept up to date, and is always based on the latest tagged Bitmark release, and also the latest tagged Bitcoin release. CreditsContributorsmymenace: Provided logo concepts and high quality final revisions Allow: Provided gui design elements and design input schnötzel, pandher, macbackfat, Este Nuno: All helped test Bitmark/Pfennig on various platforms DonatorsAnonymous: 0.0159 BTC Guriqbal Pandher: 0.2 BTC PondSea (on behalf of the Qora Community): 0.1 BTC Pentamon: 0.1 BTC Este Nuno: 0.1 BTC ethought: 0.1 BTC deepcoreotc: 0.0023 BTC chengren: 0.05 BTC zadinga: 0.03 BTC lukasplus: 0.01 BTC Mark Pfennig: 200 BTM Androidicus: 50 BTM Len: 200 BTM prix: 251 BTM medic: 250 BTM lukasplus: 50 BTM (Now too many to mention, all are equally and gratefully received...) When reading this thread, bitmark is evolutionary over time, this thread was originally titled 'define' and merged the conversation from several other threads, when reading this please be aware that it is a discussion which defined the project, many posts you read below and things discussed changed, were dropped, or were added over time, you can track the growth by reading through. It was many pages in before the 'bitmark' you know today was even created, and several more before 'marking'. The project continues to define and refine what is being done every week, it is a living and evolving project. For example, in reply one you will see the mention of 'taxation', which does not exist, we defined it then found it would break backwards compatibility so moved to donations instead. This is but one example.
|
|
|
Humans like to own full unit's of things, and feel that a full unit has value.
Currently 1 BTC is a thing of value. If/when BTC goes over $1k value again then 1 mBTC is a thing of value. If/when BTC goes over $1m then 1 bit is a thing of value.
When I say "thing of value" in this context I mean something that people will not throw away too easily.
If everybody has hundreds of thousands, or millions, of bits then the perceived value of 1 bit will go down, making the value overall decrease.
|
|
|
A good coin will be identified even "the Announcements section is full of spam and speculation" A good coin find enough people "who are willing to follow and discuss the project....."
I guess this may be the case and removing incentive to try and pump/dump/speculate by the previous methods may naturally filter things out. Thank you.
|
|
|
Suggestion: Transactionless blocks are redundant and encourage unneeded mining Simple Solution: Force a requirement that at least 1 transaction must be in each block Problems: - A- It may need to be if a transaction is in the last n blocks, where n is number of confirmations required, to ensure network quality of service
- B- Miners can just create random transactions - this is a non issue once a move to fee only remuneration has been made
Conclusion: Transactionless blocks are not viable and any suggested implementation would be susceptible to problem B. Agree?
|
|
|
I'm facing a dilemma, I would like to announce a project to create a new coin, but the Announcements section is full of spam and speculation.
The goal is to find a group of people who are willing to follow and discuss the project, helping to make rational decisions throughout the specification stage, test, and provide feedback along the way. I've already been able to cover many of the basics on various threads, but it's reaching a point where a consolidated thread would really help, or perhaps an alternative venue to discuss.
This will be a coin with no IPO, no premine, instamine, or anything of the like - the coin is to run on a testnet during development and once on the main chain we hope to keep it's value down, earning value as we go through adding utility with a user focussed approach to the entire project.
Any suggestions would be welcomed.
|
|
|
Perhaps a lazy question, but which major coin has the cleanest and most refined codebase?
I'm looking for a good, stable, starting base for a PoW coin - bitcoin and litecoin latest stables seem like good starting points, but are you aware of any others which have had reasonable development and roll out, and which aren't bloated or customized to hell and back.
Thank you.
|
|
|
Can I ask if you could take some time to define a dictionary of terms used in your posts somewhere. I'm familiar with many but only because I have pre existing knowledge. It is hard to distinguish between what is a technology, and innovation, a third party piece of software, a component of the system, and so forth.
Do keep up the good work, I'll be watching this closely.
|
|
|
Indeed, and businesses like Coinbase are working hard to support the infrastructure. However, this external infrastructure seems to be adding a useless risk where we have to trust a third-party, considering that many of the features they add can be included directly in altcoins (like the faster transaction time and lower fees).
Imho, using an altcoin with better features is safer than using Bitcoin with an external app which compensates for its flaws.
That's true. And that's an interesting way to look at using altcoins. They are likely safer than using a centralised third party. So that might be a good way to market an altcoin to people using bitcoin already. Great points, thank you. There is another option to throw in to the mix. Applications (website and services) can be designed in such a way that they interface with a users personal detail without ever having any direct control themselves, and without needing to take or store any personal information. Consider an alt with a well defined API, a personal hosted node, and various client side web services which could interface with any node defined. You would then have a range of UIs and services which respected the personal and decentralized nature of crypto currency / block chain. Over these threads I think I've collected enough information to begin specifying a project which has some merit. Would any of you be willing to give further feedback once I've collated everything in to a rough specification?
|
|
|
I'm curious, do you have any exemple of a coin that is expensive to use or hard to use?
Bitcoin is expensive and slow. Easy to use for the most part. But could be a lot better for the average person. All of these things are subjective and depend on the use case. Bitcoin is expensive compared to random-alt, cheap compared to paypal. Slow compared to paypal, fast compared to international wire transfer. Easy to use compared to most software in the world, difficult compared to most online payment systems. All of these things can be addressed by supporting infrastructure, extension, or third party software. For example, we could easily make an open source skrill or paypal which allows multiple service providers to give abstracted access to the bitcoin system, whilst remaining interoperable. Decentralized does not preclude federated, and federated does not mean centralized. Bitcoin the protocol allows the small operator to innovate and compete with the big guys in many market places.
|
|
|
X509 certificate server - provides Texai X509 certificates when installing full nodes X509 authentication - each agent and each hardware node is assigned an X509 certificate for pseudonymous authentication SSL/TLS network - communications between authenticated full nodes are encrypted with X509 certificates on both endpoints
Do not mix authentication with authorization. Let each node be named with a URI (URI-A) Nodes issue their own certificates with URI-A in the subjectAltName part of the x509 As authentication dereference URI-A to find RDF-data, check for the public key from the x509. If public key is found, assert that the node "owns" URI-A and thus can use it as an identifier. This covers authentication and allows each node to revoke and change certificates as it chooses, it also allows nodes to provide more information at the dereferenceable URI and acts as an extension point. Layer on authorization using ACL, which can also be implemented using RDF. See webid (formerly foaf-ssl) for more information, see web access control for more on authn. Consider defining a simple protocol that allows multiple forms of passing keys and establishing identifiers for agents, x509 may need to be replaced, legacy and different networks may need different auth protocols, your suggested approach binds to HTTP+TLS only, when multiple transport level protocol may be required for this. Webserver - full node statistics and network operations are presented to the operator via HTML pages
I suggest an RDF data API, it will be far more beneficial if the information is machine readable data (possibly with a default HTML view.. RDFa?), then multiple different UIX can be built on top allowing independent innovation and it'll be readily extensible by using new classes and properties in the rdf. I did not know about Web ID. Your ideas are great. I was using UUIDs (random) as subject UIDs in the X.509 certificates I generate. I can revise the server to accept a Web ID from the user, and return the certificate as you suggest. Actually I have intermediate X.509 certificates that issue the end-user certificates. The root certificate is self-signed for texai.org - so no dependency on a trusted third party as a Certificate Authority. The full node will host multiple agents and each agent can have skillful roles. The roles message other agent-roles in the network and need certificates to sign their messages if leaving the full node and going across the network. I can use UUID subject certificates for this purpose. I use a single IANA port already reserved for Texai, over which I will run TLS/SSL encrypted messages for Bitcoin, plus HTTPS for network operations, and BitTorrent for rapid provisioning of new full nodes. For the past couple of days, I have been upgrading the Bouncy Castle Java cryptographic libraries to the newest versions. When those unit tests all work again, I will add the TLS/SSL networking code from Texai, and after that the agent framework from Texai. An RDF API would be straight forward. I use the Sesame quad store to contain RDF statements. I will leave bitcoind and the blockchain alone, but the quad store will contain the OpenCyc knowledge base, and persisted java objects. I wrote an RDF entity manager which persists Java objects analogous to how Hibernate does it with a relational database. Great to hear. I believe somebody has already marked up the blockchain as RDF if that would be of use, indeed a few of us have been working on bitcoin+semantic-web for a few years, nothing vastly productive to show for it, but we've certainly prototyped and mapped the architecture out. They are a powerful match!
|
|
|
|