Quote
If you think you deserve to be whitelisted, write up a post then PM me with the link. Messages without links (or a good reason) will be ignored.
Topic: Alternative Re-Implementations to Bitcoind (Read 385 times)
Check this: https://bitcointalksearch.org/topic/newbie-readme-177133
RE: https://bitcointalksearch.org/topic/a-cautionary-note-i-just-forked-webbtccombitcoin-ruby-via-two-different-ways-260595
I'm deeply respectful to the long standing members of the Bitcoin community and I'm a newer member to this community so cannot fully understand the whole picture of Bitcoin re-implementation.
However the message I'm hearing is that re-implementations are a double edge sword.
On the one hand, we're told that they are healthy (https://bitcoinfoundation.org/blog/?p=204), and then we can see the complete opposite argument to this highlighted in this thread.
Unfortunately I'm not able to comment directly on the original thread (too newbie!), however if I was then, I would like to see some healthy debate about how to support re-implementations as a positive thing. Especially how to avoid issues as originally found with a re-implementation, such as highlighted in the thread.
I'm from a background in testing and would like to highlight that comments out of the San Francisco Conference, was that testing was one of the main issues highlighted over and over again by the core team. It seems that complexity of Bitcoin cannot really be understood by just one person and even if they did, mistakes happen - even to Bitcoind.
My initial suggestion would be that we look at supporting any implementation in a positive way, and in such a way that tackles the prevention of forking or errors.
As a tester I would like to see automated methods to solve this issue, where any implementation can be run against as a way of verifying and validating as an alternative to Bitcoind or Development spec. Perhaps this is a mammoth task but it seems like a positive step to take this approach rather than just relying on alternative implementations tests.
Some healthy debate would be nice! Especially for us newer members of the community who are enthusiastic about Bitcoin development.
If there is already material out there, which is tackling this issues of testing alternative implementation, then please could someone redirect me to it.
I'm deeply respectful to the long standing members of the Bitcoin community and I'm a newer member to this community so cannot fully understand the whole picture of Bitcoin re-implementation.
However the message I'm hearing is that re-implementations are a double edge sword.
On the one hand, we're told that they are healthy (https://bitcoinfoundation.org/blog/?p=204), and then we can see the complete opposite argument to this highlighted in this thread.
Unfortunately I'm not able to comment directly on the original thread (too newbie!), however if I was then, I would like to see some healthy debate about how to support re-implementations as a positive thing. Especially how to avoid issues as originally found with a re-implementation, such as highlighted in the thread.
I'm from a background in testing and would like to highlight that comments out of the San Francisco Conference, was that testing was one of the main issues highlighted over and over again by the core team. It seems that complexity of Bitcoin cannot really be understood by just one person and even if they did, mistakes happen - even to Bitcoind.
My initial suggestion would be that we look at supporting any implementation in a positive way, and in such a way that tackles the prevention of forking or errors.
As a tester I would like to see automated methods to solve this issue, where any implementation can be run against as a way of verifying and validating as an alternative to Bitcoind or Development spec. Perhaps this is a mammoth task but it seems like a positive step to take this approach rather than just relying on alternative implementations tests.
Some healthy debate would be nice! Especially for us newer members of the community who are enthusiastic about Bitcoin development.
If there is already material out there, which is tackling this issues of testing alternative implementation, then please could someone redirect me to it.
Jump to: