Blockchain Explorer - Search the Blockchain BTC ETH BCH

Delightful Privacy

Delightful Privacy delightful

This is a collection of software, operating systems, and other miscellaneous tools to help the average user fight for their privacy and security online.

Operating Systems

Fedora

Fedora uses Security-Enhanced Linux by default, which implements a variety of security policies, including mandatory access controls, which Fedora adopted early on. Fedora provides a hardening wrapper, and does hardening for all of its packages by using compiler features such as position-independent executable (PIE). Wikipedia

Pop!_OS

Pop!_OS provides full out-of-the-box support for both AMD and Nvidia GPUs. It is regarded as an easy distribution to set-up for gaming, mainly due to its built-in GPU support. Pop!_OS provides default disk encryption, streamlined window and workspace management, keyboard shortcuts for navigation as well as built in power management profiles. The latest releases also have packages that allow for easy setup for TensorFlow and CUDA. Wikipedia

Debian

Debian is one of the oldest operating systems based on the Linux kernel. The project is coordinated over the Internet by a team of volunteers guided by the Debian Project Leader and three foundational documents: the Debian Social Contract, the Debian Constitution, and the Debian Free Software Guidelines. New distributions are updated continually, and the next candidate is released after a time-based freeze. Wikipedia

openSUSE Tumbleweed - Rolling Release!

Any user who wishes to have the newest packages that include, but are not limited to, the Linux Kernel, SAMBA, git, desktops, office applications and many other packages, will want Tumbleweed. openSUSE

For enhanced security

Qubes OS

Qubes OS is a security-focused desktop operating system that aims to provide security through isolation. Virtualization is performed by Xen, and user environments can be based on Fedora, Debian, Whonix, and Microsoft Windows, among other operating systems. Wikipedia

Tails

Tails, or The Amnesic Incognito Live System, is a security-focused Debian-based Linux distribution aimed at preserving privacy and anonymity. All its incoming and outgoing connections are forced to go through Tor, and any non-anonymous connections are blocked. Wikipedia).*

Whonix

Whonix is a Debian GNU/Linux–based security-focused Linux distribution. It aims to provide privacy, security and anonymity on the internet. The operating system consists of two virtual machines, a "Workstation" and a Tor "Gateway", running Debian GNU/Linux. All communications are forced through the Tor network to accomplish this. Wikipedia

Web Browsers

For Desktop

Firefox Needs manual tweaking to be more secure! Use ghacks

Firefox, is a free and open-source web browser developed by the Mozilla Foundation and its subsidiary, the Mozilla Corporation. Wikipedia Recommended addons: uBlock Origin | Https Everywhere | Privacy Badger | Privacy Possum | Decentraleyes | NoScript | CanvasBlocker

Tor

Tor is free and open-source software for enabling anonymous communication. The name derived from the acronym for the original software project name "The Onion Router". Tor directs Internet traffic through a free, worldwide, volunteer overlay network consisting of more than seven thousand relays to conceal a user's location and usage from anyone conducting network surveillance or traffic analysis. Using Tor makes it more difficult to trace Internet activity to the user. Wikipedia

UnGoogled-Chromium

Without signing in to a Google Account, Chromium does pretty well in terms of security and privacy. However, Chromium still has some dependency on Google web services and binaries. In addition, Google designed Chromium to be easy and intuitive for users, which means they compromise on transparency and control of internal operations.
ungoogled-chromium addresses these issues in the following ways:

For mobile

Bromite Android Only

Bromite is a Chromium fork with ad blocking and privacy enhancements; take back your browser! Bromite

Firefox Focus Android - iOS

Firefox Focus is a free and open-source privacy-focused browser from Mozilla, available for Android and iOS. Wikipedia

Tor Browser for mobile Android - iOS

Tor protects your privacy on the internet by hiding the connection between your Internet address and the services you use. We believe Tor is reasonably secure, but please ensure you read the instructions and configure it properly. GitHub

Email

Tutanota

Tutanota is an end-to-end encrypted email software and freemium hosted secure email service. Wikipedia

Mailbox

There are many ears listening on the Internet, which is why all our services require mandatory SSL/TLS-encrypted data transmission. For additional security, we also use enhanced (green) security certificates ("EV") by the independent SwissSign trust service provider from Switzerland (Check the padlock symbol in your web browser's URL field). But this is just the beginning – there is so much more that we do. Mailbox

Disroot

Disroot is a decentralized cloud-based service that allows you to store your files and communicate with one another. Established by a privacy-focused organization of volunteers, if we look at Disroot as an email provider specifically, it stands out thanks to its emphasis on security with a completly free open-source approach. ProPrivacy

ProtonMail

ProtonMail is an end-to-end encrypted email service founded in 2013 in Geneva, Switzerland by scientists who met at the CERN research facility. ProtonMail uses client-side encryption to protect email content and user data before they are sent to ProtonMail servers, unlike other common email providers such as Gmail and Outlook.com. The service can be accessed through a webmail client, the Tor network, or dedicated iOS and Android apps. Wikipedia

Search Engine

Searx

searx is a free metasearch engine, available under the GNU Affero General Public License version 3, with the aim of protecting the privacy of its users. To this end, searx does not share users' IP addresses or search history with the search engines from which it gathers results. Tracking cookies served by the search engines are blocked, preventing user-profiling-based results modification. By default, searx queries are submitted via HTTP POST, to prevent users' query keywords from appearing in webserver logs. Wikipedia - Find public instances of searx here searx.space

Startpage

Startpage is a web search engine that highlights privacy as its distinguishing feature. Previously, it was known as the metasearch engine Ixquick, At that time, Startpage was a variant service. Both sites were merged in 2016. Wikipedia

YaCy

YaCy is a free distributed search engine, built on principles of peer-to-peer (P2P) networks. Its core is a computer program written in Java distributed on several hundred computers, as of September 2006, so-called YaCy-peers. Each YaCy-peer independently crawls through the Internet, analyzes and indexes found web pages, and stores indexing results in a common database (so called index) which is shared with other YaCy-peers using principles of P2P networks. It is a free search engine that everyone can use to build a search portal for their intranet and to help search the public internet clearly. Wikipedia

VPN

If you need anonymity and privacy online use Tor instead, if you are looking to bypass a geo-restriction, don't trust public WiFi, or are looking to Torrent, a VPN will help you.

Mullvad

Mullvad is an open-source commercial virtual private network (VPN) service based in Sweden. Launched in March 2009, Mullvad operates using the WireGuard and OpenVPN protocols. Mullvad accepts Bitcoin and Bitcoin Cash for subscriptions in addition to conventional payment methods.
No email address or other identifying information is requested during Mullvad's registration process. Rather, a unique 16-digit account number is anonymously generated for each new user. This account number is henceforth used to log in to the Mullvad service.
The TechRadar review notes that "The end result of all this is you don't have to worry about how Mullvad handles court requests to access your usage data, because, well, there isn't any." Wikipedia

ProtonVPN

ProtonVPN utilizes OpenVPN (UDP/TCP) and the IKEv2 protocol, with AES-256 encryption. The company has a strict no-logging policy for user connection data, and also prevents DNS and Web-RTC leaks from exposing users' true IP addresses. ProtonVPN also includes Tor access support and a kill switch to shut off Internet access in the event of a lost VPN connection.
In January 2020, ProtonVPN became the first VPN provider to release its source code on all platforms and conduct an independent security audit. ProtonVPN is the only VPN to do so, even though experts say this is a crucial factor in deciding whether to trust a VPN service. Wikipedia

For information about alternatives to software and services.

If you are looking for alternatives to proprietary services like Discord and Facebook, or an open-source alternative to Photoshop, check out our list about Awesome-Alternatives

Mirrors are kept up to date, this post may lag behind as we add stuff in.

submitted by CipherOps to LinuxCafe [link] [comments]

A better name for 'Decred' to broaden the reach of our superior vision

This is a detailed proposal I planned to have put up for vote on Politeia. But was told it would need a more detailed plan of execution (budget, marketing, devs etc) which is beyond my expertise. I invite everyone in the DCR community to read it and contribute to make it a reality.
Intro:
Warm greetings to everyone! I am a DCR supporter with a background in law and media. For years I was a news reporter in one of China's largest television networks, during that time I have accumulated a solid understanding of mass communication and presentation.
I fell down the Bitcoin rabbit hole in 2017 and has not look back since. But I believe DCR is a superior store-of-value and a decentralised organism capable of long-term adaptability thus securing the long term financial sovereignty and organisation of people around the world.
Problem:
However, there is a growing sense in the community that Decred has a name recognition barrier to overcome. That was expressed by the DEX developers saying the concern they have is 'getting the word out there'(Decred in Depth May 15th), a concern echoed by many others. The community also appears to be debating and experimenting with various outreach strategies. I have confidence in our vision, developers and contributors. However, they are not the only factors determining the success of a project. When it comes to the expansion of name recognition, adoption and network effects, the competition is fierce and likely winner takes most or even all (see Matthew effect, "Whoever has will be given more, and they will have an abundance. Whoever does not have, even what they have will be taken from them." Bible Matt 13:12 ).
If we do not present our project in the most approachable way possible, I do believe we are at risk of missing out on the golden window of adoption, and the project might never really catch on. That would be a big shame because the world would never be able to adopt our superior vision of Bitcoin sound money, and if the governance issues of bitcoin does flare up further down the road, there is a risk of it being corrupted, neutralised or captured by some predatory governments and the international fiat financiers, and they will never allow something like Bitcoin to develop among the masses again, if that happens, Decred would not be large enough to deter them either.
Reasons for Proposal:
I would like to lay out reasons why the name 'Decred' is not a good name for our project and is holding us back at the moment. I obviously have great respect all the design and planning that has gone before and my fellow Decredees already working on design projects will be incentivised to vote against my proposal. But I am offering constructive criticism and we all want the project to succeed and do not want proposals to just validate whatever we have been doing before. So I hope you would consider this carefully and objectively.
I suggest that the name of our project 'Decred' should be reviewed and rebranded.
Firstly, the name 'Decred (decentralized credits)' is manifestly tech and developer centred, it reflects the perspective and values of the brilliant minds that conceived our project. I understand the monumental importance of decentralization, but for the newcomer the word is hard to grasp.
When introducing the name of a project, we want to communicate what would register as substance that can be easily grasped by people. 'Bitcoin' emphasizes that it is digital and has value. The word 'Coin' is easily understood as substance, 'Coin' is a classic word communicating value that appeals to the most primordial circuits of our brains as something you want( to hold in your hand), something of value, something that jingles in your pocket, something shiny that you want to accumulate and collect.
In contrast, the "De" in Decred gives a notion of negation and negativity, not of substance and affirmation, as is common in the English language (for example: devalue, dethrone, debunk, devolve, dejected). I fully appreciated that to us insiders 'de' signifies 'decentralized' and is of enormous substance and value, but that is not apparent to the newcomer and even implies the opposite.
Secondly, 'Cred (as in credit)' is also very intangible compared to 'Coin', credit only developed later in human economy and do not register with the same force as 'Coin' in our neural circuitry that identifies value. In our day and age, the word 'credit' also has a negative connotations (for example: credit bubble, credit card fraud, credit crunch, credit crisis). In short, credit is associated with volatility and fragility, which is very contrary to the nature of our robust project that values reliability and long-term adaptability.
So with all due respect, "Decred" is not a good name to communicate what we stand for. Compared to 'Bitcoin', it does not meet people where they are (we want people to come for the profit and stay for the vision and tech, most people are like that, for better or for worse), 'Decred' is a bit too self-obsessed with putting what's under-the-hood of the project right upfront in the name, it is not at all obvious what 'Decred' means to a curious person who wanders into cryptoland. In addition, "Decred" bears an unwelcome resemblance to the word "Discredit" which is also another minus.
We should focus more on how the name of our project makes people feel, rather than emphasising function and features that newcomers are unlikely to grasp easily. The majority of people make decisions based on how it makes them feel, not on utility and reason alone. Bitcoin understands this, it struck a more visceral part of the human psyche, people want 'Coins' that can go up in value, but in fact that hopeful speculation and hopium was the Trojan's horse for the masses to adopt a more decentralized, censorship-resistance and secure form of monetary system. Our project should do the same, starting with the name.
Thirdly, I would like to put forward my idea about what should replace the name "Decred'. There can be little doubt that Decred is building on the brilliance and vision of Bitcoin (PoW, 21 million supply cap, transparency and decentralization). In a way, our project aims to be more 'Bitcoin' than Bitcoin, PoW+PoS improves security, the governance mechanism + treasury ventures to where Bitcoin has not gone before, which is building decentralization and transparency in the governance and evolutionary process of the project itself.
Our project lead Jacob Yocom-Piat, whom I really respect, shared how he discovered a 'central planning committee' running things in Bitcoin and believed it was contrary to the spirit of Bitcoin, that helped give birth to the name 'Decred'.
Therefore I believe the 'De' in Decred is a further doubling down of the principle of decentralization ('like it or not, we are taking this all the way, Bitcoin!') , it is a protest. 'Cred' could also be a reaction against the more tangible name 'Coin' signifying that we are moving further beyond it in the digital economy with 'decentralised credits'. However, as I have already laid out above, it is not an approachable name from the perspective of the new adopter. Decred is in essence a reactionary name, and is not optimal for presenting a project that is already digital, intangible and hard to grasp.
History shaped the name 'Decred' and that is a beautiful thing, we would not be here without it. But I suggest it is time to move beyond by taking a step back. We do not want to be going against the grain of two things: 1) human nature and the learning curve towards the tangible and affirmative as opposed the the negational and negative. 2) the already established network effect of the name recognition of 'Bitcoin'. Going against these two grains will make it unnecessarily harder for our outreach, thus hamstringing adoption, instead we should go with the grain and ride the wave of already established network effects by tapping into people's familiarity with the word 'Bitcoin' .
Therefore I propose the new name of our project should at least include the word 'Bitcoin" followed by a word to describe the unique way our project has taken Bitcoin forward.
Bitcoiner Dan Held mention in his blog how: "Bitcoin is the Apex predator of money" https://www.danheld.com/blog/2019/1/6/planting-bitcoinspecies-14 I truly believe that title actually belongs to our project. With our treasury, potential consensus rule changes through politeia and extra security compared to Bitcoin, we will evolve our way up the monetary food-chain because we are robust and superiorly adaptable. As Chris Buriske says: "In #crypto, so long as you have good governance, you can have any feature you want."
Thus, I further suggest our rebranded name be: Bitcoin Evolution (Bitcoin E/BTE). I believe this faithfully reflects our ethos of being true to the spirit of Bitcoin while also being future-proof and adaptable (Although the vote in this proposal itself is not a referendum on Bitcoin Evolution, I will explain at the end).
For people looking into our project, trying to figure out what we are about, 'Bitcoin Evolution' really speaks for itself.
The famous Bitcoin educator Andreas Antonopoulos once said that "the next Bitcoin is Bitcoin". I take it to mean that the idea of Bitcoin is larger than the specific chain Satoshi Nakamoto started himself. If that's true, it is justified for a later project that takes the spirit of Bitcoin even further to adopt the name Bitcoin E. E means Evolution.
Also on the off chance that we turn out to be more wrong about Bitcoin's governance than we think and Bitcoin's rough consensus works out just fine (no more hard forks, successfully implements privacy, no VC corruption etc). Then Bitcoin will become the indisputable 'gold standard' and likely take most of the pie, in that case if our name highlights our similarity to Bitcoin and our governance model also hold its own, we will likely end up doing better than sticking to our protest name 'Decred'. This is from a risk management perspective that we might want to consider.
Also on the off chance that we turn out to be more wrong about Bitcoin's governance than we think and Bitcoin's rough consensus works out just fine (no more hard forks, successfully implements privacy, no VC corruption etc). Then Bitcoin will become the indisputable 'gold standard' and likely take most of the pie, in that case if our name highlights our similarity to Bitcoin and our governance model also hold its own, we will likely end up doing better than sticking to our protest name 'Decred'. This is from a risk management perspective that we might want to consider.
Possible Objections:
I am happy to engage with any question or objections in the comments sections. But allow me to first anticipate some objections I foresee here.
Q1) "Rebranding now will undo too much of the work we have done before. It is too late."
A1: By all the indicators that matter, we are still very early. With the upcoming bull market in this money printer go brrr macro economics setting, a new wave of new investors will be flooding into the crypto sphere in the next 2-3 years, and they will be coming for Bitcoin. By not going against the grain of the established Bitcoin name, the attention Bitcoin Evolution will receive down the years would far outweigh what loss we incur from rebranding. Short term pain, long term gain.
Q2) "Won't we be making an opportunistic gambit and look like scammy or weak projects like Bitcoin Cash, Bitcoin Diamond and Bitcoin Gold ? What if we attract all the wrong people and destroy our community culture?"
A2: I believe regardless of others think, our rebranding is not an opportunistic gambit. Bitcoin Diamond, Gold and etc are forks of Bitcoin that misses the point of what BTC was about. We are not a fork of Bitcoin (and we aim precisely to avoid contentious hard forks). Nevertheless, the spirit of Bitcoin is faithfully implemented in our chain.
We preserve the immutability and robustness of BTC and take the decentralization principle to its full logical conclusion, which is for it to permeant development and community decision -making. One can say we are the true heirs of Bitcoin and we should carry the mantle proudly if we really believe in our vision.
I also do not believe "Bitcoin Evolution" will attract all the wrong people. We will have a huge influx for sure, and that will put us under pressure. But unlike Bitcoin 'Cash' Gold or Diamond', people will coming to us will understand we have the long term and adaptability in mind, 'evolution' suggests it is a long game. The quick buck at all costs bunch will not find ours to be the most enticing name.
I also have faith in our incredible community of communicators and educators to bring new people onboard to our long term mindset.
In addition, when we rebrand, the people who know Decred well and support it will not abandon ship just because they don't like the new name.
The people who are already critical of Decred will no doubt seize the opportunity to attack and insinuate. Haters gonna hate. We did not care before and should not start fretting. I invite all to focus on all the new and curious adopters and explorers who will be flocking to us because of the Bitcoin name, and rightly so.
Q3) "If the fundamentals are sound, won't the project catch on even if the name 'Decred' is unrelatable? Just a matter of time right?"
A3: No. The history of other network effects has shown, the success of a project depends on many factors, it is not just a simple framework of a sifting mechanism eventually singling out the best tech and best ideas.** Sometimes it is not the best idea that wins, but the idea that is good enough at the right time and the right place wins.*\* Think of the internet protocol TCP/IP. We have to have the right ideas at the right time and meet growth goals at an appropriate speed to break out of bottlenecks and achieve network adoption.
With Bitcoin there is the added risk of entrenched centralised establishments exploiting the weaknesses in its governance to neutralised it, if they succeed, we will likely not get a second chance. We should not leave that to chance and refine our project in as many ways as possible.
I believe precisely because we have sound fundamentals of decentralized governance, that when time is ripe to consider a rebrand, we will meet the need together and start this conversation to get the job done. But the project won't automatically catch on by itself, we need to explore and make decisions together to improve it.
In conclusion:
In our name, let us not present to the world what we are against (centralisation), but what we are for(Adaptive future-proof Bitcoin with all its classic strengths). Let us go with the grain of human nature and the network effects of name recognition and not unnecessarily strive against it.
I believe just like a teenager transitioning into adulthood, we are coming of age in a new era of growth and self-awareness. And sometimes, growth means taking a step back to recalibrate and orient ourselves.
What you are voting on:
I hope to ignite a constructive discussion about a serious plan to rebrand for the better. I do not ask for any funding as it is not up to me to implement anything, I just hope my insights can help us on the journey of changing the world for the better with our superior vision of an unstoppable decentralised organism. The How, Who and When questions concerning rebranding should be explored by the community together.
If you Vote 'Yes' you are not necessarily saying we are just going to rebrand to "Bitcoin Evolution" or even a new name with "Bitcoin" in it. Voting 'Yes' means you see the merits of my arguments and want to seriously consider rebranding and turning the page from the current name 'Decred'.
I have been engaging with the Chinese Decred community but I am not known to the community at large, so I understand there will be a lot of questions and scepticism and I welcome all constructive feedback.
I also want to pay my deep respects to all the developers, contributors and everyone who has dedicated their time and passion to our project. Let's keep building together!
If you appreciate the work I put into this, feel free to make a voluntary donation:
DCR: DsWgLiEBw5YAHqrfZpYQjgPYhAT2DkdD6m9
BTC: 3GtuhwsoY2BYjqbaf2tCdjZbZw2Zn4H48P
You can follow me on twitter: https://twitter.com/decredinator
Peace, decredinator
submitted by Decredinator to decred [link] [comments]

