I'm inviting people to correct me since I'm not all knowing on the subject but from what I understand;
Bitcoins are mined by computers. The computer is given a complicated mathmatical problem to solve, if it solves it you recieve 1 bitcoin. This creates a steady income.
Bitcoins are stored using a program called a wallet, your wallet knows of all transactions, this means coins can't be spent twice. You can send bitcoins to an address, like a house address, from your wallet to another wallet.
Since bitcoin is a secure way of sending an amount of value, and people are willing to buy bitcoin, it has value. It's not a good, it's a currency.
My explanation is probably a bit too vauge, but it might help you grasp the concept better. Feel free to ask me to clarify or give you links
tl;dr: of what's going on:
A large % of the hashing power (not just f2pool) ~~is~~ was "SPV mining" where they mine on top of headers from blocks that they haven't actually verified. They do this because in most cases you earn more money doing it - latency matters a lot and even 1MB blocks take long enough to propagate that you lose a significant amount of money by waiting for full propagation.
However, this also means they're not checking the new BIP66 rule, and are now mining invalid blocks because of it. (another miner happened to create an invalid, non-BIP66 respecting block) If you're not using Bitcoin Core, you might be accepting transactions that won't be on the longest valid chain when all this is fixed.
Bitcoin Core (after 0.10.0) rejects these invalid blocks, but a lot of other stuff doesn't. SPV Bitcoinj wallets do no validation what-so-ever, blindly following the longest chain. blockchain.info doesn't appear to do validation as well; who knows what else?
edit: FWIW, this isn't a BIP66-specific issue: any miner producing an invalid block for any reason would have triggered this issue.
edit2: The majority of hashing power is now mining only valid blocks. However, SPV wallets are still vulnerable as they do no validation, and ~4% or so of hashing power is still mining invalid blocks. Don't trust txs in SPV wallets w/o >= 2 confirmations right now.
edit3: See updated notice on bitcoin.org: https://bitcoin.org/en/alert/2015-07-04-spv-mining
> There have only ever been two hard forks of the blockchain in the history of Bitcoin, and both nearly killed Bitcoin.
Aside from being inaccurate (the first event was a softfork, not a hardfork, and neither of them came close to killing Bitcoin), this ignores the change which was most similar to increasing the max block size: On Feb 20, 2012, the protocol was changed in a completely backward-incompatible way, with implications very similar to a hard fork. Anyone using an old client was disconnected from the rest of the network, and they were vulnerable to similar double-spending attacks. The reason that no one noticed this change (most people here probably haven't even heard of it) is that the change was programmed into the client 2 years in advance. You'd have to be using a client that was released over 2 years ago to be left on the old network. This is how the max block size will be increased, hopefully with the same 2-year delay. By the time the change actually happens, everyone will be using a client with the new rules because that's the only type of client that will have been advertised on bitcoin.org and elsewhere for 2+ years. You'd have to go massively out of your way to download a version without the new rules.
I think that the max block size hardfork will proceed smoothly as long as it is unanimously supported by the core devs and no more than a handful of really big Bitcoin businesses/communities decide to explicitly oppose it.
(I don't especially support Gavin's proposal because I think that it increases block sizes too quickly, but I think that some 2-year-delayed very conservative increase in max block size should be added ASAP.)
From the whitepaper:
The proof-of-work also solves the problem of determining representation in majority decision making. If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote. The majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it. If a majority of CPU power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chains.
They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism.
As a bonus you got a free rebuttal against UASF.
Each bitcoin client hard codes a list of what are called DNS seeds. These are domain names that when queried in DNS, return a reliable, well connected bitcoin node. The first time you start a node, it queries a number of these DNS seeds and connects to these nodes. Then it asks the node for a list their peers. The client tries to keep a geographically diverse set of connections (based on IP blocks), and writes the IPs of the best of these to disk. The next time it starts up, it can seed itself from this list and connect to other nodes, once again asking them for their peers. If it can't connect to any, it falls back to the DNS seeds again.
There's a more in-depth look at how Bitcoin does it here.
edit... There are a couple of other fallback options too. There are a number of hardcoded IPs for known reliable nodes in case DNS discovery fails. You can also provide the IP or DNS of a known node in the command line parameters, to skip using DNS seeds altogether.
> Proof-of-Work - To implement a distributed timestamp server on a peer-to-peer basis, we will need to use a proof-of-work system similar to Adam Back's Hashcash
Source: https://bitcoin.org/bitcoin.pdf
Notable changes explained here: https://bitcoin.org/en/release/v0.11.0#notable-changes
It's going down! I'm yelling timber!
Oh, and in an apocalyptic setting, what's gonna be valuable? Food? Water? Medicine? Alcohol and other recreational drugs? Transportation? Fuel? Wood? Iron and steel? Weapons? Sexual services? Physical labor? Professional skills?
NOPE! Obviously it's gonna be pet rocks and imaginary Internet money.
Considering you need to use bitcoins to make entries on the blockchain I would say this guy is incredibly uninformed about how the technology actually works. He needs to go read the Bitcoin whitepaper before making intellectually dishonest statements. Satoshi goes into detail about why an incentive model is needed to achieve distributed consensus.
https://bitcoin.org/bitcoin.pdf
> We have proposed a system for electronic transactions without relying on trust. We started with the usual framework of coins made from digital signatures, which provides strong control of ownership, but is incomplete without a way to prevent double-spending. To solve this, we proposed a peer-to-peer network using proof-of-work to record a public history of transactions that quickly becomes computationally impractical for an attacker to change if honest nodes control a majority of CPU power. The network is robust in its unstructured simplicity. Nodes work all at once with little coordination. They do not need to be identified, since messages are not routed to any particular place and only need to be delivered on a best effort basis. Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone. They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism.
This is literally the day Bitcoin was born, Bitcoin's birthday if you will.
Satoshi published the theoretical basis (the white paper, really good read, check it out here) for Bitcoin's implementation in 2008. By this analogy this was Bitcoin's conception.
Either before, during or after working on that paper, he also wrote the very first functional version of the software to actually run the network. Presumably he did some testing and stuff first on his own, but 3rd January 2009 was the first, public, start of the actual working Bitcoin network when Satoshi mined the Genesis block with the code that he'd written. And so Bitcoin was born.
Wtf? This was not the intended way for Bitcoin to operate. In Satoshi's whitepaper he clearly states his intention for Bitcoin was supposed to be a cheap currency to make micro-transactions with.
"The cost of mediation increases transaction costs, limiting the minimum practical transaction size and cutting off the possibility for small casual transactions, and there is a broader cost in the loss of ability to make non-reversible payments for nonreversible services. "
And it looks like his initial intentions failed with Bitcoin. https://bitcoin.org/bitcoin.pdf
It's worthwhile to take the time to read the scalability roadmap that is supported by most of the core developers. They're making it work as we speak.
WBN is a great video series that explains a lot of different aspects of bitcoin. This video talks about what it would take to spoof anything: https://www.youtube.com/watch?v=bi2thGzzNSs
Anyway, you don't have to understand all this to use it (just like you don't have to understand how a tv works to use it), but you asked, so there's a brief into into the math.
Also check out the bitcoin whitepaper, which breaks down the economic incentives that keep everything in line: https://bitcoin.org/bitcoin.pdf
Edit: words
Edit 2: obligatory thanks for the gold - my first!
Okay. Do you remember you encrypted the file with a password? If you remember the password or don't have a password and since your file is intact, your bitcoins are safe.
Slightly difficult but "official legit" solution:
Download https://bitcoin.org/en/download.
Since it is not a HD wallet like the newer wallets, you may need to download the full blockchain (~50 GB) to check the balance.
I am assuming you have Windows.
Go to %APPDATA%\Bitcoin
In that folder, there should be a wallet.dat file.
Since it's a new file delete that and copy your backed up wallet.dat file. Restart Bitcoin Core. Do you see any recieving addresses in File-->Recieving addresses? Don't worry if the balance is 0 because the Blockchain is not synced yet. If so, right click and select 'view private key' or something like that. If that asks for a password, you'll need to remember a password. If it shows you a long string of characters (most probably beginning with 5, you can recover your coins easily.)
Now you have to options, wait for the full blockchain to download and then send the Bitcoins to a newer HD wallet which does not require full blockchain download. Electrum for Windows/Linux, Mycelium for Android, Breadwallet for iOS are the best options. They require to backup the wallet only once with 12 word seeds. KEEP THAT 12 WORDS STORED IN A SAFE SPACE. After that transfer the bitcoins.
You know what, ignore all that. I just remembered something which will be easier
https://blockchain.info/wallet/import-wallet
blockchain.info is a trusted website and all the decryption and stuff happens clientside. You can trust it. Upload your wallet.dat file and see if it works.
Otherwise I am not sure but Electrum had some feature that let you import the qt wallet.dat files. If you get the hands of your private keys, you have got access to your coins and can directly import or sweep the keys to another wallet.
I'd like to note that the companies involved in this pledge are taking a risk of being removed from bitcoin.org's wallet listings as a result of their new policy: https://bitcoin.org/en/posts/hard-fork-policy
I believe this pledge demonstrates the conviction of said companies that the future of the entire ecosystem hangs in the balance of this decision.
I think anyone involved in development (including you) knows that coders should not be and are not judged by lines of code, nor is repo access necessary. Suggesting that core development is as diverse as this list is obviously arguing in bad faith. But we can run down the list of devs in a position of control in the interest of those who may believe you at face value:
Greg Maxwell: blockstream
Peter Wuille: Blockstream
Adam Back: Blockstream
Matt Corallo: Blockstream
Mark Friedenbach: Blockstream
Luke Dash Jr.: Blockstream affiliate
Peter Todd: Blockstream affiliate
Wladimir van der Laan: unaffiliated (?)
Eric Lombrozo: unaffiliated (?)
Jonas Schnelli: unaffiliated (?)
Cory Fields: unaffiliated (?)
Jeff Garzik: Purged from core
Gavin Andresen: Purged from core
Mike Hearn: Purged from core
Have other people made commits? of course. Are you suggesting that these commits have anything to do with the strategic development of the protocol? I hope not. Functionally and pragmatically, blockstream comprises more than half of core dev decision making.
If there are any other major core contributors who are involved with strategic planning and implementation for BTC, i may have missed them. But will you honestly say that the 7 of you blockstreamers are not an oligarchy in control of core? You've already purged the most productive and insightful developers because they didn't agree to your vision - do you think other will speak up? Are you really going to try to tell me that Schnelli or Fields are making scaling and implementation decisions, or that you would even allow them to do so?
Blockstream has captured bitcoin core. So we'll just use a new implementation.
"The incentive may help encourage nodes to stay honest. If a greedy attacker is able to assemble more CPU power than all the honest nodes, he would have to choose between using it to defraud people by stealing back his payments, or using it to generate new coins. He ought to find it more profitable to play by the rules, such rules that favour him with more new coins than everyone else combined, than to undermine the system and the validity of his own wealth."
White Paper https://bitcoin.org/bitcoin.pdf
>What more do you want?
To save Bitcoin and to become A Peer-to-Peer Electronic Cash System and not a settlement layer for centralized 2nd layer payment systems.
Other useful links:
Magnet link for anyone in a country (like Russia) that blocks Bitcoin.org:
magnet:?xt=urn:btih:b6f8da60aaf2007cd6db631637951ae673e31044&dn=bitcoin-core-0.10.1&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr=udp%3A%2F%2Fopen.demonii.com%3A1337&ws=https%3A%2F%2Fbitcoin.org%2Fbin%2F
Gitian build signatures are here with signatures (so far) from Wladimir van der Laan, Pieter Wuille, Luke Dashjr, Cory Fields, Jonas Schnelli, and several others. If you trust these people, this provides assurance that the binaries you download (and verify) match the code they have in their personal Bitcoin git repositories.
Interresting that you report this: The software implementing this has not been merged yet, and the alert that is part of it will not relay through the network. So to see that you would have to be directly connected to someone who is spamming you with it. (or, you're not actually seeing it... because someone named bu_ftw isn't actually running Bitcoin Core 0.11.2...)
The text in the final alert that blocks all the others is hard-coded in the receiver (your old software) and can't be set. There has been a more descriptive alert up for months, however, which sends people to https://bitcoin.org/en/alert/2016-11-01-alert-retirement ...
As an aside, Bitcoin software that old has numerous vulnerabilities... running it is something you can do, but it's not really recommended. You can reduce your exposure and get rid of that message by setting the alerts=0 option.
Core is planning to raise the block size limit, in a responsible way, in contrast to what Roger Ver and his 14 yo "to the moon boys" want.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
https://bitcoin.org/en/bitcoin-core/capacity-increases-faq#pre-segwit-fork
Nobody knows what effects a flexible block size limit would have, it's like a new coin. Please test this on an altcoin first.
Bitcoin is not a cellphone, not a hard drive so please boys, I understand that you desperately want to be rich today, but please tell your guru, we don't want Bitcoin to becomes "Paypal 2.0", as he recently mentioned.
Bitcoin Core can now also be downloaded using BitTorrent:
https://bitcoin.org/bin/0.10.0/bitcoin-0.10.0.torrent
Or use the magnet link on the download page:
https://bitcoin.org/en/download
Seeding this torrent can help decentralizing the downloads and make them more accessible for countries where bitcoin.org is unreachable, or in the case bitcoin.org experiences downtime.
> ? Are people going to be buying BU instead of regular ol bitcoin?
no, not according to Shatoshi's Bitcoin white paper:
>Nodes always consider the longest chain to be the correct one and will keep working on extending it. If two nodes broadcast different versions of the next block simultaneously, some nodes may receive one or the other first. In that case, they work on the first one they received, but save the other branch in case it becomes longer. The tie will be broken when the next proofof-work is found and one branch becomes longer; the nodes that were working on the other branch will then switch to the longer one.
So those calling a fork or BU an altcoin don't actually understand how bitcoin works.
When BU gets more than an average of 50.01% hashpower, and can sustain it, miners can safely move the block limit. BU is one safe way of doing it as described in the White Paper. https://bitcoin.org/bitcoin.pdf.
save a copy because the Core Fundamentalists are wanting to change Satoshi's White Paper to reflect the changes they are making.
Gavin won't even be the lead maintainer. Yikes. I was at least entertaining the idea with that understanding.
So really, this is just a rag-tag group of nobodies vs these guys.
This "Classic" fork has got to be to most comically sad threat that Bitcoin has faced yet. I hope the miners are paying attention - you guys seriously have to step back and reconsider.
https://bitcoin.org/bin/0.9.1/README.txt
0.9.1 Release notes
=======================
No code changes were made between 0.9.0 and 0.9.1. Only the dependencies were changed.
Upgrade OpenSSL to 1.0.1g. This release fixes the following vulnerabilities which can affect the Bitcoin Core software:
Add statically built executables to Linux build
It occurs to me, from seeing some of the comments in /r/bitcoin, that most the users who are allowed to post there don't know anything about Bitcoin other than the price.
To learn about Bitcoin one should start with the whitepaper of course, then to better understand it read through:
The developer guide (can we get this on btc.com also?) https://bitcoin.org/en/developer-guide
and Mastering Bitcoin http://chimera.labs.oreilly.com/books/1234000001802/index.html
then to get an idea of what Satoshi wanted with bitcoin read through what he had to say:http://satoshi.nakamotoinstitute.org/
Once someone does this they very quickly realize that the things /u/nullc and /u/theymos are working towards are in contradiction with the ideas present by Satoshi, that is these people want to either destroy bitcoin or change it into another system (thereby tricking the users).
From my point of view, there is a small attempt to turn Bitcoin into an alt-coin, this is lead by some code contributors to the Core project, (mostly people who we see to have lost coins at Gox).
ETH had one ~~this~~ about 10 days ago. Nothing happened.
BTC had one by accident... https://bitcoin.org/en/alert/2013-03-11-chain-fork Nothing happened... Everyone made a quick update and things were OK... There are some dispuets if that was HF. To that I say use original or pre 0.8.0 client and sync it. It will not work... So it is... Or you could go to https://bitnodes.21.co/nodes/ and look for 0.7.x node... You will find 0.8.x nodes but not 0.7.x
> It does not need to trust a node to verify payments, it can still verify them itself.
This is a point that's very often missed. In the original paper and again here, Satoshi talked about SPV as requiring what are now called fraud proofs. With fraud proofs, lightweight nodes are still able to enforce all of the rules of Bitcoin as long as they are able to receive messages from one honest full node. But what we now think of as "SPV nodes" lack these fraud proofs, instead trusting miners absolutely. (This redefinition was first made by Mike Hearn's BitcoinJ.) This is way less secure than Satoshi imagined, and the rise of these validation-less nodes is a major threat to Bitcoin as a whole (see here and here).
Satoshi might not have realized it, but it was previously impossible to do fraud proofs that cover all of the rules. But with SegWit, this will be possible, and I hope that fraud proofs are implemented soon after SegWit. Even if the number of full nodes was reduced by 90%, if all lightweight nodes became capable of processing fraud proofs, this'd probably still be a net gain in security for Bitcoin as a whole as well as for each of its users. (Though it'd be even better to have a lot of full nodes as well.)
https://bitcoin.org/bitcoin.pdf
What is needed is an electronic payment system based on cryptographic proof instead of trust, allowing any two willing parties to transact directly with each other without the need for a trusted third party.
> I wonder if despite this, Bitcoin still has a place, as a store of value.
Realistically? No.
Why? Because there are now far better instruments under development that aim to be precisely that -- a stable, actual store of value.
Every time I hear someone ask about Bitcoin being a "store of value", I know they are late to the BTC game.
Why? Because Bitcoin was not even designed to be that. The title of the white paper is: Bitcoin: A Peer-to-Peer <strong>Electronic Cash System</strong>.
Please point me to the language in there that details the goal of becoming a "store of value".
The whole "store of value" / "digital gold" schtick is the latest pivot attempt from BTC people trying to rationalize a situation that is frankly, pretty grim.
https://bitcoin.org/bitcoin.pdf
>If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs.
Node counts are not a useful way to measure support. And this has been known since literally the very beginning.
There are a number of different Bitcoin "wallets" that you can use to store your money. Some people choose to store their money with third parties, such as on a Bitcoin exchange. This is highly discouraged as the exchange can seize/freeze your money. You should use "real" Bitcoin wallet software that runs locally on your computer and stores the Bitcoins on your computer. Whenever you want to buy/sell Bitcoins on an exchange, you should move the funds to/from your wallet and not leave any balance on the exchange. This way they are exclusively under your control. It's a good idea to take a look at https://bitcoin.org/en/choose-your-wallet - this website explains all the pros and cons of different Bitcoin wallets.
A government could declare Bitcoin illegal, however, enforcing that would be tricky. They could seize Bitcoins stored on Bitcoin exchanges, and forbid businesses from accepting Bitcoins, but the actual Bitcoin network itself is highly resistent to censorship and so is protected against interference from the government. What would likely happen is there would be a Bitcoin black market where Bitcoin exchanges and businesses operate anonymously. This has happened in countries that do not allow its citizens to transact in any currency other than their own.
Most software engineers easily start at $70-100k. A senior developer for something like C++ like the bitcoin core in Silicon Valley is $200k.
So employ 3 of those people and you're looking at $50k per month in salary of the programmers they employ on the protocol.
So you can see why $150k isn't so crazy.
Here you can see some bitcoin events which are partly organised by the foundation. https://bitcoin.org/en/events
They have a few lawyers, PR people, board members. People like Jon Matonis fly all over the world to speak at various places, talk to companies and governments.
-
>Three years ago I was actually arguing for a navel gazing protocol fix-up hard fork. Now I think that window has passed.
-
>Hard forking itself has become political, which makes it an option no longer on the table if bitcoin is to remain true to its vision and purpose.
-
-
>On chain scaling if it happens at all is likely to be via extension blocks without opportunity for hard fork fixes.
-
if bitcoin is to remain true to its vision and purpose ... which is Bitcoin: A Peer-to-Peer Electronic Cash System and not just a settlement layer for intermediaries aka LN hubs et al. or disconnecting users to have direct access.
-
From v0.9.0 release notes:
>Rebranding to Bitcoin Core >--------------------------- >To reduce confusion between Bitcoin-the-network and Bitcoin-the-software we >have renamed the reference client to Bitcoin Core.
Right now the peer-to-peer protocol version message (sent between programs when they first connect) has a services
field. It currently only has two options:
0x00
-- I am not a full node; I can't relay blocks0x01
-- I am a full node; you can get blocks from me.There's no way for a node currently to say, "I'm a full node, but I only have certain blocks."
The developers are talking about how to best communicate what blocks a node has. It's something of a tricky problem and there are several different proposals. But they'll work it out and get relaying working for pruned nodes---there's nothing fundamental stopping it.
> “It was a big mistake that any of this was ever compared to currency,” Carlson-Wee says.
Apparently, the first sentence of Satoshi's whitepaper is a mistake, according to Carlson-Wee:
> Abstract. A purely peer-to-peer version of electronic cash...
source: https://bitcoin.org/bitcoin.pdf
The 'deleted' comment in this thread was the following:
Good question. Roger Ver (owner of bitcoin,com) ultimately agreed on June 2 to redirect it to https://bitcoin.org , but that generosity seems to have ended. The site looks like it's now turned into a low-quality spammy site that recommends LuxStack as the best wallet overall, and Blockchain.info as the best smartphone wallet and web wallet (lol).
Link to where Roger agreed to redirect to bitcoin.org: > https://www.reddit.com/r/Bitcoin/comments/3879do/what_is_bitcoin_link_inside_game_of_birds_points/crsueed
p.s. I should also note that when I linked directly to bitcoin,com, my post was automatically removed by AutoMod, with the following reason given: > "Your comment was automatically removed because you linked to bitcoin,com, which is more-or-less a phishing site of bitcoin.org. Please link to bitcoin.org instead."
Ironically, the comment was deleted because I quoted AutoMod's reason (which contained the bitcoin,com link) for deleting my previous comment (in which I had linked bitcoin,com). Lol...
The whitepaper explicity states (in the abstract):
> As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers.
What we are considering here is exactly that - a majority of the hashrate being controlled by nodes that are cooperating to attack the network.
This is 100% true. Everyone already knew we had the best engineers. But since around December I have noticed an extra effort that's helped our community recover our morale. It's the little things.
Thank you for making the scalability roadmap you put together and signed. That stood out to me as a very smart and perceptive thing to do at the time. It was a great roadmap - scientific, comprehensive, very well planned - but I really liked the classy way the whole thing came across. It was a technical description but also an appeal to sense of community. I just thought it was just a good response at a difficult time.
Thanks /u/nullc for spending time addressing the users even when they're not happy. You're becoming quite the PR man ;) I've seen GM here taking bullets from nasty redditors calmly explaining the roapmap, explaining how XYZ works, and answering a lot of users questions.
Thanks for sticking to the timeline and pumping out new bad ass releases all the time. I was so so happy with the block chain sync time improvement due to the ECC library - God bless you guys for working so hard on something like that which the majority of users will never see. It means a lot to me though so rock on.
And it's been smooth sailing for a while now as we just get feature after feature as promised. About to hit halving #2 in good shape.
Congrats everyone - Onward and upward.
A farcical, and completely political attempt to sway users/miners/merchants to entrust all of their trust to a tiny group of people, that back a plan that Greg Maxwell laid out on how Bitcoin should scale, according to him. The plan itself can be summed up as, SegWit will fix all short term problems, we have no plans to roll out any increase to the blocksize for years and will only be done in the event of an emergency, other than SegWit, the devs will be concentrating all of their efforts on making the Lightning Network a reality.
Essentially a blocksize increase is thrown in the bin in the short term (they indicated that it will be years before they even consider a block increase to be an option), and all efforts will be focused on unproven, untested, and completely new solutions, that likely require several months to a year to get implemented at minimum. It is IMO, the worst possible approach that could be undertaken and the devs are either falling for it because they don't have a clue what they are doing (likely considering they've left things to the last minute), are actively trying to disrupt and destroy Bitcoin dev and community organisation from the inside (not as unlikely as you think), and or are complicit in trying to completely destroy Bitcoin as it is now, in preference of a completely different form of payment system that has never been attempted before, thus in the process completely undermining the blockchain technology and obliterating from the inside the Bitcoin protocol that we've come to use and love for the last 6+ years.
> but bitcoin shouldnt try to become the worlds payment system. > i dont think that was the goal to begin with anyway. > just to create a digital token that cannot be copied. > and bitcoin is this already.
One goal was explicitly to facilitate "small, casual transactions" that financial institutions can't handle because they can't avoid getting drawn into mediating disputes, which makes small transactions too expensive. This is right in the introduction to the white paper.
https://bitcoin.org/bitcoin.pdf
Obviously the fact that Satoshi once thought this was a good idea doesn't mean that it is, and there may well turn out to be better ways to do them, but it was clearly a design goal.
This is a minor release, bringing various improvements and fixes, as well as activation parameters for the SegWit and NULLDUMMY soft-forks. In the event that there are no further issues discovered with this Release Candidate, it will become the final release.
Preliminary release notes can be found here, and binaries can be downloaded here.
Most of the Bitcoin community believes in the vision laid out in the Bitcoin whitepaper. Satoshi's whitepaper mentions blocks growing much larger than they are today and can grow as technology allows:
> With computer systems typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of 1.2GB per year, storage should not be a problem even if the block headers must be kept in memory.
It's impossible to know what Satoshi may think today now that we know much more about how Bitcoin really works as a large P2P network. But the whitepaper pretty clearly shows the original intent of blocks getting much bigger than 1MB.
Edit: english
Retaining/increasing the value of your bitcoins is not an incentive enough?
For me it is. I see no future with Core's roadmap.
>>>>"fictions and lies. ... Core has hard fork increases proposed in their road map."
>>>They have no such thing. Come now, let me see it!
>>It's published on bitcoincore.org under capacity increases, been there for a long time now
>You mean this roadmap? https://bitcoin.org/en/bitcoin-core/capacity-increases-faq#roadmap
Yes. that one. From the roadmap: "Despite these considerable complications, with sufficient precautions, none of them is fatal to a hard fork, and we do expect to make hard forks in the future."
You're not fooling anyone so you should probably just stop. You're just wrong and anyone reading the thread can see it. What u/pb1x wrote is true. Realize your cognitive dissonance, then why you have it (likely propaganda from rtbc) and get on the right side.
> is withering away at 25% support with absolutely no danger of activation.
And your position based on an apparent lack of information, and perhaps denial, is part of the reason the only tested scaling solution, which also contains other important updates to help the next level scaling solution, has not been activated.
Or just go with the guys who apparently think testing and code review are not that important. The third team to propose hard forks and in good company, starting with an immediate bump to 8MB (along with an unadvertised TOR blacklist) proposed by the rage quitter who trashed the entire project on his way out as he signed with a team competing with bitcoin, then the second team with apparently limited coding skills who did some testing to show that anything above 4MB was not safe and thought consensus should be reached via their home grown web survey tool, and now the latest team whose git activity consists mostly of renamed variables and commits from core.
The truth is right before you but you refuse to see it.
> contentious hard fork was not born out of a desire to control the reference implementation.
I think the facts simply disprove this view. Back in December, the Bitcoin technical community found a useful capacity improving compromise in segwit and build significant backing for it.
In response, Bitcoin Classic was launched, which promoted BIP109 which would give roughly the same capacity but with hardly any of the risk mitigations or other improvements that were essential to building a big consortia. If their focus was on capacity, they could have helped get segwit built and deployed, but they didn't. Instead, they eschewed an easy road to capacity-- and their proposal is still unfinished: Bitcoin "Classic" recently ripped out half of BIP109 after the surprise interoperability failure with Bitcoin Unlimited on testnet, and still no one has bothered to write an updated specification for what classic actually implements.
The most likely scenario is that the segregated witness feature will be deployed next month, allowing for an effective 1.7x increase in block capacity. I say "allowing" because wallets must be programmed to be able to take advantage of SegWit, although I believe some are ready to do so (for example, Electrum).
Afterwards, planning for a hard fork to 2MB capacity will begin.
This is laid out in the Capacity Increases FAQ.
actually it is, you downloaded a full wallet that has the entire blockchain on it (or it will in a little while lol)
why don't you try out electrum or multibit?
https://bitcoin.org/en/developer-guide#bitcoin-uri
Source : https://bitpay.com/bitcoin-compatible-wallets Bitcoin URI Support
Air Bitz(iOS & Android)
Armory(Universal)
Blockchain(Mac OS)
Blockchain(Android)
Electrum(Universal)
GreenAddress(Universal)
KryptoKit(Chrome Extension)
Multibit(Universal)
Mycelium(Android)
Pheeva(Universal)
Is https://bitcoin.org/en/developer-guide#detecting-forks a random link now?
When you can't argue against the content, argue against the source ...
EDIT: Oh, and WTF:
> Bitcoin.org's developer documentation is often right (although perhaps not always)
You posted that just now .
Can you be a bigger hypocrite, calling bitcoin.org 's dev docs a random link over in this sub, and praising them in the other?
For shame. But you have none.
Here are some tips that often help with running a node
Reducing bandwidth usage: https://bitcoin.org/en/full-node#reduce-traffic
Add prune=550
to the bitcoin.conf
file to reduce disk space usage, see: https://bitcoin.org/en/release/v0.12.0#wallet-pruning
Add dbcache=M
where M is the number of megabytes of RAM to allocate, going up to 4000 or so can make it sync faster. The default is 500.
Clearing Up Some Misconceptions About Full Nodes
We held our private keys, and full nodes deployed / That is why our bitcoin could not be destroyed
The argument here is that bitcoins are not traceable, but this is straight from the bitcoin definition: "All Bitcoin transactions are public, traceable, and permanently stored in the Bitcoin network"
Idiot politicians once again trying to fix what's not broken because they don't understand it.
Did you read https://bitcoin.org/en/bitcoin-core/capacity-increases-faq?
There's already a plan to increase the capacity, effectively increasing the number of transactions.
Do you believe the increase in capacity is insufficient/too much?
This is incorrect, this annoncement shouldn't be online yet. The binaries for the rc1 haven't even been uploaded yet, let alone that the version is released. The release candidate has been tagged on github, and a few developers have done gitian builds, so the release candidate will be uploaded and announced soon.
Edit: rc1 binaries can now be found here: https://bitcoin.org/bin/0.9.2/test/
The market is going to have a relief rally either way. I'd prefer to not sacrifice the long-term.
You guys fail to understand that bitcoin derives its value from being ideal money. You are attacking that feature, leaving the door open for other chains to satisfy the demand for a Peer-to-Peer Electronic Cash System.
The worst thing you can say about Satoshi is that he was not entirely prescient.
To the extent they think he was wrong, it's in the little things.
What they're most concerned with is keeping Bitcoin what the title of the paper described it as:
The same way you'd get involved in any open source project: look at the bug tracker and start fixing open bugs. As you work with the code, find more bugs and fix them. Even fix small shit like misspelled words in comments. Write documentation.
As you get more familiar with the codebase, start looking at the roadmap and see if there are any requested features you think you can take on. Propose your implementation idea on the development mailing list. Be prepared for people to call you an idiot and tell you your idea is shit and will never work. Don't let it discourage you. Make some changes to your plan based on feedback until you can get a few people behind you and are willing to work with you to get the change into the code.
Check out https://bitcoin.org/en/development for more information on getting involved and to see some links to other projects that might interest you. But whatever you do, don't just get an idea in your head, code it up, then send a github pull request without even talking to the core developers of the project. That's just asking for disappointment.
Pieter basically went in depth regarding the changes listed at https://bitcoin.org/en/release/v0.10.0
Headers first synchronization - faster and more robust initial sync; cuts initial sync time down from several days to ~6 hours
Dynamic transaction fee calculation - fees no longer hardcoded, scales with demand by listening to realtime fees on network.
Consensus library - this is important for developers who want to write clients that are compatible with the protocol without having to reimplement all of the consensus logic, because a bug in a reimplementation could break that implementation.
More script opcodes considered standard - this allows more flexibility for programmable money / contracts
Improved security - libsecp256k1, non-deterministic signatures are now prohibited
No changes since rc4 except documentation and build system. Final release notes:
Binaries will be available at https://bitcoin.org/en/download but seems like they're not built yet.
> I believe that the power to change the Bitcoin protocol should, and does, rest in the hands of the economic majority of people who use Bitcoin and give it value.
See here
> SPV clients which connect to full > nodes can detect a likely hard fork by > connecting to several full nodes and > ensuring that they’re all on the same > chain with the same block height, plus > or minus several blocks to account for > transmission delays and stale blocks. > If there’s a divergence, the client > can disconnect from nodes with weaker > chains.
SPV clients will detect any hardfork and follow the longest chain with the most proof of work. If the BU chain has the majority hash rate, SPV clients will follow BU.
Do you agree that they represent a proportion of the economic majority?
If you think Blockstream has no future, then remove Bitcoin Core and GreenAddress from your list of recommended wallets: https://bitcoin.org/en/choose-your-wallet
Given that the most prolific Bitcoin Core developers are Blockstream employees and contractors, it would make sense for you to "exercise editorial control over your website" and not support a company that you think has no future.
By the way, I know you're a theymos sockpuppet, a disingenuous person, and a liar, so you probably should just stop wasting your time replying to me.
from the comments in:
https://bitcoin.org/js/main.js
function makeEditable(e) { // An easter egg that makes the page editable when user click on the page and hold their mouse button for one second. // This trick allows translators and writers to preview their work.
Congrats on discovering this [easter egg](https://en.wikipedia.org/wiki/Easter_egg_(media\)#Software)
It actually does have a scripting system and some fairly intricate transaction mechanics, though the way it is structured prevents it from being used for very complex application (and most opcodes are still disabled). In fact, it even has an unresolved quadratic attack, where maliciously crafted blocks take ~30 seconds to process (reminder: this is not fatal in bitcoin land because block time is 10 min). This has been around for three years and there has not yet been a targeted fix despite this being cited as a primary roadblock to increasing the block size (until segwit, which is being touted as the "one fix to rule them all" but we'll see if the mining pools accept it).
> Segwit in April
Did you actually read the Capacity FAQ? It points out that segwit design would be done them and it would be released for review and testing, and that activation would come months later. It went out to review and testing mid april just as scheduled. 0.13 was release a couple weeks behind schedule (in part due to the bitcoin.org snafu). Testing on testnet is going well, mining software was dragging behind but is now going well.
I'm not sure what else you're expecting, but if you'd like things to go faster you could help out with review and testing. Unfortunately AFAIK none of the companies that were saying they urgently needed more capacity have contributed to these efforts, much to my disappointment.
> "great, if there wouldn't be such a thing as an artificial limit"
I understand your sentiment here, Olivier. An "artificial limit", you're right, is probably a bad stop-gap fix. It's not setting a limit via market forces. This means, by definition, that it's probably sub-optimal. It seems it should be a dynamic limit, instead.
However, please keep in mind the latter half of my prior statement: > "externalizes costs to those who run full nodes and smaller miners"
> "offload costs in an externalized fashion that centralizes the network"
A dynamic system should raise/lower the limit, without ignoring externalization of costs to nodes & miners. It should consider those externalized costs in its calculation, otherwise the system will centralize WRT nodes & miners.
By considering these costs, we will retain the Bitcoin network's ability to be "purely peer to peer" (if someone wants to run a full node... and have full validation capability, transaction privacy, & say in setting the rules for the system... then they should have that option). > https://bitcoin.org/en/bitcoin-core/features/validation
> https://bitcoin.org/en/bitcoin-core/features/privacy
Make sense?
Currently, dynamic limit proposals do not seem to account for the externalized (indirect / invisible-until-it's-too-late) costs.
As newbie i recommend to read and view as much as possible about the basics of cryptocurrencys and decentralized networks.
You can start with the amazing videos of james d'angelo: Bitcoin 101 - What is Bitcoin?: https://youtu.be/Bhe61JaNFLU
This was also my startingpoint. He's doing a great job.
Read the Wikipedia page and maybe some articles referenced there.
Search for Andreas Antonopoulos on YouTube and listen.
Try Mycelium when you're on android or breadwallet for iphone. Electrum i recommend for windows systems.
Read the white paper of satoshi nakamoto: https://bitcoin.org/bitcoin.pdf
Have fun :)
Those are all features considered when the paper was first written.
An overview of what the double spending problem and Trusted Third Party is. By intercepting transactions at the 3rd party, you can very easily steal all the money passing through it. With bitcoin to bitcoin transactions, it's impossible. All the news reports of bitcoin being "hacked" refer to third party currency exchanges, illustrating the problem bitcoin was meant to fix.
> no one had great things to say about Core’s social relations
So. The fuck. What.
They're welcome at any party I throw.
I don't give a damn where they rate on the "social butterfly" scale...
P.S. Who are they talking about? The 101 developers 0.14.0? A subset? Everyone who has ever contributed to Core?
>Doesn't matter, dont be fooled by the psychological game. Mining hash power is meaningless in defining the consensus rules.
Actually it does matter, because that is how Bitcoin is designed.
BU mining power has the ability to push Core right off of the network once it is producing the majority of blocks. It can do that, because that is how Bitcoin is designed to work. It is fine that most of you don't seem to understand this, because it literally doesn't matter as Bitcoin doesn't operate on baseless opinions of those who clearly do not understand the content of that document.
Ummm nope. It was renamed to Core long before Classic or even XT was announced. I think in the Core name suggestion may have even been from Mike Hearn?
Edit: March 2014 - https://bitcoin.org/en/release/v0.9.0
It doesn't matter. Removing Coinbase (and keeping them removed) was petty in the extreme and reveals bitcoin.org to be anything but a non-political, information-only Bitcoin resource.
It also makes the Core team look bad. They appear to be complicit, even if that's not their intention.
I think I read somewhere Core will get its own website for PR statements and the like -- hopefully true, because using bitcoin.org seems untenable to me.
EDIT: Some choice quotes from https://bitcoin.org/en/about-us:
>...nobody can speak with authority in the name of Bitcoin.
>Bitcoin is controlled by all Bitcoin users around the world. Developers are improving the software but they can't force a change in the rules of the Bitcoin protocol because all users are free to choose what software they use.
>Mission:
>• Provide visibility to the large scale Bitcoin ecosystem.
>• Improve Bitcoin worldwide accessibility with internationalization.
>• Remain a neutral informative resource about Bitcoin.
>You can report any problem or help to improve bitcoin.org on GitHub by opening an issue or a pull request in English.
^ All beautifully contradicted by their recent moves.
All good points, except.. they are either lies or misleading.
First of all, there was an intended hardfork back in 2013, on May 15th to be exact. Here is an article as well as the official warning.
Whether you do a soft fork or a hard fork, a node operator will still have to upgrade to properly see or process transactions. The difference is that it will be plainly obvious if you got left behind with a hard fork, while unsupported soft fork transactions will be much less so. A SW transaction, for example, will just appear as a "anyone-can-spend" transaction for software that doesn't support SW, and you wouldn't be able to spend it.
Finally, it would be much simpler both for the node software and for the Bitcoin network as a whole to add a (soft?) sigops cap derived from the block size as a preventive measure for the potential CPU exhaustion attacks. This change only involves node software, unlike the SW change which will require updates to every wallet software currently in use.
Very cool!
Here's the transaction id for https://bitcoin.com/bitcoin.pdf
09b39d2f822c7cc9412997f584fe41742c9f35314ca3d6dd6cbbaac0137bd3dc
And here's the transaction id for https://bitcoin.org/bitcoin.pdf
09b39d2f822c7cc9412997f584fe41742c9f35314ca3d6dd6cbbaac0137bd3dc
What I can tell thus far:
Thanks for setting this up Roger and bitcoin.com!
Miner honesty due to economic incentives is a fundamental assumption in Bitcoin. To mis-paraphrase Schneier: If you think technology can solve your economic/social problems, then you don't understand the problems and you don't understand the technology.
You can fix that by limiting transaction size but you will limit smart contract capability (removing the limit after you place them is another hard fork).
Note that Segwit actually fixes that and now there is work on a better metric than transaction size.
Really shouldn't be using the bootstrap torrent anymore;
> As of Bitcoin Core version 0.10.0 and later, the block chain bootstrap torrent hosted here takes more time to download and import than it would to simply start Bitcoin Core and let it sync itself.
https://bitcoin.org/bin/block-chain/README.txt
If you have access to a valid bootstrap.dat off of a dedicated server or CDN, then it may still be beneficial.
I love their Bitcoin FAQ's
https://bitcoin.org/en/faq#is-bitcoin-useful-for-illegal-activities
*> Is Bitcoin useful for illegal activities? *> > Bitcoin is money, and money has always been used both for legal and illegal purposes. Cash, credit cards and current banking systems widely surpass Bitcoin in terms of their use to finance crime. Bitcoin can bring significant innovation in payment systems and the benefits of such innovation are often considered to be far beyond their potential drawbacks. > > Bitcoin is designed to be a huge step forward in making money more secure and could also act as a significant protection against many forms of financial crime. For instance, bitcoins are completely impossible to counterfeit. Users are in full control of their payments and cannot receive unapproved charges such as with credit card fraud. Bitcoin transactions are irreversible and immune to fraudulent chargebacks. Bitcoin allows money to be secured against theft and loss using very strong and useful mechanisms such as backups, encryption, and multiple signatures. > > Some concerns have been raised that Bitcoin could be more attractive to criminals because it can be used to make private and irreversible payments. However, these features already exist with cash and wire transfer, which are widely used and well-established. The use of Bitcoin will undoubtedly be subjected to similar regulations that are already in place inside existing financial systems, and Bitcoin is not likely to prevent criminal investigations from being conducted. In general, it is common for important breakthroughs to be perceived as being controversial before their benefits are well understood. The Internet is a good example among many others to illustrate this.
Just to elaborate, private keys gives you access to your bitcoin and in a sense 100% ownership (as long as only you have that private key).
In an exchange and most online web wallets YOU DO NOT have private keys. The exchange has full control of your bitcoin. If it gets hacked, shutdown or has an inside job which has occurred over and over again, your bitcoin are most likely gone.
For most downloadable Bitcoin wallets and hardware wallets YOU have the private keys and no one else - meaning NO ONE can take your bitcoin if you secure them properly.
You don't need a specific bitcoin disk image. Just grab a raspbian image, and if you don't want to build bitcoin from source, just grab the compiled release here: https://bitcoin.org/en/download and run ./bitcoind
That's it. There is only like 1 minute to be gained by using a disk image with bitcoin core already installed, and a ton of security reasons not to do this.
AND another thing. People make the connection very quickly because you guys make it so easy! See here...https://bitcoin.org/en/bitcoin-core/capacity-increases. Now that is interesting, an organized document that appears on bitcoin.org signed even by you. How did this happen? Magically? Maybe this was before bitcoincore.org maybe not I don't know. Maybe you see the Blockstream/Core/Bitcoin.org as just not existing, but the links are undeniable, however tenuous you suggest.
> Since you seemed to have missed it (mentioned nowhere in your post) - there is a scaling plan in place: https://bitcoin.org/en/bitcoin-core/capacity-increases-faq
He didn't miss it... read it again.
Bitcoin is an open protocol, like email. There are lots of email providers, with varying degrees of information that they ask from you. You could also run your own email server / Bitcoin wallet and not have to give any information to anyone. It's actually pretty easy if you aren't completely computer illiterate.
Someone asked me to elaborate on the security implications of address reusage, then deleted his comment. Since I didn't want my answer to go to waste, here you go:
When signing bitcoin transactions, you take your public key, and need to create a random number for signing. If that random number has been used before to sign another transaction for the same public key, the private key can be calculated. If you're taking the random number out of a big enough pool, there's no realistic chance they would ever repeat, but with a bad random number generator...
This happened multiple times. Like described here. Also, in 2013, there was a bug found in Android's random number generator thanks to bitcoin. Addresses reused on Android wallets had been emptied by thieves.
Nobody's saying that Segwit is the final scaling solution. Segwit isn't a silver bullet and neither is any single solution or proposal. 'Scaling' is the summation of many things together.
That said, the scaling issue WAS addressed in version 0.12. Looking at the change log, most of the features addressed scaling in some way, with signature validation using libsecp256k1 being the most significant.
ironically it is. here is how it works according to the designer Shatoshi - he states it in the Bitcoin white paper:
>Nodes always consider the longest chain to be the correct one and will keep working on extending it. If two nodes broadcast different versions of the next block simultaneously, some nodes may receive one or the other first. In that case, they work on the first one they received, but save the other branch in case it becomes longer. The tie will be broken when the next proofof-work is found and one branch becomes longer; the nodes that were working on the other branch will then switch to the longer one.
So those calling a fork or BU an altcoin or extending an orphan chain don't actually understand how bitcoin works.
When BU gets more than an average of 50.01% hashpower, and can sustain it, miners can safely move the block limit. BU is one safe way of doing it as described in the White Paper. https://bitcoin.org/bitcoin.pdf.
save a copy because the Core Fundamentalists are wanting to change the paragraph i quoted from Satoshi's White Paper to reflect the changes they are making.
Have you ever read the bitcoin whitepaper, which gives a high level overview of what bitcoin is?
Reading about the original design of Bitcoin will help your understanding:
https://bitcoin.org/bitcoin.pdf
nakamotoinstitute.org/
>The race between the honest chain and an attacker chain can be characterized as a Binomial Random Walk. The success event is the honest chain being extended by one block, increasing its lead by +1, and the failure event is the attacker's chain being extended by one block, reducing the gap by -1.
Bitcoin: A Peer-to-Peer Electronic Cash System https://bitcoin.org/bitcoin.pdf
Bitcoin is
> A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution.
This "settlement layer" talk is being pushed by devs that want to make transactions on the blockchain artificially scarce, so that people will have no option but to move to other "layers".
Here is what Satoshi had to say about the blocksize limit.
> It can be phased in, like:
> if (blocknumber > 115000) > maxblocksize = largerlimit
> It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete.
> When we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.
Back then it was no big deal. Some people could foresee a controversy:
> > If we upgrade now, we don't have to convince as much people later if the bitcoin economy continues to grow.
> I agree, especially since generators are both the source of blocks and "votes" in the network. Since a block restriction would allow generators to charge higher transaction fees, they might "vote" against an increase in the max size in the future.
> It seems unlikely to be a real problem though.
But others were naive in thinking that such upgrade wouldn't be a real problem. :(
Download 0.13 here: https://bitcoin.org/bin/bitcoin-core-0.13.0/
In Terminal, type shasum -a 256
, then drag your downloaded disk image to the Terminal window and push enter. This should return:
e7fed095f1fb833d167697c19527d735e43ab2688564887b80b76c3c349f85b0 bitcoin-0.13.0-osx.dmg
Check to make sure it matches the SHA256SUMS.asc
file in the bitcoin.org directory, but also check that it matches the hashes posted on bitcoincore.org here: https://bitcoincore.org/en/2016/08/23/release-0.13.0/
That's the minimum you should do. You can also verify gitian signatures. More info here (not updated for 0.13 quite yet): https://www.reddit.com/r/Bitcoin/wiki/verifying_bitcoin_core
> What Cobra was suggesting was creating an updated version which deals with the many things omitted in the whitepaper that frequently cause confusion, and putting it out there for people looking for a generic understanding of Bitcoin-- with clear links to the historical document.
But there are already zillions of introductory descriptions of bitcoin, for all audiences. Cobra was not lamenting the lack of a good introduction, but the fact that people who were looking for that paper got that paper; and his intent was to redirect those people to an "updated" version of that paper
> I've been noticing that the Bitcoin paper at https://bitcoin.org/bitcoin.pdf is getting a lot of traffic (mainly from people searching for "bitcoin paper", or probably seeing it cited by other papers). Almost all the people reading the paper are probably reading it for the first time, and using it as a learning resource. [...] At some point, I think the paper will start to do more harm than good, because it tricks people into believing they understand Bitcoin. I have seen people promote toxic and crazy ideas, and then cite parts of the paper in an effort to justify it. Academics are also regularly citing the paper and basing some of their reasoning and arguments on this outdated paper.
Those people who get "toxic and crazy" ideas that Cobra so dislikes obviously are people who know how bitcoin works today. So, what bothers him is not that it may not be a good introduction for newbies, but that it makes people aware that what is there today is not what it has alway been intended to be.
(And I wonder how an idea can be "toxic"; unless that means "convincing".)
> Source?
Here you are: https://bitcoin.org/en/bitcoin-core/capacity-increases
> Signed:
> Adam Back
> Gregory Maxwell
> Luke Dashjr
> Peter Todd
> Pieter Wuille
> Theymos
I think we have a secret proxy war going on: Coinbase, 21 Inc and others backed by Silicon Valley that want to create a new financial paradigm.
On the other hand, the establishment that has an enormous information advantage (product pipeline, future protocol changes that may benefit BS) by paying the salaries for most of the Core developers.
I am not saying that Core developers sold their souls, but there is the risk that they may compromise and forget the origin and vision of Bitcoin. Always worth to read it again and remember.
To reduce dependency, we need more competition and more Bitcoin developers. And the media has to cover more competing clients. There is this perception that only Core exists. A client comparison table/infographic would be highly useful.
> there has been an increasing pressure to increase the blocksize, one that development leadership has consistently ignored
I'm not trying to be facetious, but have you seen the Capacity Increases FAQ and Roadmap?
> Lead developer
Mike has never been a 'lead developer', he has like 3 commits compared to other top contributors like Wlad with 3200+ commits. https://bitcoin.org/en/development
Nice FUD storm planned by R3 and Mike himself.
>So, for at least a period of time there will be this situation where there is a market for post-fork bitcoins generated on the original chain and also a market for the post-fork coins generated on the the side with the change to the protocol.
In previous hard forks, a winner was picked very quickly. Nobody with millions invested in mining equipment wants to spend any time mining the losing side of a hard fork since the coin reward is on an expressway to $0. Even a small 1-2% win rapidly snowballs over to 99%, with the losing chain worthless. A hard fork is not a software bug that breaks anything, this process is by design.
I feel like this community needs another hard fork just to realize it can be done with some amount of prep work. Queue the downvotes.
https://bitcoin.org/en/about-us
>Domain owners- Martti Malmi (AKA Sirius) Inactive Michael Marquardt (AKA Theymos)
Incidentally, on that page: >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.
Fail.
The Bitcoin website, with an introduction and FAQs, is at https://bitcoin.org/en/
Independent information about Bitcoins, including about buying and selling, can be found at https://en.wikipedia.org/wiki/Bitcoin
From TFA:
> If you are using the Windows version of the Bitcoin Core GUI without a wallet passphrase, it is possible that your wallet could be compromised by clicking on a bitcoin: payment request link. If you are using bitcoind (on Linux, OSX, or Windows), have enabled the -rpcssl option, and allow RPC connections from the Internet, an attacker from a whitelisted (-allowip) IP address can very likely discover the rpcpassword and the last rpc request. It is possible (but unlikely) private keys could be sent to the attacker.