[bitcoin-dev] BIP135 implementation on Bitcoin Core available for review
I'm pleased to announce the completion of a Bitcoin Core implementation of BIP135: https://github.com/bitcoin/bitcoin/pull/10437 Review comments appreciated, and happy to discuss / answer questions about the implementation in this thread or on Github. Sancho BIP135: https://github.com/bitcoin/bips/blob/master/bip-0135.mediawiki___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Generalized versionbits BIP requesting number assignment
Hola, I've submitted the generalized versionbits specification for BIP number assignment: https://github.com/bitcoin/bips/pull/532 Your feedback and comments welcome. The spec has been updated to include a link to the reference implementation. I hope to find time soon to produce a similar reference implementation on Bitcoin Core. Sancho___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Reference implementation (wip) of bip-genvbvoting (generalized version bits)
Dear all, An initial reference implementation of bip-genvbvoting (spec: [1]) is now available at https://github.com/sanch0panza/bitcoin/commits/genvbvoting-bu-dev-clean1 starting at commit fdd83383436ee43b072c258d4a6feb713902c77e . This development is based against the Bitcoin Unlimited 'dev' branch, and has been submitted as PR458 to BU [2]. The naming of the new 'bipgenvb_forks' output section in the 'getblockchain' RPC interface is to be considered temporary while the BIP has no formal number. I would be happy to get any feedback while I implement a corresponding pull request for a reference implementation on Bitcoin Core. Due to other commitments this may come at a later stage - if someone else is eager to port it over, please feel free. Regards, Sancho [1] https://github.com/sanch0panza/bips/blob/bip-genvbvoting/bip-genvbvoting.mediawiki [2] https://github.com/BitcoinUnlimited/BitcoinUnlimited/pull/458 P.S. The revised "unknown version check" code is considered an implementation specific and not part of core functionality, and is consequently not fully covered by regression tests.___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: Soft Fork Threshold Signaling
> However, my point is that the threshold should be [...] not fixed in the > soft-fork proposal My proposal makes it configurable (as well as window size, grace period etc.) > I agree that coinbase space might be a limitation. I still like the coinbase idea though - more than using up the BIP9 versionbits range for verbose signaling. BIP9 (and other proposals which use those 29 versionbits) currently assume that the participants on the network will coordinate in some form or other, to agree on what the bits mean (in terms of change deployments). It would be very easy to also agree on a set of "standard" threshold levels and map those onto e.g. 1 byte. Then, in the coinbase, one could have pairs of bit numbers and bytes, e.g. "/1A/2B/3C/" where the bytes values corresponding to 'A', 'B', 'C', ... are standardized deployment schedules that people find useful. So a BIP9 conformant schedule could be A = 95% / 2016 window, while B = 75%/2016, etc. This would be quite a compact yet still readable signaling. The space of values is large enough that I doubt we'd see much contention. Regards Sancho___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: Soft Fork Threshold Signaling
Thomas, I wonder if you've seen my proposal on how to make BIP9 more configurable: https://github.com/sanch0panza/bips/blob/bip-genvbvoting/bip-genvbvoting.mediawiki This could be extended with a coinbase signaling feature as you suggest. This could include parameter information for forks which a miner is signaling, for coordination. Currently I've not included something like this, but it might make a nice addition. One problem is the limited space in coinbase for embedding data on the large number of possible independent deployments. Regards, Sancho___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] A Small Modification to Segwit
Tom Zander wrote: > The version field is still needed to actually allow future block version > upgrades. We would cut off our road forward if that were to be blocked. I tend to agree, if all 32 bits were given up to grinding. But it's worth pointing out that BIP9 is purely informational, and the top 3 bits are still reserved for other purposes. One of them could perhaps be used to signal for an extended version field somewhere else, leaving the bottom 29 as entropy? Not a direction I prefer, but just a technical possibility perhaps.___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Proposed CSV configuration file format for bip-genvbvoting
Hi, The link below includes documentation about a proposed CSV-based file format for fork deployment data (tentative config filename: forks.csv). This is planned to be used by my reference implementation of bip-genvbvoting (which is still in development - TBA later). Other BIP9 improvement proposals are of course encouraged to use this format, and I'm happy to discuss extensions of it for things like supporting flag days or direct-to-activation transitions. Regards, Sancho https://raw.githubusercontent.com/sanch0panza/bitcoin/genvbvoting-bu-dev/doc/genvbvoting.md___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] A Small Modification to Segwit
> I completely agree that it will be in the long term interest of bitcoin to > migrate, gradually, toward a commoditized POW away from the current mass > centralization. There is a big problem here though: Hundreds of millions of > dollars have been spent on the current algorithm, and will be a huge loss if > this is not done slowly enough, and the miners who control the chain > currently would likely never allow this change to happen. > Do you have any ideas regarding how to mitigate the damage of such a change > for the invested parties? Or even how we can make the change agreeable for > them? Apologies for interjecting a thought on this topic. My belief is that Bitcoin could grow freely, and become worth enough so that mining becomes profitable even for those of us in countries without free / subsidized electricity. By that time, buying commodity mining equipment (ASIC-based) from major manufacturers should be no problem, esp. not for existing Bitcoin holders. I see no sign that current major miners are principally opposed to such a natural process of decentralization of Bitcoin mining. Sancho___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP proposal: Generalized version bits voting (bip-genvbvoting)
Thomas, > the change is not opt-in and will require coordination; and the continuation > of the chain thereafter depends on people actually running the hard-fork > code, not just being aware there is something happening. This situation applies to soft forks as well. - if you wish your software to validate correctly, it is not opt-in - it requires coordination to activate without much orphan risk to miners (hence BIP9). Witness the long preparation time ahead of SegWit deployment for wallet providers, miners etc. to coordinate to support it on their systems - after activation, it depends on people running it (most notably miners, otherwise the soft-fork is no longer enforced leading to a hard fork) - awareness alone does not ensure full validation capability is retained during a soft fork Therefore, these differences seem insignificant enough to merit treating soft and hard forks equal in terms of the coordination features afforded through the versionbits. Sancho___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] bip-genvbvoting : more complete specification up for review
Hi all, I have put up an initial draft of the full 'bip-genvbvoting' (generalized version bits voting) specification for review: https://github.com/sanch0panza/bips/blob/bip-genvbvoting/bip-genvbvoting.mediawiki Comments are again most welcome - and my thanks to those reviewers who took a look at the initial rough draft [1]. A prime goal is that this BIP proposal should end up allowing full backward compatibility with the existing BIP9 state machine, if wishing to do so for a deployment. In fact, this will be necessary to maintain full compatibility with any ongoing deployments. I will work on a reference implementation which might also turn up inadequacies of the proposed specification. A link to this will follow once it is mature enough for review. Sancho [1]https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013969.html___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP proposal: Generalized version bits voting (bip-genvbvoting)
> BIP 9 doesn't limit itself, merely acknowledges the *inherent* nature of it > not being applicable to hardforks. BIP 9 provides a mechanism for having > miners coordinate softforks because they can make the upgrade process smoother > this way. But the same is not true of hardforks: miners are essentially > irrelevant to them, and cannot make the process any smoother. I accept that BIP9 is inherently concerned only with softforks, as it is explicit about this in every instance. However, I see no fundamental distinction between the 'royal privilege' assigned to miners w.r.t. softfork activation and the role they would play in properly coordinated hardforks. In either case, the majority of miners would hopefully want to wait for the right conditions to create the fork block, whether that block be the first one to contain SegWit transactions or the first one to be larger than 1MB (to give two current examples). The advance coordination with the rest of the users in the system seems important in either case. This is a big motivator for this BIP: the versionbits can be used as a coordination mechanism for hardforks just as much as softforks. With the added flexibility offered by this BIP, miners could use these bits to make the process smoother for softforks as well as hardforks. For example (this is an idea I did not write in the initial BIP draft), the period for which a fork on a particular bit remains LOCKED_IN could be made customizable too, instead of one single retargeting period. This would allow fork implementors to specify a longer adaptation period suitable to the impacts of the feature they are planning to deploy. > Therefore, BIP 9 and any miner signalling in general is not very useful > for deploying these. I think BIP9 is a very useful tool that allows a decent determination of how much of the hashing power supports a particular fork proposal. My view is that both soft and hard forks without support from the majority of miners place themselves at high risk. In general every soft fork can result in a counter hardfork by those who are not aligned with its objectives, just like every hardfork can result in a counter softfork for the same reason by those opposed to it. It seems to me that this somewhat balances out the (dis)advantages and effectively puts these fork types on a similar footing. This is a rationale for generalizing the signaling mechanism introduced by BIP9. In practice, developers will still need to choose whether their feature is best deployed by softfork or hardfork. This proposal affords them that choice, and does not propose any arbitrary conditions (e.g. a predefined split of the versionbits range into particular categories of forks or activation levels). > Softforks are not required to use BIP 9, and even if they do, they are not > required to use the recommended thresholds. This is true, but introducing more flexibility into the signaling framework of BIP9 means it will be more useful for further developments - including a potential hardfork which was on the Core roadmap to accomodate certain wishlist items that cannot easily be addressed by softforks.___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP proposal: Generalized version bits voting (bip-genvbvoting)
[Apologies, reposting this in an attempt to improve on the botched formatting of previous reply. I am still getting used to the limitations of this mail service.] Thanks for the feedback. I'll post a link to more refined proposal on github once that elaboration is more complete. For now I think more discussion will be very helpful. I think the flexibility around the tallying window size will take the most careful consideration, so that a user of this proposal can retain full compatibility with BIP9 for a certain versionbit if (s)he wishes. > The entire point of BIP9 is to allow nodes that do not know about an upgrade > to still have a functional state machine. But I don’t see how you can have a > state machine if the two basic variables that drive it are not specified. What I mean by the state machine remaining essentially unchanged is that its basic design (states and transitions) would remain the same. But the parameters that decide those transitions would be unique per bit. I think you misunderstood me if you think there will be strictly one singular state machine. Instead nodes would effectively be running a state machine instance for each signaling bit - with each state machine possibly (but not necessarily!) configured differently. An initial implementation might provide this all in compiled code. A slightly more sophisticated implementation would push the signaling configuration mostly into an external configuration file which could adhere to a fixed format and could easily be adapted and shared between implementations. > But in my opinion we would not be able to have a state machine without those > variables in the actual BIP because old nodes would miss the data to > transition to certain states. As I see it, this is the same situation we are in now with old nodes - they see that there is some action on unknown bits, but they can do nothing more than warn their operators about this. This proposal does not fundamentally change that situation. > Maybe an idea; we have 30 bits. 2 currently in use (although we could reuse > the CSV one). Maybe we can come up with 3 default sets of properties and > when a proposal starts to use bit 11 it behaves differently than if it uses > 22. One could place conventions on how certain bit ranges are used, but I don't much see the point of the BIP doing this, although it could suggest examples. I would prefer if the BIP's reference implementation provides strict BIP9 compatibility in that how it configures the bits (i.e. all with 2016 block windows evaluated in strict synchronicity with BIP9, and default 95% thresholds). Of course in reality most bits are unused today. Someone wishing to use a bit for a feature deployment would announce so publicly (e.g. in a BIP) and release an implementation which is suitably configured. Others wishing to provide compatibility with that feature would adjust their code and bip-genvbvoting configuration files accordingly. Sancho___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP proposal: Generalized version bits voting (bip-genvbvoting)
Thanks for the feedback. I'll post a link to more refined proposal on github once that elaboration is more complete. For now I think more discussion will be very helpful. I think the flexibility around the tallying window size will take the most careful consideration, so that a user of this proposal can retain full compatibility with BIP9 for a certain versionbit if (s)he wishes. The entire point of BIP9 is to allow nodes that do not know about an upgrade to still have a functional state machine. But I don’t see how you can have a state machine if the two basic variables that drive it are not specified. What I mean by the state machine remaining essentially unchanged is that its basic design (states and transitions) would remain the same. But the parameters that decide those transitions would be unique per bit. I think you misunderstood me if you think there will be strictly one singular state machine. Instead nodes would effectively be running a state machine instance for each signaling bit - with each state machine possibly (but not necessarily!) configured differently. An initial implementation might provide this all in compiled code. A slightly more sophisticated implementation would push the signaling configuration mostly into an external configuration file which could adhere to a fixed format and could easily be adapted and shared between implementations. But in my opinion we would not be able to have a state machine without those variables in the actual BIP because old nodes would miss the data to transition to certain states. As I see it, this is the same situation we are in now with old nodes - they see that there is some action on unknown bits, but they can do nothing more than warn their operators about this. This proposal does not fundamentally change that situation. Maybe an idea; we have 30 bits. 2 currently in use (although we could reuse the CSV one). Maybe we can come up with 3 default sets of properties and when a proposal starts to use bit 11 it behaves differently than if it uses 22. One could place conventions on how certain bit ranges are used, but I don't much see the point of the BIP doing this, although it could suggest examples. I would prefer if the BIP's reference implementation provides strict BIP9 compatibility in that how it configures the bits (i.e. all with 2016 block windows evaluated in strict synchronicity with BIP9, and default 95% thresholds). Of course in reality most bits are unused today. Someone wishing to use a bit for a feature deployment would announce so publicly (e.g. in a BIP) and release an implementation which is suitably configured. Others wishing to provide compatibility with that feature would adjust their code and bip-genvbvoting configuration files accordingly. Sancho___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] BIP proposal: Generalized version bits voting (bip-genvbvoting)
�Hola! Please find below a proposal [resubmission] for a new informational BIP provisionally named 'bip-genvbvoting'. I present it here in rough draft for your esteemed consideration and as a basis for discussion. Best regards, Sancho --- begin draft of bip-genvbvoting --- ==Preamble== BIP: ? Title: Generalized version bits voting Author: Sancho Panza Status: Draft Type: Informational Created: 2017-03-29 Replaces: 9 License: CC0-1.0 GNU-All-Permissive ==Abstract== This document describes a generalized version bits voting scheme based on and intended to replace BIP9. The generalization consists of allowing each version bit to be treated individually using a configurable percentage threshold and window size, instead of the fixed 95% (mainnet) and 2016 block window specified in BIP9. The state machine and governing parameters (name, bit, starttime, timeout) remain as is, but additional parameters called 'threshold' and 'windowsize' are added to the per-bit set. As before, a set of per-chain parameters will exist for the version bits governed by BIP9. ==Motivation== The Bitcoin protocol requires a flexible consensus-finding scheme to ensure that it can adapt to the needs of the market (its users) and remain competitive as an electronic payment system. While BIP9 has served the community reasonably well until now, the author remarks several shortcomings in its approach: - it limits itself to backward-compatible changes, precluding its applicability to hard forks - a fixed 95% threshold is not flexible enough to allow for a 'spectrum of contentiousness' to be represented - the 95% threshold allows small minorities to veto proposed changes, lead to stagnation (viz. current standoffs) A more generalized implementation of voting on changes using version bits can address these issues in a way that can satisfy the needs of both soft and hard forks, as well as represent varying degrees of contentiousness. ==Specification== To be elaborated. It is thought that only cosmetic changes are needed to generalize from only soft forks to 'soft or hard forks', and to add the additional per-bit parameters 'threshold' and 'windowsize' References to fixed values will need to be eliminated and replaced by respective parameters. The design of the state machine is envisioned to remain unchanged. ==Implementation== A reference implementation can be constructed after elaboration of the specification. ==Copyright== This BIP is dual-licensed under the Creative Commons CC0 1.0 Universal and GNU All-Permissive licenses. --- end draft of bip-genvbvoting ---___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
