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 m...@plan99.net wrote:
Whilst it would be nice if miners
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
On Mon, Jun 1, 2015 at 6:13 PM, Mike Hearn m...@plan99.net 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
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 p...@petertodd.org 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 m...@plan99.net wrote:
WOW Way to burn your biggest adopters who put your transactions into the
chain...what a douche.
From: Mike Hearnmailto:m...@plan99.net
Sent: 1/06/2015 8:15 PM
To: Alex Mizrahimailto:alex.mizr...@gmail.com
Cc: Bitcoin
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
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
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
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 businesses
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
On Sun, May 31, 2015 at 6:55 PM, Alex Mizrahi alex.mizr...@gmail.com
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
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
too
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:
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 be
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.
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 supports
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
(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
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
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).
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. wtog...@gmail.com wrote:
By reversing Mike's language to
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
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
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
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 gapplet...@gmail.com wrote:
Also, can we try to get a
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
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 necessary
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
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 eth...@gmail.com 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
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 m...@henricson.se wrote:
Hi!
My fingers have been itching many times now, this debate
30 matches
Mail list logo
