Bits to Bytes Conversion

Mainnet project: an important change. If you are a donor, please read.

Hi everybody.
It has been one week since the mainnet project got the funding and I have an important update to make.
A little bit about the progress: I've found a wonderful developer, who is helping with the library, so it is starting to take some shape. I'm ironing out our REST API, got some useful feedback, continuing to do so. About 0.17% of the total funding spent so far.
The important update though is that I have decided to take the development and spending private, instead of public. Before I explain what that means and why, I understand that it might upset some donors. So, if you have pledged any amount and disagree with my change for any reason - please contact me (DM, or [email protected]) and I'll refund your pledge completely, no questions asked.
(Please sign any message using the address that you used to prove that you sent the funds, see the list of donors here to find your pledge and the link the the funding donation to find which address you sent from).
If more than 50% of pledges ask for money back, I'll just return everything to everybody in full and we'll consider the project cancelled. At that point anyone willing to take on the project (via a new Flipstarter or something), I'll donate the domain to them. Everything that is done so far is MIT licensed, so anyone is free to take it at any moment.
Let the market decide!
I've got to tell you that I'm a bit disappointed with our progress so far. I expected a lot of people willing to earn some money, but I've got only 4 relevant developers, 3 of them passed a very simple test, only one is actually doing anything.
This was not expected by me, when I had promised to work publicly and with BCH developers.
Another problem is that I have a certain vision that I described in the project description. In addition to that vision there is also a lot of experience talking to read.cash users. A lot of them are in countries with very bad Internet (2G, few kilobytes per second), using very old Android phones (10+ years, the size of an iPhone 4 and the speed half of that of iPhone 4).. And I also really hope that someday we will have 100MB blocks, 1GB, 1TB blocks. But now I'm tied in arguments with BCH developers who argue that many current solutions are good enough already and we don't need to change them - just build on top of a few convoluted and complex protocols, just download a block when needed (again, Africa, 2G, 100MB blocks), just download 640,000 block headers, listen to the whole mempool (with 1TB block we'll have 1TB mempool) - it's fine, blocks are tiny... Just send a few queries (now)... Just download a mempool fully.
(To those of you that know what this is about, please don't name names, I'm not here to play the blame game, everybody is entitled to their own opinions. It's fine.)
If your wallet becomes too big - create a new one. It's fine.
Sidenote: my read.cash wallet that gets the fees takes a few hours to open now, and it's barely 9 months old! I find current solutions unacceptable, I want my wallet to open up immediately and handle 100MB blocks as well as 60KB blocks.
I don't want to develop for tiny blocks or tiny wallets that need to be changed every few months.. I want huge blocks! I don't want mainnet to be as brittle as to break at the first sight of success.
A few of these discussions got me really tired and I have no leverage on these guys. They have money now, they have their vision, I have mine, described on the site, they don't want to do it my way. I didn't collect the funds to do it their way.
Yet I have made a commitment to work with them.
This is very tiresome. I feel like I've got myself into a trap - I have to work with these people, they don't want to work on my stuff.
This is just stupid.
One more thing is that now that I have Slack - I'm caught in endless private discussions of people trying to sell me their vision of how stuff should be done or questions about me or read.cash... I didn't sign up for that, I barely have any time to do the work, I don't have time for this, sorry.
Change #1: Private development
Having said that, I'm moving the project to private development.
Frankly, all I care about is to get this project done. I added an additional burden on myself to be do the public development. And it's tiresome.
The plan would be to hire some outside developers, using regular contracts, so that they don't have THEIR ideas on how to do the project and they'll just do what I described.
I think everybody cares about the end result - library working, document being written, etc...
Change #2: Private spending
Hired developers also means salaries. When people (in the real world) know salaries of other people, it leads to conflicts. I went through this experiment (public salaries) once in my life, I won't go through that again. Even people knowing your budget become a problem, since they start to bargain with you. (Again, we're talking about outside developers, they are not interested in BCH success, they are interested in getting as much money as possible)
By private spending I mean that I'll post periodically how much is done and how much funds is approximately left, but no details on who got what for what. Right now there's 99.83% funds left.
Some of you might see it as a money grab or something else - I can't blame you, but I'd rather see this project cancelled by market forces than drown in endless fights about why we should do exactly nothing or their idea, hope for small blocks and use what we have no matter how convoluted or hard it is, or why somebody's hourly rate should be bigger than that guy's.
Will this lead to everyone cancelling their donations? It sure could! It's voluntary funding after all, I can't force anyone to love what I do or how I do it.
If you donated and want a refund to your original address - just ping me.
When this post is 48 hours old, if more than 50% pledges remain, the project will move on as described above. If 50%+ cancels - everybody gets refunds to their original addresses.
submitted by readcash to btc [link] [comments]

Preventing double-spends is an "embarrassingly parallel" massive search problem - like Google, [email protected], [email protected], or PrimeGrid. BUIP024 "address sharding" is similar to Google's MapReduce & Berkeley's BOINC grid computing - "divide-and-conquer" providing unlimited on-chain scaling for Bitcoin.

TL;DR: Like all other successful projects involving "embarrassingly parallel" search problems in massive search spaces, Bitcoin can and should - and inevitably will - move to a distributed computing paradigm based on successful "sharding" architectures such as Google Search (based on Google's MapReduce algorithm), or [email protected], [email protected], or PrimeGrid (based on Berkeley's BOINC grid computing architecture) - which use simple mathematical "decompose" and "recompose" operations to break big problems into tiny pieces, providing virtually unlimited scaling (plus fault tolerance) at the logical / software level, on top of possibly severely limited (and faulty) resources at the physical / hardware level.
The discredited "heavy" (and over-complicated) design philosophy of centralized "legacy" dev teams such as Core / Blockstream (requiring every single node to download, store and verify the massively growing blockchain, and pinning their hopes on non-existent off-chain vaporware such as the so-called "Lightning Network" which has no mathematical definition and is missing crucial components such as decentralized routing) is doomed to failure, and will be out-competed by simpler on-chain "lightweight" distributed approaches such as distributed trustless Merkle trees or BUIP024's "Address Sharding" emerging from independent devs such as u/thezerg1 (involved with Bitcoin Unlimited).
No one in their right mind would expect Google's vast search engine to fit entirely on a Raspberry Pi behind a crappy Internet connection - and no one in their right mind should expect Bitcoin's vast financial network to fit entirely on a Raspberry Pi behind a crappy Internet connection either.
Any "normal" (ie, competent) company with $76 million to spend could provide virtually unlimited on-chain scaling for Bitcoin in a matter of months - simply by working with devs who would just go ahead and apply the existing obvious mature successful tried-and-true "recipes" for solving "embarrassingly parallel" search problems in massive search spaces, based on standard DISTRIBUTED COMPUTING approaches like Google Search (based on Google's MapReduce algorithm), or [email protected], [email protected], or PrimeGrid (based on Berkeley's BOINC grid computing architecture). The fact that Blockstream / Core devs refuse to consider any standard DISTRIBUTED COMPUTING approaches just proves that they're "embarrassingly stupid" - and the only way Bitcoin will succeed is by routing around their damage.
Proven, mature sharding architectures like the ones powering Google Search, [email protected], [email protected], or PrimeGrid will allow Bitcoin to achieve virtually unlimited on-chain scaling, with minimal disruption to the existing Bitcoin network topology and mining and wallet software.
Longer Summary:
People who argue that "Bitcoin can't scale" - because it involves major physical / hardware requirements (lots of processing power, upload bandwidth, storage space) - are at best simply misinformed or incompetent - or at worst outright lying to you.
Bitcoin mainly involves searching the blockchain to prevent double-spends - and so it is similar to many other projects involving "embarrassingly parallel" searching in massive search spaces - like Google Search, [email protected], [email protected], or PrimeGrid.
But there's a big difference between those long-running wildly successful massively distributed infinitely scalable parallel computing projects, and Bitcoin.
Those other projects do their data storage and processing across a distributed network. But Bitcoin (under the misguided "leadership" of Core / Blockstream devs) instists on a fatally flawed design philosophy where every individual node must be able to download, store and verify the system's entire data structure. And it's even wore than that - they want to let the least powerful nodes in the system dictate the resource requirements for everyone else.
Meanwhile, those other projects are all based on some kind of "distributed computing" involving "sharding". They achieve massive scaling by adding a virtually unlimited (and fault-tolerant) logical / software layer on top of the underlying resource-constrained / limited physical / hardware layer - using approaches like Google's MapReduce algorithm or Berkeley's Open Infrastructure for Network Computing (BOINC) grid computing architecture.
This shows that it is a fundamental error to continue insisting on viewing an individual Bitcoin "node" as the fundamental "unit" of the Bitcoin network. Coordinated distributed pools already exist for mining the blockchain - and eventually coordinated distributed trustless architectures will also exist for verifying and querying it. Any architecture or design philosophy where a single "node" is expected to be forever responsible for storing or verifying the entire blockchain is the wrong approach, and is doomed to failure.
The most well-known example of this doomed approach is Blockstream / Core's "roadmap" - which is based on two disastrously erroneous design requirements:
  • Core / Blockstream erroneously insist that the entire blockchain must always be downloadable, storable and verifiable on a single node, as dictated by the least powerful nodes in the system (eg, u/bitusher in Costa Rica), or u/Luke-Jr in the underserved backwoods of Florida); and
  • Core / Blockstream support convoluted, incomplete off-chain scaling approaches such as the so-called "Lightning Network" - which lacks a mathematical foundation, and also has some serious gaps (eg, no solution for decentralized routing).
