Clarify the developers position regarding GHOST #4439

issue ripper234 opened this issue on June 28, 2014
  1. ripper234 commented at 7:35 PM on June 28, 2014: none

    GHOST is a suggestion to speed up the potential processing speed of Bitcoin ~ 600 fold. It requires a hard fork.

    Can someone clarify the position of the Bitcoin devs regarding GHOST? If someone created a pull request that implements GHOST in Core, would that be accepted? What kind of testing/discussion/consensus is need for that?

    I'm aware that such issues are usually discussed on the mailing list, but I'd like to open this as a proper issue. Note that the issue isn't to integrate or not to integrate GHOST, but rather to clarify the 'official position' (whatever that might mean in Bitcoin) regarding GHOST.

    P.S I believe Ethereum are using a variant of GHOST.

  2. laanwj added the label Brainstorming on Jul 28, 2014
  3. laanwj commented at 12:04 PM on July 28, 2014: member

    There is no 'official position'. You should discuss this on the mailing list whether this is a true improvement at all (from a theory angle). If there is a consensus that it would improve things, you can start an implementation. This implementation should then be tested, first on a testnet or side-chain. Lots of eyes need to look at the source code. If a large majority devs agree with the code changes, it will be merged.

  4. sipa commented at 12:11 PM on July 28, 2014: member

    My personal opinion: decreasing the effect of propagation delay on consensus is very interesting, but it's far from the only reason why the block rate or transaction rate on the Bitcoin network are limited. A shorter time between blocks (all else remaining equal) would proportionally impact SPV nodes at least (who will need to download a correspondingly higher number of headers). A higher transaction throughput impacts pretty much all resource requirements on the network.

    When the time comes to increase one of those limits (because software and hardware are capable of the increased traffic and validation overhead that comes with it), we'll need to investigate how to do it, and all research about it is interesting. The choice of when to do this needs far wider consensus than just developers, however, in my opinion, as it affects anyone running a full node.

  5. rebroad commented at 1:56 PM on July 28, 2014: contributor

    @ripper234 That pdf file makes a number of false assumptions. One obvious one is "Once adoption of the currency increases, the system will need to scale to process transactions at a greater rate than before." - firstly, bitcoin is not a currency, but is often being treated as such, and secondly, the system doesn't need to scale (at least, not unless people want to continue treating it as a currency). Bitcoin may indeed fork to include the functionality to let it scale - but there will be people who will want to continue using the bitcoin as it is now, so I believe if a fork ever happens, it will be a fork where both forks have different exchange rates.

  6. jgarzik commented at 1:59 PM on July 28, 2014: contributor

    This is list material, not github material. Please post to bitcoin-development@sourceforge.

  7. jgarzik closed this on Jul 28, 2014

  8. MarcoFalke locked this on Sep 8, 2021

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-04-26 06:15 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me