Hacker News Reader

I believe the author has been very careful in saying "if no perfect solution exists they seem ok with inaction", highlighting a different problem from "let's bang out code that sorta works and move on.

Also, poor communication skills and "immaturity" have also been a "traditional" problems in FLOSS too. Being unwelcoming to new devs is especially a big problem for a project that _is already_ losing the old trusted devs.

Unwelcoming to new devs is not true. Who wrote code & wasn't let in? Also, go to the bitcoin irc and try asking technical questions and observe how everyone is so willing to help new devs looking to get in.

I feel like people are generally comfortable making the assertion that the community is unwelcoming; but those making the assertion generally don't seem to be able to back it up.

A welcoming community doesn't need to coddle everyone who might send a patch, because that's a lot of people. If they want to succeed, they should document enough to get started, and review unfinished patches.

sorry if I was unclear but I am not backing the assertions, I am just saying that the critique to what is written is invalid.

The comment I replied to does not challenge the assumptions, but the conclusions. Whether the assumptions are true or not, I do not know.

For context, here's the Bitcoin Core developers' position on why they're not simply raising the block size right now: https://bitcoin.org/en/bitcoin-core/capacity-increases-faq#s...

Thank you. That clearly shows that some people associated with the core team have very good communications skills.

Don't be so bitter. ;-)

Why do you think a bitcoin core developer wrote the FAQ? In a large project like this it is not at all unusual to have documentation written by people outside the core development team. In fact you can go look at the history of this page, David Harding wrote most of it and I do not see any commits from him in core.

https://github.com/bitcoin-dot-org/bitcoin.org/commits/maste...

https://github.com/bitcoin/bitcoin/commits?author=harding

Part of having effective communication is having people on your wider team that are experts in that area, even if they aren't one of the people writing all the software.

I don't - I said specifically: "people associated with the core team"

As long as the core coders can associate and work well with good communicators, it's all good as far as I'm concerned.

Until you get half way down the article and discover that the Core developers aren't simply proposing inaction:

> It is worth noting that bitcoin core’s response to scaling has been to propose a solution called segregated witness. While it is a well done piece of technology, I believe it would be quite risky

SegWit can only reduce bandwidth for clients that don't need to perform full validation. Blocksize is otherwise unchanged. Miners' and payment processors' bandwidth requirements are unchanged. Lightweight wallets does benefit, as does the nodes/servers they get their data from.

The point is increasing transactions that can be included without hard forking.

All fully validating nodes must still download all the signature data. The total can not exceed 1MB per block without forking. SegWit does not reduce transaction sizes.

SegWit is not a compression technique, it is a bandwidth redundancy reduction technique. It simply makes it so that some nodes doesn't need to fetch all of the transaction data.

Take a look at the discount for segregated witness transactions. You'll see that in a world with segwit there are more transactions per block than without.

Can't be done without forking if the total data per block required to validate all the transactions exceeds 1 MB. Old full nodes will reject the blocks.

Only compression or merging can increase the transaction count per block without becoming incompatible with old full nodes.

Luke jr showed how you can implement segwit as a soft fork. The txs look like "anyone can spend" txs and the signatures are excised to the witness data structure (decreasing the tx size). To validate the segwit txs you need to upgrade, but it's not correct to say that a hardfork is needed to increase the number of txs per block.

Only works with a majority hashrate enforcing the new rules, and miners still need full bandwidth and storage like before. Then you really just create a secondary blocksize limit for the associated signature data. And old full nodes are silently converted into non-full nodes, SPV nodes.

But sure, it is a backwards compatible way to reduce overhead for old nodes. But if they want to remain full nodes then they must upgrade and take on larger storage and bandwidth requirements anyway.

AFAIK the intent of segwit is not to reduce overhead but to fix tx malleability. As an consequence of the politicized block size debate a discount was added to increase the number of txs per block--and this was seen as a compromise for the big blocker camp. It turns out you can roll it out with a softfork as well (and provide script versioning), making it a safer alternative to upping the limit with a contentious hardfork.

Can you clarify what you mean by the majority hash rate needs to enforce the new rules?

If they're anyone-can-spend scripts superficially, then old nodes will accept any attempt to spend, not just those of the actual intended recipient. Because they doesn't recognize the softfork rules that restrict who are supposed to be able to spend. To determine that you need the additional signature SegWit data, and only SegWit parsing nodes will understand the difference.

