Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

> He also said that the equation for miners has many variables, as it > should. He only said that AFTER I called him on his bullshit. Before that he wrote it like there is 100% certainty that only the party producing big blocks is punished: "That orphan rate increase will go to whoever is produc

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

Whilst it would be nice if miners in China can carry on forever regardless of their internet situation, nobody has any inherent "right" to mine if they can't do the job - if miners in China can't get the trivial amounts of bandwidth required through their firewall and end up being outcompeted then

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

On Mon, Jun 1, 2015 at 6:13 PM, Mike Hearn wrote: > Whilst it would be nice if miners in China can carry on forever regardless > of their internet situation, nobody has any inherent "right" to mine if > they can't do the job - if miners in China can't get the trivial amounts of > bandwidth requir

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

On Mon, Jun 1, 2015 at 6:13 PM, Mike Hearn wrote: > Whilst it would be nice if miners in China can carry on forever regardless > of their internet situation, nobody has any inherent "right" to mine if they > can't do the job - if miners in China can't get the trivial amounts of > bandwidth require

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

I think it would be helpful if we could all *chill* and focus on the solid engineering necessary to make Bitcoin succeed. p. On Mon, Jun 1, 2015 at 7:02 PM, Chun Wang <1240...@gmail.com> wrote: > On Mon, Jun 1, 2015 at 6:13 PM, Mike Hearn wrote: > > Whilst it would be nice if miners in China c

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

WOW Way to burn your biggest adopters who put your transactions into the chain...what a douche. From: Mike Hearn Sent: ‎1/‎06/‎2015 8:15 PM To: Alex Mizrahi Cc: Bitcoin Dev

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

I cannot believe why Gavin (who seems to have difficulty to spell my name correctly.) insists on his 20MB proposal regardless the community. BIP66 has been introduced for a long time and no one knows when the 95% goal can be met. This change to the block max size must take one year or more to be ad

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

On Mon, Jun 01, 2015 at 06:42:05PM +0800, Pindar Wong wrote: > On Mon, Jun 1, 2015 at 6:13 PM, Mike Hearn wrote: > > > Whilst it would be nice if miners in China can carry on forever regardless > > of their internet situation, nobody has any inherent "right" to mine if > > they can't do the job -

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

I've been following the discussion of the block size limit and IMO it is clear that any constant block size limit is, as many have said before, just kicking the can down the road. My problem with the dynamic lower limit solution based on past blocks is that it doesn't account for usage spikes. I wo

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

Two very valid and important points. Thank you for making these observations Peter. p. On Mon, Jun 1, 2015 at 7:26 PM, Peter Todd wrote: > On Mon, Jun 01, 2015 at 06:42:05PM +0800, Pindar Wong wrote: > > On Mon, Jun 1, 2015 at 6:13 PM, Mike Hearn wrote: > > > > > Whilst it would be nice if mi

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

Whilst it would be nice if miners in *outside* China can carry on forever regardless of their internet situation, nobody has any inherent "right" to mine if they can't do the job - if miners in *outside* China can't get the trivial amounts of bandwidth required through their firewall *TO THE MAJORI

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

> Let the block size limit be a function of the number of current transactions in the mempool. There is no single mempool which transactions could be counted and there is no consensus about the average number of unconfirmed transactions. 2015-06-01 13:30 GMT+02:00 Ricardo Filipe : > I've been fo

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

>What do other people think? > > >If we can't come to an agreement soon, then I'll ask for help >reviewing/submitting patches to Mike's Bitcoin-Xt project that implement a >big increase now that grows over time so we may never have to go through >all this rancor and debate again." > > >I'll then as

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

Agree with everything you said. Spot on observations on all counts. Thank you for speaking up. Adam On 1 June 2015 at 13:45, Jérôme Legoupil wrote: >>What do other people think? >> >> >>If we can't come to an agreement soon, then I'll ask for help >>reviewing/submitting patches to Mike's Bitcoi

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

Doesn't mean you should build something that says "fuck you" to the companies that have invested in farms of ASICS. To say "Oh yea if they can't mine it how we want stuff 'em" is naive. I get decentralisation, but don't dis incentivise mining. If miners are telling you that you're going to hurt

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

On Sun, May 31, 2015 at 6:55 PM, Alex Mizrahi wrote: > Yes, if you are on a slow network then you are at a (slight) disadvantage. >> So? >> > > Chun mentioned that his pool is on a slow network, and thus bigger blocks > give it an disadvantage. (Orphan rate is proportional to block size.) > You s

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

> > Ignorant. You seem do not understand the current situation. We > suffered from orphans a lot when we started in 2013. It is now your > turn. Then please enlighten me. You're unable to download block templates from a trusted node outside of the country because the bandwidth requirements are to

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

RE: going to the public: I started pushing privately for SOMETHING, ANYTHING to be done, or at the very least for there to be some coherent plan besides "wait and see" back in February. As for it being unhealthy for me to write the code that I think should be written and asking people to run it:

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

On Mon, Jun 1, 2015 at 7:20 AM, Chun Wang <1240...@gmail.com> wrote: > I cannot believe why Gavin (who seems to have difficulty to spell my > name correctly.) insists on his 20MB proposal regardless the > community. BIP66 has been introduced for a long time and no one knows > when the 95% goal can

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

