[bitcoin-dev] The increase of max block size should be determined by block height instead of block time

[Chun Wang via bitcoin-dev]

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] Upcoming Transaction Priority Changes

[Chun Wang via bitcoin-dev]

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] BIP - Block size doubles at each reward halving with max block size of 32M

[Chun Wang via bitcoin-dev]

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] Fill-or-kill transaction

[Chun Wang via bitcoin-dev]

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

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]

[Chun Wang via bitcoin-dev]

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
bitcoin-dev@lists.linuxfoundation.org wrote:
 Github:
 https://github.com/UpalChakraborty/bips/blob/master/BIP-DynamicMaxBlockSize.mediawiki

 pre
   BIP: 1xx
   Title: Dynamically Controlled Bitcoin Block Size Max Cap
   Author: Upal Chakraborty bitc...@upalc.com
   Status: Draft
   Type: Standards Track
   Created: 2015-08-24
 /pre

 ==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=allshowDataPoints=falsedaysAverageString=1show_header=truescale=0address=

 ==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 upgrade before the activation time or they
 will risk 

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]

[Chun Wang via bitcoin-dev]

On Wed, Aug 26, 2015 at 5:18 AM, Simon Liu via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org 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