Gregory Maxwell <gmaxw...@gmail.com> writes: > I can, however, argue it the other way (and probably have in the > past): The bit is easily checked by thin clients, so thin clients > could use it to reject potentially ill-fated blocks from non-upgraded > miners post switch (which otherwise they couldn't reject without > inspecting the whole thing). This is an improvement over not forcing > the bit, and it's why I was previously in favor of the way the > versions were enforced. But, experience has played out other ways, > and thin clients have not done anything useful with the version > numbers. > > A middle ground might be to require setting the bit for a period of > time after rule enforcing begins, but don't enforce the bit, just > enforce validity of the block under new rules. Thus a thin client > could treat these blocks with increased skepticism.
Introducing this later would trigger warnings on older clients, who would consider the bit to represent a new soft fork :( So if we want this middle ground, we should sew it in now, though it adds a other state. Simplest is to have miners keep setting the bit for another 2016 blocks. If we want to later, we can make this a consensus rule. "Bitcoin is hard, let's go shopping!" "With Bitcoin!" "..." Rusty. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
