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
block
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 after the "planned cl
-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 block
FWIW all these median time based s
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). Height seems KISS.
>
> A
My preference is height activation + one step per block (i.e. also
height). Height seems KISS.
AFAICT most of the attacks would occur around the already-heavily-watched
flag day activation event, in a height based environment, a useful
attribute.
However I would like to hear from others about po
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 late
>From a code standpoint, based off height is easy.
My first internal version triggered on block 406,800 (~May 5), and each
block increased by 20 bytes thereafter.
It was changed to time, because time was the standard used in years past
for other changes; MTP flag day is more stable than block hei
I agree that nHeight is the simplest option and is my preference.
Another option is to use the median time from the previous block (thus you
know whether or not the next block should start the miner confirmation or
not). In fact, if we're going to use bip9 for 95% miner upgrade
confirmation, it wo
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
On Dec 18, 2015 2:13 AM, "sick...@gmail.com" wrote:
> 1.75 x 0.5 + 1 x 0.5 = 1.375
>
> after six month.
>
> An hard-fork on the others side would bring 1.75 since the activation, am
I right?
Yes.
However, SW immediately gives a 1.75 capacity increase for anyone who
adopts it, after the softfork,
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 making
> >> changes to it in order to satisf
On Fri, Dec 18, 2015 at 03:02:36AM +, Eric Lombrozo via bitcoin-dev wrote:
> First of all, that's an expensive beer!
>
> Second of all, any consensus rule change risks non-full-validating
> or non-upgraded nodes seeing invalid confirmations...but assuming a
> large supermajority (i.e. > 95%) o
On Fri, Dec 18, 2015 at 8:56 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > - only assuming robust adoption rates by up-layer ecosystem software, and
>
> That's not required. Everyone who individually switches to new
> transactions gets to do 1.75x more tra
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 x
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 system have significant p
15 matches
Mail list logo
