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 A
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
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,
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
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-DynamicMaxBlock
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 w
On Sun, Aug 30, 2015 at 4:10 AM, Jorge Timón
wrote:
/tx/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a?chain=0933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943
>
> (a tx in testnet)
>
> /block/0b0d504d142ac8bdd1a2721d19f423a8146d0d6de882167b?chain=00
