Download - Bitcoin

Bitcoin - The Currency of the Internet

A community dedicated to Bitcoin, the currency of the Internet. Bitcoin is a distributed, worldwide, decentralized digital money. Bitcoins are issued and managed without any central authority whatsoever: there is no government, company, or bank in charge of Bitcoin. You might be interested in Bitcoin if you like cryptography, distributed peer-to-peer systems, or economics. A large percentage of Bitcoin enthusiasts are libertarians, though people of all political philosophies are welcome.

Bitcoin Core

Bitcoin Core software’s news and discussion

Bitcoin Core

Bitcoin Core software’s news and discussion.
[link] on Twitter: "In May 2019, Dr. Craig S. Wright was issued U.S. copyright registrations for most of the original #Bitcoin Client Software Code version 0.1 and for the Bitcoin White Paper. Learn >" on Twitter:"" title=" on Twitter: "In May 2019, Dr. Craig S. Wright was issued U.S. copyright registrations for most of the original #Bitcoin Client Software Code version 0.1 and for the Bitcoin White Paper. Learn >"" /> submitted by thacypha to bitcoinsv [link] [comments]

Bitcoin user survey: Wallets (bitcoin client software) and preferred technology - THANKS! I will post results

Bitcoin user survey: Wallets (bitcoin client software) and preferred technology - THANKS! I will post results submitted by pinhead26 to Bitcoin [link] [comments]

My Electrum wallet suddenly shows 0 BTC!

Description of Problem: I transferred bitcoin to my wallet about 2 weeks ago and confirmed that the amounts did arrive into the account. A few days later, I signed into my account and realized that my balance was showing 0 BTC. I have no idea where the BTC went. I checked the history and it seems to show that the amount was transferred out but I definitely don't remember doing that. How do I get my BTC back?! Any help is sincerely appreciated!
PS: I did verify my download.

Bitcoin Client Software and Version Number: Electrum 3.3.4 Operating System: Windows 10 Enterprise (Version 1903) System Hardware Specs: Intel Core i7-7700K CPU 4.20 Ghz, 16 GB DRAM4, 64 bit Any Related Addresses: Any Related Transaction IDs: Screenshot of the problem:
submitted by Majormuss to Bitcoin [link] [comments]

💡| Knuth is a high performance implementation of the Bitcoin Cash protocol focused on users requiring extra capacity and resilience. It is a full node software client, but also a development platform. It is designed for: miners, exchanges, app devolopers, block explorers and other businesses.

💡| Knuth is a high performance implementation of the Bitcoin Cash protocol focused on users requiring extra capacity and resilience. It is a full node software client, but also a development platform. It is designed for: miners, exchanges, app devolopers, block explorers and other businesses. submitted by ojjordan78 to Bitcoincash [link] [comments]

Who are the most influential people in Bitcoin/Crypto?

I have updated the list, please comment the influential people and why or their merits.
submitted by igreen21 to BitcoinBeginners [link] [comments]

What is up with all these Bitcoin devs who think that their job includes HARD-CODING CERTAIN VALUES THAT ARE SUPPOSED TO BE USER-CONFIGURABLE (eg: "seed servers")?