Instead, the future of Bitcoin will inevitably be based on unlimited on-chain scaling, where all of Bitcoin's existing algorithms and data structures and networking are essentially preserved unchanged / as-is - but they are distributed at the logical / software level using sharding approaches such as u/thezerg1's BUIP024 or distributed trustless Merkle trees.
These kinds of sharding architectures will allow individual nodes to use a minimum of physical resources to access a maximum of logical storage and processing resources across a distributed network with virtually unlimited on-chain scaling - where every node will be able to use and verify the entire blockchain without having to download and store the whole thing - just like Google Search, [email protected], [email protected], or PrimeGrid and other successful distributed sharding-based projects have already been successfully doing for years.
Details:
Sharding, which has been so successful in many other areas, is a topic that keeps resurfacing in various shapes and forms among independent Bitcoin developers.
The highly successful track record of sharding architectures on other projects involving "embarrassingly parallel" massive search problems (harnessing resource-constrained machines at the physical level into a distributed network at the logical level, in order to provide fault tolerance and virtually unlimited scaling searching for web pages, interstellar radio signals, protein sequences, or prime numbers in massive search spaces up to hundreds of terabytes in size) provides convincing evidence that sharding architectures will also work for Bitcoin (which also requires virtually unlimited on-chain scaling, searching the ever-expanding blockchain for previous "spends" from an existing address, before appending a new transaction from this address to the blockchain).
Below are some links involving proposals for sharding Bitcoin, plus more discussion and related examples.
BUIP024: Extension Blocks with Address Sharding
https://np.reddit.com/btc/comments/54afm7/buip024_extension_blocks_with_address_sharding/
Why aren't we as a community talking about Sharding as a scaling solution?
https://np.reddit.com/Bitcoin/comments/3u1m36/why_arent_we_as_a_community_talking_about/
(There are some detailed, partially encouraging comments from u/petertodd in that thread.)
[Brainstorming] Could Bitcoin ever scale like BitTorrent, using something like "mempool sharding"?
https://np.reddit.com/btc/comments/3v070a/brainstorming_could_bitcoin_ever_scale_like/
[Brainstorming] "Let's Fork Smarter, Not Harder"? Can we find some natural way(s) of making the scaling problem "embarrassingly parallel", perhaps introducing some hierarchical (tree) structures or some natural "sharding" at the level of the network and/or the mempool and/or the blockchain?
https://np.reddit.com/btc/comments/3wtwa7/brainstorming_lets_fork_smarter_not_harder_can_we/
"Braiding the Blockchain" (32 min + Q&A): We can't remove all sources of latency. We can redesign the "chain" to tolerate multiple simultaneous writers. Let miners mine and validate at the same time. Ideal block time / size / difficulty can become emergent per-node properties of the network topology
https://np.reddit.com/btc/comments/4su1gf/braiding_the_blockchain_32_min_qa_we_cant_remove/
Some kind of sharding - perhaps based on address sharding as in BUIP024, or based on distributed trustless Merkle trees as proposed earlier by u/thezerg1 - is very likely to turn out to be the simplest, and safest approach towards massive on-chain scaling.
A thought experiment showing that we already have most of the ingredients for a kind of simplistic "instant sharding"
A simplistic thought experiment can be used to illustrate how easy it could be to do sharding - with almost no changes to the existing Bitcoin system.
Recall that Bitcoin addresses and keys are composed from an alphabet of 58 characters. So, in this simplified thought experiment, we will outline a way to add a kind of "instant sharding" within the existing system - by using the last character of each address in order to assign that address to one of 58 shards.
(Maybe you can already see where this is going...)
Similar to vanity address generation, a user who wants to receive Bitcoins would be required to generate 58 different receiving addresses (each ending with a different character) - and, similarly, miners could be required to pick one of the 58 shards to mine on.
Then, when a user wanted to send money, they would have to look at the last character of their "send from" address - and also select a "send to" address ending in the same character - and presto! we already have a kind of simplistic "instant sharding". (And note that this part of the thought experiment would require only the "softest" kind of soft fork: indeed, we haven't changed any of the code at all, but instead we simply adopted a new convention by agreement, while using the existing code.)
Of course, this simplistic "instant sharding" example would still need a few more features in order to be complete - but they'd all be fairly straightforward to provide:
  • A transaction can actually send from multiple addresses, to multiple addresses - so the approach of simply looking at the final character of a single (receive) address would not be enough to instantly assign a transaction to a particular shard. But a slightly more sophisticated decision criterion could easily be developed - and computed using code - to assign every transaction to a particular shard, based on the "from" and "to" addresses in the transaction. The basic concept from the "simplistic" example would remain the same, sharding the network based on some characteristic of transactions.
  • If we had 58 shards, then the mining reward would have to be decreased to 1/58 of what it currently is - and also the mining hash power on each of the shards would end up being roughly 1/58 of what it is now. In general, many people might agree that decreased mining rewards would actually be a good thing (spreading out mining rewards among more people, instead of the current problems where mining is done by about 8 entities). Also, network hashing power has been growing insanely for years, so we probably have way more than enough needed to secure the network - after all, Bitcoin was secure back when network hash power was 1/58 of what it is now.
  • This simplistic example does not handle cases where you need to do "cross-shard" transactions. But it should be feasible to implement such a thing. The various proposals from u/thezerg1 such as BUIP024 do deal with "cross-shard" transactions.
(Also, the fact that a simplified address-based sharding mechanics can be outlined in just a few paragraphs as shown here suggests that this might be "simple and understandable enough to actually work" - unlike something such as the so-called "Lightning Network", which is actually just a catchy-sounding name with no clearly defined mechanics or mathematics behind it.)
Addresses are plentiful, and can be generated locally, and you can generate addresses satisfying a certain pattern (eg ending in a certain character) the same way people can already generate vanity addresses. So imposing a "convention" where the "send" and "receive" address would have to end in the same character (and where the miner has to only mine transactions in that shard) - would be easy to understand and do.
Similarly, the earlier solution proposed by u/thezerg1, involving distributed trustless Merkle trees, is easy to understand: you'd just be distributing the Merkle tree across multiple nodes, while still preserving its immutablity guarantees.
Such approaches don't really change much about the actual system itself. They preserve the existing system, and just split its data structures into multiple pieces, distributed across the network. As long as we have the appropriate operators for decomposing and recomposing the pieces, then everything should work the same - but more efficiently, with unlimited on-chain scaling, and much lower resource requirements.
The examples below show how these kinds of "sharding" approaches have already been implemented successfully in many other systems.
Massive search is already efficiently performed with virtually unlimited scaling using divide-and-conquer / decompose-and-recompose approaches such as MapReduce and BOINC.
Every time you do a Google search, you're using Google's MapReduce algorithm to solve an embarrassingly parallel problem.
And distributed computing grids using the Berkeley Open Infrastructure for Network Computing (BOINC) are constantly setting new records searching for protein combinations, prime numbers, or radio signals from possible intelligent life in the universe.
We all use Google to search hundreds of terabytes of data on the web and get results in a fraction of a second - using cheap "commodity boxes" on the server side, and possibly using limited bandwidth on the client side - with fault tolerance to handle crashing servers and dropped connections.
Other examples are [email protected], [email protected] and PrimeGrid - involving searching massive search spaces for protein sequences, interstellar radio signals, or prime numbers hundreds of thousands of digits long. Each of these examples uses sharding to decompose a giant search space into smaller sub-spaces which are searched separately in parallel and then the resulting (sub-)solutions are recomposed to provide the overall search results.
It seems obvious to apply this tactic to Bitcoin - searching the blockchain for existing transactions involving a "send" from an address, before appending a new "send" transaction from that address to the blockchain.
Some people might object that those systems are different from Bitcoin.
But we should remember that preventing double-spends (the main thing that the Bitcoin does) is, after all, an embarrassingly parallel massive search problem - and all of these other systems also involve embarrassingly parallel massive search problems.
The mathematics of Google's MapReduce and Berkeley's BOINC is simple, elegant, powerful - and provably correct.
Google's MapReduce and Berkeley's BOINC have demonstrated that in order to provide massive scaling for efficient searching of massive search spaces, all you need is...
  • an appropriate "decompose" operation,
  • an appropriate "recompose" operation,
  • the necessary coordination mechanisms
...in order to distribute a single problem across multiple, cheap, fault-tolerant processors.
This allows you to decompose the problem into tiny sub-problems, solving each sub-problem to provide a sub-solution, and then recompose the sub-solutions into the overall solution - gaining virtually unlimited scaling and massive efficiency.
The only "hard" part involves analyzing the search space in order to select the appropriate DECOMPOSE and RECOMPOSE operations which guarantee that recomposing the "sub-solutions" obtained by decomposing the original problem is equivalent to the solving the original problem. This essential property could be expressed in "pseudo-code" as follows:
  • (DECOMPOSE ; SUB-SOLVE ; RECOMPOSE) = (SOLVE)
Selecting the appropriate DECOMPOSE and RECOMPOSE operations (and implementing the inter-machine communication coordination) can be somewhat challenging, but it's certainly doable.
In fact, as mentioned already, these things have already been done in many distributed computing systems. So there's hardly any "original work to be done in this case. All we need to focus on now is translating the existing single-processor architecture of Bitcoin to a distributed architecture, adopting the mature, proven, efficient "recipes" provided by the many examples of successful distributed systems already up and running like such as Google Search (based on Google's MapReduce algorithm), or [email protected], [email protected], or PrimeGrid (based on Berkeley's BOINC grid computing architecture).
That's what any "competent" company with $76 million to spend would have done already - simply work with some devs who know how to implement open-source distributed systems, and focus on adapting Bitcoin's particular data structures (merkle trees, hashed chains) to a distributed environment. That's a realistic roadmap that any team of decent programmers with distributed computing experience could easily implement in a few months, and any decent managers could easily manage and roll out on a pre-determined schedule - instead of all these broken promises and missed deadlines and non-existent vaporware and pathetic excuses we've been getting from the incompetent losers and frauds involved with Core / Blockstream.
ASIDE: MapReduce and BOINC are based on math - but the so-called "Lightning Network" is based on wishful thinking involving kludges on top of workarounds on top of hacks - which is how you can tell that LN will never work.
Once you have succeeded in selecting the appropriate mathematical DECOMPOSE and RECOMPOSE operations, you get simple massive scaling - and it's also simple for anyone to verify that these operations are correct - often in about a half-page of math and code.
An example of this kind of elegance and brevity (and provable correctness) involving compositionality can be seen in this YouTube clip by the accomplished mathematician Lucius Greg Meredith presenting some operators for scaling Ethereum - in just a half page of code:
https://youtu.be/uzahKc_ukfM?t=1101
Conversely, if you fail to select the appropriate mathematical DECOMPOSE and RECOMPOSE operations, then you end up with a convoluted mess of wishful thinking - like the "whitepaper" for the so-called "Lightning Network", which is just a cool-sounding name with no actual mathematics behind it.
The LN "whitepaper" is an amateurish, non-mathematical meandering mishmash of 60 pages of "Alice sends Bob" examples involving hacks on top of workarounds on top of kludges - also containing a fatal flaw (a lack of any proposed solution for doing decentralized routing).
The disaster of the so-called "Lightning Network" - involving adding never-ending kludges on top of hacks on top of workarounds (plus all kinds of "timing" dependencies) - is reminiscent of the "epicycles" which were desperately added in a last-ditch attempt to make Ptolemy's "geocentric" system work - based on the incorrect assumption that the Sun revolved around the Earth.
This is how you can tell that the approach of the so-called "Lightning Network" is simply wrong, and it would never work - because it fails to provide appropriate (and simple, and provably correct) mathematical DECOMPOSE and RECOMPOSE operations in less than a single page of math and code.
Meanwhile, sharding approaches based on a DECOMPOSE and RECOMPOSE operation are simple and elegant - and "functional" (ie, they don't involve "procedural" timing dependencies like keeping your node running all the time, or closing out your channel before a certain deadline).
Bitcoin only has 6,000 nodes - but the leading sharding-based projects have over 100,000 nodes, with no financial incentives.
Many of these sharding-based projects have many more nodes than the Bitcoin network.
The Bitcoin network currently has about 6,000 nodes - even though there are financial incentives for running a node (ie, verifying your own Bitcoin balance.
[email protected] and [email protected] each have over 100,000 active users - even though these projects don't provide any financial incentives. This higher number of users might be due in part the the low resource demands required in these BOINC-based projects, which all are based on sharding the data set.
[email protected]
As part of the client-server network architecture, the volunteered machines each receive pieces of a simulation (work units), complete them, and return them to the project's database servers, where the units are compiled into an overall simulation.
In 2007, Guinness World Records recognized [email protected] as the most powerful distributed computing network. As of September 30, 2014, the project has 107,708 active CPU cores and 63,977 active GPUs for a total of 40.190 x86 petaFLOPS (19.282 native petaFLOPS). At the same time, the combined efforts of all distributed computing projects under BOINC totals 7.924 petaFLOPS.
[email protected]
Using distributed computing, [email protected] sends the millions of chunks of data to be analyzed off-site by home computers, and then have those computers report the results. Thus what appears an onerous problem in data analysis is reduced to a reasonable one by aid from a large, Internet-based community of borrowed computer resources.
Observational data are recorded on 2-terabyte SATA hard disk drives at the Arecibo Observatory in Puerto Rico, each holding about 2.5 days of observations, which are then sent to Berkeley. Arecibo does not have a broadband Internet connection, so data must go by postal mail to Berkeley. Once there, it is divided in both time and frequency domains work units of 107 seconds of data, or approximately 0.35 megabytes (350 kilobytes or 350,000 bytes), which overlap in time but not in frequency. These work units are then sent from the [email protected] server over the Internet to personal computers around the world to analyze.
Data is merged into a database using [email protected] computers in Berkeley.
The [email protected] distributed computing software runs either as a screensaver or continuously while a user works, making use of processor time that would otherwise be unused.
Active users: 121,780 (January 2015)
PrimeGrid
PrimeGrid is a distributed computing project for searching for prime numbers of world-record size. It makes use of the Berkeley Open Infrastructure for Network Computing (BOINC) platform.
Active users 8,382 (March 2016)
MapReduce
A MapReduce program is composed of a Map() procedure (method) that performs filtering and sorting (such as sorting students by first name into queues, one queue for each name) and a Reduce() method that performs a summary operation (such as counting the number of students in each queue, yielding name frequencies).
How can we go about developing sharding approaches for Bitcoin?
We have to identify a part of the problem which is in some sense "invariant" or "unchanged" under the operations of DECOMPOSE and RECOMPOSE - and we also have to develop a coordination mechanism which orchestrates the DECOMPOSE and RECOMPOSE operations among the machines.
The simplistic thought experiment above outlined an "instant sharding" approach where we would agree upon a convention where the "send" and "receive" address would have to end in the same character - instantly providing a starting point illustrating some of the mechanics of an actual sharding solution.
BUIP024 involves address sharding and deals with the additional features needed for a complete solution - such as cross-shard transactions.
And distributed trustless Merkle trees would involve storing Merkle trees across a distributed network - which would provide the same guarantees of immutability, while drastically reducing storage requirements.
So how can we apply ideas like MapReduce and BOINC to providing massive on-chain scaling for Bitcoin?
First we have to examine the structure of the problem that we're trying to solve - and we have to try to identify how the problem involves a massive search space which can be decomposed and recomposed.
In the case of Bitcoin, the problem involves:
  • sequentializing (serializing) APPEND operations to a blockchain data structure
  • in such a way as to avoid double-spends
Can we view "preventing Bitcoin double-spends" as a "massive search space problem"?
Yes we can!
Just like Google efficiently searches hundreds of terabytes of web pages for a particular phrase (and [email protected], [email protected], PrimeGrid etc. efficiently search massive search spaces for other patterns), in the case of "preventing Bitcoin double-spends", all we're actually doing is searching a massive seach space (the blockchain) in order to detect a previous "spend" of the same coin(s).
So, let's imagine how a possible future sharding-based architecture of Bitcoin might look.
We can observe that, in all cases of successful sharding solutions involving searching massive search spaces, the entire data structure is never stored / searched on a single machine.
Instead, the DECOMPOSE and RECOMPOSE operations (and the coordination mechanism) a "virtual" layer or grid across multiple machines - allowing the data structure to be distributed across all of them, and allowing users to search across all of them.
This suggests that requiring everyone to store 80 Gigabytes (and growing) of blockchain on their own individual machine should no longer be a long-term design goal for Bitcoin.
Instead, in a sharding environment, the DECOMPOSE and RECOMPOSE operations (and the coordination mechanism) should allow everyone to only store a portion of the blockchain on their machine - while also allowing anyone to search the entire blockchain across everyone's machines.
This might involve something like BUIP024's "address sharding" - or it could involve something like distributed trustless Merkle trees.
In either case, it's easy to see that the basic data structures of the system would remain conceptually unaltered - but in the sharding approaches, these structures would be logically distributed across multiple physical devices, in order to provide virtually unlimited scaling while dramatically reducing resource requirements.
This would be the most "conservative" approach to scaling Bitcoin: leaving the data structures of the system conceptually the same - and just spreading them out more, by adding the appropriately defined mathematical DECOMPOSE and RECOMPOSE operators (used in successful sharding approaches), which can be easily proven to preserve the same properties as the original system.
Conclusion
Bitcoin isn't the only project in the world which is permissionless and distributed.
Other projects (BOINC-based permisionless decentralized [email protected], [email protected], and PrimeGrid - as well as Google's (permissioned centralized) MapReduce-based search engine) have already achieved unlimited scaling by providing simple mathematical DECOMPOSE and RECOMPOSE operations (and coordination mechanisms) to break big problems into smaller pieces - without changing the properties of the problems or solutions. This provides massive scaling while dramatically reducing resource requirements - with several projects attracting over 100,000 nodes, much more than Bitcoin's mere 6,000 nodes - without even offering any of Bitcoin's financial incentives.
Although certain "legacy" Bitcoin development teams such as Blockstream / Core have been neglecting sharding-based scaling approaches to massive on-chain scaling (perhaps because their business models are based on misguided off-chain scaling approaches involving radical changes to Bitcoin's current successful network architecture, or even perhaps because their owners such as AXA and PwC don't want a counterparty-free new asset class to succeed and destroy their debt-based fiat wealth), emerging proposals from independent developers suggest that on-chain scaling for Bitcoin will be based on proven sharding architectures such as MapReduce and BOINC - and so we should pay more attention to these innovative, independent developers who are pursuing this important and promising line of research into providing sharding solutions for virtually unlimited on-chain Bitcoin scaling.
submitted by ydtm to btc [link] [comments]

Interested in contributing to the BTC network? Here is the steps to get a full node up and running in Linux.

These instructions will work both on a VPS cloud server or a personal computer. You may find cheap VPS somewhere online for rent.
What Is A Full Node?
A full node is a program that fully validates transactions and blocks. Almost all full nodes also help the network by accepting transactions and blocks from other full nodes, validating those transactions and blocks, and then relaying them to further full nodes.
Most full nodes also serve lightweight clients by allowing them to transmit their transactions to the network and by notifying them when a transaction affects their wallet. If not enough nodes perform this function, clients won’t be able to connect through the peer-to-peer network—they’ll have to use centralized services instead.
Many people and organizations volunteer to run full nodes using spare computing and bandwidth resources—but more volunteers are needed to allow Bitcoin to continue to grow. This document describes how you can help and what helping will cost you.
Costs And Warnings
Running a Bitcoin full node comes with certain costs and can expose you to certain risks. This section will explain those costs and risks so you can decide whether you’re able to help the network.
Special Cases
Miners, businesses, and privacy-conscious users rely on particular behavior from the full nodes they use, so they will often run their own full nodes and take special safety precautions. This document does not cover those precautions—it only describes running a full node to help support the Bitcoin network in general.
Please consult an expert if you need help setting up your full node correctly to handle high-value and privacy-sensitive tasks.
Secure Your Wallet
It’s possible and safe to run a full node to support the network and use its wallet to store your bitcoins, but you must take the same precautions you would when using any Bitcoin wallet. Please see the securing your wallet page for more information.
Minimum Requirements
Bitcoin Core full nodes have certain requirements. If you try running a node on weak hardware, it may work—but you’ll likely spend more time dealing with issues. If you can meet the following requirements, you’ll have an easy-to-use node.
Note: many operating systems today (Windows, Mac, and Linux) enter a low-power mode after the screensaver activates, slowing or halting network traffic. This is often the default setting on laptops and on all Mac OS X laptops and desktops. Check your screensaver settings and disable automatic “sleep” or “suspend” options to ensure you support the network whenever your computer is running.
Possible Problems
Legal: Bitcoin use is prohibited or restricted in some areas.
Bandwidth limits: Some Internet plans will charge an additional amount for any excess upload bandwidth used that isn’t included in the plan. Worse, some providers may terminate your connection without warning because of overuse. We advise that you check whether your Internet connection is subjected to such limitations and monitor your bandwidth use so that you can stop Bitcoin Core before you reach your upload limit.
Anti-virus: Several people have placed parts of known computer viruses in the Bitcoin block chain. This block chain data can’t infect your computer, but some anti-virus programs quarantine the data anyway, making it more difficult to run a full node. This problem mostly affects computers running Windows.
Attack target: People who want to disrupt the Bitcoin network may attack full nodes in ways that will affect other things you do with your computer, such as an attack that limits your available download bandwidth or an attack that prevents you from using your full node’s wallet for sending transactions.
Linux Instructions
The following instructions describe installing Bitcoin Core on Linux systems.
Ubuntu 14.10 Instructions for Bitcoin Core 0.10.0.
If you use Ubuntu Desktop, click the Ubuntu swirl icon to start the Dash and type “term” into the input box. Choose any one of the terminals listed:
Alternatively, access a console or terminal emulator using another method, such as SSH on Ubuntu Server or a terminal launcher in an alternative desktop environment.
Type the following line to add the Bitcoin Personal Package Archive (PPA) to your system:
sudo apt-add-repository ppa:bitcoin/bitcoin
You will be prompted for your user password. Provide it to continue. Afterwards, the following text will be displayed:
Stable Channel of bitcoin-qt and bitcoind for Ubuntu, and their dependencies
More info: https://launchpad.net/~bitcoin/+archive/ubuntu/bitcoin
Press [ENTER] to continue or ctrl-c to cancel adding it
Press enter to continue. The following text (with some variations) will be displayed and you will be returned to the command line prompt:
gpg: keyring /tmp/tmpixuqu73x/secring.gpg' created gpg: keyring/tmp/tmpixuqu73x/pubring.gpg' created gpg: requesting key 8842CE5E from hkp server > > > >keyserver.ubuntu.com gpg: /tmp/tmpixuqu73x/trustdb.gpg: trustdb created gpg: key 8842CE5E: public key "Launchpad PPA for Bitcoin" imported gpg: no ultimately trusted keys found gpg: Total number processed: 1 pg: imported: 1 (RSA: 1) OK
Type the following line to get the most recent list of packages:
sudo apt-get update
A large number of lines will be displayed as different update files are downloaded. This step may take several minutes on a slow Internet connection.
To continue, choose one of the following options
sudo apt-get install bitcoin-qt
sudo apt-get install bitcoind
sudo apt-get install bitcoin-qt bitcoind
After choosing what packages to install, you will be asked whether you want to proceed. Press enter to continue.
If you’re logged in as an administrative user with sudo access, you may log out. The steps in this section should be performed as the user you want to run Bitcoin Core. (If you’re an expert administrator, you can make this a locked account used only by Bitcoin Core.)
Before using the Bitcoin Core daemon, bitcoind, you need to create its configuration file with a user name and password. First create the .bitcoin directory, create (touch) the file, and set the file’s permissions so that only your user account can read it. From the terminal, type:
mkdir ~/.bitcoin touch ~/.bitcoin/bitcoin.conf chmod 600 ~/.bitcoin/bitcoin.conf
Then you can run the command bitcoind. It will print output similar to this:
bitcoind Error: To use the "-server" option, you must set a rpcpassword in the configuration file: /home/bitcoinorg/.bitcoin/bitcoin.conf It is recommended you use the following random password: rpcuser=bitcoinrpc rpcpassword=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX (you do not need to remember this password)
The username and password MUST NOT be the same.
If the file does not exist, create it with owner-readable-only file permissions. It is also recommended to set alertnotify so you are notified of problems; for example: alertnotify=echo %s | mail -s "Bitcoin Alert" [email protected] The “rpcpassword” displayed will be unique for your system. You can copy the rpcuser and rpcpassword lines into your configuration file using the following commands. Note that in most Ubuntu terminals, you need to press Ctrl-Shift-C to copy and Ctrl-Shift-V to paste because Ctrl-C and Ctrl-V have different meanings in a Unix-style terminal.
echo rpcuser=bitcoinrpc >> ~/.bitcoin/bitcoin.conf echo rpcpassword=XXXXXX >> ~/.bitcoin/bitcoin.conf (Warning: Don’t use XXXXXX as your RPC password. Copy the rpcpassword displayed by bitcoind for your system.)
Now you can start Bitcoin Core daemon for real. Type the following command:
bitcoind -daemon
It will print a message that Bitcoin Core is starting. To interact with Bitcoin Core daemon, you will use the command bitcoin-cli (Bitcoin command line interface). Note: it may take up to several minutes for Bitcoin Core to start, during which it will display the following message whenever you use bitcoin-cli:
error: {"code":-28,"message":"Verifying blocks..."}
After it starts, you may find the following commands useful for basic interaction with your node:
to safely stop your node, run the following command:
bitcoin-cli stop
A complete list of commands is available in the Bitcoin.org developer reference.
When Bitcoin Core daemon first starts, it will begin to download the block chain. This step will take at least several hours, and it may take a day or more on a slow Internet connection or with a slow computer. During the download, Bitcoin Core will use a significant part of your connection bandwidth. You can stop Bitcoin Core at any time using the stop command; it will resume from the point where it stopped the next time you start it.
Optional: Start Your Node At Boot
Starting your node automatically each time your computer boots makes it easy for you to contribute to the network. The easiest way to do this is to start Bitcoin Core daemon from your crontab. To edit your crontab, run the following command:
crontab -e
@reboot bitcoind -daemon Save the file and exit; the updated crontab file will be installed for you. Now Bitcoin Core daemon will be automatically started each time your reboot your computer.
If you’re an Ubuntu expert and want to use an init script instead, see this Upstart script.
You have now completed installing Bitcoin Core. If you have any questions, please ask in one of Bitcoin’s many communities, such as Bitcoin StackExchange, BitcoinTalk technical support, or the #bitcoin IRC chatroom on Freenode.
To support the Bitcoin network, you also need to allow incoming connections. Please read the Network Configuration section for details.
Network Configuration
If you want to support the Bitcoin network, you must allow inbound connections.
When Bitcoin Core starts, it establishes 8 outbound connections to other full nodes so it can download the latest blocks and transactions. If you just want to use your full node as a wallet, you don’t need more than these 8 connections—but if you want to support lightweight clients and other full nodes on the network, you must allow inbound connections.
Servers connected directly to the Internet usually don’t require any special configuration. You can use the testing instructions below to confirm your server-based node accepts inbound connections.
Home connections are usually filtered by a router or modem. Bitcoin Core will request your router automatically configure itself to allow inbound connections to Bitcoin’s port, port 8333. Unfortunately many routers don’t allow automatic configuration, so you must manually configure your router. You may also need to configure your firewall to allow inbound connections to port 8333. Please see the following subsections for details.
Testing Connections
The BitNodes project provides an online tool to let you test whether your node accepts inbound connections. To use it, start Bitcoin Core (either the GUI or the daemon), wait 10 minutes, and then visit the GetAddr page (https://getaddr.bitnodes.io/). The tool will attempt to guess your IP address—if the address is wrong (or blank), you will need to enter your address manually.
For more instruction and reviews based off BTC please follow my subreddit /BTC_Reviews
all material from this post was found here --> https://bitcoin.org/en/full-node
submitted by Mattjhagen to Bitcoin [link] [comments]

FAQ For Newcomers

August 9th, 2014: With the amount of projects that have been in constant development, this FAQ is somewhat out of date. While information about fundamentals of the coin remains the same and can be found here, there is much that has changed since then. In the meanwhile, please see the projects list here for a taste of the enormous development efforts of the BlackCoin community, and feel free to follow the subreddit to keep on track with new updates:
http://www.reddit.com/blackcoin/comments/27lz3h/blackcoin_projects_overview/
I created this as an initial draft of a FAQ for newcomers, feel free to recommend additions, corrections, removals, or changes.
TL/DR version at the end for those short on time.

Sections: (Ctrl + F to jump)

What is BlackCoin? [A]
What separates BlackCoin from other cryptocurrencies? [B]
Why Proof of Stake? [C]
What other reasons are there to pick up some BlackCoin? [D]
How to obtain BlackCoin? [E]
Why BlackCoin instead of competing Proof of Stake coins? [F]
Where can I talk to others about BlackCoin? [G]
TL/DR Version: [H]

What is BlackCoin? [A]

BlackCoin is a cryptocurrency based on many of the ideas contained within the original Bitcoin protocol, but with a few very important changes. Being only a couple of months old, it is a relatively new currency, but has been experiencing rapid growth. It is already in the top 10 cryptocurrencies by market cap.

What separates BlackCoin from other cryptocurrencies? [B]

There are a few main advantages to BlackCoin that separate it from most other cryptocurrencies. To ensure a fair distribution of coins, BlackCoin was initially distributed through a Proof of Work phase, the same method that Bitcoin uses to generate coins and secure the network.
That period is now over, and BlackCoin has transitioned entirely to PoS, or Proof of Stake. This allows lightning fast confirmation times, which can average as fast as 10 seconds each. In comparison, bitcoin averages 10 minutes per confirmation and litecoin clocks in at 2.5 minutes. These faster confirmation times can provide an extraordinary advantage for merchant adoption, as well as greatly improving the user experience.

Why Proof of Stake? [C]

Proof of Work was a fantastic innovation that formed the backbone of the original Bitcoin protocol. The idea is that by solving a computationally intensive math problem, one can prove the effort they've done to secure the protocol. This is how a blockchain is generated, and the effort that is required to perform this computations contribute to a coin's scarcity and value.
However, proof of work eventually becomes an extraordinarily expensive system. To secure the bitcoin network at the current market value costs about $1.8 million dollars, every single day. Most of this money is leaving the system to pay for energy costs and specialized computer equipment, much of which is done by huge computer farms. Even worse, when the value of a bitcoin increases, so does this cost. The hypothetical "$10,000 bitcoin" would cost $13 billion per year to maintain. While some of this may be mitigated by a reward "halving" or two in 3-7 years time, decreasing this reward too substantially creates a potential security risk.
Proof of Stake solves this issue in a very elegant way. Rather than using computer power as a scarce resource to generate security, Proof of Stake uses the scarcity of the coin itself. A user may choose to "stake" his coins to generate the next block in the chain, and his chance of doing so is basically proportional to the weight of his own coins.
With Proof of Work, a user can attack a network if he holds 51% of the current computer power, but to do so with Proof of Stake, that user would need a large shares of the overall coins. Acquiring this number of coins would be very difficult and expensive, and such an individual would have little incentive to attack the network as this would hurt the value of his own coins. As such, a Proof of Stake system is secured through basic economic facts rather than mass computing power.
While this is still a very contentious issue, the superior environmental and economic efficients of Proof of Stake lead many here to believe that it could be the future of cryptocurrency.

What other reasons are there to pick up some BlackCoin? [D]

There are many interesting coins out there, but BlackCoin strives to be superior in all areas. The combination of Proof of Stake and fast transaction times allow BlackCoin to excel both as a long-term store of value and for day-to-day transactions, a rare combination. But the coin also has a strong community and a rapidly developing infrastructure.
The coin's original developer has continued to work on the coin and make sure new applications are secure, even going so far as to point out a potential vulnerability in a competing coin. There is a dedicated community manager and many others who have been helping BlackCoin to grow and thrive.
Further, there are many new and exciting projects going on with BlackCoin, and it can even be difficult to keep track of it all. The most famous of these projects is the Blackcoin mining pool (http://blackcoinpool.com/), which allows miners to group together to mine other Proof of Work coins and use the profits to purchase BlackCoin, allowing this value to be absorbed into the BlackCoin economy. But don't be confused - the coin wasn't built around the idea of the mining pool, it's just one of the many great community developments that have sprung up to support it.
There have been other major developments recently as well. BlackCoin was recently accepted to be part of CoinKite's point of sale system, a huge step which will make it easy for both physical and online merchants to accept BlackCoin. The Black Coin Card (www.blackcoincard.com) is another effort which will make it very simple for anyone to get started using BlackCoin. Even a press release was sent out today to spread the word about BlackCoin: http://www.prweb.com/releases/2014/04/prweb11772516.htm. The community brings more and more ideas each day to support and promote BlackCoin.

How to obtain BlackCoin? [E]

Just like any cryptocurrency at the moment, it can take a little effort to get started, but once you have some cryptocurrency to your name, it isn't too hard.
The best way at the moment to acquire BlackCoin would be to buy Bitcoin and send those to an exchange to convert to BlackCoin. BitStamp.net is one of the largest exchanges between USD and Bitcoin, while CoinBase is also an option for U.S. customers. Once you have bitcoin in your possession, you can convert them to BlackCoin pretty quickly. Just send them to an exchange like MintPal and you can buy them at the present market rate.
Unfortunately, it can be a bit slow to get Bitcoin with the above method, but it's probably the best. If you want greater speed, you could try localbitcoins.com or finding someone directly to trade with (perhaps another reddit user). However, you may pay a significant premium over the market rate this way (15%+) and have to be careful of scams.
For the miners out there, you can't mine BlackCoin directly, but you can join the BlackCoin pool which mines the most profitable coins and uses them to purchase BlackCoin. Another user made a video explaining how to get started here: http://www.reddit.com/blackcoin/comments/23dy88/a_video_on_how_to_get_set_up_for_new_members/ (But make sure you are pointed at the updated address, stratum+tcp://useast.blackcoinpool.com:3333 for scrypt as I write this, stratum+tcp://useast.blackcoinpool.com:4444 for SHA).

Why BlackCoin instead of competing Proof of Stake coins? [F]

Some way wonder why they should obtain BlackCoin when coins like NXT and Peercoin have been around longer. Of course, this is always up to an individual to decide, but I feel there are strong reasons to support BlackCoin instead.
I think PeerCoin was a great idea for a coin and was the original pioneer of the Proof of Stake/Proof of Work concept. It is still in a combination phase between the two, slowly transitioning to a pure proof of stake coin. But it is different in its goals from BlackCoin.
Peercoin was designed to be the sort of coin that you use as a store of value, but is also specifically designed not to be used for day to day transactions. It uses a slow transaction confirmation time of 10 minutes per block and a very high fixed fee rate for transactions at .01 PPC per kilobyte. It is intended to be more of a complementary coin to something like Bitcoin rather than a day to day currency.
NXT is another coin which is operating as completely Proof of Stake, but there are some important differences between the two coins. BlackCoin is currently about twice as fast as NXT in terms of average confirmation speed and was based on the original Bitcoin Protocol. In comparison, NXT was instead built on its own code base. This may allow some potential positive changes, but also means that NXT is more likely to introduce new bugs or exploits that were not a part of its tried-and-true predecessors.
But one of the biggest differences can be found in the initial coin distribution. BlackCoin was launched with a brief initial Proof of Work phase and no pre-mine. Although this phase is much shorter than the one implemented by Peercoin, it was announced a week in advance to give all miners and buyers an equal and fair opportunity to claim the coin. In contrast to this method, NXT was distributed based on Bitcoin payments to an account set up by the developer. The period for purchasing NXT was prematurely cut off 6 weeks early without any warning. See here for more information:
https://bitcointalk.org/index.php?topic=303898.msg3620944#msg3620944
Another important component of any cryptocurrency that truly cannot be understated is the community that supports, builds infrastructure for, and spreads awareness of the coin to increase both its utility and adoption rate. It is this very factor that I feel has played a major role in bringing Bitcoin to where it is today, with a multi-billion dollar market cap. While this is a largely subjective area, I feel that BlackCoin has one of the strongest communities, especially for a very young coin, with several new projects springing up every few days. Contrastingly, it appears that NXT has some schisms within the community as can be seen here, splitting into two different forums:
https://nextcoin.org/index.php/topic,4621.0.html
However, bear in mind that this is my own view on the situation as an outsider with limited involvement, and it is always best to do your own research if time permits.

Where can I talk to others about BlackCoin? [G]

There are a few places to talk about BlackCoin, news, and upcoming developments. First, where you are now, the reddit community has been growing very quickly:
http://www.reddit.com/blackcoin/ Make sure to check the sidebar for many more websites.
https://bitcointalk.org/index.php?topic=469640.0 This is the bitcointalk thread. This thread has historically had the most information of any forum, but it's quite a slog to read through. Worth checking up on if you don't want to miss anything though.
http://blackcointalk.com/ The "official" forums.

TL/DR Version: [H]

Blackcoin is a cryptocurrency. It's pretty new, but it's pretty great. It uses Proof of Stake, so it's efficient. It's also lightning fast. Bitcoin is slow and expensive to secure. Proof of Stake = the future. BlackCoin = the future. The community here is amazing. BlackCoinPool. BlackCoinCard. Press. Hype. CoinKite. New projects all the time. Don't get left in the dust. Blackcoin is the best in all areas. Speed, store of value, economics, efficiency, community, developers, got it all. Buy some.
submitted by asdffsdf to blackcoin [link] [comments]

Denomination Naming Shower Thought

Hi everyone,
I've been thinking about this for a while, and I wanted to share with everyone here and get their thoughts.
I feel like adoption for BCH could be improved to newcomers if we adopted a naming convention for amounts. We're all used to seeing 8 digit decimal values but they're really difficult to say or understand other than just a string of numbers. What if we did this?
0.00000001 => 1 Bit (1 Satoshi)
0.0000001 => 1 Byte
0.000001 => 1 Kilobyte
0.00001 => 1 Megabyte
0.0001 => 1 Gigabyte
0.001 => 1 Terabyte
0.01 => 1 Petabyte
0.1 => 1 Exabyte
1.0 => 1 Bitcoin
Look, I know this isn't right in a pure mathematical sense (not to mention it's base 10 instead of base 2), but are there any standard ways to describe the very long float values that are passed around? I like the idea of playing off the Bit in the Bitcoin name to adopt the standard byte names, but I'm a programmer so of course I like it ;-)
Some of this is a bit moot in the sense that so many payment options display fiat currency next to the digits so people understand the amounts better, but I feel like BCH deserves its own naming convention too just like USD has dollars, pennies, nickels, dimes, quarters, etc.
Like I said before, this is just a shower thought and may not be a great idea, but how do you feel about a naming standard for the decimal places? Any other ideas you have or have seen that maybe I just missed?
submitted by mikeytag to btc [link] [comments]

The Earth is a growing brain and we are the neurons that will power it. I can see it now.

I have had a stunning moment of clarity and I've got some good news and some bad news for you. The good news: if you get involved in cryptocurrency at this point in time, you will eventually be wealthy beyond your wildest dreams. The bad news? You are also about to live in an age where being wealthy will not mean the same thing it used to, and neither will luxury.
Cryptocurrency is necessary for more reasons than most can imagine. We are (whether we realize it or not) advancing a set of rules for how power and information will be directed on a global scale in the coming information revolution.
The future is one where we aren't worried about material things because our fundamental survival needs will be exceeded. As well, the toils of our physical labor will no longer be necessary in the coming robotics revolution. Most manual labor will become obsolete.
Then where do we go from here? The answer is not to extend our current trajectory outward towards what appears to be the logical next step. Instead we must take this trajectory in a direction that seems preposterous at the moment, but as with all advances in civilization will be obvious in retrospect.

Booting Up The Machine

Connectivity... energy... communications... think of the first tenuous strands of neural matter in a baby's brain wrapping together. Consider how as the child grows in the womb the network comes together and lights up with energy, firing randomly as it tests its own limits and explores all the ways in which it is connected.
Our species is doing the same thing!
Those first telegrams were the first 'lights' of our neural network firing off, sending tiny bits of data at long range for the first time. Before that our species was the equivalent of prokaryotes all swimming around selfishly, and forming tiny and specialized networks at best in the harsh soup of its existence.
But the hyper-expansion of global communications? This is something infinitely more powerful. This is the first fully formed global brain, and it will be capable of feats so many orders of magnitude from our current prokaryotic nature as to render a comparison impossible.
We are that brain, and we are the neurons that will power it. Right now we send pieces of data to each other on the order of kilobytes and megabytes, each of us connected to anywhere from ten to a thousand others. Some of us are more useful (or popular) nodes than others and have millions of connections. Some become dead weight and cull ourselves through isolation.
Imagine once our capabilities grow several orders of magnitude from this point. Yes, gigabit fiber is next but let's go further. Imagine having the technology to communicate at terabits or petabits per second and easily connecting to as many other "nodes" in the global brain as you have value to share. Now realize that most humans (nodes) aren't even performing anywhere near full capacity!
We've got billions of us that are not even wired up to this future global brain that have yet to come online! And even if there are small differences in our minds, every human brain added to this global super-brain makes us exponentially more powerful and productive.
What marvels will our civilization be able to produce once we aren't a scattered and disorganized petri-dish of prokaryotes anymore? Imagine directing our energies at a common goal instead of chomping at whatever local gunk we can get our hands on. Imagine transforming into an efficient super-network of intelligence which criss-crosses in a quadrillion different ways, each providing some small area of expertise to the whole.

Enter cryptocurrency

Every system needs rules. Every system needs a way to distribute resources and influence. And every system can't rely on infallible nodes within it to manage those systems.
Cryptocurrency (like bitcoin) will provide the backbone for how we as a global brain will distribute our efforts. You need to understand that once we enter this upcoming knowledge age the focus won't be on becoming the best prokaryote on the block anymore... no. Instead you will bask and revel in the accomplishments of the whole superorganism and your own happiness will be in direct proportion to its progress.
Guys, we're about to be born. Think about what that means. If the Earth in is current state is a fetus that is still putting together all the pieces of the infant it will one day become, just imagine when our global hive mind is capable of truly comprehending its environment for the first time. You can try to imagine the nature of our reality, but the fact is that we haven't even scratched the surface of what will be possible once this global network truly gets started.
Cryptocurrency is going to help ensure that useless nodes do not carry much influence in the super organism, and valuable nodes carry a lot. "Money" in this civilization 2.0 is going to be much more than just a debt ledger. In an age where luxury is freely available and all needs are met, money is going to be a vote towards the future of our civilization. Democracy and money will fuse into one common language!
The institutions of the prokaryotes aren't going to know what hit them. I haven't even begun to fathom how artificial intelligence, biological uploading/immortality, and potential energy revolutions are going to factor into this.
The future isn't going to just be amazing... it's going to be so mind boggling that if you really could 'peek' at the year 2115 your simple prokaryotic mind wouldn't even be able to register the scale of what civilization has become.
To borrow a metaphor from my favorite YouTube video about black holes (made possible by the tiny spark of a global brain we currently are using):
Gross potential of our civilization in 1915 at the dawn of the Industrial Revolution: https://youtu.be/QgNDao7m41M?t=1m35s
Gross potential of our civilization in 2015 at the dawn of the Digital Revolution: https://youtu.be/QgNDao7m41M?t=2m3s
Gross potential of our civilization in 2115 after another century of developing our global brain: https://youtu.be/QgNDao7m41M?t=2m25s
I am confident that if any of us could truly glimpse the future we wouldn't call it 'amazing" or 'cool'. I'm fairly certain the words we would use would be more along the lines of 'dizzying', 'unimaginable', and 'terrifying'.
Hold onto your butts. We might even live to see it.
submitted by americanpegasus to Bitcoin [link] [comments]

Potential Information

Potential Information
I'm going to try and demonsrate, in Natural Language, why there is a Revolution occuring in Information Science. The question I wish to Address is: "How much Information is there in a give Container?". As modern Computer Scientists see things, the amount of Information in a given container is precisely the number of possible discrete states of that conainer. So a nibble can be in 16 possibles states, a byte can be in 256 possible states, and so on. I'd to coin the term "Potential Information" and make an explicit Parallel with Potential Energy. So for a byte, the Potential Information is 256. It's interesting that we don't use Units for Potential Information, though it is a well studied concept, if newly named. Conctpetually, we understand the Units as 256 pieces of "Potential Discrete Information", so let us use name the Units pdi.
Let's extend the Parallel with Potential Energy. A Boulder at the Top of a Mountain is said to have a Potential Energy Relative to it's height, weight and the Gravitational Constant that is tranfered to Kinetic Energy if it Rolls down the Mountain. For Argument's sake let us Suppose a Flat Earth, then at the Bottom of the Mountain, the Boulder is said to have Zero Potential Energy (certinaly regarding its Potential to fall under Gravity but but I expect there are other ways Squeeze Enery out of Rock!). In a Computer I would say that a byte in a Switch On Computer is like the Boulder at the top of the Mountain with Maximum Potential Information (256pdi) and in a Switch of Computer, it has Minimum Potential Information.
So here's a Question first of all: "What is Minimum Potential Information?". Let's now do a thought experiment to help aswer the question at hand. Consider the concept of a "Broken Bit"; a bit that is fixed in either the 0 or 1 state and can't be changed. So, Information Theorists? What is the pdi of a Broken Bit? We now a working bit has 2pdi, but do we say the Broken Bit has 1pdi or 0pdi? 1pdi seems reasonable because it has a single Discrete State, but then 0pdi it seems we can't draw any information from it. If 0 is your answer, then I think you've jumped the gun, becuase I never told you what state it was locked in. What if I tell you it is locked in the 1 state? Well certainly we can draw no further information from it, but I say we still have the information that it is in the 1 state. So, I would say that before observation, the bit has 1pdi, but after observation, it has 0 pdi.
Now let us consider another possible unit of Information Measure "Discrete Information" or "di". So what is the di of a Broken Bit? Before we Observe it, we know we are going to read 1 Discrete Piece of information, and afterwards, we have read 1 Discrete Piece of Information. So I would say that the di of a Broken Bit is 1 in any Eventuality.
So you could interpret that as meaning that pdi is Time dependent and di is not Time dependent, which is a reasonable way to look at it. A more precise Way to look at it from a Computer Scientists point of view woud be to say that pdi is dependent on the number of "Reads" or "Potential Reads" where as di is not. This certainly holds for the Broken Bit. But, let us consider a working bit.
Let's get side tracked a bit and analyze a couple of common Computer Science Abstracts: Programs and Operations. Here's a suggestion for the definition of a "Program": A "Program" be an initial value for a container, and a series of well defined operations that manipulate the information of the container.
But this begs the question, what is an Operation... actually there's no obvious answer, it is thought of differently at different levels of the Computer Stack. To a user, Typing in a url and hitting Enter might be thought of as an Operation. The Web-Browser Software Developer, might consider an Operation to flag that the user has clicked in the url bar, an operation to read the string, operation(s) to analyis it, and operation(s) to send it to the DNS server. How about the guy who programmed the "String Read" operation, perhaps Scanf in C. That probably entails rather a few operations in Software alone, though it is a single operation in C. Then how many operations in Hardware were performed in this situation?
Here's a good Analogy for this type of thinking that any programmer will understand. Imagine you meansure Operations number of function calls. So how many operations in a "hello world application"? Well in C, it's One function call (not including main). Ok, but what about in Assembler? Rather a many function calls I would think. Then how did it get on your screen? Imagine the vast quatities of Function Calls that translate printf("hello world"); into a pattern of illuminated LEDs on the screen in a Terminal Window. Beyond that, how about the vast Edifices of Abstractions that lead to these LEDs glowing? Pixels, resolution, then colour of pixel which is represented as four bytes and needs Computer Software to interpret, then convert into a format correct to the monitor, then the monitor probably has more software to apply any colour correction and convert it into an Electrical Charge through some sort of Digital to Analog Converster that will eventually make a pixel glow with a certain colour. So how many operations in a "hello world" program? One could probably write countless Volumes analysing every operation that takes place from the flow of electrons through through Logic Gates, in the CPU, through the interupt mechanism on the chip to read you keystrokes, the abtraction of a bit and the operations of each ALU, the interpretation of the bits at each state of the ALUs computation etc. In fact, I think if you fully Analysed Everything that takes place inside a Computer in writing, compiling and executing a simple "hello world" program on a modern computer, you could probably chart pretty much the entire History of Computer Science.
For a moment, let us consider programs with no inputs, and et me suggest a definition of an Operation that may seem a little left field: "A Single Operation is the Space between two outputs", and "an output is any piece of information that it is a requirement that the program produce to satisfy its operation to the user". Let us assume for a moment that the only output device for a program is a Screen, and we a running a tech demo of the latest video game. As far as the user (i.e. viewer) is concerned, the only output they need is each frame. So long as the frame rate ticks over, the user is happy regardless of what is going on inside the computer. Then, the rate of Operations is Solely Dependent on how often the Screen updates, and 1 Operation takes place in the Computer inbetween each frame under this definition. So why use this seemingly bizarre Abstraction? What I'm seeking is an Absolute Measure of Compute Speed or Proficiency, and it seems to me, it is dependent on the program that is running. I'm sure those ASCII chips for mining bitcoin are dyamite at mining bitcoin, but your not going to get world of Warcraft running on them. I'm not sure you can really compare the Compute Speed of a ASCII bitcoin mining Rig to an XBox to example, certainly not simply by measuring Clock Speed and memory access rates anyway. What would be considered an "output" for a bitcoin miner? Hashrate is the standard measure of a bitcoin miners speed, and it is a most beautifully simple and perfect measure. Considering Compute Speed as "Numer of Operations per Second", then my definition of Operations and Outputs gives the Hashrate on a bitcoin miner. What about when an output is a frame on a Screen? Then on a game tech demo, for example, the Compute Speed would be the frame rate using the definitions I have already give. Again, probably the best know measure of Compute Speed for that type of Software. So perhaps I beginning to hit on a good generaization. I've actually conned you a little bit... in fact, under this definition of an operation as the "space between" outputs, my measure of compute speed of a video game is actually framerate-1 and my bitcoin mining measure is Hashrate-1. Here's another interesting consequence, with framerate, if my Computer is outputing a 30 frames per second, then I am running at 29 operations per second, but if I am running at 59 operations per 2 seconds... Actually very important with this measure of speed, which I'll write about another time. Those that have been studying O-Cycles may well have just spotted a Parallel! I want to consider another type of program also. Some programs (and in my opinion usually wise ones) don't necessarilly seek to operate as fast as possible. Take "metronome" program for example and let an "output" be one metronome "click". If you just tried to run it as fast as possible, you would have hyper speed noisy and irregular metronome. i.e. not really a metronome at all. So what would satisfy the user in a metronome program? Ignoring issues of software design, the main anwer would be accuracy of timing; usually not directly proportional to compute speed. Let us coin a new phrase, "Compute Proficiency" and say that for a metronome, Compute Proficiecy is measured by the accuracy of the metronome's timing. So Compute proficiency could be measured the deviation of the click, from some standar norm. i.e. deviation (perhaps in milliseconds) away from some target timing. Now, in my experience as a skilled bedroom music producer and Computer Scientist, this has precisely no relationship to the clock speed of any electronic/computer musical intrument I use. Consider measuring time in Beats and consider the Cartesian Plane with Time Measured on the x axis and Time Modulus 1 on the y axis. Then the beats will be series of points with y = around the line y = 0. Then we can do all sorts of Statistics to Measure Compute Profiency based on each point's deviation from (0, n) where n is an Integer...
[...a brief digression for those that have been following my other work, if we map the timing of each beat to the Complex Plane as follows: y = time and x = (time modulus 1) + 1/2, then let c = x + yi, then we have a rather recognizable line through the Complex Plane. For a Perfectly accurate Metronome, the line Re(c) = 1/2, i.e. what most think and hope are the Zeros of the Zeta Function... honestly, I'm still investigating whether this is True... I'm pretty sure that either the Sum of 0s divided by the number of Zeros Summed = 1/2 as i o-o, or they are all 1/2. Curiously, for the purposes I like to use this Science for, it wouldn't matter one jot which was True... So far anyway...]
So, if you'll exuse my digression, let's get back to measures of information. So I would propose the following definition of "rate of information": number of discrete pieces of information per output, with output defined per computer program. Let's take an example of Video playing software, and assuming so sound, say it out puts a grey scale image of 1024 x 1024 pixels every 100 milliseconds. Then assuming 1 byte per pixel, the program outputs 1 Megabyte memory per 100 milliseonds. So how much Discrete Information is it outputting per 100 milliseconds? Most people would say 1 Megabyte... How about per second? Again, most people would say 10 Megabytes. Here is how I would analyse the situation. I might say that a Megabyte, in a particular state, would constitute 1 Discrete piece of information (though not the only way of looking at it). Then I might day that the Potential Discrete Information of that Megabyte was 1024 * 1024 Discrete Pieces of information. So I would say the program is outputting at 10 Discrete Pieces of Information per Second- of course this doesn't consider Container Size of the Information. Let's look at it under a different lense, why would I consider 1 Megabyte in a particular state, a single piece of information? We could just as easily see it as 1024 * 1024 Discrete Pieces of Information if we consider the value of each pixel (byte) as a single piece of Information. Finally, I could consider it as 1024 *1024 * 256 Discrete Pieces of Information if we consider each bit individually. Here's a useful Equivolance Relationship:
Assume that the number of bits in a Sub-Container is a Power of 2 and the number of bits in a Container is a larger power of 2.
letting:
S = the Sub-Contain's Potential Discrete Information
C = the Container's Potential Discrete Information
s = number of bits in the Sub-Container
c = number of bits in the Container
then:
S / 2c = 2s / C
This is nothing to Computer Scientists, as Potential Discrete Information is what they usually consider. The above Relation is just a need formalization relating the number of bits and Potential Information in a Storage Container with a Sub-Container. Such as Total RAM to words or words to bytes etc.
Now what if we relate this to Discrete Pieces of information. Considering the situation, it seems that a single output should generally be considered a single Discrete Piece of Information. Then the goal of reducing the memory foot-print of Software Might be to make a Single Piece of Discrete Information have as little Potential Information as possible. How about an example: Consider out video game Tech Demo again, where we considered a single frame to be a single output and found that a single frame had 1 Megabyte of Potential Information. So by standard Information flow calculations, we are outputting information at 10 Megabytes per Second (One frame every 100 milliseconds). Now let's consider another situation, suppose we could stream a the output data to the screen without storing the whole frame. Let's say we could output it in 10 kilobyte chunks every 1 millisecond. Then our rate of information flow hasn't changed, however out memory footprint has reduced 100 fold. I'm still a little Wooly on the notion of an output, but it would now seem sensible to model an output as one of these 10 kilobyte chunks and therefore a discrete piece of information as a single output. So what do we have now:
1000 Discrete Pieces of Information per second 1 kilobyte of Potential Information per Discrete Piece of Information Therefore: 1 Megabyte of Potetial Discrete Pieces of Information per Second...
thus: Speed = pdi di/s
i.e Data Rate = Potential Discrete Pieces of Information per Discrete Piece of Information Per Second
So we may consider di/s purely a measure of speed of data trasfer, without considering size... e.g.
30 or 60 di/s for a 60 frames per second game for example, (treating each frame as 1 discrete piece of information). Then if it is outputting on 1024x1024 screen with 4 bytes per pixel, then we could say the Output Rate of the Game is:
Output Rate = 4Mb * 60 di/s or
Output Rate = 4Mb * 30 di/s
In visual Programs such as Graphical Programs, the di/s is VERY slow in comparison to a CPUs clock speed as humans rarely perceive quality improvements in animation about about 60fps (don't believe anyone who tell you that it's 30fps!).
Now consider the Polar Opposite in Modern Day Computing, a program than generates audio. an audio output device may ouput at 44,100 frames per second (for CD Quality) and the frames will usually be 16 bits for this kind of audio. So, such a pieces of Hardware/Software has the following output rate:
Output Rate = 16bits * 44,100 di/s
So some tell me, what is the Theoretical Minimum Memory footprint for such devices? The Theoretical Minimum is to create a program who's memory footprint is less that or equal to the Potetial Discrete Information Per frame. That doesn't help you with how to achieve this, but you certainly could not beat that minimum. I'm in the process of designing programs that can do this kind of this using the Tick operation.
Now, what's the minimum Discrete Pieces of Information per frame. The Answer is actually very Surpising, even for interesting programs. The answer is 1 bit. Let me explain. EVERY output of a Computer is Analog bar none. Very obviously so in Audio Devices and and old Televisions, but even Digital Information transfer is a Wave that is interpreted Digitally. Now how many bits does it take to produce a Wave? Well let's say I flick a bit at 500Hz and output it down a cable and send it into an Amp. Then I've just created a 500Hz Square Wave and I didn't need any software to Store anything, interpret what was stored, convert to packets, decode and send to the audio device. I wont speak much more about this now because I lack the Language of an Electrical EngineeEnergy Scientist to Describe my supositions, but one thing I do know, from an information persective, is that you can generate a Vast Quantity of Waves simply by flicking a single bit with the correct timing and sequence. Finally, when it gets to the point of directly outputting an Analog Signal direct from Code, what does this Discrete Pieces of Information per Second thing mean that I'd talking about earlier? You might say that the speed was the rate at which we flicked the bit, which is probably reasonable, but by the same token, the output itself does not have a discrete quality if it is a smooth Wave...
Here's the idea... you know those ugly annoying Computer Noises that sometimes leak from Speakers, like the Insidious Machinations of some Digital Monster? That is the Amplified noise of a Computer's Brain Pattern. We send that brain Data, our Digital Firend Mulls it over using His/Her Digital Brain Wave, then sends us back data. My thinking is to try to manipulate the Computer's Brain Waves Directly, then Amplify the result to use for whatever purposes...
Finally, what happens if you amplify the signal of [a] bit[s] ‘ticking itself in an O-Cycle? That’s kind of where I’m going with this...
...hmmm... Mysterious...
Nishikala
submitted by PotentiallyNishikala to mathematics [link] [comments]

Interested in contributing to the BTC community? Here is a exhaustive manual to get you up and running. (Only takes about 20-30 minutes if you are fluent in command prompt on linux).

These instructions will work both on a VPS cloud server or a personal computer. You may find cheap VPS somewhere online for rent.
What Is A Full Node?
A full node is a program that fully validates transactions and blocks. Almost all full nodes also help the network by accepting transactions and blocks from other full nodes, validating those transactions and blocks, and then relaying them to further full nodes.
Most full nodes also serve lightweight clients by allowing them to transmit their transactions to the network and by notifying them when a transaction affects their wallet. If not enough nodes perform this function, clients won’t be able to connect through the peer-to-peer network—they’ll have to use centralized services instead.
Many people and organizations volunteer to run full nodes using spare computing and bandwidth resources—but more volunteers are needed to allow Bitcoin to continue to grow. This document describes how you can help and what helping will cost you.
Costs And Warnings
Running a Bitcoin full node comes with certain costs and can expose you to certain risks. This section will explain those costs and risks so you can decide whether you’re able to help the network.
Special Cases
Miners, businesses, and privacy-conscious users rely on particular behavior from the full nodes they use, so they will often run their own full nodes and take special safety precautions. This document does not cover those precautions—it only describes running a full node to help support the Bitcoin network in general.
Please consult an expert if you need help setting up your full node correctly to handle high-value and privacy-sensitive tasks.
Secure Your Wallet
It’s possible and safe to run a full node to support the network and use its wallet to store your bitcoins, but you must take the same precautions you would when using any Bitcoin wallet. Please see the securing your wallet page for more information.
Minimum Requirements
Bitcoin Core full nodes have certain requirements. If you try running a node on weak hardware, it may work—but you’ll likely spend more time dealing with issues. If you can meet the following requirements, you’ll have an easy-to-use node.
Note: many operating systems today (Windows, Mac, and Linux) enter a low-power mode after the screensaver activates, slowing or halting network traffic. This is often the default setting on laptops and on all Mac OS X laptops and desktops. Check your screensaver settings and disable automatic “sleep” or “suspend” options to ensure you support the network whenever your computer is running.
Possible Problems
Legal: Bitcoin use is prohibited or restricted in some areas.
Bandwidth limits: Some Internet plans will charge an additional amount for any excess upload bandwidth used that isn’t included in the plan. Worse, some providers may terminate your connection without warning because of overuse. We advise that you check whether your Internet connection is subjected to such limitations and monitor your bandwidth use so that you can stop Bitcoin Core before you reach your upload limit.
Anti-virus: Several people have placed parts of known computer viruses in the Bitcoin block chain. This block chain data can’t infect your computer, but some anti-virus programs quarantine the data anyway, making it more difficult to run a full node. This problem mostly affects computers running Windows.
Attack target: People who want to disrupt the Bitcoin network may attack full nodes in ways that will affect other things you do with your computer, such as an attack that limits your available download bandwidth or an attack that prevents you from using your full node’s wallet for sending transactions.
Linux Instructions
The following instructions describe installing Bitcoin Core on Linux systems.
Ubuntu 14.10 Instructions for Bitcoin Core 0.10.0.
If you use Ubuntu Desktop, click the Ubuntu swirl icon to start the Dash and type “term” into the input box. Choose any one of the terminals listed:
Alternatively, access a console or terminal emulator using another method, such as SSH on Ubuntu Server or a terminal launcher in an alternative desktop environment.
Type the following line to add the Bitcoin Personal Package Archive (PPA) to your system:
sudo apt-add-repository ppa:bitcoin/bitcoin
You will be prompted for your user password. Provide it to continue. Afterwards, the following text will be displayed:
Stable Channel of bitcoin-qt and bitcoind for Ubuntu, and their dependencies
More info: https://launchpad.net/~bitcoin/+archive/ubuntu/bitcoin
Press [ENTER] to continue or ctrl-c to cancel adding it
Press enter to continue. The following text (with some variations) will be displayed and you will be returned to the command line prompt:
gpg: keyring /tmp/tmpixuqu73x/secring.gpg' created gpg: keyring/tmp/tmpixuqu73x/pubring.gpg' created gpg: requesting key 8842CE5E from hkp server > > > >keyserver.ubuntu.com gpg: /tmp/tmpixuqu73x/trustdb.gpg: trustdb created gpg: key 8842CE5E: public key "Launchpad PPA for Bitcoin" imported gpg: no ultimately trusted keys found gpg: Total number processed: 1 pg: imported: 1 (RSA: 1) OK
Type the following line to get the most recent list of packages:
sudo apt-get update
A large number of lines will be displayed as different update files are downloaded. This step may take several minutes on a slow Internet connection.
To continue, choose one of the following options
sudo apt-get install bitcoin-qt
sudo apt-get install bitcoind
sudo apt-get install bitcoin-qt bitcoind
After choosing what packages to install, you will be asked whether you want to proceed. Press enter to continue.
If you’re logged in as an administrative user with sudo access, you may log out. The steps in this section should be performed as the user you want to run Bitcoin Core. (If you’re an expert administrator, you can make this a locked account used only by Bitcoin Core.)
Before using the Bitcoin Core daemon, bitcoind, you need to create its configuration file with a user name and password. First create the .bitcoin directory, create (touch) the file, and set the file’s permissions so that only your user account can read it. From the terminal, type:
mkdir ~/.bitcoin touch ~/.bitcoin/bitcoin.conf chmod 600 ~/.bitcoin/bitcoin.conf
Then you can run the command bitcoind. It will print output similar to this:
bitcoind Error: To use the "-server" option, you must set a rpcpassword in the configuration file: /home/bitcoinorg/.bitcoin/bitcoin.conf It is recommended you use the following random password: rpcuser=bitcoinrpc rpcpassword=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX (you do not need to remember this password)
The username and password MUST NOT be the same.
If the file does not exist, create it with owner-readable-only file permissions. It is also recommended to set alertnotify so you are notified of problems; for example: alertnotify=echo %s | mail -s "Bitcoin Alert" [email protected] The “rpcpassword” displayed will be unique for your system. You can copy the rpcuser and rpcpassword lines into your configuration file using the following commands. Note that in most Ubuntu terminals, you need to press Ctrl-Shift-C to copy and Ctrl-Shift-V to paste because Ctrl-C and Ctrl-V have different meanings in a Unix-style terminal.
echo rpcuser=bitcoinrpc >> ~/.bitcoin/bitcoin.conf echo rpcpassword=XXXXXX >> ~/.bitcoin/bitcoin.conf (Warning: Don’t use XXXXXX as your RPC password. Copy the rpcpassword displayed by bitcoind for your system.)
Now you can start Bitcoin Core daemon for real. Type the following command:
bitcoind -daemon
It will print a message that Bitcoin Core is starting. To interact with Bitcoin Core daemon, you will use the command bitcoin-cli (Bitcoin command line interface). Note: it may take up to several minutes for Bitcoin Core to start, during which it will display the following message whenever you use bitcoin-cli:
error: {"code":-28,"message":"Verifying blocks..."}
After it starts, you may find the following commands useful for basic interaction with your node:
to safely stop your node, run the following command:
bitcoin-cli stop
A complete list of commands is available in the Bitcoin.org developer reference.
When Bitcoin Core daemon first starts, it will begin to download the block chain. This step will take at least several hours, and it may take a day or more on a slow Internet connection or with a slow computer. During the download, Bitcoin Core will use a significant part of your connection bandwidth. You can stop Bitcoin Core at any time using the stop command; it will resume from the point where it stopped the next time you start it.
Optional: Start Your Node At Boot
Starting your node automatically each time your computer boots makes it easy for you to contribute to the network. The easiest way to do this is to start Bitcoin Core daemon from your crontab. To edit your crontab, run the following command:
crontab -e
@reboot bitcoind -daemon Save the file and exit; the updated crontab file will be installed for you. Now Bitcoin Core daemon will be automatically started each time your reboot your computer.
If you’re an Ubuntu expert and want to use an init script instead, see this Upstart script.
You have now completed installing Bitcoin Core. If you have any questions, please ask in one of Bitcoin’s many communities, such as Bitcoin StackExchange, BitcoinTalk technical support, or the #bitcoin IRC chatroom on Freenode.
To support the Bitcoin network, you also need to allow incoming connections. Please read the Network Configuration section for details.
Network Configuration
If you want to support the Bitcoin network, you must allow inbound connections.
When Bitcoin Core starts, it establishes 8 outbound connections to other full nodes so it can download the latest blocks and transactions. If you just want to use your full node as a wallet, you don’t need more than these 8 connections—but if you want to support lightweight clients and other full nodes on the network, you must allow inbound connections.
Servers connected directly to the Internet usually don’t require any special configuration. You can use the testing instructions below to confirm your server-based node accepts inbound connections.
Home connections are usually filtered by a router or modem. Bitcoin Core will request your router automatically configure itself to allow inbound connections to Bitcoin’s port, port 8333. Unfortunately many routers don’t allow automatic configuration, so you must manually configure your router. You may also need to configure your firewall to allow inbound connections to port 8333. Please see the following subsections for details.
Testing Connections
The BitNodes project provides an online tool to let you test whether your node accepts inbound connections. To use it, start Bitcoin Core (either the GUI or the daemon), wait 10 minutes, and then visit the GetAddr page (https://getaddr.bitnodes.io/). The tool will attempt to guess your IP address—if the address is wrong (or blank), you will need to enter your address manually.
For more instruction and reviews based off BTC please follow my subreddit /BTC_Reviews
all material from this post was found here --> https://bitcoin.org/en/full-node
submitted by Mattjhagen to rBitcoin [link] [comments]

Running a full node using Bitcoin-daemon. Instructions for Linux.

These instructions will work both on a VPS cloud server or a personal computer. You may find cheap VPS somewhere online for rent.
What Is A Full Node?
A full node is a program that fully validates transactions and blocks. Almost all full nodes also help the network by accepting transactions and blocks from other full nodes, validating those transactions and blocks, and then relaying them to further full nodes.
Most full nodes also serve lightweight clients by allowing them to transmit their transactions to the network and by notifying them when a transaction affects their wallet. If not enough nodes perform this function, clients won’t be able to connect through the peer-to-peer network—they’ll have to use centralized services instead.
Many people and organizations volunteer to run full nodes using spare computing and bandwidth resources—but more volunteers are needed to allow Bitcoin to continue to grow. This document describes how you can help and what helping will cost you.
Costs And Warnings
Running a Bitcoin full node comes with certain costs and can expose you to certain risks. This section will explain those costs and risks so you can decide whether you’re able to help the network.
Special Cases
Miners, businesses, and privacy-conscious users rely on particular behavior from the full nodes they use, so they will often run their own full nodes and take special safety precautions. This document does not cover those precautions—it only describes running a full node to help support the Bitcoin network in general.
Please consult an expert if you need help setting up your full node correctly to handle high-value and privacy-sensitive tasks.
Secure Your Wallet
It’s possible and safe to run a full node to support the network and use its wallet to store your bitcoins, but you must take the same precautions you would when using any Bitcoin wallet. Please see the securing your wallet page for more information.
Minimum Requirements
Bitcoin Core full nodes have certain requirements. If you try running a node on weak hardware, it may work—but you’ll likely spend more time dealing with issues. If you can meet the following requirements, you’ll have an easy-to-use node.
Note: many operating systems today (Windows, Mac, and Linux) enter a low-power mode after the screensaver activates, slowing or halting network traffic. This is often the default setting on laptops and on all Mac OS X laptops and desktops. Check your screensaver settings and disable automatic “sleep” or “suspend” options to ensure you support the network whenever your computer is running.
Possible Problems
Legal: Bitcoin use is prohibited or restricted in some areas.
Bandwidth limits: Some Internet plans will charge an additional amount for any excess upload bandwidth used that isn’t included in the plan. Worse, some providers may terminate your connection without warning because of overuse. We advise that you check whether your Internet connection is subjected to such limitations and monitor your bandwidth use so that you can stop Bitcoin Core before you reach your upload limit.
Anti-virus: Several people have placed parts of known computer viruses in the Bitcoin block chain. This block chain data can’t infect your computer, but some anti-virus programs quarantine the data anyway, making it more difficult to run a full node. This problem mostly affects computers running Windows.
Attack target: People who want to disrupt the Bitcoin network may attack full nodes in ways that will affect other things you do with your computer, such as an attack that limits your available download bandwidth or an attack that prevents you from using your full node’s wallet for sending transactions.
Linux Instructions
The following instructions describe installing Bitcoin Core on Linux systems.
Ubuntu 14.10 Instructions for Bitcoin Core 0.10.0.
If you use Ubuntu Desktop, click the Ubuntu swirl icon to start the Dash and type “term” into the input box. Choose any one of the terminals listed:
Alternatively, access a console or terminal emulator using another method, such as SSH on Ubuntu Server or a terminal launcher in an alternative desktop environment.
Type the following line to add the Bitcoin Personal Package Archive (PPA) to your system:
sudo apt-add-repository ppa:bitcoin/bitcoin
You will be prompted for your user password. Provide it to continue. Afterwards, the following text will be displayed:
Stable Channel of bitcoin-qt and bitcoind for Ubuntu, and their dependencies
More info: https://launchpad.net/~bitcoin/+archive/ubuntu/bitcoin
Press [ENTER] to continue or ctrl-c to cancel adding it
Press enter to continue. The following text (with some variations) will be displayed and you will be returned to the command line prompt:
gpg: keyring /tmp/tmpixuqu73x/secring.gpg' created gpg: keyring/tmp/tmpixuqu73x/pubring.gpg' created gpg: requesting key 8842CE5E from hkp server > > > >keyserver.ubuntu.com gpg: /tmp/tmpixuqu73x/trustdb.gpg: trustdb created gpg: key 8842CE5E: public key "Launchpad PPA for Bitcoin" imported gpg: no ultimately trusted keys found gpg: Total number processed: 1 pg: imported: 1 (RSA: 1) OK
Type the following line to get the most recent list of packages:
sudo apt-get update
A large number of lines will be displayed as different update files are downloaded. This step may take several minutes on a slow Internet connection.
To continue, choose one of the following options
sudo apt-get install bitcoin-qt
sudo apt-get install bitcoind
sudo apt-get install bitcoin-qt bitcoind
After choosing what packages to install, you will be asked whether you want to proceed. Press enter to continue.
If you’re logged in as an administrative user with sudo access, you may log out. The steps in this section should be performed as the user you want to run Bitcoin Core. (If you’re an expert administrator, you can make this a locked account used only by Bitcoin Core.)
Before using the Bitcoin Core daemon, bitcoind, you need to create its configuration file with a user name and password. First create the .bitcoin directory, create (touch) the file, and set the file’s permissions so that only your user account can read it. From the terminal, type:
mkdir ~/.bitcoin touch ~/.bitcoin/bitcoin.conf chmod 600 ~/.bitcoin/bitcoin.conf
Then you can run the command bitcoind. It will print output similar to this:
bitcoind Error: To use the "-server" option, you must set a rpcpassword in the configuration file: /home/bitcoinorg/.bitcoin/bitcoin.conf It is recommended you use the following random password: rpcuser=bitcoinrpc rpcpassword=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX (you do not need to remember this password)
The username and password MUST NOT be the same.
If the file does not exist, create it with owner-readable-only file permissions. It is also recommended to set alertnotify so you are notified of problems; for example: alertnotify=echo %s | mail -s "Bitcoin Alert" [email protected] The “rpcpassword” displayed will be unique for your system. You can copy the rpcuser and rpcpassword lines into your configuration file using the following commands. Note that in most Ubuntu terminals, you need to press Ctrl-Shift-C to copy and Ctrl-Shift-V to paste because Ctrl-C and Ctrl-V have different meanings in a Unix-style terminal.
echo rpcuser=bitcoinrpc >> ~/.bitcoin/bitcoin.conf echo rpcpassword=XXXXXX >> ~/.bitcoin/bitcoin.conf (Warning: Don’t use XXXXXX as your RPC password. Copy the rpcpassword displayed by bitcoind for your system.)
Now you can start Bitcoin Core daemon for real. Type the following command:
bitcoind -daemon
It will print a message that Bitcoin Core is starting. To interact with Bitcoin Core daemon, you will use the command bitcoin-cli (Bitcoin command line interface). Note: it may take up to several minutes for Bitcoin Core to start, during which it will display the following message whenever you use bitcoin-cli:
error: {"code":-28,"message":"Verifying blocks..."}
After it starts, you may find the following commands useful for basic interaction with your node:
to safely stop your node, run the following command:
bitcoin-cli stop
A complete list of commands is available in the Bitcoin.org developer reference.
When Bitcoin Core daemon first starts, it will begin to download the block chain. This step will take at least several hours, and it may take a day or more on a slow Internet connection or with a slow computer. During the download, Bitcoin Core will use a significant part of your connection bandwidth. You can stop Bitcoin Core at any time using the stop command; it will resume from the point where it stopped the next time you start it.
Optional: Start Your Node At Boot
Starting your node automatically each time your computer boots makes it easy for you to contribute to the network. The easiest way to do this is to start Bitcoin Core daemon from your crontab. To edit your crontab, run the following command:
crontab -e
@reboot bitcoind -daemon Save the file and exit; the updated crontab file will be installed for you. Now Bitcoin Core daemon will be automatically started each time your reboot your computer.
If you’re an Ubuntu expert and want to use an init script instead, see this Upstart script.
You have now completed installing Bitcoin Core. If you have any questions, please ask in one of Bitcoin’s many communities, such as Bitcoin StackExchange, BitcoinTalk technical support, or the #bitcoin IRC chatroom on Freenode.
To support the Bitcoin network, you also need to allow incoming connections. Please read the Network Configuration section for details.
Network Configuration
If you want to support the Bitcoin network, you must allow inbound connections.
When Bitcoin Core starts, it establishes 8 outbound connections to other full nodes so it can download the latest blocks and transactions. If you just want to use your full node as a wallet, you don’t need more than these 8 connections—but if you want to support lightweight clients and other full nodes on the network, you must allow inbound connections.
Servers connected directly to the Internet usually don’t require any special configuration. You can use the testing instructions below to confirm your server-based node accepts inbound connections.
Home connections are usually filtered by a router or modem. Bitcoin Core will request your router automatically configure itself to allow inbound connections to Bitcoin’s port, port 8333. Unfortunately many routers don’t allow automatic configuration, so you must manually configure your router. You may also need to configure your firewall to allow inbound connections to port 8333. Please see the following subsections for details.
Testing Connections
The BitNodes project provides an online tool to let you test whether your node accepts inbound connections. To use it, start Bitcoin Core (either the GUI or the daemon), wait 10 minutes, and then visit the GetAddr page (https://getaddr.bitnodes.io/). The tool will attempt to guess your IP address—if the address is wrong (or blank), you will need to enter your address manually.
For more instruction and reviews based off BTC please follow my subreddit /BTC_Reviews
all material from this post was found here --> https://bitcoin.org/en/full-node
submitted by Mattjhagen to BTC_Reviews [link] [comments]

Computer Memory - YouTube Byte, Kilobyte, Megabyte, Gigabyte, Terabyte Conversion Part 2 How many Bytes are in a Gigabyte? - YouTube Basic Computer skill part-1 Bits,byte, kilobytes, megabytes,gigabytes, terabytes, petabytes etc How Many Kb In A Gb

A nibble is 4 bits. Byte. Today, a byte is 8 bits. 1 character, e.g., "a", is one byte. Kilobyte (KB) A kilobyte is 1,024 bytes. 2 or 3 paragraphs of text. Megabyte (MB) A megabyte is 1,048,576 bytes or 1,024 kilobytes. 873 pages of plain text (1,200 characters). 4 books (200 pages or 240,000 characters). Gigabyte (GB) Bitcoin Stack Exchange is a question and answer site for Bitcoin crypto-currency enthusiasts. It only takes a minute to sign up. Sign up to join this community. Anybody can ask a question Anybody can answer The best answers are voted up and rise to the top Bitcoin . Home ; Questions ; Tags ; Users ; Unanswered ; Jobs; How to calculate transaction size before sending (Legacy Non-Segwit - P2PKH ... How many Bits in a Byte. There are 8 bits in a byte. 1 byte = 8 bits. Bytes. Byte is the basic unit of digital information transmission and storage, used extensively in information technology, digital technology, and other related fields. It is one of the smallest units of memory in computer technology, as well as one of the most basic data measurement units in programming. The earliest ... Bits. Bit (b) is a measurement unit used in binary system to store or transmit data, like internet connection speed or the quality scale of an audio or a video recording. A bit is usually represented with a 0 or a 1. 8 bits make 1 byte. A bit can also be represented by other values like yes/no, true/false, plus/minus, and so on. Bit Calculator - Convert between bits/bytes/kilobits/kilobytes/megabits/megabytes/gigabits/gigabytes. Enter a number and choose the type of Units

[index] [27717] [45874] [28833] [11142] [6607] [28998] [44918] [45041] [21354] [33207]

Computer Memory - YouTube

Byte, Kilobyte, Megabyte, Gigabyte, Terabyte Conversion Part 2. I created this video with the YouTube Video Editor (http://www.youtube.com/editor) Subscribe Puthunutpam (It's free) - http://goo.gl/SS1hS This screencast explains all about bits and bytes and whole idea about them. How to Convert Kilobytes, Megabytes and Gigabytes - Duration: 7:24. ... How many Bytes are in a Gigabyte? - Duration: 4:32. Jared Owen Recommended for you. 4:32. How Many Kb In A Mb - Duration: 1 ... Basic computer skill part-1 Bits to bytes Bytes to kilobytes Kilobytes to megabytes Megabytes to gigabytes Gigabyte to terabytes Terabytes to petabytes Petabytes to exabytes.

#