Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime
Eric, that would be, I think, my sequencenumbers2 branch in which nSequence is an explicit relative lock-time field (unless the most significant bit is set). That has absolutely clear semantics. You should comment on #6312 where this is being discussed. On Wed, Sep 16, 2015 at 7:23 PM, Eric Lombrozo wrote: > I'd rather replace the whole nSequence thing with an explicit relative > locktime with clear semantics...but I'm not going to fight this one too > much. > > > On September 16, 2015 6:40:06 PM EDT, Btc Drak via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> Where do we stand now on which sequencenumbers variation to use? We >> really should make a decision now. >> >> On Fri, Aug 28, 2015 at 12:32 AM, Mark Friedenbach via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >>> So I've created 2 new repositories with changed rules regarding >>> sequencenumbers: >>> >>> https://github.com/maaku/bitcoin/tree/sequencenumbers2 >>> >>> This repository inverts (un-inverts?) the sequence number. nSequence=1 >>> means 1 block relative lock-height. nSequence=LOCKTIME_THRESHOLD means 1 >>> second relative lock-height. nSequence>=0x8000 (most significant bit >>> set) is not interpreted as a relative lock-time. >>> >>> https://github.com/maaku/bitcoin/tree/sequencenumbers3 >>> >>> This repository not only inverts the sequence number, but also >>> interprets it as a fixed-point number. This allows up to 5 year relative >>> lock times using blocks as units, and saves 12 low-order bits for future >>> use. Or, up to about 2 year relative lock times using seconds as units, and >>> saves 4 bits for future use without second-level granularity. More bits >>> could be recovered from time-based locktimes by choosing a higher >>> granularity (a soft-fork change if done correctly). >>> >>> On Tue, Aug 25, 2015 at 3:08 PM, Mark Friedenbach >>> wrote: >>> To follow up on this, let's say that you want to be able to have up to 1 year relative lock-times. This choice is somewhat arbitrary and what I would like some input on, but I'll come back to this point. * 1 bit is necessary to enable/disable relative lock-time. * 1 bit is necessary to indicate whether seconds vs blocks as the unit of measurement. * 1 year of time with 1-second granularity requires 25 bits. However since blocks occur at approximately 10 minute intervals on average, having a relative lock-time significantly less than this interval doesn't make much sense. A granularity of 256 seconds would be greater than the Nyquist frequency and requires only 17 bits. * 1 year of blocks with 1-block granularity requires 16 bits. So time-based relative lock time requires about 19 bits, and block-based relative lock-time requires about 18 bits. That leaves 13 or 14 bits for other uses. Assuming a maximum of 1-year relative lock-times. But what is an appropriate maximum to choose? The use cases I have considered have only had lock times on the order of a few days to a month or so. However I would feel uncomfortable going less than a year for a hard maximum, and am having trouble thinking of any use case that would require more than a year of lock-time. Can anyone else think of a use case that requires >1yr relative lock-time? TL;DR On Sun, Aug 23, 2015 at 7:37 PM, Mark Friedenbach >>> > wrote: > A power of 2 would be far more efficient here. The key question is how > long of a relative block time do you need? Figure out what the maximum > should be ( I don't know what that would be, any ideas?) and then see how > many bits you have left over. > On Aug 23, 2015 7:23 PM, "Jorge Timón" < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev >> wrote: >> > Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the >> > discussion has any thought been given to represent one block with >> more >> > than one increment? This would leave additional space for future >> > signaling, or allow, for example, higher resolution numbers for a >> > sharechain commitement. >> >> No, I don't think anybody thought about this. I just explained this to >> Pieter using "for example, 10 instead of 1". >> He suggested 600 increments so that it is more similar to timestamps. >> ___ >> 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 >>
Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime
I'd rather replace the whole nSequence thing with an explicit relative locktime with clear semantics...but I'm not going to fight this one too much. On September 16, 2015 6:40:06 PM EDT, Btc Drak via bitcoin-dev wrote: >Where do we stand now on which sequencenumbers variation to use? We >really >should make a decision now. > >On Fri, Aug 28, 2015 at 12:32 AM, Mark Friedenbach via bitcoin-dev < >bitcoin-dev@lists.linuxfoundation.org> wrote: > >> So I've created 2 new repositories with changed rules regarding >> sequencenumbers: >> >> https://github.com/maaku/bitcoin/tree/sequencenumbers2 >> >> This repository inverts (un-inverts?) the sequence number. >nSequence=1 >> means 1 block relative lock-height. nSequence=LOCKTIME_THRESHOLD >means 1 >> second relative lock-height. nSequence>=0x8000 (most significant >bit >> set) is not interpreted as a relative lock-time. >> >> https://github.com/maaku/bitcoin/tree/sequencenumbers3 >> >> This repository not only inverts the sequence number, but also >interprets >> it as a fixed-point number. This allows up to 5 year relative lock >times >> using blocks as units, and saves 12 low-order bits for future use. >Or, up >> to about 2 year relative lock times using seconds as units, and saves >4 >> bits for future use without second-level granularity. More bits could >be >> recovered from time-based locktimes by choosing a higher granularity >(a >> soft-fork change if done correctly). >> >> On Tue, Aug 25, 2015 at 3:08 PM, Mark Friedenbach > >> wrote: >> >>> To follow up on this, let's say that you want to be able to have up >to 1 >>> year relative lock-times. This choice is somewhat arbitrary and what >I >>> would like some input on, but I'll come back to this point. >>> >>> * 1 bit is necessary to enable/disable relative lock-time. >>> >>> * 1 bit is necessary to indicate whether seconds vs blocks as the >unit >>> of measurement. >>> >>> * 1 year of time with 1-second granularity requires 25 bits. >However >>> since blocks occur at approximately 10 minute intervals on average, >having >>> a relative lock-time significantly less than this interval doesn't >make >>> much sense. A granularity of 256 seconds would be greater than the >Nyquist >>> frequency and requires only 17 bits. >>> >>> * 1 year of blocks with 1-block granularity requires 16 bits. >>> >>> So time-based relative lock time requires about 19 bits, and >block-based >>> relative lock-time requires about 18 bits. That leaves 13 or 14 bits >for >>> other uses. >>> >>> Assuming a maximum of 1-year relative lock-times. But what is an >>> appropriate maximum to choose? The use cases I have considered have >only >>> had lock times on the order of a few days to a month or so. However >I would >>> feel uncomfortable going less than a year for a hard maximum, and am >having >>> trouble thinking of any use case that would require more than a year >of >>> lock-time. Can anyone else think of a use case that requires >1yr >relative >>> lock-time? >>> >>> TL;DR >>> >>> On Sun, Aug 23, 2015 at 7:37 PM, Mark Friedenbach > >>> wrote: >>> A power of 2 would be far more efficient here. The key question is >how long of a relative block time do you need? Figure out what the >maximum should be ( I don't know what that would be, any ideas?) and then >see how many bits you have left over. On Aug 23, 2015 7:23 PM, "Jorge Timón" < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev > wrote: > > Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the > > discussion has any thought been given to represent one block >with more > > than one increment? This would leave additional space for >future > > signaling, or allow, for example, higher resolution numbers for >a > > sharechain commitement. > > No, I don't think anybody thought about this. I just explained >this to > Pieter using "for example, 10 instead of 1". > He suggested 600 increments so that it is more similar to >timestamps. > ___ > 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 -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.
The exact numbers (95% vs. 75% etc) don't need to be completely specified to start working on an implementation. What really matters for now is defining the states and trigger mechanisms. I'd rather we not argue over the optimal values for supermajority requirement at this point. On September 16, 2015 5:03:43 PM EDT, "Jorge Timón via bitcoin-dev" wrote: >I understand your proposal, but I don't see what it accomplishes >compared >to applying the new rule from the start (in your own blocks) and wait >for >95% for consensus activation (which is my preference and it's much >simpler >to implement). >What are the disadvantages of my approach? What are the advantages of >yours? >On Sep 16, 2015 4:57 PM, "Tier Nolan via bitcoin-dev" < >bitcoin-dev@lists.linuxfoundation.org> wrote: > >> >> >> On Wed, Sep 16, 2015 at 9:54 PM, Jorge Timón >wrote: >> >>> >>> On Sep 16, 2015 4:49 PM, "Tier Nolan via bitcoin-dev" < >>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>> > At 75%, if someone sets the bit, then they should be creating >valid >>> blocks (under the rule). >>> >>> You shouldn't rely on that, some may start applying the restrictions >in >>> their own blocks at 0% and others only at 90%. Until it becomes a >consensus >>> rule it is just part of the standard policy (and we shouldn't rely >on nodes >>> following the standard policy). >>> >> >> It would be a consensus rule. If >75% of the blocks in the last 2016 >> window have the bit set, then reject all blocks that have the bit set >and >> fail to meet the rule. >> >> >> ___ >> 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 -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime
Where do we stand now on which sequencenumbers variation to use? We really should make a decision now. On Fri, Aug 28, 2015 at 12:32 AM, Mark Friedenbach via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > So I've created 2 new repositories with changed rules regarding > sequencenumbers: > > https://github.com/maaku/bitcoin/tree/sequencenumbers2 > > This repository inverts (un-inverts?) the sequence number. nSequence=1 > means 1 block relative lock-height. nSequence=LOCKTIME_THRESHOLD means 1 > second relative lock-height. nSequence>=0x8000 (most significant bit > set) is not interpreted as a relative lock-time. > > https://github.com/maaku/bitcoin/tree/sequencenumbers3 > > This repository not only inverts the sequence number, but also interprets > it as a fixed-point number. This allows up to 5 year relative lock times > using blocks as units, and saves 12 low-order bits for future use. Or, up > to about 2 year relative lock times using seconds as units, and saves 4 > bits for future use without second-level granularity. More bits could be > recovered from time-based locktimes by choosing a higher granularity (a > soft-fork change if done correctly). > > On Tue, Aug 25, 2015 at 3:08 PM, Mark Friedenbach > wrote: > >> To follow up on this, let's say that you want to be able to have up to 1 >> year relative lock-times. This choice is somewhat arbitrary and what I >> would like some input on, but I'll come back to this point. >> >> * 1 bit is necessary to enable/disable relative lock-time. >> >> * 1 bit is necessary to indicate whether seconds vs blocks as the unit >> of measurement. >> >> * 1 year of time with 1-second granularity requires 25 bits. However >> since blocks occur at approximately 10 minute intervals on average, having >> a relative lock-time significantly less than this interval doesn't make >> much sense. A granularity of 256 seconds would be greater than the Nyquist >> frequency and requires only 17 bits. >> >> * 1 year of blocks with 1-block granularity requires 16 bits. >> >> So time-based relative lock time requires about 19 bits, and block-based >> relative lock-time requires about 18 bits. That leaves 13 or 14 bits for >> other uses. >> >> Assuming a maximum of 1-year relative lock-times. But what is an >> appropriate maximum to choose? The use cases I have considered have only >> had lock times on the order of a few days to a month or so. However I would >> feel uncomfortable going less than a year for a hard maximum, and am having >> trouble thinking of any use case that would require more than a year of >> lock-time. Can anyone else think of a use case that requires >1yr relative >> lock-time? >> >> TL;DR >> >> On Sun, Aug 23, 2015 at 7:37 PM, Mark Friedenbach >> wrote: >> >>> A power of 2 would be far more efficient here. The key question is how >>> long of a relative block time do you need? Figure out what the maximum >>> should be ( I don't know what that would be, any ideas?) and then see how >>> many bits you have left over. >>> On Aug 23, 2015 7:23 PM, "Jorge Timón" < >>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>> On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev wrote: > Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the > discussion has any thought been given to represent one block with more > than one increment? This would leave additional space for future > signaling, or allow, for example, higher resolution numbers for a > sharechain commitement. No, I don't think anybody thought about this. I just explained this to Pieter using "for example, 10 instead of 1". He suggested 600 increments so that it is more similar to timestamps. ___ 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] libconsensus and bitcoin development process
On Tue, Sep 15, 2015 at 12:10:37AM -0400, Jeff Garzik via bitcoin-dev wrote: > Refactors however have a very real negative impact. > bitcoin/bitcoin.git is not only the source tree in the universe. > Software engineers at home, at startups, and at major companies are > maintaining branches of their own. Incidentally, it'd help if we got some insight into why those branches are being maintained; what features are in those branches that Bitcoin Core doesn't have? I've run into a number of cases where companies were maintaining forks of Bitcoin Core unnecessarily, where a different, loosely coupled, architecture could do what they needed to do without including the new logic in the codebase itself. -- 'peter'[:-1]@petertodd.org 13137b1bd77e352d28fa36309be1c821180eda408bcb745c signature.asc Description: Digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Scaling Bitcoin conference micro-report
I only have one "correction", included inline. On 09/16/15 21:32, Jeff Garzik via bitcoin-dev wrote: > > During Scaling Bitcoin, Bitcoin Core committers and notable contributors > got together and chatted about where a "greatest common denominator" > type consensus might be. The following is a without-attribution > (Chatham House) summary. This is my own personal summary of the chat; > any errors are my own; this is _not_ a consensus statement or anything > formal. > > - Background (pre-conference, was on public IRC): "net-utxo", > calculating transaction size within block by applying a delta to > transaction size based on the amount of data added, or removed, from the > UTXO set. Fee is then evaluated after the delta is applied. This > aligns user incentives with UTXO resource usage/cost. Original idea by > gmaxwell (and others??). > > - Many interested or at least willing to accept a "short term bump", a > hard fork to modify block size limit regime to be cost-based via > "net-utxo" rather than a simple static hard limit. 2-4-8 and 17%/year > were debated and seemed "in range" with what might work as a short term > bump - net after applying the new cost metric. I would be careful to point out that hard numbers were deliberately NOT discussed. Though some general things were thrown out, they were not extensively discussed nor agreed to. I personally think 2-4 is "in range", though 8 maybe not so much. Of course it depends on exactly how the non-blocksize limit accounting/adjusting is done. Still, the "greatest common denominator" agreement did not seem to be agreeing to an increase which continues over time, but which instead limits itself to a set, smooth increase for X time and then requires a second hardfork if there is agreement on a need for more blocksize at that point. > - Hard fork method: Leaning towards "if (timestamp > X)" flag day hard > fork Y months in the future. Set high bit in version, resulting in a > negative number, to more cleanly fork away. "miner advisement" - > miners, as they've done recently, signal non-binding (Bitcoin Core does > not examine the value) engineering readiness for a hard fork via > coinbase moniker. Some fork cancellation method is useful, if > unsuccessful after Z time elapses. > > - As discussed publicly elsewhere, other forks may be signaled via > setting a bit in version, and then triggering a fork'ing change once a > threshold is reached. > > Chat participants are invited to reply to this message with their own > corrections and comments and summary in their view. > > For the wider community, take this as one of many "inputs" described at > Scaling Bitcoin. Over the next few months developers and the community > should evaluate everything discussed and work towards some concrete > proposal(s) that are implemented, tested and simulated in December in > Hong Kong. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Scaling Bitcoin conference micro-report
During Scaling Bitcoin, Bitcoin Core committers and notable contributors got together and chatted about where a "greatest common denominator" type consensus might be. The following is a without-attribution (Chatham House) summary. This is my own personal summary of the chat; any errors are my own; this is _not_ a consensus statement or anything formal. - Background (pre-conference, was on public IRC): "net-utxo", calculating transaction size within block by applying a delta to transaction size based on the amount of data added, or removed, from the UTXO set. Fee is then evaluated after the delta is applied. This aligns user incentives with UTXO resource usage/cost. Original idea by gmaxwell (and others??). - Many interested or at least willing to accept a "short term bump", a hard fork to modify block size limit regime to be cost-based via "net-utxo" rather than a simple static hard limit. 2-4-8 and 17%/year were debated and seemed "in range" with what might work as a short term bump - net after applying the new cost metric. - Hard fork method: Leaning towards "if (timestamp > X)" flag day hard fork Y months in the future. Set high bit in version, resulting in a negative number, to more cleanly fork away. "miner advisement" - miners, as they've done recently, signal non-binding (Bitcoin Core does not examine the value) engineering readiness for a hard fork via coinbase moniker. Some fork cancellation method is useful, if unsuccessful after Z time elapses. - As discussed publicly elsewhere, other forks may be signaled via setting a bit in version, and then triggering a fork'ing change once a threshold is reached. Chat participants are invited to reply to this message with their own corrections and comments and summary in their view. For the wider community, take this as one of many "inputs" described at Scaling Bitcoin. Over the next few months developers and the community should evaluate everything discussed and work towards some concrete proposal(s) that are implemented, tested and simulated in December in Hong Kong. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.
I understand your proposal, but I don't see what it accomplishes compared to applying the new rule from the start (in your own blocks) and wait for 95% for consensus activation (which is my preference and it's much simpler to implement). What are the disadvantages of my approach? What are the advantages of yours? On Sep 16, 2015 4:57 PM, "Tier Nolan via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > > > On Wed, Sep 16, 2015 at 9:54 PM, Jorge Timón wrote: > >> >> On Sep 16, 2015 4:49 PM, "Tier Nolan via bitcoin-dev" < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> > At 75%, if someone sets the bit, then they should be creating valid >> blocks (under the rule). >> >> You shouldn't rely on that, some may start applying the restrictions in >> their own blocks at 0% and others only at 90%. Until it becomes a consensus >> rule it is just part of the standard policy (and we shouldn't rely on nodes >> following the standard policy). >> > > It would be a consensus rule. If >75% of the blocks in the last 2016 > window have the bit set, then reject all blocks that have the bit set and > fail to meet the rule. > > > ___ > 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] Version bits with timeout and delay.
On Wed, Sep 16, 2015 at 9:54 PM, Jorge Timón wrote: > > On Sep 16, 2015 4:49 PM, "Tier Nolan via bitcoin-dev" < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > At 75%, if someone sets the bit, then they should be creating valid > blocks (under the rule). > > You shouldn't rely on that, some may start applying the restrictions in > their own blocks at 0% and others only at 90%. Until it becomes a consensus > rule it is just part of the standard policy (and we shouldn't rely on nodes > following the standard policy). > It would be a consensus rule. If >75% of the blocks in the last 2016 window have the bit set, then reject all blocks that have the bit set and fail to meet the rule. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.
On Sep 16, 2015 4:49 PM, "Tier Nolan via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > On Wed, Sep 16, 2015 at 9:38 PM, Jorge Timón wrote: >> >> No, 95% is safer and will produce less orphaned blocks. > > The point of the 75% is just as a test run. Enforcement wouldn't happen until 95%. > > At 75%, if someone sets the bit, then they should be creating valid blocks (under the rule). You shouldn't rely on that, some may start applying the restrictions in their own blocks at 0% and others only at 90%. Until it becomes a consensus rule it is just part of the standard policy (and we shouldn't rely on nodes following the standard policy). > ___ > 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] Version bits with timeout and delay.
On Wed, Sep 16, 2015 at 9:38 PM, Jorge Timón wrote: > No, 95% is safer and will produce less orphaned blocks. > The point of the 75% is just as a test run. Enforcement wouldn't happen until 95%. At 75%, if someone sets the bit, then they should be creating valid blocks (under the rule). ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.
No, 95% is safer and will produce less orphaned blocks. 0%is fine to do it in your own blocks. I agree on using height vs time. Rusty, what do you mean by being easier for bip writers? How is writing "block x" any harder than writing "date y". On Sep 16, 2015 4:32 PM, "Tier Nolan via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > > > On Wed, Sep 16, 2015 at 9:27 PM, Jorge Timón wrote: > >> For enforcing new restrictions on your own blocks (thus at the policy >> level, not consensus) you don't need to wait for 75%. You can do it from >> the start (this way all miners setting the bit will enforce the new >> restrictions. >> > At 75%, you have a pretty solid super-majority. > > You can safely reject blocks that have the bit set but are invalid > according to the new rule (as long as everyone who sets the bit does it > too). > > ___ > 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] Version bits with timeout and delay.
On Wed, Sep 16, 2015 at 9:27 PM, Jorge Timón wrote: > For enforcing new restrictions on your own blocks (thus at the policy > level, not consensus) you don't need to wait for 75%. You can do it from > the start (this way all miners setting the bit will enforce the new > restrictions. > At 75%, you have a pretty solid super-majority. You can safely reject blocks that have the bit set but are invalid according to the new rule (as long as everyone who sets the bit does it too). ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.
On Wed, Sep 16, 2015 at 9:19 PM, Rusty Russell wrote: > I couldn't see a use for it, since partial enforcement of a soft fork is > pretty useless. > It isn't useful for actually using the feature, but some miners might set the bit but not actually create blocks that comply with the new rule. This would cause their blocks to be orphaned until they fixed it. OK, *that* variant makes perfect sense, and is no more complex, AFAICT. > > So, there's two weeks to detect bad implementations, then you everyone > stops setting the bit, for later reuse by another BIP. > It could be more than two weeks if the support stays between 80% and 90% for a while. 75%+ checks that blocks with the bit set follow the rule. 95%+ enters lock-in and has the same rules as 75%+, but is irreversible at that point. > You need a timeout: an ancient (non-mining, thus undetectable) node > should never fork itself off the network because someone reused a failed > BIP bit. > I meant if the 2nd bit was part of the BIP. One of the 2 bits is "FOR" and the other is "AGAINST". If against hits 25%, then it is deemed a failure. The 2nd bit wouldn't be used normally. This means that proposals can be killed quickly if they are obviously going to fail. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.
For enforcing new restrictions on your own blocks (thus at the policy level, not consensus) you don't need to wait for 75%. You can do it from the start (this way all miners setting the bit will enforce the new restrictions. On Sep 16, 2015 4:20 PM, "Rusty Russell via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > Tier Nolan via bitcoin-dev > writes: > > On Sun, Sep 13, 2015 at 7:56 PM, Rusty Russell via bitcoin-dev < > > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > >> '''States''' > >> With every softfork proposal we associate a state BState, which begins > >> at ''defined'', and can be ''locked-in'', ''activated'', > >> or ''failed''. Transitions are considered after each > >> retarget period. > >> > > > > I think the 75% rule should be maintained. It confirms that miners who > are > > setting the bit are actually creating blocks that meet the new rule > (though > > it doesn't check if they are enforcing it). > > I couldn't see a use for it, since partial enforcement of a soft fork is > pretty useless. > > Your point about checking that miners are actually doing it is true, > though all stuff being forked in in future will be nonstandard AFAICT. > > I bias towards simplicity for this. > > > What is the reason for aligning the updated to the difficulty window? > > Miners already have that date in their calendar, so prefer to anchor to > that. > > > *defined* > > Miners set bit > > If 75% of blocks of last 2016 have bit set, goto tentative > > > > > > *tentative* > > Miners set bit > > Reject blocks that have bit set that don't follow new rule > > If 95% of blocks of last 2016 have bit set, goto locked-in > > > > > > *locked-in* > > > > Point of no return > > Miners still set bit > > Reject blocks that have bit set that don't follow new rule > > After 2016 blocks goto notice > > OK, *that* variant makes perfect sense, and is no more complex, AFAICT. > > So, there's two weeks to detect bad implementations, then you everyone > stops setting the bit, for later reuse by another BIP. > > > I think counting in blocks is easier to be exact here. > > Easier for code, but harder for BIP authors. > > > If two bits were allocated per proposal, then miners could vote against > > forks to recover the bits. If 25% of the miners vote against, then that > > kills it. > > You need a timeout: an ancient (non-mining, thus undetectable) node > should never fork itself off the network because someone reused a failed > BIP bit. > > > In the rationale, it would be useful to discuss effects on SPV clients > and > > buggy miners. > > > > SPV clients should be recommended to actually monitor the version field. > > SPV clients don't experience a security change when a soft fork occurs? > They're already trusting miners. > > Greg pointed out that soft forks tend to get accompanied by block forks > across activation, but SPV clients should *definitely* be taking those > into account whenever they happen, right? > > Thanks! > Rusty. > ___ > 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] Version bits with timeout and delay.
Tier Nolan via bitcoin-dev writes: > On Sun, Sep 13, 2015 at 7:56 PM, Rusty Russell via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> '''States''' >> With every softfork proposal we associate a state BState, which begins >> at ''defined'', and can be ''locked-in'', ''activated'', >> or ''failed''. Transitions are considered after each >> retarget period. >> > > I think the 75% rule should be maintained. It confirms that miners who are > setting the bit are actually creating blocks that meet the new rule (though > it doesn't check if they are enforcing it). I couldn't see a use for it, since partial enforcement of a soft fork is pretty useless. Your point about checking that miners are actually doing it is true, though all stuff being forked in in future will be nonstandard AFAICT. I bias towards simplicity for this. > What is the reason for aligning the updated to the difficulty window? Miners already have that date in their calendar, so prefer to anchor to that. > *defined* > Miners set bit > If 75% of blocks of last 2016 have bit set, goto tentative > > > *tentative* > Miners set bit > Reject blocks that have bit set that don't follow new rule > If 95% of blocks of last 2016 have bit set, goto locked-in > > > *locked-in* > > Point of no return > Miners still set bit > Reject blocks that have bit set that don't follow new rule > After 2016 blocks goto notice OK, *that* variant makes perfect sense, and is no more complex, AFAICT. So, there's two weeks to detect bad implementations, then you everyone stops setting the bit, for later reuse by another BIP. > I think counting in blocks is easier to be exact here. Easier for code, but harder for BIP authors. > If two bits were allocated per proposal, then miners could vote against > forks to recover the bits. If 25% of the miners vote against, then that > kills it. You need a timeout: an ancient (non-mining, thus undetectable) node should never fork itself off the network because someone reused a failed BIP bit. > In the rationale, it would be useful to discuss effects on SPV clients and > buggy miners. > > SPV clients should be recommended to actually monitor the version field. SPV clients don't experience a security change when a soft fork occurs? They're already trusting miners. Greg pointed out that soft forks tend to get accompanied by block forks across activation, but SPV clients should *definitely* be taking those into account whenever they happen, right? Thanks! Rusty. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.
On Sun, Sep 13, 2015 at 7:56 PM, Rusty Russell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > '''States''' > With every softfork proposal we associate a state BState, which begins > at ''defined'', and can be ''locked-in'', ''activated'', > or ''failed''. Transitions are considered after each > retarget period. > I think the 75% rule should be maintained. It confirms that miners who are setting the bit are actually creating blocks that meet the new rule (though it doesn't check if they are enforcing it). What is the reason for aligning the updated to the difficulty window? *defined* Miners set bit If 75% of blocks of last 2016 have bit set, goto tentative *tentative* Miners set bit Reject blocks that have bit set that don't follow new rule If 95% of blocks of last 2016 have bit set, goto locked-in *locked-in* Point of no return Miners still set bit Reject blocks that have bit set that don't follow new rule After 2016 blocks goto notice *activated* Miners don't set bit for at least 10080 blocks Reject blocks that don't follow new rule '''Failure: Timeout''' > A soft fork proposal should include a ''timeout''. > I think counting in blocks is easier to be exact here. If two bits were allocated per proposal, then miners could vote against forks to recover the bits. If 25% of the miners vote against, then that kills it. In the rationale, it would be useful to discuss effects on SPV clients and buggy miners. SPV clients should be recommended to actually monitor the version field. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.
Rusty,
I think you've covered all the issues discussed now. +1 for submitting to
BIPs repo to get an official number.
Are you planning to write the implementation?
On Sun, Sep 13, 2015 at 7:56 PM, Rusty Russell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi all,
>
> Those who've seen the original versionbits bip, this adds:
>1) Percentage checking only on retarget period boundaries.
>2) 1 retarget period between 95% and activation.
>3) A stronger suggestion for timeout value selection.
>
> https://gist.github.com/rustyrussell/47eb08093373f71f87de
>
> And pasted below, de-formatted a little.
>
> Thanks,
> Rusty.
>
> BIP: ??
> Title: Version bits with timeout and delay
> Author: Pieter Wuille , Peter Todd <
> p...@petertodd.org>, Greg Maxwell , Rusty Russell <
> ru...@rustcorp.com.au>
> Status: Draft
> Type: Informational Track
> Created: 2015-10-04
>
> ==Abstract==
>
> This document specifies a proposed change to the semantics of the
> 'version' field in Bitcoin blocks, allowing multiple backward-compatible
> changes (further called called "soft forks") being deployed in parallel. It
> relies on interpreting the version field as a bit vector, where each bit
> can be used to track an independent change. These are tallied each retarget
> period. Once the consensus change succeeds or times out, there is a
> "fallow" pause after which the bit can be reused for later changes.
>
> ==Motivation==
>
> BIP 34 introduced a mechanism for doing soft-forking changes without
> predefined flag timestamp (or flag block height), instead relying on
> measuring miner support indicated by a higher version number in block
> headers. As it relies on comparing version numbers as integers however, it
> only supports one single change being rolled out at once, requiring
> coordination between proposals, and does not allow for permanent rejection:
> as long as one soft fork is not fully rolled out, no future one can be
> scheduled.
>
> In addition, BIP 34 made the integer comparison (nVersion >= 2) a
> consensus rule after its 95% threshold was reached, removing 2^31 +2 values
> from the set of valid version numbers (all negative numbers, as nVersion is
> interpreted as a signed integer, as well as 0 and 1). This indicates
> another downside this approach: every upgrade permanently restricts the set
> of allowed nVersion field values. This approach was later reused in BIP 66,
> which further removed nVersion = 2 as valid option. As will be shown
> further, this is unnecessary.
>
> ==Specification==
>
> ===Mechanism===
>
> '''Bit flags'''
> We are permitting several independent soft forks to be deployed in
> parallel. For each, a bit B is chosen from the set {0,1,2,...,28}, which is
> not currently in use for any other ongoing soft fork. Miners signal intent
> to enforce the new rules associated with the proposed soft fork by setting
> bit 1B in nVersion to 1 in their blocks.
>
> '''High bits'''
> The highest 3 bits are set to 001, so the range of actually possible
> nVersion values is [0x2000...0x3FFF], inclusive. This leaves two
> future upgrades for different mechanisms (top bits 010 and 011), while
> complying to the constraints set by BIP34 and BIP66. Having more than 29
> available bits for parallel soft forks does not add anything anyway, as the
> (nVersion >= 3) requirement already makes that impossible.
>
> '''States'''
> With every softfork proposal we associate a state BState, which begins
> at ''defined'', and can be ''locked-in'', ''activated'',
> or ''failed''. Transitions are considered after each
> retarget period.
>
> '''Soft Fork Support'''
> Software which supports the change should begin by setting B in all blocks
> mined until it is resolved.
>
> if (BState == defined) {
> SetBInBlock();
> }
>
> '''Success: Lock-in Threshold'''
> If bit B is set in 1916 (1512 on testnet) or more of the 2016 blocks
> within a retarget period, it is considered ''locked-in''. Miners should
> stop setting bit B.
>
> if (NextBlockHeight % 2016 == 0) {
> if (BState == defined && Previous2016BlocksCountB() >= 1916) {
> BState = locked-in;
> BActiveHeight = NextBlockHeight + 2016;
> }
> }
>
> '''Success: Activation Delay'''
> The consensus rules related to ''locked-in'' soft fork will be enforced in
> the second retarget period; ie. there is a one retarget period in
> which the remaining 5% can upgrade. At the that activation block and
> after, the bit B may be reused for a different soft fork.
>
> if (BState == locked-in && NextBlockHeight == BActiveHeight) {
> BState = activated;
> ApplyRulesForBFromNextBlock();
> /* B can be reused, immediately */
> }
>
> '''Failure: Timeout'''
> A soft fork proposal should include a ''timeout''. This is measured
> as the beginning of a calendar year as per this table (suggested
> three years from drafting the soft fork proposal):
>
> Timeout Year>= Seconds Timeout Year>=
Re: [bitcoin-dev] Quick Bitcoin/Pre-Christmas modest blocksize max increase
Jason Livesay via bitcoin-dev wrote: > In order to keep the existing brand momentum, network, and business > investment, These are precisely the issues that the Bitcoin Development team SHOULD NOT concern themselves with as they are not technical in nature. > I believe the smoothest path forward is to build a new, additional > system re-using the bitcoin name. I suggest this new system come > packaged with the bitcoin core client and be referred to as > QuickBitcoin or qbtc or something similar. As far as the public is > concerned it could simply continue to be called bitcoin. The system > will work on top of traditional bitcoins but have a mechanism for > more/faster transactions. Exactly what mechanism doesn't have to be > perfect, it just needs to be reasonably secure/useful and something > that the community will accept. A few members of the development team have already begun doing something along these lines but its future does not look promising. I do not see any indication that this Christmas will be any more or less busy than last Christmas. Correct me if I'm wrong, but retail spending as a whole still makes up only a small percentage of Bitcoin transactions. phm http://phm.link ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