Ethereum is considering scalability with Layer 2 strategy and sharding

Scalability is considered a hurdle for wider use of the blockchain. Ethereum is also faced with this problem. But technologies like sharding and layer 2 strategies should solve the problem in the future.
The scalability of a blockchain is particularly difficult because, with a typical blockchain design, every node in the network has to process every transaction, which limits the transaction processing capacity of the entire system to the capacity of a single node, "says Decrypt Ethereum co-founder Vitalik Buterin Blog post from the Ethereum Foundation from over two years ago again.
The developers recognized the problem of network utilization at that time. At that time, Buterin had identified various scaling strategies. Firstly, sharding, in which transactions are carried out without each node processing every transaction according to the principle mentioned, and secondly, layer 2 protocols, in which transactions take place outside the blockchain.

Layer 2 strategy and sharding

On June 1, Buterin then tweeted that "While no one was looking, the initial introduction of Ethereum's Layer 2 scaling strategy was basically successful". "What is left is improvement and commitment."
https://twitter.com/VitalikButerin/status/1267464298919534593?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1267464298919534593&ref_url=https%3A%2F%2Fwww.finanzen.net%2Fnachricht%2Fdevisen%2Fschub-fuer-ethereum-ethereum-fasst-mit-layer-2-strategie-und-sharding-skalierbarkeit-ins-auge-8940233
The plasma second-layer solution, which works similarly to Bitcoin's lightning network, enables "so-called branches to be used off-chain to process smart contracts with higher volumes," explains crypto-news-flash. Complementary to this is Sharding, a first-layer scalability solution that uses micro-chains to validate various transactions on the Ethereum blockchain.
In combination with plasma, sharding should increase the scalability of the Ethereum network, according to Buterin, by one million transactions per second. As a result, as crypto-news-flash reports, Ethereum could even overtake major credit card companies such as Visa or MasterCard.

Scalability as a hurdle for wider use of the blockchain

When it comes to Buterin, token transfers will have to be switched to layer 2 solutions in the future as well, since they used up a large part of the network activity, Decrypt reports. In his opinion, the existing hurdles are not of a technical nature: "This is an adaptation challenge, not a technical challenge. Part of this adaptation challenge is to tighten the guarantees so that users feel comfortable inside and in the L2 system".
The fact that Tether recently announced that it is processing transactions in the OmiseGo network (OMG) seems to show, according to Decrypt, that the scalability of the Ethereum network is currently still a problem. If Ethereum succeeds in using the layer 2 technology to reserve the main chain only for "high-security projects, complex transactions and for bridging and validating layer 2 chains" and thus relieve the network, this could increase scalability contribute and give Ethereum a boost.

Ethereum benefits from improvements

Bitcoin has only recently grown strongly again in the recent past, broke the $ 10,000 mark again and rose by around 8.5 percent to $ 9,666.14 last month (as of June 3, 2020). But Ethereum has also benefited from the improvement of its technology and has grown strongly since its crash in March. Last month, Ethereum saw a price increase of around 16.5 percent to $ 244.52. And maybe the evolution of scalability will soon give Ethereum another boost.
submitted by jakkkmotivator to thecryptobasic [link] [comments]

A proposal for a decentralized social network layer capable of storing rich media

Hello folks!
I have been thinking about the idea of decentralised social network for quite some time, and recently the ideas formed what I think is a rather compete picture. In light of recent Yours announcements I think it's a proper time to share these ideas with a community.
It turned into a long post, and there is no guarantee these idea have a contact with reality, so forgive me if I stole a few minutes of your time.
Protools and standards that will help to understand the proposal (besides blockchain): Memo - blockchain-based base social network protocol, WebRTC transport protocol, WebTorrent JavaScript BitTorrent protocol implementation, BidDB - blockchain crawler by u/unwriter, Progressive Web Apps –– cross platform mobile and desktop apps installable without gatekeepers.
Overall, I prefer WebTorrent in my proposal instead of IPFS as BitTorrent protocol is proved to be robust for almost two decades, while IPFS at this moment is very young and overhyped.
What I propose is a layer that can exist on top of any Memo-like protocol, where Memo forms a base social network state, and the media layer extends its capabilities so that it's possible to store rich media files without any centralised hostings.
Here are the hypothesis/axioms I use as a basement for such a media layer
The proposed idea is based on a play of three actors, or a triangle of 'Original Posters' 'Moderators' and 'Viewers'. Below is detailed explanation of each role, and there are some sub-roles that will be discussed alongside.
Original Poster is anyone connected to the internet who is willing to share any kind of content with the world with only modern browser and a content itself in possession.
Moderator is anyone in the connected world who is willing to be engaged into a socially important role with only a desktop computer with decent amount of free disk space in possession. There is no need to ask a permission to become a moderator.
Viewer is anyone willing to enjoy the media without the need to be engaged with existing social media platforms.
Base technologies:
  1. A webtorrent enabled website with a support of basic bch wallet functionaloty.
  2. A webtorrent enabled website with a feed of op_return messages. Note: 1 and 2 can be implemented as a single platform. (e.g. instant.io x datacash x chainfeed)
  3. A webrtc enabled cross platform desktop torrent client hybridised with a bitdb instance
  4. A webtorrent enabled torrent tracker(s)