Recently, the developer of SegWit2x / BTC1, Jeff Garzik, caused some controversy by hard-coding the "seed servers" which Bitcoin uses to first start hunting for "peers".
Worse than that: apparently one of the "seeds" is a company he started, variously named Chainalysis / Skry / Bloq - which apparently specializes in de-anonymizing Bitcoin transactions and performing KYC/AML - and which also has apparently entered into agreements with Interpol.
Seriously, WTF???
This is what "Bitcoin devs" still consider to be part of their "job" - hard-coding parameters like this, which affect everyone else on the network - and which could easily be "exposed" to be made user-configurable - instead of being baked into the source code and requiring a friggin' recompile to change???
This recent event has refocused attention on the fact all these past years, most of these seed servers in "the" existing (legacy) client running on most of the network have _also been hard-coded - to domains under the control of "devs associated with Blockstream".
I don't like the list of seed servers in Bitcoin Core
Pieter Wuille - does not support BIP148 - works for Blockstream
Matt Corallo - does not support BIP148 - works for Blockstream
Luke Dashjr - supports BIP148 - works for Blockstream
Christian Decker - supports BIP148 - works for Blockstream
Jonas Schnelli - supports BIP148
Peter Todd - supports BIP148 - worked for Samson Mow who works for Blockstream
The corporate takeover of bitcoin illustrated in 1 commit
In The corporate takeover of bitcoin illustrated in 1 commit a user complains that btc1 changing the seed servers to servers run by some companies (see commit) equals a "corporate takeover of bitcoin". I never really took much care who runs these seed server, although they do posses a certain power over the network as correctly pointed out by P. Todd in the same thread:
...and the key thing with that is being able to control what nodes a node connects to can be a very powerful tool to attack new nodes, as it lets you prevent a node from learning about the valid chain with the most work.
4 out of 5 people running the bitcoin networks seed servers are directly associated with Blockstream!
I don't even believe that Blockstream is actually plotting an evil, forceful takeover of bitcoin using the seed servers. However it beautifully counteracts Adam's "decentralization is everything" arguments. What is most troublesome to me, is that this simple information is not allowed to appear on r\bitcoin at all.
Bitcoin is almost 9 years old - and most people are still running clients which use hard-coded values (which require an inconvenient recompile to reconfigure) for the "seed servers"??
Maybe this is, in some sense, part of the reason why people like BlueMatt and Luke-Jr and Pieter Wiulle think they can lord it over us and tell everyone else what to do? ...because they have quietly (and unfairly / incompetently) hard-coded their own friggin' server domain names directly into everyone else's client code, as our "seed servers"?
Is the low level of "quality" we - as a community - have become accustomed to from our devs?
Do other clients (Bitcoin Classic, Bitcoin Unlimited and Bitcoin ABC) also gratuitously hard-code their "seed servers" like this?
Here's a post from a year ago regarding "seed servers" in Classic:
How come "classic" uses the same alert keys/DNS seeds as Core?
Meanwhile, here's the main question:
Why are any "serious" Bitcoin clients still "gratuitously" hard-coding any values like this?
Why has our "ecosystem" / "community" not naturally evolved to the point where we have some public "wiki" pages listing all the "good" (community-recognized, popular) seed servers - and every user configures their own client software by choosing who they want from this list?
(Maybe because we've been distracted by bullshit for these past few years, fighting with these very same devs because they've refused provide any support for users who want bigger blocks?)
What would users have to do if (God forbid) something were to happen to the servers of those 4-5 seed servers which are currently hard-coded into nearly everyone's clients?
In that situation (assuming some "new" seed servers quickly appeared) people would be have two options:
  • Edit their C++ source code and download/install a (trusted, verified) C++ compiler (if they don't already have one), and recompile the friggin' code; or
  • Wait until new binaries got posted online - and download them (and verify them).
This unnecessary "centralization point" (or major inconvenience / bottleneck) has been sitting in our code this entire time - while these supposedly knowledgeable devs keep beating us over their head with their mantra of "decentralization" - which they have actually been doing so little to maximize?
Psycho-Socio-Economic Side Bar
Serious (but delicate/senstive) question: How many of these "devs" have developed (possibly unconscious?) behaviors in life where they try to make users dependent on them?
"Vendor lock-in" is a thing - a very bad thing, which certain Bitcoin devs have exhibited a tendency to inflict on users - in many cases due to rather obvious (psychological, social, and/or economic) reasons.
We should gently (but firmly) reject these tendencies whenever any dev exhibits them.
Our community should expect and demand an accessible, user-friendly interface for all user-configurable parameters - to maximize decentralization and autonomy
  • In "command-line" versions of the client program, these kind of parameters should be:
    • in a separate config file - using some ultra-simple, standard format such as YAML or JSON
    • also configurable via options (eg, --seed-server) upon invocation on the command-line
  • In GUI versions version of the client program (using some popular cross-platform standard such as Qt, HTML, etc.) these kind of parameters should be exposed as user-configurable options.
Yes, these user-configurable values for things like "seed servers" (or "max blocksize") could come pre-configured to "sensible defaults - so that the software will work "out of the box" (immediately upon downloading and installing) - with no initial configuration required by the user.
Yes: Even the blocksize has always been user-configurable - but most users don't know this, because most devs have been hiding this fact from us.
Three recent posts by u/ForkiusMaximus explained how Adjustable-Blocksize-Cap (ABC) Bitcoin clients shatter this illusion:
Adjustable-blocksize-cap (ABC) clients give miners exactly zero additional power. BU, Classic, and other ABC clients are really just an argument in code form, shattering the illusion that devs are part of the governance structure.
Adjustable blocksize cap (ABC) is dangerous? The blocksize cap has always been user-adjustable. Core just has a really shitty inferface for it.
Clearing up Some Widespread Confusions about BU
Note about Bitcoin ABC vs Bitcoin Unlimited:
There is a specific new Bitcoin client called Bitcoin ABC, which functions similar to Bitcoin Unlimited - with the important difference that Bitcoin ABC is _guaranteed to hard-fork to bigger blocks on August 1_.
(Please correct me if I'm wrong about this. Documentation for the behavior of these various hard-forks is currently still rather disorganized :-)
All serious devs should be expected to provide code which does not require a "recompile" to change these "initial, sensible" default parameters.
I mean - come on. Even back in the 80s people had "*.INI" files on DOS and Windows.
Nearly all users understand and know how to set user-configurable values - for decades.
How many people are familiar with using a program which has a "Preferences" screen? (Sometimes you may have to close and re-open the program in order for your new preferences to take effect.) This is really basic, basic functionality which nearly all software provides via a GUI (and or config file and/or command-line options).
And nearly all devs have been offering this kind of functionality - in either command-line parameters, config files, and/or graphic user interfaces (GUIs).
Except most Bitcoin devs.
The state of "software development" for Bitcoin clients seems really messed up in certain ways like this.
As users, we need to start demanding simple, standard features in our client software - such as accessible, user-friendly configurability of parameter values - without the massive inconvenience of a recompile.
What is a "Bitcoin client"?
After nearly 9 years in operation, our community should by now have a basic concept or definition of what a "Bitcoin client" is / does - probably something along the lines of:

A Bitcoin client is a device for reading (and optionally appending to) the immutable Bitcoin Blockchain.

Based on that general concept / definition, a program which does all of the above and also gratuitously "hard-codes" a bunch of domain names for "seed servers" is not quite the same thing as a "a Bitcoin client".
Such an "overspecialized" client actually provides merely a subset of the full functionality of a true "Bitcoin client", eg:
  • An "overspecialized" client only enables connecting to certain "seed servers" upon startup (in accordance with the "gratuitous opinion" of the dev who (mis)translated the community's conceptual specifications to C++ code)
  • An "overspecialized" client only enables mining blocks less that a certain size (in accordance with the "gratuitous opinion" of the dev who (mis)translated the community's conceptual specifications to C++ code)
One of the main problems with nearly all Bitcoin clients developed so far is that they are gratuitously opinionated: they "gratuitously" hard-code particular values (eg, "max blocksize", "seed servers") which are not part of the whitepaper, and not part of the generally accepted definition of a "Bitcoin client".
This failure on the part of devs to provide Bitcoin clients which behave in accordance with the community's specification of "Bitcoin clients" is seriously damaging Bitcoin - and needs to be fixed as soon as possible.
Right now is a good opportunity - with so many new Bitcoin clients popping up, as the community prepares to fork.
All devs working on various Bitcoin client software offerings need to wake up and realize that there is about to be a major battle to find out which Bitcoin client software offering performs "best" (in the user-interface sense - and ultimately in the economic sense) at:

reading (and optionally appending to) the immutable Bitcoin Blockchain

The Bitcoin client software offerings which can optimally (and most simply and securely :-) "satisfy" the above specification (and not merely some gratuitously overspecialized "subset" of it) will have the most success.
submitted by ydtm to btc [link] [comments]

Bitcoin Core 0.15.1 re-d/l ?

Bitcoin Client Software and Version Number: Bitcoin Core 0.15.1
Operating System: Windows 64
System Hardware Specs: Intel® Core™ i7 7700HQ @2.8ghz 16GB RAM Windows 10 Home 1TB 5400RPM (might be 7200) SATA HDD 256GB SSD
Description of Problem: So, I already d/l and sync blockchain AND successfully used my wallet. One week after last successful transaction: when I go to open Bitcoin Core, it is directing me to start over as if this is my first time using it. A new subfolder for the new wallet data is being created in the same directory as my first wallet. Any idea what's going on?
Thanks in advance, Smiley
submitted by MAC-U-TRON_7000 to Bitcoin [link] [comments]

The reasons for doing a HF now as opposed to SW are more than just: "HF is a neater cleaner solution" . Here is a list

First of all I am not opposed to SW. I'd prefer BU. Over that I would prefer Segwit. I do not think UASF is good. In fact it makes me doubt some of my previous conclusions: That the market can resolve this issue. I think UASF might be a way for a minority to take control of bitcoin by introducing chaos or the threat of chaos. Anyways...
1 A hard fork now is better than segwit because if done through BU it gives us an opportunity to avoid this same debate over and over again over the next few years. With SW you just get a theoretical 1.7MB increase which is something. With a HF upgrade it shows everyone there is no big deal. As we have already seen from ethereum HF Is NOT a big deal. The market cap of Ethereum is higher than before their hard fork. Period.
2 Tier 2 solutions don't exist yet. It is not worth destroying bitcoins network effect by causing high transaction fees from a delayed scaling resolution during our growth phase. While segwit would go a way towards mitigating this problem and giving us time to rollout solutions it is probably not enough. Especially considering that it needs a 95% miner signal and that will probably never happen.
3 The tier 2 solutions most talked about such as the lightning network do not actually allow more users* . It allows one user to make several payments to someone else by opening up channels and perhaps it allows those payments to be routed to other people who are also part of the LN. As thezerg1 recently said, if payment channels were the solution then the ones that exist would already be seeing great usage (like's payment channels). But they aren't. Say for instance I opened up a channel with amazon. I paid them in bitcoin through this payment channel. I actually order a ton of things from amazon. Maybe 1 per week. This means I could use the channel over time to order more and more things right? Except that amazon wouldn't be able to convert the bitcoins into dollars until the payment channel is closed. This makes it useless for merchants UNTIL a time when bitcoin starts making a full loop in the economy. That isn't happening yet. That is another reason why on chain scaling is preferable now. It gives more time for that to happen. (Also worth mentioning that with high transaction fees it is going to take a great fee to even start a payment channel).
3 We are going to need a hard fork eventually anyway because even with tier 2 solutions and even if you cram twice as many transactions into current blocks we will still need greater sized blocks. The only argument against this perhaps is some convoluted "extension blocks" idea. But that still doesn't solve the problem of miner funding. Ultimately miners are going to need more on chain capacity to achieve a greater revenue than what 1MB will allow so that the security of the network is kept relatively high. Since we are going to need one anyway, now is better.
4 The decentralization of bitcoin will rapidly become greater with more users. Not only will there be more holders of bitcoin, more merchants, there will be more nodes since nodes exist as a proportion of the user base. With the rapid advancement of things like bandwidth, more CPU power, even cheaper devices like maybe a raspberry pi 4 that will be able to run full nodes, greater storage space... and more sophisticated bitcoin client software that will work on things like faster synching, smarter bandwidth controls ETC... I think the network will be MORE decentralized if we allow more use cases which allows more users which allows more decentralization. It is worth mentioning that one of the greatest use cases for running a node is a merchant who accepts bitcoin and doesn't use a payment processor. If the transaction fees are too high then that disincentivizes merchants from using bitcoin at all which is something core actually wants since they consider the market for payments already saturated with Credit cards. (Two more reasons why Andreas talks are now pointless. He claims that payments are safer with Bitcoin because they are push instead of pull. Kind of moot when the core developers of bitcoin don't even believe in "payments").
5 Now there is a new reason. UASF. As vitalik said it carries nearly 100% of the risks of hard forks but with nearly 0% of the benefits. A hard fork is definitely superior to UASF. * (i) only soft-fork-able changes can be implemented in this way * (ii) not as much user freedom, as if the majority of miners download then users who refuse are stuck on the miners' chain * Costs: (i) the stability risks of a chaotic split into two chains if the majority of miners do not install the fork * (ii) since the majority of miners may switch over later, the no-fork chain is under constant risk of getting annihilated * (iii) if there is a ~50/50 split between miners, chaotic forks and rejoins can happen many times * Wrong: best case hard fork is that no one cares about one of the two sides, ie. all ethereum forks except for one. Jihaan Wu even had to create a 10 btc bounty for directionn on the chaos that would ensue for exchanges if the UASF is tried out.
Reason # 6 Finally development will get some decentralization. One creepy assertion that many make for why not to switch from core is that it has a greater amount of contributors. The fact is... whatever the main bitcoin client is will have the most contributors by default. People are simply less willing to develop for things when their chances of contributions have a significantly less chance of ever being used. It is a non-argument.
Vitalik Buterin Hard forks: they're controversial because some people oppose them because they're concerned they would be too controversial. Erm....
submitted by specialenmity to btc [link] [comments]

The Oracle Problem

Bitcoin the currency is often cited as just the initial app for blockhain technology. Having a decentralized system of trust is potentially useful in many ways.
Thinking about decentralized crowdfunding, bounty award systems, gambling, prediction markets, and the like, I keep running into one problem that I have trouble seeing a solution to. I think of it as 'The Oracle Problem'. Wondering if anyone knows of planned solutions on the matter.
All of these type of systems require some sort of conditional test. A question must be answered to complete the transaction. In current systems we rely on a centralized system to serve as the Oracle -broadcasting whether or not the conditions were met and triggering the appropriate response.
So these centralized Oracles answer questions like:
Did the required sum get raised to release the funds (crowdfunding)?
Have the terms of the bounty award been met?
Has the prediction come true?
Did the Red Sox win?
Who won this round of Starcraft/LoL?
And so on and so on. To get to a place where we can have decentralized versions we need to have decentralized Oracles, and I have a real hard time conceptualizing how that would work.
Let's say we wanted to build a decentralized crowdfunding app using Bitcoin. We only want the person raising the funds to get the sum if a certain minimal threshold is met. If you raise $2,000 or more you get it all, but otherwise all the payments are returned, for example.
How do we not have a centrally controlled party sitting in the middle that holds the funds and determines whether the sum is large enough to either release or return. How could you commit your bitcoin so that you could not go back on your word if the threshold is met, but without a centralized entity holding the funds? And how do they agree upon what the threshold is without a central system?
In the case of prediction markets or gambling, for example, how does a system without a central oracle determine that the Red Sox won last night? Or that a stock went up or down? You can build in API feeds, I suppose, from trusted sources, but if those ever go away your system breaks. And those feeds would only be good for big events, it wouldn't be able to tell whether the conditions for a unique and complex bounty were met.
It seems to me the oracle problem has to be solved to really get next-gen decentralized systems going. To recap, the main issues are:
Assuming a decentralized system:
  1. How to lock the funds so that the promisebettor cannot renege on the commitment but will receive their funds back if the condition is not met.
  2. How to produce trusted oracles (sources of determinations of the outcomes of conditions)
The only solution I can think of is kind of a 'wisdom of crowds' type of system. It would not work well until sufficiently large I think, but the idea would be that all users of the system get a vote. They can opt in to answer questions as often as they want or be presented with a single question every time they use the system or some function of the system.
So a user downloads this bitcoin client software that functions as a local wallet and your interface to this system. When they use it, as a condition of using other functionality, they are asked things like 'Did the Red Sox win?', options are presented and they select one. This would be combined with a reputation type of system, so a contrary vote to that of the crowd's hurts your reputation and decreases the value of your future votes.
Most of the time people will vote honestly even if their are outliers who intentionally lie or are incorrect, and so the system itself collects its own data to decide whether there is good reason to believe a condition has been met. As described, this system would get more robust over time as reputations point towards more trustworthy oracles. People could still be anonymous and create new accounts constantly, but those who consistently used the same account and were consistently right would have more sway over the system.
For the release of bounties and the like, conditions which are complex and not simple yes/no a/b questions, it's even harder. I suppose when you create a bounty, you could commit the funds and set a ratio of success. Once 80% of users have voted that the bounty has been met, the funds will be released. All can see these conditions, so they commit funds towards them knowingly.
Seems like it would be really susceptible to being gamed though. Someone could create 1000s of fake accounts or there could be massive 'voting blocks' that ally to swing things in an unfair way (even with reputation systems).
I'm mostly thinking out loud here and am curious what the best thinking out there along these lines is today.
submitted by dalovindj to Bitcoin [link] [comments]

Bitcoin Core v. Bitcoin Cash

I have wrote this to clarify confusion between Bitcoin and Bitcoin Cash, and hopefully alleviate bias from this discussion.
Bitcoin Core (Bitcoin) (BTC/XBT) It should be acknowledged that Bitcoin Core is the original Bitcoin code released 2009; not 1st August 2017. The version history for Bitcoin Core can be seen [1]
“Bitcoin Core is an open source project which maintains and releases Bitcoin client software called “Bitcoin Core”.”
“It is a direct descendant of the original Bitcoin software client released by Satoshi Nakamoto after he published the famous Bitcoin whitepaper.” – [2]
For reasons, which will now become obvious, during the Bitcoin Cash hardfork, block 478558 (August 1st, 2017 about 13:16 UTC) [3], Bitcoin’s blockchain was split [4], consequently the formal name for Bitcoin’s group was seen to be used more frequently; Bitcoin Core. This now results in two blockchains, Bitcoin Core and Bitcoin Cash. It would be worth taking some time to read [5], as I have seen stating “Bitcoin Core has only one team”, and despite this being true, it’s a skewed detail of how that team operates with the community.
Bitcoin Cash (BCash) (BCH) “Bitcoin Cash is peer-to-peer electronic cash for the Internet. It is fully decentralized, with no central bank and requires no trusted third parties to operate.” – [3] “Yes. Bitcoin Cash is the continuation of the Bitcoin project as peer-to-peer digital cash. It is a fork of the Bitcoin blockchain ledger, with upgraded consensus rules that allow it to grow and scale.” – [3]
It should be noted as specified above, Bitcoin Cash is intended as digital cash, which Bitcoin Core prior to the August hardfork, (SegWit and Lightening Network) was incapable of feasibly being used as digital cash like DASH. The context of digital cash I am referring too is instore transactions, where confirmation needs to be within several seconds.
Bitcoin Cash increasing the block size from Bitcoin Core’s 1MB block to 8MB blocks. “The legacy Bitcoin code had a maximum limit of 1MB of data per block, or about 3 transactions per second.” – [3]. This should be acknowledged as partly true, as the block size consists of different data, which can range in size. Hence the number of transaction can be seen to range from 3.3 – 7 transactions per second. – [9]. Regardless this is still a potential bottleneck which was seen too cause much higher TX fees in 2017.
BCash This has caused much debate, whether it should be called BCash or Bitcoin Cash. The argument for using BCash is that new users to the cryptocurrency community will not understand the difference between Bitcoin and Bitcoin Cash when purchasing via Coinbase. There is a debate that the name Bitcoin Cash is preferred by Roger Ver instead of BCash for reasons of branding; where Bitcoin is a recognised name. [6] Do your own due diligence and form your own opinion regarding Bitcoin Cash v BCash.
What is the difference between and “ was originally registered and owned by Bitcoin's first two developers, Satoshi Nakamoto and Martti Malmi. When Nakamoto left the project, he gave ownership of the domain to additional people, separate from the Bitcoin developers, to spread responsibility and prevent any one person or group from easily gaining control over the Bitcoin project.” – [7] iascah Reddit. “ is your premier source for everything Bitcoin related. We can help you buy bitcoins, choose a bitcoin wallet. You can also read the latest news, or engage with the community on our Bitcoin Forum. Please keep in mind that this is a commercial website that lists wallets, exchanges and other bitcoin related companies. Are you interested in to work for Click here to see our current opportunities.” - [8]
Conclusion Do your own due diligence and do not become influence by FUD (fear uncertainty and doubt) and FOMO (fear of missing out). Bitcoin has done well in the white paper [10] idea of ‘solving the double spending problem’, by using a decentralised public blockchain. Too which is now adopted by many other cryptocurrencies which seek to improve on features Bitcoin lacks, or features Bitcoin was not intended for, but blockchain technology has made possible. Features which Ethereum (smart contracts), Dash (digital cash) and Monero (privacy oriented transactions) added into the cryptocurrency community, making this community stronger with open source solutions.
Regardless of how people feel about Bitcoin now it has definitely been a milestone towards wider adoption of blockchain technology globally. Even in the context of having a decentralised blockchain.
References: [1] - [2] - [3] - [4] - [5] - [6] Roger Ver Rage Quit Interview - [7] - [8] - [9] - [10] -
submitted by bellmittens to Bitcoincash [link] [comments]

Bitcoin BCH has 8 full node software clients, 5 unique protocol implementations written in 4 different programming languages.

Bitcoin BCH has 8 full node software clients, 5 unique protocol implementations written in 4 different programming languages. submitted by Egon_1 to btc [link] [comments]

Is anyone else freaked out by this whole blocksize debate? Does anyone else find themself often agreeing with *both* sides - depending on whichever argument you happen to be reading at the moment? And do we need some better algorithms and data structures?

Why do both sides of the debate seem “right” to me?
I know, I know, a healthy debate is healthy and all - and maybe I'm just not used to the tumult and jostling which would be inevitable in a real live open major debate about something as vital as Bitcoin.
And I really do agree with the starry-eyed idealists who say Bitcoin is vital. Imperfect as it may be, it certainly does seem to represent the first real chance we've had in the past few hundred years to try to steer our civilization and our planet away from the dead-ends and disasters which our government-issued debt-based currencies keep dragging us into.
But this particular debate, about the blocksize, doesn't seem to be getting resolved at all.
Pretty much every time I read one of the long-form major arguments contributed by Bitcoin "thinkers" who I've come to respect over the past few years, this weird thing happens: I usually end up finding myself nodding my head and agreeing with whatever particular piece I'm reading!
But that should be impossible - because a lot of these people vehemently disagree!
So how can both sides sound so convincing to me, simply depending on whichever piece I currently happen to be reading?
Does anyone else feel this way? Or am I just a gullible idiot?
Just Do It?
When you first look at it or hear about it, increasing the size seems almost like a no-brainer: The "big-block" supporters say just increase the blocksize to 20 MB or 8 MB, or do some kind of scheduled or calculated regular increment which tries to take into account the capabilities of the infrastructure and the needs of the users. We do have the bandwidth and the memory to at least increase the blocksize now, they say - and we're probably gonna continue to have more bandwidth and memory in order to be able to keep increasing the blocksize for another couple decades - pretty much like everything else computer-based we've seen over the years (some of this stuff is called by names such as "Moore's Law").
On the other hand, whenever the "small-block" supporters warn about the utter catastrophe that a failed hard-fork would mean, I get totally freaked by their possible doomsday scenarios, which seem totally plausible and terrifying - so I end up feeling that the only way I'd want to go with a hard-fork would be if there was some pre-agreed "triggering" mechanism where the fork itself would only actually "switch on" and take effect provided that some "supermajority" of the network (of who? the miners? the full nodes?) had signaled (presumably via some kind of totally reliable p2p trustless software-based voting system?) that they do indeed "pre-agree" to actually adopt the pre-scheduled fork (and thereby avoid any possibility whatsoever of the precious blockchain somehow tragically splitting into two and pretty much killing this cryptocurrency off in its infancy).
So in this "conservative" scenario, I'm talking about wanting at least 95% pre-adoption agreement - not the mere 75% which I recall some proposals call for, which seems like it could easily lead to a 75/25 blockchain split.
But this time, with this long drawn-out blocksize debate, the core devs, and several other important voices who have become prominent opinion shapers over the past few years, can't seem to come to any real agreement on this.
Weird split among the devs
As far as I can see, there's this weird split: Gavin and Mike seem to be the only people among the devs who really want a major blocksize increase - and all the other devs seem to be vehemently against them.
But then on the other hand, the users seem to be overwhelmingly in favor of a major increase.
And there are meta-questions about governance, about about why this didn't come out as a BIP, and what the availability of Bitcoin XT means.
And today or yesterday there was this really cool big-blockian exponential graph based on doubling the blocksize every two years for twenty years, reminding us of the pure mathematical fact that 210 is indeed about 1000 - but not really addressing any of the game-theoretic points raised by the small-blockians. So a lot of the users seem to like it, but when so few devs say anything positive about it, I worry: is this just yet more exponential chart porn?
On the one hand, Gavin's and Mike's blocksize increase proposal initially seemed like a no-brainer to me.
And on the other hand, all the other devs seem to be against them. Which is weird - not what I'd initially expected at all (but maybe I'm just a fool who's seduced by exponential chart porn?).
Look, I don't mean to be rude to any of the core devs, and I don't want to come off like someone wearing a tinfoil hat - but it has to cross people's minds that the powers that be (the Fed and the other central banks and the governments that use their debt-issued money to run this world into a ditch) could very well be much more scared shitless than they're letting on. If we assume that the powers that be are using their usual playbook and tactics, then it could be worth looking at the book "Confessions of an Economic Hitman" by John Perkins, to get an idea of how they might try to attack Bitcoin. So, what I'm saying is, they do have a track record of sending in "experts" to try to derail projects and keep everyone enslaved to the Creature from Jekyll Island. I'm just saying. So, without getting ad hominem - let's just make sure that our ideas can really stand scrutiny on their own - as Nick Szabo says, we need to make sure there is "more computer science, less noise" in this debate.
When Gavin Andresen first came out with the 20 MB thing - I sat back and tried to imagine if I could download 20 MB in 10 minutes (which seems to be one of the basic mathematical and technological constraints here - right?)
I figured, "Yeah, I could download that" - even with my crappy internet connection.
And I guess the telecoms might be nice enough to continue to double our bandwidth every two years for the next couple decades – if we ask them politely?
On the other hand - I think we should be careful about entrusting the financial freedom of the world into the greedy hands of the telecoms companies - given all their shady shenanigans over the past few years in many countries. After decades of the MPAA and the FBI trying to chip away at BitTorrent, lately PirateBay has been hard to access. I would say it's quite likely that certain persons at institutions like JPMorgan and Goldman Sachs and the Fed might be very, very motivated to see Bitcoin fail - so we shouldn't be too sure about scaling plans which depend on the willingness of companies Verizon and AT&T to double our bandwith every two years.
Maybe the real important hardware buildout challenge for a company like 21 (and its allies such as Qualcomm) to take on now would not be "a miner in every toaster" but rather "Google Fiber Download and Upload Speeds in every Country, including China".
I think I've read all the major stuff on the blocksize debate from Gavin Andresen, Mike Hearn, Greg Maxwell, Peter Todd, Adam Back, and Jeff Garzick and several other major contributors - and, oddly enough, all their arguments seem reasonable - heck even Luke-Jr seems reasonable to me on the blocksize debate, and I always thought he was a whackjob overly influenced by superstition and numerology - and now today I'm reading the article by Bram Cohen - the inventor of BitTorrent - and I find myself agreeing with him too!
I say to myself: What's going on with me? How can I possibly agree with all of these guys, if they all have such vehemently opposing viewpoints?
I mean, think back to the glory days of a couple of years ago, when all we were hearing was how this amazing unprecedented grassroots innovation called Bitcoin was going to benefit everyone from all walks of life, all around the world:
...basically the entire human race transacting everything into the blockchain.
(Although let me say that I think that people's focus on ideas like driverless cabs creating realtime fare markets based on supply and demand seems to be setting our sights a bit low as far as Bitcoin's abilities to correct the financial world's capital-misallocation problems which seem to have been made possible by infinite debt-based fiat. I would have hoped that a Bitcoin-based economy would solve much more noble, much more urgent capital-allocation problems than driverless taxicabs creating fare markets or refrigerators ordering milk on the internet of things. I was thinking more along the lines that Bitcoin would finally strangle dead-end debt-based deadly-toxic energy industries like fossil fuels and let profitable clean energy industries like Thorium LFTRs take over - but that's another topic. :=)
Paradoxes in the blocksize debate
Let me summarize the major paradoxes I see here:
(1) Regarding the people (the majority of the core devs) who are against a blocksize increase: Well, the small-blocks arguments do seem kinda weird, and certainly not very "populist", in the sense that: When on earth have end-users ever heard of a computer technology whose capacity didn't grow pretty much exponentially year-on-year? All the cool new technology we've had - from hard drives to RAM to bandwidth - started out pathetically tiny and grew to unimaginably huge over the past few decades - and all our software has in turn gotten massively powerful and big and complex (sometimes bloated) to take advantage of the enormous new capacity available.
But now suddenly, for the first time in the history of technology, we seem to have a majority of the devs, on a major p2p project - saying: "Let's not scale the system up. It could be dangerous. It might break the whole system (if the hard-fork fails)."
I don't know, maybe I'm missing something here, maybe someone else could enlighten me, but I don't think I've ever seen this sort of thing happen in the last few decades of the history of technology - devs arguing against scaling up p2p technology to take advantage of expected growth in infrastructure capacity.
(2) But... on the other hand... the dire warnings of the small-blockians about what could happen if a hard-fork were to fail - wow, they do seem really dire! And these guys are pretty much all heavyweight, experienced programmers and/or game theorists and/or p2p open-source project managers.
I must say, that nearly all of the long-form arguments I've read - as well as many, many of the shorter comments I've read from many users in the threads, whose names I at least have come to more-or-less recognize over the past few months and years on reddit and bitcointalk - have been amazingly impressive in their ability to analyze all aspects of the lifecycle and management of open-source software projects, bringing up lots of serious points which I could never have come up with, and which seem to come from long experience with programming and project management - as well as dealing with economics and human nature (eg, greed - the game-theory stuff).
So a lot of really smart and experienced people with major expertise in various areas ranging from programming to management to game theory to politics to economics have been making some serious, mature, compelling arguments.
But, as I've been saying, the only problem to me is: in many of these cases, these arguments are vehemently in opposition to each other! So I find myself agreeing with pretty much all of them, one by one - which means the end result is just a giant contradiction.
I mean, today we have Bram Cohen, the inventor of BitTorrent, arguing (quite cogently and convincingly to me), that it would be dangerous to increase the blocksize. And this seems to be a guy who would know a few things about scaling out a massive global p2p network - since the protocol which he invented, BitTorrent, is now apparently responsible for like a third of the traffic on the internet (and this despite the long-term concerted efforts of major evil players such as the MPAA and the FBI to shut the whole thing down).
Was the BitTorrent analogy too "glib"?
By the way - I would like to go on a slight tangent here and say that one of the main reasons why I felt so "comfortable" jumping on the Bitcoin train back a few years ago, when I first heard about it and got into it, was the whole rough analogy I saw with BitTorrent.
I remembered the perhaps paradoxical fact that when a torrent is more popular (eg, a major movie release that just came out last week), then it actually becomes faster to download. More people want it, so more people have a few pieces of it, so more people are able to get it from each other. A kind of self-correcting economic feedback loop, where more demand directly leads to more supply.
(BitTorrent manages to pull this off by essentially adding a certain structure to the file being shared, so that it's not simply like an append-only list of 1 MB blocks, but rather more like an random-access or indexed array of 1 MB chunks. Say you're downloading a film which is 700 MB. As soon as your "client" program has downloaded a single 1-MB chunk - say chunk #99 - your "client" program instantly turns into a "server" program as well - offering that chunk #99 to other clients. From my simplistic understanding, I believe the Bitcoin protocol does something similar, to provide a p2p architecture. Hence my - perhaps naïve - assumption that Bitcoin already had the right algorithms / architecture / data structure to scale.)
The efficiency of the BitTorrent network seemed to jive with that "network law" (Metcalfe's Law?) about fax machines. This law states that the more fax machines there are, the more valuable the network of fax machines becomes. Or the value of the network grows on the order of the square of the number of nodes.
This is in contrast with other technology like cars, where the more you have, the worse things get. The more cars there are, the more traffic jams you have, so things start going downhill. I guess this is because highway space is limited - after all, we can't pave over the entire countryside, and we never did get those flying cars we were promised, as David Graeber laments in a recent essay in The Baffler magazine :-)
And regarding the "stress test" supposedly happening right now in the middle of this ongoing blocksize debate, I don't know what worries me more: the fact that it apparently is taking only $5,000 to do a simple kind of DoS on the blockchain - or the fact that there are a few rumors swirling around saying that the unknown company doing the stress test shares the same physical mailing address with a "scam" company?
Or maybe we should just be worried that so much of this debate is happening on a handful of forums which are controlled by some guy named theymos who's already engaged in some pretty "contentious" or "controversial" behavior like blowing a million dollars on writing forum software (I guess he never heard that software is open-source)?
So I worry that the great promise of "decentralization" might be more fragile than we originally thought.
Anyways, back to Metcalfe's Law: with virtual stuff, like torrents and fax machines, the more the merrier. The more people downloading a given movie, the faster it arrives - and the more people own fax machines, the more valuable the overall fax network.
So I kindof (naïvely?) assumed that Bitcoin, being "virtual" and p2p, would somehow scale up the same magical way BitTorrrent did. I just figured that more people using it would somehow automatically make it stronger and faster.
But now a lot of devs have started talking in terms of the old "scarcity" paradigm, talking about blockspace being a "scarce resource" and talking about "fee markets" - which seems kinda scary, and antithetical to much of the earlier rhetoric we heard about Bitcoin (the stuff about supporting our favorite creators with micropayments, and the stuff about Africans using SMS to send around payments).
Look, when some asshole is in line in front of you at the cash register and he's holding up the line so they can run his credit card to buy a bag of Cheeto's, we tend to get pissed off at the guy - clogging up our expensive global electronic payment infrastructure to make a two-dollar purchase. And that's on a fairly efficient centralized system - and presumably after a year or so, VISA and the guy's bank can delete or compress the transaction in their SQL databases.
Now, correct me if I'm wrong, but if some guy buys a coffee on the blockchain, or if somebody pays an online artist $1.99 for their work - then that transaction, a few bytes or so, has to live on the blockchain forever?
Or is there some "pruning" thing that gets rid of it after a while?
And this could lead to another question: Viewed from the perspective of double-entry bookkeeping, is the blockchain "world-wide ledger" more like the "balance sheet" part of accounting, i.e. a snapshot showing current assets and liabilities? Or is it more like the "cash flow" part of accounting, i.e. a journal showing historical revenues and expenses?
When I think of thousands of machines around the globe having to lug around multiple identical copies of a multi-gigabyte file containing some asshole's coffee purchase forever and ever... I feel like I'm ideologically drifting in one direction (where I'd end up also being against really cool stuff like online micropayments and Africans banking via SMS)... so I don't want to go there.
But on the other hand, when really experienced and battle-tested veterans with major experience in the world of open-souce programming and project management (the "small-blockians") warn of the catastrophic consequences of a possible failed hard-fork, I get freaked out and I wonder if Bitcoin really was destined to be a settlement layer for big transactions.
Could the original programmer(s) possibly weigh in?
And I don't mean to appeal to authority - but heck, where the hell is Satoshi Nakamoto in all this? I do understand that he/she/they would want to maintain absolute anonymity - but on the other hand, I assume SN wants Bitcoin to succeed (both for the future of humanity - or at least for all the bitcoins SN allegedly holds :-) - and I understand there is a way that SN can cryptographically sign a message - and I understand that as the original developer of Bitcoin, SN had some very specific opinions about the blocksize... So I'm kinda wondering of Satoshi could weigh in from time to time. Just to help out a bit. I'm not saying "Show us a sign" like a deity or something - but damn it sure would be fascinating and possibly very helpful if Satoshi gave us his/hetheir 2 satoshis worth at this really confusing juncture.
Are we using our capacity wisely?
I'm not a programming or game-theory whiz, I'm just a casual user who has tried to keep up with technology over the years.
It just seems weird to me that here we have this massive supercomputer (500 times more powerful than the all the supercomputers in the world combined) doing fairly straightforward "embarassingly parallel" number-crunching operations to secure a p2p world-wide ledger called the blockchain to keep track of a measly 2.1 quadrillion tokens spread out among a few billion addresses - and a couple of years ago you had people like Rick Falkvinge saying the blockchain would someday be supporting multi-million-dollar letters of credit for international trade and you had people like Andreas Antonopoulos saying the blockchain would someday allow billions of "unbanked" people to send remittances around the village or around the world dirt-cheap - and now suddenly in June 2015 we're talking about blockspace as a "scarce resource" and talking about "fee markets" and partially centralized, corporate-sponsored "Level 2" vaporware like Lightning Network and some mysterious company is "stess testing" or "DoS-ing" the system by throwing away a measly $5,000 and suddenly it sounds like the whole system could eventually head right back into PayPal and Western Union territory again, in terms of expensive fees.
When I got into Bitcoin, I really was heavily influenced by vague analogies with BitTorrent: I figured everyone would just have tiny little like utorrent-type program running on their machine (ie, Bitcoin-QT or Armory or Mycelium etc.).
I figured that just like anyone can host a their own blog or webserver, anyone would be able to host their own bank.
Yeah, Google and and Mozilla and Twitter and Facebook and WhatsApp did come along and build stuff on top of TCP/IP, so I did expect a bunch of companies to build layers on top of the Bitcoin protocol as well. But I still figured the basic unit of bitcoin client software powering the overall system would be small and personal and affordable and p2p - like a bittorrent client - or at the most, like a cheap server hosting a blog or email server.
And I figured there would be a way at the software level, at the architecture level, at the algorithmic level, at the data structure level - to let the thing scale - if not infinitely, at least fairly massively and gracefully - the same way the BitTorrent network has.
Of course, I do also understand that with BitTorrent, you're sharing a read-only object (eg, a movie) - whereas with Bitcoin, you're achieving distributed trustless consensus and appending it to a write-only (or append-only) database.
So I do understand that the problem which BitTorrent solves is much simpler than the problem which Bitcoin sets out to solve.
But still, it seems that there's got to be a way to make this thing scale. It's p2p and it's got 500 times more computing power than all the supercomputers in the world combined - and so many brilliant and motivated and inspired people want this thing to succeed! And Bitcoin could be our civilization's last chance to steer away from the oncoming debt-based ditch of disaster we seem to be driving into!
It just seems that Bitcoin has got to be able to scale somehow - and all these smart people working together should be able to come up with a solution which pretty much everyone can agree - in advance - will work.
Right? Right?
A (probably irrelevant) tangent on algorithms and architecture and data structures
I'll finally weigh with my personal perspective - although I might be biased due to my background (which is more on the theoretical side of computer science).
My own modest - or perhaps radical - suggestion would be to ask whether we're really looking at all the best possible algorithms and architectures and data structures out there.
From this perspective, I sometimes worry that the overwhelming majority of the great minds working on the programming and game-theory stuff might come from a rather specific, shall we say "von Neumann" or "procedural" or "imperative" school of programming (ie, C and Python and Java programmers).
It seems strange to me that such a cutting-edge and important computer project would have so little participation from the great minds at the other end of the spectrum of programming paradigms - namely, the "functional" and "declarative" and "algebraic" (and co-algebraic!) worlds.
For example, I was struck in particular by statements I've seen here and there (which seemed rather hubristic or lackadaisical to me - for something as important as Bitcoin), that the specification of Bitcoin and the blockchain doesn't really exist in any form other than the reference implementation(s) (in procedural languages such as C or Python?).
Curry-Howard anyone?
I mean, many computer scientists are aware of the Curry-Howard isomorophism, which basically says that the relationship between a theorem and its proof is equivalent to the relationship between a specification and its implementation. In other words, there is a long tradition in mathematics (and in computer programming) of:
And it's not exactly "turtles all the way down" either: a specification is generally simple and compact enough that a good programmer can usually simply visually inspect it to determine if it is indeed "correct" - something which is very difficult, if not impossible, to do with a program written in a procedural, implementation-oriented language such as C or Python or Java.
So I worry that we've got this tradition, from the open-source github C/Java programming tradition, of never actually writing our "specification", and only writing the "implementation". In mission-critical military-grade programming projects (which often use languages like Ada or Maude) this is simply not allowed. It would seem that a project as mission-critical as Bitcoin - which could literally be crucial for humanity's continued survival - should also use this kind of military-grade software development approach.
And I'm not saying rewrite the implementations in these kind of theoretical languages. But it might be helpful if the C/Python/Java programmers in the Bitcoin imperative programming world could build some bridges to the Maude/Haskell/ML programmers of the functional and algebraic programming worlds to see if any kind of useful cross-pollination might take place - between specifications and implementations.
For example, the JavaFAN formal analyzer for multi-threaded Java programs (developed using tools based on the Maude language) was applied to the Remote Agent AI program aboard NASA's Deep Space 1 shuttle, written in Java - and it took only a few minutes using formal mathematical reasoning to detect a potential deadlock which would have occurred years later during the space mission when the damn spacecraft was already way out around Pluto.
And "the Maude-NRL (Naval Research Laboratory) Protocol Analyzer (Maude-NPA) is a tool used to provide security proofs of cryptographic protocols and to search for protocol flaws and cryptosystem attacks."
These are open-source formal reasoning tools developed by DARPA and used by NASA and the US Navy to ensure that program implementations satisfy their specifications. It would be great if some of the people involved in these kinds of projects could contribute to help ensure the security and scalability of Bitcoin.
But there is a wide abyss between the kinds of programmers who use languages like Maude and the kinds of programmers who use languages like C/Python/Java - and it can be really hard to get the two worlds to meet. There is a bit of rapprochement between these language communities in languages which might be considered as being somewhere in the middle, such as Haskell and ML. I just worry that Bitcoin might be turning into being an exclusively C/Python/Java project (with the algorithms and practitioners traditionally of that community), when it could be more advantageous if it also had some people from the functional and algebraic-specification and program-verification community involved as well. The thing is, though: the theoretical practitioners are big on "semantics" - I've heard them say stuff like "Yes but a C / C++ program has no easily identifiable semantics". So to get them involved, you really have to first be able to talk about what your program does (specification) - before proceeding to describe how it does it (implementation). And writing high-level specifications is typically very hard using the syntax and semantics of languages like C and Java and Python - whereas specs are fairly easy to write in Maude - and not only that, they're executable, and you state and verify properties about them - which provides for the kind of debate Nick Szabo was advocating ("more computer science, less noise").
Imagine if we had an executable algebraic specification of Bitcoin in Maude, where we could formally reason about and verify certain crucial game-theoretical properties - rather than merely hand-waving and arguing and deploying and praying.
And so in the theoretical programming community you've got major research on various logics such as Girard's Linear Logic (which is resource-conscious) and Bruni and Montanari's Tile Logic (which enables "pasting" bigger systems together from smaller ones in space and time), and executable algebraic specification languages such as Meseguer's Maude (which would be perfect for game theory modeling, with its functional modules for specifying the deterministic parts of systems and its system modules for specifiying non-deterministic parts of systems, and its parameterized skeletons for sketching out the typical architectures of mobile systems, and its formal reasoning and verification tools and libraries which have been specifically applied to testing and breaking - and fixing - cryptographic protocols).
And somewhat closer to the practical hands-on world, you've got stuff like Google's MapReduce and lots of Big Data database languages developed by Google as well. And yet here we are with a mempool growing dangerously big for RAM on a single machine, and a 20-GB append-only list as our database - and not much debate on practical results from Google's Big Data databases.
(And by the way: maybe I'm totally ignorant for asking this, but I'll ask anyways: why the hell does the mempool have to stay in RAM? Couldn't it work just as well if it were stored temporarily on the hard drive?)
And you've got CalvinDB out of Yale which apparently provides an ACID layer on top of a massively distributed database.
Look, I'm just an armchair follower cheering on these projects. I can barely manage to write a query in SQL, or read through a C or Python or Java program. But I would argue two points here: (1) these languages may be too low-level and "non-formal" for writing and modeling and formally reasoning about and proving properties of mission-critical specifications - and (2) there seem to be some Big Data tools already deployed by institutions such as Google and Yale which support global petabyte-size databases on commodity boxes with nice properties such as near-real-time and ACID - and I sometimes worry that the "core devs" might be failing to review the literature (and reach out to fellow programmers) out there to see if there might be some formal program-verification and practical Big Data tools out there which could be applied to coming up with rock-solid, 100% consensus proposals to handle an issue such as blocksize scaling, which seems to have become much more intractable than many people might have expected.
I mean, the protocol solved the hard stuff: the elliptical-curve stuff and the Byzantine General stuff. How the heck can we be falling down on the comparatively "easier" stuff - like scaling the blocksize?
It just seems like defeatism to say "Well, the blockchain is already 20-30 GB and it's gonna be 20-30 TB ten years from now - and we need 10 Mbs bandwidth now and 10,000 Mbs bandwidth 20 years from - assuming the evil Verizon and AT&T actually give us that - so let's just become a settlement platform and give up on buying coffee or banking the unbanked or doing micropayments, and let's push all that stuff into some corporate-controlled vaporware without even a whitepaper yet."
So you've got Peter Todd doing some possibly brilliant theorizing and extrapolating on the idea of "treechains" - there is a Let's Talk Bitcoin podcast from about a year ago where he sketches the rough outlines of this idea out in a very inspiring, high-level way - although the specifics have yet to be hammered out. And we've got Blockstream also doing some hopeful hand-waving about the Lightning Network.
Things like Peter Todd's treechains - which may be similar to the spark in some devs' eyes called Lightning Network - are examples of the kind of algorithm or architecture which might manage to harness the massive computing power of miners and nodes in such a way that certain kinds of massive and graceful scaling become possible.
It just seems like a kindof tiny dev community working on this stuff.
Being a C or Python or Java programmer should not be a pre-req to being able to help contribute to the specification (and formal reasoning and program verification) for Bitcoin and the blockchain.
XML and UML are crap modeling and specification languages, and C and Java and Python are even worse (as specification languages - although as implementation languages, they are of course fine).
But there are serious modeling and specification languages out there, and they could be very helpful at times like this - where what we're dealing with is questions of modeling and specification (ie, "needs and requirements").
One just doesn't often see the practical, hands-on world of open-source github implementation-level programmers and the academic, theoretical world of specification-level programmers meeting very often. I wish there were some way to get these two worlds to collaborate on Bitcoin.
Maybe a good first step to reach out to the theoretical people would be to provide a modular executable algebraic specification of the Bitcoin protocol in a recognized, military/NASA-grade specification language such as Maude - because that's something the theoretical community can actually wrap their heads around, whereas it's very hard to get them to pay attention to something written only as a C / Python / Java implementation (without an accompanying specification in a formal language).
They can't check whether the program does what it's supposed to do - if you don't provide a formal mathematical definition of what the program is supposed to do.
Specification : Implementation :: Theorem : Proof
You have to remember: the theoretical community is very aware of the Curry-Howard isomorphism. Just like it would be hard to get a mathematician's attention by merely showing them a proof without telling also telling them what theorem the proof is proving - by the same token, it's hard to get the attention of a theoretical computer scientist by merely showing them an implementation without showing them the specification that it implements.
Bitcoin is currently confronted with a mathematical or "computer science" problem: how to secure the network while getting high enough transactional throughput, while staying within the limited RAM, bandwidth and hard drive space limitations of current and future infrastructure.
The problem only becomes a political and economic problem if we give up on trying to solve it as a mathematical and "theoretical computer science" problem.
There should be a plethora of whitepapers out now proposing algorithmic solutions to these scaling issues. Remember, all we have to do is apply the Byzantine General consensus-reaching procedure to a worldwide database which shuffles 2.1 quadrillion tokens among a few billion addresses. The 21 company has emphatically pointed out that racing to compute a hash to add a block is an "embarrassingly parallel" problem - very easy to decompose among cheap, fault-prone, commodity boxes, and recompose into an overall solution - along the lines of Google's highly successful MapReduce.
I guess what I'm really saying is (and I don't mean to be rude here), is that C and Python and Java programmers might not be the best qualified people to develop and formally prove the correctness of (note I do not say: "test", I say "formally prove the correctness of") these kinds of algorithms.
I really believe in the importance of getting the algorithms and architectures right - look at Google Search itself, it uses some pretty brilliant algorithms and architectures (eg, MapReduce, Paxos) which enable it to achieve amazing performance - on pretty crappy commodity hardware. And look at BitTorrent, which is truly p2p, where more demand leads to more supply.
So, in this vein, I will close this lengthy rant with an oddly specific link - which may or may not be able to make some interesting contributions to finding suitable algorithms, architectures and data structures which might help Bitcoin scale massively. I have no idea if this link could be helpful - but given the near-total lack of people from the Haskell and ML and functional worlds in these Bitcoin specification debates, I thought I'd be remiss if I didn't throw this out - just in case there might be something here which could help us channel the massive computing power of the Bitcoin network in such a way as to enable us simply sidestep this kind of desperate debate where both sides seem right because the other side seems wrong.
The above paper is about "higher dimensional trees". It uses a bit of category theory (not a whole lot) and a bit of Haskell (again not a lot - just a simple data structure called a Rose tree, which has a wikipedia page) to develop a very expressive and efficient data structure which generalizes from lists to trees to higher dimensions.
I have no idea if this kind of data structure could be applicable to the current scaling mess we apparently are getting bogged down in - I don't have the game-theory skills to figure it out.
I just thought that since the blockchain is like a list, and since there are some tree-like structures which have been grafted on for efficiency (eg Merkle trees) and since many of the futuristic scaling proposals seem to also involve generalizing from list-like structures (eg, the blockchain) to tree-like structures (eg, side-chains and tree-chains)... well, who knows, there might be some nugget of algorithmic or architectural or data-structure inspiration there.
So... TL;DR:
(1) I'm freaked out that this blocksize debate has splintered the community so badly and dragged on so long, with no resolution in sight, and both sides seeming so right (because the other side seems so wrong).
(2) I think Bitcoin could gain immensely by using high-level formal, algebraic and co-algebraic program specification and verification languages (such as Maude including Maude-NPA, Mobile Maude parameterized skeletons, etc.) to specify (and possibly also, to some degree, verify) what Bitcoin does - before translating to low-level implementation languages such as C and Python and Java saying how Bitcoin does it. This would help to communicate and reason about programs with much more mathematical certitude - and possibly obviate the need for many political and economic tradeoffs which currently seem dismally inevitable - and possibly widen the collaboration on this project.
(3) I wonder if there are some Big Data approaches out there (eg, along the lines of Google's MapReduce and BigTable, or Yale's CalvinDB), which could be implemented to allow Bitcoin to scale massively and painlessly - and to satisfy all stakeholders, ranging from millionaires to micropayments, coffee drinkers to the great "unbanked".
submitted by BeYourOwnBank to Bitcoin [link] [comments]

Explain bitcoin to a 5 year old

Wikipedia says
“Bitcoin is a cryptocurrency and worldwide payment system. It is the first decentralized digital currency — the system works without a central bank or single administrator.”
I’m sorry Wikipedia but you lost me.
Instead, picture this…
Imagine a giant wall of letter boxes, each with a glass door. A crowd of people stand watching the letter boxes. Inside some of the boxes are coins. The crowd can see how many coins are in each box.
The crowd watches as a person steps forward with a key, opens a box, takes a coin, and deposits into the slot of another box. A clerk in the corner of the room writes this transaction into a ledger book. “Coin moved from box 4 to box 10.”
Time passes and more people step forward with keys, open individual boxes, and move coins to another. All the while the clerk in the corner is busy keeping track.
When approximately 10 minutes pass, the clerk closes his book and invites anyone in the room to solve a puzzle. A few people with huge calculators step forward. The first to solve the puzzle gets the honour to place the completed book on the shelf of official records. Good job buddy! The clerk rewards the winner with some newly minted coins.
This 10 minute cycle of record keeping continues so long as there are people in the room watching the boxes.
*The glass boxes are wallet addresses. Contents visible to all.
*The key is your wallet password. Keep it safe.
*The crowd is anyone running the bitcoin client software.
*The smart guys with big calculators are the miners.
*With a big enough calculator, anyone can try to mine.
*A book for every 10 minutes is a “block”.
*The shelf of books is the “blockchain”. All transactions ever, safely stored for anyone to read.
Why is a crowd of people watching a bunch of glass boxes important?
Before Bitcoin, a security guard would watch the boxes. Think of your bank, VISA or PayPal.
What if the guard caught a virus and got ill? What if the guard took a nap during some downtime? These mistakes happen when there is a single point of failure, like bank account details on a database.
Before Bitcoin, the keys were held on the guards belt. We trust the guard, of course, but must answer a number of personal security questions to gain access to our key.
Are we comfortable with the guard knowing so much? What if the guard lost the key? What if someone figured out the secret answer to our key? What if the guard sold our personal information? Not all guards are good.
With Bitcoin the whole world is watching the boxes all of the time. No one can lie, cheat or spend a coin in two recipient boxes at once. You hold the key to your box.
Remember always, with Bitcoin there’s no guard. If someone pickpockets your key, there is no one to turn to for help.
Thanks for reading. Thanks for sharing. Your comments are most appreciated.
[email protected]
submitted by coinagogo to Bitcoin [link] [comments] takeover attempt - "" removed from Bitcoin Core's BTC Bitcoin software client - Does Adam Back know what decentralization is? takeover attempt - submitted by ColinTalksCrypto to btc [link] [comments]

Bitcoin Core 0.15.1 re-d/l ?

Bitcoin Client Software and Version Number: Bitcoin Core 0.15.1
Operating System: Windows 64
System Hardware Specs: Intel® Core™ i7 7700HQ @2.8ghz 16GB RAM Windows 10 Home 1TB 5400RPM (might be 7200) SATA HDD 256GB SSD
Description of Problem: So, I already d/l and sync blockchain AND successfully used my wallet. One week after last successful transaction: when I go to open Bitcoin Core, it is directing me to start over as if this is my first time using it. A new subfolder for the new wallet data is being created in the same directory as my first wallet. Any idea what's going on?
Thanks in advance, Smiley
submitted by MAC-U-TRON_7000 to BitcoinBeginners [link] [comments]

nChain Announces Technical Support for Bitcoin Unlimited Client Software

nChain Announces Technical Support for Bitcoin Unlimited Client Software submitted by JavelinoB to btc [link] [comments]

12-02 22:02 - 'bitcoind unable to start ~NEED HELP' (self.Bitcoin) by /u/Light_of_Lucifer removed from /r/Bitcoin within 122-132min

Bitcoin Client Software and Version Number: Bitcoin Core 0.15.1
Operating System: Ubuntu 16.04
System Hardware Specs: 2.4 GHz Intel Core CPU with 16 GB RAM, 250GS ssd boot & 750 hdd gb storage hub.
Description of Problem: bitcoind refuses to start up. Keep getting the same error over and over.
Screenshot of the problem: [link]1
debug.log: [link]2
bitconi.conf: [link]3
Hello everyone. I have been running my own full node for a few weeks now. Ive been in the space for a long time but just recently started to get into developing on bitcoin. I turn off my node at the end of each day, I just use it to practice coding. A few days ago I was no longer able to start bitcoind because of this error
EXCEPTION: N5boost10filesystem16filesystem_errorE boost::filesystem::space: Operation not permitted bitcoin in AppInit()
I tried to -reindex and -reindex-chainstate but then bitcoind is stuck on block 0..... I have found virtually no resources on line to help me with this issue. Bitcoin is saved on my ssd home folder and the data direction is on my hdd storage folder located within media. ANY help is welcomed. Thank you
bitcoind unable to start ~NEED HELP
Go1dfish undelete link
unreddit undelete link
Author: Light_of_Lucifer
1: 2: 3:
submitted by removalbot to removalbot [link] [comments]

[uncensored-r/Bitcoin] bitcoind unable to start ~NEED HELP

The following post by Light_of_Lucifer is being replicated because the post has been silently removed.
The original post can be found(in censored form) at this link: Bitcoin/comments/7h4tkf
The original post's content was as follows:
Bitcoin Client Software and Version Number: Bitcoin Core 0.15.1
Operating System: Ubuntu 16.04
System Hardware Specs: 2.4 GHz Intel Core CPU with 16 GB RAM, 250GS ssd boot & 750 hdd gb storage hub.
Description of Problem: bitcoind refuses to start up. Keep getting the same error over and over.
Screenshot of the problem:
Hello everyone. I have been running my own full node for a few weeks now. Ive been in the space for a long time but just recently started to get into developing on bitcoin. I turn off my node at the end of each day, I just use it to practice coding. A few days ago I was no longer able to start bitcoind because of this error
EXCEPTION: N5boost10filesystem16filesystem_errorE boost::filesystem::space: Operation not permitted bitcoin in AppInit()
I tried to -reindex and -reindex-chainstate but then bitcoind is stuck on block 0..... I have found virtually no resources on line to help me with this issue. Bitcoin is saved on my ssd home folder and the data direction is on my hdd storage folder located within media. ANY help is welcomed. Thank you
submitted by censorship_notifier to noncensored_bitcoin [link] [comments]

Mods of /r/bitcoin: a 75% majority isn't anything to brag about

Hello again, /btc.
Some of you might remember me as that guy who got banned from /bitcoin yesterday for being insolent enough to question the integrity of the mods, who have embarked on an unprecedented campaign of censorship, obfuscation and interference in an apparent attempt to stifle discussion of alternative implementations of the bitcoin client software.
After being banned from the sub, I had a cordial exchange with /bitcoin's enlightened council of rulers, which, if you're interested, you can read here.
The long and short of it is, I shamed the mod team for being comically out of touch with their user base, which up-voted my original banned anti-mod rant at a rate of 75%. This seemed to strike a nerve with some of them, since it's hard if not impossible to justify blatant censorship of content that the majority approves of without admitting that you don't represent the user base at all. So how does our esteemed mod-team resolve the cognitive dissonance that comes along with being petty dictators opposed by the overwhelming majority? By claiming that a 75% majority "isn't anything to brag about."
Yes, you read that right. 75% - the same threshold coded into XT - isn't significant. Somehow I suspect the irony of this statement may have been lost on these simple tyrants.
submitted by KoKansei to btc [link] [comments]

'Promotion of client software which attempts to alter the Bitcoin protocol without overwhelming consensus is not permitted.' Is 72% overwhelming enough?

'Promotion of client software which attempts to alter the Bitcoin protocol without overwhelming consensus is not permitted.' Is 72% overwhelming enough? submitted by bitfuzz to Bitcoin [link] [comments]

"The correct thing to do when a critical bug hits software responsible for 100’s of billions of dollars, would be to recommend people to run alternative clients. Of course, those in control of Bitcoin Core would never do that, as it would mean giving up power. Monopoly = Control."

submitted by Egon_1 to btc [link] [comments]

We just updated our software's currency to include Bitcoin. This is for (Philippine) real estate professionals who want to find clients that want to transact in ₿.

We just updated our software's currency to include Bitcoin. This is for (Philippine) real estate professionals who want to find clients that want to transact in ₿. submitted by PhilippineRealEstate to Bitcoin [link] [comments]

Bitcoin Core Server for Windows 2016 Bitcoin-Qt Client Update 0.8.6 Explained Bitcoin Mining Pro Software (Updated Version) - YouTube Lunar Client is a Bitcoin Miner DEBUNKED How to mine bitcoins (solo mining) with the core client ...

Bitcoin Core is a community-driven free software project, released under the MIT license. Verify release signatures Download torrent Source code Show version history. Bitcoin Core Release Signing Keys v0.8.6 - v0.9.3 - 0.10.2 v0.11.0+ Or choose your operating system. Windows exe - zip. Mac OS X dmg - tar.gz. Linux (tgz) 64 bit. ARM Linux 64 bit - 32 bit. Linux (Snap Store) Support ... A bitcoin client is the end-user software that facilitates private key generation and security, payment sending on behalf of a private key, and optionally provides: Useful information about the state of the network and transactions. Information related to the private keys under its management. Syndication of network events to other peer clients. This table compares the features of the ... Die Software des Bitcoin-Netzwerks. Um im Bitcoin-Netzwerk geschäftig zu werden, benötigt jeder Bitcoin-User eine Software, einen Bitcoin-Client. Es gibt unterschiedliche Anbieter dieser Software, die es erlaubt ein eigenes Wallet zu erstellen. Mithilfe eines Bitcoin-Client kann jeder User Bitcoins empfangen und überweisen. Bitcoin Core ist ein gemeinschaftliches, freies Software-Projekt, veröffentlicht unter der MIT-Lizenz. Release-Signaturen überprüfen Download über Torrent Quelltext Versionshistorie anzeigen. Bitcoin Core Release Signierschlüssel v0.8.6 - v0.9.3 - 0.10.2 v0.11.0+ Oder wählen Sie Ihr Betriebssystem . Windows exe - zip. Mac OS X dmg - tar.gz. Linux (tgz) 64 bit. ARM Linux 64 bit ... Bitcoin Core ist ein Bitcoin-Client, der Nutzer mit dem Bitcoin-Netzwerk verbindet und synchronisiert.Die Software bietet eine integrierte Wallet, sodass sich Bitcoins senden und empfangen lassen.

[index] [4016] [376] [32107] [7723] [3906] [33511] [39272] [25906] [28577] [7515]

Bitcoin Core Server for Windows 2016

bitcoin (dot) org [bitcoin wallet] bitminter (dot) com [client and workers] there will never be a better version of this. *****UPDATE***** Solo mining has been removed from client. I'll keep the video up for how it used to work, it might still work for some alt coins (unsure) yo... An introduction to the Bitcoin JSON-RPC tutorial series. BTC: 1NPrfWgJfkANmd1jt88A141PjhiarT8d9U Lunar Client is a Bitcoin Miner DEBUNKED - Duration: 2:34. Fukkatsu 2,284 views. 2:34. Using VAPE on - SCREENSHARED + Bypass!? - Duration: 13:19. CloudSmoke Recommended for you. 13:19 ... Bitcoin Core is a quick deployment official Bitcoin cryptocurrency client. Bitcoin Core Server for Windows 2016 Bitcoin Core is an open-source software that serves as a bitcoin node (the set of ...