Bitcoin Core. Alles über Kryptowährung - BitcoinWiki

ETH Insider - Ethereum Forums, News, Trading & ICO's

ETH discussion board with a focus on ETH and ETH tokens. Alt-talk only if it is highly relevant for the current price. No FUD, No Hype, No Spamming. Thank you!

Crypto Insiders

Crypto discussion board with a focus on a variety of coins. No FUD, No Hype, No Spamming. Thank you!

I recently recounted the history of the block size controversy for someone and thought I'd repost it here

Bitcoin development was initially led by an anonymous figure named Satoshi Nakamoto who created the project "Bitcoin: a Peer-to-peer Electronic Cash System"
The project mostly languished in obscurity until in late 2010 it was revealed that Bitcoin was being used to evade the ban on Wikileaks contributions. (A good summary of Bitcoin's early history can be found here.)
Satoshi was opposed to Bitcoin being used for something as controversial as funding Wikileaks, and in one of his last messages, wrote "It would have been nice to get this attention in any other context. WikiLeaks has kicked the hornet's nest, and the swarm is headed towards us." (link). Satoshi vanished shortly thereafter.
When Satoshi disappeared, he left the project effectively in the control of Gavin Andresen, one of the early contributors to the project. Gavin has been characterized as something of a naive academic. It wasn't long before Gavin had been approached by the CIA and agreed to visit and do a presentation. So we know that Bitcoin was on the CIA's radar by 2011.
Bitcoin-as-introduced had an Achilles heel. To prevent a specific kind of denial-of-service attack, Satoshi had added a "block size limit" to prevent flooding attacks. Satoshi's plan was to raise the limit as usage increased. Satoshi and the early Bitcoiners such as myself did not envision that the limit might itself be a vulnerability. A near-complete history of the block size limit controversy is here. I'll attempt to summarize my experience with some references.
Now it's almost 2020, and by now we've all become much more attuned to the scope of what three-letter-agencies have been doing to manipulate social media platforms. But in 2012 that was tinfoil-hat stuff across most of the internet.
In 2012, the Bitcoin subreddit was one of the key places people went for discussion about what was happening in Bitcoin. That, and the bitcointalk forum. The history of what happened has been well documented with sources in places like here and here.
The TLDR is
Throughout all of this, Blockstream steadfastly argued that it didn't control the Bitcoin Core software. Blockstream pointed to Chaincode Labs who funded several key bitcoin developers and the MIT Media Labs "Digital Currency Initiative" who funded Gavin, Cory, and Wladimir. Gavin and Wladimir in particular had the authority to merge changes into the Bitcoin Core software and as such effectively could decide what did and did not go into the software. As an ostensibly academic organization, Gavin and Wladimir etc could act with intellectual honesty and without coercion.
Except Gavin left the Digital Currency Initiative in 2017, saying that while he wasn't pressured to quit, he "didn't want to feel obligated to any person or organization."
Fast forward to 2019, and we learn the fascinating news that the MIT Media Labs were funded in part by none other than Jeffrey Epstein, who it turns out just so happened to be a staunch advocate of the Blockstream approach. So really, Bitcoin development was corralled: Blockstream was paying a bunch of devs, and Blockstream-Friendly MIT Media Labs were paying the others.
If you're still reading this, you probably wonder what it is about the Blockstream strategy that is so "bad." Aren't they just proposing a different way to solve Bitcoin's problems?
The original idea for Bitcoin was a "peer to peer cash system" - - the idea being that if Alice wants to buy something from Bob, she can just give him some tokens - - just like cash.
The new vision of bitcoin promoted by Blockstream and Core is "store of value". Under this model, you buy Bitcoins like you might speculate on gold - you buy some and you hold it. Later, if you want to purchase something, you sell your Bitcoins for some other payment method (or use an IOU against a deposit, just like a bank), and use that for purchases.
It should be apparent after a moment of thought that the original concept (Alice hands Bob some cash which Bob can then spend how he likes) is vastly more disruptive than the model in which Alice buys Bitcoin on a government-regulated exchange, holds them hoping they'll appreciate in value, and then sells them for Euros or dollars. In model one, the currency is essentially outside the domain of gatekeepers, and could completely disintermediate the entire existing financial system just like Napster for money. In model two, Bitcoin is no more disruptive than shares of a gold fund.
submitted by jessquit to btc [link] [comments]

Core/AXA/Blockstream CTO Greg Maxwell, CEO Adam Back, attack dog Luke-Jr and censor Theymos are sabotaging Bitcoin - but they lack the social skills to even feel guilty for this. Anyone who attempts to overrule the market and limit or hard-code Bitcoin's blocksize must be rejected by the community.

Centrally planned blocksize is not a desirable feature - it's an insidious bug which is slowly and quietly suppressing Bitcoin's adoption and price and market cap.
And SegWit's dangerous "Anyone-Can-Spend" hack isn't just a needless kludge (which Core/Blockstream/AXA are selfishly trying to quietly slip into Bitcoin via a dangerous and messy soft fork - because they're deathly afraid of hard fork, knowing that most people would vote against their shitty code if they ever had the balls to put it up for an explicit, opt-in vote).
SegWit-as-a-soft-fork is a poison-pill for Bitcoin
SegWit is brought to you by the anti-Bitcoin central bankers at AXA and the economically ignorant, central blocksize planners at Blockstream whose dead-end "road map" for Bitcoin is:
AXA is trying to sabotage Bitcoin by paying the most ignorant, anti-market devs in Bitcoin: Core/Blockstream
This is the direction that Bitcoin has been heading in since late 2014 when Blockstream started spreading their censorship and propaganda and started bribing and corrupting the "Core" devs using $76 million in fiat provided by corrupt, anti-Bitcoin "fantasy fiat" finance firms like the debt-backed, derivatives-addicted insurance mega-giant AXA.
You Do The Math, and follow the money, and figure out why Bitcoin has been slowly failing to prosper ever since AXA started bribing Core devs to cripple our code with their centrally planned blocksize and now their "Anyone-Can-Spend" SegWit poison-pill.
Smart, honest devs fix bugs. Fiat-fueled AXA-funded Core/Blockstream devs add bugs - and then turn around and try to lie to our face and claim their bugs are somehow "features"
Recently, people discovered bugs in other Bitcoin implementations - memory leaks in BU's software, "phone home" code in AntMiner's firmware.
And the devs involved immediately took public responsibility, and fixed these bugs.
So the difference is: BU's and AntMiner's devs possess enough social and economic intelligence to fix bugs in their code immediately when the community finds them.
Meanwhile, most people in the community have been in an absolute uproar for years now against AXA-funded Blockstream's centrally planned blocksize and their deadly Anyone-Can-Spend hack/kludge/poison-pill.
Of course, the home-schooled fiat-fattened sociopath Blockstream CTO One-Meg Greg u/nullc would probably just dismiss all these Bitcoin users as the "shreaking" [sic] masses.
Narcissistic sociopaths like AXA-funded Blockstream CTO Greg Maxwell and CTO Adam and their drooling delusional attack dog Luke-Jr (another person who was home-schooled - which may help explain why he's also such a tone-deaf anti-market sociopath) are just too stupid and arrogant to have the humility and the shame to shut the fuck up and listen to the users when everyone has been pointing out these massive lethal bugs in Core's shitty code.
Greg, Adam, Luke-Jr, and Theymos are the most damaging people in Bitcoin
These are the four main people who are (consciously or unconsciously) attempting to sabotage Bitcoin:
These toxic idiots are too stupid and shameless and sheltered - and too anti-social and anti-market - to even begin to recognize the lethal bugs they have been trying to introduce into Bitcoin's specification and our community.
Users decide on specifications. Devs merely provide implementations.
Guys like Greg think that they're important because they can do implemenation-level stuff (like avoiding memory leaks in C++ code).
But they are total failures when it comes to specification-level stuff (ie, they are incapable of figuring out how to "grow" a potentially multi-trillion-dollar market by maximally leveraging available technology).
Core/Blockstream is living in a fantasy world. In the real world everyone knows (1) our hardware can support 4-8 MB (even with the Great Firewall), and (2) hard forks are cleaner than soft forks. Core/Blockstream refuses to offer either of these things. Other implementations (eg: BU) can offer both.
Greg, Adam, Luke-Jr and Theymos apparently lack the social and economic awareness and human decency to feel any guilt or shame for the massive damage they are attempting to inflict on Bitcoin - and on the world.
Their ignorance is no excuse
Any dev who is ignorant enough to attempt to propose adding such insidious bugs to Bitcoin needs to be rejected by the Bitcoin community - no matter how many years they keep on loudly insisting on trying to sabotage Bitcoin like this.
The toxic influence and delusional lies of AXA-funded Blockstream CTO Greg Maxwell, CEO Adam Back, attack dog Luke-Jr and censor Theymos are directly to blame for the slow-motion disaster happening in Bitcoin right now - where Bitcoin's market cap has continued to fall from 100% towards 60% - and is continuing to drop.
When bitcoin drops below 50%, most of the capital will be in altcoins. All they had to do was increase the block size to 2mb as they promised. Snatching defeat from the jaws of victory.
u/FormerlyEarlyAdopter : "I predict one thing. The moment Bitcoin hard-forks away from Core clowns, all the shit-coins out there will have a major sell-off." ... u/awemany : "Yes, I expect exactly the same. The Bitcoin dominance index will jump above 95% again."
Market volume (ie, blocksize) should be decided by the market - not based on some arbitrary number that some ignorant dev pulled out of their ass
For any healthy cryptocurrency, market price and market capitalization and market volume (a/k/a "blocksize") are determined by the market - not by any dev team, not by central bankers from AXA, not by economically ignorant devs like Adam and Greg (or that other useless idiot - Core "Lead Maintainer" Wladimir van der Laan), not by some drooling pathological delusional authoritarian freak like Luke-Jr, and not by some petty tyrant and internet squatter and communmity-destroyer like Theymos.
The only way that Bitcoin can survive and prosper is if we, as a community, denounce and reject these pathological "centralized blocksize" control freaks like Adam and Greg and Luke and Theymos who are trying to use tricks like fiat and censorship and lies (in collusion with their army of trolls organized and unleashed by the Dragons Den) to impose their ignorance and insanity on our currency.
These losers might be too ignorant and anti-social to even begin to understand the fact that they are attempting to sabotage Bitcoin.
But their ignorance is no excuse. And Bitcoin is getting ready to move on and abandon these losers.
There are many devs who are much better than Greg, Adam and Luke-Jr
A memory leak is an implementation error, and a centrally planned blocksize is a specification error - and both types of errors will be avoided and removed by smart devs who listen to the community.
There are plenty of devs who can write Bitcoin implementations in C++ - plus plenty of devs who can write Bitcoin implementations in other languages as well, such as:
Greg, Adam, Luke-Jr and Theymos are being exposed as miserable failures
AXA-funded Blockstream CTO Greg Maxwell, CEO Adam Back, their drooling attack dog Luke-Jr and their censor Theymos (and all the idiot small-blockheads, trolls, and shills who swallow the propaganda and lies cooked up in the Dragons Den) are being exposed more and more every day as miserable failures.
Greg, Adam, Luke-Jr and Theymos had the arrogance and the hubris to want to be "trusted" as "leaders".
But Bitcoin is the world's first cryptocurrency - so it doesn't need trust, and it doesn't need leaders. It is decentralized and trustless.
C++ devs should not be deciding Bitcoin's volume. The market should decide.
It's not suprising that a guy like "One-Meg Greg" who adopts a nick like u/nullc (because he spends most of his life worrying about low-level details like how to avoid null pointer errors in C++ while the second-most-powerful fiat finance corporation in the world AXA is throwing tens of millions of dollars of fiat at his company to reward him for being a "useful idiot") has turned to be not very good at seeing the "big picture" of Bitcoin economics.
So it also comes as no suprise that Greg Maxwell - who wanted to be the "leader" of Bitcoin - has turned out to be one of most harmful people in Bitcoin when it comes to things like growing a potentially multi-trillion-dollar market and economy.
All the innovation and growth and discussion in cryptocurrencies is happening everywhere else - not at AXA-funded Blockstream and r\bitcoin (and the recently discovered Dragons Den, where they plan their destructive social engineering campaigns).
Those are the censored centralized cesspools financed by central bankers and overrun by loser devs and the mindless trolls who follow them - and supported by inefficient miners who want to cripple Bitcoin with centrally planned blocksize (and dangerous "Anyone-Can-Spend" SegWit).
Bitcoin is moving on to bigger blocks and much higher prices - leaving AXA-funded Blockstream's crippled censored centrally planned shit-coin in the dust
Let them stagnate in their crippled shit-coin with its centrally planned, artificial, arbitrary 1MB 1.7MB blocksize, and SegWit's Anyone-Can-Spend hack kludge poison-pill.
Bitcoin is moving on without these tyrants and liars and losers and sociopaths - and we're going to leave their crippled censored centrally planned shit-coin in the dust.
Core/Blockstream are now in the Kübler-Ross "Bargaining" phase - talking about "compromise". Sorry, but markets don't do "compromise". Markets do COMPETITION. Markets do winner-takes-all. The whitepaper doesn't talk about "compromise" - it says that 51% of the hashpower determines WHAT IS BITCOIN.
Core/Blockstream is living in a fantasy world. In the real world everyone knows (1) our hardware can support 4-8 MB (even with the Great Firewall), and (2) hard forks are cleaner than soft forks. Core/Blockstream refuses to offer either of these things. Other implementations (eg: BU) can offer both.
1 BTC = 64 000 USD would be > $1 trillion market cap - versus $7 trillion market cap for gold, and $82 trillion of "money" in the world. Could "pure" Bitcoin get there without SegWit, Lightning, or Bitcoin Unlimited? Metcalfe's Law suggests that 8MB blocks could support a price of 1 BTC = 64 000 USD
Bitcoin Original: Reinstate Satoshi's original 32MB max blocksize. If actual blocks grow 54% per year (and price grows 1.542 = 2.37x per year - Metcalfe's Law), then in 8 years we'd have 32MB blocks, 100 txns/sec, 1 BTC = 1 million USD - 100% on-chain P2P cash, without SegWit/Lightning or Unlimited
submitted by ydtm to btc [link] [comments]

SegWit would make it HARDER FOR YOU TO PROVE YOU OWN YOUR BITCOINS. SegWit deletes the "chain of (cryptographic) signatures" - like MERS (Mortgage Electronic Registration Systems) deleted the "chain of (legal) title" for Mortgage-Backed Securities (MBS) in the foreclosure fraud / robo-signing fiasco

Summary (TL;DR)

Many people who study the financial crisis which started in 2008 know about "MERS", or "Mortgage Electronic Registration Systems" - a company / database containing over 62 million mortgages.
(The word "mortgages" may be unfamiliar to some non-English speakers - since it is not a cognate with most other languages. In French, they say "hypothèques", or "hipotecas" in Spanish, "Hypotheken" in German, etc).
The goal of MERS was to "optimize" the process of transferring "title" (legal ownership) of real-estate mortgages, from one owner to another.
But instead, in the 2010 "foreclosure crisis", MERS caused tens of billions of dollars in losses and damages - due to the "ususual" way it handled the crucial "ownership data" for real-estate mortgages - the data at the very heart of the database.
How did MERS handle this crucial "ownership data" for real-estate mortgages?
The "brilliant" idea behind MERS to "optimize" the process of conveying (transferring) mortgages was to separate - and eventually delete - all the data proving who transferred what to whom!
Hmm... that sounds vaguely familiar. What does that remind me of?
SegWit separating and then deleting the "chain of (cryptographic) signatures" for bitcoins sounds a lot like MERS separating and then deleting the "chain of (legal) title" for mortgages.
So, SegWit and MERS have a lot in common:
Of course, the "experts" (on Wall Street, and at AXA-owned Blockstream) present MERS and SegWit as "innovations" - as a way to "optimize" and "streamline" vast chains of transactions reflecting ownership and transfer of valuable items (ie, real-estate mortgages, and bitcoins).
But, unfortunately, the "brilliant bat-shit insane approach" devised by the "geniuses" behind MERS and SegWit to do this is to simply delete the data which proved ownership and transfer of these items - information which is essential for legal purposes (in the case of mortgages), or security purposes (in the case of bitcoins).
So, the most pernicious aspect of SegWit may be that it encourages deleting all of Bitcoin's cryptographic security data - destroying the "chain of signatures" which (according to the white paper) are what define what a "bitcoin" actually is.
Wow, deleting signatures with SegWit sounds bad. Can I avoid SegWit?
Yes you can.
To guarantee the long-term cryptographic, legal and financial security of your bitcoins:


MERS = "The dog ate your mortgage's chain of title".
SegWit = "The dog ate your bitcoin's chain of signatures."
Wall Street-backed MERS = AXA-backed SegWit
It is probably no coincidence that:
How is AXA related to Blockstream?
Insurance multinational AXA, while not a household name, is actually the second-most-connected "fiat finance" firm in the world.
AXA's former CEO Pierre Castries was head of the secretive Bilderberg Group of the world's ultra-rich. (Recently, he moved on to HSBC.)
Due to AXA's massive exposure to derivatives (bigger than any other insurance company), it is reasonable to assume that AXA would be destroyed if Bitcoin reaches trillions of dollars in market cap as a major "counterparty-free" asset class - which would actually be quite easy using simple & safe on-chain scaling - ie, just using bigger blocks, and no SegWit.
So, the above facts provide one plausible explanation of why AXA-owned Blockstream seems to be quietly trying to undermine Bitcoin...
Do any Core / Blockstream devs and supporters know about MERS - and recognize its dangerous parallels with SegWit?
It would be interesting to hear from some of the "prominent" Core / Blockstream devs and supporters listed below to find out if they are aware of the dangerous similarities between SegWit and MERS:
Finally, it could also be interesting to hear from:
Core / Blockstream devs might not know about MERS - but AXA definitely does
While it is likely that most or all Core / Blockstream devs do not know about the MERS fiasco... is 100% certain that people at AXA (the main owners of Blockstream) do know about MERS.
This is because the global financial crisis which started in 2008 was caused by:
The major financial media and blogs (Naked Capitalism, Zero Hedge, Credit Slips, Washington's Blog, etc.) covered MERS extensively:
So people at all the major "fiat finance firms" such as AXA would of course be aware of CDOs, MBSs and MERS - since these have been "hot topics" in their industry since the start of the global financial crisis in 2008.
Eerie parallels between MERS and SegWit
Read the analysis below of MERS by legal scholar Christopher Peterson - and see if you notice the eerie parallels with SegWit (with added emphasis in bold, and commentary in square brackets):
Loans originated with MERS as the original mortgagee purport to separate the borrower’s promissory note, which is made payable to the originating lender, from the borrower’s conveyance of a mortgage, which purportedly is granted to MERS. If this separation is legally incorrect - as every state supreme court looking at the issue has agreed - then the security agreements do not name an actual mortgagee or beneficiary.
The mortgage industry, however, has premised its proxy recording strategy on this separation, despite the U.S. Supreme Court’s holding that “the note and mortgage are inseparable.” [Compare with the language from Satoshi's whitepaper: "We define an electronic coin as a chain of digital signatures."]
If today’s courts take the Carpenter decision at its word, then what do we make of a document purporting to create a mortgage entirely independent of an obligation to pay? If the Supreme Court is right that a “mortgage can have no separate existence” from a promissory note, then a security agreement that purports to grant a mortgage independent of the promissory note attempts to convey something that cannot exist.
Many courts have held that a document attempting to convey an interest in realty fails to convey that interest if the document does not name an eligible grantee. Courts around the country have long held that “there must be, in every grant, a grantor, a grantee and a thing granted, and a deed wanting in either essential is absolutely void.”
The parallels between MERS and SegWit are obvious and inescapable.
Note that I am not arguing here that SegWit could be vulnerable to attacks from a strictly legal perspective. (Although that may be possible to.)
I am simply arguing that SegWit, because it encourages deleting the (cryptographic) signature data which defines "bitcoins", could eventually be vulnerable to attacks from a cryptographic perspective.
But I heard that SegWit is safe and tested!
Yeah, we've heard a lot of lies from Blockstream, for years - and meanwhile, they've only succeeded in destroying Bitcoin's market cap, due to unnecessarily high fees and unnecessarily slow transactions.
Now, in response to those legal-based criticisms of SegWit in the article from nChain, several so-called "Bitcoin legal experts" have tried to rebut that those arguments from nChain were somehow "flawed".
But if you read the rebuttals of these "Bitcoin legal experts", they sound a lot like the clueless "experts" who were cheerleading MERS for its "efficiency" - and who ended up costing tens billions of dollars in losses when the "chain of title" for mortgages held in the MERS database became "clouded" after all the crucial "ownership data" got deleted in the name of "efficiency" and "optimization".
In their attempt to rebut the article by nChain, these so-called "Bitcoin legal experts" use soothing language like "optimization" and "pragmatic" to try to lull you into believing that deleting the "chain of (cryptographic) signatures" for your bitcoins will be just as safe as deleting the "chain of (legal) notes" for mortgages:
The (unsigned!) article on CoinDesk attempting to rebut Nguyen's article on nChain starts by stating:
Nguyen's criticisms fly in the face of what has emerged as broad support for the network optimization, which has been largely embraced by the network's developers, miners and startups as a pragmatic step forward.
Then it goes on to quote "Bitcoin legal experts" who claim that using SegWit to delete Bitcoin's cryptographic signatures will be just fine:
Marco Santori, a fintech lawyer who leads the blockchain tech team at Cooley LLP, for example, took issue with what he argued was the confused framing of the allegation.
Santori told CoinDesk:
"It took the concept of what is a legal contract, and took the position that if you have a blockchain signature it has something to do with a legal contract."
Stephen Palley, counsel at Washington, DC, law firm Anderson Kill, remarked similarly that the argument perhaps put too much weight on the idea that the "signatures" involved in executing transactions on the bitcoin blockchain were or should be equivalent to signatures used in digital documents.
"It elides the distinction between signature and witness data and a digital signature, and they're two different things," Palley said.
"There are other ways to cryptographically prove a transaction is correctly signed other than having a full node," said BitGo engineer Jameson Lopp. "The assumption that if a transaction is in the blockchain, it's probably valid, is a fairly good guarantee."
Legal experts asserted that, because of this design, it's possible to prove that the transaction occurred between parties, even if those involved did not store signatures.
For this reason, Coin Center director Jerry Brito argued that nChain is overstating the issues that would arise from the absence of this data.
"If you have one-time proof that you have the bitcoin, if you don't have it and I have it, logically it was signed over to me. As long as somebody in the world keeps the signature data and it's accessible, it's fine," he said.
There are several things you can notice here:
  • These so-called "Bitcoin legal experts" are downplaying the importance of signatures in Bitcoin - just like the "experts" behind MERS downplayed the importance of "notes" for mortgages.
  • Satoshi said that a bitcoin is a "chain of digital signatures" - but these "Bitcoin legal experts" are now blithely asserting that we can simply throw the "chain of digital signatures" in the trash - and we can be "fairly" certain that everything will "probably" be ok.
  • The "MERS = SegWit" argument which I'm making is not based on interpreting Bitcoin signatures in any legal sense (although some arguments could be made along those lines).
  • Instead, I'm just arguing that any "ownership database" which deletes its "ownership data" (whether it's MERS or SegWit) is doomed to end in disaster - whether that segregated-and-eventually-deleted "ownership data" is based on law (with MERS), or cryptography (with SegWit).
Who's right - Satoshi or the new "Bitcoin experts"?
You can make up your own mind.
Personally, I will never send / receive / store large sums of money using any "SegWit" bitcoin addresses.
This, is not because of any legal considerations - but simply because I want the full security of "the chain of (cryptographic) signatures" - which, according to the whitepaper, is the very definition of what a bitcoin "is".
Here are the words of Satoshi, from the whitepaper, regarding the "chain of digital signatures":
We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin. A payee can verify the signatures to verify the chain of ownership.
Does that "chain of digital signatures" sound like something you'd want to throw in the trash??
  • The "clever devs" from AXA-owned Blockstream (and a handful of so-called "Bitcoin legal experts) say "Trust us, it is safe to delete the chain of signatures proving ownership and transfer of bitcoins". They're pushing "SegWit" - the most radical change in the history of Bitcoin. As I have repeatedly discussed, SegWit weakens Bitcoin's security model.
  • The people who support Satoshi's original Bitcoin (and clients which continue to implement it: Bitcoin ABC, Bitcoin Unlimited, Bitcoin, Bitcoin Classic - all supporting "Bitcoin Cash" - ie "Bitcoin" without SegWit) say "Trust no one. You should never delete the chain of signatures proving ownership and transfer of your bitcoins."
  • Satoshi said:

We define an electronic coin as a chain of digital signatures.

  • So, according to Satoshi, a "chain of digital signatures" is the very definition of what a bitcoin is.
  • Meanwhile according to some ignorant / corrupt devs from AXA-owned Blockstream (and a handful of "Bitcoin legal experts") now suddenly it's "probably" "fairly" safe to just throw Satoshi's "chain of digital signatures" in the trash - all in the name of "innovation" and "efficiency" and "optimization" - because they're so very clever.
Who do you think is right?
Finally, here's another blatant lie from SegWit supporters (and small-block supporters)
Let's consider this other important quote from Satoshi's whitepaper above:
A payee can verify the signatures to verify the chain of ownership.
Remember, this is what "small blockers" have always been insisting for years.
They've constantly been saying that "blocks need to be 1 MB!!1 Waah!1!" - even though several years ago the Cornell study showed that blocks could already be 4 MB, with existing hardware and bandwidth.
But small-blockers have always insisted that everyone should store the entire blockchain - so they can verify their own transactions.
But hey, wait a minute!
Now they turn around and try to get you to use SegWit - which allows deleting the very data which insisted that you should download and save locally to verify your own transactions!
So, once again, this exposes the so-called "arguments" of small-blocks supporters as being fake arguments and lies:
  • On the one hand, they (falsely) claim that small blocks are necessary in order for everyone to be run "full nodes" because (they claim) that's the only way people can personally verify all their own transactions. By the way, there are already several errors here with what they're saying:
    • Actually "full nodes" is a misnomer (Blockstream propaganda). The correct terminology is "full wallets", because only miners are actually "nodes".
    • Actually 1 MB "max blocksize" is not necessary for this. The Cornell study showed that we could easily be using 4 MB or 8 MB blocks by now - since, as everyone knows, the average size of most web pages is already over 2 MB, and everyone routinely downloads 2 MB web pages in a matter of seconds, so in 10 minutes you could download - and upload - a lot more than just 2 MB. But whatever.
  • On the other hand, they support SegWit - and the purpose of SegWit is to allow people to delete the "signature data".
    • This conflicts with their argument the everyone should personally verify all their own transactions. For example, above, Coin Center director Jerry Brito was saying: "As long as somebody in the world keeps the signature data and it's accessible, it's fine."
    • So which is it? For years, the "small blockers" told us we needed to all be able to personally verify everything on our own node. And now SegWit supporters are telling us: "Naah - you can just rely on someone else's node."
    • Plus, while the transactions are still being sent around on the wire, the "signature data" is still there - it's just "segregated" - so you're not getting any savings on bandwidth anyways - you'd only get the savings if you delete the "signature data" from storage.
    • Storage is cheap and plentiful, it's never been the "bottleneck" in the system. Bandwidth is the main bottleneck - and SegWit doesn't help that at all, because it still transmits all the data.
So if you're confused by all the arguments from small-blockers and SegWitters, there's a good reason: their "arguments" are total bullshit and lies. They're attempting to contradict and destroy:
  • Satoshi's original design of Bitcoin as a "chain of digital signatures":
"We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin. A payee can verify the signatures to verify the chain of ownership."
  • Satoshi's plan for scaling Bitcoin by simply increasing the goddamn blocksize:
Satoshi Nakamoto, October 04, 2010, 07:48:40 PM "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."
  • The the notorious mortgage database MERS, pushed by clueless and corrupt Wall Street bankers, deleted the "chain of (legal) title" which had been essential to show who conveyed what mortgages to whom - leading to "clouded titles", foreclosure fraud, and robo-signing.
  • The notorious SegWit soft fork / kludge, pushed by clueless and corrupt AXA-owned Blockstream devs, allows deleting the "chain of (cryptographic) signatures" which is essential to show who sent how many bitcoins to whom - which could lead to a catastrophe for people who foolishly use SegWit addresses (which can be avoided: unsafe "SegWit" bitcoin addresses start with a "3" - while safe, "normal" Bitcoin addresses start with a "1").
  • Stay safe and protect your bitcoin investment: Avoid SegWit transactions.
[See the comments from me directly below for links to several articles on MERS, foreclosure fraud, robo-signing, "clouded title", etc.]
submitted by ydtm to btc [link] [comments]

Bitcoin is a captured system
Bitcoin Core is the reference client of bitcoin. Initially, the software was published by Satoshi Nakamotounder the name Bitcoin, and later renamed to Bitcoin Core to distinguish it from the network.[1] For this reason, it is also known as the Satoshi client.[2] It is the reference implementation for bitcoin nodes, which form the bitcoin network. Through changes to Bitcoin Core, its developers make changes to the underlying bitcoin protocol.[3] As of 2016, Bitcoin Core repositories are maintained by Wladimir J. van der Laan.[4]
What is a reference implementation?
In the software development process, a reference implementation (or, less frequently, sample implementation or model implementation) is the standard from which all other implementations and corresponding customizations are derived.
A reference implementation defines the protocol.
Bitcoin Core defines the reference implementation.
It is true that a majority of hashpower could choose to mine a fork that's different from the reference implementation, but by definition, this cannot be called "Bitcoin" because such a fork is not compatible with the "reference." It is an altcoin, by definition, because the reference defines "what is Bitcoin."
Whoever controls the development process of Bitcoin Core controls the definition of "what is Bitcoin." The system cannot be called decentralized. In fact it is indistinguishable from a corporate controlled coin and brand, like Ripple, as all power for decisions concerning the protocol is vested in the tiny handful of people that control the development process of Bitcoin Core.
Control the repo, control Bitcoin.
By definition.
Lesson learned for Bitcoin Cash: if the protocol is to be called "decentralized," there can be no formal definition of the specification. Instead there should be multiple interoperating specifications.
submitted by jessquit to btc [link] [comments]

My draft for a new /r/btc FAQ explaining the split from /r/Bitcoin to new users

If /btc is going to actually compete with /Bitcoin, it needs to be just as friendly and informative to new users, especially given its position as the “non default” or “breakaway” sub. The current /btc sticky saying "Welcome to the Wiki" doesn't even have any content in it and I feel this is a bit of a wasted opportunity to create an informative resource that new users will see by default and everyone else can link to instead of retyping things over and over about the history and difference between the subs.
Here's what I've written as a starting point. I've done my best to keep it as concise and relevant as possible but in all honesty it is a complicated issue and a short but effective explanation is basically impossible. I hope the community can expand/improve on it further.
Quick bit about me
I got into Bitcoin in October 2013, when /Bitcoin had around 40k subscribers if I remember correctly, so by now I've actually personally experienced a large portion of Bitcoin's history - including the events preceding and since the creation of this sub. I have been an active and popular poster on /Bitcoin for almost all of that time, until the split and my subsequent banning. With the recent censorship fiasco, I'm finding I have to reiterate the same points over and over again to explain to newer users what happened with the /Bitcoin vs /btc split, questions about hard forks, what is likely to happen in the future and so on. So I put a couple of hours into writing this post to save myself the trouble in future.

/btc FAQ - Historical split from /Bitcoin megathread - v0.1

There is a TL:DR; at the bottom, but it is exactly that. If you skip straight to the TL:DR; then don’t expect sympathy when you post questions that have already been covered in the lengthy and detailed main post.

New to Bitcoin?

I am totally new to Bitcoin. What is it? How does it work? Can/should I mine any? Where can I buy some? How do I get more information?
All of these questions are actually really well covered in the /Bitcoin FAQ. Check it out in a new tab here. Once you've got a bit of a handle on the technology as a whole, come back here for the rest of the story.

History: /btc vs /Bitcoin

What's the difference between /btc and /Bitcoin? What happened to create two such strongly opposed communities? Why can't I discuss /btc in /Bitcoin?
Historically, the /Bitcoin subreddit was the largest and most active forum for discussing Bitcoin. As Bitcoin grew close to a cap in the number of transactions it could process, known as the 1MB block size limit, the community had differing opinions on the best way to proceed. Note that this upcoming issue was anticipated well ahead of time, with Satoshi's chosen successor to lead the project Gavin Andresen posting about it in mid 2015. Originally, there was quite a broad spread of opinions - some people favoured raising the blocksize to various extents, some people favoured implementing a variety of second layer solutions to Bitcoin, probably most people thought both could be a good idea in one form or another.
This topic was unbelievably popular at the time, taking up almost every spot on the front page of /Bitcoin for weeks on end.
Unfortunately, the head moderator of /Bitcoin - theymos - felt strongly enough about the issue to use his influence to manipulate the debate. His support was for the proposal of existing software (called Bitcoin Core) NOT to raise the blocksize limit past 1MB and instead rely totally on second layer solutions - especially one called Segregated Witness (or SegWit). With some incredibly convoluted logic, he decided that any different implementations of Bitcoin that could potentially raise the limit were effectively equivalent to separate cryptocurrencies like Litecoin or Ethereum and thus the block size limit or implement other scaling solutions were off-topic and ban-worthy. At the time the most popular alternative was called Bitcoin XT and was supported by experienced developers Gavin Andresen and Mike Hearn, who have since both left Bitcoin Core development in frustration at their marginalisation. Theymos claimed that for Bitcoin XT or any other software implementation to be relevant to /Bitcoin required "consensus", which was never well defined, despite it being seemingly impossible for everyone to agree on the merits of a new project if no one was allowed to discuss it in the first place. Anyone who didn't toe the line of his vaguely defined moderation policy was temporarily or permanently banned. There was also manipulation of the community using the following tactics - which can still be seen today:
This created enormous uproar among users, as even many of those in favour of Bitcoin Core thought it was authoritarian to actively suppress this crucial debate. theymos would receive hundreds of downvotes whenever he posted: for example here where he gets -749 for threatening to ban prominent Bitcoin business Coinbase from the subreddit.
In an extraordinary turn of events, Theymos posted a thread which received only 26% upvotes in a sample size of thousands announcing that he did not care if even 90% of users disagreed with his policy, he would not change his opinion or his moderation policy to facilitate the discussion the community wanted to have. His suggested alternative was instead for those users, however many there were, to leave.
Here are Theymos' exact words, as he describes how he intends to continue moderating Bitcoin according to his own personal rules rather than the demands of the vast majority of users, who according to him clearly don't have any "real arguments" or "any brains".
Do not violate our rules just because you disagree with them. This will get you banned from /Bitcoin , and evading this ban will get you (and maybe your IP) banned from Reddit entirely.
If 90% of /Bitcoin users find these policies to be intolerable, then I want these 90% of /Bitcoin users to leave. Both /Bitcoin and these people will be happier for it. I do not want these people to make threads breaking the rules, demanding change, asking for upvotes, making personal attacks against moderators, etc. Without some real argument, you're not going to convince anyone with any brains -- you're just wasting your time and ours. The temporary rules against blocksize and moderation discussion are in part designed to encourage people who should leave /Bitcoin to actually do so so that /Bitcoin can get back to the business of discussing Bitcoin news in peace.
/btc was therefore born in an environment not of voluntary departure but of forced exile.
This forced migration caused two very unfortunate occurrences:
  1. It polarised the debate around Bitcoin scaling. Previously, there was a lot of civil discussion about compromise and people with suggestions from all along the spectrum were working to find the best solution. That was no longer possible when a moderation policy would actively suppress anyone with opinions too different from Theymos. Instead it forced everyone into a "with us or against us" situation, which is why the /btc subreddit has been pushed so far in favour of the idea of a network hard fork (discussed below).
  2. It has distracted Bitcoin from its mission of becoming a useful, global, neutral currency into a war of information. New users often find /Bitcoin and assume it to be the authoritative source of information, only to later discover that a lot of important information or debate has been invisibly removed from their view.
Since then, like any entrenched conflict, things have degenerated somewhat on both sides to name calling and strawman arguments. However, /btc remains committed to permitting free and open debate on all topics and allowing user downvotes to manage any "trolling" (as /Bitcoin used to) instead of automatic shadow-banning or heavy-handed moderator comment deletion (as /Bitcoin does now). Many users in /Bitcoin deny that censorship exists at all (it is difficult to see when anyone pointing out the censorship has their comment automatically hidden by the automoderator) or justify it as necessary removal of "trolls", which at this point now includes thousands upon thousands of current and often long-standing Bitcoin users and community members.
Ongoing censorship is still rampant, partially documented in this post by John Blocke
For another detailed account of this historical sequence of events, see singularity87 s posts here and here.
/btc has a public moderator log as demonstration of its commitment to transparency and the limited use of moderation. /Bitcoin does not.
Why is so much of the discussion in /btc about the censorship in /Bitcoin? Isn't a better solution to create a better community rather than constantly complaining?
There are two answers to this question.
  1. Over time, as /btc grows, conversation will gradually start to incorporate more information about the Bitcoin ecosystem, technology, price etc. Users are encouraged to aid this process by submitting links to relevant articles and up/downvoting on the /new and /rising tab as appropriate. However, /btc was founded effectively as a refuge for confused and angry users banned from /Bitcoin and it still needs to serve that function so at least some discussion of the censorship will probably always persist (unless there is a sudden change of moderation policy in /Bitcoin).
  2. The single largest issue in Bitcoin right now is the current cap on the number of transactions the network can process, known as the blocksize limit. Due to the censorship in /Bitcoin, open debate of the merits of different methods of addressing this problem is impossible. As a result, the censorship of /Bitcoin (historically the most active and important Bitcoin community forum) has become by proxy the single most important topic in Bitcoin, since only by returning to open discussion would there be any hope of reaching agreement on the solution to the block size limit itself. As a topic of such central importance, there is naturally going to be a lot of threads about this until a solution is found. This is simply how Bitcoin works, that at any one time there is one key issue under discussion for lengthy periods of time (previous examples of community "hot topics" include the demise of the original Bitcoin exchange Mt Gox, the rise to a 51% majority hash rate of mining pool and the supposed "unveiling" of Bitcoin's anonymous creator Satoshi Nakamoto).

Bitcoin Network Hard Forks

What is a hard fork? What happens if Bitcoin hard forks?
A network hard fork is when a new block of transactions is published under a new set of rules that only some of the network will accept. In this case, Bitcoin diverges from a single blockchain history of transactions to two separate blockchains of the current state of the network. With any luck, the economic incentive for all users to converge quickly brings everyone together on one side of the fork, but this is not guaranteed especially since there is not a lot of historical precedent for such an event.
A hard fork is necessary to raise the block size limit above its 1MB cap.
Why is /btc generally in favour of a hard fork and /Bitcoin generally against?
According to a lot of users on /Bitcoin - a hard fork can be characterised as an “attack” on the network. The confusion and bad press surrounding a hard fork would likely damage Bitcoin’s price and/or reputation (especially in the short term). They point to the ongoing turmoil with Ethereum as an example of the dangers of a hard fork. Most of /Bitcoin sees the stance of /btc as actively reckless, that pushing for a hard fork creates the following problems:
According to a lot of users on /btc - a hard fork is necessary despite these risks. Most of /btc sees the stance of /Bitcoin as passively reckless, that continuing to limit Bitcoin’s blocksize while remaining inactive creates the following problems:
Bitcoiners are encouraged to examine all of the information and reach their own conclusion. However, it is important to remember that Bitcoin is an open-source project founded on the ideal of free market competition (between any/all software projects, currencies, monetary policies, miners, ideas etc.). In one sense, /btc vs /Bitcoin is just another extension of this, although Bitcoiners are also encouraged to keep abreast of the top posts and links on both subreddits. Only those afraid of the truth need to cut off opposing information.
What do Bitcoin developers, businesses, users, miners, nodes etc. think?
There are developers on both sides of the debate, although it is a common argument in /Bitcoin to claim that the majority supports Bitcoin Core. This is true in the sense that Bitcoin Core is the current default and has 421 listed code contributors but misleading because not only are many of those contributors authors of a single tiny change and nothing else but also many major figures like Gavin Andresen, Mike Hearn and Jeff Garzik have left the project while still being counted as historical contributors.
Businesses including exchanges etc.
A definite vote of confidence is not available from the vast majority of Bitcoin businesses, and wouldn't be binding in any case. The smart decision for most businesses is to support both chains in the event of a fork until the network resolves the issue (which may only be a day or two).
Exact user sentiment is impossible to determine, especially given the censorship on /Bitcoin.
Miners and Nodes hosts some excellent graphical representations of the current opinion on the network.
Node Support Information
Miner Support Information
What do I do if the network hard forks?* Do we end up with two Bitcoins?
Firstly, in the event of a hard fork there is no need to panic. All Bitcoins are copied to both chains in the case of a split, so any Bitcoins you have are safe. HOWEVER, in the event of a fork there will be some period of confusion where it is important to be very careful about how/why you spend your Bitcoins. Hopefully (and most likely) this would not last long - everyone in Bitcoin is motivated to converge into agreement for everyone's benefit as soon as possible - but it's impossible to say for sure.
There isn't a lot of historical data about cryptocurrency hard forks, but one example is alternative cryptocurrency Ethereum that forked into two coins after the events of the DAO and currently exists as two separate chains, ETH (Ethereum) and ETC (Ethereum Classic).
The Ethereum fork is not a good analogy for Bitcoin because its network difficulty target adjusts every single block, so a massive drop in hash rate does not significantly impede its functioning. Bitcoin’s difficult target adjusts only every 2100 blocks - which under usual circumstances takes two weeks but in the event of a hard fork could be a month or more for the smaller chain. It is almost inconceivable that a minority of miners would willingly spend millions of dollars over a month or more purely on principle to maintain a chain that was less secure and processed transactions far slower than the majority chain - even assuming the Bitcoins on this handicapped chain didn't suffer a market crash to close to worthless.
Secondly, a hard fork is less likely to be a traumatic event than it is often portrayed in /Bitcoin:

What Happens Now

How do I check on the current status of opinion? hosts some excellent graphical representations of the current opinion on the network.
Node Support Information
Miner Support Information
Users are also welcome to engage in anecdotal speculation about community opinion based on their impression of the commentary and activity in /btc and /Bitcoin.
Haven't past attempts to raise the blocksize failed?
There is no time limit or statute of limitations on the number of attempts the community can make to increase the block size and scale Bitcoin. Almost any innovation in the history of mankind required several attempts to get working and this is no different.
The initial attempt called Bitcoin XT never got enough support for a fork because key developer Mike Hearn left out of frustration at trying to talk around all the censorship and community blockading.
The second major attempt called Bitcoin Classic gained massive community momentum until it was suddenly halted by the drastic implementation of censorship by Theymos described above.
The most popular attempt at the moment is called Bitcoin Unlimited.
/btc is neutral and welcoming to any and all projects that want to find a solution to scaling Bitcoin - either on-or off-chain. However, many users are suspicious of Bitcoin Core's approach that involves only SegWit, developed by a private corporation called Blockstream and that has already broken its previous promises in a document known as the Hong Kong Agreement to give the network a block size limit raise client along with Segregated Witness (only the latter was delivered) .
What if the stalemate is irreconcilable and nothing ever happens?
Increasing transaction fees and confirmation times are constantly increasing the pressure to find a scaling solution - leading some to believe that further adoption of Bitcoin Unlimited or a successor scaling client will eventually occur. Bitcoin Core's proposed addition of SegWit is struggling to gain significant support and as it is already the default client (and not censored in /Bitcoin) it is unlikely to suddenly grow any further.
If the stalemate is truly irreconcilable, eventually users frustrated by the cost, time and difficulty of Bitcoin will begin migrating to alternative cryptocurrencies. This is obviously not a desirable outcome for long standing Bitcoin supporters and holders, but cannot be ignored as the inevitable free market resort if Bitcoin remains deadlocked for long enough.


I don’t know anything about Bitcoin. Help me?
What’s the /btc vs /Bitcoin story?
  • Bitcoin is at its transaction capacity and needs to scale to onboard more users
  • The community was discussing different ways to do this until the biased head moderator of /Bitcoin Theymos got involved
  • Theymos, started an authoritarian censorship rampage which culminated in telling 90% of /Bitcoin users to leave. /btc is where they went. Here is the thread where it all started. Note the 26% upvoted on the original post, the hundreds of upvotes of community outcry in the comments and the graveyard of [removed] posts further down the chain. Highly recommended reading in its entirety.
  • To this day, /Bitcoin bans all discussion of alternative scaling proposals and /btc
  • Bitcoin is about freedom, and can’t function effectively with either an artificially restricted transaction cap or a main community forum that is so heavily manipulated. This subreddit is the search for solutions to both problems as well as general Bitcoin discussion.
What’s the deal with hard forks?
  • No TL:DR; possible, read the whole post.
What happens now?
  • Node Support Information
  • Miner Support Information
  • Debate continues in /btc, and generally doesn't continue in /Bitcoin - although posts referencing /btc or Bitcoin Unlimited regularly sneak past the moderators because it is such a crucial topic
  • Eventually one side or the other breaks, enough miners/nodes/users get on one side and Bitcoin starts scaling. This may or may not involve a hard fork.
  • If not, fees and average confirmation times continue to rise until users migrate en masse to an altcoin. This is not an imminent danger, as can be seen by the BTC marketcap dominance at its historical levels of 80+% but could change at any time
submitted by Shibinator to btc [link] [comments]

List of people who have had commit access to Bitcoin Core

I decided to attempt to figure out who has ever had commit access to Bitcoin Core's git repository and from when to when. I also posted this on Bitcointalk, but I will not link the thread due to the doxxing rule (that thread contains real names taken from the commit messages).
This list contains the git names (to avoid doxxing) of everyone who I can find evidence for ever having commit access to Bitcoin Core, the dates during which they had commit access, sources for all of this information, and reasoning for the access. Those who currently have commit access are in bold.
Other Notes:
After scrolling through nearly the entire git merges history, I have found a couple of interesting things.
Satoshi did not use a Version Control System originally. The releases and source code were originally in a rar file that was uploaded to Sirius had to setup the original SVN repository on SourceForge for him. This was then later migrated to GitHub by gavinandresen. Originally patches were authored by developers and then emailed to Satoshi, Sirius, or gavinandresen who then committed the changes to the source tree with the commit message containing the attribution, but not the actual commit itself.
Another interesting fact is that the giving out of commit access has become more strict. It is now a privilege held by those given maintainer positions and those whose privilege was grandfathered in (i.e. they had it previously and kept it). Previously it was simply given out to those who contributed frequently and revoked after they stopped contributing. This appears to be no longer the case, although there are still multiple people who can commit to the repository so that there is not any reliance on one person. The maintainers are still given to frequent contributors as the maintainers are frequent contributors to the set of functionality for which they are maintainers of. They received the positions because of frequent contributions to those functionalities.
Lastly, I could not find any evidence for Satoshi ever publicly announcing that gavinandresen was to be the Lead Maintainer after him. It seems that Gavin was already a frequent contributor and already had commit access for a while before Satoshi disappeared. After Satoshi disappeared and Sirius stopped contributing as much, gavinandresen simply took over the role as lead maintainer as he was the only frequent contributor with commit access.
Dooglus -> dooglus
jgarzik's commit access was revoked a while ago.
Bolded those who still actively contribute to the project
Clarified how maintainers got their roles
submitted by achow101 to Bitcoin [link] [comments]

Bitcoin dev IRC meeting in layman's terms (2016-01-14)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last summarisation
Please bear in mind I'm not a developer so some things might be incorrect or plain wrong. There are no decisions being made in these meetings, but since a fair amount of devs are present it's a good representation. Copyright: Public domain


Main topics



BIP 9 Currently softforks have been done by the isSuperMajority mechanism, meaning when 95% of the last 1000 blocks have a version number higher than X the fork is deployed. A new way of doing this is currently being worked on and that uses all bits of the version number, appropriately being called versionbits. So instead of a fork happening when the version is larger than (for example) 00000000011 (3), a fork happens when (for example) the 3rd bit is up (so 00100000011). This way softforks can be deployed simultaneous and independent of each other.

meeting comments

Morcos is volunteering to take over championing this proposal as CodeShark and Rusty are busy on other things. He'll review both implementations and then decide on which implementation he'll base his work upon. He notes that if non-core implementations are trying to do something else (and are using nVersion for their signaling) while segregated witness is being deployed, not conflicting will be important so users of other versions can also support segregated witness. If there's an agreement with this approach it's necessary that versionbits is ready before the segregated witness deployment. jtimon has some suggestions to make the implementation less complicated and more flexible.

meeting conclusion

Morcos will champion the new reference implementation for BIP9: Versionbits.

Status of segregated witness


Segregated witness changes the structure of transactions so that the signatures can be separated from the rest of the transactions. This allows for bandwidth savings for relay, pruning of old signatures, softforking all future script changes by introducing script versions and solves all unintentional forms of malleability. During the last scaling bitcoin conference Pieter Wuille presented a way of doing this via a softfork, and proposed increasing the maximum amount of transactions in a block by discounting signature data towards the total blocksize. Segregated witness is part of the capacity increase roadmap for bitcoin-core. More detailed explanations: - By Pieter Wuille at the San Francisco bitcoin developer meetup (more technical) - By Andreas Antonopoulos in the let's talk bitcoin podcast (less technical)

meeting comments

Segnet, the testnet for segregated transactions, will be going to it's 3rd version soon. Luke-Jr has assigned all the segregated witness BIPs to a 14x range. Currently there are 4 BIPs: 141, 142, 143 and 144.

Status of 0.12 bitcoin-core release


Bitcoin Core 0.12 is scheduled for release around February and introduces a lot of fixes and improvements. (release notes) There's a release candidate 0.12rc1 available at

meeting comments

Luke-Jr feels PR's #7149, #7339 and #7340 should have been in 0.12, but are now really late and possibly impractical to get in. For gitian builders: 0.12rc1's osx sig attach descriptor fails due to a missing package (that's not actually needed). Rather than using the in-tree descriptor, use the one from #7342. This is fixed for rc2. "fundrawtransaction" and "setban" should be added to the release notes. At some point it makes more sense to document these commands elsewhere and link to it in the release notes, as they've become very lengthy. Wumpus thinks the release notes have too much details, they're not meant to be a substitute for documentation.

meeting conclusion

Close PR #7142 as it's now part of #7148 Everyone is free to improve on the release notes, just submit a PR.

consensus code encapsulation (libconsensus)


Satoshi wasn't the best programmer out there, which leaves a pretty messy code. Ideally you'd have the part of the code that influences the network consensus separate, but in bitcoin it's all intertwined. Libconsensus is what eventually should become this part. This way people can more easily make changes in the non-consensus part without fear of causing a network fork. This however is a slow and dangerous project of moving lots of code around.

meeting comments

jtimon has 4 libconsensus related PRs open, namely #7091 #7287 #7311 and #7310 He thinks any "big picture branch" will be highly unreadable without merging something like #7310 first. The longest "big picture branch" he currently has is He'll document the plan and "big picture" in stages: 1. have something to call libconsensus: expose verifyScript. (Done) 2. put the rest of the consensus critical code, excluding storage in the same building package (see #7091) 3. discuss a complete C API for libconsensus 4. separate it into a sub-repository Wumpus notes he'd like to start with 3 as soon as possible as an API would be good to guide this.

meeting conclusion

review #7091 #7287 #7311 and #7310

Locktime PRs


BIP 68 Consensus-enforced transaction replacement signaled via sequence numbers. BIP 112 CHECKSEQUENCEVERIFY. BIP 113 Median time-past as endpoint for lock-time calculations. In short: BIP 68 changes the meaning of the sequence number field to a relative locktime. BIP 112 makes that field accessible to the bitcoin scripting system. BIP 113 enables the usage of GetMedianTimePast (the median of the previous 11 blocks) from the prior block in lock-time transactions.

meeting comments

We need to make a choice between 2 implementations, namely #6312 and #7184. PR #7184 is a result of the CreateNewBlock optimisations not being compatible with #6312. jtimon thinks it could be merged relatively soon as #7184 is based on #6312 which has plenty of testing and review.

meeting conclusion

Close #6312 in favor of #7184. Morcos will fix the open nits on #7184 btcdrak will update the BIP-text


wumpus Wladimir J. van der Laan btcdrak btcdrak morcos Alex Morcos jtimon Jorge Timón Luke-Jr Luke Dashjr MarcoFalke Marco Falke jonasshnelli Jonas Schnelli cfields Cory Fields sipa Pieter Wuille kanzure Bryan Bishop droark Douglas Roark sdaftuar Suhas Daftuar Diablo-D3 Patrick McFarland 

Comic relief

19:54 wumpus #meetingstop 19:54 wumpus #stopmeeting 19:54 btcdrak haha 19:54 MarcoFalke #closemeeting 19:54 wumpus #endmeeting 19:54 lightningbot` Meeting ended Thu Jan 14 19:54:26 2016 UTC. Information about MeetBot at . (v 0.1.4) 
submitted by G1lius to Bitcoin [link] [comments]

Bitcoin dev IRC meeting in layman's terms (2015-11-12)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last weeks summarization Note that I crosspost this to Voat, and the bitcoin-discuss mailing list every week. I can't control what's being talking about in the meeting, if certain things come up I might not be able to post here because of "guidelines".
Please bear in mind I'm not a developer and I'd have problems coding "hello world!", so some things might be incorrect or plain wrong. Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can. There are no decisions being made in these meetings, so if I say "everyone agrees" this means everyone present in the meeting, that's not consensus, but since a fair amount of devs are present it's a good representation. The dev IRC and mailinglist are for bitcoin development purposes. If you have not contributed actual code to a bitcoin-implementation, this is probably not the place you want to reach out to. There are many places to discuss things that the developers read, including this sub-reddit.
link to this week logs Meeting minutes by meetbot
Main topics discussed where:
transaction priority for 0.12 Opt-in replace-by-fee Versionbits Chain limits
transaction priority for 0.12
Each transaction is assigned a priority, determined by the age, size, and number of inputs. Which currently makes some transactions free. This currently has a large amount of code, which makes it harder to maintain, and is not that optimal since you can't expect miners to include 0-fee transactions.
Most people seem fine with removing priority in the mempool, but people should be notified ahead of time this is coming. sdaftuar proposed a staggered approach, setting the default value for priority to 0, and remove it entirely in the next release. petertodd notes there will be a natural staggered process since not everyone will upgrade to 0.12 instantly and some implementations might not remove priority at all. Most wallet-software outside of bitcoin-core don't implement priority calculations. As fee estimation becomes more important and many wallet providers use the bitcoin-core fee estimation, improvements on that are welcome. Luke-Jr doesn't agree with removing priority, particularly with changing the mining code to use the priority a transaction has when it enters the mempool. Sipa has the idea to add a small fraction of bitcoin days destroyed divided by the average UTXO age to the fee, so that non-spam-attack transactions are viewed as if they have a larger fee.
While most agree with the proposal to remove the current priority, there's still much debate on whether it needs to be replaced for 0.13, and if so, how.
Review "Improve usage of fee estimation code" BlueMatt will mail the developer mailinglist announcing the changes. ([email protected]/msg02790.html )
Opt-in replace-by-fee
Currently when a node sees a transaction that spends the same output it ignores it. With replace-by-fee it replaces the current transaction in the mempool if it has a higher fee. This allows for things like spending "stuck" transactions, adding more recipients to a transaction in order to prevent chaining, etc.
Since there are people that accept 0-confirmation transactions and this would make it extremely easy to double spend them, this is made opt-in. The sender can choose to opt-in to replace-by-fee by changing an input in the nSequence field.
Peter Todd wrote some tools to use replace-by-fee. link It would be nice to have opt-in per output instead of the whole transaction, however that would be very hard to implement and would have some privacy concerns. Luke-Jr would like to see an option to toggle between first-seen-safe/full RBF and neveopt-in/always. Since there are possibly some objections with the "always" toggle it should be a separate pull-request.
review and merge nSequence-based Full-RBF opt-in Peter Todd will write a mail to the list to explain how it works and how people can not accept opt-in transactions.
BIP 9 Currently softforks have been done by the isSuperMajority mechanism, meaning when 95% of the last X blocks has a version number higher than Y the fork is deployed. A new way of doing this is currently being worked on and that uses all bits of the version number, appropriately being called versionbits. So instead of a fork happening when the version is larger than (for example) 00000000011 (3), a fork happens when (for example) the 3rd bit is up (so 00100000011). This way softforks can be deployed simultaneous and independent of each other.
There are 2 different implementations. One from Codeshark and one from Rusty jtimon thinks both implementations are more complicated than they need to be. There needs to be a minor revision namely a starting time for proposals. In general we'd like to get this in soon, but existing softforks need to complete first.
CodeShark adds a starting time to versionbits.
Chain limits
Chain in this context means connected transactions. When you send a transaction that depends on another transaction that has yet to be confirmed we talk about a chain of transactions. Miners ideally take the whole chain into account instead of just every single transaction (although that's not widely implemented afaik). So while a single transaction might not have a sufficient fee, a depending transaction could have a high enough fee to make it worthwhile to mine both. This is commonly known as child-pays-for-parent. Since you can make these chains very big it's possible to clog up the mempool this way. With the recent malleability attacks, anyone who made transactions going multiple layers deep would've already encountered huge problems doing this (beautifully explained in let's talk bitcoin #258 from 13:50 onwards) Proposal and github link.
Wumpus doesn't feel comfortable with merging it because there's some controversy from companies who exceed the limits (or could be/want to). jgarzik does feel comfortable with it, and many think it should be merged as it's easy to revert if needed. There's little choice as it's not safe from attacks without limits. We should communicate the replace-by-fee sendmany alternative to long chains (adding new recipients on existing non-confirmed transactions), although it won't show up in users wallet yet and block-explorers probably aren't ready to display it correctly. Emphasis on the fact it's a change in default values, not a consensus change, however default values have a lot of power. The final limits are 25 transactions and 101kb total size for both ancestor and descendant packages.
jgarzik will merge the pull-request. Morcos will mail the list once it's merged.
BlueMatt Matt Corallo petertodd Peter Todd morcos Alex Morcos jgarzik Jeff Garzik gmaxwell Gregory Maxwell wumpus Wladimir J. van der Laan Luke-Jr Luke Dashjr jtimon Jorge Timón btcdrak btcdrak phantomcircuit Patrick Strateman sipa Pieter Wuille CodeShark Eric Lombrozo sdaftuar Suhas Daftuar jg_taxi jg_taxi gavinandresen Gavin Andresen cfields Cory Fields bsm1175321 Bob McElrath 
Comic relief
19:53 sipa new topic? 19:53 wumpus any other topics? 19:53 petertodd  19:53 jgarzik did we cover jonas while I was in the taxi? 19:54 sdaftuar ? 19:54 jtimon ? 19:54 CodeShark not sure I want to know 19:54 jgarzik proposal for new GUI maintainer 19:54 CodeShark sounds kinky, though 19:54 petertodd CodeShark: GUI's are pretty kinky 19:56 BlueMatt ok, end meeting? 19:56 btcdrak if we can remember the command this week :-) 19:56 wumpus #meetingend 19:56 gmaxwell #destroymeeting 19:56 wumpus #endmeeting 19:56 Luke-Jr #endmeeting 19:56 lightningbot Meeting ended Thu Nov 12 19:56:42 2015 UTC. Information about MeetBot at . (v 0.1.4) 19:56 BlueMatt #magicmeetbotincantation 19:57 petertodd #DoWhatIMean 
submitted by G1lius to Bitcoin [link] [comments]

Bitcoin dev IRC meeting in layman's terms (2016-01-21)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last summarisation
Please bear in mind I'm not a developer so some things might be incorrect or plain wrong. There are no decisions being made in these meetings, but since a fair amount of devs are present it's a good representation. Copyright: Public domain


Main topics

Short topics

0.11 backport release for chainstate obfuscation


As some windows users might have experienced in the past, anti-virus software regularly detects values in the bitcoin database files which are false-positives. Thereby deleting those files and corrupting the database. To prevent this from happening developers discussed a way to obfuscate the database files and implemented it last year. While downgrading after upgrading is possible, if you start from a new 0.12 installation or you've done a -reindex on 0.12 it's impossible to downgrade to 0.11 (without starting from scratch).

meeting comments

The proposed pull-request detects the obfuscation in 0.11 so it throws a relevant error message. To avoid this in the future it would be good to have versionnumbers for the chainstate.

meeting conclusion

Release a 0.11 backport release right after the 0.12 final release to avoid confusion.

C++11 update


C++11 is an update of the C++ language. It offers new functionalities, an extended standard library, etc. Zerocash had to be written with some c++11 libraries and some IBLT simulation code was written in c++11, which they want to recycle for the eventual core commit.

meeting comments

All changes needed for C++11 have gone in and it's ready to switch. Cfields talked to the travis team and all the features needed (trusty, caching) will be ready by the end of the month, so he proposes to wait until then to flip the switch. Wangchung from f2pool indicated he would not run code that required a C++11 compiler. No one knows what his exact concerns are. Wumpus notes the gitian-built executables don't need any special OS support after the C++11 switch.

meeting conclusion

Wait for Travis update to switch to C++11. Talk to wangchung about his concerns.

EOL Policy / release cycles


In general bugfixes, translations and softforks are maintained for 2 major releases. btcdrak proposed to makes this official into a software life-cycle document for bitcoin core in order to inform users what to expect and developers what to code for. Pull request for this document. Given the huge 0.12 changelog jonasschnelli asks whether shorter release cycles might be a good idea. Currently there's a +/- 6 month release cycle.

meeting comments

Gmaxwell notes he doesn't know how useful the backports are given there's no feedback about them, but thinks the current policy is not bad. "I am observing the backports appear to be a waste of time. From a matter of principle, I think they are important, but the industry doesn't appear to agree." If no one is using the backports, it might not see sufficient testing. People generally agree with the 2 major releases approach.
The cyclelength also contributes to frustration and pressure to get features in, as it won't see the light of day for 6 months if it doesn't make the new release. For users it's not really better to have more frequent major releases, as upgrading may not always be a trivial process. There's also a lot of work going into releases. If the GUI and wallet where detached there could be more frequent releases for that part.

meeting conclusion

Policy will be: final release of 0.X means end-of-life of 0.(X-2), which means a 1 year support on the 6 month cycle.


wumpus Wladimir J. van der Laan gmaxwell Gregory Maxwell jonasshnelli Jonas Schnelli cfields Cory Fields btcdrak btcdrak sipa Pieter Wuille jtimon Jorge Timón maaku Mark Friedenbach kangx_ ??? Kang Zhang ??? sdaftuar Suhas Daftuar phantomcircuit Patrick Strateman CodeShark Eric Lombrozo bsm117532 Bob McElrath dkog ?dkog? jeremias ??? Jeremias Kangas ??? 

Comic relief

jonasschnelli maaku: refactoring? We have a main.cpp. We don't need refactoring. :) gmaxwell jonasschnelli: can we move everything back into main.cpp? I'd save a lot of time grepping. :P wumpus #endmeeting lightningbot` Meeting ended Thu Jan 21 19:55:48 2016 UTC. Information about MeetBot at . (v 0.1.4) btcdrak wumpus: hole in one maaku Did it right this time! gmaxwell Hurray! 
submitted by G1lius to Bitcoin [link] [comments]

Bitcoin dev IRC meeting in layman's terms (2015-11-05)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last weeks summarization Note that I crosspost this to Voat, and the bitcoin-discuss mailing list every week. I can't control what's being talking about in the meeting, if certain things come up I might not be able to post here because of "guidelines".
Please bear in mind I'm not a developer and I'd have problems coding "hello world!", so some things might be incorrect or plain wrong. Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can. There are no decisions being made in these meetings, so if I say "everyone agrees" this means everyone present in the meeting, that's not consensus, but since a fair amount of devs are present it's a good representation. The dev IRC and mailinglist are for bitcoin development purposes. If you have not contributed actual code to a bitcoin-implementation, this is probably not the place you want to reach out to. There are many places to discuss things that the developers read, including this sub-reddit.
link to this week logs Meeting minutes by meetbot
Main topics discussed where:
Sigcache performance Performance goals for 0.12 transaction priority sigops flooding attack chain limits
Short topics/notes
Note: cfields, mcelrath and BlueMatt (and maybe more) missed the meeting because of daylight saving time.
Closing date for proposals for the scaling bitcoin workshop is the 9th.
Check to see if there are any other commits for the 0.11.2 RC. As soon as 6948 and 6825 are merged it seems good to go. We need to move fairly quick as there are already miners voting for CLTV (F2Pool). Also testnet is CLTV locked already and is constantly forking. 0.11.2 RC1 has been released as of today:
Most of the mempool-limiting analysis assumed child-pays-for-parent, however that isn't ready for 0.12 yet, so we should think about possible abuses in context of the existing mining algorithm.
Because of time-constrains opt-in replace-by-fee has been deferred to next weeks meeting, but most people seem to want it in 0.12. sdaftuar makes a note that we need to make clear to users what they need to do if they don't want to accept opt-in transactions.
Sigcache performance
The signature cache, which is in place to increase performance (by not having to check the signature multiple times), and to mitigate some attacks currently has a default limit of 50 000 signatures. Sipa has a pull-request which proposes to: Change the limit from number of entries to megabytes Change the default to 40MB, which corresponds to 500 000 signatures Store salted hashes instead of full entries Remove entries that have been validated in a block
Sipa did benchmarks for various signature cache sizes on hitrate in blocks (how many of the cached signatures are in the block). The maximum sigcache size was 68MB, resulting in a 3% miss-rate. Some blocks though have extremely high miss rates (60%) while others have none. Likely caused by miners running different policies. Gmaxwell proposed to always run script verification for mempool transactions, even if these transactions get rejected into the mempool by the clients policy. The result of that is that even a 300MB sigcache size only gets down to 15% misses. So there's too much crap being relayed to keep any reasonable sized cache. Gmaxwell points out downsides to not checking any rejected transactions, namely: there are some DOS attacks possible, and you increase your misrate if you set a policy which is more restrictive than the typical network, which might result in a race to the bottom.
Sipa continues his work and seeks out other strategies
Performance goals for 0.12
Bitcoin-core 0.12 is scheduled for release December 1st.
Everybody likes to include secp256k1 ASAP, as it has a very large performance increase. Some people would like to include the sigcache pull-request, BIP30, modifyNewCoins and a createNewBlock rewrite if it's ready. Wumpus advises against merging last-minute performance improvements for 0.12.
Mentioned pull-requests should be reviewed, prioritizing CreateNewBlock
transaction priority
Each transaction is assigned a priority, determined by the age, size, and number of inputs. Which makes some transactions free.
Sipa thinks we should get rid of the current priority completely and replace it with a function that modifies fee or size of a transaction. There's a pull-request available that optimizes the current transaction priority, thereby avoiding the political debate that goes with changing the definition of transaction priority. Luke-jr thinks the old policy should remain possible.
Check to see if PR #6357 is safe and efficient enough.
sigops flooding attack
The number of ECDSA signature-checking operations or sigops is currently limited to 20 000 per block. This in order to prevent miners creating blocks that take ages to verify as those operations are time-consuming. You could however construct transactions that have a very high sigops count and since most miners don't take into account the sigops count they end up with very small blocks because the sigop limit is reached. This attack is described here.
Suggestion to take the number of sigops relative to the maximum blocksize into account with the total size. Meaning a 10k sigops transaction would currently be viewed as 500kB in size (for that single transaction, not towards the block). That suggestion would be easy to change in the mining code, but more invasive to try and plug that into everything that looks at feerate. This would also open up attacks on the mempool if these transactions are not evicted by mempool limiting. Luke-jr has a bytes-per-sigop limit, that filters out these attack transactions.
More analysis should be done, people seem fine with the general direction of fixing it.
chain limits
Chain in this context means connected transactions. When you send a transaction that depends on another transaction that has yet to be confirmed we talk about a chain of transactions. Miners ideally take the whole chain into account instead of just every single transaction (although that's not widely implemented afaik). So while a single transaction might not have a sufficient fee, a depending transaction could have a high enough fee to make it worthwhile to mine both. This is commonly known as child-pays-for-parent. Since you can make these chains very big it's possible to clog up the mempool this way. With the recent malleability attacks, anyone who made transactions going multiple layers deep would've already encountered huge problems doing this (beautifully explained in let's talk bitcoin #258 from 13:50 onwards) Proposal and github link.
sdaftuar's analysis shows that 40% of blocks contain a chain that exceeds the proposed limits. Even a small bump doesn't make the problem go away. Possible sources of these chains: a service paying the fees on other transactions (child-pays-for-parent), an iOS wallet that gladly spends unconfirmed change. A business confirms they use child-pays-for-parent when they receive bitcoins from an unspent chain. It is possible that these long chains are delivered to miners directly, in which case they wouldn't be affected by the proposed relay limits (and by malleability). Since this is a problem that needs to be addressed, people seem fine with merging it anyway, communicating in advance to let businesses think about how this affects them.
Merge "Policy: Lower default limits for tx chains" Morcos will mail the developer mailing list after it's merged.
morcos Alex Morcos gmaxwell Gregory Maxwell wumpus Wladimir J. van der Laan sipa Pieter Wuille jgarzik Jeff Garzik Luke-Jr Luke Dashjr phantomcircuit Patrick Strateman sdaftuar Suhas Daftuar btcdrak btcdrak jouke ??Jouke Hofman?? jtimon Jorge Timón jonasschnelli Jonas Schnelli 
Comic relief
20:01 wumpus #meetingend 20:01 wumpus #meetingstop 20:01 gmaxwell Thanks all. 20:01 btcdrak #exitmeeting 20:01 gmaxwell #nomeetingnonono 20:01 btcdrak #meedingexit 20:01 wumpus #endmeeting 20:01 lightningbot Meeting ended Thu Nov 5 20:01:29 2015 UTC. Information about MeetBot at . 20:01 btcdrak #rekt 
submitted by G1lius to Bitcoin [link] [comments]

Bitcoin dev IRC meeting in layman's terms (2015-10-15)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last weeks summarization
Please bear in mind I'm not a developer and I'd have problems coding "hello world!", so some things might be incorrect or plain wrong. Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can. There are no decisions being made in these meetings, so if I say "everyone agrees" this means everyone present in the meeting, that's not consensus, but since a fair amount of devs are present it's a good representation. The dev IRC and mailinglist are for bitcoin development purposes. If you have not contributed actual code to a bitcoin-implementation, this is probably not the place you want to reach out to. There are many places to discuss things that the developers read, including this sub-reddit.
link to this week logs Meeting minutes by meetbot
Main topics discussed where:
Mempool limiting sendheaders BIP versionbits dev/discuss list policy CHECKSEQUENCEVERIFY
Mempool limiting
When a transaction is relayed across the network it is held by the nodes in memory, until it gets into a block. All these transactions that sit in memory are called the memorypool or mempool for short. Like we could see during the spam-attack if there's a big back-log of transactions that couldn't make it in the blockchain this mempool can get pretty big resulting in nodes crashing.
To stop this from happening devs are trying to find a way to limit this mempool, so a mechanism to reject and/or remove transactions from the mempool. The hard part here is to make it so nodes can't be attacked by abusing this mechanism. So far the devs are going with TheBlueMatt's proposal of throwing away the cheapest txn and setting the min relay fee to it
While testing, sipa encountered transactions that took 200ms to be accepted into the mempool. As it's the first time he has benchmarked this and the pull-request shouldn't make an impact on these times it likely doesn't have anything to do with this. However, such times are bad either way. The average time in sipa's tests is 4ms. (After the meeting Morcos did some benchmarking and confirmed it was not specific to this PR, and pointed out the outliers come from CheckInputs and HaveInputs (as you might guess, having to do with checking the inputs) Question on why we should revert the minrelay (minimum fee for nodes to relay a transaction) back to 1000 (it has been set to 5000 to quick-fix the mempool issues), sipa thinks it should be floating as well or the dust limit becomes ineffective.
Review PR 6722 Limit mempool by throwing away the cheapest txn and setting min relay fee to it Morcos/sipa will do some more benchmarks and comment on the PR ( morcos' benchmark results )
sendheaders BIP
send headers BIP Copy/paste from the BIP: Since the introduction of "headers-first" downloading of blocks in 0.10, blocks will not be processed unless they are able to connect to a (valid) headers chain. Consequently, block relay generally works as follows:
  1. A node (N) announces the new tip with an "inv" message, containing the block hash
  2. A peer (P) responds to the "inv" with a "getheaders" message (to request headers up to the new tip) and a "getdata" message for the new tip itself
  3. N responds with a "headers" message (with the header for the new block along with any preceding headers unknown to P) and a "block" message containing the new block However, in the case where a new block is being announced that builds on the tip, it would be generally more efficient if the node N just announced the block header for the new block, rather than just the block hash, and saved the peer from generating and transmitting the getheaders message (and the required block locator).
Question on how to move forward. How to let the nodes know you want the blockheader instead of the blockhash. Options:
  1. Extend the version message.
  2. Have an "options" message that can send flags.
  3. Send a "sendheaders" message early when connecting so the way peers want their block announcement is immediately known.
  4. Send a "sendheaders" message at any time, changing the way peers want their block announcement from hashes to headers.
No one likes to extend the version message further. There's no strong advantage to have an "options" message over a "sendheaders" message. Having the message being sent early on might be too constraining. Possible usecase from morcos: "its entirely possible some future optimization may say, i want to send sendheaders to these peers b/c they announce a lot of new stuff to me and not these others b/c they don't". Most people like this to be enable-only, so no message to get back to receiving blockhashes. Which is how the BIP was drafted.
sdaftuar does a pull-request for the BIP to get a number assigned and proceeds with the BIP as drafted.
BIP 9 Currently softforks have been done by the isSuperMajority mechanism, meaning when 95% of the last X blocks has a version number higher than Y the fork is deployed. A new way of doing this is currently being worked on and that uses all bits of the version number, appropriately being called versionbits. So instead of a fork happening when the version is larger than (for example) 00000000011 (3), a fork happens when (for example) the 3rd bit is up (so 00100000011). This way softforks can be deployed simultaneous and independent of each other.
copy/paste from IRC, since I don't know what this specifically means: CodeShark: so right now it's just a unit that implements the versionbits logic but does not demonstrate its usage I thought it would be better to actually integrate in a separate PR, but I can add a demonstration sipa: separate commit, same PR - i think we need something that's mergable as a whole, to be able to see whether the whole thing easily backports
Codeshark (who's implementing versionbits) had some more remarks but no one present had seemed to reviewed it, so not much use in discussing things further.
review versionbits implementation
dev/discuss list policy
The bitcoin-dev mailing list is intended for technical discussions only. There's things that don't belong there but need to be discussed anyway. Now this is done in bitcoin-dev, but the volume of this is getting too big. There's recently also an influx of really inappropriate posts, level kindergarden. For the things that don't belong on bitcoin-dev, but need to be discussed anyway there's a new list being created namely bitcoin-discuss as well as clear policies and moderation for both.
Bitcoin-discuss was created, but the admin password wasn't distributed to jgarzik who's willing to guide the moderation. Seperate moderation-proposals have been done meanwhile. People just want it to move on.
Since none of the people who proposed a moderation-scheme are present we'll let them discuss it among each other and post their decisions publicly.
CheckLockTimeVerify (CLTV) repurposes the nSequence field (nSequence are 4 bytes intended for sequencing time-locked transactions, but this never got used). However, there's no way use these values in a bitcoin script. CheckSequenceVerify (CSV) makes this field accessible to bitcoin scripts.
EDIT: Turns out this is not entirely correct as it is relative locktime that repurposes the nSequence field.
CLTV is pretty much done. Check to see maaku moving one of the bits to allow for other implementations to have better granularity has any objections. As long as we're using as few bits as possible the exact semantics are less important for most people. sipa points out a possible bug that influences the wallet. CSV is not on target for the end of of the month, although a lot of work and progress has been made.
Review and ACK/NACK of 6312 BIP-68: Mempool-only sequence number constraint verification Review and ACK/NACK of 6566 BIP-113: Mempool-only median time-past as endpoint for lock-time calculations
wumpus Wladimir J. van der Laan sipa Pieter Wuille btcdrak btcdrak gmaxwell Gregory Maxwell morcos Alex Morcos maaku Mark Friedenbach CodeShark Eric Lombrozo BlueMatt Matt Corallo sdaftuar Suhas Daftuar warren Warren Togami GreenIsMyPepper Joseph Poon davec Dave Collins cfields Cory Fields jonasschnelli Jonas Schnelli
Comic relief
19:21 sdaftuar it sounds like everyone is ok with the BIP as drafted then? 19:21 wumpus yes 19:21 gmaxwell I think so. 19:22 davec yes 19:22 sipa well, the only person with concerns was cfields, who doesn't seem to be here :) 19:22 gmaxwell sipa: he can raise concerns later too! 19:22 cfields dammit! 19:22 sipa cfields: too late! 19:22 gmaxwell ha 19:23 cfields did i really miss my third one of these in a row?
submitted by G1lius to Bitcoin [link] [comments]

Top 50 Cryptocurrencies

Top 50 Cryptocurrencies
I thought this might be of real help for the ones that are just joining crypto and still want to read.
Let’s face it: there are a lot of cryptocurrencies out there, with new ones coming out almost daily and old ones disappearing seemingly just as fast as they appeared. It’s easy to get overwhelmed.
If you are new to cryptocurrencies, this is an excellent starting point to learn about each of the top 50 cryptocurrencies (by market cap). Even if you’re a crypto veteran, this is a great resource to reference if you ever get any of the top 50 confused, or if you want to read more about a new coin which has joined the ranks.
Our hope is to point you in the right direction, spur your interest to do more research, and steer you away from the potential scams out there (And yes, there are potential scam coins in the top 50!)
Here at Invest In Blockchain, we are obsessed with researching the internet for all things crypto. The information found in this post is the result of hundreds of hours of painstaking research by me and other writers on our team.
Note that this list is constantly changing and I will do my best to keep it up-to-date, but the top 50 moves almost daily! Please refer to for the latest information on the top 50 cryptocurrencies and their prices.
Let’s get started!
(Information accurate as of May 23, 2018)

#1 – Bitcoin (BTC)

The king of the crypto world, Bitcoin is now a household name; to many, it is synonymous with “cryptocurrency”. Its purpose is to provide a peer-to-peer electronic version of cash to allow payments to be sent online without the need for a third party (such as Mastercard).
The rapid rise in Bitcoin’s price has brought about an explosion of new Bitcoin investors. With the huge increase in interest has come a rise in merchants accepting Bitcoin as a legitimate form of payment. Bitcoin is fast moving towards its goal of becoming a currency accepted worldwide.
Bitcoin’s development is led by Bitcoin Core developer Wladimir J. van der Laan, who took over the role on April 8, 2014. Bitcoin’s changes are decided democratically by the community.
For an in-depth look at Bitcoin, including an explanation of Bitcoin mining, Bitcoin’s history, an analysis of Bitcoins’ value and a description on how bitcoin actually works, see our comprehensive guide “What is Bitcoin? Everything You Need to Know About Bitcoin, Explained“.
For a more detailed description of Bitcoin’s economics, what makes money and how Bitcoin works in the economy as a whole see: “Bitcoin Explained” and “Bitcoin is a Deflationary Currency”.

#2 – Ethereum (ETH)

Ethereum is the revolutionary platform which brought the concept of “smart contracts” to the blockchain. First released to the world in July 2015 by then 21-year-old Vitalik Buterin, Ethereum has quickly risen from obscurity to cryptocurrency celebrity status.
Buterin has a full team of developers working behind him to further develop the Ethereum platform. For more background information on Buterin, read our article, “Vitalik Buterin: The Face of Blockchain”.
Ethereum has the ability to process transactions quickly and cheaply over the blockchain similar to Bitcoin, but also has the ability to run smart contracts. For future reading on smart contracts, see “What’s the Difference Between Bitcoin and Ethereum”; but for now, think automated processes which can do just about anything.
For further reading on Ethereum, including an analysis of the platform’s strengths and future prospects, read “What is Ethereum, Everything You Need to Know Explained“.

#3 – Ripple (XRP)

Ripple aims to improve the speed of financial transactions, specifically international banking transactions.
Anyone who has ever sent money internationally knows that today it currently takes anywhere from 3-5 business days for a transaction to clear. It is faster to withdraw money, get on a plane, and fly it to your destination than it is to send it electronically! Not to mention you will be paying exorbitant transaction fees — usually somewhere around 6% but it can vary depending on the financial institution.
Ripple’s goal is to make these transactions fast (it only takes around 4 seconds for a transaction to clear) and cheap.
The Ripple team currently comprises over 150 people, making it one of the biggest in the cryptocurrency world. They are led by CEO Brad Garlinghouse, who has an impressive resume which includes high positions in other organizations such as Yahoo and Hightail.
Check out “What is Ripple” for more information, including a closer look at what they do, controversies and future prospects.

#4 – Bitcoin Cash (BCH)

Bitcoin Cash was created on August 1, 2017 after a “hard fork” of the Bitcoin blockchain. For years, a debate has been raging in the Bitcoin community on whether to increase the block size in the hope of alleviating some of the network bottleneck which has plagued Bitcoin due to its increased popularity.
Because no agreement could be reached, the original Bitcoin blockchain was forked, leaving the Bitcoin chain untouched and in effect creating a new blockchain which would allow developers to modify some of Bitcoin’s original programmed features.
Generally speaking, the argument for Bitcoin Cash is that by allowing the block size to increase, more transactions can be processed in the same amount of time. Those opposed to Bitcoin Cash argue that increasing the block size will increase the storage and bandwidth requirement, and in effect will price out normal users. This could lead to increased centralization, the exact thing Bitcoin set out to avoid.
Bitcoin Cash does not have one single development team like Bitcoin. There are now multiple independent teams of developers.
Read “What is Bitcoin Cash” for more information. You can also check out their reddit and official webpage.

#5 – EOS (EOS)

Billed as a potential “Ethereum Killer”, EOS proposes improvements that can challenge Ethereum as the dominant smart contract platform. One main issue EOS looks to improve is the scalability problems which has plagued the Ethereum network during times of high transaction volume, specifically during popular ICOs.
A perhaps more profound difference EOS has, compared to Ethereum, is the way in which you use the EOS network. With Ethereum, every time you make modifications or interact with the network, you need to pay a fee. With EOS, the creator of the DAPP (decentralized app) can foot the bill, while the user pays nothing. And if you think about it, this makes sense. Would you want to have to pay every time you post something on social media? No, of course not!
In addition to this, EOS has a few other technical advantages over Ethereum such as delegated proof of stake and other protocol changes. Just know that EOS has some serious power under the hood to back up the claim of “Ethereum Killer”.
EOS was created by Dan Larrimer who is no stranger to blockchain or start ups. He has been the driving force behind multiple successful projects in the past such as BitShares, Graphene and Steem.
For more information on EOS such as how and where to buy EOS tokens, EOS’s vision and potential challenges, see “What is EOS”.

#6 – Litecoin (LTC)

Similar to Bitcoin, Litecoin is a peer-to-peer transaction platform designed to be used as a digital currency. Due to some notable technical improvements, Litecoin is able to handle more transactions at lower costs. Litecoin has been designed to process the small transactions we make daily.
Litecoin is sometimes referred to “digital silver” while Bitcoin is known as “digital gold”. This is because traditionally silver was used for small daily transactions while gold was used as a store of wealth and was not used in everyday life.
The Litecoin blockchain is a fork from the Bitcoin chain. It was initially launched in 2011 when its founder, Charlie Lee, was still working for Google. Well-known as a cryptocurrency expert, Charlie Lee is backed by a strong development team who appear to be achieving what they set out to do. They have recently achieved a very notable accomplishment with the first successful atomic swap.
For an in-depth discussion on what Litecoin does, how it is different than Bitcoin and the team backing up the development, see “What is Litecoin”.

#7 – Cardano (ADA)

Cardano is a smart contract-focused blockchain. It was originally released under the name Input Output Hong Kong by Charles Hoskinson and Jeremy Wood, a few of the early team members of Ethereum, and later rebranded into Cardano.
Cardano is trying to fix some of the largest problems the cryptocurrency world which have been causing ongoing issues for years such as scalability issues and democratized voting.
They have the potential to challenge Ethereum’s dominance in the smart contract world. Cardano is developing their own programing language similar to Ethereum; however, they are focusing more heavily on being interoperable between other cryptocurrencies.
While some cryptocurrencies are all bite but no bark, Cardano is quite the opposite. They are quietly focusing on a strong software which will be completely open-source.
Cardano’s team comprises some of the best minds in the industry, and they seek to create a strong foundation which others can build upon for years to come.
For up-to-date information on Cardano’s status see their Reddit page or official website. You can also read our article “What is Cardano” to learn more about them.

#8 – Stellar Lumens (XLM)

In a nutshell, Stellar Lumens seeks to use blockchain to make very fast international payments with small fees. The network can handle thousands of transactions a second with only a 3-5 second confirmation time.
As you may know, Bitcoin can sometimes take 10-15 minutes for a transaction to confirm, can only handle a few transactions a second and, in turn, has very high transaction fees.
If this sounds a lot like Ripple, you’re right! Stellar Lumens was based off of the Ripple protocol) and is attempting to do similar things. Some of Stellar Lumens’ main uses will be for making small daily payments (micropayments), sending money internationally, and mobile payments.
Stellar Lumens is focusing on the developing world and, more specifically, the multi-billion dollar industry of migrant workers who send money back to their family in impoverished countries.
The Stellar Lumens team is led by Jed McCaleb, who has worked in numerous successful startups in the past such as eDonkey, Overnet, Ripple, and the infamous Mt. Gox.
For more information on Stellar Lumens, including the history and what sets Stellar Lumens apart, see “What are Stellar Lumens”. You can also learn about the differences between Stellar Lumens and Ripple.

#9 – TRON (TRX)

As stated in TRON’s whitepaper, “TRON is an attempt to heal the internet”. The TRON founders believe that the internet has deviated from its original intention of allowing people to freely create content and post as they please; instead, the internet has been taken over by huge corporations like Amazon, Google, Alibaba and others.
TRON is attempting to take the internet back from these companies by constructing a free content entertainment system. This will enable users to freely store, publish and own data, giving them the power to decide where and how to share.
The project is led by founder Justin Sun, who has been listed on the Forbes 30 under 30 list twice (in 2015 and 2017). In addition, Sun is a protégé of Jack Ma, founder of Alibaba Group, China’s former Ripple representative and the founder of Peiwo APP.
Sun has assembled a strong team with heavy hitters including Binshen Tang (founder of Clash of King), Wei Dai (founder of ofo, the biggest shared bicycles provider in China), and Chaoyong Wang (founder of ChinaEquity Group). Sun has also secured the support of a few notable angel investors such as Xue Manzi.
For up-to-date information on Tron and further discussion of the technology and team, see “What is Tron” and their website.

#10 – IOTA (MIOTA)

IOTA has seen many of the issues Bitcoin and Ethereum have with the POW (proof-of-work) and POI (proof-of-importance) models and looks to improve them with their revolutionary transaction validation network simply called “tangle”.
When issuing a transaction in IOTA, you validate 2 previous transactions. This means you no longer outsource validation to miners which requires wasteful amounts of computing power and usually a large stake of coins. These required resources are, in effect, centralizing the currencies which many believe were created to be decentralized in the first place.
With IOTA, the more active a ledger is, the more validation there is. In other words, the more people who use it, the faster it gets. You don’t have to subsidize miners, so there are no fees on transactions. That’s right: zero.
The IOTA team has been actively developing blockchain technology since 2011, and created the IOTA foundation and company in 2016. Since its emergence, the team has been continuously growing, attracting exceptional talent from around the world.
For more information on IOTA’s team and their revolutionary“tangle” technology, check out “What is IOTA”.

#11 – NEO (NEO)

A leading platform for smart contracts and sometimes referred to as “China’s Ethereum”. NEO (formally Antshares) hopes to digitize many types of assets which were formerly kept in more traditional means, and therefore make it possible to use them in smart contracts.
To imagine a potential use case of NEO, think digitizing the title to a house into a smart asset, and then setting up that asset to automatically transfer to another person after payment for the house has been received. This would be, in effect, a simple smart contract.
NEO founder Da Hongfei is a leading figure in the cryptocurrency world and has worked on numerous blockchain projects in the past. The development team consists of 6 in-house investors and a large community of third-party developers.
For a complete overview of NEO, including the team, history and competitive analysis, check out “What is NEO”.

#12 – Dash (DASH)

Dash (which comes from ‘digital cash’) aims to be the most user-friendly and scalable cryptocurrency in the world. It has the ability to send funds instantly confirmed by “double-send-proof” security with the added functionality of erasable transaction history and the ability to send transactions anonymously.
Like Bitcoin, Dash is meant to be used as a digital currency but has some added values such as much faster transaction times and lower fees. For a slightly higher fee, Dash has the added function of “instant send” which allows transactions to be confirmed almost instantly. This is one of the main selling points of Dash because many believe that this feature would allow it to be used in brick and mortar establishments.
The Dash development team consists of over 50 members and is led by former financial services professional Evan Duffield.
For the latest on Dash, see their official website and reddit page. You can also read “What is Dash” to learn more about the project.

#13 – Monero (XMR)

Monero is a digital currency designed to be used as a completely anonymous payment system.
A common misconception with Bitcoin is that it is completely anonymous. In reality, all payments processed on the Bitcoin network are recorded on a public ledger (blockchain), so Bitcoin is actually only partially anonymous or “pseudonymous”.
This means that you can, in theory, trace back every transaction a coin has been involved with from its creation. Though users aren’t able to inherently link the public key on the blockchain with the private keys used to store the coins themselves, there will always exist a correlation between the two.
Monero has solved this problem by implementing cryptonic hashing of receiving addresses, therefore separating the coin from the address it is going to. This can be hugely valuable for anyone wishing to conceal their purchases.
The Monero development team consists of 7 core developers, only two of which are publicly known. There have been over 200 additional contributors to the project and software updates are implemented every six months or so.
To learn more about Monero including its competitors and challenges, read “What is Monero”. If you’re thinking about investing in Monero, check out our opinion piece “Should You Invest In Monero?“.

#14 – Tether (UDST)

Tether is a cryptocurrency token issued on the Bitcoin blockchain. Each Tether coin is allegedly backed by one US Dollar. The goal is to facilitate transactions with a rate fixed to the USD.
Amongst other things, Tether looks to fix some of the legal issues which can arise when trading cryptocurrencies and it aims to protect people from market volatility.
Tether has faced controversy regarding their business model, and some consider it a scam. More info can be seen on reddit posts such as this.

#15 – NEM (XEM)

NEM (New Economy Movement) is the world’s first proof-of-importance (POI) enterprise based on blockchain technology. With a focus on business use cases, the software was built from the ground up with adaptability in mind. NEM’s goal is for companies to use their “smart asset system” to implement customizable blockchains. A smart asset can be almost anything: a cryptocurrency token, a business’s stock or a company’s invoicing and records.
Some potential use cases for NEM’s technology include: voting, crowdfunding, stock ownership, keeping secure records, loyalty rewards point programs, mobile payments and escrow services. A list of NEM’s use cases can be found here.
The development of NEM is monitored by the Singapore-based NEM Foundation.
For more information on what NEM does and what sets NEM apart from its competitors, see “What is NEM”.

#16 – VeChain (VEN)

As described in VeChain’s development plan, the organization’s purpose is to build “a trustfree and distributed business ecosystem based on the Blockchain technology self-circulated and expanding”.
They plan to do this by creating an efficient trustless business ecosystem to significantly reduce the wasteful information transfer systems of today.
Some of the areas and industries the VeChain platform is focusing on include eliminating counterfeiting in the fashion and luxury industry, food safety tracking systems, digitizing maintenance in the car industry and many other global supply chain processes.
For more information on VeChain, see their reddit and website. Read “What is Vechain” to learn about the project, and our investment opinion piece “5 Reasons to Invest in Vechain“.

#17 – Ethereum Classic (ETC)

Ethereum Classic came about after a hard fork of Ethereum in 2016. The fork was a result of the infamous DOA hack where around 50 million dollars worth of Ethereum was stolen due to what was considered an oversight in the code.
The blockchain was forked in order to recoup the losses from this attack, but a small portion of the community did not wish to go back and change the original blockchain. Vitalik Buterin, founder of Ethereum, and subsequently the development team chose to go with the hard fork and work on what is now “Ethereum” today.
There is a lot of ongoing controversy with Ethereum Classic which can be better described on this reddit thread. For an in-depth discussion of Ethereum Classic, see”What is Ethereum Classic“.

#18 – Binance Coin (BNB)

Binance Coin is the coin used to facilitate operations on the Binance platform, a cryptocurrency exchange that is capable of processing 1.4 million orders per second. The name “Binance” is derived from the combination of the terms “binary” and “finance”, referring to the integration of digital technology and finance.
The BNB coin is used to pay exchange fees, withdrawal fees, listing fees, and all other possible transaction expenses on the Binance platform. In order to incentivize new users to do their cryptocurrency trading on Binance, the team is offering discounts when BNB is used to pay fees. The discount will be 50% in the first year, 25% in the second, 12.5% in the third, and 6.25% in the fourth year before the discount ends.
Binance was primarily marketed to Chinese cryptocurrency investors at first, but they also have English, Korean, Japanese, French, Spanish, and Russian versions of the platform.
For a deeper look into Binance, you can read the whitepaper or check out the trading platform here.

#19 – Bytecoin (BCN)

Bytecoin describes itself as “a private, decentralized cryptocurrency with with open source code that allows everyone to take part in the Bytecoin network development”. It is the first coin to offer untraceable payments, unlinkable transactions and resistance to blockchain analysis.
With Bytecoin, it is possible to send instant transactions anywhere around the world, which are totally untraceable and don’t require additional fees.
Bytecoin’s development is community-driven and a list of all of the different community websites can be found here.
For more information on Bytecoin, see: “What is Bytecoin“.

#20 – QTUM (QTUM)

QTUM (pronounced Quantum) is an open-source value transfer platform which focuses on mobile decentralized apps or Dapps. QTUM is the world’s first proof-of-stake smart contracts platform.
QTUM is meant to be used as both a value transfer protocol, like Bitcoin, and a smart contract platform, like Ethereum. They have a number of technical innovations which some consider to make it superior to Ethereum, and they are focusing on mobile applications.
The platform itself is very new. It came about in March 2017, after a highly successful crowdfunding campaign raised them nearly 16 million dollars in only 5 days. QTUM has a small but strong development team and an impressive list of investors backing their ideas. QTUM’s development is lead by the Singapore based QTUM Foundation.
For further reading on the background of QTUM and what sets them apart, see “What is QTUM”.

#21 – Zcash (ZEC)

ZCash is a value transfer protocol forked off of the Bitcoin blockchain. ZCash can be used like Bitcoin, with a few added improvements. With “zero cash technology”, ZCash shields both the amount transferred and the senders, making transactions truly anonymous.
ZCash is one of the new kids on the block in the world of “private transactions”.
An interesting note is that Ethereum is in the process of implementing some of ZCash’s technologies to enable transactions on the Ethereum network to be anonymous as well.
ZCash is being developed by the Zerocoin Electric Coin Company. They’ve had some great successes, most notably JP Morgan’s announcement that they would implement Zcash’s privacy technology to Quarum, a technology JP built on Ethereum.
Interested in investing in ZCash? Here’s the opinion of one of our writers: Should You Invest In ZCash?
ZCash was recently featured on the Radiolab episode The Ceremony.

#22 – OmiseGO (OMG)

“Unbank the Banked” is the slogan of Omise’s online platform OmiseGo and that’s exactly what Omise has set out to do. Founded in 2013 off of the Ethereum blockchain, Omise aims to revolutionize the financial dynamics in Southeast Asia.
Omise is targeting individuals and businesses of all sizes by improving the current financial system which is slow, outdated, and inaccessible to most “everyday” people in these countries.
With their planned online exchange OmiseGO, Omise seeks to speed up the way money is spent and sent, both domestically and internationally in Southeast Asia and beyond.
They have a lot to celebrate too. OmiseGo has been building partnerships in the region and recently partnered with McDonald’s and Credit Saison.
Omise has established a strong team of over 130 staff members located in different countries. CEO and founder of Omise, Jun Hasegawa, has been involved in multiple startups and worked for Google for over 16 years.
The OmiseGO platform has been endorsed by some of the heavy hitters in the cryptocurrency world such as Vitalik Buterin and Gavin Wood, the co-founders of Ethereum.
For more information on what OmiseGO aims to do, see “What is OmiseGo”.

#23 – ICON (ICX)

Fresh off a successful ICO, the Korea-based startup ICON is looking to provide a medium to connect all the different blockchains together. This puts ICON in the same field as Ark, which is attempting to accomplish similar goals.
The main concept of ICON is their idea of a “loopchain”. As stated in their whitepaper, a loopchain can be described as a “high-performance blockchain that can provide real-time transaction, which is based on enhanced Smart Contract.” Through ICON, participants will be able to connect to any blockchain without relying on the current centralized exchanges.
ICON has a relatively large team from various backgrounds. They have also secured the help of a few notable advisors such as Jason Best and Don Tapscott.
For more information on ICON and the work they’re doing, see “What is ICON“.

#24 – Lisk (LSK)

📷 Lisk is a decentralized network, like Bitcoin and Litecoin, which enables developers to deploy their own side chains off the main Lisk blockchain. These side chains are fully customizable blockchains which enable you to change the parameters you want to fit your own blockchain application.
This is similar to Ethereum and QTUM in some ways. With Lisk, the main difference is that the customizable blockchains split into their own separate side chains. This saves developers the grueling legwork of designing something from scratch. At the end of the day, side chains are only decentralized databases of blockchain applications.
Lisk is being developed by a small but quickly growing Berlin-based team. They are led by co-founders Max Kordek and Olivier Beddows who are veterans in the cryptocurrency and development world.
For a thorough look into Lisk including more on what Lisk does, its competitors, challenges and teams, see “What is Lisk”. You can also check out our case study of an accountant who invested all his life savings in Lisk: “Accountant Invests All in Lisk”.

#25 – Zilliqa – (ZIL)

Zilliqa is a blockchain platform which focuses on solving the problem of scaling on public blockchains. With Zilliqa’s network, the number of transactions increases at a linear rate to the number of nodes.
This means that as nodes increase, so will its ability to handle high transaction volume. Zilliqa has already run a successful test on their network, where they were able to achieve 1,200 transactions per second with only 2,400 nodes.
Zilliqa also is the first blockchain to successfully integrate “sharding” into a public blockchain. This concept is extremely useful in improving the rate of scalability, bandwidth and performance in blockchains. Sharding, in effect, splits nodes into “shards” which can then conduct micro-transactions in each blockchain block.
In addition to this, Zilliqa claims to be more energy-efficient to mine. They also plan to implement dapps into their platform in the future.
For more information on Zilliqa, see their website and reddit. Our article “What is Zilliqa” can provide you with an overview of the project.


submitted by SilverSniper2017 to cryptoinvestingtop [link] [comments]

Spectcular Weekend in Bitcoin and Sports -- Gavin Andresen Steps Down, Welcome Wladimir Bitcoin  The Hostile Takeover Bitcoin: Gold for millennials? Semantic debate may account for Wladimir van der Laan's ... DTNS 2642 - Leaking Mr. Bitcoin.

AKA laanwj Maintainer of Bitcoin Core, his work get's financed by MIT Media Lab. Wladimir van der Laan (Bitcoin Core Lead Maintainer): "Bitcoin Core tests: performance in VM" ( submitted 2 years ago by eragmus 19 comments In other words, Wladimir van der Laan is not qualified to be the "official maintainer" of the code repository for a major Bitcoin implementation - which is one more reason why Core/Blockstream/AXA is about to go the way of the dinosaur, with their anti-market, centrally planned 1MB 1.7MB blocksize, and their latest proposed hack poison pill called "SegWit", which would be the most radical an ... Bitcoin-Qt può essere utolizzato comme portafoglio desktop per i pagamenti oppure comme utilità di server per commercianti e altri servizi di pagamento.. Bitcoin-Qr è un cliente di rete ufficiale, che è sviluppato e promosso dalla Fondazione di Bitcoin, un'organizzazione non-profit che unisce sviluppatori di base e responsabile dei contatti della comunità con aziende e governi. Talk:Wladimir van der Laan. From Bitcoin Wiki. Jump to: navigation, search. WikiProject People. This page is within the scope of WikiProject People, a collaborative effort to improve the coverage of people associated with Bitcoin on the Bitcoin Wiki. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. Stub: This page ...

[index] [23367] [10025] [30500] [6381] [6697] [18962] [14799] [20401] [39303] [25878]

Spectcular Weekend in Bitcoin and Sports -- Gavin Andresen Steps Down, Welcome Wladimir

All the keys are owned by 5 people: Wladimir van der Laan, Pieter Wuille, Jonas Schnelli, Marco Falke and Samuel Dobson. You obviously can’t put all your trust in these people so you should ... Wladimir van der Laan is a developer at the MIT Digital Currency Initiative and lead maintainer for the Bitcoin Core project. This involves reviewing code, troubleshooting bugs, software testing ... Support MadBitcoins: 1PtAdf3LbwrPfX87dQ8TMuKEzuMUZtg1z1 April 8, 2014 -- Pittsburgh, Pennsylvania -- MadBitcoins: Head for the mountains. Madbitcoins Subscriber Index ... Through the changes to Bitcoin Core, its developers make changes to the underlying bitcoin protocol. As of 2017, Bitcoin Core repositories are maintained by Wladimir J. van der Laan. Is bitcoin and other cryptocurrencies the future, a bubble or both? Is the recent bitcoin rush comparable to the olden gold rush? Garrick Hileman, cryptocurr...