They're non standard and therefore don't get relayed by old nodes. They won't make it into the longer chain because we're assuming the fork is activated. So what does an attack look like, exactly?

If someone blindly accepts non-standard zero confs they've got bigger problems.

I just realized I might be wrong. Anyone-can-spend transactions will be non standard, but transactions spending those outputs might be standard (don't know offhand). In that case, the risk is someone accepting standard transactions with zero confs, which is slightly worse but still doesn't seem too bad considering that all such forks are well publicized and there's no guarantee for zero conf security.

SegWit is also intended up to open up some new middle ground security options-- e.g. making it realistically possible for nodes that verify a random fraction of the data; with a security model in between light an full.

It also addresses some of problems with validation costs that are quadratic in transaction size.

It's also, by far, not the only tool in the Increased-capacity-without-harming-decentralization tool belt, for example I recently described a new approach for signature aggregation which, if applied to the current transaction load would decrease transaction sizes around 30% while making verification somewhat faster.

"I get this bad feeling that someone (author of the article) is planning a takeover and for all the wrong reasons."

The author of the article is the CEO of Coinbase. They want Bitcoin retail-sized transactions to clear fast, so their exposure to Bitcoin price variations is low. Coinbase guarantees the price of Bitcoin for several minutes when merchants use their service. The longer they have to hold those Bitcoins, the more risk they take.

Yeah, so they want to make more money. Is that necessarily best thing for the bitcoin as a whole? Just for full disclosure I have my bitcoins over at Coinbase.

I have my bitcoins over at Coinbase.

Please transfer your money back under your control. That's the whole point of bitcoin. You won't be able to do this when problems happen.

I mean, if it's only a few hundred dollars in BTC, it doesn't matter much. But it's a terrible feeling to lose way more than that.

Here's a recap of Coinbase's problems over the years, in case it matters: https://news.ycombinator.com/item?id=8947926

Your comment is perhaps true in a general sense. However, in the case of the Bitcoin core team, we're talking about a group of people who richly deserve to be unseated.

this is open source software - you act as if the seat can't be earned with enough commits.

That's the thing; the core maintainers won't allow anyone new in. At least nobody who disagrees with their pretty much objectively harmful inaction on raising the transaction limit, a stance they've adopted out of extreme stubbornness combined with glaring financial conflicts of interest.

I think the parent meant "unseated" as in LibreOffice unseating OpenOffice: the proper way to attempt a coup of a FOSS project is to fork it and outcompete it.

but that has already happened, TFA is advocating moving to LibreOffice (BitcoinClassic).

BitcoinClassic has to do what LibreOffice has done first. Write more code, have more active developers, fix more bugs - be the better community for new developers etc. So far none of this happened.

Yeah, but that's a chicken and egg problem because unless/until BitcoinClassic outcompetes the other one, none of your code will ever get executed, so any developer wanting to scratch an itch must contribute to the existing bitcoin rather than BitcoinClassic.

The dynamics don't work the same way as a traditonal FOSS fork. Perhaps getting mindshare first is the way.

That has been tried before with XT and it failed.

Bitcoin Classic is the attempt to change the reference implementation from the Core code to their code, by only changing as little as possible (that is, raising the 1 MB blocksize to 2 MB).

The current problem is not being more open to other developers but to get a different reference implementation installed on full nodes and miners.

I know; and obviously Bitcoin Core aren't going to fire themselves. I'm just addressing the why they should be unseated, not the how.

(It's worth noting that Bitcoin Core supporters have been DDOSing people running the various attempts at a "LibreOffice" that've been tried).

DDOSing nodes does nothing to support Bitcoin Core.

Bitcoin nodes get DDOSed from time to time-- e.g. people incorrectly believe they're the node for some service they think they can extort. Sometimes users on bufferbloat afflicted connections mistake other users fetching the chain from them as a DOS attack.

That said, since these claims that people are DDOSing "Bitcoin classic" were first made, I've had someone running a classic node-- in the hope of identifying the attacker-- which has received no attacks. I don't believe the claimed attacks are widespread if they're even happening at all.

But Bitcoin isn't just a FOSS project -- it aspires to be a currency, even a financial system of sorts. Currencies have a network effect; the more widespread their adoption, the greater their gravity, making a popular currency difficult to supplant.

I'm skeptical that the FOSS philosophy is the correct philosophy for anything which becomes harder to replace as it becomes more established.

It seems to me that the problem with Bitcoin is that its "consensus rules" (the flowchart to follow to decide a block of transactions as either being valid or invalid) aren't instantiated anywhere, but rather are just buried within the particular implementation details of BitcoinCore.

In an ideal world, you'd split these up:

1. there'd be a currency steering committee (with some structure whose ideal form is above my pay-grade) that produces a machine-readable validity ruleset (sort of like a DTD or XML Schema);

2. and then there'd be a proliferation of competing clients that all know how to parse those rulesets, and use them to validate blocks; but which otherwise go about their business of being Bitcoin clients in entirely separate ways.

With such a split, issues with the management of "BitcoinCore the FOSS reference client implementation" wouldn't overlap with issues with "Bitcoin, the ruleset that, in being instantiated in a majority of nodes, gives them a consensus chain." Instead, the first would just be a regular code project, no longer at-all critical; and the second would be something more like the project of defining a new version of e.g. the ePub standard, or of drafting an RFC.

The challenge is that the rules are only legitimized by the clients choosing to follow them. You can't launch new rules until at least 50% of clients by weight are following those rules. There is no way for the ruleset to somehow disable or ignore a misbehaving client, you need consensus.

Right, this would just make the difference explicit: given a good spec for defining the rulesets, a client would be able to just give a drop-down for which ruleset to follow (or allow you to point the client at your own by URL, etc.)

They have been split up. Bitcoin Core now builds a separate library, libbitcoinconsensus.

There are several problems with this. Firstly, a machine-readable validity ruleset would basically just have to be a library implementing the rules, simply because of their complexity - for example, one of the previous validity changes requires scripts of a particular format to be treated as hashes of the actual script, which is provided by the transaction redeeming it. Secondly, bugs in implementations can effectively cause the to enforce unexpected additional rules, such as the BDB lock limit which caused an unplanned hard fork a few years back. Thirdly, everyone involved still needs to be a skilled developer with knowledge of distributed systems - especially the currency steering committee, since changes to the validity ruleset can break the whole thing in subtle and unexpected ways - and the committee still needs in-depth knowledge of the actual implementations to know if they can cope with their planned rule changes.

Please provide an example of person with loads of recent commits (past year or so) who wasn't allowed in.

I mean they don't add new people to the core, decision-making team (relevant to this controversy: those who decide the block size i.e. transaction limit).

Now, many open source projects don't add new people to the core, decision-making team, but few open source projects are run by people who are acting in direct opposition to the [financial] interests of their userbase.

Sure, but they aren't being paid by their users so why should they follow their interests? Ideally the users should be paying for development they control but that of course would never happen because of the Tragedy of the Commons and such.

They should follow the user's interest because if they don't users will just leave Bitcoin for another cryptocurrency. Who wants to use a crypto that has 0.50$ fees, and takes hours to confirm a transaction?

> Who wants to use a crypto that has 0.50$ fees, and takes hours to confirm a transaction?

Just pointing out that that would still be an order of magnitude better than my current non-bitcoin options for forex/remittance ($100s, days).

But if you really think that changes need to be made that the quintumvirate don't want to make... your commits aren't going to be approved.

Authority in Bitcoin comes from hashing power not by credentials or anything else. Go and convince the Chinese mining pools to adopt someone's fork. These are the guys spending >$50k a month on electricity and millions of dollars in mining gear. You can also go start collecting Dogecoin or Ethereum or start your own crypto currency. Nobel Prize winner F.A Hayek in his book "The Denationalization of Money" suggested that in the future there should be multiple competing currencies anyway, not one uber currency to rule them all.

That's exactly what we're doing. Here's a chart for Bitcoin Classic blocks mined: https://coin.dance/blocks/classic

What an uninformed amateur sees from this page is ... utter chaos in Total Miner Support by Proposal. BIP 100 leads but the BIP repo linked doesn't contain such a BIP, the link is broken. 8MB doesn't even have a link. The four of them together managed to convince 27% to change to something and 3.8% for classic is the last.

What the heck are you talking about? The bitcoin core repo accepts contributions from any and all. There are new developers showing up all the time.

This just makes me go: "well, duh". If I would come in on your current project and make changes you didn't agree with, would you "let me in"?

If things are really so bad and Bitcoin is FOSS, why don't you (or whoever cares about rising the limit most) just fork the project and create Bitcoin 2.0. If this is truly best thing for the currency then everyone is bound to jump the ship and use your new currency.

The forks XT and Classic are both trying to do that. XT was actively fought with things like DDoS attacks and lies and other foul play. Classic goes for a more moderate (IMHO too cowardly) increase, and is at least not being fought in the same way.

As someone who hasn't been following bitcoin development very closely, can you please give me some examples or sources as to why they deserve to be unseated?

It's been posted elsewhere in this thread, but: https://medium.com/@octskyward/the-resolution-of-the-bitcoin...

HN discussion: https://news.ycombinator.com/item?id=10905118

Do you trust these people?

Austin Hill, CEO of Blockstream, admits to committing fraud to scam people:

http://betakit.com/montreal-angel-austin-hill-failed-spectac...

Greg Maxwell, CTO of Blockstream, vandalizes pages on Wikipedia for fun:

https://en.wikipedia.org/w/index.php?title=Wikipedia:Adminis...

Patrick Strateman, co-founder of Blockstream, has been accused of fraud/theft:

https://bitcointalk.org/index.php?topic=159071.0

Luke-Jr, consultant to Blockstream claims the sun orbits the earth, slavery is okay, sodomy should be punished by death and that gay marriage is a logical impossibility.

http://forums3.armagetronad.net/viewtopic.php?p=203850#p2038...

https://np.reddit.com/r/bitcoin_uncensored/comments/492ztl/l...

https://www.reddit.com/r/Christianity/comments/48avz0/inform...

Unfortunately this comment and this account (created only to criticise the bitcoin core team) is a good representation of the calibre of most of the criticism and attacks they have been copping over the last year or so.

Let's be more clear: it's horribly misleading.

E.g. the Austin Hill example is from when the man was 16, and comes from a talk he gave about how he learned an important moral lesson from that moral failure that changed the course of the rest of his life.

I don't really see anything horribly misleading here. The linked article mentions this as well.

Luke-JR seems to have --- special --- views of the world. Not sure if I would trust him with anything at all.

Yeah, I guess the issue is everyone is very self-interest and there is a lot of money at stake. Imagine if a private company can take over bitcoin core.

I stopped reading after

>2. They prefer ‘perfect’ solutions to ‘good enough’. And if no perfect solution exists they seem ok with inaction, even if that puts bitcoin at risk.

I mean the kind of 'good enough' thinking got us into the router mess we are currently in.

this ain't no imageboard

You should not have stopped reading. Brian is entirely correct about the whole situation, the only shame being that he didn't say these things publicly (and take corresponding action) 18 months ago.

The key thing to realise is this. Whilst the remaining Bitcoin Core developers (really: Blockstream) like to present their alternative plans like Lightning as tradeoff-free "solutions", the reality is that their proposed alternatives to the Bitcoin block chain are not launched or even close to launching, are developing extremely slowly, are missing huge chunks from their basic design and even if we assume they find answers to those problems and do actually launch something - the design itself is in no way "perfection" and has very serious unanswered critiques. It is very likely, in my view and the views of others, that their new system would actually be worse than Bitcoin, not better.

Thus driving Bitcoin into a brick wall at high speed because they prefer to believe in vapourware is not perfectionism, it's just idiocy. You don't need to be a businessman to understand that.

In short, they're in the grip of the nirvana fallacy:

https://en.wikipedia.org/wiki/Nirvana_fallacy

So the core of the argument is

> The number of lines of code that need to be written for this across the entire industry will be several orders of magnitude more than a scaling solution of changing 1MB blocks to 2MB blocks. This was explained to core developers at the conference and it didn’t seem to change their opinion of what the best short term solution was to scaling.

Aka, the author knows the day to day challenges of writing core better than the core developers. I believe reading the piece only validated my original heuristic.

"I mean the kind of 'good enough' thinking got us into the router mess we are currently in."

You mean the problem caused by everyone using the system? Certainly, if you don't have a system, you won't have problems with the system.