That is good. I oppose 20MB because I estimate it may increase the overall orphan rate to an unacceptable level. 5MB, 8MB or probably 10MB should be ok. On Mon, Jun 1, 2015 at 9:59 PM, Gavin Andresen wrote: > On Mon, Jun 1, 2015 at 7:20 AM, Chun Wang <1240...@gmail.com> wrote: >> >> I cannot beli

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

On Mon, Jun 1, 2015 at 3:59 PM, Gavin Andresen wrote: > What do other people think? Would starting at a max of 8 or 4 get > consensus? Scaling up a little less than Nielsen's Law of Internet > Bandwidth predicts for the next 20 years? (I think predictability is > REALLY important). > > I chose

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

The current max block size of 100 bytes is not power of two anyway. On Mon, Jun 1, 2015 at 10:46 PM, Oliver Egginger wrote: > On Mon, Jun 1, 2015 at 3:59 PM, Gavin Andresen wrote: >> What do other people think? Would starting at a max of 8 or 4 get >> consensus? Scaling up a little less tha

Re: [Bitcoin-development] Version bits proposal

oh my God ... 发自我的 iPhone > 在 2015年5月27日，19:26，Tier Nolan 写道： > > > >> On Wed, May 27, 2015 at 11:15 AM, Peter Todd wrote: >> The median time mechanism is basically a way for hashing power to show >> what time they think it is. Equally, the nVersion soft-fork mechanism is >> a way for hashin

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

I'm OK with a smaller size + a formula that ramps it up over time. We are far from having enough demand to fill 10MB blocks, let alone 20MB today. To put it in perspective, to be feeling squeezed inside 10MB within two years, we would need to double usage five times. I wish I knew a way to make th

[Bitcoin-development] soft-fork block size increase (extension blocks)

Hi Gavin Sorry for slow response & broken threading - mailbox filled up & only saw your response on archive. I do earnestly think opt-in block-size increases are politically cleaner (gives different people different sized blocks by their own volition without forcing a compromise) and less risky t

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

> > It's surprising to see a core dev going to the public to defend a proposal > most other core devs disagree on, and then lobbying the Bitcoin ecosystem. > I agree that it is a waste of time. Many agree. The Bitcoin ecosystem doesn't really need lobbying - my experience from talking to businesse

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

Hi everyone, I'm a long-time lurker of this mailing list but it's the first time I post here, so first of all I'd like to thank all of the usual contributors for the great insights and technical discussions that can be found here. As this is such a momentous point in the history of Bitcoin, I'd ju

Re: [Bitcoin-development] soft-fork block size increase (extension blocks)

Hi Adam, I have more experience than Gavin of building consumer wallets, so I'll make an attempt to answer your questions. > Then ask the various wallet developer how long it would take them to > update > > their software to support something like this, > > I don't think thats any particular conc

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

The overlapping consensus mechanisms between the Core Developers, the miners, the block chain based businesses, and the end users make it such that the very definition of Bitcoin is not just what any single one of those groups comes to a consensus about. We must ALL be in consensus about just what

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

Nielsen's Law of Internet Bandwidth is simply not true, but if you look at data points like http://www.netindex.com/upload/ which will show we are at least on the right track, but this is flawed still. The fact of the matter is these speed tests are done from local origin to local destination wit

Re: [Bitcoin-development] soft-fork block size increase (extension blocks)

Mike wrote: >> Businesses who are keen to >> have more transactions, would make it their problem to implement in >> their wallet, or ask the wallet vendor/maintainer they're working with >> to do it. Nothing breaks if they dont use it. > > > I don't see how this is the case. If an exchange support

Re: [Bitcoin-development] soft-fork block size increase (extension blocks)

> > (at reduced security if it has software that doesnt understand it) Well, yes. Isn't that rather key to the issue? Whereas by simply increasing the block size, SPV wallets don't care (same security and protocol as before) and fully validating wallets can be updated with a very small code chan

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

By reversing Mike's language to the reality of the situation I had hoped people would realize how abjectly ignorant and insensitive his statement was. I am sorry to those in the community if they misunderstood my post. I thought it was obvious that it was sarcasm where I do not seriously believe p

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

I don't see this as an issue of sensitivity or not. Miners are businesses that sell a service to Bitcoin users - the service of ordering transactions chronologically. They aren't charities. If some miners can't provide the service Bitcoin users need any more, then OK, they should not/cannot mine.

[Bitcoin-development] Why do we need a MAX_BLOCK_SIZE at all?

Ok, I understand at least some of the reason that blocks have to be kept to a certain size. I get that blocks which are too big will be hard to propagate by relays. Miners will have more trouble uploading the large blocks to the network once they've found a hash. We need block size constraints to c

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

So lets rephrase that and say instead more correctly it is the job of miners (collectively) to be well connected globally - and indeed there are incentivised to be or they tend to receive blocks at higher latency and so are at increased risk of orphans. And miner groups with good block latency in-

