[bitcoin-dev] The increase of max block size should be determined by block height instead of block time
In many BIPs we have seen, include the latest BIP202, it is the block time that determine the max block size. From from pool's point of view, it cannot issue a job with a fixed ntime due to the existence of ntime roll. It is hard to issue a job with the max block size unknown. For developers, it is also easier to implement if max block size is a function of block height instead of time. Block height is also much more simple and elegant than time. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP - Block size doubles at each reward halving with max block size of 32M
How about these specs: * 1 MB, height < 21; * 2 MB, 21 <= height < 42; * 4 MB, 42 <= height < 63; * 8 MB, 63 <= height < 84; * 16 MB, 84 <= height < 105; * 32 MB, height >= 105. On Fri, Nov 13, 2015 at 7:47 AM, John Sacco via bitcoin-dev wrote: > Hi Devs, > > > Please consider the draft proposal below for peer review. > > > Thanks, > > > John > > > BIP > > BIP: ? > > Title: Block size doubles at each reward halving with max block size of > 32M > > Author: John Sacco > > Status: Draft > > Type: Standards Track > > Created: 2015-11-11 > > Abstract > > Change max block size to 2MB at next block subsidy halving, and double the > block size at each subsidy halving until reaching 32MB. > > Copyright > > This proposal belongs in the public domain. Anyone can use this text for any > purpose with proper attribution to the author. > > Motivation > > 1.Gradually restores block size to the default 32 MB setting originally > implemented by Satoshi. > > 2.Initial increase to 2MB at block halving in July 2016 would have > minimal impact to existing nodes running on most hardware and networks. > > 3.Long term solution that does not make enthusiastic assumptions > regarding future bandwidth and storage availability estimates. > > 4.Maximum block size of 32MB allows peak usage of ~100 tx/sec by year > 2031. > > 5.Exercise network upgrade procedure during subsidy reward halving, a > milestone event with the goal of increasing awareness among miners and node > operators. > > Specification > > 1.Increase the maximum block size to 2MB when block 630,000 is reached > and 75% of the last 1,000 blocks have signaled support. > > 2.Increase maximum block size to 4MB at block 840,000. > > 3.Increase maximum block size to 8MB at block 1,050,000. > > 4.Increase maximum block size to 16MB at block 1,260,000. > > 5.Increase maximum block size to 32MB at block 1,470,000. > > Backward compatibility > > All older clients are not compatible with this change. The first block > larger than 1M will create a network partition excluding not-upgraded > network nodes and miners. > > Rationale > > While more comprehensive solutions are developed, an increase to the block > size is needed to continue network growth. A longer term solution is needed > to prevent complications associated with additional hard forks. It should > also increase at a gradual rate that retains and allows a large distribution > of full nodes. Scheduling this hard fork to occur no earlier than the > subsidy halving in 2016 has the goal of simplifying the communication > outreach needed to achieve consensus, while also providing a buffer of time > to make necessary preparations. > > > ___ > 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] Upcoming Transaction Priority Changes
I doubt changing the default value is useful as casual mining had long dead, and pools all have their own customized policies. But I think change the priority size to 0 is the right way to do. The sort by priority part in the block is always the best place for spam nowadays. I would think about to merge the priority, feerate, and probably sigoprate into one number, probably 576 priorities trade for 1 satoshi per kb? On Fri, Nov 13, 2015 at 4:12 AM, Luke Dashjr via bitcoin-dev wrote: > On Thursday, November 12, 2015 7:47:50 PM Matt Corallo via bitcoin-dev wrote: >> With the mempool limiting stuff already in git master, high-priority >> relay is disabled when mempools are full. In addition, there was >> agreement to take the following steps for 0.12: >> >> * Mining code will use starting priority for ease of implementation > > This should be optional, at least for 0.12. > >> * Default block priority size will be 0 > > We should not be influencing miner policy by changing defaults. > > Luke > ___ > 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] Fill-or-kill transaction
We are currently using nLockTime for share info and nSequence for extranonce2. I have carefully reviewed the reference implementation of BIP68 and it should be compatible, but this proposal may break the implementation unless it does not affect coinbase transactions. On Fri, Sep 18, 2015 at 2:41 AM, jl2012 via bitcoin-dev wrote: > Fill-or-kill tx is not a new idea and is discussed in the Scaling Bitcoin > workshop. In Satoshi's implementation of nLockTime, a huge range of > timestamp (from 1970 to 2009) is wasted. By exploiting this unused range and > with compromise in the time resolution, a fill-or-kill system could be built > with a softfork. > > --- > Two new parameters, nLockTime2 and nKillTime are defined: > > nLockTime2 (Range: 0-1,853,010) > 0: Tx could be confirmed at or after block 420,000 > 1: Tx could be confirmed at or after block 420,004 > . > . > 719,999: Tx could be confirmed at or after block 3,299,996 (about 55 years > from now) > 720,000: Tx could be confirmed if the median time-past >= 1,474,562,048 > (2016-09-22) > 720,001: Tx could be confirmed if the median time-past >= 1,474,564,096 > (2016-09-22) > . > . > 1,853,010 (max): Tx could be confirmed if the median time-past >= > 3,794,966,528 (2090-04-04) > > nKillTime (Range: 0-2047) > if nLockTime2 < 720,000, the tx could be confirmed at or before block > (nLockTime2 + nKillTime * 4) > if nLockTime2 >= 720,000, the tx could be confirmed if the median time-past > <= (nLockTime2 - 720,001 + nKillTime) * 2048 > > Finally, nLockTime = 500,000,000 + nKillTime + nLockTime2 * 2048 > > Setting a bit flag in tx nVersion will activate the new rules. > > The resolution is 4 blocks or 2048s (34m) > The maximum confirmation window is 8188 blocks (56.9 days) or 16,769,024s > (48.5 days) > > For example: > With nLockTime2 = 20 and nKillTime = 100, a tx could be confirmed only > between block 420,080 and 420,480 > With nLockTime2 = 730,000 and nKillTime = 1000, a tx could be confirmed only > between median time-past of 1,495,042,048 and 1,497,090,048 > > > Why is this a softfork? > > Remember this formula: nLockTime = 500,000,000 + nKillTime + nLockTime2 * > 2048 > > For height based nLockTime2 (<= 719,999) > > For nLockTime2 = 0 and nKillTime = 0, nLockTime = 500,000,000, which means > the tx could be confirmed after 1970-01-01 with the original lock time rule. > As the new rule does not allow confirmation until block 420,000, it's > clearly a softfork. > > It is not difficult to see that the growth of nLockTime will never catch up > nLockTime2. > > At nLockTime2 = 719,999 and nKillTime = 2047, nLockTime = 1,974,559,999, > which means 2016-09-22. However, the new rule will not allow confirmation > until block 3,299,996 which is decades to go > > > > For time based nLockTime2 (> 720,000) > > For nLockTime2 = 720,000 and nKillTime = 0, nLockTime = 1,974,560,000, which > means the tx could be confirmed after median time-past 1,474,560,000 > (assuming BIP113). However, the new rule will not allow confirmation until > 1,474,562,048, therefore a soft fork. > > For nLockTime2 = 720,000 and nKillTime = 2047, nLockTime = 1,974,562,047, > which could be confirmed at 1,474,562,047. Again, the new rule will not > allow confirmation until 1,474,562,048. The 1 second difference makes it a > soft fork. > > Actually, for every nLockTime2 value >= 720,000, the lock time with the new > rule must be 1-2048 seconds later than the original rule. > > For nLockTime2 = 1,853,010 and nKillTime = 2047, nLockTime = 4,294,966,527, > which is the highest possible value with the 32-bit nLockTime > > > User's perspective: > > A user wants his tx either filled or killed in about 3 hours. He will set a > time-based nLockTime2 according to the current median time-past, and set > nKillTime = 5 > > A user wants his tx get confirmed in the block 63, the first block with > reward below 10BTC. He is willing to pay high fee but don't want it gets > into another block. He will set nLockTime2 = 210,000 and nKillTime = 0 > > > OP_CLTV > > Time-based OP_CLTV could be upgraded to support time-based nLockTime2. > However, height-based OP_CLTV is not compatible with nLockTime2. To spend a > height-based OP_CLTV output, user must use the original nLockTime. > > We may need a new OP_CLTV2 which could verify both nLockTime and nLockTime2 > > > 55 years after? > > The height-based nLockTime2 will overflow in 55 years. It is very likely a > hard fork will happen to implement a better fill-or-kill system. If not, we > could reboot everything with another tx nVersion for another 55 years. > > > ___ > 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/l
Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
On Sun, Aug 30, 2015 at 4:10 AM, Jorge Timón wrote: /tx/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a?chain=0933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943 > > (a tx in testnet) > > /block/0b0d504d142ac8bdd1a2721d19f423a8146d0d6de882167b?chain=0019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f Some altcoins (LTC and FTC for example) have the same genesis block hash. On Sun, Aug 30, 2015 at 4:10 AM, Jorge Timón wrote: > On Sat, Aug 29, 2015 at 9:01 PM, Matt Whitlock via bitcoin-dev > wrote: >> That's still not right, since "mainnet" and "testnet" are not host names. >> >> You'd have to do something like: >> >> blockchain:?network=testnet&txid=3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a > > I would really prefer chain= over network= > By chainID I mean the hash of the genesis block, see > https://github.com/jtimon/bitcoin/commit/3191d5e8e75687a27cf466b7a4c70bdc04809d39 > I'm completely fine with doing that using an optional parameter (for > backwards compatibility). > > I agree with Andreas Schildbach that respecting the most commonly used > schemes is desirable. > So my preference would be: > > /tx/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a?chain=0933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943 > > (a tx in testnet) > > /block/0b0d504d142ac8bdd1a2721d19f423a8146d0d6de882167b?chain=0019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f > > (a block in bitcoin's mainnet) > ___ > 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] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]
On Wed, Aug 26, 2015 at 5:18 AM, Simon Liu via bitcoin-dev wrote: > I don't think this would work. > > If the rule is that one user can only have one vote, how do you prevent > a user running multiple nodes? The vote is not counted by nodes, but bitcoin amount, or probably better, coin-days. It works like proof-of-stake. A mix of proof-of-work and proof-of-stake is good. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]
Proposal 1 looks good, but tx fee collected can be manipulated by miners. I like the idea next block collect the tx fee from previous block. On Tue, Aug 25, 2015 at 5:07 PM, Upal Chakraborty via bitcoin-dev wrote: > Github: > https://github.com/UpalChakraborty/bips/blob/master/BIP-DynamicMaxBlockSize.mediawiki > > > BIP: 1xx > Title: Dynamically Controlled Bitcoin Block Size Max Cap > Author: Upal Chakraborty > Status: Draft > Type: Standards Track > Created: 2015-08-24 > > > ==Abstract== > > This BIP proposes replacing the fixed one megabyte maximum block size with a > dynamically controlled maximum block size that may increase or decrease with > difficulty change depending on various network factors. I have two proposals > regarding this... > > i. Depending only on previous block size calculation. > > ii. Depending on previous block size calculation and previous Tx fee > collected by miners. > > ==Motivation== > > With increased adoption, transaction volume on bitcoin network is bound to > grow. If the one megabyte max cap is not changed to a flexible one which > changes itself with changing network demand, then adoption will hamper and > bitcoin's growth may choke up. Following graph shows the change in average > block size since inception... > > https://blockchain.info/charts/avg-block-size?timespan=all&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address= > > ==Specification== > > ===Proposal 1 : Depending only on previous block size calculation=== > > If more than 50% of block's size, found in the first 2000 of the last > difficulty period, is more than 90% MaxBlockSize > Double MaxBlockSize > Else if more than 90% of block's size, found in the first 2000 of the last > difficulty period, is less than 50% MaxBlockSize > Half MaxBlockSize > Else > Keep the same MaxBlockSize > > ===Proposal 2 : Depending on previous block size calculation and previous Tx > fee collected by miners=== > > TotalBlockSizeInLastButOneDifficulty = Sum of all Block size of first 2008 > blocks in last 2 difficulty period > TotalBlockSizeInLastDifficulty = Sum of all Block size of second 2008 > blocks in last 2 difficulty period (This actually includes 8 blocks from > last but one difficulty) > > TotalTxFeeInLastButOneDifficulty = Sum of all Tx fees of first 2008 blocks > in last 2 difficulty period > TotalTxFeeInLastDifficulty = Sum of all Tx fees of second 2008 blocks in > last 2 difficulty period (This actually includes 8 blocks from last but one > difficulty) > > If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 > > 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty > > TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty > > TotalBlockSizeInLastButOneDifficulty) ) > MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize / > TotalBlockSizeInLastButOneDifficulty > Else If ( ( (Sum of first 4016 block size in last 2 difficulty > period)/4016 < 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty < > TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty < > TotalBlockSizeInLastButOneDifficulty) ) > MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize / > TotalBlockSizeInLastButOneDifficulty > Else > Keep the same MaxBlockSize > > ==Rationale== > > These two proposals have been derived after discussion on > [https://bitcointalk.org/index.php?topic=1154536.0 BitcoinTalk] and > [http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010285.html > bitcoin-dev mailing list]. The original idea and its evolution in the light > of various arguements can be found [http://upalc.com/maxblocksize.php here]. > > ===Proposal 1 : Depending only on previous block size calculation=== > > This solution is derived directly from the indication of the problem. If > transaction volume increases, then we will naturally see bigger blocks. On > the contrary, if there are not enough transaction volume, but maximum block > size is high, then only few blocks may sweep the mempool. Hence, if block > size is itself taken into consideration, then maximum block size can most > rationally be derived. Moreover, this solution not only increases, but also > decreases the maximum block size, just like difficulty. > > ===Proposal 2 : Depending on previous block size calculation and previous Tx > fee collected by miners=== > > This solution takes care of stable mining subsidy. It will not increase > maximum block size, if Tx fee collection is not increasing and thereby > creating a Tx fee pressure on the market. On the other hand, though the > block size max cap is dynamically controlled, it is very difficult to game > by any party because the increase or decrease of block size max cap will > take place in the same ratio of average block size increase or decrease. > > ==Compatibility== > > This is a hard-forking change to the Bitcoin protocol; anybody running code > that fully validates blocks must
