Release [obsolete] Release I - 32MB Block Size Limit ...

Epic Cash AMA Recap with CryptoDiffer Community

CryptoDiffer team Hello, everyone! We are glad to meet here: Max Freeman (@maxfreeman4), Project Lead at Epic Cash Yoga Dude (@Yogadude), PR&Marketing at Epic Cash Xenolink (@Xenolink), Advisor at Epic Cash
Max Freeman Project Lead at Epic Cash Thanks Max, we are excited to be here!
Yoga Dude PR&Marketing at Epic Cash Hello Everyone! Thank you for having us here!
Xenolink Advisor at Epic Cash Thank you to the CryptoDiffer team and CryptoDiffer community for hosting us!
CryptoDiffer team Let`s start from the first introduction question: Q1: Can you introduce yourself to the community? What is your background and how did you join Epic Cash?
Yoga Dude PR&Marketing at Epic Cash
Hello! My background is Marketing and Business Development, I’ve been in crypto since 2011 started with Bitcoin, then Monero in 2014, Ethereum in 2015 and at some point Doge for fun and profit. I joined Epic Cash team in September 2019 handling PR and Marketing.
I saw in Epic Cash what was missing in my previous cryptos — things that were missing in Bitcoin and Monero especially.
Xenolink Advisor at Epic Cash
Hello Cryptodiffer Community, I am not an original co-founder nor am I a developer for the Epic Cash project. I am however a community member that is involved in helping scale this project to higher levels. One of the many beauties of Epic Cash is that every single member in the community has the opportunity to be part of EPIC’s team, it can be from development all the way to content producing. Epic Cash is a community driven project. The true Core Team of Epic Cash is our community. I believe a community that is the Core Team is truly powerful. EPIC Cash has one of the freshest and strongest communities I have seen in quite a while. Which is one of the reasons why I became involved in this project. Epic displayed some of the most self community produced content I have seen in a project. I’m actually a doctor of medicine but in terms of my experience in crypto, I have been involved in the industry since 2012 beginning with mining Litecoin. Since then I have been doing deep dive analysis on different projects, investing, and building a network in crypto that I will utilize to help connect and scale Epic in every way I can. To give some credit to those people in my network that have been a part of helping give Epic exposure, I would like to give a special thanks to u/Tetsugan and u/Saurabhblr. Tetsugan has been doing a lot of work for the Japanese community to penetrate the Japanese market, and Japan has already developed a growing interest in Epic. Daku Sarabh the owner and creator of Crypto Daku Robinhooders, I would like to thank him and his community for giving us one of our first large AMA’s, which he has supported our project early and given us a free AMA. Many more to thank but can’t be disclosed. Also thank you to all the Epic Community leaders, developers, and Content producers!
Max Freeman Project Lead at Epic Cash
I’m Max Freeman, which stands for “Maximum Freedom for Mankind”. I started working on the ideas that would become Epic in 2018. I fell in love with Bitcoin in 2017 but realized that it needs privacy at the base layer, fungibility, better scalability in order to go to the next level.
CryptoDiffer team
Really interesting backgrounds I must admit, pleasure to see the team that clearly has one vision of the project by being completely decentralized:)
Q2: Can you briefly describe what is Epic Cash in 3–5 sentences? What technology stands behind Epic Cash and why it’s better than the existing one?
Max Freeman Project Lead at Epic Cash
I’d like to highlight the differences between Epic and the two highest-valued privacy coin projects, Monero and Zcash. XMR has always-on privacy like Epic does, but at a cost: Its blockchain is over 20x more data intensive than Epic, which limits its possibilities for scalability. Epic’s blockchain is small and light enough to run a full node on cell phones, something that is in our product road map. ZEC by comparison can’t run on low end devices because of its zero knowledge based approach, and only 1% of transactions are fully private. Epic is simply newer, more advanced technology than prior networks thanks to Mimblewimble
We will also add more algorithms to widen the range of hardware that can participate in mining. For example, cell phones and tablets based around ARM chips. Millions of people can mine Epic that can’t mine Bitcoin, and that will help grow the network rapidly.
There are some great short videos on our YouTube channel https://www.youtube.com/channel/UCQBFfksJlM97rgrplLRwNUg/videos
that explain why we believe we have created something truly special here.
Our core architecture derives from Grin, so we are fortunate to benefit on an ongoing basis from their considerable development efforts. We are focused on making our currency truly usable and widely available, beyond a store of value and becoming a true medium of exchange.
Yoga Dude PR&Marketing at Epic Cash
Well we all have our views, but in a nutshell, we offer things that were missing in the previous cryptos. We have sound fiscal emission schedule matching Bitcoin, but we are vastly more private and faster. Our blockchain is lighter than Bitcoin or Monero and our tech is more scalable. Also, we are unique in that we are mineable with CPUs and GPUs as well as ASICs, giving the broadest population the ability to mine Epic Cash. Plus, you can’t forget FUNGIBILITY 🙂 we are big on that — since you can’t have true privacy without fungibility.
Also, please understand, we have HUGE respect to all the cryptos that came before us, we learned a lot from them, and thanks to their mistakes we evolved.
Xenolink Advisor at Epic Cash
To add on, what also makes Epic Cash unique is the ability to decentralize the mining using a tri-algo model of Random X (CPU), Progpow (GPU), and Cuckoo (ASIC) for an ability to do hybrid mining. I believe this is an issue we can see today in Bitcoin having centralized mining and the average user has a costly barrier of entry.
To follow up on this one in my opinion one of the things we adopted that we have seen success for , in example Bitcoin and Monero, is a strong community driven coin. I believe having a community driven coin will provide a more organic atmosphere especially when starting with No ICO, or Premine with a fair distribution model for everyone.
CryptoDiffer team
Q3: What are the major milestones Epic Cash has achieved so far? Maybe you can share with us some exciting plans for future weeks/months?
Yoga Dude PR&Marketing at Epic Cash
Since we went live in September of 2019, we attracted a very large community of users, miners, investors and contributors from across the world. Epic Cash is a very international project with white papers translated into over 30 languages. We are very much a community driven project; this is very evident from our content and the amount of translations in our white papers and in our social media content.
We are constantly working on improving our usability, security and privacy, as well as getting our message and philosophy out into the world to achieve mass adoption. We have a lot of exciting plans for our project, the plan is to make Epic Cash into something that is More than Money.
You can tell I am the Marketing guy since my message is less about the actual tech and more about the usability and use cases for Epic Cash, I think our Team and Community have a great mix of technical, practical, social and fiscal experiences. Since we opened our YouTube channels content for community submissions, we have seen our content translated into Spanish, French, German, Polish, Chinese, Japanese, Arabic, Russian, and other languages
Max Freeman Project Lead at Epic Cash
Our future development roadmap will be published soon and includes 4 tracks:
Usability
Mining
Core Protocol
Ecosystem Development
Core Protocol
Epic Server 2.9.0 — this release improves the difficulty adjustment and is aimed at making block emission closer to the target 60 seconds, particularly reducing the incidence of extremely short and long blocks — Status: In Development (Testing) Anticipated Release: June 2020
Epic Server 3.0.0 — this completes the rebase to Grin 3.0.0 and serves as the prerequisite to some important functional building blocks for the future of the ecosystem. Specifically, sending via Tor (which eliminates the need to open ports), proof of payment (useful for certain dex applications e.g. Bisq), and our native mobile app. Status: In Development (Testing) Anticipated Release: Fall 2020
Non-Interactive Transactions — this will enhance usability by enabling “fire and forget” send-to-address functionality that users are accustomed to from most cryptocurrencies. Status: Drawing Board Anticipated Release: n/a
Scaling Options — when blocks start becoming full, how will we increase capacity? Two obvious options are increasing the block size, as well as a Lightning Network-style Layer 2 structure. Status: Drawing Board Anticipated Release: n/a
Confidential Assets — Similar to Raven, Tari, and Beam, the ability to create independently tradable assets that ride on the Epic Blockchain. Status: Drawing Board Anticipated Release: n/a
Usability
GUI Wallet 2.0 — Restore from seed words and various usability enhancements — Status: Needs Assessment Anticipated Release: Fall 2020
Mobile App — Native mobile experience for iOS and Android. Status: In Development (Testing) Anticipated Release: Winter 2020
Telegram Integration — Anonymous payments over the Telegram network, bot functionality for groups. Status: Drawing Board Anticipated Release: n/a
Mining
RandomX on ARM — Our 4th PoW algorithm, this will enable tablets, cell phones, and low power devices such as Raspberry Pi to participate in mining. Status: Needs Assessment Anticipated Release: n/a
The economics of mining Epic are extremely compelling for countries that have free or extremely cheap electricity, since anyone with an ordinary PC can mine. Individual people around the world can simply run the miner and earn meaningful money (imagine Venezuela for example), something that has not been possible since the very early days of Bitcoin.
Ecosystem Development
Atomic Swaps — Connecting Epic to other blockchains in a trustless way, starting with ETH so that Epic can trade on DeFi infrastructure such as Uniswap, Kyber, etc. Status: Drawing Board Anticipated Release: n/a
Xenolink Advisor at Epic Cash
From the Community aspect, we have been further developing our community international reach. We have been seeing an increase in interest from South America, China, Russia, Japan, Italy, and the Philippines. We are working on targeting more countries. We truly aim to be a decentralized project that is open to everyone worldwide.
CryptoDiffer team
Great, thank you for your answers, we now can move to community questions part!
Cryptodiffer Community
You have 3 mining algorithms, the question is: how do they not compete with each other? Is there any benefit of mining on the GPU and CPU if someone is mining on the ASIC?
Max Freeman Project Lead at Epic Cash
The block selection is deterministic, so that every 100 blocks, 60% are for RandomX (CPU), 38% for ProgPow (GPU), and 2% for Cuckoo (ASIC) — the policy is flexible so that we can have as many algorithms with any percentages we want. The goal is to make the most decentralized and resilient network possible, and with that in mind we are excited to work on enabling tablets and cell phones to mine, since that opens it up to millions of people that otherwise can’t take part.
Cryptodiffer Community
To Run a project smoothly, Funding is very important, From where does the Funding/revenue come from?
Xenolink Advisor at Epic Cash
Yes, early on this was realized and in order to scale a project funds are indeed needed. Epic Cash did not start with any funding and no ICO and was organically genesis mined with no pre-mine. Epic cash is also a nonprofit community driven project similar to Monero. There is no profit-driven entity in the picture. To overcome the revenue issue Epic Cash setup a development fund tax that decreases 1% every year until 2028 when Epic Cash reaches singularity with Bitcoin emissions. Currently it is at 7.77%. This will help support the scaling of the project.
Cryptodiffer Community
Hi! In your experience working also with MONERO can you please clarify which are those identified problems that EPIC CASH aims to develop and resolve? What’s the main advantage that EPIC CASH has over MONERO? Thank you!
Yoga Dude PR&Marketing at Epic Cash
First, I must admit that I am still a huge fan and HODLer of Monero. That said:
✅ our blockchain is MUCH lighter than Monero’s
✅ our transaction processing speed is much faster
✅ our address-less blockchain is more private
✅ Epic Cash can be mined with CPU (RandomX) GPU (ProgPow) and Cuckoo, whereas Monero migrated to RandomX and currently only mineable with CPU
Cryptodiffer Community
  1. the feature ‘Cut Through’ deletes old data, how is it decided which data will be deletes, and what are the consequences of it for the platform and therefore the users?
  2. On your website I see links to download Epic wallet and mining software for Linux,Windows and MacOs, I am a user of android, is there a version for me, or does it have a release date?
Max Freeman Project Lead at Epic Cash
  1. This is one of the most exciting features of Mimblewimble, which is its extraordinary ability to compress blockchain data. In Bitcoin, the entire history of a coin must be replayed every time it is spent, and comprehensive details are permanently stored in the blockchain. Epic discards spent transaction inputs and consolidates outputs, storing neither addresses or amounts, only a tiny kernel to allow sender and receiver to prove their transaction.
  2. The Vitex mobile app is great for today, and we have a native mobile app for iOS and Android in the works as well.
Cryptodiffer Community
$EPIC Have total Supply of 21,000,000 EPIC , is there any burning plan? Or Buyback program to maintain $EPIC price in the future?
Who is Epic Biggest competitors?
And what’s makes epic better than competitors?
Xenolink Advisor at Epic Cash
We respect the older generation coins like Bitcoin. But we have learned that the supply economics of Bitcoin is very sound. Until today we can witness how the Bitcoin is being adopted institutionally and by retail. We match the 21 million BTC supply economics because it is an inelastic fixed model which makes the long-term economics very sound. To have an elastic model of burning tokens or printing tokens will not have a solid economic future. Take for example the USD which is an inflating supply. In terms of competitors we look at everyone in crypto with respect and also learn from everyone. If we had to compare to other Mimblewimble tech coins, Grin is an inelastic forever inflating supply which in the long term is not sound economics. Beam however is an inelastic model but is formed as a corporation. The fair distribution is not there because of the permanent revenue model setup for them. Epic Cash a non-profit development tax fund model for scaling purposes that will disappear by 2028’s singularity.
Cryptodiffer Community
What your plans in place for global expansion, are you focusing on only market at this time? Or focus on building and developing or getting customers and users, or partnerships?
Yoga Dude PR&Marketing at Epic Cash
Since we are a community project, we have many developers, in addition to the core team.
Our plans for Global expansion are simple — we have advocates in different regions addressing their audiences in their native languages. We are growing organically, by explaining our ideology and usability. The idea is to grow beyond needing a fiat bridge for crypto use, but to rather replace fiat with our borderless, private and fungible crypto so people can use it to get goods and services without using banks.
We are not limiting ourselves to one particular demographic — Epic Cash is a valid solution for the gamers, investors, techie and non techie people, and the unbanked.
Cryptodiffer Community
EPIC confidential coin! Did you have any problems with the regulators? And there will be no problems with listing on centralized exchanges?
Xenolink Advisor at Epic Cash
In terms of structure, we are carefully set up to minimize these concerns. Without a company or investors in the picture, and having raised no funds, there is little scope to attack in terms of securities laws. Bitcoin and Ethereum are widely acknowledged as acceptable, and we follow in their well-established footprints in that respect. Centralized exchanges already trade other privacy coins, so we don’t see this as much of an issue either. In general, decentralized p2p exchange options are more interesting than today’s centralized platforms. They are more censorship resistant, secure, and privacy-protecting. As the technology gets better, they should continue to gain market share and that’s why we’re proud to be partnered with Vitex, whose exchange and mobile app work very well.
Cryptodiffer Community
What are the main utility and real-life usage of the #EPIC As an investor, why should we invest in the #EPIC project as a long-term investment?
Max Freeman Project Lead at Epic Cash
Because our blockchain is so light (only 1.16gb currently, and grows very slowly) it is naturally well suited to become a decentralized mobile money standard because people can run a full node on their phone, guaranteeing the security of their funds. Scalability in Bitcoin requires complicated and compromised workarounds such as Lightning Network and light clients, and these problems are solved in Epic.
With our forthcoming Mobile Mining app, hundreds of millions of cell phones and tablets will be able to easily join the network. People can quickly and cheaply send money to one another, fulfilling the long-envisioned promise of P2P electronic cash.
As an investor, it’s important to ask a few key questions. Bitcoin Standard tokenomics of disinflation and a fixed supply are well proven over a decade now. We follow this model exactly, with a permanently synchronized supply from 2028, and 4 emission halvings from now until then, with our first one in about two weeks. Beyond that, we can apply some simple logical tests. What is more valuable, money that can only be used in some cases (censorable Bitcoin based on a lack of fungibility) or money that can be used universally? (fungible Epic based on always-on privacy by default). Epic is also poised to be a more decentralized and therefore resilient network because of wider participation in mining. Epic is designed to be Bitcoin++ Privacy, Fungibility, Scalability
Cryptodiffer Community
Q1. What are advantages for choosing three mining algorithms RandomX+, ProgPow and CuckAToo31+ ?
Q2. Beam and Grin use MimbleWimble protocol, so what are difference for Epic? All of you will be friends for partners or competitors?
Max Freeman Project Lead at Epic Cash
RandomX and ProgPow are designed to use the entirety of a CPU / GPU’s unique processing capabilities in a way that other types of hardware don’t work as well. You can run RandomX on a GPU but it doesn’t work nearly as well as a much cheaper CPU, for example. Cuckoo is a “memory hard” algorithm that widens the range of companies that can produce the hardware.
Grin and Beam are great projects and we’ve learned a lot from them. We inherited our first codebase from Grin’s excellent Rust design, which is a better language for community participation than C++ that Beam currently uses.
Functionally, Mimblewimble is similar across the 3 coins, with standard Confidential Transactions, CoinJoin, Dandelion++, Schnorr Signatures and other advanced features. Grin is primarily ASIC-targeted, Beam is GPU-targeted, and Epic is multi-hardware.
The biggest differences though are in tokenomics and project structure. Grin has permanent inflation of 60 coins per block with no halvings, which means steady erosion of value over time due to new supply pressure. It also lacks a steady funding model, making future development in jeopardy, particularly as the per coin price falls. Beam has a for-profit model with heavy early inflation and a high developer tax. Epic builds on the strengths of these earlier mimblewimble projects and addresses the parts that could be improved.
Cryptodiffer Community Some privacy coin has scalability issues! How Epic cash will solve scalability issues? Why you choose randomX consensus algorithem?
Xenolink Advisor at Epic Cash
Fungibility means that you can’t distinguish one unit of currency from another, in example Gold. Fungibility has recently become a hot issue as people have been noticing Bitcoins being locked up by exchanges which may of had a nefarious history which are called Tainted Coins. In example coins that have been involved in a hack, darknet market transactions, or even processing coin through a mixer. Today we can already see freshly mined Bitcoins being sold at a premium price to avoid the fungibility problem Bitcoin carries today. Bitcoin can be tracked by chainalysis and is not a fungible cryptocurrency. One of the features that Epic has is privacy with added fungibility, because of Mimblewimble technology, Epic has no addresses recorded and therefore nothing can be tracked by chainalysis. Below I provide a link of an example of what the lack of fungibility is resulting in today with Bitcoin. One of the reasons why we chose the Random X algo. is because of the easy barrier of entry and also to further decentralize the mining. Random X algo can be mined on old computers or laptops. We also have 2 other algos Progpow (GPU), and Cuckoo (ASIC) to create a wider decentralization of mining methods for Epic.
Cryptodiffer Community
I’m a newbie in crypto and blockchain so how will Epic Cash team target and educate people who don’t know about blockchain and crypto?
What is the uniqueness of Epic Cash that cannot be found in other project that´s been released so far ?
Yoga Dude Pr&Marketing at Epic Cash
Actually, while we have our white paper translated into over 30 languages, we are more focused on explaining our uses and advantages rather than cold specs. Our tech is solid, but we not get hung up on pure tech talk which most casual users do not need to or care to understand. As long as our fundamentals and tech are secure and user friendly our primary goal is to educate about use cases and market potential.
The uniqueness of Epic Cash is its amalgamation of “whats good” in other cryptos. We use Mimblewimble for privacy and anonymity. Our blockchain is much lighter than our competitors. We are the only Mimblewimble crypto to use a unique cocktail of mining algorithms allowing to be mined by casual miners with gaming rigs and laptops, while remaining friendly to GPU and CPU farmers.
The “uniqueness” is learning from the mistakes of those who came before us, we evolved and learned, which is why our privacy is better, we are faster, we are fungible, we offer diverse mining and so on. We are the best blend — thats powerful and unique
Cryptodiffer Community
Can you share EPIC’s vision for decentralized finance (DEFI)? What features do EPIC have to support DEFI?
Yoga Dude PR&Marketing at Epic Cash
We view Epic as ideally suited to be the decentralized digital reserve asset of the new Private Internet of Money that’s emerging. At a technology level, atomic swaps can be created to build liquidity bridges so that wrapped Epic tokens (like WBTC, WETH) can trade on other networks as ERC20, BEP2, NEP5, VIP180, Algorand and so on. There is more Bitcoin value locked on Ethereum than in Lightning Network, so we will similarly integrate Epic so that it can trade on networks such as Uniswap, Kyber, and so on.
Longer term, if there is market demand for it, thanks to Scriptless Script functionality our blockchain has, we can build “Confidential Assets” (which Raven, Tari, and Beam are all also working on) that enable people to create tokenized assets in a private way.
Cryptodiffer Community
If you could choose one celebrity to promote Epic-cash, who that would be?
Max Freeman Project Lead at Epic Cash
I am a firm believer that the strength of the project lies in allowing community members to become their own celebrities, if their content is good enough the community will propel them to celebrity status. Organic celebrities with small but loyal following are vastly more beneficial than big name professional shills with inflated but non caring audiences.
I remember the early days of Apple when an enthusiastic dude named Guy Kawasaki became Apple Evangelist, he was literally going around stores that sold Apple and visited user groups and Evangelized his belief in Apple. This guy became a Legend and helped Apple become what it is today.
Epic Cash will have its OWN Celebrities
Cryptodiffer Community
How does $EPIC solve scalability of transactions? Current blockchains face issues with scalability a lot, how does $EPIC creates a solution to it?
Xenolink Advisor at Epic Cash
Epic Cash is utilizing Mimblewimble technology. Besides the privacy & fungibility aspect of the tech. There is the scalability features of it. It is implemented into Epic by transaction cut-through. Which means it allows nodes to remove all intermediate transactions, thus significantly reducing the blockchain size without affecting its validation. Mimblewimble also does not use addresses like a BTC address, and amount of transactions are also not recorded. One problem Monero and Bitcoin are facing now is scalability. It is evident today that data is getting more expensive and that will be a problem in the long run for those coins. Epic is 90% lighter and more scalable compared to Monero and Bitcoin.
Cryptodiffer Community
what are the ways that Epic Cash generates profits/revenue to maintain your project and what is its revenue model ? How can it make benefit win-win to both invester and your project ?
Max Freeman Project Lead at Epic Cash
There is a block subsidy of 7.77% that declines 1.11% per year until 0, where it stays after that. As a nonprofit community effort, this extremely modest amount goes much further than in other projects, which often take 20, 30, even 50+ % of the coin supply. We believe that this ongoing funding model best aligns the long term incentives for all participants and balances the compromises between the ends of the centralized/decentralized spectrum of choices that any project must make.
Cryptodiffer Community
Q1 : What are your major goals to archive in the next 3–4 years?
Q2 : What are your plans to expand and gain more adoption?
Yoga Dude Pr&Marketing at Epic Cash
Max already talked about our technical plans and goals in his roadmap. Allow me to talk more about the non technical 😁
We are aiming for broader reach in the non technical more mainstream community — this is a big challenge but we believe it is doable. By offering simpler ways to mine Epic Cash (with smart phones for example), and by doing more education we will achieve the holy grail of crypto — moving past the fiat bridges and getting Epic Cash to be accepted as means of payment for goods and services. We will accomplish this by working with regional advocacy groups, community interaction, off-line promotional activities and diverse social media targeting.
Cryptodiffer Community
It seems to me that EpicCash will have its first Halving, right? Why a halving so soon?
Is a mobile version feasible?
Max Freeman Project Lead at Epic Cash
Our supply emission catches up to that of Bitcoin’s first 19 years after 8 years in Epic, so that requires more frequent halvings. Today’s block emission is 16, next up are 8, 4, 2, and then finally 0.15625. After that, the supply of Epic and that of BTC stay synchronized until maxing out at 21m coins in 2140.
Today we have a mobile wallet through the Vitex app, a native mobile wallet coming, and are working on mobile mining.
Cryptodiffer Community
What markets will you add after that?
Yoga Dude PR&Marketing at Epic Cash
Well, we are aiming to have ALL markets
Epic Cash in its final iteration will be usable by everyone everywhere regardless of their technical expertise. We are not limiting ourselves to the technocrats, one of our main goals is to help the billions of unbanked. We want everyone to be able to mine, buy, and most of all USE Epic Cash — gamers, farmers, soccer moms, students, retirees, everyone really — even bankers (well once we defeat the banking industry)
We will continue building on the multilingual diversity of our global community adding support and advocacy groups in more countries in more languages.
Epic Cash is More than Money and its for Everyone.
Cryptodiffer Community
Almost, all cryptocurrencies are decentralized & no-one knows who owns that cryptocurrencies ! then also, why Privacy is needed? hats the advantages of Private coins?
Max Freeman Project Lead at Epic Cash
With a public transparent blockchain such as Bitcoin, you are permanently posting a detailed history of your money movements open for anyone to see (not just legitimate authorities, either!) — It would be considered crazy to post your credit card or bank statements to Twitter, but that’s what is happening every time you send a transaction that is not private. This excellent video from community contributor Spencer Lambert https://www.youtube.com/watch?v=0blbfmvCq\_4 explains better than I can.
Privacy is not just for criminals, it’s for everyone. Do you want your landlord to increase the rent when he sees that you get a raise? Your insurance company to raise your healthcare costs because they see you buying too much ice cream? If you’re a business, do you want your employees to see how much money their coworkers make? Do you want your competitors to trace your supplier and customer relationships? Of course not. By privacy being default for everyone, cryptocurrency can be used in a much wider range of situations without unacceptable compromises.
Cryptodiffer Community
What are the main utility and real-life usage of the #EPIC As an investor, why should we invest in the #EPIC project as a long-term investment?
Xenolink Advisor at Epic Cash
Epic Cash can be used as a Private and Fungible store of value, medium of exchange, and unit of account. As Epic Cash grows and becomes adopted it can be compared to how Bitcoin and Monero is used and adopted as well. As Epic is adopted by the masses, it can be accepted as a medium of exchange for store owners and as fungible payments without the worry of having money that is tainted. Epic Cash as a store of value may be a good long term aspect of investment to consider. Epic Cash carries an inelastic fixed supply economic model of 21 million coins. There will be 5 halvings which this month of June will be our first halving of epic. From a block reward of 16 Epic reduced to 8. If we look at BTC’s price action and history of their halvings it has been proven and show that there has been an increase in value due to the scarcity and from halvings a reduction of # of BTC’s mined per block. An inelastic supply model like Bitcoin provides proof of the circulating supply compared to the total supply by the history of it’s Price action which is evident in long term charts since the birth of Bitcoin. EPIC Plans to have 5 halvings before the year 2028 to match the emissions of Bitcoin which we call the singularity event. Below is a chart displaying our halvings model approaching singularity. Once bitcoin and cryptocurrency becomes adopted mainstream, the fungibility problem will be more noticed by the general public. Privacy coins and the features of fungibility/scalability will most likely be sought over. Right now a majority of people believe that all cryptocurrency is fungible. However, that is not true. We can already see Chainalysis confirming that they can trace and track and even for other well-known privacy coins today such as Z-Cash.
Cryptodiffer Community
  1. You aim to reach support from a global community, what are your plans to get spanish speakers involved into Epic Cash? And emerging markets like the african
  2. How am I secure I won’t be affected by receiving tainted money?
Max Freeman Project Lead at Epic Cash
Native speakers from our community are working to raise awareness in key markets such as mining in Argentina and Venezuela for Spanish (Roberto Navarro called Epic “the holy grail of cryptocurrency” and Ethiopia and certain North African countries that have the lowest electricity costs in the world. Remittances between USA and Latin American countries are expensive and slow, so Epic is also perfect for people to send money back home as well.
Cryptodiffer Community
Do EPICs in 2020 focus more on research and coding, or on sales and implementation?
Yoga Dude PR&Marketing at Epic Cash
We will definitely continue to work on research and coding, with emphasis on improved accessibility (especially via smartphones) usability, security and privacy.
In terms of financial infrastructure will continuing to add exchanges both KYC and non KYC.
Big part of our plans is in ongoing Marketing and PR outreach. The idea is to make Epic Cash a viral sensation of sorts. If we can get Epic Cash adopters to spread the word and tell their family, coworkers and friends about Epic Cash — there will be no stopping us and to help that happen we have a growing army of content creators, and supporters.
Everyone with skin in the game gets the benefit of advancing the cause.
Folks also, this isn’t an answer to the question but an example of a real-world Epic Cash content —
https://www.youtube.com/watch?v=XtAVEqKGgqY
a challenge from one of our content creators to beat his 21 pull ups and get 100 epics! This has not been claimed yet — people need to step up 🙂 and to help that I will match another 100 Epic Cash to the first person to beat this
Cryptodiffer Community
I was watching some videos explaining how to send and receive transactions in EpicCash, which consists of ports and sending links, my question is why this is so, which, for now, looks complex?
Let’s talk about the economic model, can EpicCash comply with the concept of value reserve?
Max Freeman Project Lead at Epic Cash
In V3, which is coming later this summer, Epic can be sent over Tor, which eliminates this issue of port opening, even though using tools like ngrok.io, it’s not necessarily as painful as directly configuring the router ports. Early Lightning Network had this issue as well and it’s something we have a plan to address via research into non-interactive transactions. “Fire and Forget” payments to an address, as people are used to in Bitcoin, is coming to Epic and we’re excited to develop functionality that other advanced mimblewimble coins don’t yet have. We are committed to constant improvement in usability and utility, to make our money system the ease of use leader.
We are involved in the project (anyone can join the Freeman Family) because we believe that simply by choosing to use a form of money that better aligns with our ideals, that we can make a positive change in the world. Some of my thoughts about how I got involved are here: https://medium.com/epic-cash/the-freeman-family-e3b9c3b3f166
Max Freeman Project Lead at Epic Cash
Huge thanks to our friends Maks and Vladyslav, we welcome everyone to come say hi at one of our friendly communities. It is extremely early in this journey, our market cap is only 0.5m right now, whereas the 3 other mimblewimble coins are at $20m, $30m and $100m respectively. Epic is a historic opportunity to follow in the footsteps of legends such as Bitcoin and Monero, and we hope to become the first Top 5 privacy coin project.
Xenolink Advisor at Epic Cash
Would like to Thank the Cryptodiffer Team and the Cryptodiffer community for hosting us and also engaging with us to learn more about Epic. If anyone else has more questions and wants to know more about EPIC , can find us at our telegram channel at https://t.me/EpicCash .
Yoga Dude Pr&Marketing at Epic Cash
Thank you, CryptoDiffer Team, and this wonderful Community!!!
Cryptodiffer TEAM
Thank you everyone for taking your time and asking great questions
Thank you for your time, it was an insightful session
Spread the love
submitted by EpicCashFrodo to epiccash [link] [comments]

ColossusXT Q2 AMA Ends!

Thank you for being a part of the ColossusXT Reddit AMA! Below we will summarize the questions and answers. The team responded to 78 questions! If you question was not included, it may have been answered in a previous question. The ColossusXT team will do a Reddit AMA at the end of every quarter.
The winner of the Q2 AMA Contest is: Shenbatu
Q: Why does your blockchain exist and what makes it unique?
A: ColossusXT exists to provide an energy efficient method of supercomputing. ColossusXT is unique in many ways. Some coins have 1 layer of privacy. ColossusXT and the Colossus Grid will utilize 2 layers of privacy through Obfuscation Zerocoin Protocol, and I2P and these will protect users of the Colossus Grid as they utilize grid resources. There are also Masternodes and Proof of Stake which both can contribute to reducing 51% attacks, along with instant transactions and zero-fee transactions. This protection is paramount as ColossusXT evolves into the Colossus Grid. Grid Computing will have a pivotal role throughout the world, and what this means is that users will begin to experience the Internet as a seamless computational universe. Software applications, databases, sensors, video and audio streams-all will be reborn as services that live in cyberspace, assembling and reassembling themselves on the fly to meet the tasks at hand. Once plugged into the grid, a desktop machine will draw computational horsepower from all the other computers on the grid.
Q: What is the Colossus Grid?
A: ColossusXT is an anonymous blockchain through obfuscation, Zerocoin Protocol, along with utilization of I2P. These features will protect end user privacy as ColossusXT evolves into the Colossus Grid. The Colossus Grid will connect devices in a peer-to-peer network enabling users and applications to rent the cycles and storage of other users’ machines. This marketplace of computing power and storage will exclusively run on COLX currency. These resources will be used to complete tasks requiring any amount of computation time and capacity, or allow end users to store data anonymously across the COLX decentralized network. Today, such resources are supplied by entities such as centralized cloud providers which are constrained by closed networks, proprietary payment systems, and hard-coded provisioning operations. Any user ranging from a single PC owner to a large data center can share resources through Colossus Grid and get paid in COLX for their contributions. Renters of computing power or storage space, on the other hand, may do so at low prices compared to the usual market prices because they are only using resources that already exist.
Q: When will zerocoin be fully integrated?
A: Beta has been released for community testing on Test-Net. As soon as all the developers consider the code ready for Main-Net, it will be released. Testing of the code on a larger test network network will ensure a smooth transition.
Q: Is the end goal for the Colossus Grid to act as a decentralized cloud service, a resource pool for COLX users, or something else?
A: Colossus Grid will act as a grid computing resource pool for any user running a COLX node. How and why we apply the grid to solve world problems will be an ever evolving story.
Q: What do you think the marketing role in colx.? When ll be the inwallet shared nodes available...i know its been stated in roadmap but as u dont follow roadmap and offer everything in advance...i hope shared MN's to be avilable soon.
A: The ColossusXT (COLX) roadmap is a fluid design philosophy. As the project evolves, and our community grows. Our goal is to deliver a working product to the market while at the same time adding useful features for the community to thrive on, perhaps the Colossus Grid and Shared Masternodes will be available both by the end of Q4 2018.
Q: When will your github be open to the public?
A: The GitHub has been open to the public for a few months now.
You can view the GitHub here: https://github.com/ColossusCoinXT
The latest commits here: https://github.com/ColossusCoinXT/ColossusCoinXT/commits/master
Q: Why should I use COLX instead of Monero?
A: ColossusXT offers Proof of Stake and Masternodes both which contribute layers in protection from 51% attacks often attributed with Proof of Work consensus, and in being Proof of Work(Monero) ColossusXT is environmentally friendly compared to Proof of Work (Monero). You can generate passive income from Proof of Stake, and Masternodes. Along with helping secure the network.What really sets ColossusXT apart from Monero, and many other privacy projects being worked on right now, is the Colossus Grid. Once plugged into the Colossus Grid, a desktop machine will draw computational horsepower from all the other computers on the grid. Blockchain, was built on the core value of decentralization and ColossusXT adhere to these standards with end-user privacy in mind in the technology sector.
Q: With so many coins out with little to no purpose let alone a definitive use case, how will COLX distinguish itself from the crowd?
A: You are right, there are thousands of other coins. Many have no purpose, and we will see others “pumping” from day to day. It is the nature of markets, and crypto as groups move from coin to coin to make a quick profit. As blockchain regulations and information is made more easily digestible projects like ColossusXT will rise. Our goal is to produce a quality product that will be used globally to solve technical problems, in doing so grid computing on the ColossusXT network could create markets of its own within utilizing Super-computing resources. ColossusXT is more than just a currency, and our steadfast approach to producing technical accomplishments will not go unnoticed.
Q: Tell the crowd something about the I2P integration plan in the roadmap? 🙂
A: ColossusXT will be moving up the I2P network layer in the roadmap to meet a quicker development pace of the Colossus Grid. The I2P layer will serve as an abstraction layer further obfuscating the users of ColossusXT (COLX) nodes. Abstraction layer allows two parties to communicate in an anonymous manner. This network is optimised for anonymous file-sharing.
Q: What kind of protocols, if any, are being considered to prevent or punish misuse of Colossus Grid resources by bad actors, such as participation in a botnet/denial of service attack or the storage of stolen information across the Grid?
A: What defines bad actors? ColossusXT plans on marketing to governments and cyber security companies globally. Entities and individuals who will certainly want their privacy protected. There is a grey area between good and bad, and that is something we can certainly explore as a community. Did you have any ideas to contribute to this evolving variable?What we mean when we say marketing towards security companies and governments is being utilized for some of the projects and innovating new ways of grid computing.
Security: https://wiki.ncsa.illinois.edu/display/cybersec/Projects+and+Software
Governments: https://www.techwalla.com/articles/what-are-the-uses-of-a-supercomputer
Q: The Colossus Grid is well defined but I don't feel easily digestible. Has their been any talk of developing an easier to understand marketing plan to help broaden the investoadoptor base?
A: As we get closer to the release of the Colossus Grid marketing increase for the Colossus Grid. It will have a user friendly UI, and we will provide Guides and FAQ’s with the release that any user intending to share computing power will be able to comprehend.
Q: Can you compare CollossusXT and Golem?
A: Yes. The Colosssus Grid is similar to other grid computing projects. The difference is that ColossusXT is on it’s own blockchain, and does not rely on the speed or congestion of a 3rd party blockchain. The Colossus Grid has a privacy focus and will market to companies, and individuals who would like to be more discreet when buying or selling resources by offering multiple levels of privacy protections.
Q: How do you guys want to achieve to be one of the leaders as a privacy coin?
A: Being a privacy coin leader is not our end game. Privacy features are just a small portion of our framework. The Colossus Grid will include privacy features, but a decentralized Supercomputer is what will set us apart and we intend to be leading this industry in the coming years as our vision, and development continue to grow and scale with technology.
Q: With multiple coins within this space, data storage and privacy, how do you plan to differentiate COLX from the rest? Any further partnerships planned?
A: The Colossus Grid will differentiate ColossusXT from coins within the privacy space. The ColossusXT blockchain will differentiate us from the DATA storage space. Combining these two features with the ability to buy and sell computing power to complete different computational tasks through a decentralized marketplace. We intend to involve more businesses and individuals within the community and will invite many companies to join in connecting the grid to utilize shared resources and reduce energy waste globally when the BETA is available.
Q: Has colossus grid had the best come up out of all crypto coins?
A: Possibly. ColossusXT will continue to “come up” as we approach the launch of the Colossus Grid network.
Q: How far have Colossus gone in the ATM integration
A: ColossusXT intends to and will play an important role in the mass adoption of cryptocurrencies. We already have an ongoing partnership with PolisPay which will enable use of COLX via master debit cards. Along with this established relationship, ColossusXT team is in touch with possible companies to use colx widely where these can only be disclosed upon mutual agreement.
Q: How does COLX intend to disrupt the computing industry through Grid Computing?
A: Using the Colossus Grid on the ColossusXT blockchain, strengthens the network. Computers sit idly by for huge portions of the day. Connecting to the Colossus Grid and contributing those idle resources can make use of all the computing power going to waste, and assist in advancing multiple technology sectors and solving issues. Reducing costs, waste, and increased speed in technology sectors such as scientific research, machine learning, cyber security, and making it possible for anyone with a desktop PC to contribute resources to the Colossus Grid and earn passive income.
Q: What kind of partnerships do you have planned and can you share any of them? :)
A: The ColossusXT team will announce partnerships when they are available. It’s important to finalize all information and create strong avenues of communication between partners ColossusXT works with in the future. We are currently speaking with many different exchanges, merchants, and discussing options within our technology sector for utilizing the Colossus Grid.
Q: Will shared Masternodes be offered by the COLX team? Or will there be any partnerships with something like StakingLab, StakeUnited, or SimplePosPool? StakingLab allows investors of any size to join their shared Masternodes, so any investor of any size can join. Is this a possibility in the future?
A: ColossusXT has already partnered with StakingLab. We also plan to implement shared Masternodes in the desktop wallet.
Q: How innovative is the Colossus Grid in the privacy coin space?
A: Most privacy coins are focused on being just a currency / form of payment. No other project is attempting to do what we are doing with a focus on user privacy.
Q: Hey guys do you think to integrated with some other plataforms like Bancor? I would like it!
A: ColossusXT is in touch with many exchange platforms, however, due to non disclosure agreements details cannot be shared until it is mutually decided with the partners. We will always be looking for new platforms to spread the use of colx in different parts of the world and crypto space.
Q: What is the reward system for the master node owners?
A: From block 388.800 onwards, block reward is 1200 colx and this is split based on masternode ownestaker ratio. This split is based on see-saw algorithm. With an increasing number of masternodes the see-saw algorithm disincentivizes the establishment of even more masternodes because it lowers their profitability. To be precise, as soon as more than 41.5% of the total COLX coin supply is locked in masternodes, more than 50% of the block reward will be distributed to regular staking nodes. As long as the amount of locked collateral funds is below the threshold of 41.5%, the see-saw algorithm ensure that running a masternode is financially more attractive than running a simple staking node, to compensate for the additional effort that a masternode requires in comparison to a simple staking node.Please refer to our whitepaper for more information.
Q: What other marketplaces has the COLX team been in contact with?
Thanks guys! Love the coin and staff
A: ColossusXT gets in touch for different platforms based on community request and also based on partnership requests received upon ColossusXT business team’s mutual agreement. Unfortunately, these possibilities cannot be shared until they are mutually agreed between the partners and ColossusXT team due to non disclosure agreements.
Q: What do you think about the new rules that will soon govern crypto interactions in the EU? they are against anonymous payments
A: Blockchain technology is just now starting to become clear to different governments.
ColossusXT's privacy features protect the end-user from oversharing personal information. As you are probably aware from the multiple emails you've received recently from many websites.
Privacy policies are always being updated and expanded upon. The use of privacy features with utility coins like ColossusXT should be a regular norm throughout blockchain. This movement is part is about decentralization as much as it is about improving technology.
While this news may have a role to play. I don't think it is THE role that will continuously be played as blockchain technology is implemented throughout the world.
Q: Any hints on the next big feature implementation you guys are working on? According to road map - really excited to hear more about the Shared MN and the scale of the marketplace!
A: Current work is focused on the privacy layer of Colossus Grid and completing the updated wallet interface.
Q: Why choose COLX, or should I say why should we believe in COLX becoming what you promise in the roadmap. What are you different from all the other privacy coins with block chain establishment already in effect?
A: ColossusXT is an environmentally friendly Proof of Stake, with Masternode technology that provide dual layers of protection from 51% attacks. It includes privacy features that protect the user while the utilize resources from the Colossus Grid. Some of the previous questions within this AMA may also answer this question.
Q: What tradeoffs do you have using the Colossus Grid versus the more typical distribution?
A: The advantage of supercomputers is that since data can move between processors rapidly, all of the processors can work together on the same tasks. Supercomputers are suited for highly-complex, real-time applications and simulations. However, supercomputers are very expensive to build and maintain, as they consist of a large array of top-of-the-line processors, fast memory, custom hardware, and expensive cooling systems. They also do not scale well, since their complexity makes it difficult to easily add more processors to such a precisely designed and finely tuned system.By contrast, the advantage of distributed systems (Like Colossus Grid) is that relative to supercomputers they are much less expensive. Many distributed systems make use of cheap, off-the-shelf computers for processors and memory, which only require minimal cooling costs. In addition, they are simpler to scale, as adding an additional processor to the system often consists of little more than connecting it to the network. However, unlike supercomputers, which send data short distances via sophisticated and highly optimized connections, distributed systems must move data from processor to processor over slower networks making them unsuitable for many real-time applications.
Q: Why should I choose Colossus instead of another 100,000 altcoins?
A: Many of these alt-coins are all very different projects. ColossusXT is the only Grid computing project with a focus on user privacy. We have instant transactions, and zero-fee transactions and ColossusXT is one of the very few coins to offer live support. Check out our Whitepaper!
Q: Will there be an option (in the future) to choose between an anonymous or public transaction?
A: Zerocoin is an evolution of the current coin mixing feature. Both allow an individual to decide how they would like to send their transactions.
Q: What exchange has highest volume for ColossusXT, and are there any plans for top exchanges soon ?
A: Currently Cryptopia carries the majority of ColossusXT volume. We are speaking with many different exchanges, and preparing requested documentation for different exchanges. ColossusXT intends to be traded on every major exchange globally.
Q: What is the TPS speed that colx blockchain achieves?
A: ColossusXT achieves between 65-67 TPS depending on network conditions currently.
Q: Plans on expanding the dev team?
A: As development funds allow it, the team will be expanded. Development costs are high for a unique product like ColossusXT, and a good majority of our budget is allocated to it.
Q: Can you explain what is and what are the full porpose of the COLOSSUSXT GRID PROJECT ?
A: Colossus Grid is explained in the whitepaper. The uses for grid computing and storage are vast, and we are only starting to scratch the surface on what this type of computing power can do. There is also a description within the formatting context within the AMA of the Colossus Grid.
Q: Is there mobile wallet for Android and iOS? If not, is there a roadmap?
A: There Android wallet is out of beta and on the Google PlayStore: iOS wallet is planned for development.
The roadmap can be found here: https://colossusxt.io/roadmap/
Q: Is ColossusXT planning on partnering up with other cryptocurrency projects? Such as: Bread and EQUAL.
A: ColossusXT plans on partnering with other crypto projects that make sense. We look for projects that can help alleviate some of our development work / provide quality of life upgrades to our investors so that we can focus on Colossus Grid development. When absolutely love it when the community comes to us with great projects to explore.
Q: Did you ever considered a coinburn? Don't you think a coin burn will increase COLX price and sustain mass adoption? Do you plan on keeping the price of COLX in a range so the potential big investors can invest in a not so much volatile project?
A**:** There are no plans to do a coinburn at this time. Please check out our section in the whitepaper about the supply.
Q: what is the next big exchange for colx to be listed ?
A: There are several exchanges that will be listing ColossusXT soon. Stay tuned for updates within the community as some have already been announced and future announcements.
  1. CryptalDash
  2. NextExchange
  3. CoinPulse
  4. CoinSwitch (Crowdfunding)
  5. Plaak (Crowdfunding)
Q: How will Colx compete with other privacy coins which claim to be better like Privacy?
A: ColossusXT is not competing with other privacy coins. ColossusXT will evolve into the Colossus Grid, which is built on the backbone of a privacy blockchain. In our vision, all these other privacy coins are competing for relevancy with ColossusXT. There are also similar responses to question that may hit on specifics.
Q: Does COLX have a finite number of coins like bitcoin?
A: No, ColossusXT is Proof of Stake. https://en.wikipedia.org/wiki/Proof-of-stake
Q: What are the advantages of COLX over other competitor coins (eg. ECA)?
A: The only similarities between ColossusXT and Electra is that we are both privacy blockchains. ColossusXT is very much an entirely different project that any other privacy coin in the blockchain world today. The Colossus Grid will be a huge advantage over any other privacy coin. Offering the ability for a desktop machine to rent power from others contributing to the Colossus Grid and perform and compute high level tasks.
Q: How do you feel about some countries frowning upon privacy coins and how do you plan to change their minds (and what do you plan to do about it?)
A: The ColossusXT team tries to view opinions from multiple perspectives so that we can understand each line of thinking. As blockchain technology becomes more widely adopted, so will the understanding of the importance of the privacy features within ColossusXT. Privacy is freedom.
Q: How do you see COLX in disrupting cloud gaming services such as PlayStation Now?
A: Cloud gaming services have not been discussed. Initial marketing of our private grid computing framework will be targeted at homes users, governments, and cyber security firms who may require more discretion / anonymity in their work.
Q: Since colx is a privacy coin and is known for its privacy in the transactions due to which lot of money laundering and scams could take place, would colx and its community be affected due to it? And if does then how could we try to prevent it?
A: ColossusXT intends to be known for the Colossus Grid. The Colossus Grid development will be moved up from Q1 2019 to Q3 2018 to reflect this message and prevent further miscommunication about what privacy means for the future of ColossusXT. Previous answers within this AMA may further elaborate on this question.
Q: When do you plan to list your coin on other "bigger" exchanges?
A: ColossusXT is speaking with many different exchanges. These things have many different factors. Exchanges decide on listing dates and we expect to see ColossusXT listed on larger exchanges as we approach the Colossus Grid Beta. The governance system can further assist in funding.
Q: What was the rationale behind naming your coin ColossusXT?
A: Colossus was a set of computers developed by British codebreakers in the years 1943–1945. XT symbolises ‘extended’ as the coin was forked from the original Cv2 coin.
Q: Can you give any details about the E Commerce Marketplace, and its progress?
A: The Ecommerce Marketplace is a project that will receive attention after our development pass on important privacy features for the grid. In general, our roadmap will be changing to put an emphasis on grid development.
Q: How will someone access the grid, and how will you monetize using the grid? Will there be an interface that charges COLX for time on the grid or data usage?
A: The Colossus Grid will be integrated within the ColossusXT wallet. Buying & Selling resources will happen within the wallet interface. You won't be able to charge for "time" on the grid, and have access to unlimited resources. The goal is to have users input what resources they need, and the price they are willing to pay. The Colossus Grid will then look for people selling resources at a value the buyer is willing to pay. Time may come into play based on which resources you are specifically asking for.
Q: Are there any plans to launch an official YouTube channel with instructional videos about basic use of the wallets and features of COLX? Most people are visually set and learn much faster about wallets when actually seeing it happen before they try themselves. This might attract people to ColossusXT and also teach people about basic use of blockchain and cryptocurrency wallets. I ask this because I see a lot of users on Discord and Telegram that are still learning and are asking a lot of real basic questions.
A: ColossusXT has an official YT account with instructional videos: https://www.youtube.com/channel/UCCmMLUSK4YoxKvrLoKJnzng
Q: What are the usp's of colx in comparing to other privacy coins?
A: Privacy coins are a dime a dozen. ColossusXT has different end goals than most privacy coins, and this cannot be stated enough. Our goal is not just to be another currency, but to build a sophisticated computing resource sharing architecture on top of the privacy blockchain.
Q: A new exchange will probably gain more liquidity for our coin. If you might choose 3 exchanges to get COLX listed, what would be your top 3?
A: ColossusXT intends to be listed on all major exchanges globally. :)
Q: What is the future of privacy coins? What will be the future colx userbase (beyond the first adopters and enthusiasts)?
A: The future of privacy is the same it has always been. Privacy is something each and everyone person owns, until they give it away to someone else. Who is in control of your privacy? You or another person or entity?The future of the ColossusXT user base will comprise of early adopters, enthusiast, computer science professionals, artificial intelligence, and computational linguistics professionals for which these users can utilize the Colossus Grid a wide range of needs.
Q: Will ColossusXT join more exchanges soon??
A: Yes. :)
Q: So when will Colossus put out lots of advertisement to the various social media sites to get better known? Like Youtube videos etc.
A: As we get closer to a product launch of the Colossus Grid, you’ll begin to see more advertisements, YouTubers, and interviews. We’re looking to also provide some presentations at blockchain conferences in 2018, and 2019.
Q: In your opinion, what are some of the issues holding COLX back from wider adoption? In that vein, what are some of the steps the team is considering to help address those issues?
A: One of the main issues that is holding ColossusXT back from a wider adoption is our endgame is very different from other privacy coins. The Colossus Grid. In order to address this issue, the ColossusXT team intends to have a Colossus Grid Beta out by the end of Q4 and we will move development of the Colossus Grid from Q1 2019 to Q3 2018.
Q: Or to see it from another perspective - what are some of the biggest issues with crypto-currency and how does COLX address those issues?
A: Biggest issue is that cryptocurrency is seen as a means to make quick money, what project is going to get the biggest “pump” of the week, and there is not enough focus on building blockchain technologies that solve problems or creating legitimate business use cases.
For the most part we believe the base of ColossusXT supporters see our end-game, and are willing to provide us with the time and support to complete our vision. The ColossusXT team keeps its head down and keeps pushing forward.
Q: I know it's still early in the development phase but can you give a little insight into what to look forward to regarding In-wallet voting and proposals system for the community? How much power will the community have regarding the direction COLX development takes in the future?
A: The budget and proposal system is detailed in the whitepaper. Masternode owners vote on and guide the development of ColossusXT by voting on proposals put forth by the community and business partners.
Our goal is to make this process as easy and accessible as possible to our community.
Q: Will there be an article explaining the significance of each partnership formed thus far?
A: Yes, the ColossusXT team will announce partners on social media, and community outlets. A detailed article of what partnerships mean will be available on our Medium page: https://medium.com/@colossusxt
Q: What potential output from the Grid is expected and what would it's use be?
For example, x teraflops which could process y solutions to protein folding in z time.
A: There are many uses for grid computing. A crypto enthusiast mining crypto, a cyber security professional cracking a password using brute force, or a scientist producing climate prediction models.
The resources available to put towards grid projects will be determined by the number of nodes sharing resources, and the amount of resources an individual is willing to purchase with COLX.
All individuals will not have access to infinite grid resources.
Q: Is there a paper wallet available?
A: Yes, see https://mycolxwallet.org
Q: Is there a possibility of implementing quantum computer measures in the future?
A: This is a great idea for potentially another project in the future. Currently this is not possible with the Colossus Grid. Instead of bits, which conventional computers use, a quantum computer uses quantum bits—known as qubits. In classical computing, a bit is a single piece of information that can exist in two states – 1 or 0. Quantum computing uses quantum bits, or 'qubits' instead. These are quantum systems with two states. However, unlike a usual bit, they can store much more information than just 1 or 0, because they can exist in any superposition of these values.
Q: Do you plan to do a coin burn?
A: No future coin burns are planned. Anything like this would go through a governance proposal and Masternode owners would vote on this. This is not anything we’ve seen within the community being discussed.
Q: Can I check the exact number of current COLX master node and COLX staking node?
A: Yes. You can view the Masternodes and the amount of ColossusXT (COLX) being staked by viewing the block explorer.
Block explorer: https://chainz.cryptoid.info/colx/#!extraction
Q: What incentive could we give a youtuber to do the BEST video of ColossusXT (COLX)?
A: We've been approached by several YouTubers. The best thing a YouTuber can do is understand what ColossusXT is, join the community, ask questions if there is something they don't understand.
The problem with many YouTubers is that some of them are just trying to get paid, they don't really care to provide context or research a project.
Disclaimer: This is not all YouTubers, but many.
Q: In which ways is the ColossusGrid different from other supercomputer / distributed computing projects out there. Golem comes to mind. Thanks!
A: The main difference is that we are focused on the end users privacy, and the types of users that we will be targeting will be those that need more discretion / anonymity in their work. We are building framework that will continue to push the boundaries of user privacy as it relates to grid computing.
Q: Can we please complete our roadmap ahead of schedule? I find most other coins that do this actually excell in terms of price and community members. Keep on top of the game :)
A: The Colossus XT roadmap is a very fluid document, and it is always evolving. Some items are moved up in priority, and others are moved back. The roadmap should not be thought of something that is set in stone.
Q: Does COLX have master nodes?
A: Yes. ColossusXT has masternodes.
Q: Have thought about providing a method to insert a form of payment in colx in any page that wants to use cryptocurrencies in a fast and simple way in order to masive adoption????
A: There is already this option.https://mycryptocheckout.com/coins/
Q: What do you think your community progress till now?
A: The community has grown greatly in the last 3 months. We’re very excited to go from 13 to 100 questions in our quarterly AMA. Discord, Telegram, and Twitter are growing everyday.
Q: I noticed on Roadmap: Coinomi and ahapeshift wallet integration. Can you tell me more about this? I am new in crypto and new ColX investor so I don't know much about this. Thanks and keep a good work.
A: Coinomi is a universal wallet. ColossusXT will have multiple wallet platforms available to it. Shapeshift allows you to switch one crypto directly for another without the use of a coupler (BTC).
Q: Is "A general-purpose decentralized marketplace" written in the whitepaper the same as "E-COMMERCE MARKETPLACE" written on the roadmap?
Please tell me about "A general-purpose decentralized marketplace" or "E-COMMERCE MARKETPLACE" in detail.
A: Details will be posted as we get closer to the marketplace. It will be similar to other marketplaces within blockchain. Stay tuned for more information by following us on Twitter.
Q: History has shown that feature-based technologies always get replaced by technologies with platforms that incorporate those features; what is colossius big picture?
A: The Colossus Grid. Which has been explained within this AMA in a few different ways.
Q: What are the main objectives for COLX team this year? Provide me 5 reason why COLX will survive in a long term perspective? Do you consider masternodes working in a private easy to setup wallet on a DEX network? Already big fan, have a nice day!
A: Getting into Q3 our main object is to get a working product of the Colossus Grid by the end of Q4.
  1. Community - Our community is growing everyday as knowledge about what we’re building grows. When the Colossus Grid is online we expect expansion to grow at a rapid pace as users connect to share resources.
  2. Team - The ColossusXT team will continue to grow. We are stewards of a great community and an amazing project. Providing a level of support currently unseen in many other projects through Discord. The team cohesion and activity within the community is a standard we intend to set within the blockchain communities.
  3. Features - ColossusXT and The Colossus Grid will have user friendly AI. We understand the difficulties when users first enter blockchain products. The confusion between keys, sending/receiving addresses, and understanding available features within. Guides will always be published for Windows/Mac/Linux with updates so that these features can be easily understood.
  4. Colossus Grid - The Colossus Grid answers real world problems, and provides multiple solutions while also reducing energy consumption.
  5. Use Case - Many of the 1000+ other coins on the market don’t have the current use-case that ColossusXT has, let alone the expansion of utility use-cases in multiple sectors.
Q: Will the whitepaper be available in Portuguese?
A: Yes. We will be adding some language bounties to the website in the future. Stay tuned.
Q: Notice in your white paper there are future plans for decentralised governance and masternode voting. While all that is great, how do you plan on mitigating malicious proposals from getting through by gaming the system (i.e. bot votes, multiple accounts, spam,etc)?
A: You cannot game the system. Masternode owners get 1 vote.
Q: Been a massive fan of this project since Dec last year, anyways what was the reason you guys thought of putting XT at the end of Colossus. :)
A: XT symbolizes ‘extended’ as the coin was forked from the original Cv2 coin.
Q: Do you plan a partnership within the banking industry to capitalize on such large amounts of money being moved continuously?
A: The focus will be on the Colossus Grid and Grid computing, with the option to participate in the financial sector of Blockchain through Polis Pay, and other partnerships that can be announced in the future.
Q: When will be COLX supported By The Ledger Wallet?
A: Integration with cold storage wallet is planned. I myself (PioyPioyPioy) have a Nano Ledger S and I love it!
Q: Where do you see yourself in five years?
A: The goal 5 years from now would be to be a leading competitor in cloud computing and storage. Providing government, private cybersecurity, and individuals with efficient solutions to Super-computing, cloud storage through Blockchain infrastructure. I would like to see hardware options of connecting to the grid to utilize resources after the Colossus Grid is online, and I think this can contribute to many use-case scenarios.
Q: How can I suggest business partnerships and strategic ideas etc to the ColossusXT team?
A: Join us in Discord. Members of the team here are active daily, you can also contact us at: [[email protected]](mailto:[email protected])
Q: A great project requires good funding. How do you plan to incorporate fund sourcing and management into the long-term planning of this project
A: Check out our governance section within the whitepaper. :)
Website: https://colossusxt.io
Whitepaper: https://colossuscoinxt.org/whitepape
Roadmap: https://colossuscoinxt.org/roadmap/
Follow ColossusXT on:
Twitter: https://twitter.com/colossuscoinxt
Facebook Page: https://www.facebook.com/ColossusCoin/
Telegram: https://web.telegram.org/#/im?p=s1245563208_12241980906364004453
Discord: https://discord.gg/WrnAPcx
Apply to join the team: https://docs.google.com/forms/d/1YcOoY6nyCZ6aggJNyMU-Y5me8_gLTHkuDY4SrQPRe-4/viewform?edit_requested=true
Contribute an idea: https://colossusxt.fider.io/
Q2 AMA Questions: https://www.reddit.com/ColossuscoinX/comments/8ppkxf/official_colossusxt_ama_q2/
Previous AMA: https://www.reddit.com/ColossuscoinX/comments/8bia7o/official_colossusxt_ama/
submitted by PioyPioyPioy to ColossuscoinX [link] [comments]

The Astounding Incompetence, Negligence, and Dishonesty of the Bitcoin Unlimited Developers

On August 26, 2016 someone noticed that their Classic node had been forked off of the "Big Blocks Testnet" that Bitcoin Classic and Bitcoin Unlimited were running. Neither implementation was testing their consensus code on any other testnets; this was effectively the only testnet being used to test either codebase. The issue was due to a block on the testnet that was mined on July 30, almost a full month prior to anyone noticing the fork at all, which was in violation of the BIP109 specification that Classic miners were purportedly adhering to at the time. Gregory Maxwell observed:
That was a month ago, but it's only being noticed now. I guess this is demonstrating that you are releasing Bitcoin Classic without much testing and that almost no one else is either? :-/
The transaction in question doesn't look at all unusual, other than being large. It was, incidentally, mined by pool.bitcoin.com, which was signaling support for BIP109 in the same block it mined that BIP 109 violating transaction.
Later that day, Maxwell asked Roger Ver to clarify whether he was actually running Bitcoin Classic on the bitcoin.com mining pool, who dodged the question and responded with a vacuous reply that attempted to inexplicably change the subject to "censorship" instead.
Andrew Stone (the lead developer of Bitcoin Unlimited) voiced confusion about BIP109 and how Bitcoin Unlimited violated the specification for it (while falsely signaling support for it). He later argued that Bitcoin Unlimited didn't need to bother adhering to specifications that it signaled support for, and that doing so would violate the philosophy of the implementation. Peter Rizun shared this view. Neither developer was able to answer Maxwell's direct question about the violation of BIP109 §4/5, which had resulted in the consensus divergence (fork).
Despite Maxwell having provided a direct link to the transaction violating BIP109 that caused the chain split, and explaining in detail what the results of this were, later Andrew Stone said:
I haven't even bothered to find out the exact cause. We have had BUIP016 passed to adhere to strict BIP109 compatibility (at least in what we generate) by merging Classic code, but BIP109 is DOA -- so no-one bothered to do it.
I think that the only value to be had from this episode is to realise that consensus rules should be kept to an absolute, money-function-protecting minimum. If this was on mainnet, I'll be the Classic users would be unhappy to be forked onto a minority branch because of some arbitrary limit that is yet another thing would have needed to be fought over as machine performance improves but the limit stays the same.
Incredibly, when a confused user expressed disbelief regarding the fork, Andrew Stone responded:
Really? There was no classic fork? As i said i didnt bother to investigate. Can you give me a link to more info? Its important to combat this fud.
Of course, the proof of the fork (and the BIP109-violating block/transaction) had already been provided to Stone by Maxwell. Andrew Stone was willing to believe that the entire fork was imaginary, in the face of verifiable proof of the incident. He admits that he didn't investigate the subject at all, even though that was the only testnet that Unlimited could have possibly been performing any meaningful tests on at the time, and even though this fork forced Classic to abandon BIP109 entirely, leaving it vulnerable to the types of attacks that Gavin Andresen described in his Guided Tour of the 2mb Fork:
“Accurate sigop/sighash accounting and limits” is important, because without it, increasing the block size limit might be dangerous... It is set to 1.3 gigabytes, which is big enough so none of the blocks currently in the block chain would hit it, but small enough to make it impossible to create poison blocks that take minutes to validate.
As a result of this fork (which Stone was clueless enough to doubt had even happened), Bitcoin Classic and Bitcoin Unlimited were both left vulnerable to such attacks. Fascinatingly, this fact did not seem to bother the developers of Bitcoin Unlimited at all.
On November 17, 2016 Andrew Stone decided to post an article titled A Short Tour of Bitcoin Core wherein he claimed:
Bitcoin Unlimited is building the highest quality, most stable, Bitcoin client available. We have a strong commitment to quality and testing as you will see in the rest of this document.
The irony of this claim should soon become very apparent.
In the rest of the article, Stone wrote with venomous and overtly hostile rhetoric:
As we mine the garbage in the Bitcoin Core code together... I want you to realise that these issues are systemic to Core
He went on to describe what he believed to be multiple bugs that had gone unnoticed by the Core developers, and concluded his article with the following paragraph:
I hope when reading these issues, you will realise that the Bitcoin Unlimited team might actually be the most careful committers and testers, with a very broad and dedicated test infrastructure. And I hope that you will see these Bitcoin Core commits— bugs that are not tricky and esoteric, but simple issues that well known to average software engineers —and commits of “Very Ugly Hack” code that do not reflect the care required for an important financial network. I hope that you will realise that, contrary to statements from Adam Back and others, the Core team does not have unique skills and abilities that qualify them to administer this network.
As soon as the article was published, it was immediately and thoroughly debunked. The "bugs" didn't exist in the current Core codebase; some were results of how Andrew had "mucked with wallet code enough to break" it, and "many of issues were actually caused by changes they made to code they didn't understand", or had been fixed years ago in Core, and thus only affected obsolete clients (ironically including Bitcoin Unlimited itself).
As Gregory Maxwell said:
Perhaps the biggest and most concerning danger here isn't that they don't know what they're doing-- but that they don't know what they don't know... to the point where this is their best attempt at criticism.
Amusingly enough, in the "Let's Lose Some Money" section of the article, Stone disparages an unnamed developer for leaving poor comments in a portion of the code, unwittingly making fun of Satoshi himself in the process.
To summarize: Stone set out to criticize the Core developer team, and in the process revealed that he did not understand the codebase he was working on, had in fact personally introduced the majority of the bugs that he was criticizing, and was actually completely unable to identify any bugs that existed in current versions Core. Worst of all, even after receiving feedback on his article, he did not appear to comprehend (much less appreciate) any of these facts.
On January 27, 2017, Bitcoin Unlimited excitedly released v1.0 of their software, announcing:
The third official BU client release reflects our opinion that Bitcoin full-node software has reached a milestone of functionality, stability and scalability. Hence, completion of the alpha/beta phase throughout 2009-16 can be marked in our release version.
A mere 2 days later, on January 29, their code accidentally attempted to hard-fork the network. Despite there being a very clear and straightforward comment in Bitcoin Core explaining the space reservation for coinbase transactions in the code, Bitcoin Unlimited obliviously merged a bug into their client which resulted in an invalid block (23 bytes larger than 1MB) being mined by Roger Ver's Bitcoin.com mining pool on January 29, 2017, costing the pool a minimum of 13.2 bitcoins. A large portion of Bitcoin Unlimited nodes and miners (which naively accepted this block as valid) were temporarily banned from the network as a result, as well.
The code change in question revealed that the Bitcoin Unlimited developers were not only "commenting out and replacing code without understanding what it's for" as well as bypassing multiple safety-checks that should have prevented such issues from occurring, but that they were not performing any peer review or testing whatsoever of many of the code changes they were making. This particular bug was pushed directly to the master branch of Bitcoin Unlimited (by Andrew Stone), without any associated pull requests to handle the merge or any reviewers involved to double-check the update. This once again exposed the unprofessionalism and negligence of the development team and process of Bitcoin Unlimited, and in this case, irrefutably had a negative effect in the real world by costing Bitcoin.com thousands of dollars worth of coins.
In effect, this was the first public mainnet fork attempt by Bitcoin Unlimited. Unsurprisingly, the attempt failed, costing the would-be forkers real bitcoins as a result. It is possible that the costs of this bug are much larger than the lost rewards and fees from this block alone, as other Bitcoin Unlimited miners may have been expending hash power in the effort to mine slightly-oversized (invalid) blocks prior to this incident, inadvertently wasting resources in the doomed pursuit of invalid coins.
On March 14, 2017, a remote exploit vulnerability discovered in Bitcoin Unlimited crashed 75% of the BU nodes on the network in a matter of minutes.
In order to downplay the incident, Andrew Stone rapidly published an article which attempted to imply that the remote-exploit bug also affected Core nodes by claiming that:
approximately 5% of the “Satoshi” Bitcoin clients (Core, Unlimited, XT) temporarily dropped off of the network
In reddit comments, he lied even more explicitly, describing it as "a bug whose effects you can see as approximate 5% drop in Core node counts" as well as a "network-wide Bitcoin client failure". He went so far as to claim:
the Bitcoin Unlimited team found the issue, identified it as an attack and fixed the problem before the Core team chose to ignore it
The vulnerability in question was in thinblock.cpp, which has never been part of Bitcoin Core; in other words, this vulnerability only affected Bitcoin Classic and Bitcoin Unlimited nodes.
In the same Medium article, Andrew Stone appears to have doctored images to further deceive readers. In the reddit thread discussing this deception, Andrew Stone denied that he had maliciously edited the images in question, but when questioned in-depth on the subject, he resorted to citing his own doctored images as sources and refused to respond to further requests for clarification or replication steps.
Beyond that, the same incident report (and images) conspicuously omitted the fact that the alleged "5% drop" on the screenshotted (and photoshopped) node-graph was actually due to the node crawler having been rebooted, rather than any problems with Core nodes. This fact was plainly displayed on the 21 website that the graph originated from, but no mention of it was made in Stone's article or report, even after he was made aware of it and asked to revise or retract his deceptive statements.
There were actually 3 (fundamentally identical) Xthin-assert exploits that Unlimited developers unwittingly publicized during this episode, which caused problems for Bitcoin Classic, which was also vulnerable.
On top of all of the above, the vulnerable code in question had gone unnoticed for 10 months, and despite the Unlimited developers (including Andrew Stone) claiming to have (eventually) discovered the bug themselves, it later came out that this was another lie; an external security researcher had actually discovered it and disclosed it privately to them. This researcher provided the following quotes regarding Bitcoin Unlimited:
I am quite beside myself at how a project that aims to power a $20 billion network can make beginner’s mistakes like this.
I am rather dismayed at the poor level of code quality in Bitcoin Unlimited and I suspect there [is] a raft of other issues
The problem is, the bugs are so glaringly obvious that when fixing it, it will be easy to notice for anyone watching their development process,
it doesn’t help if the software project is not discreet about fixing critical issues like this.
In this case, the vulnerabilities are so glaringly obvious, it is clear no one has audited their code because these stick out like a sore thumb
In what appeared to be a desperate attempt to distract from the fundamental ineptitude that this vulnerability exposed, Bitcoin Unlimited supporters (including Andrew Stone himself) attempted to change the focus to a tweet that Peter Todd made about the vulnerability, blaming him for exposing it and prompting attackers to exploit it... but other Unlimited developers revealed that the attacks had actually begun well before Todd had tweeted about the vulnerability. This was pointed out many times, even by Todd himself, but Stone ignored these facts a week later, and shamelessly lied about the timeline in a propagandistic effort at distraction and misdirection.
submitted by sound8bits to Bitcoin [link] [comments]

The Astounding Incompetence, Negligence, and Dishonesty of the Bitcoin Unlimited Developers

On August 26, 2016 someone noticed that their Classic node had been forked off of the "Big Blocks Testnet" that Bitcoin Classic and Bitcoin Unlimited were running. Neither implementation was testing their consensus code on any other testnets; this was effectively the only testnet being used to test either codebase. The issue was due to a block on the testnet that was mined on July 30, almost a full month prior to anyone noticing the fork at all, which was in violation of the BIP109 specification that Classic miners were purportedly adhering to at the time. Gregory Maxwell observed:
That was a month ago, but it's only being noticed now. I guess this is demonstrating that you are releasing Bitcoin Classic without much testing and that almost no one else is either? :-/
The transaction in question doesn't look at all unusual, other than being large. It was, incidentally, mined by pool.bitcoin.com, which was signaling support for BIP109 in the same block it mined that BIP 109 violating transaction.
Later that day, Maxwell asked Roger Ver to clarify whether he was actually running Bitcoin Classic on the bitcoin.com mining pool, who dodged the question and responded with a vacuous reply that attempted to inexplicably change the subject to "censorship" instead.
Andrew Stone voiced confusion about BIP109 and how Bitcoin Unlimited violated the specification for it (while falsely signaling support for it). He later argued that Bitcoin Unlimited didn't need to bother adhering to specifications that it signaled support for, and that doing so would violate the philosophy of the implementation. Peter Rizun shared this view. Neither developer was able to answer Maxwell's direct question about the violation of BIP109 §4/5, which had resulted in the consensus divergence (fork).
Despite Maxwell having provided a direct link to the transaction violating BIP109 that caused the chain split, and explaining in detail what the results of this were, later Andrew Stone said:
I haven't even bothered to find out the exact cause. We have had BUIP016 passed to adhere to strict BIP109 compatibility (at least in what we generate) by merging Classic code, but BIP109 is DOA -- so no-one bothered to do it.
I think that the only value to be had from this episode is to realise that consensus rules should be kept to an absolute, money-function-protecting minimum. If this was on mainnet, I'll be the Classic users would be unhappy to be forked onto a minority branch because of some arbitrary limit that is yet another thing would have needed to be fought over as machine performance improves but the limit stays the same.
Incredibly, when a confused user expressed disbelief regarding the fork, Andrew Stone responded:
Really? There was no classic fork? As i said i didnt bother to investigate. Can you give me a link to more info? Its important to combat this fud.
Of course, the proof of the fork (and the BIP109-violating block/transaction) had already been provided to Stone by Maxwell. Andrew Stone was willing to believe that the entire fork was imaginary, in the face of verifiable proof of the incident. He admits that he didn't investigate the subject at all, even though that was the only testnet that Unlimited could have possibly been performing any meaningful tests on at the time, and even though this fork forced Classic to abandon BIP109 entirely, leaving it vulnerable to the types of attacks that Gavin Andresen described in his Guided Tour of the 2mb Fork:
“Accurate sigop/sighash accounting and limits” is important, because without it, increasing the block size limit might be dangerous... It is set to 1.3 gigabytes, which is big enough so none of the blocks currently in the block chain would hit it, but small enough to make it impossible to create poison blocks that take minutes to validate.
As a result of this fork (which Stone was clueless enough to doubt had even happened), Bitcoin Classic and Bitcoin Unlimited were both left vulnerable to such attacks. Fascinatingly, this fact did not seem to bother the developers of Bitcoin Unlimited at all.
On November 17, 2016 Andrew Stone decided to post an article titled A Short Tour of Bitcoin Core wherein he claimed:
Bitcoin Unlimited is building the highest quality, most stable, Bitcoin client available. We have a strong commitment to quality and testing as you will see in the rest of this document.
The irony of this claim should soon become very apparent.
In the rest of the article, Stone wrote with venomous and overtly hostile rhetoric:
As we mine the garbage in the Bitcoin Core code together... I want you to realise that these issues are systemic to Core
He went on to describe what he believed to be multiple bugs that had gone unnoticed by the Core developers, and concluded his article with the following paragraph:
I hope when reading these issues, you will realise that the Bitcoin Unlimited team might actually be the most careful committers and testers, with a very broad and dedicated test infrastructure. And I hope that you will see these Bitcoin Core commits— bugs that are not tricky and esoteric, but simple issues that well known to average software engineers —and commits of “Very Ugly Hack” code that do not reflect the care required for an important financial network. I hope that you will realise that, contrary to statements from Adam Back and others, the Core team does not have unique skills and abilities that qualify them to administer this network.
As soon as the article was published, it was immediately and thoroughly debunked. The "bugs" didn't exist in the current Core codebase; some were results of how Andrew had "mucked with wallet code enough to break" it, and "many of issues were actually caused by changes they made to code they didn't understand", or had been fixed years ago in Core, and thus only affected obsolete clients (ironically including Bitcoin Unlimited itself).
As Gregory Maxwell said:
Perhaps the biggest and most concerning danger here isn't that they don't know what they're doing-- but that they don't know what they don't know... to the point where this is their best attempt at criticism.
Amusingly enough, in the "Let's Lose Some Money" section of the article, Stone disparages an unnamed developer for leaving poor comments in a portion of the code, unwittingly making fun of Satoshi himself in the process.
To summarize: Stone set out to criticize the Core developer team, and in the process revealed that he did not understand the codebase he was working on, had in fact personally introduced the majority of the bugs that he was criticizing, and was actually completely unable to identify any bugs that existed in current versions Core. Worst of all, even after receiving feedback on his article, he did not appear to comprehend (much less appreciate) any of these facts.
On January 27, 2017, Bitcoin Unlimited excitedly released v1.0 of their software, announcing:
The third official BU client release reflects our opinion that Bitcoin full-node software has reached a milestone of functionality, stability and scalability. Hence, completion of the alpha/beta phase throughout 2009-16 can be marked in our release version.
A mere 2 days later, on January 29, their code accidentally attempted to hard-fork the network. Despite there being a very clear and straightforward comment in Bitcoin Core explaining the space reservation for coinbase transactions in the code, Bitcoin Unlimited obliviously merged a bug into their client which resulted in an invalid block (23 bytes larger than 1MB) being mined by Roger Ver's Bitcoin.com mining pool on January 29, 2017, costing the pool a minimum of 13.2 bitcoins. A large portion of Bitcoin Unlimited nodes and miners (which naively accepted this block as valid) were temporarily banned from the network as a result, as well.
The code change in question revealed that the Bitcoin Unlimited developers were not only "commenting out and replacing code without understanding what it's for" as well as bypassing multiple safety-checks that should have prevented such issues from occurring, but that they were not performing any peer review or testing whatsoever of many of the code changes they were making. This particular bug was pushed directly to the master branch of Bitcoin Unlimited (by Andrew Stone), without any associated pull requests to handle the merge or any reviewers involved to double-check the update. This once again exposed the unprofessionalism and negligence of the development team and process of Bitcoin Unlimited, and in this case, irrefutably had a negative effect in the real world by costing Bitcoin.com thousands of dollars worth of coins.
In effect, this was the first public mainnet fork attempt by Bitcoin Unlimited. Unsurprisingly, the attempt failed, costing the would-be forkers real bitcoins as a result. It is possible that the costs of this bug are much larger than the lost rewards and fees from this block alone, as other Bitcoin Unlimited miners may have been expending hash power in the effort to mine slightly-oversized (invalid) blocks prior to this incident, inadvertently wasting resources in the doomed pursuit of invalid coins.
On March 14, 2017, a remote exploit vulnerability discovered in Bitcoin Unlimited crashed 75% of the BU nodes on the network in a matter of minutes.
In order to downplay the incident, Andrew Stone rapidly published an article which attempted to imply that the remote-exploit bug also affected Core nodes by claiming that:
approximately 5% of the “Satoshi” Bitcoin clients (Core, Unlimited, XT) temporarily dropped off of the network
In reddit comments, he lied even more explicitly, describing it as "a bug whose effects you can see as approximate 5% drop in Core node counts" as well as a "network-wide Bitcoin client failure". He went so far as to claim:
the Bitcoin Unlimited team found the issue, identified it as an attack and fixed the problem before the Core team chose to ignore it
The vulnerability in question was in thinblock.cpp, which has never been part of Bitcoin Core; in other words, this vulnerability only affected Bitcoin Classic and Bitcoin Unlimited nodes.
In the same Medium article, Andrew Stone appears to have doctored images to further deceive readers. In the reddit thread discussing this deception, Andrew Stone denied that he had maliciously edited the images in question, but when questioned in-depth on the subject, he resorted to citing his own doctored images as sources and refused to respond to further requests for clarification or replication steps.
Beyond that, the same incident report (and images) conspicuously omitted the fact that the alleged "5% drop" on the screenshotted (and photoshopped) node-graph was actually due to the node crawler having been rebooted, rather than any problems with Core nodes. This fact was plainly displayed on the 21 website that the graph originated from, but no mention of it was made in Stone's article or report, even after he was made aware of it and asked to revise or retract his deceptive statements.
There were actually 3 (fundamentally identical) Xthin-assert exploits that Unlimited developers unwittingly publicized during this episode, which caused problems for Bitcoin Classic, which was also vulnerable.
On top of all of the above, the vulnerable code in question had gone unnoticed for 10 months, and despite the Unlimited developers (including Andrew Stone) claiming to have (eventually) discovered the bug themselves, it later came out that this was another lie; an external security researcher had actually discovered it and disclosed it privately to them. This researcher provided the following quotes regarding Bitcoin Unlimited:
I am quite beside myself at how a project that aims to power a $20 billion network can make beginner’s mistakes like this.
I am rather dismayed at the poor level of code quality in Bitcoin Unlimited and I suspect there [is] a raft of other issues
The problem is, the bugs are so glaringly obvious that when fixing it, it will be easy to notice for anyone watching their development process,
it doesn’t help if the software project is not discreet about fixing critical issues like this.
In this case, the vulnerabilities are so glaringly obvious, it is clear no one has audited their code because these stick out like a sore thumb
In what appeared to be a desperate attempt to distract from the fundamental ineptitude that this vulnerability exposed, Bitcoin Unlimited supporters (including Andrew Stone himself) attempted to change the focus to a tweet that Peter Todd made about the vulnerability, blaming him for exposing it and prompting attackers to exploit it... but other Unlimited developers revealed that the attacks had actually begun well before Todd had tweeted about the vulnerability. This was pointed out many times, even by Todd himself, but Stone ignored these facts a week later, and shamelessly lied about the timeline in a propagandistic effort at distraction and misdirection.
submitted by sound8bits to sound8bits [link] [comments]

Hard Fork Framework

Hard Fork Framework (HFF)
Instead of trying to avoid hard forks at all costs, perhaps we should create a well defined, versioned, framework to embrace hard forks. The framework would provide a relatively easy way to allow anyone to run their own consensus rules. Perhaps this could be done via plugin system?
When a fork occurs, the block-hash (or perhaps some other algorithm, because the block-hash loses entropy as the difficulty increases. Perhaps the hash should be transaction based so that multiple forks could be created per block) of the first block will become its reference "fork-hash". The new fork can then be "named" and referenced as "bitcoin-deadbeef...". The creators of the fork might give their fork a pseudonym such as "Bitcoin Super Duper XT 1000", but this does not need to be handled by the framework. Only the fork-hash is important.
Just like transactions, it would be recommended to wait for the new fork's chain to become at least a certain length before trusting the fork-hash. The number of blocks to wait would depend on the consensus rules of the new fork. (If the new fork changed the average block rate to 30 seconds, you would want to wait for many more blocks to confirm than for a fork with an average block rate of 10 minutes).
Replay attacks could be mitigated by requiring that the fork-hash be included in the transaction (not sure how this might affect the size of the transaction, perhaps there is a clever way to do this?). This would ensure that transactions would only be valid on their respective forks. Or whatever replay prevention technique is deemed fit.
Why would we want this?
  1. Mitigate consensus change / social / stalling attacks. If a re-branded "Bitcoin Super Duper XT 1000" comes along wanting to change the consensus rules to something controversial, the response is simple: "Create a HFF module". The discussion ends there.
  2. The HFF will allow wallets, exchanges and businesses to easily accept new hard forks if they want to. They would simply download the HFF plugin module and tell bitcoind to include/run it. The HFF would provide a well defined API for interacting with forks, so the user's software may not require any changes. (Some forks may require custom API commands, in which case the client software would need to be changed, but that is up to the maintainers of the fork. It is in their best interest to make their fork as compatible as possible)
  3. If there are valid HFF changes that fork X needs, this should be far less controversial as long as it does not inhibit the other forks from functioning normally. Making sure HFF is properly versioned should allow for future innovation while keeping support for existing forks.
  4. Empower users by providing them with an economic way to support their preferred chain. Each exchange will make the decision whether or not to support a new fork. There may end up being hundreds or even thousands of forks so it would only make sense for the exchanges to support the most common. Once an exchange enables support for a particular fork (One of the goals of HFF is to make this easy), users will be able to either sell or buy the new coin. Let the market decide.
  5. Keep miners in line. If miners misbehave, it would be trivial to create a new fork using a new POW algorithm. If there truly is an economic majority opposed to the miners' behaviour, then the misbehaving miners may find themselves mining an economic minority chain. This should be a constant reminder for them that they are not in charge.
  6. Segwit + LN enabled forks may become easily exchangeable. So if a particular merchant has not yet enabled "bitcoin-deadbeef", an intelligent wallet could convert to "bitcoin-3d7ae587" on-the-fly to make the payment.
  7. Creating a fork becomes more like creating a linux distro or any other open source software. The best survive. The weak die. Survival of the fittest.
How is this different from an altcoin?
  1. History is preserved. You will have the same number of coins on each chain. No, this is not inflation because the value of the new coin at the time of the fork is zero. An exchange rate would need to emerge naturally. Preserving the history is important because it allows existing stake holders to vote economically by buying or selling the new coin.
  2. Choosing to support an altcoin takes time and effort. The goal of HFF is to allow businesses, exchanges and users to enable support as easily as possible. E.g "bitcoind -consensus libbitcoinsuperduperxt1000". Or "bitcoind -consensus libpowkeccak" etc.
  3. Most of the code remains the same for all forks. Only the consensus code differs from fork to fork.
Could a HFF plugin expose a security vulnerability which puts other running forks at risk?
This would obviously need to be addressed in the design. Perhaps each fork would run in its own process? Or its own container? Or even its own machine if the user chooses. The goal would be to sufficiently sandbox each fork from each other. Each user should assess the competency of the dev team (Or the actual code if possible) behind the fork before they run it.
Wont multiple forks confuse people?
This will need to be addressed through education. People will call each fork by their friendly name. However, each fork should be referenced using its fork-hash when appropriate. It is likely that only a small handful of forks will have any meaningful relevance.
Is this even possible?
Maybe not. Hopefully the devs can discuss it. (Or even immediately dismiss)
What is the time frame for such a feature?
This would likely take several years to design and implement. It would be a long term goal.
submitted by hff-btc to Bitcoin [link] [comments]

Bitcoin Core 0.11.0 released | Wladimir J. van der Laan | Jul 12 2015

Wladimir J. van der Laan on Jul 12 2015:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Bitcoin Core version 0.11.0 is now available from:
<https://bitcoin.org/bin/bitcoin-core-0.11.0/>
This is a new major version release, bringing both new features and
bug fixes.
Please report bugs using the issue tracker at github:
<https://github.com/bitcoin/bitcoin/issues>
The entire distribution is also available as torrent:
magnet:?xt=urn:btih:82f0d2fa100d6db8a8c1338768dcb9e4e524da13&dn;=bitcoin-core-0.11.0&tr;=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr;=udp%3A%2F%2Fopen.demonii.com%3A1337&ws;=https%3A%2F%2Fbitcoin.org%2Fbin%2F 
Upgrading and downgrading

How to Upgrade
If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or
bitcoind/bitcoin-qt (on Linux).
Downgrade warning
Because release 0.10.0 and later makes use of headers-first synchronization and
parallel block download (see further), the block files and databases are not
backwards-compatible with pre-0.10 versions of Bitcoin Core or other software:
  • Blocks will be stored on disk out of order (in the order they are
received, really), which makes it incompatible with some tools or
other programs. Reindexing using earlier versions will also not work
anymore as a result of this.
  • The block index database will now hold headers for which no block is
stored on disk, which earlier versions won't support.
If you want to be able to downgrade smoothly, make a backup of your entire data
directory. Without this your node will need start syncing (or importing from
bootstrap.dat) anew afterwards. It is possible that the data from a completely
synchronised 0.10 node may be usable in older versions as-is, but this is not
supported and may break as soon as the older version attempts to reindex.
This does not affect wallet forward or backward compatibility. There are no
known problems when downgrading from 0.11.x to 0.10.x.
Important information

Transaction flooding
At the time of this release, the P2P network is being flooded with low-fee
transactions. This causes a ballooning of the mempool size.
If this growth of the mempool causes problematic memory use on your node, it is
possible to change a few configuration options to work around this. The growth
of the mempool can be monitored with the RPC command getmempoolinfo.
One is to increase the minimum transaction relay fee minrelaytxfee, which
defaults to 0.00001. This will cause transactions with fewer BTC/kB fee to be
rejected, and thus fewer transactions entering the mempool.
The other is to restrict the relaying of free transactions with
limitfreerelay. This option sets the number of kB/minute at which
free transactions (with enough priority) will be accepted. It defaults to 15.
Reducing this number reduces the speed at which the mempool can grow due
to free transactions.
For example, add the following to bitcoin.conf:
minrelaytxfee=0.00005 limitfreerelay=5 
More robust solutions are being worked on for a follow-up release.
Notable changes

Block file pruning
This release supports running a fully validating node without maintaining a copy
of the raw block and undo data on disk. To recap, there are four types of data
related to the blockchain in the bitcoin system: the raw blocks as received over
the network (blk???.dat), the undo data (rev???.dat), the block index and the
UTXO set (both LevelDB databases). The databases are built from the raw data.
Block pruning allows Bitcoin Core to delete the raw block and undo data once
it's been validated and used to build the databases. At that point, the raw data
is used only to relay blocks to other nodes, to handle reorganizations, to look
up old transactions (if -txindex is enabled or via the RPC/REST interfaces), or
for rescanning the wallet. The block index continues to hold the metadata about
all blocks in the blockchain.
The user specifies how much space to allot for block & undo files. The minimum
allowed is 550MB. Note that this is in addition to whatever is required for the
block index and UTXO databases. The minimum was chosen so that Bitcoin Core will
be able to maintain at least 288 blocks on disk (two days worth of blocks at 10
minutes per block). In rare instances it is possible that the amount of space
used will exceed the pruning target in order to keep the required last 288
blocks on disk.
Block pruning works during initial sync in the same way as during steady state,
by deleting block files "as you go" whenever disk space is allocated. Thus, if
the user specifies 550MB, once that level is reached the program will begin
deleting the oldest block and undo files, while continuing to download the
blockchain.
For now, block pruning disables block relay. In the future, nodes with block
pruning will at a minimum relay "new" blocks, meaning blocks that extend their
active chain.
Block pruning is currently incompatible with running a wallet due to the fact
that block data is used for rescanning the wallet and importing keys or
addresses (which require a rescan.) However, running the wallet with block
pruning will be supported in the near future, subject to those limitations.
Block pruning is also incompatible with -txindex and will automatically disable
it.
Once you have pruned blocks, going back to unpruned state requires
re-downloading the entire blockchain. To do this, re-start the node with
  • -reindex. Note also that any problem that would cause a user to reindex (e.g.,
disk corruption) will cause a pruned node to redownload the entire blockchain.
Finally, note that when a pruned node reindexes, it will delete any blk???.dat
and rev???.dat files in the data directory prior to restarting the download.
To enable block pruning on the command line:
  • - -prune=N: where N is the number of MB to allot for raw block & undo data.
Modified RPC calls:
    • getblockchaininfo now includes whether we are in pruned mode or not.
    • getblock will check if the block's data has been pruned and if so, return an
error.
  • - getrawtransaction will no longer be able to locate a transaction that has a
UTXO but where its block file has been pruned.
Pruning is disabled by default.
Big endian support
Experimental support for big-endian CPU architectures was added in this
release. All little-endian specific code was replaced with endian-neutral
constructs. This has been tested on at least MIPS and PPC hosts. The build
system will automatically detect the endianness of the target.
Memory usage optimization
There have been many changes in this release to reduce the default memory usage
of a node, among which:
    • Accurate UTXO cache size accounting (#6102); this makes the option -dbcache
    precise where this grossly underestimated memory usage before
    • Reduce size of per-peer data structure (#6064 and others); this increases the
    number of connections that can be supported with the same amount of memory
    • Reduce the number of threads (#5964, #5679); lowers the amount of (esp.
    virtual) memory needed
Fee estimation changes
This release improves the algorithm used for fee estimation. Previously, -1
was returned when there was insufficient data to give an estimate. Now, -1
will also be returned when there is no fee or priority high enough for the
desired confirmation target. In those cases, it can help to ask for an estimate
for a higher target number of blocks. It is not uncommon for there to be no
fee or priority high enough to be reliably (85%) included in the next block and
for this reason, the default for -txconfirmtarget=n has changed from 1 to 2.
Privacy: Disable wallet transaction broadcast
This release adds an option -walletbroadcast=0 to prevent automatic
transaction broadcast and rebroadcast (#5951). This option allows separating
transaction submission from the node functionality.
Making use of this, third-party scripts can be written to take care of
transaction (re)broadcast:
    • Send the transaction as normal, either through RPC or the GUI
    • Retrieve the transaction data through RPC using gettransaction (NOT
    getrawtransaction). The hex field of the result will contain the raw
    hexadecimal representation of the transaction
    • The transaction can then be broadcasted through arbitrary mechanisms
    supported by the script
One such application is selective Tor usage, where the node runs on the normal
internet but transactions are broadcasted over Tor.
For an example script see [bitcoin-submittx](https://github.com/laanwj/bitcoin-submittx).
Privacy: Stream isolation for Tor
This release adds functionality to create a new circuit for every peer
connection, when the software is used with Tor. The new option,
-proxyrandomize, is on by default.
...[message truncated here by reddit bot]...
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009400.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

Bitcoin Core 0.10.0 released | Wladimir | Feb 16 2015

Wladimir on Feb 16 2015:
Bitcoin Core version 0.10.0 is now available from:
https://bitcoin.org/bin/0.10.0/
This is a new major version release, bringing both new features and
bug fixes.
Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues
The whole distribution is also available as torrent:
https://bitcoin.org/bin/0.10.0/bitcoin-0.10.0.torrent
magnet:?xt=urn:btih:170c61fe09dafecfbb97cb4dccd32173383f4e68&dn;=0.10.0&tr;=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr;=udp%3A%2F%2Fopen.demonii.com%3A1337&ws;=https%3A%2F%2Fbitcoin.org%2Fbin%2F
Upgrading and downgrading

How to Upgrade
If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or
bitcoind/bitcoin-qt (on Linux).
Downgrading warning
Because release 0.10.0 makes use of headers-first synchronization and parallel
block download (see further), the block files and databases are not
backwards-compatible with older versions of Bitcoin Core or other software:
  • Blocks will be stored on disk out of order (in the order they are
received, really), which makes it incompatible with some tools or
other programs. Reindexing using earlier versions will also not work
anymore as a result of this.
  • The block index database will now hold headers for which no block is
stored on disk, which earlier versions won't support.
If you want to be able to downgrade smoothly, make a backup of your entire data
directory. Without this your node will need start syncing (or importing from
bootstrap.dat) anew afterwards. It is possible that the data from a completely
synchronised 0.10 node may be usable in older versions as-is, but this is not
supported and may break as soon as the older version attempts to reindex.
This does not affect wallet forward or backward compatibility.
Notable changes

Faster synchronization
Bitcoin Core now uses 'headers-first synchronization'. This means that we first
ask peers for block headers (a total of 27 megabytes, as of December 2014) and
validate those. In a second stage, when the headers have been discovered, we
download the blocks. However, as we already know about the whole chain in
advance, the blocks can be downloaded in parallel from all available peers.
In practice, this means a much faster and more robust synchronization. On
recent hardware with a decent network link, it can be as little as 3 hours
for an initial full synchronization. You may notice a slower progress in the
very first few minutes, when headers are still being fetched and verified, but
it should gain speed afterwards.
A few RPCs were added/updated as a result of this:
  • getblockchaininfo now returns the number of validated headers in addition to
the number of validated blocks.
  • getpeerinfo lists both the number of blocks and headers we know we have in
common with each peer. While synchronizing, the heights of the blocks that we
have requested from peers (but haven't received yet) are also listed as
'inflight'.
  • A new RPC getchaintips lists all known branches of the block chain,
including those we only have headers for.
Transaction fee changes
This release automatically estimates how high a transaction fee (or how
high a priority) transactions require to be confirmed quickly. The default
settings will create transactions that confirm quickly; see the new
'txconfirmtarget' setting to control the tradeoff between fees and
confirmation times. Fees are added by default unless the 'sendfreetransactions'
setting is enabled.
Prior releases used hard-coded fees (and priorities), and would
sometimes create transactions that took a very long time to confirm.
Statistics used to estimate fees and priorities are saved in the
data directory in the fee_estimates.dat file just before
program shutdown, and are read in at startup.
New command line options for transaction fee changes:
  • -txconfirmtarget=n : create transactions that have enough fees (or priority)
so they are likely to begin confirmation within n blocks (default: 1). This setting
is over-ridden by the -paytxfee option.
  • -sendfreetransactions : Send transactions as zero-fee transactions if possible
(default: 0)
New RPC commands for fee estimation:
  • estimatefee nblocks : Returns approximate fee-per-1,000-bytes needed for
a transaction to begin confirmation within nblocks. Returns -1 if not enough
transactions have been observed to compute a good estimate.
  • estimatepriority nblocks : Returns approximate priority needed for
a zero-fee transaction to begin confirmation within nblocks. Returns -1 if not
enough free transactions have been observed to compute a good
estimate.
RPC access control changes
Subnet matching for the purpose of access control is now done
by matching the binary network address, instead of with string wildcard matching.
For the user this means that -rpcallowip takes a subnet specification, which can be
  • a single IP address (e.g. 1.2.3.4 or fe80::0012:3456:789a:bcde)
  • a network/CIDR (e.g. 1.2.3.0/24 or fe80::0000/64)
  • a network/netmask (e.g. 1.2.3.4/255.255.255.0 or fe80::0012:3456:789a:bcde/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff)
An arbitrary number of -rpcallow arguments can be given. An incoming connection will be accepted if its origin address
matches one of them.
For example:
| 0.9.x and before | 0.10.x |
|--------------------------------------------|---------------------------------------|
| -rpcallowip=192.168.1.1 | -rpcallowip=192.168.1.1 (unchanged) |
| -rpcallowip=192.168.1.* | -rpcallowip=192.168.1.0/24 |
| -rpcallowip=192.168.* | -rpcallowip=192.168.0.0/16 |
| -rpcallowip=* (dangerous!) | -rpcallowip=::/0 (still dangerous!) |
Using wildcards will result in the rule being rejected with the following error in debug.log:
 Error: Invalid -rpcallowip subnet specification: *. Valid are a single IP (e.g. 1.2.3.4), a network/netmask (e.g. 1.2.3.4/255.255.255.0) or a network/CIDR (e.g. 1.2.3.4/24). 
REST interface
A new HTTP API is exposed when running with the -rest flag, which allows
unauthenticated access to public node data.
It is served on the same port as RPC, but does not need a password, and uses
plain HTTP instead of JSON-RPC.
Assuming a local RPC server running on port 8332, it is possible to request:
In every case, EXT can be bin (for raw binary data), hex (for hex-encoded
binary) or json.
For more details, see the doc/REST-interface.md document in the repository.
RPC Server "Warm-Up" Mode
The RPC server is started earlier now, before most of the expensive
intialisations like loading the block index. It is available now almost
immediately after starting the process. However, until all initialisations
are done, it always returns an immediate error with code -28 to all calls.
This new behaviour can be useful for clients to know that a server is already
started and will be available soon (for instance, so that they do not
have to start it themselves).
Improved signing security
For 0.10 the security of signing against unusual attacks has been
improved by making the signatures constant time and deterministic.
This change is a result of switching signing to use libsecp256k1
instead of OpenSSL. Libsecp256k1 is a cryptographic library
optimized for the curve Bitcoin uses which was created by Bitcoin
Core developer Pieter Wuille.
There exist attacks[1] against most ECC implementations where an
attacker on shared virtual machine hardware could extract a private
key if they could cause a target to sign using the same key hundreds
of times. While using shared hosts and reusing keys are inadvisable
for other reasons, it's a better practice to avoid the exposure.
OpenSSL has code in their source repository for derandomization
and reduction in timing leaks that we've eagerly wanted to use for a
long time, but this functionality has still not made its
way into a released version of OpenSSL. Libsecp256k1 achieves
significantly stronger protection: As far as we're aware this is
the only deployed implementation of constant time signing for
the curve Bitcoin uses and we have reason to believe that
libsecp256k1 is better tested and more thoroughly reviewed
than the implementation in OpenSSL.
[1] https://eprint.iacr.org/2014/161.pdf
Watch-only wallet support
The wallet can now track transactions to and from wallets for which you know
all addresses (or scripts), even without the private keys.
This can be used to track payments without needing the private keys online on a
possibly vulnerable system. In addition, it can help for (manual) construction
of multisig transactions where you are only one of the signers.
One new RPC, importaddress, is added which functions similarly to
importprivkey, but instead takes an address or script (in hexadecimal) as
argument. After using it, outputs credited to this address or script are
considered to be received, and transactions consuming these outputs will be
considered to be sent.
The following RPCs have optional support for watch-only:
getbalance, listreceivedbyaddress, listreceivedbyaccount,
listtransactions, listaccounts, listsinceblock, gettransaction. See the
RPC documentation for those methods for more information.
Compared to using getrawtransaction, this mechanism does not require
-txindex, scales better, integrates better with the wallet, and is compatible
with future block chain pruning functionality. It does mean that all relevant
addresses need to added to the wallet before the payment, though.
Consensus library
Starting from 0.10.0, the Bitcoin Core distribution includes a consensus library.
The purpose of this library is to make the verification functionality that is
critical to Bitcoin's consensus available to other applications, e.g. to language
bindings such as [python-bitcoinlib](https://pypi.python.org/pypi/python-bitcoinlib) or
alternative node implementations.
This library is called libbitcoinconsensus.so (or, .dll for Windows).
Its interface is defined in the C header [bitcoinconsensus.h](https://github.com/bitcoin/bitcoin/blob/0.10/src/script/bitcoinconsensus.h).
In its initial version the API includes two functions:
  • bitcoinconsensus_verify_script verifies a script. It returns whether the indicated input of the provided serialized transaction
correctly spends the passed scriptPubKey under additional constraints indicated by flags
  • bitcoinconsensus_version returns the API version, currently at an experimental 0
The functionality is planned to be extended to e.g. UTXO management in upcoming releases, but the interface
for existing methods should remain stable.
Standard script rules relaxed for P2SH addresses
The IsStandard() rules have been almost completely removed for P2SH
redemption scripts, allowing applications to make use of any valid
script type, such as "n-of-m OR y", hash-locked oracle addresses, etc.
While the Bitcoin protocol has always supported these types of script,
actually using them on mainnet has been previously inconvenient as
standard Bitcoin Core nodes wouldn't relay them to miners, nor would
most miners include them in blocks they mined.
bitcoin-tx
It has been observed that many of the RPC functions offered by bitcoind are
"pure functions", and operate independently of the bitcoind wallet. This
included many of the RPC "raw transaction" API functions, such as
createrawtransaction.
bitcoin-tx is a newly introduced command line utility designed to enable easy
manipulation of bitcoin transactions. A summary of its operation may be
obtained via "bitcoin-tx --help" Transactions may be created or signed in a
manner similar to the RPC raw tx API. Transactions may be updated, deleting
inputs or outputs, or appending new inputs and outputs. Custom scripts may be
easily composed using a simple text notation, borrowed from the bitcoin test
suite.
This tool may be used for experimenting with new transaction types, signing
multi-party transactions, and many other uses. Long term, the goal is to
deprecate and remove "pure function" RPC API calls, as those do not require a
server round-trip to execute.
Other utilities "bitcoin-key" and "bitcoin-script" have been proposed, making
key and script operations easily accessible via command line.
Mining and relay policy enhancements
Bitcoin Core's block templates are now for version 3 blocks only, and any mining
software relying on its getblocktemplate must be updated in parallel to use
libblkmaker either version 0.4.2 or any version from 0.5.1 onward.
If you are solo mining, this will affect you the moment you upgrade Bitcoin
Core, which must be done prior to BIP66 achieving its 951/1001 status.
If you are mining with the stratum mining protocol: this does not affect you.
If you are mining with the getblocktemplate protocol to a pool: this will affect
you at the pool operator's discretion, which must be no later than BIP66
achieving its 951/1001 status.
The prioritisetransaction RPC method has been added to enable miners to
manipulate the priority of transactions on an individual basis.
Bitcoin Core now supports BIP 22 long polling, so mining software can be
notified immediately of new templates rather than having to poll periodically.
Support for BIP 23 block proposals is now available in Bitcoin Core's
getblocktemplate method. This enables miners to check the basic validity of
their next block before expending work on it, reducing risks of accidental
hardforks or mining invalid blocks.
Two new options to control mining policy:
  • -datacarrier=0/1 : Relay and mine "data carrier" (OP_RETURN) transactions
if this is 1.
  • -datacarriersize=n : Maximum size, in bytes, we consider acceptable for
"data carrier" outputs.
The relay policy has changed to more properly implement the desired behavior of not
relaying free (or very low fee) transactions unless they have a priority above the
AllowFreeThreshold(), in which case they are relayed subject to the rate limiter.
BIP 66: strict DER encoding for signatures
Bitcoin Core 0.10 implements BIP 66, which introduces block version 3, and a new
consensus rule, which prohibits non-DER signatures. Such transactions have been
non-standard since Bitcoin v0.8.0 (released in February 2013), but were
technically still permitted inside blocks.
This change breaks the dependency on OpenSSL's signature parsing, and is
required if implementations would want to remove all of OpenSSL from the
consensus code.
The same miner-voting mechanism as in BIP 34 is used: when 751 out of a
sequence of 1001 blocks have version number 3 or higher, the new consensus
rule becomes active for those blocks. When 951 out of a sequence of 1001
blocks have version number 3 or higher, it becomes mandatory for all blocks.
Backward compatibility with current mining software is NOT provided, thus miners
should read the first paragraph of "Mining and relay policy enhancements" above.
0.10.0 Change log

Detailed release notes follow. This overview includes changes that affect external
behavior, not code moves, refactors or string updates.
RPC:
  • f923c07 Support IPv6 lookup in bitcoin-cli even when IPv6 only bound on localhost
  • b641c9c Fix addnode "onetry": Connect with OpenNetworkConnection
  • 171ca77 estimatefee / estimatepriority RPC methods
  • b750cf1 Remove cli functionality from bitcoind
  • f6984e8 Add "chain" to getmininginfo, improve help in getblockchaininfo
  • 99ddc6c Add nLocalServices info to RPC getinfo
  • cf0c47b Remove getwork() RPC call
  • 2a72d45 prioritisetransaction
  • e44fea5 Add an option -datacarrier to allow users to disable relaying/mining data carrier transactions
  • 2ec5a3d Prevent easy RPC memory exhaustion attack
  • d4640d7 Added argument to getbalance to include watchonly addresses and fixed errors in balance calculation
  • 83f3543 Added argument to listaccounts to include watchonly addresses
  • 952877e Showing 'involvesWatchonly' property for transactions returned by 'listtransactions' and 'listsinceblock'. It is only appended when the transaction involves a watchonly address
  • d7d5d23 Added argument to listtransactions and listsinceblock to include watchonly addresses
  • f87ba3d added includeWatchonly argument to 'gettransaction' because it affects balance calculation
  • 0fa2f88 added includedWatchonly argument to listreceivedbyaddress/...account
  • 6c37f7f getrawchangeaddress: fail when keypool exhausted and wallet locked
  • ff6a7af getblocktemplate: longpolling support
  • c4a321f Add peerid to getpeerinfo to allow correlation with the logs
  • 1b4568c Add vout to ListTransactions output
  • b33bd7a Implement "getchaintips" RPC command to monitor blockchain forks
  • 733177e Remove size limit in RPC client, keep it in server
  • 6b5b7cb Categorize rpc help overview
  • 6f2c26a Closely track mempool byte total. Add "getmempoolinfo" RPC
  • aa82795 Add detailed network info to getnetworkinfo RPC
  • 01094bd Don't reveal whether password is <20 or >20 characters in RPC
  • 57153d4 rpc: Compute number of confirmations of a block from block height
  • ff36cbe getnetworkinfo: export local node's client sub-version string
  • d14d7de SanitizeString: allow '(' and ')'
  • 31d6390 Fixed setaccount accepting foreign address
  • b5ec5fe update getnetworkinfo help with subversion
  • ad6e601 RPC additions after headers-first
  • 33dfbf5 rpc: Fix leveldb iterator leak, and flush before gettxoutsetinfo
  • 2aa6329 Enable customising node policy for datacarrier data size with a -datacarriersize option
  • f877aaa submitblock: Use a temporary CValidationState to determine accurately the outcome of ProcessBlock
  • e69a587 submitblock: Support for returning specific rejection reasons
  • af82884 Add "warmup mode" for RPC server
  • e2655e0 Add unauthenticated HTTP REST interface to public blockchain data
  • 683dc40 Disable SSLv3 (in favor of TLS) for the RPC client and server
  • 44b4c0d signrawtransaction: validate private key
  • 9765a50 Implement BIP 23 Block Proposal
  • f9de17e Add warning comment to getinfo
Command-line options:
  • ee21912 Use netmasks instead of wildcards for IP address matching
  • deb3572 Add -rpcbind option to allow binding RPC port on a specific interface
  • 96b733e Add -version option to get just the version
  • 1569353 Add -stopafterblockimport option
  • 77cbd46 Let -zapwallettxes recover transaction meta data
  • 1c750db remove -tor compatibility code (only allow -onion)
  • 4aaa017 rework help messages for fee-related options
  • 4278b1d Clarify error message when invalid -rpcallowip
  • 6b407e4 -datadir is now allowed in config files
  • bdd5b58 Add option -sysperms to disable 077 umask (create new files with system default umask)
  • cbe39a3 Add "bitcoin-tx" command line utility and supporting modules
  • dbca89b Trigger -alertnotify if network is upgrading without you
  • ad96e7c Make -reindex cope with out-of-order blocks
  • 16d5194 Skip reindexed blocks individually
  • ec01243 --tracerpc option for regression tests
  • f654f00 Change -genproclimit default to 1
  • 3c77714 Make -proxy set all network types, avoiding a connect leak
  • 57be955 Remove -printblock, -printblocktree, and -printblockindex
  • ad3d208 remove -maxorphanblocks config parameter since it is no longer functional
Block and transaction handling:
  • 7a0e84d ProcessGetData(): abort if a block file is missing from disk
  • 8c93bf4 LoadBlockIndexDB(): Require block db reindex if any blk*.dat files are missing
  • 77339e5 Get rid of the static chainMostWork (optimization)
  • 4e0eed8 Allow ActivateBestChain to release its lock on cs_main
  • 18e7216 Push cs_mains down in ProcessBlock
  • fa126ef Avoid undefined behavior using CFlatData in CScript serialization
  • 7f3b4e9 Relax IsStandard rules for pay-to-script-hash transactions
  • c9a0918 Add a skiplist to the CBlockIndex structure
  • bc42503 Use unordered_map for CCoinsViewCache with salted hash (optimization)
  • d4d3fbd Do not flush the cache after every block outside of IBD (optimization)
  • ad08d0b Bugfix: make CCoinsViewMemPool support pruned entries in underlying cache
  • 5734d4d Only remove actualy failed blocks from setBlockIndexValid
  • d70bc52 Rework block processing benchmark code
  • 714a3e6 Only keep setBlockIndexValid entries that are possible improvements
  • ea100c7 Reduce maximum coinscache size during verification (reduce memory usage)
  • 4fad8e6 Reject transactions with excessive numbers of sigops
  • b0875eb Allow BatchWrite to destroy its input, reducing copying (optimization)
  • 92bb6f2 Bypass reloading blocks from disk (optimization)
  • 2e28031 Perform CVerifyDB on pcoinsdbview instead of pcoinsTip (reduce memory usage)
  • ab15b2e Avoid copying undo data (optimization)
  • 341735e Headers-first synchronization
  • afc32c5 Fix rebuild-chainstate feature and improve its performance
  • e11b2ce Fix large reorgs
  • ed6d1a2 Keep information about all block files in memory
  • a48f2d6 Abstract context-dependent block checking from acceptance
  • 7e615f5 Fixed mempool sync after sending a transaction
  • 51ce901 Improve chainstate/blockindex disk writing policy
  • a206950 Introduce separate flushing modes
  • 9ec75c5 Add a locking mechanism to IsInitialBlockDownload to ensure it never goes from false to true
  • 868d041 Remove coinbase-dependant transactions during reorg
  • 723d12c Remove txn which are invalidated by coinbase maturity during reorg
  • 0cb8763 Check against MANDATORY flags prior to accepting to mempool
  • 8446262 Reject headers that build on an invalid parent
  • 008138c Bugfix: only track UTXO modification after lookup
P2P protocol and network code:
  • f80cffa Do not trigger a DoS ban if SCRIPT_VERIFY_NULLDUMMY fails
  • c30329a Add testnet DNS seed of Alex Kotenko
  • 45a4baf Add testnet DNS seed of Andreas Schildbach
  • f1920e8 Ping automatically every 2 minutes (unconditionally)
  • 806fd19 Allocate receive buffers in on the fly
  • 6ecf3ed Display unknown commands received
  • aa81564 Track peers' available blocks
  • caf6150 Use async name resolving to improve net thread responsiveness
  • 9f4da19 Use pong receive time rather than processing time
  • 0127a9b remove SOCKS4 support from core and GUI, use SOCKS5
  • 40f5cb8 Send rejects and apply DoS scoring for errors in direct block validation
  • dc942e6 Introduce whitelisted peers
  • c994d2e prevent SOCKET leak in BindListenPort()
  • a60120e Add built-in seeds for .onion
  • 60dc8e4 Allow -onlynet=onion to be used
  • 3a56de7 addrman: Do not propagate obviously poor addresses onto the network
  • 6050ab6 netbase: Make SOCKS5 negotiation interruptible
  • 604ee2a Remove tx from AlreadyAskedFor list once we receive it, not when we process it
  • efad808 Avoid reject message feedback loops
  • 71697f9 Separate protocol versioning from clientversion
  • 20a5f61 Don't relay alerts to peers before version negotiation
  • b4ee0bd Introduce preferred download peers
  • 845c86d Do not use third party services for IP detection
  • 12a49ca Limit the number of new addressses to accumulate
  • 35e408f Regard connection failures as attempt for addrman
  • a3a7317 Introduce 10 minute block download timeout
  • 3022e7d Require sufficent priority for relay of free transactions
  • 58fda4d Update seed IPs, based on bitcoin.sipa.be crawler data
  • 18021d0 Remove bitnodes.io from dnsseeds.
Validation:
  • 6fd7ef2 Also switch the (unused) verification code to low-s instead of even-s
  • 584a358 Do merkle root and txid duplicates check simultaneously
  • 217a5c9 When transaction outputs exceed inputs, show the offending amounts so as to aid debugging
  • f74fc9b Print input index when signature validation fails, to aid debugging
  • 6fd59ee script.h: set_vch() should shift a >32 bit value
  • d752ba8 Add SCRIPT_VERIFY_SIGPUSHONLY (BIP62 rule 2) (test only)
  • 698c6ab Add SCRIPT_VERIFY_MINIMALDATA (BIP62 rules 3 and 4) (test only)
  • ab9edbd script: create sane error return codes for script validation and remove logging
  • 219a147 script: check ScriptError values in script tests
  • 0391423 Discourage NOPs reserved for soft-fork upgrades
  • 98b135f Make STRICTENC invalid pubkeys fail the script rather than the opcode
  • 307f7d4 Report script evaluation failures in log and reject messages
  • ace39db consensus: guard against openssl's new strict DER checks
  • 12b7c44 Improve robustness of DER recoding code
  • 76ce5c8 fail immediately on an empty signature
Build system:
  • f25e3ad Fix build in OS X 10.9
  • 65e8ba4 build: Switch to non-recursive make
  • 460b32d build: fix broken boost chrono check on some platforms
  • 9ce0774 build: Fix windows configure when using --with-qt-libdir
  • ea96475 build: Add mention of --disable-wallet to bdb48 error messages
  • 1dec09b depends: add shared dependency builder
  • c101c76 build: Add --with-utils (bitcoin-cli and bitcoin-tx, default=yes). Help string consistency tweaks. Target sanity check fix
  • e432a5f build: add option for reducing exports (v2)
  • 6134b43 Fixing condition 'sabotaging' MSVC build
  • af0bd5e osx: fix signing to make Gatekeeper happy (again)
  • a7d1f03 build: fix dynamic boost check when --with-boost= is used
  • d5fd094 build: fix qt test build when libprotobuf is in a non-standard path
  • 2cf5f16 Add libbitcoinconsensus library
  • 914868a build: add a deterministic dmg signer
  • 2d375fe depends: bump openssl to 1.0.1k
  • b7a4ecc Build: Only check for boost when building code that requires it
Wallet:
  • b33d1f5 Use fee/priority estimates in wallet CreateTransaction
  • 4b7b1bb Sanity checks for estimates
  • c898846 Add support for watch-only addresses
  • d5087d1 Use script matching rather than destination matching for watch-only
  • d88af56 Fee fixes
  • a35b55b Dont run full check every time we decrypt wallet
  • 3a7c348 Fix make_change to not create half-satoshis
  • f606bb9 fix a possible memory leak in CWalletDB::Recover
  • 870da77 fix possible memory leaks in CWallet::EncryptWallet
  • ccca27a Watch-only fixes
  • 9b1627d [Wallet] Reduce minTxFee for transaction creation to 1000 satoshis
  • a53fd41 Deterministic signing
  • 15ad0b5 Apply AreSane() checks to the fees from the network
  • 11855c1 Enforce minRelayTxFee on wallet created tx and add a maxtxfee option
GUI:
  • c21c74b osx: Fix missing dock menu with qt5
  • b90711c Fix Transaction details shows wrong To:
  • 516053c Make links in 'About Bitcoin Core' clickable
  • bdc83e8 Ensure payment request network matches client network
  • 65f78a1 Add GUI view of peer information
  • 06a91d9 VerifyDB progress reporting
  • fe6bff2 Add BerkeleyDB version info to RPCConsole
  • b917555 PeerTableModel: Fix potential deadlock. #4296
  • dff0e3b Improve rpc console history behavior
  • 95a9383 Remove CENT-fee-rule from coin control completely
  • 56b07d2 Allow setting listen via GUI
  • d95ba75 Log messages with type>QtDebugMsg as non-debug
  • 8969828 New status bar Unit Display Control and related changes
  • 674c070 seed OpenSSL PNRG with Windows event data
  • 509f926 Payment request parsing on startup now only changes network if a valid network name is specified
  • acd432b Prevent balloon-spam after rescan
  • 7007402 Implement SI-style (thin space) thoudands separator
  • 91cce17 Use fixed-point arithmetic in amount spinbox
  • bdba2dd Remove an obscure option no-one cares about
  • bd0aa10 Replace the temporary file hack currently used to change Bitcoin-Qt's dock icon (OS X) with a buffer-based solution
  • 94e1b9e Re-work overviewpage UI
  • 8bfdc9a Better looking trayicon
  • b197bf3 disable tray interactions when client model set to 0
  • 1c5f0af Add column Watch-only to transactions list
  • 21f139b Fix tablet crash. closes #4854
  • e84843c Broken addresses on command line no longer trigger testnet
  • a49f11d Change splash screen to normal window
  • 1f9be98 Disable App Nap on OSX 10.9+
  • 27c3e91 Add proxy to options overridden if necessary
  • 4bd1185 Allow "emergency" shutdown during startup
  • d52f072 Don't show wallet options in the preferences menu when running with -disablewallet
  • 6093aa1 Qt: QProgressBar CPU-Issue workaround
  • 0ed9675 [Wallet] Add global boolean whether to send free transactions (default=true)
  • ed3e5e4 [Wallet] Add global boolean whether to pay at least the custom fee (default=true)
  • e7876b2 [Wallet] Prevent user from paying a non-sense fee
  • c1c9d5b Add Smartfee to GUI
  • e0a25c5 Make askpassphrase dialog behave more sanely
  • 94b362d On close of splashscreen interrupt verifyDB
  • b790d13 English translation update
  • 8543b0d Correct tooltip on address book page
Tests:
  • b41e594 Fix script test handling of empty scripts
  • d3a33fc Test CHECKMULTISIG with m == 0 and n == 0
  • 29c1749 Let tx (in)valid tests use any SCRIPT_VERIFY flag
  • 6380180 Add rejection of non-null CHECKMULTISIG dummy values
  • 21bf3d2 Add tests for BoostAsioToCNetAddr
  • b5ad5e7 Add Python test for -rpcbind and -rpcallowip
  • 9ec0306 Add CODESEPARATOFindAndDelete() tests
  • 75ebced Added many rpc wallet tests
  • 0193fb8 Allow multiple regression tests to run at once
  • 92a6220 Hook up sanity checks
  • 3820e01 Extend and move all crypto tests to crypto_tests.cpp
  • 3f9a019 added list/get received by address/ account tests
  • a90689f Remove timing-based signature cache unit test
  • 236982c Add skiplist unit tests
  • f4b00be Add CChain::GetLocator() unit test
  • b45a6e8 Add test for getblocktemplate longpolling
  • cdf305e Set -discover=0 in regtest framework
  • ed02282 additional test for OP_SIZE in script_valid.json
  • 0072d98 script tests: BOOLAND, BOOLOR decode to integer
  • 833ff16 script tests: values that overflow to 0 are true
  • 4cac5db script tests: value with trailing 0x00 is true
  • 89101c6 script test: test case for 5-byte bools
  • d2d9dc0 script tests: add tests for CHECKMULTISIG limits
  • d789386 Add "it works" test for bitcoin-tx
  • df4d61e Add bitcoin-tx tests
  • aa41ac2 Test IsPushOnly() with invalid push
  • 6022b5d Make script_{valid,invalid}.json validation flags configurable
  • 8138cbe Add automatic script test generation, and actual checksig tests
  • ed27e53 Add coins_tests with a large randomized CCoinViewCache test
  • 9df9cf5 Make SCRIPT_VERIFY_STRICTENC compatible with BIP62
  • dcb9846 Extend getchaintips RPC test
  • 554147a Ensure MINIMALDATA invalid tests can only fail one way
  • dfeec18 Test every numeric-accepting opcode for correct handling of the numeric minimal encoding rule
  • 2b62e17 Clearly separate PUSHDATA and numeric argument MINIMALDATA tests
  • 16d78bd Add valid invert of invalid every numeric opcode tests
  • f635269 tests: enable alertnotify test for Windows
  • 7a41614 tests: allow rpc-tests to get filenames for bitcoind and bitcoin-cli from the environment
  • 5122ea7 tests: fix forknotify.py on windows
  • fa7f8cd tests: remove old pull-tester scripts
  • 7667850 tests: replace the old (unused since Travis) tests with new rpc test scripts
  • f4e0aef Do signature-s negation inside the tests
  • 1837987 Optimize -regtest setgenerate block generation
  • 2db4c8a Fix node ranges in the test framework
  • a8b2ce5 regression test only setmocktime RPC call
  • daf03e7 RPC tests: create initial chain with specific timestamps
  • 8656dbb Port/fix txnmall.sh regression test
  • ca81587 Test the exact order of CHECKMULTISIG sig/pubkey evaluation
  • 7357893 Prioritize and display -testsafemode status in UI
  • f321d6b Add key generation/verification to ECC sanity check
  • 132ea9b miner_tests: Disable checkpoints so they don't fail the subsidy-change test
  • bc6cb41 QA RPC tests: Add tests block block proposals
  • f67a9ce Use deterministically generated script tests
  • 11d7a7d [RPC] add rpc-test for http keep-alive (persistent connections)
  • 34318d7 RPC-test based on invalidateblock for mempool coinbase spends
  • 76ec867 Use actually valid transactions for script tests
  • c8589bf Add actual signature tests
  • e2677d7 Fix smartfees test for change to relay policy
  • 263b65e tests: run sanity checks in tests too
Miscellaneous:
  • 122549f Fix incorrect checkpoint data for testnet3
  • 5bd02cf Log used config file to debug.log on startup
  • 68ba85f Updated Debian example bitcoin.conf with config from wiki + removed some cruft and updated comments
  • e5ee8f0 Remove -beta suffix
  • 38405ac Add comment regarding experimental-use service bits
  • be873f6 Issue warning if collecting RandSeed data failed
  • 8ae973c Allocate more space if necessary in RandSeedAddPerfMon
  • 675bcd5 Correct comment for 15-of-15 p2sh script size
  • fda3fed libsecp256k1 integration
  • 2e36866 Show nodeid instead of addresses in log (for anonymity) unless otherwise requested
  • cd01a5e Enable paranoid corruption checks in LevelDB >= 1.16
  • 9365937 Add comment about never updating nTimeOffset past 199 samples
  • 403c1bf contrib: remove getwork-based pyminer (as getwork API call has been removed)
  • 0c3e101 contrib: Added systemd .service file in order to help distributions integrate bitcoind
  • 0a0878d doc: Add new DNSseed policy
  • 2887bff Update coding style and add .clang-format
  • 5cbda4f Changed LevelDB cursors to use scoped pointers to ensure destruction when going out of scope
  • b4a72a7 contrib/linearize: split output files based on new-timestamp-year or max-file-size
  • e982b57 Use explicit fflush() instead of setvbuf()
  • 234bfbf contrib: Add init scripts and docs for Upstart and OpenRC
  • 01c2807 Add warning about the merkle-tree algorithm duplicate txid flaw
  • d6712db Also create pid file in non-daemon mode
  • 772ab0e contrib: use batched JSON-RPC in linarize-hashes (optimization)
  • 7ab4358 Update bash-completion for v0.10
  • 6e6a36c contrib: show pull # in prompt for github-merge script
  • 5b9f842 Upgrade leveldb to 1.18, make chainstate databases compatible between ARM and x86 (issue #2293)
  • 4e7c219 Catch UTXO set read errors and shutdown
  • 867c600 Catch LevelDB errors during flush
  • 06ca065 Fix CScriptID(const CScript& in) in empty script case
Credits

Thanks to everyone who contributed to this release:
  • 21E14
  • Adam Weiss
  • Aitor Pazos
  • Alexander Jeng
  • Alex Morcos
  • Alon Muroch
  • Andreas Schildbach
  • Andrew Poelstra
  • Andy Alness
  • Ashley Holman
  • Benedict Chan
  • Ben Holden-Crowther
  • Bryan Bishop
  • BtcDrak
  • Christian von Roques
  • Clinton Christian
  • Cory Fields
  • Cozz Lovan
  • daniel
  • Daniel Kraft
  • David Hill
  • Derek701
  • dexX7
  • dllud
  • Dominyk Tiller
  • Doug
  • elichai
  • elkingtowa
  • ENikS
  • Eric Shaw
  • Federico Bond
  • Francis GASCHET
  • Gavin Andresen
  • Giuseppe Mazzotta
  • Glenn Willen
  • Gregory Maxwell
  • gubatron
  • HarryWu
  • himynameismartin
  • Huang Le
  • Ian Carroll
  • imharrywu
  • Jameson Lopp
  • Janusz Lenar
  • JaSK
  • Jeff Garzik
  • JL2035
  • Johnathan Corgan
  • Jonas Schnelli
  • jtimon
  • Julian Haight
  • Kamil Domanski
  • kazcw
  • kevin
  • kiwigb
  • Kosta Zertsekel
  • LongShao007
  • Luke Dashjr
  • Mark Friedenbach
  • Mathy Vanvoorden
  • Matt Corallo
  • Matthew Bogosian
  • Micha
  • Michael Ford
  • Mike Hearn
  • mrbandrews
  • mruddy
  • ntrgn
  • Otto Allmendinger
  • paveljanik
  • Pavel Vasin
  • Peter Todd
  • phantomcircuit
  • Philip Kaufmann
  • Pieter Wuille
  • pryds
  • randy-waterhouse
  • R E Broadley
  • Rose Toomey
  • Ross Nicoll
  • Roy Badami
  • Ruben Dario Ponticelli
  • Rune K. Svendsen
  • Ryan X. Charles
  • Saivann
  • sandakersmann
  • SergioDemianLerner
  • shshshsh
  • sinetek
  • Stuart Cardall
  • Suhas Daftuar
  • Tawanda Kembo
  • Teran McKinney
  • tm314159
  • Tom Harding
  • Trevin Hofmann
  • Whit J
  • Wladimir J. van der Laan
  • Yoichi Hirai
  • Zak Wilcox
As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/).
Also lots of thanks to the bitcoin.org website team David A. Harding and Saivann Carignan.
Wladimir
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-February/007480.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

Peter Rizun: A Bitcoin Fee Market Without A Blocksize Limit (Episode 172) شرح الربح يوميا بيتكوين مدى الحياة والوصول الى اكثر من 150 دولار شهريا How Much Money Will You Make Bitcoin Mining With a 330MH s Block Erupter SF Bitcoin Devs Seminar: Bitcoin Under Massive Attack What Is Bitcoin?

This tutorial is to install Bitcoin XT v0.11C on a Raspberry Pi 2. Bitcoin XT is an extension of the Bitcoin Core reference client with additional features such as relaying double spends, UTXO querying, and a larger block size limit. More information can be found on the Bitcoin XT github. Options are given to install the GUI and wallet or not ... Anti-virus: Several people have placed parts of known computer viruses in the Bitcoin block chain. This block chain data can’t infect your computer, but some anti-virus programs quarantine the data anyway, making it more difficult to run Bitcoin Core. This problem mostly affects computers running Windows. Attack target: Bitcoin Core powers the Bitcoin peer-to-peer network, so people who want ... Though blockmaxweight has been preferred for limiting the size of blocks returned by getblocktemplate since 0.13.0, blockmaxsize remained as an option for those who wished to limit their block size directly. Using this option resulted in a few UI issues as well as non-optimal fee selection and ever-so-slightly worse performance, and has thus now been deprecated. Further, the blockmaxsize ... BCH currently has roughly three full-node implementations (Bitcoin ABC, Bitcoin XT, Bitcoin Unlimited). However, these implementations are forked versions of the same Bitcoin (Core) reference client, which means they may share the same (undiscovered) bugs. With a diverse network of nodes, bugs in the implementation of the protocol will result in incompatible blocks, causing a temporary fork ... Making Bitcoin more professional threatens to centralize power. The larger the block size, the more computing power is required to mine blocks. That would shrink the pool of people who can ...

[index] [31378] [442] [2623] [40339] [11150] [4574] [34905] [42555] [44459] [12711]

Peter Rizun: A Bitcoin Fee Market Without A Blocksize Limit (Episode 172)

Have you ever wondered what the whole buzz is about Bitcoin? In this video you'll learn what Bitcoin is and why you absolutely must get involved now. Free Video Reveals: How To Earn 3.24 BTC In 51 ... SUBSCRIBE FOR MORE HOW MUCH - http://shorturl.at/arBHL GekkoScience NewPac USB Miner - https://bit.ly/2RIQgdX GekkoScience 8 Port USB Hub - https://bit.ly/2x... Whether the block size should be increased to 20MB has created more controversy than any other question in Bitcoin's recent history. For some, it is an urgent and necessary step in Bitcoin's ... bitcoin block bitcoin bot bitcoin difficulty bitcoin definition bitcoin download bitcoin dollar bitcoin difficulty chart bitcoin debit card bitcoin difficulty history bitcoin dice bitcoin ... Tech can be complicated; we try to make it easy. Linus Tech Tips is a passionate team of "professionally curious" experts in consumer technology and video pr...

#