5 ms·
All great changes, especially BIP 70 and the fixes on transaction malleability and relaying. I'm unconvinced the efforts to make bitcoind (now Bitcoin Core Serv
by mriou 13y ago
All great changes, especially BIP 70 and the fixes on transaction malleability and relaying. I'm unconvinced the efforts to make bitcoind (now Bitcoin Core Server) a "border router" are well-spent however. Software that's optimized for server deployment and larger clusters is fundamentally different from what you would run on your desktop. I personally think that Bitcoin Core should focus on the protocol and extensions to be a good reference implementation, easy to deploy in all environments.
But regardless, great job guys.
- hendzen 13y agoThe router functionality is very important, because bitcoin-core is the only bitcoin implementation capable of verifying transactions & blocks. The reason for this is that the bitcoin protocol, in practice, is whatever bitcoin-core implements, including any and all bugs. All attempts to fully implement bitcoin-core have all had chain splitting bugs (btcd, bitcoinj experimental full verification mode) so they are not yet trusted in production. Unfortunately the wallet handling capabilities of bitcoin-core don't scale to high numbers of wallets. Thus as an org running a service handling many wallets, it is useful to program against a lightweight client API such as bitcoinj, and then have your client peer with "trusted" bitcoin-core nodes.
- mriou 13y agoI've heard that argument many times and all it does is reinforce the idea that no other implementation can work. And how you end-up with an implementation mono-culture. Forks of a single block happen regularly, it can be dealt with. A production system can detect a fork and check the reference implementation's behavior, preventing any longer fork. The *coin ecosystem need more than one implementation, a single codebase can't cater to all uses. I should know, I'm an Apache member.
- hendzen 13y agoForks of a single block ("orphans") are expected due to block propagation taking a nonzero amount of time. That's very different than the case where say 50% of the network is running bitcoind, and the other 50% is running btcd, and some transaction triggers an edge case in either implementation that causes one implementation to accept the transaction and another to reject it. I think multiple compatible implementations would be great to have, but we don't have them at the moment, and in the meantime companies handling huge numbers of bitcoin transactions need a solution that works today. So I applaud the bitcoin-core team for catering to the increasingly common use case of using bitcoind only for consensus.
- mriou 13y agoAnd it happened even only with bitcoin-core. Anyhow the 50/50% scenario across implementations is unlikely to happen if everyone seeing a new one cries forking wolf. I do empathize with the need of solutions for today though. I was just thinking about tomorrow.
- bachback 13y agoalternative implementations would mean you need consensus between different groups of developers holding the keys to the software. unlikely to be a good idea.
- wyager 13y agoWhat chain-splitting bug did btcd have?
- hendzen 13y agoHere's a recent commit fixing one. https://github.com/conformal/btcscript/commit/299dcc2fad071d33e5492af381f74dfc630363ae https://github.com/conformal/btcscript/commit/299dcc2fad071d... Chain splitting bugs in btcd get fixed all the time, that's why its considered alpha quality software.