The flow:
The Original Poster uses a web browser to create a torrent of the attached media. OP registers the torrent on a tracker, puts infohash alongside a tracker url and desired hashtags into op_return and publishes the memo formatted transaction to bitcoin network. The progress bar shows the status of the 'pseudo' upload that's familiar to most non-tech savvy people. During that phase the content is in network’s ‘working-memory’.
The Moderator uses software to parse the op_return feed. The software continuously downloads all the media from initial seeders and presents it to moderator one by one. It does not open itself as a seeder until moderator decided whether this is a kind of content worth bothering. It's completely subjective decision and every moderator can follow personal strategy. It can be imagined as clicking the green and red buttons where the red one is clicked if the content is subjectively a complete garbage. Once the green button is clicked, moderator becomes a seeder of the content. Moderator can also 'reply' to OPs message with hashtags: every hashtag that corresponds to one of initial hashtags gives it additional weight. Every omitted hashtag loses weight. Some new hashtags can as well be introduced by a moderator. The deeper the history of moderator’s categorization activity, the more weight categorization transaction gives to hashtags (but this is a higher level concept and can vary from implementation to implementation). Moderator creates an internal queue of stored media and deletes the oldest content as soon as the storage threshold is hit (but some other policy can be implemented if moderator decides so). Described above is a level00 moderator who decided to judge the very unclassified content that's received directly from initial seeders.
If the collective speed of content approval is lower than speed of new content introduction, OPs is notified that it maybe necessary to wait for a prolonged time for content to be uploaded, or the fee can be included towards a 'super-moderator' address, so moderators who operate under a single swarm will priorities that content. That address can be a mulitisig where each moderator is a part of a joint account. Once in a while they unlock funds and distribute them in accordance to each moderator's contribution based on the number of 'categorisation transactions' – replies with hashtags, and there can be additional rules that prevent cheating such as only one categorisation transaction to each OP post is taken into account, or rules with some degree of centralisation that encourage seeding, such as the more the moderator seeds the more he earns from these fees if the swarm operates under a single tracker). Alternatively, payouts can be implemented as simple and centralised as existing mining pools.
There are Moderator sub-roles, such as a moderator can choose to only parse the content that was categorised to some degree (e.g. only nsfw content, or only non-nsfw content). The deeper the categorisation, the more precise is the kind of content that's fetched by a moderator, to a degree where moderator can actually enjoy the process a lot as he approves the kind of content he is the most interested in, akin to browsing chronologically filtered subreddit feed. Moderator can also choose to parse several 'categories' simply by 'subscribing' to several hashtags or hashtag tuples. The subroles can be named like moderator level01, level10, level11 etc. By replying to lower level moderator's categorisation transactions, higher-level moderators gives or removes hashtags weight.
The Viewer is presented with a feed of op_return media posts (similar to chainfeed.org), and the content is fetched on the fly from the webtorrent network. The moment the content is fetched the viewer becomes a seeder and continues seeding for as long as content is cached inside browser's storage. That way, the more moderators have approved the content, and the more followers the OP has, the longer the content will persist in a network's 'short-term’ memory.
The Viewer role has sub-roles as well. As soon as the user is engaged into that kind of social network, he can become a Loyal User by installing a special software on a desktop computer that is very similar to Moderators's software, but differs in a following way: viewer inputs Memo account identifier (which is a bitcoin address) into the software that only fetches and seeds the content that was liked by a user, completely in background. As the whole network state is a public information, each user can increase the level of loyalty by specifying the maximum 'dimension' of the content being fetched and seeded, where 1D is the content liked by initial viewer, 2D is the content liked by initial viewer and accounts followed by initial viewer and so on, up until around 6D, where mostly anything that was liked is stored within individual's storage threshold. Loyal Viewers can adopt different policies to restrict the content being fetched and seeded by blacklisting or prioritising certain hashtags, adopting some third-party priority/black lists, as well as specifying storage threshold. Contented that is stored by Loyal Users can be imagined as persisted in networks ‘long-term’ memory. The more Loyal Users are engaged in a network, and the more likes certain content has, the longer it will be stored.
It's worth noting that centralised torrent trackers are not points of failure per se as they are mostly used to pass the content from initial [browser] seeders to moderators. As soon as the content is approved by at least one moderator it can be listed on different trackers operated by different entities, and there can be a rotation of trackers if necessary. That said, each moderator can always re-register all of the content in possession on a new tracker, and the tracker can be adopted by web op_return feed providers. Moreover, the ongoing evolution of browser standards related to web-workers will make in-browser dht lookup a reality in a 2-3 years, which is likely a reasonable window to bootstrap such a network. OP can use some trackers only known among neighbours in particular area.
The layer is vulnerable to a situation where trackers blacklist certain content, and such content can be accessed by using a different op_return feed provider with different trackers, or a native app that will be able to fetch content seeders from the dht. Networks such as i2p can be used to create deep media layers operated anonymously. Also, as Tor is adopted by mainstream browsers (e.g. Brave) Viewers can access trackers through Tor, and such trackers are more resilient. These viewers will be unable to seed, however.
The layer is capable of storing any kind of content, but during bootstrap phase it will be most suitable for images, short video/audio messages, markdown formatted blogposts with embedded media. Each Moderator / Loyal Viewer can adopt different policies related to the size of the content being fetched and stored according to investments into storage facilities. If the proposed idea works, there will be parties willing to store some heavyweight content such as movies. If the layer is accessed from within a native app, it's even capable of livestreams, where the more users are watching a stream the more bandwidth there is for others to join, completely without any centralised content distribution networks.
As outlined above, the layer consist of short-term memory layer capable of storing content for minutes-days, and long-term memory layer capable of storing content for months and probably years. I use biological metaphors here instead of computer science ones as in my opinion the behaviour of this media layer resembles human memory more than computer memory, as ultimately it's a collective human brain decides what to remember and for how long. There is no guarantee that something will be stored at all, and at the same time some kind of content that's collectively perceived as valuable can be stored for a prolonged period of time.
Few words in regard to monetisation. Some heavily engaged players can choose to archive old content and provide access in trade for some micropayments. I see like the Joystream protocol can be used here with little changes such as adoption of webrtc transport protocol. Some different monetisation strategies can be discussed later as microtransaction technologies are more mature and well understood.
I am willing to form a workgroup of developers and creative enthusiasts who find the described idea interesting. I have been thinking about a possible starting point, so I have acquired the BlockPress source code with intention to distribute it in open source. We postponed the announcement a bit as the process of open-source release always takes time. BlockPress is an alternative Memo protocol implementation with a rather slick UI that's familiar to non tech savvy users - the quality I find extremely important. I think this can be a good starting point. If you think so as well, feel free to drop me a telegram message @taowanzou or [proton mail](mailto:[email protected]). Follow me on memo as well!
Sorry for any possible mistakes as English is not my primary language. And thanks for you time reading this!
submitted by taowanzou to btc [link] [comments]

The possibility of community de-anonymizing attacks of /r/btc, sockpuppet revealing and the serious flaw in Bitcoin Cash's SLP tokens.

This post is an informative security briefing, done in the style of responsible disclosure to allow Bitcoin Cash users to consider their security.
It is expected if this security briefing manages to breach the heavily controlled censorship on /btc and actually gets posted there that the response will be "use Cashshuffle". This is not a good response for people who have whitecoins (i.e. legal ones) and will be mixing them with coins from unknown sources which can and most probably will lead to future problems with authorities. Not everybody has the pleasure of being official domiciled on St. Kitts & Nevis like Roger Ver or Andreas Brekken.
This is for all interested users and describes practices that have been done and attacks that could be prepared and is achievable not logged into reddit and just by referencing archived posts from archive.is [such as this one].(http://archive.is/OF419)
This post is being written to highlight a serious flaw and to raise the concern and security awareness of /btc users so they learn to value Satoshi Nakamoto's Wrightpaper and all it states about anonymity and privacy which are 2 different things. No doxxing or breaking of rules or T&C has been done and all information is information that has willingly been published by the authors in their quest for free useless valueless dumbass tokens.
SLP (Simple Ledger Protocol) is a basic token system for Bitcoin Cash created by Gabriel Cardona. This is one of the few developments that has happened on Bitcoin Cash that has not been copied from somewhere else, so is worth analysing to value their competence.
The idea is for very little fee you can create a token with a Ticker Symbol, a Description and a URI and can create any quantity of specific tokens.
As Bitcoin Cash is permissionless any user using memo.cash can create a token in less than a minute or any user with reasonable Javascript skills can create thousands of custom tokens with a simple script and very little cost.
Problem 1: Harassment by Token
Normally using services such as memo.cash you can block a user from being able to send you messages. A way to bypass this is simply to write your message as a token name, or a series of tokens you mint and sent to the user, or using programming mint into the possession of the user with just 1 TX.
And example would be a token sent to user Bob From Alice.
Alice creates a token with qty of 1 with ticker symbol name: "Bob you are a fucking asshole and I hate you". Ticker symbol names can have long lengths, but also additional messages could be in the description. Also a URL attached to the token which would probably be opened could include more text or even an insulting or offensive photo or image. In addition if the URL was a server Alice controlled it could include a unique ID such as http://alice.com/?frombobstoken which would allow the capturing of Bob's IP address by checking the logs so Alice would know it.
This harassment could be simple trolling, or it could verge on serious harassment in the case of example a ex-girlfriend. All you would need is the users SLP address, and you could follow the address as they moved other SLP tokens from their wallet.
A series of messages (unique tokens) can be created all with individual messages. This is different to most forms of internet-based harassment as users generally have their wallets on their cellphones, so the harassment literally gets to their pockets by way of a new token notification.
Problem 2: De-anonymizing Users
Users regularly try to get free SLP tokens by posting their addresses alongside their usernames. Common platforms are Telegram and forums, however it seems Roger Ver himself gets users to do this on reddit and even he is aware of the security implications but does not care.
An example would be this posting
It easy to see which users are posting "in-use" SLP addresses, and also the SLP addresses of the senders. Also sock puppets can be identified.
If I told you ErdoganTalk was MemoryDealers would it surprise you?
So now you could mint tokens with just a qty 1 token, you can mint thousands of custom tokens sending 1 to each reddit user with their reddit username as part of the token symbol to allow you to track these users throughout the blockchain.
Combine this with the flaw highlighted above (harassment etc..) and you can see that SLP tokens, Simple Ledger Protocol is really a dumbass protocol thought of by dumbass developers with little security thought or oversight.
The most important security is the security of your users and their well-being. Bitcoin Cash has clearly failed.
Thanks all for reading. Any questions reach out to me ( jim-btc ). Thanks :-)
Donations: $jimjim
submitted by jim-btc to bitcoincashSV [link] [comments]

Bitcoin Rhodium Mining Guide

Bitcoin Rhodium Mining Guide
Happy Mining!

All available XRC pools can be found on MiningPoolStats

Bitcoin Rhodium Mining Hardware

Baikal Giant+: 1.6 GH/s
Baikal Quad Cube: 1.2 GH/s
Baikal Giant: 900 MH/s
Baikal Quadruple Mini Miner: 600 MH/s
Baikal Miner Cube: 300 MH/s
Baikal Mini Miner: 150 MH/s

Mining Setup

To mine Bitcoin Rhodium you need to set up an XRC wallet and configure your miner of choice. You can choose between Web wallet, Electrum-XRC or Magnum wallet. To set up a web wallet please visit wallet.bitcoinrh.org. Or download and install Electrum-XRC wallet (recommended) for Windows, Linux and MacOS.
Web wallet: wallet.bitcoinrh.org
Electrum-XRC wallet: electrum.bitcoinrh.org
Magnum wallet: https://magnumwallet.co

Sign up for XRC web wallet if not yet done so

  1. Create an account, with your username, password and secure question.
  2. Sign in and click “Create Wallet”.
  3. Set up a strong transaction password. Make sure you store it securely in a secure password manager of choice.
  4. Copy the seed somewhere safe. It’d be a good idea to write seed on a hardcopy and keep it safe.
  5. Paste it to confirm you got it right.
  6. Grab an address for the mining step. Your wallet is now ready to mine XRC.

Instructions for mining XRC on the official pool

Pool link: poolcore.bitcoinrh.org
  1. Any miner that supports X13 will be able to mine XRC. We have a few examples below of miners that are well tested with Bitcoin Rhodium network.
  2. For any miner, configure the miner to point to:
(0–0.8 GH/s) stratum+tcp://poolcore.bitcoinrh.org:3061
(0.8–2 GH/s) stratum+tcp://poolcore.bitcoinrh.org:3062
(3–4 GH/s) stratum+tcp://poolcore.bitcoinrh.org:3063
(5+ GH/s) stratum+tcp://poolcore.bitcoinrh.org:3064
with your XRC address as username and x as password. You don’t need to open an account on pool. You will be mining to XRC address and mined coins will be transferred to your wallet
after blocks reach 10 block maturity
after you mined up minimal amount of coins (currently 0.1 XRC)
sometimes mined blocks could get rejected by network (orphaned) after they were counted as valid blocks. This is normal network behavior to follow longest chain
  1. http://poolcore.bitcoinrh.org is used to follow your miner and network statistics.

CPU Miner-Multi

Source: https://github.com/tpruvot/cpuminer-multi
Sample configuration with CPU Miner tested on UBUNTU.
{
“url” : “stratum+tcp://poolcore.bitcoinrh.org:3061”, “user” : “YOUR XRC ADDRESS”,
“pass” : “x”,
“algo” : “x13”, “threads” : 1,
“cpu-priority” : 5,
“cpu-affinity” : 1, “benchmark” : false, “debug” : true, “protocol”: true, “show-diff”: true, “quiet” : false
}
Command to run your CPUMiner: cpuminer -c cpuminer.json

SGMiner (ATI GPU)

SGMiner is a GPU-based mine: https://github.com/nicehash/sgminereleases
The configuration below was tested on Windows:
setx GPU_FORCE_64BIT_PTR 0
setx GPU_MAX_HEAP_SIZE 100
setx GPU_USE_SYNC_OBJECTS 1
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_SINGLE_ALLOC_PERCENT 100
cd C:\Software\sgminer-5.6.1-nicehash-51-windowsamd64 sgminer.exe
— gpu-platform 1 — algorithm x13mod -url stratum+tcp://poolcore.bitcoinrh. org:3062 — pool-user — userpass :x — auto-fan — temp-target 70 — temp-over- heat 82 — temp-cutoff 85 — gpu-fan 65–85 — log-file log.txt — no-adl — no-extra- nonce -P –T

CCMiner (NVIDIA GPU)

CCMiner is a GPU-based miner (NVIDIA)
Command to run your CCMINER:
ccminer-x64.exe -a x13 -o stratum+tcp://poolcore.bitcoinrh.org:3062 -O :without -D — show-diff

Baikal miner

Settings: Url:
(0–2 GH/s) stratum+tcp://poolcore.bitcoinrh.org:3062
(3–4 GH/s) stratum+tcp://poolcore.bitcoinrh.org:3063
(5+ GH/s) stratum+tcp://poolcore.bitcoinrh.org:3064
Algo: x13User: your XRC receiving address (make sure you set 2 distinct addresses for each hashing board)
Pass: x
Extranonce: leave off Priority set to 0 and 1
Once pool stratum address and your wallet as user are set up you should see your miner mining against XRC pool. When miner is working the status column is green. The pool and miner are incorrectly configured now as status says “Dead” highlighted in red.

Instructions for mining XRC on BSOD pool

Pool link: bsod.pw/en/pool/dashboard/XRC/
Use this code for your miner: -a x13 -o stratum+tcp://pool.bsod.pw:2582 -u WALLET.rig
BSOD pool allows both solo and party mining.
For solo mining use code: -a x13 -o stratum+tcp://pool.bsod.pw:2582 -u WALLET.rig -p m=solo And for party mining use: -a x13 -o stratum+tcp://pool.bsod.pw:2582 -u WALLET.rig -p m=party.yourpassword
NOTICE: You can use us for North America and asia for Asia instead of euin your .bat file or config.
You can also use BSOD pool’s monitor app for Android and iOS.

Instructions for mining XRC on ZERGPOOL

