Re: [bitcoin-dev] Hard fork proposal from last week's meeting

> On 29 Mar 2017, at 04:50, Tom Zander > wrote: > > On Tuesday, 28 March 2017 19:34:23 CEST Johnson Lau via bitcoin-dev wrote: >> So if we really want to get prepared for a potential HF with unknown >> parameters, > > That was not suggested. >

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

Hi Juan > I tend to believe more in Moore’s law, Butters' Law of Photonics and Kryder’s Law all has been verified for many years and support that 32 MB in 2020 are possible and equals or less than 1 MB in 2010. Protocol development, especially one in control of people's money cannot be

Re: [bitcoin-dev] Encouraging good miners

If a miner try to hurt the network mining just empty blocks at some time the rest will start rejecting their blocks and will be orphans so will loss the reward incentive and that miner will join the behavior of the rest of the miners, if that miner has 51% of hashrate there the smallest problem

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

Alphonse, Even when several of the experts involved in the document you refer has my respect and admiration, I do not agree with some of their conclusions some of their estimations are not accurate other changed like Bootstrap Time, Cost per Confirmed Transaction they consider a network of

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

On Tuesday, March 28, 2017 8:53:30 PM Alphonse Pace via bitcoin-dev wrote: > His demand (not suggestion) allows it without any safeguards. > > >This patch must be in the immediate next release of Bitcoin Core. > > That is not a suggestion. I think it was probably a design requirement more than

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

Alphonse, In my opinion if 1MB limit was ok in 2010, 8MB limit is ok on 2016 and 32MB limit valid in next halving, from network, storage and CPU perspective or 1MB was too high in 2010 what is possible or 1MB is to low today. If is unsafe or impossible to raise the blocksize is a different

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

On Tuesday, 28 March 2017 19:34:23 CEST Johnson Lau via bitcoin-dev wrote: > So if we really want to get prepared for a potential HF with unknown > parameters, That was not suggested. Maybe you can comment on the very specific suggestion instead? -- Tom Zander Blog: https://zander.github.io

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

On Tuesday, 28 March 2017 18:59:32 CEST Wang Chun via bitcoin-dev wrote: > Despite spam tx on the network, the block capacity is approaching its > limit, and we must think ahead. Shall we code a patch right now, to > remove the block size limit of 1MB, but not activate it until far in > the

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

On Tue, Mar 28, 2017 at 12:56 PM, Paul Iverson via bitcoin-dev wrote: > So I think Core can't decide on hard forks like this. It must be left up to > the users. I think only choice is for Core to add a run-time option to allow > node operators to increase

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

Thank you for the proposal Wang Chung! It is clear that, spam aside, blocks are getting full and we need increase them soon. What I don't like about your proposal is it forces all node operators to implicitly accept larger blocks in 2020, even maybe against their will. 32 MB blocks might result

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

On 2017/3/28 10:31, Wang Chun via bitcoin-dev wrote: > The basic idea is, let's stop the debate for whether we should upgrade > to 2MB, 8MB or 32MiB. 32MiB is well above any proposals' upper limit, > so any final decision would be a soft fork to this already deployed > release. If by 2020, we

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

On Tuesday, March 28, 2017 5:34:23 PM Johnson Lau via bitcoin-dev wrote: > You are probably not the first one nor last one with such idea. Actually, > Luke wrote up a BIP with similar idea in mind: > > https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.mediawiki >

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

You are probably not the first one nor last one with such idea. Actually, Luke wrote up a BIP with similar idea in mind: https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.mediawiki Instead of just lifting the block

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

I think it's probably safer to have a fork-to-minumum (e.g. minimal coinbase+header) after a certain date than to fork up at a certain date. At least in that case, the default isn't breaking consensus, but you still get the same pressure to fork to a permanent solution. I don't endorse the above

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

The basic idea is, let's stop the debate for whether we should upgrade to 2MB, 8MB or 32MiB. 32MiB is well above any proposals' upper limit, so any final decision would be a soft fork to this already deployed release. If by 2020, we still agree 1MB is enough, it can be changed back to 1MB limit

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

What meeting are you referring to? Who were the participants? Removing the limit but relying on the p2p protocol is not really a true 32MiB limit, but a limit of whatever transport methods provide. This can lead to differing consensus if alternative layers for relaying are used. What you seem

Re: [bitcoin-dev] Inquiry: Transaction Tiering

> [...] we don't need to implement any kind of special bloated transaction that > is only mine-able by some explicit set of miners... No fork or compatibility > problems are necessary, can be completely implemented as an added feature. Yes, absolutely. It would still be helpful if it is

Re: [bitcoin-dev] Encouraging good miners

On 27/03/17 18:12, Btc Ideas via bitcoin-dev wrote: > Add a preference for mined blocks to be the one with more > transactions. This comes into play when 2 blocks of the same height > are found. The first good block mined would be orphaned if it had > less transactions than another. Optionally,