btcd: a bitcoind alternative written in Go

[coinrevo]

the code is the spec is a bit of a crap base for the future of finance and something we'll leave behind. the more of us there are, the quicker bitcoin will move forward. decentralise everything and distribute the power. we need a solid infrastructure and the bitcoind is really poor.

Is it even possible to have two major reference clients in parallel? Imagine we have a full spec (bitcoinP) and two clients - bitcoinA and bitcoinX with each 50% distribution. each are SSH locked repos (that's the access model we have currently). Then somebody has a good idea on how to improve bitcoinP. The bitcoinX developers think its a great idea, bitoinA developers think its terrible. who gets to decide? very likely bitcoinX would be build as an Alt-Coin. Now you have the question, is all the infrastructure transportable? it seems to me that there is very little evolution of the primitives, and very little development activity compared to the number of people talking about bitcoin now, like silicon valley hotshots, pumping millions into inferior infrastructure. I guess if you have x millions $ in BTC you are going to be rather conservative in introducing changes.

basically the argument goes like this. we have opensource and everybody can suggest changes. therefore its free and anybody can join. this assumes that software is simply the sum of small proposed changes, not of architectural decisions. in reality the development has centralized somewhat. but the Linux/Python/whatever is not good enough as a model. we can't have the equivalent of a Linus Torvalds merging all the changes. but coming up with a better model is very hard. it seems to me that very little profits are being reused to build useful stuff. there is not even the possibility of hosting a server for 100$/year, and funding that through public means, when marketcap has reached 10 billion $. instead we have perhaps a thousand people now trying to produce a Scam AltCoin.

[1713305301]

1713305301

[1713305301]

1713305301

[1713305301]

1713305301

[justusranvier]

the more of us there are, the quicker bitcoin will move forward.

Unfortunately this is not the case.

Bitcoin can only move forward as quickly as the slowest implementation. This is even more true with the slowest implementation is the one use by virtually all the network.

There is no path forward that does not involved either fixing the reference implementation, or convincing the network to abandon it en masse.

[grau]

Bitcoin can only move forward as quickly as the slowest implementation. This is even more true with the slowest implementation is the one use by virtually all the network.

Since we can not eliminate the bottleneck for now, we should seek to control the damage to productivity by isolating and freezing consensus relevant code base of the reference implementation.

We should take out the wallet and replace the badly designed RPC with a bus (e.g. zeromq) that allows wallets and all higher level functions to be built without touching or even understanding the P2P consensus kernel.

Added: I used the word kernel intentionally. The P2P consensus is the operating system of the network for which we need an API that is high performance, language agnostic, simple but correct representation of the current consensus for application developer who create all sorts of wallet and business functions thereby eliminating the bottleneck at those levels.

[justusranvier]

Since we can not eliminate the bottleneck for now, we should seek to control the damage to productivity by isolating and freezing consensus relevant code base of the reference implementation.

"Freezing" is the opposite of progress.

[U1TRA_L0RD]

This can be a great program for the future use of storing bitcoins, thanks OP!

[genjix]

Since we can not eliminate the bottleneck for now, we should seek to control the damage to productivity by isolating and freezing consensus relevant code base of the reference implementation.

"Freezing" is the opposite of progress.

I don't want Bitcoin to change. Changing and extending the protocol/standard is the worst thing we can do. There's far more important stuff that needs to be done implementation side. Moving forwards means freezing the standard, that's why I want to diversify.

[grau]

Since we can not eliminate the bottleneck for now, we should seek to control the damage to productivity by isolating and freezing consensus relevant code base of the reference implementation.

"Freezing" is the opposite of progress.

Not if what is frozen is what should not change. We need competition in higher level features not in shooting for a moving target.

[coinrevo]

satoshi said this about alternative clients:

I don't believe [for] a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network.

In his 575 posts, that is about the strongest statement he ever made.


I suppose Gavin and Mike don't want to put in such strong words, but in the end the algorithm is tied up to the current developers. Which in my mind is a huge flaw in the design of the currency. If Gavin wants to design a payment protocol, he can just go ahead (BIP70-72 are terrible IMO). Any solution to this problem of decision making will be a different cryptocurrency.  

I don't want Bitcoin to change. Changing and extending the protocol/standard is the worst thing we can do.

In other words you want the current devs to continue with the process as it is? All design decision will be stuck forever? I certainly hope not. As soon as one wants to do useful things, which are not possible with fiat, one is kind of stuck. Colored Coin and Mastercoin will not work, for very good and actually quite obvious reasons. One can't transfer property on the bitcoin network.

[U1TRA_L0RD]

What about other crypto currencies

[grau]

Yes, the design depends on getting identical results in a lockstep on what the longest chain and the set of unconfirmed transactions is.

I see no argument in this against competing wallet implementations just like we have seen a variety of miner. The bottleneck in higher level feature development is imposed by poor design, not fundamental reasons.

Added the lockstep is endangered by any new version of the reference implementation itself. Recognize that the most dangerous fork we have seen was between two versions of satoshi's code. Do you need any better argument for an isolation and freeze of that ? We can however only freeze after we create an interface that enables feature development on a higher level.

[coinrevo]

grau, I believe you don't see the depth of the above statement. The fundamental question is: who makes decisions about bitcoin? The current bitcoin developers - granted by what power? They have the SSH keys and can implement more or less whatever they think is right, with rather vague references to the community. The trust and consensus system is very far from perfect. Think about it - from an economic perspective all what bitcoin does is enforce consensus for the balances. It does not enforce consensus about the properties of the network itself (devs, miners, community, users are all seperate groups). The process of development is not formalized in any way. Say an alternative implementation tracks all the features at the beginning. It slowly grows to 51% marketshare. Now the developers have the power to force new changes. There is no way to resolve a conflict.

[grau]

Do not overestimate the power of the core team.

They can not introduce a change that breaks the lockstep immediately, since that would fork the network if not upgraded instantaneously (which is not feasible).

At max they can introduce a change that takes effect well ahead from some some future block on. If the change is highly controversial, then and this opens the time window to build alternate core team that steps up to maintain the version before the change.

[coinrevo]

I think you, like almost all, are seeing this very much from the perspective of bitcoin as it is today, which is a very limited view. Bitcoin in the future can and should be infinitely more, than what it is now. As this is not necessarily btcd related, I will post longer comments elsewhere. But I think you haven't thought this through. Again, imagine two alternative implementations with 50% share. How to resolve conflicts? bitcoin's consensus mechanism is not just about the calculations. it's not just about hashes, IP addresses, ASIC's, etc. we are talking about the future of money. Unfortunately the set of people who can combine both views, the social and technological aspects, is extremely small.

[grau]

I think you, like almost all, are seeing this very much from the perspective of bitcoin as it is today, which is a very limited view.

.....

Unfortunately the set of people who can combine both views, the social and technological aspects, is extremely small.

Do you count yourself to that chosen few ? If yes, show me small piece your wisdom that I am eventually capable to grasp, as I have not seen it yet.

[coinrevo]

If you're interested in these kinds of things I would suggest this resource: http://szabo.best.vwh.net/

When you're saying the bitcoin developers have no power, that doesn't hold up in argument. They have they keys, and they are designing the protocols. What is the input from outside of that group? where is that discussion even taking place? If you approach one of the devs with these questions you wouldn't get a straight answer. I can make a proposal, but this is subject to the lead devs views, which I don't share in many ways. We need much better trust models and infrastructure for collective decision making. we can do better than this messageboard and some mailing list.

[piotr_n]

11 PH/s of the hashing power - how much of it are the devs actually holding?
And do you think whoever is holding it do not realize what kind of power they have?

A sooner you realize that devs have no calls on protocol changes anymore, the sooner you will avoid any further disappointments.  

[genjix]

any dev who makes the argument about having 1 bitcoin is talking rubbish. bitcoind itself has changed massively since its inception and will continue to do so. the problem is people are too trigger happy to go and make destructive changes to the bitcoin consensus core which is both dangerous and harms consensus. bitcoin should be kept pure and simple. sorry but i don't want all the contracts and new prototype theoretical features thrown into bitcoin. by all means use the blockchain (people will anyway), but this stuff is so new. bitcoin should be left alone because it works, and needs to be protected.

for example:

https://github.com/bitcoin/bitcoin/commit/f5857e5c

the sighash is one of the hardest parts of bitcoin. this is not a place I
would optimise.

compare both versions:

https://github.com/bitcoin/bitcoin/blob/f5857e5cb5fb03bee9c05d1dd6ba2621cac49179/src/script.cpp#L978

https://github.com/bitcoin/bitcoin/blob/881a85a22d76c875f519cd54388a419ec6f70857/src/script.cpp#L976

don't mean to criticise sipa since he is working hard. but this is your precious code by satoshi having a radical redesign.

[genjix]

there needs to be a incredible amount of friction against modifying bitcoin's rules. some of these issues are very complex and less than a handful of people understand them worldwide. what happens when you as a user, have no-one representing your interest in that circle.

[justusranvier]

sorry but i don't want all the contracts and new prototype theoretical features thrown into bitcoin.

Sorry, but Bitcoin is not your personal toy.

Quite a few people are waiting for this capability to be returned to the protocol.

[grau]

If you're interested in these kinds of things I would suggest this resource: http://szabo.best.vwh.net/

When you're saying the bitcoin developers have no power, that doesn't hold up in argument. They have they keys, and they are designing the protocols. What is the input from outside of that group? where is that discussion even taking place? If you approach one of the devs with these questions you wouldn't get a straight answer. I can make a proposal, but this is subject to the lead devs views, which I don't share in many ways. We need much better trust models and infrastructure for collective decision making. we can do better than this messageboard and some mailing list.

I said, do not overestimate their power, not that they would not have one. They have to be very careful exercising the power otherwise they could lose it. Should a significant part of the community disagree with their decisions, then the code could be forked and their keys would become worthless with the majority moving away.

We see the trend that non-miner move to SPV slowly erodes the control on that group as a whole. This combined with heavy weight of a few pools concerns me more than the power of core developer.