Zergpool offers low fees (just 0.5%) and also SOLO and PARTY mining with no extra fees.
To mine XRC on Zergpool use this command lines for your miner:
Regular: -a x13 -o stratum+tcp://x13.mine.zergpool.com:3633 -u -p c=XRC,mc=XRC Solo: -a x13 -o stratum+tcp://x13.mine.zergpool.com:3633 -u -p c=XRC,mc=XRC,m=solo Party: -a x13 -o stratum+tcp://x13.mine.zergpool.com:3633 -u -p c=XRC,mc=XRC,m=party
Use your coin wallet address as username in mining software. Specify c=SYMBOL as password to identify payout wallet coin, and the same coin in mc=SYMBOL to specify mining coin.
For more information and support please visit http://zergpool.com
Notice that when there are more pools mining XRC in different geographic/availability locations choose the nearest to you as lowest priority and then add desirable fall back pool options in different geographic locations or pools. This is useful when one pool experiences issues, to fall back to different pool in Bitcoin Rhodium network.

Calculate your Bitcoin Rhodium mining profitability

WhatToMine: https://whattomine.com/coins/317-xrc-x13
CoinCalculators: https://www.coincalculators.io/coin/bitcoin-rhodium

Feel free to ask questions in Discord community. There are lots of helpful people around the world watching XRC 24x7.

Bitcoin Rhodium Dev Team
submitted by BitcoinRh to BitcoinRhodium [link] [comments]

Preliminary Proposal for Wallet support for OP_RETURN messages

