Topic: Is funding a development team really that difficult? (Read 2377 times)

I spoke to them about that - they said the Bloom filter standard was broken in that there was no way to advertise support for other protocol features with very when you don't support NODE_BLOOM...



You mean Pieter Wuille is doing the malleability fixes wrong... So rather than being silly about it, how about you publish your criticisms on the development mailing list by replying to Pieter's request for comments so we can come up with a good long term design. I've already published mine with regard to how the "whack-a-mole" approach Pieter is taking is likely to miss cases, and we should additionally do a soft-fork with new txid-less signature modes. Anyway he's convinced me that it won't be actually harmful, and the code I've implemented will still be useful whatever approach we take.

Note that usually what you call "endless criticism" is called design review. Its gets results too, like how recently a estimate fees design flaw was caught that could allow an attacker - or bad luck - to empty peoples' wallets completely to fees.

Sometimes I whish I would also get a small crumb of donations...

Anyway, I think it's bad to be not focused on improving things, but just on destroying anothers thoughts and work... EVEN if I have objections.
Some of the projects idleness comes from that fact IMHO. I also think more users should help testing pulls on Github and give feedback. Often there sneak in bugs into releases that shouldn't be in there because of the RC phases for example.

Dia

I don't see any connection between what we were talking about and this, perhaps I missed something. I don't think btcd guys have been "shut out". If they really do have more functionality then that's great, though the last I heard about btcd is that it didn't support Bloom filtering (but advertised in their ver message that they did).

Anyway, they presumably need a long term funding model as well. I don't know how Conformal subsidise btcd development, but relying on a single generous company is not a solution either.


The Foundation has received plenty of donations which is why it can now afford to pay three full time devs, at least for a while.

Peter - for what it's worth I think you're doing the malleability fixes wrong. I haven't bothered to argue about it or strongly object because unlike you I think something is better than nothing in this regard, but if you like I'll deluge your pull requests in endless criticism too. Wouldn't that be fun!

last time i checked he didn't owe anyone anything, if he doesn't feel he earns enough for his efforts its his right to quit.

Can't believe you are so money hungry greedy you would leave as soon as money drops by $50-100. Do you know, that in my country people live off $310 per month? I am sure you get at least 10 times as much, at least.

Can't believe you would starve if you worked for free for a bit.

Eh, you don't need to bring the word "agenda" into this discussion - Mike proposes a lot of ideas that the core devs are opposed too, often strongly. For instance getutxos was strongly opposed by Pieter, Jeff, and Gregory with only Gavin in support and Wladimir moderately supporting. Similarly double spend relaying is something Mike supports that has had little support other than Gavin. There's also fee estimation, particularly SPV nodes getting fee estimates in an untrusted way. As for his stance on soft-forks, basically no-one agrees with him that they're a bad thing. And of course there's Coinbase reallocation....

Seems to me the guy is annoyed that his ideas aren't getting support more than anything else. This isn't a funding issue, this is because the ideas aren't something others agree with.

OTOH look at Pieter's quite reasonable BIP to fix transaction malleability, which has plenty of development effort going to implementing it - I personally have written two patches, one merged, going towards implementing it. Of course, you don't hear about that because its a good, well-argued, idea that hasn't generated any controversy.

If this was true, then you wouldn't be so panicy literally days before btcd is getting ready to surpass Bitcoin Core in terms of functionality, despite persistent and coordinated efforts over the last year to shut them out.

The evidence suggests that the "core development team" is increasingly facing votes of no-confidence in multiple fronts exactly because of your attitude. The reason nobody donates money to Bitcoin Foundation is because nobody trust them or you.

The "reference implementation" is a dead project walking. Bitcoin, on the other hand, will be just fine without you.

Putting aside the lame insult about being mentally equipped, I guess you're talking about coinbase reallocation or erasure. I was actually thinking of the getutxo message.

Still, whilst I agree we could really use some organising principles to cut down on circular arguments on github, I think your thesis about NPV is incorrect. The core goal of Bitcoin is to make digital cash that can't be double spent. Everything else it does is just a way to achieve that end goal, there is no higher principle than no double spending. Yet, we see double spending with miner cooperation and the NPV of Bitcoin does not fall to zero.

Another example; you mentioned "scripts must be executed faithfully". P2SH outputs have scripts that are designed to always evaluate to true under the original rules when presented with the right redeem script, regardless of whether the transaction is properly signed or not. Later versions of Bitcoin added a special new rule that said outout scripts of the P2SH form aren't really scripts at all, they're just pattern matched and processed using special rules. This directly violated your principle that scripts will be executed faithfully, but NPV did not fall to zero. And why should it have done? Script is a relatively minor technical detail of how Bitcoin works.