Re: [Bitcoin-development] Why do we need a MAX_BLOCK_SIZE at all?

This exact question came up on the Bitcoin Stack Exchange once. I gave an answer here: http://bitcoin.stackexchange.com/questions/37292/whats-the-purpose-of-a-maximum-block-size/37303#37303 On Mon, Jun 1, 2015 at 2:32 PM, Jim Phillips wrote: > Ok, I understand at least some of the reason that bl

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

I did wonder what the post actually meant, I recommend appending /s after sarcasm so it's clear. Lots gets lost in text. But I agree with you btw his response was not particularly tactful. On Mon, Jun 1, 2015 at 7:19 PM, Warren Togami Jr. wrote: > By reversing Mike's language to the reality of t

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

> What do other people think? Would starting at a max of 8 or 4 get > consensus? Scaling up a little less than Nielsen's Law of Internet > Bandwidth predicts for the next 20 years? (I think predictability is > REALLY important). TL;DR: Personally I'm in favour of doing something relatively unco

Re: [Bitcoin-development] Why do we need a MAX_BLOCK_SIZE at all?

> > 1. To Maintaining Consensus > There has to be clearly defined rules about which blocks are valid and > which are not for the network to agree. Obviously no node will accept a > block that is 10 million terabytes, it would be near impossible to download > even if it were valid. So where do you

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

On Mon, Jun 01, 2015 at 09:01:49PM +0100, Roy Badami wrote: > > What do other people think? Would starting at a max of 8 or 4 get > > consensus? Scaling up a little less than Nielsen's Law of Internet > > Bandwidth predicts for the next 20 years? (I think predictability is > > REALLY important).

[Bitcoin-development] We are filling most blocks right now - Let's change the max blocksize default

We seem to be experiencing bursts of high transaction rate right now. https://blockchain.info/ shows nearly all blocks full. We should increase the default max block size to 1MB to give us more space where we see the 731MB blocks, as we don’t want to be limited by those who don’t bother to cha

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

Ah sorry, I just thought you were saying doesn't matter which side let 'em burn. If I were the Chinese and people moved to 20mb MAX size blocks and said stuff you, I'd just start firing out small coinbase only blocks now, if they truly have >50% hashing power and they collaborate chances are the

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

It would be helpful to hear from the other miners, and perhaps arrange some testing and telemetry in China with 8 ... that's even a Chinese lucky number ;) p. On Tue, Jun 2, 2015 at 5:32 AM, Thy Shizzle wrote: > Ah sorry, I just thought you were saying doesn't matter which side let > 'em bur

[Bitcoin-development] Meta suggestions for this block size debate

Hi! My fingers have been itching many times now, this debate drives me nuts. I just wish all posters could follow two simple principles: 1. Read up. Yes. All of what has been written. Yes, it will take many hours. But if you're rehashing what other smarter people have said over and over be

Re: [Bitcoin-development] soft-fork block size increase (extension blocks)

On 6/1/2015 10:21 AM, Adam Back wrote: > if it stays as is for a year, in a wait and see, reduce spam, see > fee-pressure take effect as it has before, work on improving improve > decentralisation metrics, relay latency, and do a blocksize increment > to kick the can if-and-when it becomes necessar

[Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

I have written a reference implementation and BIP draft for a soft-fork change to the consensus-enforced behaviour of sequence numbers for the purpose of supporting transaction replacement via per-input relative lock-times. This proposal was previously discussed on the mailing list in the following

Re: [Bitcoin-development] Meta suggestions for this block size debate

Also, can we try to get a wiki page for the debate? That way we could condense the information as much as possible. I'll be willing to assist if the page gets approval. On Jun 1, 2015 6:41 PM, "Mats Henricson" wrote: > Hi! > > My fingers have been itching many times now, this debate > drives me n

Re: [Bitcoin-development] Meta suggestions for this block size debate

I second this, I don't have time to read the large number of emails generated every day from the block size debate. A summary of the various positions and arguments would be extremely helpful. On Mon, Jun 1, 2015 at 11:02 PM, gabe appleton wrote: > Also, can we try to get a wiki page for the deb

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

Hi Mark, Overall, I like this idea in every way except for one: unless I am missing something, we may still need an OP_RCLTV even with this being implemented. In use cases such as micropayment channels where the funds are locked up by multiple parties, the enforcement of the relative locktime can

Re: [Bitcoin-development] Meta suggestions for this block size debate

I don't have permission to create a page. If someone else does, I'll happily get a framework started. On Mon, Jun 1, 2015 at 11:32 PM, Ethan Heilman wrote: > I second this, I don't have time to read the large number of emails > generated every day from the block size debate. A summary of the var

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

You are correct! I am maintaining a 'checksequenceverify' branch in my git repository as well, an OP_RCLTV using sequence numbers: https://github.com/maaku/bitcoin/tree/checksequenceverify Most of the interesting use cases for relative lock-time require an RCLTV opcode. What is interesting about

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

I see, so OP_SEQUENCEVERIFY will have a value pushed on the stack right before, and then check that the input spending the prevout has nSequence corresponds to at least the sequence specified by the stack value. Good idea! Keeps the script code from depending on external chain specific data, which