Hi all,
I have a few use cases at the moment for services I am working on where I would need a user to attach an OP_RETURN to particular transactions. The use-case for this is that it allows one to track a particular wallet address for a transaction without having to act as a mediator of exchange (i.e. first receiving the payment to a controlled address and then forwarding it to the target address). Acting as a mediator of exchange carries high risk (potential for forwarding service to get hacked) and introduces a lot of technical overhead.
In the old bitcoin: URI format, there was a "message" parameter supported (?message=some_message) that appears to be placed in the "Label" section of the wallets I tested (e.g. Electron Cash). I'm not sure if this has always been the case (and is the case with ABC, Unlimited, etc), but to be able to differentiate a "Label" (stored in client-only) and a "Message" (which would be appended as an OP_RETURN to the transaction) would allow services to watch an address for a particular transaction.
To give an example of a use-case for this, I am currently working on a Donation service where I would like the amount that each individual has received to be transparent. Assuming the wallet supported the "message" param as an OP_RETURN, I could do this by formatting the Bitcoin Cash URI like so:
bitcoincash:qrfzahj3tet3rwu5v9a56wm2fn83r8f0m5cuf8z0ws?message={TYPEINDICATOR}{SERVICE}{TX_ID}
Where:
TYPE_INDICATOR refers to a prefix to differentiate it from other services using OP_RETURN (e.g. memo.cash) and prevent those services from picking up irrelevant tx's. As a convention, I'd suggest a hexadecimal value of FF (255) to indicate that it's a custom service that isn't very integral to BCH.
SERVICE is a custom identifier for the particular service. This could be the name of the service itself, shortened to X bytes.
TX_ID is the internal identifer used by the service to identify the transaction.
All in all, this might look something like follows: bitcoincash:qrfzahj3tet3rwu5v9a56wm2fn83r8f0m5cuf8z0ws?message=%FFCHARITY_123
Supporting the above in wallet clients would also allow for people to perform actions using the protocol defined by Memo.Cash by simply clicking a URL - removing reliance on https://memo.cash as a third-party service to do this on their behalf (this could potentially then be a step towards an Internet-Wide BCH commenting platform).
I have been planning on writing a BDIP for this (https://github.com/web3bch/BDIPs) so that wallet implementers can have something official to refer to, but if someone has any suggestions/thoughts on the above, please let me know. Would love to see something like this implemented in popular wallet clients as it's been a wall of sorts, stopping me from progressing with a few different projects I am working on.
Thank you.
(EDIT: Formatting)
EDIT (2018-04-11):
The bitcoincash URI's appear to follow BIP21 (https://github.com/bitcoin/bips/blob/mastebip-0021.mediawiki).
The "message" param is intended as a client label against the transaction itself where as the "label" param is intended to be assigned to the address (i.e. an alias for who owns that address). There does not appear to be a consensus yet on what an OP_RETURN type param should be called. Does anyone have any suggestions?
submitted by jimfriendo to btc [link] [comments]

Call for testing: bustapay :: a practical coinjoin protocol (BIP79) on mainnet! [With a small bounty!]

Originally inspired by pay 2 endpoint, I authored Bustapay :: a practical coinjoin protocol which is a simple payment protocol with truly outsized privacy gains.
After a lot of private testing, I am happy to announce that it's ready for some real-world testing. One of (the?) the largest bitcoin casinos (bustabit) has (quietly) implemented bustapay receive support. As bustabit averages several million dollars worth of volume per day, this represents a huge opportunity to see how bustapay's privacy benefits work in the real world. Bustabit already employs unparalleled bitcoin privacy techniques (custom coin selection, change avoidance, address reuse avoidance, optional batching, randomized wallet behavior etc) but companies like chainalysis have proven to employ rather effective heuristics that lead to much better results than you would first suspect.
It is my belief that if we can get even a small amount (say 1%) of transactions using bustapay, we will totally destroy their ability to analyze the wallet. So that is what I am asking for us to try today. I know someone with access to chainalysis who will be able to help me with a few queries (if anyone else wants to volunteer: please email me at [email protected] and your identity and all identifying queries you run will be kept absolutely confidential).
By helping test, you will also obfuscate your wallet hugely! But please be aware that your wallet will likely be confused as being part of a casino, so only help if you don't mind! I will be happy to reimburse all reasonable txfees used for testing, and offering a free $10 of bitcoin to the first 100 people who test. (But please don't abuse this. I will not pay anyone who I suspect might not be an independent person).
Right now wallet support for bustapay is unfortunately lacking (please ask your favorite wallet about support!) but fortunately it's not too difficult to do with bitcoin core. I wrote a little utility to automate it, however I'd strongly advise against running arbitrary code like that as it's a ridiculous security risk. Plus by doing it manually you get to see the steps involved. So please instead use the manual instructions:
The procedure is as simple as:
Use: https://bustapayproxy.herokuapp.com/ as your "bustapay url"
(Important note: I run this service, it is not an official bustabit service. However the security model of bustapay makes it impossible for me to steal from you. It just allows me observe the transactions (which I will be doing for the purpose of monitoring how badly we confuse chainalysis). I promise to treat all information with due care and will delete it as soon as possible.
Now follow the manual instructions here: https://bustapay.com/manual.html
After 1 confirmation all funds will be in your bustabit account, which you can withdraw (no gambling required!).
P.S. If you want to try first with testnet, use: http://test.bustapay.com/get-newish-address to get a testnet address, and then use http://test.bustapay.com (NOTE: this is pretty much a blackhole, please don't expect the testnet coins back).
submitted by RHavar to Bitcoin [link] [comments]

The Internet is to the Blockchain

I found myself sitting on a plane today, imagining how beautiful a functioning decentralized oracle network would be, as I often do. It occurred to me that there is still a disconnect between blockchain networks, and what we typically think of as the ‘Internet’. Turns out the Internet has changed a lot in my lifetime, although it seemed to happen so casually that I almost forget how far it’s come. And I realized there are some interesting, if imperfect, analogies between the development of the Internet, and the major blockchain developments so far.
So here goes:
Email is to Bitcoin
The first emails were sent in the early 70’s, and within a couple years constituted 3/4 of all ARPANET usage. It’s kind of crazy to think how long ago it was, but email was, at any rate, the first killer app of the internet. Despite the obvious network and adoption limitations from its early days, email has (and continues to) revolutionize our daily interactions. Despite being a relatively simple and limited application, the need for this streamlined method of communication is clear to us all in hindsight.
Bitcoin similarly introduced to the world a streamlined form of communication- this time with value instead of information. I took me awhile to recognize money in this way, but it is very much a form of communication. The money we choose to use is tied to the state of our world, our geopolitical situation, our culture, our values, who we associate with. This is sometimes hard to identify because forms of money we have used over the course of human history changes infrequently, for many of us the rise of Bitcoin has been our first experience making a decision to adopt a new form of money.
Anyways, the main analogy to email is that Bitcoin brought us a very specific and basic function- money- and made it within the framework of a network protocol where it can be transacted as simply and universally as sending an email.
The web browser is to Ethereum
The first web browser was invented later, in 1990. For the first time users could navigate the web with a somewhat friendly GUI, and it kicked off the beginning of the internet as we know it today. This was when the real innovation started happening as business started seeing the potential of having an online presence. The web browser was the first major tool that made real mainstream adoption possible. It was only a few years after the invention of the web browser that some of today’s tech behemoths were conceived and first launched.
Likewise, Ethereum ushered in a similar rush of innovation. The concept of a smart contract platform or “world computer” makes the possibilities of where this technology can go virtually limitless. We all might feel silly looking back on the ICO craze last year, but it happened for a good reason. It was part of a collective realization that what’s happening here is the beginning of a new financial paradigm that none of us fully understands yet. To me that’s the most exciting part of all of this- we know something really cool is going to come out of this crazy thing, but even the most prescient of us can’t predict exactly how it will unfold.
So just as the browser opened the floodgates for innovators to build new types of business on the web, Ethereum (and competing smart contract platforms) have brought us a new wave of opportunity through this new platform for creation of wide ranging applications.
The search engine is to Chainlink
Without the existence of a search engine, I would probably not bother using the web. A lot of people wouldn’t bother. Keep track of a list of all my URLs, having to fight through peripheral pages navigating to information I actually want to see? It’s not worth it for the average person. The whole experience, despite all information I need being technically available, would be disjointed and unsatisfying. The main function of the web browser is to act as the glue of the internet-compiling the relevant info and presenting it as queried.
Chainlink is the glue that binds decentralized systems together, and binds decentralized networks to the rest of the web. Without it, you could technically gain access to the Ethereum network and use it to do business or play games or use social media or whatever possibilities are there, but would you choose to? With the tiny handful of onboarding options and an isolated network environment? Oracles are a thorny problem and make a lot of people uncomfortable, but, the way I see it, it’s the only way to bring wide scale access to tomorrow’s economy, so we need to make sure it’s sorted out.
Anyone have other analogies they like, or improvements on these above? I like analogies because it makes for a simpler explanation since it gives people an association with something they already understand
submitted by straytjacquet to LINKTrader [link] [comments]

🔥Auditchain - Is the world's first decentralized continuous audit and real time financial reporting protocol ecosystem!🔥

🔥Auditchain - Is the world's first decentralized continuous audit and real time financial reporting protocol ecosystem!🔥
https://preview.redd.it/qk1qnrwstoc31.jpg?width=640&format=pjpg&auto=webp&s=e7ba4f9ae479da49dc90bc3c369dae9467131dab
To date, the audit of companies occurs in various cases, in most cases, when one side does not have a transparent and clear vision of the situation in important business. This can give answers to how much more time or money is needed to complete the work, start the project, the current situation, what needs to be changed and corrected.
In simple words, an audit of any company or project is an independent assessment of the state of all their parameters and it should be carried out according to existing and generally accepted standards. They can also be checked how the team copes with its functions, how well the management processes are organized inside. If inconsistencies are identified, the auditor makes recommendations for elimination or improvement.
The audit can also be conducted by employees, determine independently their competence and benefit for the company, on the basis of this conclusion and a personal map of each with a development plan. That is, it is quite a vast area and requires constant checks to better understand what actions should be taken for further production growth.
The audit process takes a lot of time, usually 2-3 weeks and as you know it can affect the workflow and costs a lot of money. Every communication with employees is documented, discussed, problems are identified and ways to solve them. This option is already becoming obsolete and requires a more innovative and rapid approach to finding optimal actions and solutions in real time without distracting many parts of the processes.
And the ideal solution for this area is offered by a project called Auditchain, let's study it.
Auditchain - this is a decentralized platform that continuously collects reports, information from production, from businesses, checks them and immediately issues verification protocols without intermediaries and third parties who might be interested in falsifying documents. This greatly speeds up the process of getting recommendations to improve performance and vision of the whole picture.
Companies will no longer need to look for independent auditors who may not always be qualified and worry about the results, professionalism and disclosure of confidential information to third parties. All this will be implemented on one platform and will be done with the help of AUDT tokens and checked by a network of certified accountants.
At the head of the auditors is DCARPE Alliance, which provides all the necessary tools and assistance for the implementation of this protocol in businesses. Tokens AUDT will help create a new economy of trust and will help to guarantee and safely disclose information of enterprises and constantly check the activities to quickly identify solutions to those problems that are already beginning to slow down the process.
In my opinion, this is a very necessary and important platform that enables many investors, large companies to make a decision to invest in small and medium-sized businesses, as they will receive continuous up-to-date information about the development of their production.
Today the initial placement of tokens on the exchange starts https://exmarkets.com/launchpad at the price of one token 0.20 USD and to take part in it, you will need to register on the site, make a deposit in the currency Bitcoin, Ethereum, USDC or EUR and purchase the required amount. In conclusion, I want to say that the team is already actively entering into partnership agreements with many well-known companies to provide their services and can count on successful development. Thank you for your attention, all the necessary links for a deeper understanding of leave below:
WEBSITE: https://auditchain.com/
TELEGRAM CHAT: https://t.me/Auditchain_Community
WHITEPAPER: https://auditchain.com/wp-content/uploads/2019/05/Auditchain-Whitepaper.pdf
BITCOINTALK THREAD: https://bitcointalk.org/index.php?topic=5152521.0
FACEBOOK ACCOUNT: https://www.facebook.com/auditchain/
TWITTER URL: https://twitter.com/auditchain
submitted by sinhrofazatron to Auditchain [link] [comments]

Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI | Paul Puey | Feb 05 2015

Paul Puey on Feb 05 2015:
Airbitz has developed and implemented a method for communicating a bitcoin
URI across Bluetooth (BLE) or any other P2P, mid range, wireless, broadcast
medium. The currently documented implementation is available in our iOS and
Android mobile wallet (updated Android version with BLE coming in about 1
week). We would like to have the BIP pulled into Github for review and
discussion. Here is the current BIP:
BIP: TBD
Title: P2P Wireless URI transfer
Authors: Thomas Baker , Paul Puey
Contributors: Joey Krug
Status: proposal
Type: Standards Track
Created: 2015-01-12
Table of Contents
-
Abstract
-
Motivation
-
Specification
-
Compatibility
-
Examples
-
References
Abstract
This is a protocol for peer-to-peer wireless transfer of a URI request
using an open broadcast or advertisement channel such as Bluetooth,
Bluetooth Low Energy, or WiFi Direct.
Motivation
There are disadvantages for a merchant (requester) and customer (sender) to
exchange a URI request using QR codes that can be eliminated by using
wireless broadcast or advertisements.
Current QR code scan method to transfer a request URI from merchant
(Requester) to customer (Sender) is cumbersome. A usual scenario is a
merchant with a POS terminal for order entry and a separate tablet for
transacting payments with bitcoin, and a customer with a smartphone. After
the order is entered, the merchant enters payment request information into
the tablet, generates the QR code representing the URI, and presents this
to the customer. The customer prepares to scan the QR code with their
smartphone by maneuvering the camera to the tablet. The tablet screen must
be relatively clean, point at the customer, and held steady. The smartphone
camera lens must be clean, point at the tablet screen, come into range, and
held steady to focus and wait for a QR scan. Environmental conditions such
as bright outdoor sunlight, indoor spot lights, or significant distance
between QR code and camera can create difficult and cumbersome experiences
for users.
Using a wireless local broadcast allows the merchant to just enter the
payment and wait. The tablet and smartphone are not maneuvered to align in
any way. The customer observes broadcast listings, selects the appropriate
one from possible simultaneous broadcasts from other POS stations nearby,
examines the URI request details such as amount, and decides whether to
send funds, initiating a bitcoin network transfer. The merchant and
customer then receive the transaction confirmations and are done with the
sale. Merchant and customer devices are kept private and secured in their
own possession.
The URI and other broadcast identification (Joe’s Grill #1) only contain
public information. However, a copycat broadcaster acting as MITM might
duplicate the broadcast simultaneously as the merchant, attempting to lure
the customer to send funds to the copycat. That attack is mitigated with
this broadcast method because of the partial address in the broadcast.
Specification
Requester generates a bitcoin URI request of variable length, and a limited
descriptive identifier string. Requester then broadcasts the URI’s partial
public address () plus identifier () over a publicly visible
wireless channel.
Sender scans for broadcasts on their device, examines and selects the
desired request by the identifier and partial address. This connects a data
channel to Requester.
Requester sends full URI back over the data channel.
Sender device ensures is part of the full URI public address and
checks the full address integrity. Checking the broadcast and full URI
integrity prevents a copycat device within range from copying the partial
address and fooling the customer into sending funds to the copycat instead.
Below is a description of the protocol through Bluetooth Smart (Low Energy).
Requestor Sender - Bitcoin transaction roles
Peripheral Central - Bluetooth GAP definitions
Mode Mode
1 |-----------| - Requestor Advertises partial bitcoin: URI +
Name
| ... |
2 |<-------------| - Subscribe then send sender's Name, requesting
a response
3 |-----------| - ACK
4 |<-------------| - request Read Characteristic from peripheral
5 |-----------| - Sender receives full bitcoin: URI
1.
Peripheral advertises over a service UUID a BLE extended advertisement
with a Scan Response containing the partial address of a bitcoin URI and a
Name, any plain text. The entire response is limited to 26 characters. The
first 10 make up the first 10 characters of the bitcoin URI public address
where to send bitcoin, and must be present. The remaining characters are
any plain text such as “The Habit 1” or “Starbucks-Reg 1”, more human
readable information. The partial address serves as a check against a
nearby attacker who may try to lure a Sender into sending payment to a
separate wallet by advertising a similar Scan Response but cannot replicate
a public address with the same leading 10 characters and different trailing
characters.
2.
When the Central scans the advertisement, it may display the Scan
Response in a human readable listing using the two pieces of information.
If Central chooses this advertisement to receive the full request, it then
subscribes to the service and writes the characteristic (a second UUID)
with it’s own name, or a blank if not sending a name, to the Peripheral.
3.
Peripheral gets a characteristic write request of the Central’s name,
and acknowledges the receipt by sending a server response.
4.
Central receives a characteristic write (from the response) and
immediately requests the entire bitcoin URI by issuing a read request on
that characteristic.
5.
Peripheral receives the read request and sends the entire bitcoin URI
over that characteristic up to 512 bytes.
This ends the proposed specification as the bitcoin URI transfer is
complete. The Sender would then normally confirm the request and decide
whether to initiate the fund transfer.
Compatibility
There are no prior BIPs covering this.
Examples
Airbitz iOS Bluetooth Low Energy to Bluetooth Low Energy request transfer.
References
[image: logo]
Paul Puey CEO / Co-Founder, Airbitz Inc
+1-619-850-8624 | http://airbitz.co | San Diego
<http://facebook.com/airbitz> <http://twitter.com/airbitz>
<https://plus.google.com/118173667510609425617>
<https://go.airbitz.co/comments/feed/> <http://linkedin.com/in/paulpuey>
<https://angel.co/paul-puey>
DOWNLOAD THE AIRBITZ WALLET:
<https://play.google.com/store/apps/details?id=com.airbitz>
<https://itunes.apple.com/us/app/airbitz/id843536046>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150205/a00a4c8a/attachment.html>
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-February/007320.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

Bitcoin-development Digest, Vol 48, Issue 41 | Damian Gomez | May 08 2015

Damian Gomez on May 08 2015:
Well zombie txns aside, I expect this to be resolved w/ a client side
implementation using a Merkle-Winternitz OTS in order to prevent the loss
of fee structure theougth the implementation of a this security hash that
eill alloow for a one-wya transaction to conitnue, according to the TESLA
protocol.
We can then tally what is needed to compute tteh number of bit desginated
for teh completion og the client-side signature if discussin the
construcitons of a a DH key (instead of the BIP X509 protocol)
On Fri, May 8, 2015 at 2:08 PM, <
bitcoin-development-request at lists.sourceforge.net> wrote:
Send Bitcoin-development mailing list submissions to
bitcoin-development at lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
or, via email, send a message with subject or body 'help' to
bitcoin-development-request at lists.sourceforge.net
You can reach the person managing the list at
bitcoin-development-owner at lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Bitcoin-development digest..."
Today's Topics:
  1. Re: Block Size Increase (Mark Friedenbach)
  2. Softfork signaling improvements (Douglas Roark)
  3. Re: Block Size Increase (Mark Friedenbach)
  4. Re: Block Size Increase (Raystonn) (Damian Gomez)
  5. Re: Block Size Increase (Raystonn)
---------- Forwarded message ----------
From: Mark Friedenbach <mark at friedenbach.org>
To: Raystonn <raystonn at hotmail.com>
Cc: Bitcoin Development <bitcoin-development at lists.sourceforge.net>
Date: Fri, 8 May 2015 13:55:30 -0700
Subject: Re: [Bitcoin-development] Block Size Increase
The problems with that are larger than time being unreliable. It is no
longer reorg-safe as transactions can expire in the course of a reorg and
any transaction built on the now expired transaction is invalidated.
On Fri, May 8, 2015 at 1:51 PM, Raystonn <raystonn at hotmail.com> wrote:
Replace by fee is what I was referencing. End-users interpret the old
transaction as expired. Hence the nomenclature. An alternative is a new
feature that operates in the reverse of time lock, expiring a transaction
after a specific time. But time is a bit unreliable in the blockchain
---------- Forwarded message ----------
From: Douglas Roark <doug at bitcoinarmory.com>
To: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>
Cc:
Date: Fri, 8 May 2015 15:27:26 -0400
Subject: [Bitcoin-development] Softfork signaling improvements
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hello. I've seen Greg make a couple of posts online
(https://bitcointalk.org/index.php?topic=1033396.msg11155302#msg11155302
is one such example) where he has mentioned that Pieter has a new
proposal for allowing multiple softforks to be deployed at the same
time. As discussed in the thread I linked, the idea seems simple
enough. Still, I'm curious if the actual proposal has been posted
anywhere. I spent a few minutes searching the usual suspects (this
mailing list, Reddit, Bitcointalk, IRC logs, BIPs) and can't find
anything.
Thanks.
Douglas Roark
Senior Developer
Armory Technologies, Inc.
doug at bitcoinarmory.com
PGP key ID: 92ADC0D7
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJVTQ4eAAoJEGybVGGSrcDX8eMQAOQiDA7an+qZBqDfVIwEzY2C
SxOVxswwxAyTtZNM/Nm+8MTq77hF8+3j/C3bUbDW6wCu4QxBYA/uiCGTf44dj6WX
7aiXg1o9C4LfPcuUngcMI0H5ixOUxnbqUdmpNdoIvy4did2dVs9fAmOPEoSVUm72
6dMLGrtlPN0jcLX6pJd12Dy3laKxd0AP72wi6SivH6i8v8rLb940EuBS3hIkuZG0
vnR5MXMIEd0rkWesr8hn6oTs/k8t4zgts7cgIrA7rU3wJq0qaHBa8uASUxwHKDjD
KmDwaigvOGN6XqitqokCUlqjoxvwpimCjb3Uv5Pkxn8+dwue9F/IggRXUSuifJRn
UEZT2F8fwhiluldz3sRaNtLOpCoKfPC+YYv7kvGySgqagtNJFHoFhbeQM0S3yjRn
Ceh1xK9sOjrxw/my0jwpjJkqlhvQtVG15OsNWDzZ+eWa56kghnSgLkFO+T4G6IxB
EUOcAYjJkLbg5ssjgyhvDOvGqft+2e4MNlB01e1ZQr4whQH4TdRkd66A4WDNB+0g
LBqVhAc2C8L3g046mhZmC33SuOSxxm8shlxZvYLHU2HrnUFg9NkkXi1Ub7agMSck
TTkLbMx17AvOXkKH0v1L20kWoWAp9LfRGdD+qnY8svJkaUuVtgDurpcwEk40WwEZ
caYBw+8bdLpKZwqbA1DL
=ayhE
-----END PGP SIGNATURE-----
---------- Forwarded message ----------
From: Mark Friedenbach <mark at friedenbach.org>
To: "Raystonn ." <raystonn at hotmail.com>
Cc: Bitcoin Development <bitcoin-development at lists.sourceforge.net>
Date: Fri, 8 May 2015 13:40:50 -0700
Subject: Re: [Bitcoin-development] Block Size Increase
Transactions don't expire. But if the wallet is online, it can
periodically choose to release an already created transaction with a higher
fee. This requires replace-by-fee to be sufficiently deployed, however.
On Fri, May 8, 2015 at 1:38 PM, Raystonn . <raystonn at hotmail.com> wrote:
I have a proposal for wallets such as yours. How about creating all
transactions with an expiration time starting with a low fee, then
replacing with new transactions that have a higher fee as time passes.
Users can pick the fee curve they desire based on the transaction priority
they want to advertise to the network. Users set the priority in the
wallet, and the wallet software translates it to a specific fee curve used
in the series of expiring transactions. In this manner, transactions are
never left hanging for days, and probably not even for hours.
-Raystonn
On 8 May 2015 1:17 pm, Aaron Voisine <voisine at gmail.com> wrote:
As the author of a popular SPV wallet, I wanted to weigh in, in support
of the Gavin's 20Mb block proposal.
The best argument I've heard against raising the limit is that we need
fee pressure. I agree that fee pressure is the right way to economize on
scarce resources. Placing hard limits on block size however is an
incredibly disruptive way to go about this, and will severely negatively
impact users' experience.
When users pay too low a fee, they should:
1) See immediate failure as they do now with fees that fail to propagate.
2) If the fee lower than it should be but not terminal, they should see
degraded performance, long delays in confirmation, but eventual success.
This will encourage them to pay higher fees in future.
The worst of all worlds would be to have transactions propagate, hang in
limbo for days, and then fail. This is the most important scenario to
avoid. Increasing the 1Mb block size limit I think is the simplest way to
avoid this least desirable scenario for the immediate future.
We can play around with improved transaction selection for blocks and
encourage miners to adopt it to discourage low fees and create fee
pressure. These could involve hybrid priority/fee selection so low fee
transactions see degraded performance instead of failure. This would be the
conservative low risk approach.
Aaron Voisine
co-founder and CEO
breadwallet.com
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
---------- Forwarded message ----------
From: Damian Gomez <dgomez1092 at gmail.com>
To: bitcoin-development at lists.sourceforge.net
Cc:
Date: Fri, 8 May 2015 14:04:10 -0700
Subject: Re: [Bitcoin-development] Block Size Increase (Raystonn)
Hello,
I was reading some of the thread but can't say I read the entire thing.
I think that it is realistic to cinsider a nlock sixe of 20MB for any
block txn to occur. THis is an enormous amount of data (relatively for a
netwkrk) in which the avergage rate of 10tps over 10 miniutes would allow
for fewasible transformation of data at this curent point in time.
Though I do not see what extra hash information would be stored in the
overall ecosystem as we begin to describe what the scripts that are
atacrhed tp the blockchain would carry,
I'd therefore think that for the remainder of this year that it is
possible to have a block chain within 200 - 300 bytes that is more
charatereistic of some feasible attempts at attaching nuanced data in order
to keep propliifc the blockchain but have these identifiers be integral
OPSIg of the the entiore block. THe reasoning behind this has to do with
encryption standards that can be added toe a chain such as th DH algoritnm
keys that would allow for a higher integrity level withinin the system as
it is. Cutrent;y tyh prootocl oomnly controls for the amount of
transactions through if TxnOut script and the publin key coming form teh
lcoation of the proof-of-work. Form this then I think that a rate of higher
than then current standard of 92bytes allows for GPUS ie CUDA to perfirm
its standard operations of 1216 flops in rde rto mechanize a new
personal identity within the chain that also attaches an encrypted instance
of a further categorical variable that we can prsribved to it.
I think with the current BIP7 prootclol for transactions there is an area
of vulnerability for man-in-the-middle attacks upon request of bitcin to
any merchant as is. It would contraidct the security of the bitcoin if it
was intereceptefd iand not allowed to reach tthe payment network or if the
hash was reveresed in orfr to change the value it had. Therefore the
current best fit block size today is between 200 - 300 bytws (depending on
how exciteed we get)
Thanks for letting me join the conversation
I welcomes any vhalleneged and will reply with more research as i figure
out what problems are revealed in my current formation of thoughts (sorry
for the errors but i am just trying to move forward - THE DELRERT KEY
LITERALLY PREVENTS IT )
_Damian
---------- Forwarded message ----------
From: Raystonn <raystonn at hotmail.com>
To: Mark Friedenbach <mark at friedenbach.org>
Cc: Bitcoin Development <bitcoin-development at lists.sourceforge.net>
Date: Fri, 8 May 2015 14:01:28 -0700
Subject: Re: [Bitcoin-development] Block Size Increase
Replace by fee is the better approach. It will ultimately replace zombie
transactions (due to insufficient fee) with potentially much higher fees as
the feature takes hold in wallets throughout the network, and fee
competition increases. However, this does not fix the problem of low tps.
In fact, as blocks fill it could make the problem worse. This feature
means more transactions after all. So I would expect huge fee spikes, or a
return to zombie transactions if fee caps are implemented by wallets.
-Raystonn
On 8 May 2015 1:55 pm, Mark Friedenbach <mark at friedenbach.org> wrote:
The problems with that are larger than time being unreliable. It is no
longer reorg-safe as transactions can expire in the course of a reorg and
any transaction built on the now expired transaction is invalidated.
On Fri, May 8, 2015 at 1:51 PM, Raystonn <raystonn at hotmail.com> wrote:
Replace by fee is what I was referencing. End-users interpret the old
transaction as expired. Hence the nomenclature. An alternative is a new
feature that operates in the reverse of time lock, expiring a transaction
after a specific time. But time is a bit unreliable in the blockchain
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/dbf018a4/attachment.html>
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008025.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