In fact the whole purpose of a "soft fork" (as used to introduce P2SH) is to trick older clients into thinking a block is valid when in fact according to the majority it isn't valid, which is one reason I don't like them and don't think we should do them. But we've done them in the past and the sky did not fall.

Regardless of what we may like to believe, all the evidence suggests that most people see Bitcoin as merely a convenient way to move money around, not a manifesto or constitution. The rules have been broken before and  probably will be again in future.

What about Google Ventures?  Didn't they invest
in a bitcoin company/project?  Don't they have
deep pockets?  Plus Mike Hearn has relations
with Google.  Maybe they can pony up some dough.

There's a certain kind of person who is not mentally equipped to perform cost/benefit calculations in this subject, because they can't comprehend anything other than short-term pragmatism.

Bitcoin's value largely come from a widespread assumption that certain promises will be kept forever - those promises are intrinsic to Bitcoin and if they are ever violated then the NPV of Bitcoin drops to zero.

One of those promises is the block reward. If that is ever changed - no matter how slightly - then Bitcoin has a NPV of zero. The pragmatists can't see this - they'll insist that a minor change in inputs should lead to a minor change in results - because they don't perceive that the change is binary:  the block reward is either unchangable or it's changable and Bitcoin is only valuable if it remains the former.

Another promise is that scripts in the blockchain will be executed faithfully and not overridden. Value transfer in Bitcoin is either governed by the scripting language or it's governed by something else.

Cost/benefit analysis is frequently non-linear. What Bitcoin needs rather than a bunch of cost/benefit calculations is a well-thought-out set of core value statements that the community can refer to in order to overrule decisions that look like good ideas in the moment but lead toward a zero NPV in the long term.

When I talked about "crisis" I didn't mean funding crisis - there's more funded work being done on Bitcoin Core now than at any time in the past. I was referring specifically to the way protocol development is grinding to a halt because of a lack of clear design principles combined with a culture that's become hopelessly adversarial - any proposed change is deluged with people coming up with any possible reason to object, without any kind of cost/benefit analysis being done. This is not going to motivate people to work on the many upgrades that we need or want. Scalability is just one of them. Robustness matters too.

That said, although funding isn't in "crisis" per se, it's not where it probably should be. There are only three full time Core devs, four if you count Jeff though I think he also works on Bitpay's Javascript infrastructure too.

For comparison that's the same size as the BitPay Copay multisig wallet project. It's smaller than a lot of indie video games. It's smaller than the teams working on Coinbase, or Circle, or Hive. It's smaller than the team at YouTube that works on counting video playbacks.

Many companies have a larger team working on their intranet!

Yet, this is the backbone that handles about $8 billion of value.

It's not just me that is concerned by that. Yes, Bitcoin is larger than it once was. Compared to the massive growth in importance of the system though, it's not much larger. E.g. the project is maybe 3x larger than it used to be, but the value in dollar terms is 500x larger. So I think we need to try and address this, somehow. I'd like to see more in the region of 10 people working full time on Core, then we'd be making really significant progress on robustness, scaling, decentralisation and privacy issues.

On the other hand, it is not a problem right this second, and the block limit can be increased quickly.

Exactly. He seems to have interests and agenda that don't always line up with the general community. When development does not follow his risky ideas, he creates a crisis where there is none.

its been discussed to death and nothing has been done

Scalability issues discussed:

https://bitcointalksearch.org/topic/long-term-scalability-of-bitcoin-and-the-1-mb-block-size-limit-322748

https://en.bitcoin.it/wiki/Scalability

Good point. What's the plans for this?  Extend to 10mb?  Or something more complex?

One of the posters in this very thread was responsible for funding much of my development time over the last 18 months (not sure if he wants public credit, so I'm not naming him). It's a model that can work... but alas altruists are the minority. It seems, sadly, that most people would rather have someone else pay for the code. Tragedy of the commons and all that.

It is vitally important that we come up with alternative mechanisms for pooling resources to get the necessary projects done, because what we are doing is not working. I have high hopes for Hearn's Lighthouse application, but even more innovation than that may be needed...

the bitcoin client as it is doesn't scale.
right now the block size is limited to 1MB giving a laughable maximum transaction rate of 7 transactions per second.

An interesting point...I though the protocol was fairly stable.
What exactly needs to be developed?

What major bugs are there?

What key features are missing ?

Some times I think they don't want any form of funding 

https://github.com/bitcoin/bitcoin/issues/4079
https://github.com/bitcoin/bitcoin.org/issues/365