📅 Original date posted:2015-09-01
📝 Original message:I think the "Kill King Bitcoin - Long Live the King" call is somewhat
inevitable, and we should expect this to happen from time-to-time, now that
the cat is out of the bag.
However, I fully agree with Adam that livenet is probably not the place to
play this game, and I'm also not convinced that testnet is either.
I often wondered if there is any appetite for a no-holds-barred, anything
goes, bitcoin fork that would allow for the kind of valuable
experimentation that Peter R is suggesting? This is a different concept
than an alt-coin because it would be undoubtedly unstable until consensus
is reached - and that is the whole idea. It hopefully would inform future
decisions about what gets rolled into Core. One problem I see with doing
this, is the lack of incentive.
Chris
On 1 September 2015 at 10:42, Adam Back via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Peter this seems to be a not well thought through course of action,
> fun though it maybe informally or philosophically or to tweak various
> peoples sensibilities.
>
> Bitcoin is a consensus system that does not work if there are
> incompatible versions of consensus code competing on the network.
> This is why work is underway on libconsensus so we can see diversity
> of implementation without the risk of incompatibility arising by
> software defect. It has proven quite hard to match independent
> consensus implementations bit for bit against an adaptive adversary
> looking for inconsistencies in interpretation.
>
> In terms of protocol updates it is more constructive therefore that
> people with a technical interest analyse and validate others proposals
> via testing, or make their own proposals so that we can arrive at a
> well validated upgrade mechanism that everyone upgrades to in a
> coordinated fashion.
>
> Previous intentional upgrades to bitcoin have been
> backwards-compatible (via soft-fork which can be secured reasonably
> using a miner vote trigger and temporary SPV security for those who
> not yet upgraded) but the current topic of a throughput increase is
> non-backwards-compatible (via a hard-fork), and the way to minimise
> risk of such an upgrade is for everyone to try to upgrade well in
> advance of an agreed upgrade schedule, and to be all upgrading to the
> *same* consensus rule change.
>
> Encouraging nodes or miners to "vote" by running a range of different
> consensus rules isnt really constructive I feel - it alarms people who
> understand the risks, sets things on a path that have to be fixed
> while in flight by obvious implication, and isnt collaborative - so it
> risks being a politicising suggestion on what should be a purely
> technical topic of choosing the best approach, where it is best to
> strive to keep things non-emotive and professional and technically
> focussed. Such calls are offending the technical sensibilities of
> people who understand the risks.
>
> Anyway lets try to keep things constructive and focus on analysing
> proposals.
>
> Adam
>
> On 31 August 2015 at 19:16, Peter R via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > I agree, s7r, that Bitcoin Core represents the most stable code base. To
> > create multiple implementations, other groups would fork Bitcoin Core
> > similar to what Bitcoin XT did. We could have:
> >
> > - Bitcoin-A (XT)
> > - Bitcoin-B (Blockstream)
> > - Bitcoin-C (promoting BIP100)
> > - Bitcoin-D
> > - etc.
> >
> > Innovation from any development group would be freely integrated by any
> > other development group, if desired. Of course, each group would have a
> > very strong incentive to remain fork-wise compatible with the other
> > implementations.
> >
> > In fact, this just gave me a great idea! Since Wladimir has stated that
> he
> > will not integrate a forking change into Core without Core Dev
> consensus, I
> > suggest we work together to never reach consensus with Bitcoin Core.
> This
> > will provide impetus for new implementations to fork from Core (like XT
> did)
> > and implement whatever scaling solution they deem best. The users will
> then
> > select the winning solution simply based on the code they choose to run.
> > The other implementations will then rush to make compatible changes in
> order
> > to keep their dwindling user bases.
> >
> > This is the decentralized spirit of Bitcoin in action. Creative
> > destruction. Consensus formed simply by the code that gets run.
> >
> > Let's kill Bitcoin Core and allow the green shoots of a garden of new
> > implementations to grow from its fertile ashes.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150901/8d5ffbbb/attachment.html>;
Chris D'Costa [ARCHIVE] /
npub1qv…x33a6
2023-06-07 17:38:56
in reply to nevent1q…wpnn
Author Public Key
npub1qvgc8w7mhjaspd7y2z9xuywch4xdll2rm6vy598rnmw0cuvezqnqfx33a6Published at
2023-06-07 17:38:56Event JSON
{
"id": "c29ec57458614846d8d53e044d21ebc7113001748e8d8a6f4b79251320c6ac1c",
"pubkey": "031183bbdbbcbb00b7c4508a6e11d8bd4cdffd43de984a14e39edcfc71991026",
"created_at": 1686159536,
"kind": 1,
"tags": [
[
"e",
"ef7dd733baa635c8b09bf401eb3f9c67ca63dce69308d41bbc389dd40256aed2",
"",
"root"
],
[
"e",
"e77f3e9e3f158111e306ac1fcfed0c5d3d0179c1fddded62033a86d084b210ec",
"",
"reply"
],
[
"p",
"ee0fa66772f633411e4432e251cfb15b1c0fe8cd8befd8b0d86eb302402a8b4a"
]
],
"content": "📅 Original date posted:2015-09-01\n📝 Original message:I think the \"Kill King Bitcoin - Long Live the King\" call is somewhat\ninevitable, and we should expect this to happen from time-to-time, now that\nthe cat is out of the bag.\n\nHowever, I fully agree with Adam that livenet is probably not the place to\nplay this game, and I'm also not convinced that testnet is either.\n\nI often wondered if there is any appetite for a no-holds-barred, anything\ngoes, bitcoin fork that would allow for the kind of valuable\nexperimentation that Peter R is suggesting? This is a different concept\nthan an alt-coin because it would be undoubtedly unstable until consensus\nis reached - and that is the whole idea. It hopefully would inform future\ndecisions about what gets rolled into Core. One problem I see with doing\nthis, is the lack of incentive.\n\nChris\n\nOn 1 September 2015 at 10:42, Adam Back via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Peter this seems to be a not well thought through course of action,\n\u003e fun though it maybe informally or philosophically or to tweak various\n\u003e peoples sensibilities.\n\u003e\n\u003e Bitcoin is a consensus system that does not work if there are\n\u003e incompatible versions of consensus code competing on the network.\n\u003e This is why work is underway on libconsensus so we can see diversity\n\u003e of implementation without the risk of incompatibility arising by\n\u003e software defect. It has proven quite hard to match independent\n\u003e consensus implementations bit for bit against an adaptive adversary\n\u003e looking for inconsistencies in interpretation.\n\u003e\n\u003e In terms of protocol updates it is more constructive therefore that\n\u003e people with a technical interest analyse and validate others proposals\n\u003e via testing, or make their own proposals so that we can arrive at a\n\u003e well validated upgrade mechanism that everyone upgrades to in a\n\u003e coordinated fashion.\n\u003e\n\u003e Previous intentional upgrades to bitcoin have been\n\u003e backwards-compatible (via soft-fork which can be secured reasonably\n\u003e using a miner vote trigger and temporary SPV security for those who\n\u003e not yet upgraded) but the current topic of a throughput increase is\n\u003e non-backwards-compatible (via a hard-fork), and the way to minimise\n\u003e risk of such an upgrade is for everyone to try to upgrade well in\n\u003e advance of an agreed upgrade schedule, and to be all upgrading to the\n\u003e *same* consensus rule change.\n\u003e\n\u003e Encouraging nodes or miners to \"vote\" by running a range of different\n\u003e consensus rules isnt really constructive I feel - it alarms people who\n\u003e understand the risks, sets things on a path that have to be fixed\n\u003e while in flight by obvious implication, and isnt collaborative - so it\n\u003e risks being a politicising suggestion on what should be a purely\n\u003e technical topic of choosing the best approach, where it is best to\n\u003e strive to keep things non-emotive and professional and technically\n\u003e focussed. Such calls are offending the technical sensibilities of\n\u003e people who understand the risks.\n\u003e\n\u003e Anyway lets try to keep things constructive and focus on analysing\n\u003e proposals.\n\u003e\n\u003e Adam\n\u003e\n\u003e On 31 August 2015 at 19:16, Peter R via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e I agree, s7r, that Bitcoin Core represents the most stable code base. To\n\u003e \u003e create multiple implementations, other groups would fork Bitcoin Core\n\u003e \u003e similar to what Bitcoin XT did. We could have:\n\u003e \u003e\n\u003e \u003e - Bitcoin-A (XT)\n\u003e \u003e - Bitcoin-B (Blockstream)\n\u003e \u003e - Bitcoin-C (promoting BIP100)\n\u003e \u003e - Bitcoin-D\n\u003e \u003e - etc.\n\u003e \u003e\n\u003e \u003e Innovation from any development group would be freely integrated by any\n\u003e \u003e other development group, if desired. Of course, each group would have a\n\u003e \u003e very strong incentive to remain fork-wise compatible with the other\n\u003e \u003e implementations.\n\u003e \u003e\n\u003e \u003e In fact, this just gave me a great idea! Since Wladimir has stated that\n\u003e he\n\u003e \u003e will not integrate a forking change into Core without Core Dev\n\u003e consensus, I\n\u003e \u003e suggest we work together to never reach consensus with Bitcoin Core.\n\u003e This\n\u003e \u003e will provide impetus for new implementations to fork from Core (like XT\n\u003e did)\n\u003e \u003e and implement whatever scaling solution they deem best. The users will\n\u003e then\n\u003e \u003e select the winning solution simply based on the code they choose to run.\n\u003e \u003e The other implementations will then rush to make compatible changes in\n\u003e order\n\u003e \u003e to keep their dwindling user bases.\n\u003e \u003e\n\u003e \u003e This is the decentralized spirit of Bitcoin in action. Creative\n\u003e \u003e destruction. Consensus formed simply by the code that gets run.\n\u003e \u003e\n\u003e \u003e Let's kill Bitcoin Core and allow the green shoots of a garden of new\n\u003e \u003e implementations to grow from its fertile ashes.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150901/8d5ffbbb/attachment.html\u003e",
"sig": "2adf25e48dc5a7588dd9f0c857dc1032a94cdcd2b64d32e2223283e839c096336f52420c0a40813789a5ed135c824c16d80559f49a851b70f80dca76694c6885"
}