Monero. Overview

Monero. Overview

https://preview.redd.it/bcgzjh51cpi11.png?width=720&format=png&auto=webp&s=0a5995c852e67caccecdb138b1b475e84d8fab8d
Cryptoindex is a tool for exposure to the cryptomarket and serves as a smart benchmark for all cryptocurrencies. The AI-based Cryptoindex algorithm is continuously analyzing more than 1000 coins applying over 170 factors, processing more than 1 million signals per second to provide a highly sophisticated index of the top 100 coins.
You can find our previous reviews here:
Dash. Review - August 2018. Binance Coin. Review IOTA. Review. August - 2018 NEM.Overview Ethereum Classic.Review TRON overview. Cardano - review. Future plans. Ripple - review. Further Perspectives Litecoin. June'18 overview The Dow Jones index. From where did it come to us? Bitcoin Cash. June 2018 overview Are cryptocurrency indices a new crypto market trend? EOS. End of May'18 overview Ethereum. May 2018 overview
Here on our Cryptoindex blog, we will be posting 100 articles about each of the top performing coins selected by our powerful AI algorithm#CIX100coinreview.
Today’s review: Monero
What is Monero?
This name cryptocurrency has received from the word "coin" in the language of Esperanto. Cryptocurrency appeared on April 18, 2014, as Bytecoin fork (not Bitcoin). The release of the coin caused increased interest from the crypto community after announcing by the developers the Roadmap and the Whitepaper. The essence of the project was to make the cryptocurrency anonymous.
But on the other hand, the creation of such cryptocurrency attracted the attention of law enforcement agencies, including Europol. As an argument that was brought to the attention of developers, it was that Monero could become a good means of payment on the black market for drugs trade.
The FBI also speaks with the same statement, pointing out that Monero is in the TOP of the crypto-currency on the black market:
  1. Bitcoin
  2. Litecoin
  3. Monero.
The level of Monero anonymity is sometimes questioned, in particular, Edward Snowden called it "amateur cryptocurrency."
At the time of writing, Monero is ranked 11th by the capitalization in Coinmarketcap.com
How does it work?
Monero is mostly an open source software that uses the principle of proof-of-work. But unlike Bitcoin, Monero emission is not limited. That's why the developers did it so that the miners would ensure the system's operation even after the emission was completed.

https://i.redd.it/nzcpy6u3cpi11.gif
The developers of Monero have made a lot of efforts to make their cryptocurrency secure. To achieve a high result, special measures were taken:
  • Use of "Annular signatures". This technology allows you to "shuffle" all the public keys, thus eliminating the possibility of identifying any of the participants in the system.
  • Monero uses a unique protocol that creates one-time addresses. This allows you to hide information about the payee, the balance of his account and so on.
  • Protection against hacking. Cryptographic algorithms ensure the security of electronic cash stored in user wallets.
Due to CryptoNote and the obfuscation added to the protocol, passive mixing is provided: all transactions in the system are anonymous, and all participants in the system can use plausible negation in the event if they are being captured.
Dirty Monero?
Among the miners, it’s in high demand, due to anonymity for mining on other people's computers and servers. Recently, there have been more cases when Monero was noticed in the code of many viruses. The power of many computers around the world is used to extract this particular cryptocurrency, in particular, this happened last year in London, where scammers used the hacked government servers for mining.
Also Monero, right along with Bitcoin, Zcash and Dash is the most used cryptocurrency in Darknet. A particularly favored method of money laundering is the so-called "mixer". The principle of its work is that the money received illegally is sent to the exchange where Bitcoin coins are purchased, for which the Monero tokens are then purchased and then the attacker can safely transfer to any stock exchange, to a pre-established account and receive money in any form convenient for him.
Advantages of Monero
  • Absolute decentralization. Without any control, including financial organizations (banks and etc);
  • The anonymity of transactions;
  • Constant growth and trust;
  • The presence of his own personal wallet.
Disadvantages of Monero
  • The size of one transaction in Monero is more significant than in Bitcoin;
  • The anonymity of transactions began to challenge experts working on the development of other cryptocurrencies.
Conclusion
Now the developers are actively working to promote the currency. Given the high anonymity and growth in demand, success is entirely assured. The anonymity of Monero transactions is not absolute. If the attacker controls a large part of the network, then under certain circumstances, he can deanonymize some of the transactions.
At the time this article was published, Monero [XMR] is 0.812% of the total of CryptoIndex portfolio. You can always check the current CIX100 composition at our MVP platform: http://cryptoindex.ai/
Stay updated on our channels: Follow CRYPTOINDEX on Telegram Follow CRYPTOINDEX on Medium Follow CRYPTOINDEX on Twitter Follow CRYPTOINDEX on Facebook Follow CRYPTOINDEX on Linkedin Follow CRYPTOINDEX on Reddit
https://preview.redd.it/zz0qunsbcpi11.png?width=757&format=png&auto=webp&s=63687e4c6d097b241a2c647fe03945b3d07d2047
submitted by kkkc to CryptoIndex_io [link] [comments]

The Strange Birth & History of Monero, Part III: Decentralized team

