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] Extension block proposal by Jeffrey et al
I feel particularly disappointed that while this BIP is 80% similar to my proposal made 2 months ago ( https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013490.html ), Matt Corallo was only the person replied me. Also, this BIP seems ignored the txid malleability of the resolution tx, as my major technical critique of xblock design. But anyway, here I’m only making comments on the design. As I said in my earlier post, I consider this more as an academic topic than something really ready for production use. > This specification defines a method of increasing bitcoin transaction > throughput without altering any existing consensus rules. Softforks by definition tighten consensus rules > There has been great debate regarding other ways of increasing transaction > throughput, with no proposed consensus-layer solutions that have proven > themselves to be particularly safe. so the authors don’t consider segwit as a consensus-layer solution to increase transaction throughput, or not think segwit is safe? But logically speaking if segwit is not safe, this BIP could only be worse. OTOH, segwit also obviously increases tx throughput, although it may not be as much as some people wish to have. > This specification refines many of Lau's ideas, and offers a much simpler > method of tackling the value transfer issue, which, in Lau's proposal, was > solved with consensus-layer UTXO selection. The 2013 one is outdated. As the authors are not quoting it, not sure if they read my January proposal > extension block activation entails BIP141 activation. I think extension block in the proposed form actually breaks BIP141. It may say it activates segregated witness as a general idea, but not a specific proposal like BIP141 > The merkle root is to be calculated as a merkle tree with all extension block > txids and wtxids as the leaves. It needs to be more specific here. How are they exactly arranged? I suggest it uses a root of all txids, and a root of all wtxids, and combine them as the commitment. The reason is to allow people to prune the witness data, yet still able to serve the pruned tx to light wallets. If it makes txid and wtxid as pairs, after witness pruning it still needs to store all the wtxids or it can’t reconstruct the tree > Outputs signal to exit the extension block if the contained script is either > a minimally encoded P2PKH or P2SH script. This hits the biggest question I asked in my January post: do you want to allow direct exit payment to legacy addresses? As a block reorg will almost guarantee changing txid of the resolution tx, that will permanently invalidate all the child txs based on the resolution tx. This is a significant change to the current tx model. To fix this, you need to make exit outputs unspendable for up to 100 blocks. Doing this, however, will make legacy wallet users very confused as they do not anticipate funding being locked up for a long period of time. So you can’t let the money sent back to a legacy address directly, but sent to a new format address that only recognized by new wallet, which understands the lock up requirement. This way, however, introduces friction and some fungibility issues, and I’d expect people using cross chain atomic swap to exchange bitcoin and xbitcoin To summarise, my questions are: 1. Is it acceptable to have massive txid malleability and transaction chain invalidation for every natural happening reorg? Yes: the current spec is ok; No: next question (I’d say no) 2. Is locking up exit outputs the best way to deal with the problem? (I tried really hard to find a better solution but failed) 3. How long the lock-up period should be? Answer could be anywhere from 1 to 100 4. With a lock-up period, should it allow direct exit to legacy address? (I think it’s ok if the lock-up is short, like 1-2 block. But is that safe enough?) 5. Due to the fungibility issues, it may need a new name for the tokens in the ext-block > Verification of transactions within the extension block shall enforce all > currently deployed softforks, along with an extra BIP141-like ruleset. I suggest to only allow push-only and OP_RETURN scriptPubKey in xblock. Especially, you don’t want to replicate the sighash bug to xblock. Also, requires scriptSig to be always empty > This leaves room for 7 future soft-fork upgrades to relax DoS limits. Why 7? There are 16 unused witness program versions > Witness script hash v0 shall be worth the number of accurately counted sigops > in the redeem script, multiplied by a factor of 8. There is a flaw here: witness script with no sigop will be counted as 0 and have a lot free space > every 73 bytes in the serialized witness vector is worth 1 additional point. so 72 bytes is 1 point or 0 point? Maybe it should just scale everything up by 64 or 128, and make 1 witness byte = 1 point . So it won’t provide any “free space” in the block. > Currently defined witness progr
Re: [bitcoin-dev] Extension block proposal by Jeffrey et al
Recently there has been some discussion of an apparent work-in-progress extension block proposal by Christopher Jeffrey, Joseph Poon, Fedor Indutny, and Steven Pair. Since this hasn't been formally posted on the ML yet, perhaps it is still in pre-draft stages and not quite ready for review, but in light of public interest, I think it is appropriate to open it to discussion, and toward this end, I have reviewed the current revision. For reference, the WIP proposal itself is here: https://github.com/tothemoon-org/extension-blocks ==Overall analysis & comparison== This is a relatively complicated proposal, creating a lot of additional technical debt and complexity in comparison to both BIP 141 and hardforks. It offers no actual benefits beyond BIP 141 or hardforks, so seems irrational to consider at face value. In fact, it fits much better the inaccurate criticisms made by segwit detractors against BIP 141. That being said, this proposal is very interesting in construction and is for the most part technically sound. While ill-fit to merely making blocks larger, it may be an ideal fit for fundamentally different block designs such as Rootstock and MimbleWimble in absence of decentralised non-integrated sidechains (extension blocks are fundamentally sidechains tied into Bitcoin directly). ==Fundamental problem== Extension blocks are a risk of creating two classes of "full nodes": those which verify the full block (and are therefore truly full nodes), and those which only verify the "base" block. However, because the extension is consensus-critical, the latter are in fact not full nodes at all, and are left insecure like pseudo-SPV (not even real SPV) nodes. This technical nature is of course true of a softfork as well, but softforks are intentionally designed such that all nodes are capable of trivially upgrading, and there is no expectation for anyone to run with pre-softfork rules. In general, hardforks can provide the same benefits of an extension block, but without the false expectation and pointless complexity. ==Other problems & questions== > These outpoints may not be spent inside the mempool (they must be redeemed from the next resolution txid in reality). This breaks the ability to spend unconfirmed funds in the same block (as is required for CPFP). The extension block's transaction count is not cryptographically committed-to anywhere. (This is an outstanding bug in Bitcoin today, but impractical to exploit in practice; however, exploiting it in an extension block may not be as impractical, and it should be fixed given the opportunity.) > The merkle root is to be calculated as a merkle tree with all extension block txids and wtxids as the leaves. This needs to elaborate how the merkle tree is constructed. Are all the txids followed by all the wtxids (tx hashes)? Are they alternated? Are txid and wtxid trees built independently and merged at the tip? > Output script code aside from witness programs, p2pkh or p2sh is considered invalid in extension blocks. Why? This prevents extblock users from sending to bare multisig or other various possible destinations. (While static address forms do not exist for other types, they can all be used by the payment protocol.) Additionally, this forbids datacarrier (OP_RETURN), and forces spam to create unprovably-unspendable UTXOs. Is that intentional? > The maximum extension size should be intentionally high. This has the same "attacks can do more damage than ordinary benefit" issue as BIP141, but even more extreme since it is planned to be used for future size increases. > Witness key hash v0 shall be worth 1 point, multiplied by a factor of 8. What is a "point"? What does it mean multiplied by a factor of 8? Why not just say "8 points"? > Witness script hash v0 shall be worth the number of accurately counted sigops in the redeem script, multiplied by a factor of 8. Please define "accurately counted" here. Is this using BIP16 static counting, or accurately counting sigops during execution? > To reduce the chance of having redeem scripts which simply allow for garbage data in the witness vector, every 73 bytes in the serialized witness vector is worth 1 additional point. Is the size rounded up or down? If down, 72-byte scripts will carry 0 points...) ==Trivial & process== BIPs must be in MediaWiki format, not Markdown. They should be submitted for discussion to the bitcoin-dev mailing list, not social media and news. > Layer: Consensus (soft-fork) Extension blocks are more of a hard-fork IMO. > License: Public Domain BIPs may not be "public domain" due to non-recognition in some jurisdictions. Can you agree on one or more of these? https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#Recommended_licenses > ## Abstract > > This specification defines a method of increasing bitcoin transaction throughput without altering any existing consensus rules. This is inaccurate. Even soft
Re: [bitcoin-dev] BIP proposal: Generalized version bits voting (bip-genvbvoting)
On Monday, April 03, 2017 9:06:02 AM Sancho Panza via bitcoin-dev wrote: > 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 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. Therefore, BIP 9 and any miner signalling in general is not very useful for deploying these. > - 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) Softforks are not required to use BIP 9, and even if they do, they are not required to use the recommended thresholds. Basically, the problems you're trying to solve don't exist... Luke ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP draft: Extended block header hardfork
Tom, It's clear that you have some rather large gaps in your knowledge of Bitcoin, its rules, implementation and game theory. I highly encourage you spend some time learning more about these things before continuing posting here. https://www.reddit.com/r/BitcoinBeginners/ is a good place to start. It's a safe place where you can ask any question you want without fear of being laughed at. Kind regards, Jean-Paul > On Apr 4, 2017, at 8:44 AM, Greg Sanders via bitcoin-dev > wrote: > > That's BIP30, he linked BIP34: > https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L3004 > >> On Tue, Apr 4, 2017 at 11:32 AM, Tom Zander via bitcoin-dev >> wrote: >> Can you tell me where it is enforced? >> >> The only place I found was here; >> https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1793 >> >> which doesn’t enforce it, all that code does is check that the txid is >> unknown or fully spent. >> And since the below idea from Russel would change the txid, it would seem no >> full client would reject this. >> >> Maybe its in a BIP, but I can’t find it in the code. >> >> On Tuesday, 4 April 2017 16:59:12 CEST James Hilliard wrote: >> > It is a consensus rule >> > https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki >> > >> > On Tue, Apr 4, 2017 at 6:47 AM, Tom Zander via bitcoin-dev >> > >> > wrote: >> > > On Sunday, 2 April 2017 22:39:13 CEST Russell O'Connor via bitcoin-dev >> > > >> > > wrote: >> > >> Someone told me a while back that it would be more natural if we move >> > >> the >> > >> >> > >> nHeight from the coinbase script to the coinbase locktime. Have you >> > >> considered doing this? >> > > >> > > That change would not be a consensus change and thus free to make any >> > > day. >> >> >> -- >> Tom Zander >> Blog: https://zander.github.io >> Vlog: https://vimeo.com/channels/tomscryptochannel >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ 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
Re: [bitcoin-dev] BIP draft: Extended block header hardfork
I notice you didn’t read the actual full line :) If you click on it, you’ll notice at the end of the line it says; “chainparams.GetConsensus().BIP34Hash” so, this is about BIP34. On Tuesday, 4 April 2017 17:44:40 CEST Greg Sanders wrote: > That's BIP30, he linked BIP34: > https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L3004 > > On Tue, Apr 4, 2017 at 11:32 AM, Tom Zander via bitcoin-dev < > > bitcoin-dev@lists.linuxfoundation.org> wrote: > > Can you tell me where it is enforced? > > > > The only place I found was here; > > https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1793 > > > > which doesn’t enforce it, all that code does is check that the txid is > > unknown or fully spent. > > And since the below idea from Russel would change the txid, it would > > seem > > no > > full client would reject this. > > > > Maybe its in a BIP, but I can’t find it in the code. > > > > On Tuesday, 4 April 2017 16:59:12 CEST James Hilliard wrote: > > > It is a consensus rule > > > https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki > > > > > > On Tue, Apr 4, 2017 at 6:47 AM, Tom Zander via bitcoin-dev > > > > > > wrote: > > > > On Sunday, 2 April 2017 22:39:13 CEST Russell O'Connor via > > > > bitcoin-dev > > > > > > > > wrote: > > > >> Someone told me a while back that it would be more natural if we > > > >> move > > > >> the > > > >> > > > >> nHeight from the coinbase script to the coinbase locktime. Have > > > >> you > > > >> considered doing this? > > > > > > > > That change would not be a consensus change and thus free to make > > > > any > > > > day. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP draft: Extended block header hardfork
That's BIP30, he linked BIP34: https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L3004 On Tue, Apr 4, 2017 at 11:32 AM, Tom Zander via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Can you tell me where it is enforced? > > The only place I found was here; > https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1793 > > which doesn’t enforce it, all that code does is check that the txid is > unknown or fully spent. > And since the below idea from Russel would change the txid, it would seem > no > full client would reject this. > > Maybe its in a BIP, but I can’t find it in the code. > > On Tuesday, 4 April 2017 16:59:12 CEST James Hilliard wrote: > > It is a consensus rule > > https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki > > > > On Tue, Apr 4, 2017 at 6:47 AM, Tom Zander via bitcoin-dev > > > > wrote: > > > On Sunday, 2 April 2017 22:39:13 CEST Russell O'Connor via bitcoin-dev > > > > > > wrote: > > >> Someone told me a while back that it would be more natural if we move > > >> the > > >> > > >> nHeight from the coinbase script to the coinbase locktime. Have you > > >> considered doing this? > > > > > > That change would not be a consensus change and thus free to make any > > > day. > > > -- > Tom Zander > Blog: https://zander.github.io > Vlog: https://vimeo.com/channels/tomscryptochannel > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP draft: Extended block header hardfork
Can you tell me where it is enforced? The only place I found was here; https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1793 which doesn’t enforce it, all that code does is check that the txid is unknown or fully spent. And since the below idea from Russel would change the txid, it would seem no full client would reject this. Maybe its in a BIP, but I can’t find it in the code. On Tuesday, 4 April 2017 16:59:12 CEST James Hilliard wrote: > It is a consensus rule > https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki > > On Tue, Apr 4, 2017 at 6:47 AM, Tom Zander via bitcoin-dev > > wrote: > > On Sunday, 2 April 2017 22:39:13 CEST Russell O'Connor via bitcoin-dev > > > > wrote: > >> Someone told me a while back that it would be more natural if we move > >> the > >> > >> nHeight from the coinbase script to the coinbase locktime. Have you > >> considered doing this? > > > > That change would not be a consensus change and thus free to make any > > day. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP draft: Extended block header hardfork
It is a consensus rule https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki On Tue, Apr 4, 2017 at 6:47 AM, Tom Zander via bitcoin-dev wrote: > On Sunday, 2 April 2017 22:39:13 CEST Russell O'Connor via bitcoin-dev > wrote: >> Someone told me a while back that it would be more natural if we move the >> nHeight from the coinbase script to the coinbase locktime. Have you >> considered doing this? > > That change would not be a consensus change and thus free to make any day. > > -- > Tom Zander > Blog: https://zander.github.io > Vlog: https://vimeo.com/channels/tomscryptochannel > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP draft: Extended block header hardfork
On Sunday, 2 April 2017 22:39:13 CEST Russell O'Connor via bitcoin-dev wrote: > Someone told me a while back that it would be more natural if we move the > nHeight from the coinbase script to the coinbase locktime. Have you > considered doing this? That change would not be a consensus change and thus free to make any day. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ___ 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)
On Monday, 3 April 2017 11:06:02 CEST Sancho Panza wrote: > ==Specification== > > To be elaborated. Please do elaborate :) The meat of the proposal is missing. > 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' I agree that the type of forks are rather irrelevant to the voting mechanism. As we remember that BIP109 used a voting bit too. The per-bit (lets call that per-proposal) parameter threshold and windowsize are a different matter though, based on the next paragraph you wrote; > The design of the state machine is envisioned to remain unchanged. 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. Now, to be clear, I am a big fan of making the window size and the threshold more flexible. 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. 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. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
