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

2015-05-28 Thread Gavin Andresen
On Thu, May 28, 2015 at 1:34 PM, Mike Hearn m...@plan99.net 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

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

2015-05-28 Thread Pieter Wuille
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

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

2015-05-28 Thread Peter Todd
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 should be

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

2015-05-28 Thread Pieter Wuille
On May 28, 2015 10:42 AM, Raystonn . rayst...@hotmail.com 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

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

2015-05-28 Thread Mike Hearn
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, which

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

2015-05-28 Thread Gavin Andresen
On Thu, May 28, 2015 at 1:59 PM, Pieter Wuille pieter.wui...@gmail.com 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.

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

2015-05-28 Thread Gavin Andresen
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 stepfunction

2015-05-28 Thread Raystonn .
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.

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

2015-05-28 Thread Steven Pine
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

Re: [Bitcoin-development] Version bits proposal

2015-05-28 Thread Christian Decker
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

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

2015-05-28 Thread Mike Hearn
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

2015-05-28 Thread Tier Nolan
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

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

2015-05-28 Thread Peter Todd
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] Consensus-enforced transaction replacement via sequence numbers

2015-05-28 Thread Tier Nolan
On Thu, May 28, 2015 at 3:59 PM, Mark Friedenbach m...@friedenbach.org 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