You can read here part I (by americanpegaus). This is the post that motivated me to make the part II. Now i'm doing a third part, and there'll be a final 4th part. This is probably too much but i wasn't able to make it shorter. Some will be interested in going through all them, and maybe someone is even willing to make a summary of the whole serie :D.
Monero - an anonymous coin based on CryptoNote technology
https://bitcointalk.org/index.php?topic=582080.0
Comentarios de interés:
-4: "No change, this is just a renaming. In the future, the binaries will have to be changed, as well as some URL, but that's all. By the way, this very account (monero) is shared by several user and is meant to make it easier to change the OP in case of vacancy of the OP. This idea of a shared OP comes from Karmacoin.
Some more things to come:
"
(https://bitcointalk.org/index.php?topic=582080.msg6362672#msg6362672)
-5: “Before this thread is too big, I would like to state that a bug has been identified in the emission curve and we are currently in the process of fixing it (me, TFT, and smooth). Currently coins are emitted at double the rate that was intended. We will correct this in the future, likely by bitshifting values of outputs before a certain height, and then correcting 1 min blocks to 2 min blocks. The changes proposed will be published to a Monero Improvement Protocol on github.”
(https://bitcointalk.org/index.php?topic=582080.msg6363016#msg6363016)
[tacotime make public the bug in the emission curve: token creation is currently 2 times what was intended to be, see this chart BTC vs the actual XMR curve, as it was and it is now, vs the curve that was initially planned in yellow see chart]
-14: “Moving discussion to more relevant thread, previous found here:
https://bitcointalk.org/index.php?topic=578192.msg6364026#msg6364026
I have to say that I am surprised that such an idea [halving current balances and then changing block target to 2 min with same block reward to solve the emission curve issue] is even being countenanced - there are several obvious arguments against it.
Perception - what kind of uproar would happen if this was tried on a more established coin? How can users be expected to trust a coin where it is perceived that the devs are able and willing to "dip" into people's wallets to solve problems?
Technically - people are trying to suggest that this will make no difference since it applies to reward and supply, which might be fair enough if the cap was halved also, but it isn't. People's holdings in the coin are being halved, however it is dressed up.
Market price - How can introducing uncertainty in the contents of people's wallets possibly help market price? I may well be making a fool of myself here, but I have never heard of such a fix before, unless you had savings in a Cypriot bank - has this ever been done for another coin?”
(https://bitcointalk.org/index.php?topic=582080.msg6364174#msg6364174)
-15: “You make good points but unfortunately conflicting statements were made and it isn't possible to stick to them all. It was said that this coin had a mining reward schedule similar to bitcoin. In fact it is twice as fast as intended, even even a bit more than twice as fast as bitcoin.
If you acquired your coins on the basis of the advertised reward schedule, you would be disappointed, and rightfully so, as more coins come to into existence more quickly than you were led to believe.
To simply ignore that aspect of the bug is highly problematic. Every solution may be highly problematic, but the one being proposed was agreed as being the least bad by most of the major stakeholders. Maybe it will still not work, this coin will collapse, and there will need to be a relaunch, in which case all your coins will likely be worthless. I hope that doesn't happen.”
(https://bitcointalk.org/index.php?topic=582080.msg6364242#msg6364242)
[smooth tries to justify his proposal to solve the emission curve issue: halve every current balance and change block target to 2 min with same block reward]
-16: “This coin wasn't working as advertised. It was supposed to be mined slowly like BTC but under the current emission schedule, 39% would be mined by the first year and 86% by the fourth year. Those targets have been moved out by a factor of 2, i.e. 86% mined by year 8, which is more like BTC's 75% by year 8. So the cap has been moved out much further into the future, constraining present and near-term supply, which is what determines the price.”
(https://bitcointalk.org/index.php?topic=582080.msg6364257#msg6364257)
[eizh supports smooth’s plan]
-20: “So long as the process is fair and transparent it makes no difference what the number is... n or n/2 is the same relative value so long as the /2 is applied to everyone. Correcting this now will avoid people accusing the coin of a favourable premine for people who mined in the first week.”
(https://bitcointalk.org/index.php?topic=582080.msg6364338#msg6364338)
[random user supporting smooth’s idea]
-21: “Why not a reduction in block reward of slightly more than half to bring it into line with the proposed graph? That would avoid all sorts of perceptual problems, would not upset present coin holders and be barely noticeable to future miners since less than one percent of coins have been mined so far, the alteration would be very small?”
(https://bitcointalk.org/index.php?topic=582080.msg6364348#msg6364348)
-22: “Because that still turns into a pre-mine or instamine where a few people got twice as many coins as everyone else in the first week.
This was always a bug, and should be treated as such.”
(https://bitcointalk.org/index.php?topic=582080.msg6364370#msg6364370)
[smooth wants to be sure they can’t be stigmatized as “premine”]
-23: “No, not true [answering to "it makes no difference what the number is... n or n/2 is the same relative value so long as the /2 is applied to everyone"]. Your share of the 18,000,000 coins is being halved - rightly or wrongly.”
(https://bitcointalk.org/index.php?topic=582080.msg6364382#msg6364382)
[good point made by a user that is battling “hard” with smooth and his proposal]
-28: “+1 for halving all coins in circulation. Would they completely disappear? What would the process be?”
-31: “I will wait for the next coin based on CryptoNote. Many people, including myself, avoided BMR because TFT released without accepting input from anyone (afaik). I pm'ed TFT 8 days before launch to help and didn't get response until after launch. Based on posting within the thread, I bet there were other people. Now the broken code gets "fixed" by taking away coins.”
(https://bitcointalk.org/index.php?topic=582080.msg6364531#msg6364531)
-32: “What you say is true, and I can't blame anyone from simply dropping this coin and wanting a complete fresh start instead. On the other hand, this coin is still gaining in popularity and is already getting close to bytecoin in hash rate, while avoiding its ninja premine. There is a lot done right here, and definitely a few mistakes.”
(https://bitcointalk.org/index.php?topic=582080.msg6364574#msg6364574)
[smooth stands for the project legitimacy despite the bugs]
-37: “Since everything is scaled and retroactive, the only person to be affected is... me. Tongue Because I bought BMR with BTC, priced it with incorrect information, and my share relative to the eventual maximum has been halved. Oh well. The rest merely mined coins that never should have been mined. The "taking away coins" isn't a symptom of the fix: it's the fundamental thing that needed fixing. The result is more egalitarian and follows the original intention. Software is always a work-in-progress. Waiting for something ideal at launch is pretty hopeless. edit: Let me point out that most top cryptocurrencies today were released before KGW and other new difficulty retargeting algorithms became widespread. Consequently they had massive instamines on the first day, even favorites in good standing like LTC. Here the early miners are voluntarily reducing their eventual stake for the sake of fairness. How cool is that?”
(https://bitcointalk.org/index.php?topic=582080.msg6364886#msg6364886)
[this is eizh supporting the project too]
-43: “I'm baffled that people are arguing about us making the emission schedule more fair. I'm an early adopter. This halves my money, and it's what I want to do. There's another change that needs to be talked about too: we don't believe that microscopic levels of inflation achieved at 9 or 10 years will secure a proof-of-work network. In fact, there's a vast amount of evidence from DogeCoin and InfiniteCoin that it will not. So, we'd like to fix reward when it goes between 0.25 - 1.00 coins. To do so, we need to further bitshift values to decrease the supply under 264-1 atomic units to accommodate this. Again, this hurts early adopters (like me), but is designed to ensure the correct operation of the chain in the long run. It's less than a week old, and if we're going to hardfork in economic changes that make sense we should do it now. We're real devs turning monero into the coin it should have been, and our active commitment should be nothing but good news. Fuck the pump and dumps, we're here to create something with value that people can use.”
(https://bitcointalk.org/index.php?topic=582080.msg6366134#msg6366134)
[tacotime brings to the public for first time the tail emission proposal and writes what is my favourite sentence of the whole monero history: “Fuck the pump and dumps, we're here to create something with value that people can use”]
-51: “I think this is the right attitude. Like you I stand to "lose" from this decision in having my early mining halved, but I welcome it. Given how scammy the average coin launch is, I think maximizing fairness for everyone is the right move. Combining a fair distribution with the innovation of Cryptonote tech could be what differentiates Monero from other coins.”
(https://bitcointalk.org/index.php?topic=582080.msg6366346#msg6366346)
-59: “Hello! It is very good that you've created this thread. I'm ok about renaming. But I can't agree with any protocol changes based only on decisions made by bitcointalk.org people. This is because not all miners are continiously reading forum. Any decision about protocol changes are to be made by hashpower-based voting. From my side I will agree on such a decision only if more than 50% of miners will agree. Without even such a simple majority from miners such changes are meaningless. In case of hardfork that isn't supported by majority of miners the network will split into two nets with low-power fork and high-power not-forking branches. I don't think that this will be good for anybody. Such a voting is easy to be implemented by setting minor_version of blocks to a specific value and counting decisions made after 1000 of blocks. Do you agree with such a procedure?”
(https://bitcointalk.org/index.php?topic=582080.msg6368478#msg6368478)
[TFT appears after a couple days of inactivity]
-63: “In few days I will publish a code with merged mining support. This code will be turned ON only by voting process from miners. What does it mean:
The same procedure is suitable for all other protocol changes.”
(https://bitcointalk.org/index.php?topic=582080.msg6368720#msg6368720)
[And now he is back, TFT is all about merged mining]
-67: “We don't agree that a reverse split amounts to "taking" coins. I also wouldn't agree that a regular forward split would be "giving" coins. It's an exchange of old coins with new coins, with very nearly the exact same value. There is a very slight difference in value due to the way the reward schedule is capped, but that won't be relevant for years or decades. Such a change is entirely reasonable to fix an error in a in coin that has only existed for a week.”
(https://bitcointalk.org/index.php?topic=582080.msg6368861#msg6368861)
-68: “There were no error made in this coin but now there is an initiative to make some changes. Changes are always bad and changes destroy participant confidence even in case these changes are looking as useful. We have to be very careful before making any changes in coins”
(https://bitcointalk.org/index.php?topic=582080.msg6368939#msg6368939)
[TFT does not accept the unexpected emission curve as a bug]
-72: “You are wrong TFT. The original announcement described the coin as having a reward curve "close to Bitcoin's original curve" (those are your exact words). The code as implemented has a reward curve that is nothing like bitcoin. It will be 86% mined in 4 years. It will be 98% mined in 8 years. Bitcoin is 50% mined in 4 years, and 75% in 8 years.
With respect TFT, you did the original fork, and you deserve credit for that. But this coin has now gone beyond your initial vision. It isn't just a question of whether miners are on bitcointalk or not.
There is a great team of people who are working hard to make this coin a success, and this team is collaborating regularly through forum posts, IRC, PM and email. And beyond that a community of users who by and large have been very supportive of the efforts we've taken to move this forward.
Also, miners aren't the only stakeholders, and while a miner voting process is great, it isn't the answer to every question. Though I do agree that miners need to be on board with any hard fork to avoid a harmful split.”
(https://bitcointalk.org/index.php?topic=582080.msg6369137#msg6369137)
[smooth breaks out publicily for first time against TFT]
-75: “I suppose that merged mining as a possible option is a good idea as soon as nobody is forced to use it. MM is a possibility to accept PoW calculated for some other network. It helps to increase a security of both networks and makes it possible for miners not to choose between two networks if they want both:
Important things to know about MM:
Actually the only change that goes with MM is that we are able to accept PoW from some other net with same hash-function. Each miner can decide his own other net he will merge mine BMR with.
And this is still very secure.
This way I don't see any disadvantage in merged mining. What disadvantages do you see in MM?”
(https://bitcointalk.org/index.php?topic=582080.msg6369255#msg6369255)
[TFT stands for merged mining]
-77: “Merged mining essentially forces people to merge both coins because that is the only economically rational decision. I do not want to support the ninja-premined coin with our hash rate.
Merged mining makes perfect sense for a coin with a very low hash rate, otherwise unable to secure itself effectively. That is the case with coins that merge mine with bitcoin. This coin already has 60% of the hash rate of bytecoin, and has no need to attach itself to another coin and encourage sharing of hash rate between the two. It stands well on its own and will likely eclipse bytecoin very soon.
I want people to make a clear choice between the fair launched coin and the ninja-premine that was already 80% mined before it was made public. Given such a choice I believe most will just choose this coin. Letting them choose both allows bytecoin to free ride on what we are doing here. Let the ninja-preminers go their own way.”
(https://bitcointalk.org/index.php?topic=582080.msg6369386#msg6369386)
[smooth again]
-85: “One of you is saying that there was no mistake in the emission formula, while the other is. I'm not asking which I should believe . . I'm asking for a way to verify this”
(https://bitcointalk.org/index.php?topic=582080.msg6369874#msg6369874)
[those that have not been paying attention to the soap opera since the beginning do not understand anything at all]
-86: “The quote I posted "close to Bitcoin's original curve" is from the original announcement here: https://bitcointalk.org/index.php?topic=563821.0
I think there was also some discussion on the thread about it being desirable to do that.
At one point in that discussion, I suggested increasing the denominator by a factor of 4, which is what ended up being done, but I also suggested retaining the block target at 2 minutes, which was not done. The effect of making one change without the other is to double the emission rate from something close to bitcoin to something much faster (see chart a few pages back on this thread).”
(https://bitcointalk.org/index.php?topic=582080.msg6369935#msg6369935)
[smooth answers just a few minutes later]
-92: “I'm happy the Bitmonero attracts so much interest.
I'm not happy that some people want to destroy it.
Here is a simple a clear statement about plans: https://bitcointalk.org/index.php?topic=582670
We have two kind of stakeholders we have respect: miders and coin owners.
Before any protocol changes we will ask miners for agreement. No changes without explicit agreement of miners is possible.
We will never take away or discount any coins that are already emitted. This is the way we respect coin owners.
All other issues can be discussed, proposed and voted for. I understand that there are other opinions. All decisions that aren't supported in this coin can be introduced in any new coin. It's ok to start a new fork. It's not ok to try to destroy an existsing network.”
(https://bitcointalk.org/index.php?topic=582080.msg6370324#msg6370324)
[TFT is kinda upset – he can see how the community is “somehow” taking over]
-94: “Sounds like there's probably going to be another fork then. Sigh.
I guess it will take a few tries to get this coin right.
The problem with not adjusting existing coins is that it make this a premine/instamine. If the emission schedule is changed but not as a bug fix, then earlier miners got an unfair advantage over everyone else. Certainly there are coins with premines and instamines, but there's a huge stigma and such a coin will never achieve the level of success we see for this coin. This was carefully discussed during the team meeting, which was announced a day ahead of time, and everyone with any visible involvement with the coin, you included, was invited. It is unfortunate you couldn't make it to that meeting TFT.”
(https://bitcointalk.org/index.php?topic=582080.msg6370411#msg6370411)
[smooth is desperate due to TFT lack of interest in collaboration, and he publicly speaks about an scission for first time]
-115: “Very rough website online, monero.cc (in case you asked, the domain name was voted on IRC, like the crypto name and its code). Webdesigner, webmaster, writers... wanted.”
(https://bitcointalk.org/index.php?topic=582080.msg6374702#msg6374702)
[Even though the lack of consensus and the obvious chaos, the community keeps going on: Monero already has his own site]
-152: “Here's one idea on fixing the emissions without adjusting coin balances.
We temporarily reduce the emission rate to half of the new target for as long as it takes for the total emission from 0 to match the new curve. Thus there will be a temporary period when mining is very slow, and during that period there was a premine.
But once that period is compete, from the perspective of new adopters, there was no premine -- the total amount of coins emitted is exactly what the slow curve says it should be (and the average rate since genesis is almost the same as the rate at which they are mining, for the first year or so at least).
This means the mining rewards will be very low for a while (if done now then roughly two weeks), and may not attract many new miners. However, I think there enough of us early adopters (and even some new adopters who are willing to make a temporary sacrifice) who want to see this coin succeed to carry it through this period.
The sooner this is done the shorter the catch up period needs to be.”
(https://bitcointalk.org/index.php?topic=582080.msg6378032#msg6378032)
[smooth makes a proposal to solve the “emission curve bug” without changing users balances and without favoring the early miners]
-182: “We have added a poll in the freenode IRC room "Poll #2: "Emission future of Monero, please vote!!" started by stickh3ad. Options: #1: "Keep emission like now"; #2: "Keep emission but change blocktime and final reward"; #3: "Keep emission but change blocktime"; #4: "Keep emission but change final reward"; #5: "Change emission"; #6: "Change emission and block time"; #7: "Change emission and block time and final reward"
Right now everyone is voting for #4, including me.”
(https://bitcointalk.org/index.php?topic=582080.msg6379518#msg6379518)
[tacotime announces an ongoing votation on IRC]
-184: “ change emission: need to bitshift old values on the network or double values after a certain block. controversial. not sure if necessary. can be difficult to implement. keep emission: straightforward, we don't keep change emission or block time. change final reward is simple. if (blockSubsidy < finalSubsidy) return finalSubsidy; else return blockSubsidy;”
(https://bitcointalk.org/index.php?topic=582080.msg6379562#msg6379562)
-188: “Yeah, well. We need to change the front page to reflect this if we can all agree on it.
We should post the emissions curve and the height and value that subsidy will be locked in to.
In my opinion this is the least disruptive thing we can do at the moment, and should ensure that the fork continues to be mineable and secure in about 8 years time without relying on fees to secure it (which I think you agree is a bad idea).”
(https://bitcointalk.org/index.php?topic=582080.msg6379871#msg6379871)
[tacotime]
-190: “I don't think the proposed reward curve is bad by any means. I do think it is bad to change the overall intent of a coin's structure and being close to bitcoins reward curve was a bit part of the intent of this coin. It was launched in response to the observation that bytecoin was 80% mined in less than two years (too fast) and also that it was ninja premined, with a stated goal that the new coin have a reward curve close to bitcoin.
At this point I'm pretty much willing to throw in the towel on this launch:
  1. No GUI
  2. No web site
  3. Botched reward curve (at least botched relative to stated intent)
  4. No pool (and people who are enthusiastically trying to mine having trouble getting any blocks; some of them have probably given up and moved on).
  5. No effective team behind it at launch
  6. No Mac binaries (I don't think this is all that big a deal, but its another nail)
I thought this could be fixed but with all the confusion and lack of clear direction or any consistent vision, now I'm not so sure.
I also believe that merged mining is basically a disaster for this coin, and is probably being quietly promoted by the ninjas holding 80% of bytecoin, because they know it keeps their coin from being left behind, and by virtue of first mover advantage, probably relegates any successors to effective irrelevance (like namecoin, etc.).
We can do better. It's probably time to just do better.”
(https://bitcointalk.org/index.php?topic=582080.msg6380065#msg6380065)
[smooth is disappointed]
-191: “The website does exist now, it's just not particularly informative yet. :) But, I agree that thankful_for_today has severely mislead everyone by stating the emission was "close to Bitcoin's" (if he's denying that /2 rather than /4 emission schedule was unintentional, as he seems to be). I'm also against BCN merge mining. It works against the goal of overtaking BCN and if that's not a goal, I don't know what we're even doing here. I'll dedicate my meagre mining to voting against that.
That said, you yourself have previously outlined why relaunches and further clones fail. I'd rather stick with this one and fix it.”
(https://bitcointalk.org/index.php?topic=582080.msg6380235#msg6380235)
[eizh tries to keep smooth on board]
-196: “BCN is still growing as well. It is up to 1.2 million now. If merged mining happens, (almost) everyone will just mine both. The difficulty on this coin will jump up to match BCN (in fact both will likely go higher since the hash rate will be combined) and again it is an instamine situation. (Those here the first week get the benefit of easy non-merged mining, everyone else does not.) Comments were made on this thread about this not being yet another pump-and-dump alt. I think that could have been the case, but sadly, I don't really believe that it is.”
(https://bitcointalk.org/index.php?topic=582080.msg6380778#msg6380778)
-198: “There's no point in fragmenting talent. If you don't think merge mining is a good idea, I'd prefer we just not add it to the code.
Bitcoin had no web site or GUI either initially. Bitcoin-QT was the third Bitcoin client.
If people want a pool, they can make one. There's no point in centralizing the network when it's just began, though. Surely you must feel this way.”
(https://bitcointalk.org/index.php?topic=582080.msg6381866#msg6381866)
[tacotime also wants smooth on board]
-201: “My personal opinion is that I will abandon the fork if merge mining is added. And then we can discuss a new fork. Until then I don't think Monero will be taken over by another fork.”
(https://bitcointalk.org/index.php?topic=582080.msg6381970#msg6381970)
[tacotime opens the season: if merged mining is implemented, he will leave the ship]
-203: “Ditto on this. If the intention wasn't to provide a clearweb launched alternative to BCN, then I don't see a reason for this fork to exist. BCN is competition and miners should make a choice.”
(https://bitcointalk.org/index.php?topic=582080.msg6382097#msg6382097)
[eizh supports tacotime]
-204: “+1 Even at the expense of how much I already "invested" in this coin.”
(https://bitcointalk.org/index.php?topic=582080.msg6382177#msg6382177)
[NoodleDoodle is also against merged mining]
This is basically everything worth reading in this thread. This thread was created in the wrong category, and its short life of about 2 days was pretty interesting. Merged mining was rejected and it ended up with the inactivity of TFT for +7 days and the creation of a new github repo the 30th of April. It is only 12 days since launch and a decentralized team is being built.
Basically the community had forked (but not the chain) and it was evolving and moving forward to its still unclear future.
These are the main takeaways of this thread:
  • The legitimacy of the "leaders" of the community is proven when they proposed and supported the idea of halving the balances for the greater good to solve the emission curve issue without any possible instamine accusation. Also their long-term goals and values rejecting merged-mining with a "primined scam"
  • It is decided that, as for now, it is “too late” to change the emission curve, and finally monero will mint 50% of its coin in ~1.3 years (bitcoin did it after 3.66 years) and 86% of its coins in 4 years (bitcoin does it in ~11 years) (was also voted here) (see also this chart)
  • It is decided that a “minimum subsidy” or “tail emission” to incentivize miners “forever” and avoid scaling fees will be added (it will be finally added to the code march 2015)
  • Merged mining is plainly rejected by the future “core team” and soon rejected by "everyone". This will trigger TFT inactivity.
  • The future “core team” is somehow being formed in a decentralized way: tacotime, eizh, NoodleDoodle, smooth and many others
And the most important. All this (and what is coming soon) is a proof of the decentralization of Monero. Probably comparable to Bitcoin first days. This is not a company building a for-profit project (even if on the paper it is not for-profit), this a group of disconnected individuals sharing a goal and working together to reach it.
Soon will be following a final part where i'll collect the bitcointalk logs in the current official announcement threads. There you'll be able to follow the decentralized first steps of develoment (open source pool, miner optimizations and exchanges, all surrounded by fud trolls, lots of excitmen and a rapidly growing collaborative community.
submitted by el_hispano to Monero [link] [comments]

Segwit2Mb - combined soft/hard fork - Request For Comments | Sergio Demian Lerner | Mar 31 2017

Sergio Demian Lerner on Mar 31 2017:
Hi everyone,
Segwit2Mb is the project to merge into Bitcoin a minimal patch that aims to
untangle the current conflict between different political positions
regarding segwit activation vs. an increase of the on-chain blockchain
space through a standard block size increase. It is not a new solution, but
it should be seen more as a least common denominator.
Segwit2Mb combines segwit as it is today in Bitcoin 0.14+ with a 2MB block
size hard-fork activated ONLY if segwit activates (95% of miners
signaling), but at a fixed future date.
The sole objective of this proposal is to re-unite the Bitcoin community
and avoid a cryptocurrency split. Segwit2Mb does not aim to be best
possible technical solution to solve Bitcoin technical limitations.
However, this proposal does not imply a compromise to the future
scalability or decentralization of Bitcoin, as a small increase in block
size has been proven by several core and non-core developers not to affect
Bitcoin value propositions.
In the worst case, a 2X block size increase has much lower economic impact
than the last bitcoin halving (<10%), which succeeded without problem.
On the other side, Segwit2Mb primary goal is to be minimalistic: in this
patch some choices have been made to reduce the number of lines modified in
the current Bitcoin Core state (master branch), instead of implementing the
most elegant solution. This is because I want to reduce the time it takes
for core programmers and reviewers to check the correctness of the code,
and to report and correct bugs.
The patch was built by forking the master branch of Bitcoin Core, mixing a
few lines of code from Jeff Garzik's BIP102, and defining a second
versionbits activation bit (bit 2) for the combined activation.
The combined activation of segwit and 2Mb hard-fork nVersion bit is 2
(DEPLOYMENT_SEGWIT_AND_2MB_BLOCKS).
This means that segwit can still be activated without the 2MB hard-fork by
signaling bit 1 in nVersion (DEPLOYMENT_SEGWIT).
The tentative lock-in and hard-fork dates are the following:
Bit 2 signaling StartTime = 1493424000; // April 29th, 2017
Bit 2 signaling Timeout = 1503964800; // August 29th, 2017
HardForkTime = 1513209600; // Thu, 14 Dec 2017 00:00:00 GMT
The hard-fork is conditional to 95% of the hashing power has approved the
segwit2mb soft-fork and the segwit soft-fork has been activated (which
should occur 2016 blocks after its lock-in time)
For more information on how soft-forks are signaled and activated, see
https://github.com/bitcoin/bips/blob/mastebip-0009.mediawiki
This means that segwit would be activated before 2Mb: this is inevitable,
as versionbits have been designed to have fixed activation periods and
thresholds for all bits. Making segwit and 2Mb fork activate together at a
delayed date would have required a major re-write of this code, which would
contradict the premise of creating a minimalistic patch. However, once
segwit is activated, the hard-fork is unavoidable.
Although I have coded a first version of the segwit2mb patch (which
modifies 120 lines of code, and adds 220 lines of testing code), I would
prefer to wait to publish the source code until more comments have been
received from the community.
To prevent worsening block verification time because of the O(N2) hashing
problem, the simple restriction that transactions cannot be larger than 1Mb
has been kept. Therefore the worse-case of block verification time has only
doubled.
Regarding the hard-fork activation date, I want to give enough time to all
active economic nodes to upgrade. As of Fri Mar 31 2017,
https://bitnodes.21.co/nodes/ reports that 6332 out of 6955 nodes (91%)
have upgraded to post 0.12 versions. Upgrade to post 0.12 versions can be
used to identify economic active nodes, because in the 0.12 release dynamic
fees were introduced, and currently no Bitcoin automatic payment system can
operate without automatic discovery of the current fee rate. A pre-0.12
would require constant manual intervention.
Therefore I conclude that no more than 91% of the network nodes reported by
bitnodes are active economic nodes.
As Bitcoin Core 0.12 was released on February 2016, the time for this 91%
to upgrade has been around one year (under a moderate pressure of
operational problems with unconfirmed transactions).
Therefore we can expect a similar or lower time to upgrade for a hard-fork,
after developers have discussed and approved the patch, and it has been
reviewed and merged and 95% of the hashing power has signaled for it (the
pressure not to upgrade being a complete halt of the operations). However I
suggest that we discuss the hard-fork date and delay it if there is a real
need to.
Currently time works against the Bitcoin community, and so is delaying a
compromise solution. Most of the community agree that halting the
innovation for several years is a very bad option.
After the comments collected by the community, a BIP will be written
describing the resulting proposal details.
If segwit2mb locks-in, before hard-fork occurs all bitcoin nodes should be
updated to a Segwit2Mb enabled node to prevent them to be forked-away in a
chain with almost no hashing-power.
The proof of concept patch was made for Bitcoin Core but should be easily
ported to other Bitcoin protocol implementations that already support
versionbits. Lightweight (SPV) wallets should not be affected as they
generally do not check the block size.
I personally want to see the Lightning Network in action this year, use the
non-malleability features in segwit, see the community discussing other
exciting soft-forks in the scaling roadmap, Schnorr sigs, drivechains and
MAST.
I want to see miners, developers and industry side-by-side pushing Bitcoin
forward, to increase the value of Bitcoin and prevent high transaction fees
to put out of business use-cases that could have high positive social
impact.
I believe in the strength of a unified Bitcoin community. If you're a
developer, please give your opinion, suggest changes, audit it, and take a
stand with me to unlock the current Bitcoin deadlock.
Contributions to the segwit2mb project are welcomed and awaited. The only
limitation is to stick to the principle that the patch should be as simple
to audit as possible. As an example, I wouldn't feel confident if the patch
modified more than ~150 lines of code.
Improvements unrelated to a 2 Mb increase or segwit, as beneficial as it
may be to Bitcoin, should not be part of segwit2Mb.
This proposal should not prevent other consensus proposals to be
simultaneously merged: segwit2mb is a last resort solution in case we can
not reach consensus on anything better.
Again, the proposal is only a starting point: community feedback is
expected and welcomed.
Regards,
Sergio Demian Lerner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170331/c55dafa8/attachment-0001.html
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013921.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Introducing a POW through a soft-fork | Devrandom | Nov 01 2017

Devrandom on Nov 01 2017:
Hi all,
Feedback is welcome on the draft below. In particular, I want to see if
there is interest in further development of the idea and also interested in
any attack vectors or undesirable dynamics.
(Formatted version available here:
https://github.com/devrandom/btc-papers/blob/masteaux-pow.md )

Soft-fork Introduction of a New POW

Motivation:

not have economies of scale
mining power fluctuations
Note however that choice of a suitable POW will require deep analysis.
Some pitfalls include: botnet mining, POWs that seem ASIC resistant but are
not, unexpected/covert optimization.
In particular, unexpected/covert optimizations, such as ASCIBOOST, present
a potential centralizing and destabilizing force.

Design

Aux POW intermediate block

Auxiliary POW blocks are introduced between normal blocks - i.e. the chain
alternates between the two POWs.
Each aux-POW block points to the previous normal block and contains
transactions just like a normal block.
Each normal block points to the previous aux-POW block and must contain all
transactions from the aux-POW block.
Block space is not increased.
The new intermediate block and the pointers are introduced via a soft-fork
restriction.

Reward for aux POW miners

The reward for the aux POW smoothly increases from zero to a target value
(e.g. 1/2 of the total reward) over time.
The reward is transferred via a soft-fork restriction requiring a coinbase
output to an address published in the
aux-POW block.

Aux POW difficulty adjustment

Difficulty adjustments remain independent for the two POWs.
The difficulty of the aux POW is adjusted based on the average time between
normal block found
to aux block found.
Further details are dependent on the specific POW.

Heaviest chain rule change

This is a semi-hard change, because non-upgraded nodes can get on the wrong
chain in case of attack. However,
it might be possible to construct an alert system that notifies
non-upgraded nodes of an upcoming rule change.
All blocks are still valid, so this is not a hardforking change.
The heaviest chain definition changes from sum of difficulty to sum of:
mainDifficulty ^ x * auxDifficulty ^ y 
where we start at:
x = 1; y = 0 
and end at values of x and y that are related to the target relative
rewards. For example, if the target rewards
are equally distributed, we will want ot end up at:
x = 1/2; y = 1/2 
so that both POWs have equal weight. If the aux POW is to become dominant,
x should end small relative to y.

Questions and Answers

weight? A: 1/2 of the reward should be transferred
to aux miners and x = 1/2, y = 1/2.
most of the reward should be transferred to
aux miners and x = 0, y = 1. The main difficulty will tend to zero, and
aux miners will just trivially generate the
main block immediately after finding an aux block, with identical content.
optimized by skipping transactions already
transferred.
would agree if they believe that
the coins will increase in value due to improved security properties.

Open Questions

become idle while a block of the other type is being mined. In practice,
the spare capacity can be used to find alternative ("attacking") blocks or
mine other coins. Is that a problem?
types of hardware?

POW candidates

confirmation)

Next Steps

detrimental behavior patterns (e.g. block withholding / selfish mining)

Credits

Bram Cohen came up with a similar idea back in March:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013744.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171101/9dc7ba4e/attachment.html
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Novembe015236.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

BitPay Wallet FAQ - YouTube Secrete Tips How to confirm your unconfirmed bitcoin transaction (Hindi) Ce sunt ALTcoin-uri? Si ce sunt ICO-uri? Initial Coin Offering Bitcoin 2019 - YouTube Blockchain Websocket API - JavaScript

Blockchain.com is the most popular place to securely buy, store, and trade Bitcoin, Ethereum, and other top cryptocurrencies. Wallet; Exchange; Explorer; Log In Sign Up. The World's Most Popular Way to Buy, Hold, and Use Crypto. Trusted by 51M Wallets - with Over $620 Billion in Transactions - Since 2013 . Get Started. The Easiest and Most Powerful Crypto Wallet. Create A Wallet Learn More ... The token economy has gained significant momentum. As of today, an ecosystem of more than 5,100 publicly traded crypto tokens and over 245,000 Ethereum token contracts has emerged. However, due to… Bitcoin Evolution does not gain or lose profits based on your trading results and operates as a technology, marketing and advertising service. Bitcoin Evolution does not operate as a financial services firm and is only used as a marketing tool by third party advertisers and brokers to receive more customers. When you signup to Bitcoin Evolution ... ABNS - The ANNE Bitcoin Name System. Documentation . Search the docs. Introduction. The ABNS uses ANNE to create unique human-readable ANNdles that serve as keywords, url shorteners, email lookups, payment addresses and more! Protocol Specs. In ANNE, every concept is its own neuron with its own unique identifier (a BSV address). Thus, every class has its own specs. Resources. There are a few ... Buying crypto like Bitcoin and Ether is as easy as verifying your identity, adding a payment and clicking "Buy". Sign up for our Wallet today. Create Wallet. Trade Crypto at the Exchange. Integrated with the Blockchain Wallet, our Exchange is a one-stop shop where you can deposit funds and place trades seamlessly in minutes. Get Started . Dive Deeper. Buy Crypto. Bitcoin $ USD. Your Email ...

[index] [33063] [40175] [47688] [10690] [10877] [50496] [22633] [3840] [25873] [6024]

BitPay Wallet FAQ - YouTube

ALTcoin este un termen care defineste monedele alternative. Este vorba despre alte monede bazate pe acelasi protocol ca si Bitcoin, open-source, care pot avea insa funtionalitati diferite. Bitcoin Law Review - Ripple vs YouTube, EOS Class Action, G20 vs StableCoins & More Tone Vays 438 watching Live now How I held my breath for 17 minutes David Blaine - Duration: 20:19. Bitcoin 2019: In Review: Protocol Improvement Outlooks by Bitcoin Magazine. 27:58. Play next; Play now; Bitcoin 2019: Scaling to the Masses by Bitcoin Magazine. 32:05. Play next; Play now; Bitcoin ... Speakers: Dino Farinacci, Cisco Systems David Meyer, Cisco Systems/University of Oregon This tutorial introduces the Locator/ID Separation Protocol (LISP). After providing a survey of Loc/ID split ... Identifiers such as your name, phone number, and address, ... A Referrer URL (Uniform Resource Locator) is information transmitted to a destination webpage by a web browser, typically when you click a link to that page. The Referrer URL contains the URL of the last webpage the browser visited. Sensitive personal information. This is a particular category of personal information relating to ...

#