Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

Can we hold off on bike-shedding the particular choice of parameters until people have a chance to weigh in on whether or not there is SOME set of dynamic parameters they would support right now? -- -- Gavin Andresen --

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

My understanding, which is very likely wrong in one way or another, is transaction size and block size are two slightly different things but perhaps it's so negligible that block size is a fine stand-in for total transaction throughput. Potentially Doubling the block size everyday is frankly impru

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

On Thu, May 28, 2015 at 1:34 PM, Mike Hearn wrote: > As noted, many miners just accept the defaults. With your proposed change >> their target would effectively *drop* from 1mb to 800kb today, which >> seems crazy. That's the exact opposite of what is needed right now. >> > > I am very skeptical

Re: [Bitcoin-development] Proposed alternatives to the 20MB stepfunction

On Thu, May 28, 2015 at 1:59 PM, Pieter Wuille wrote: > I personally think the block size should increase, by the way, but only if > we can do it under a policy of doing it after technological growth has been > shown to be sufficient to support it without increased risk. > > Can you be more speci

Re: [Bitcoin-development] Proposed alternatives to the 20MB stepfunction

On May 28, 2015 10:42 AM, "Raystonn ." wrote: > > I agree that developers should avoid imposing economic policy. It is dangerous for Bitcoin and the core developers themselves to become such a central point of attack for those wishing to disrupt Bitcoin. I could not agree more that developers sh

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

On Thu, May 28, 2015 at 01:19:44PM -0400, Gavin Andresen wrote: > As for whether there "should" be fee pressure now or not: I have no > opinion, besides "we should make block propagation faster so there is no > technical reason for miners to produce tiny blocks." I don't think us > developers shoul

Re: [Bitcoin-development] Proposed alternatives to the 20MB stepfunction

I agree that developers should avoid imposing economic policy. It is dangerous for Bitcoin and the core developers themselves to become such a central point of attack for those wishing to disrupt Bitcoin. My opinion is these things are better left to a decentralized free market anyhow. From:

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

> > Twenty is scary. > To whom? The only justification for the max size is DoS attacks, right? Back when Bitcoin had an average block size of 10kb, the max block size was 100x the average. Things worked fine, nobody was scared. The max block size is really a limit set by hardware capability, whic

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

> until we have size-independent new block propagation I don't really believe that is possible. I'll argue why below. To be clear, this is not an argument against increasing the block size, only against using the assumption of size-independent propagation. There are several significant improvemen

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

On Thu, May 28, 2015 at 5:22 PM, s7r wrote: > In this scenario, if channel is closed, Alice is the only one who can > take the coins back after a relative locktime of 150 blocks. Bob is not > able to do this. > Yes, Alice is assumed to be the one who funded the channel. It is a single direction

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

On Thu, May 28, 2015 at 1:05 PM, Mike Hearn wrote: > Isn't that a step backwards, then? I see no reason for fee pressure to >> exist at the moment. All it's doing is turning away users for no purpose: >> mining isn't supported by fees, and the tiny fees we use right now seem to >> be good enough

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

Le 28/05/2015 17:53, Gavin Andresen a écrit : > > So my straw-man proposal would be: max size 2x average size over last 144 > blocks, calculated at every block. > I like that idea. Average is a better choice than median. The median is not well defined on discrete sets, as shown in your example

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

> > Even a 2x rule (implying 800K max blocks) would, today, be squeezing out > transactions / putting pressure to increase fees . > > So my straw-man proposal would be: max size 2x average size over last 144 > blocks, calculated at every block. > Isn't that a step backwards, then? I see no re

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

I would support a dynamic block size increase as outlined. I have a few questions though. Is scaling by average block size the best and easiest method, why not scale by transactions confirmed instead? Anyone can write and relay a transaction, and those are what we want to scale for, why not measur

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

On 5/28/2015 4:35 PM, Tier Nolan wrote: > On Thu, May 28, 2015 at 1:04 PM, Peter Todd > wrote: > > For that matter, we probably don't want to treat this as a *version* > change, but rather a *feature* flag. > > > I think it is still a version change. At th

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

What are the use cases for relative lock time verify? I have 1 and I think that is the kind of thing it is useful for. I think that most cases are just to guarantee that the other party has a chance to react. This means that 8191 blocks should be more than enough (and most would set it lower).

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

On Fri, May 8, 2015 at 3:20 AM, Matt Whitlock wrote: > Between all the flames on this list, several ideas were raised that did > not get much attention. I hereby resubmit these ideas for consideration and > discussion. > > - Perhaps the hard block size limit should be a function of the actual > b

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

Oh ok you mean a semantic difference for the purpose of explaining. It doesn't actually change the code. Regarding saving more bits, there really isn't much room if you consider time-based relative locktimes and long-lived channels on the order of a year or more. On Thu, May 28, 2015 at 8:18 AM,

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

On Thu, May 28, 2015 at 3:59 PM, Mark Friedenbach wrote: > Why 3? Do we have a version 2? > I meant whatever the next version is, so you are right, it's version 2. > As for doing it in serialization, that would alter the txid making it a > hard fork change. > The change is backwards compatible (

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

Why 3? Do we have a version 2? As for doing it in serialization, that would alter the txid making it a hard fork change. On May 28, 2015 03:30, "Tier Nolan" wrote: > Can you update it so that it only applies to transactions with version > number 3 and higher. Changing the meaning of a field is

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

On Thu, May 28, 2015 at 1:04 PM, Peter Todd wrote: > For that matter, we probably don't want to treat this as a *version* > change, but rather a *feature* flag. I think it is still a version change. At the moment, the 4 bytes refer to the sequence number and afterwards they mean something else

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

On Thu, May 28, 2015 at 11:30:18AM +0100, Tier Nolan wrote: > Can you update it so that it only applies to transactions with version > number 3 and higher. Changing the meaning of a field is exactly what the > version numbers are for. > > You could even decode version 3 transactions like that. >

Re: [Bitcoin-development] Long-term mining incentives

> > The prior (and seemingly this) assurance contract proposals pay the > miners who mines a chain supportive of your interests and miners whom > mine against your interests identically. > The same is true today - via inflation I pay for blocks regardless of whether they contain or double spend my

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

Can you update it so that it only applies to transactions with version number 3 and higher. Changing the meaning of a field is exactly what the version numbers are for. You could even decode version 3 transactions like that. Version 3 transactions have a sequence number of 0x and the seq

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

Cool, thanks. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

I have no problem with modifying the proposal to have the most significant bit signal use of the nSequence field as a relative lock-time. That leaves a full 31 bits for experimentation when relative lock-time is not in use. I have adjusted the code appropriately: https://github.com/maaku/bitcoin/t

Re: [Bitcoin-development] Version bits proposal

Or as far as that goes, permuting (the non-dependent) transactions in the block by permuting the internal merkle tree nodes at increasing depths. (Dependent because transactions that depend on each other have to come in-order; but one could eg put the n-1 of each n sequence of in-order transaction

Re: [Bitcoin-development] Version bits proposal

Agreed, there is no need to misuse the version field as well. There is more than enough variability you could roll in the merkle tree including and excluding transactions, and the scriptSig of the coinbase transaction, which also influences the merkle root. I have a fundamental dislike of retroact