Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

On Thu, Dec 17, 2015 at 7:44 PM, Peter Todd wrote: > If Bitcoin remains decentralized, miners have veto power over any > blocksize increases. You can always soft-fork in a blocksize reduction > in a decentralized blockchain that actually works. > The actual users of the

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

Anthony, On Thu, Dec 17, 2015 at 6:55 PM, Anthony Towns via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Thu, Dec 17, 2015 at 04:51:19PM +0100, sickpig--- via bitcoin-dev wrote: > > On Thu, Dec 17, 2015 at 2:09 PM, Jorge Timón wrote: > > > Unless I'm missing something, 2 mb

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

Well, if it's not going to be height, I think median time of the previous block is better than the time of the current one, and would also solve Chun Wang's concerns. But as said I prefer to use heights that correspond to diff recalculation (because that's the window that bip9 will use for the

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

I believe the attacks are the same for height or median time of the prev block are equal, only the time of the current block has more edge cases. On Dec 18, 2015 9:15 PM, "Jeff Garzik" wrote: > My preference is height activation + one step per block (i.e. also > height).

[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

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 18 December 2015 11:52:19 GMT-08:00, "Jorge Timón via bitcoin-dev" wrote: >I agree that nHeight is the simplest option and is my preference. >Another option is to use the median time from the previous

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

On Fri, Dec 18, 2015 at 2:56 AM, Pieter Wuille wrote: > On Fri, Dec 18, 2015 at 6:11 AM, Jeff Garzik wrote: > >> You present this as if the Bitcoin Core development team is in charge > >> of deciding the network consensus rules, and is responsible for

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

On Dec 18, 2015 9:43 PM, "Peter Todd" wrote: > FWIW all these median time based schemes should be using median time past: the point is to use a time that the block creator has no direct control of, while still tying the rule to wall clock time for planning purposes. Well, if

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

Not entirely correct, no. Edge cases also matter. Segwit is described as 4MB because that is the largest possible combined block size that can be constructed. BIP 102 + segwit would allow a maximum relay of 8MB. So you have to be confident that an 8MB relay size would be acceptable, even if a