On Sun, May 31, 2015 at 10:59 AM, Jorge Timón jti...@jtimon.cc wrote:
Whatever...let's use the current subsidies, the same argument applies,
it's just 20 + 25 = 45 btc per block for miner B vs 27 btc for miner B.
Miner B would still go out of business, bigger blocks still mean more
mining and
On May 31, 2015 5:08 PM, Gavin Andresen gavinandre...@gmail.com wrote:
On Sun, May 31, 2015 at 10:59 AM, Jorge Timón jti...@jtimon.cc wrote:
Whatever...let's use the current subsidies, the same argument applies,
it's just 20 + 25 = 45 btc per block for miner B vs 27 btc for miner B.
Miner B
On Sun, May 31, 2015 at 3:05 AM, Peter Todd p...@petertodd.org wrote:
Yeah, I'm pretty surprised myself that Gavin never accepted the
compromises offered by others in this space for a slow growth solution
What compromise? I haven't seen a specific proposal that could be turned
into a pull
On Sun, May 31, 2015 at 10:46 AM, Jorge Timón jti...@jtimon.cc wrote:
Here's a thought experiment:
Subsidy is gone, all the block reward comes from fees.
I wrote about long-term hypotheticals and why I think it is a big mistake
to waste time worrying about them here:
Whatever...let's use the current subsidies, the same argument applies, it's
just 20 + 25 = 45 btc per block for miner B vs 27 btc for miner B.
Miner B would still go out of business, bigger blocks still mean more
mining and validation centralization. The question is how far I we willing
to go with
On 05/29/15 23:48, Gavin Andresen wrote:
On Fri, May 29, 2015 at 7:25 PM, Matt Corallo bitcoin-l...@bluematt.me
mailto:bitcoin-l...@bluematt.me wrote:
Sadly, this is very far from the whole story. The issue of miners
optimizing for returns has been discussed several times during
Stop trying to dictate block growth limits. Block size will be determined
by competition between miners and availability of transactions, not through
hard-coded limits.
Do you even game theory, bro? It doesn't work that way.
Mike Hearn described the problem in this article:
On Fri, May 29, 2015 at 7:42 PM, Chun Wang 1240...@gmail.com wrote:
Hello. I am from F2Pool. We are currently mining the biggest blocks on
the network.
Thanks for giving your opinion!
Bad miners could attack us and the network with artificial
big blocks.
How?
I ran some simulations,
Matt brought this up on Twitter, I have no idea why I didn't respond weeks
ago (busy writing blog posts, probably):
On Thu, May 7, 2015 at 6:02 PM, Matt Corallo bitcoin-l...@bluematt.me
wrote:
* Though there are many proposals floating around which could
significantly decrease block
On 05/29/15 22:36, Gavin Andresen wrote:
Matt brought this up on Twitter, I have no idea why I didn't respond
weeks ago (busy writing blog posts, probably):
On Thu, May 7, 2015 at 6:02 PM, Matt Corallo bitcoin-l...@bluematt.me
mailto:bitcoin-l...@bluematt.me wrote:
* Though
Hello. I am from F2Pool. We are currently mining the biggest blocks on
the network. So far top 100 biggest bitcoin blocks are all from us. We
do support bigger blocks and sooner rather than later. But we cannot
handle 20 MB blocks right now. I know most blocks would not be 20 MB
over night. But
On Sat, May 9, 2015 at 4:08 AM, Peter Todd p...@petertodd.org wrote:
I wonder if having a miner flag would be good for the network.
Makes it trivial to find miners and DoS attack them - a huge risk to the
network as a whole, as well as the miners.
To mitigate against this, two chaintips
On Sat, May 16, 2015 at 5:39 AM, Stephen stephencalebmo...@gmail.com
wrote:
I think this could be mitigated by counting confirmations differently. We
should think of confirmations as only coming from blocks following the
miners' more strict rule set. So if a merchant were to see payment for
Comments in line:
On May 8, 2015, at 11:08 PM, Peter Todd p...@petertodd.org wrote:
Makes it trivial to find miners and DoS attack them - a huge risk to the
network as a whole, as well as the miners.
Right now pools already get DoSed all the time through their work
submission systems;
08.05.2015 at 5:49 Jeff Garzik wrote:
To repeat, the very first point in my email reply was: Agree that 7 tps
is too low
For interbank trading that would maybe enough but I don't know.
I'm not a developer but as a (former) user and computer scientist I'm
also asking myself what is the core
Personally, for privacy reasons I do not want to leave a footprint in the
blockchain for each pizza. And why should this expense be good for trivial
things of everyday life?
Then what's the point?
Isn't this supposed to be an Open transactional network, it doesn't matter
if you don't want that,
The nice thing about 1 MB is that you can store ALL bitcoin transactions
relevant to your lifetime (~100 years) on one 5 TB hard drive
(1*6*24*365*100=5256000). Any regular person can run a full node and store
this 5 TB hard drive easily at their home. With 10 MB blocks you need a 50
TB drive just
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/09/2015 02:02 PM, Andrew wrote:
The nice thing about 1 MB is that you can store ALL bitcoin
transactions relevant to your lifetime (~100 years) on one 5 TB
hard drive (1*6*24*365*100=5256000). Any regular person can run a
full node and store
On Sat, May 9, 2015 at 12:53 PM, Justus Ranvier justusranv...@riseup.net
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/09/2015 02:02 PM, Andrew wrote:
The nice thing about 1 MB is that you can store ALL bitcoin
transactions relevant to your lifetime (~100 years) on one 5 TB
] Block Size Increase
Thanks Matt; I was actually really confused by this sudden push with
not a word here or on Github--so much so that I responded on Reddit to
people pointing to commits in Gavin's personal repository saying they
were reading too much into it.
I saw this. I was also pointing
* Though there are many proposals floating around which could
significantly decrease block propagation latency, none of them are
implemented today.
With a 20mb cap, miners still have the option of the soft limit.
I would actually be quite surprised if there were no point along the road
Alan argues that 7 tps is a couple orders of magnitude too low
By the way, just to clear this up - the real limit at the moment is more
like 3 tps, not 7.
The 7 transactions/second figure comes from calculations I did years ago,
in 2011. I did them a few months before the sendmany command was
This isn't about everyone's coffee. This is about an absolute minimum
amount of participation by people who wish to use the network. If our
goal is really for bitcoin to really be a global, open transaction
network that makes money fluid, then 7tps is already a failure. If even
5% of the
On 05/08/2015 01:13 AM, Tom Harding wrote:
On 5/7/2015 7:09 PM, Jeff Garzik wrote:
G proposed 20MB blocks, AFAIK - 140 tps
A proposed 100MB blocks - 700 tps
For ref,
Paypal is around 115 tps
VISA is around 2000 tps (perhaps 4000 tps peak)
For reference, I'm not proposing 100 MB blocks
On Fri, May 8, 2015 at 2:59 PM, Alan Reiner etothe...@gmail.com wrote:
This isn't about everyone's coffee. This is about an absolute minimum
amount of participation by people who wish to use the network. If our
goal is really for bitcoin to really be a global, open transaction network
On Fri, May 8, 2015 at 10:59 AM, Alan Reiner etothe...@gmail.com wrote:
This isn't about everyone's coffee. This is about an absolute minimum
amount of participation by people who wish to use the network. If our
goal is really for bitcoin to really be a global, open transaction network
On Fri, May 08, 2015 at 12:03:04PM +0200, Mike Hearn wrote:
* Though there are many proposals floating around which could
significantly decrease block propagation latency, none of them are
implemented today.
With a 20mb cap, miners still have the option of the soft limit.
The
On Fri, May 8, 2015 at 5:37 PM, Peter Todd p...@petertodd.org wrote:
The soft-limit is there miners themselves produce smaller blocks; the
soft-limit does not prevent other miners from producing larger blocks.
I wonder if having a miner flag would be good for the network.
Clients for general
Actually I believe that side chains and off-main-chain transactions will be
a critical part for the overall scalability of the network. I was actually
trying to make the point that (insert some huge block size here) will be
needed to even accommodate the reduced traffic.
I believe that it is
Replace by fee is what I was referencing. End-users interpret the old
transaction as expired. Hence the nomenclature. An alternative is a new
feature that operates in the reverse of time lock, expiring a transaction after
a specific time. But time is a bit unreliable in the blockchain
Hello,
I was reading some of the thread but can't say I read the entire thing.
I think that it is realistic to cinsider a nlock sixe of 20MB for any block
txn to occur. THis is an enormous amount of data (relatively for a netwkrk)
in which the avergage rate of 10tps over 10 miniutes would allow
Transactions don't expire. But if the wallet is online, it can periodically
choose to release an already created transaction with a higher fee. This
requires replace-by-fee to be sufficiently deployed, however.
On Fri, May 8, 2015 at 1:38 PM, Raystonn . rayst...@hotmail.com wrote:
I have a
Replace by fee is the better approach. It will ultimately replace zombie transactions (due to insufficient fee) with potentially much higher fees as the feature takes hold in wallets throughout the network, and fee competition increases. However, this does not fix the problem of low tps. In fact,
On Fri, May 08, 2015 at 08:47:52PM +0100, Tier Nolan wrote:
On Fri, May 8, 2015 at 5:37 PM, Peter Todd p...@petertodd.org wrote:
The soft-limit is there miners themselves produce smaller blocks; the
soft-limit does not prevent other miners from producing larger blocks.
I wonder if
On Wednesday 6. May 2015 21.49.52 Peter Todd wrote:
I'm not sure if you've seen this, but a good paper on this topic was
published recently: The Economics of Bitcoin Transaction Fees
The obvious flaw in this paper is that it talks about a block size in todays
(trivial) data-flow economy and
I have a proposal for wallets such as yours. How about creating all transactions with an expiration time starting with a low fee, then replacing with new transactions that have a higher fee as time passes. Users can pick the fee curve they desire based on the transaction priority they want to
The problems with that are larger than time being unreliable. It is no
longer reorg-safe as transactions can expire in the course of a reorg and
any transaction built on the now expired transaction is invalidated.
On Fri, May 8, 2015 at 1:51 PM, Raystonn rayst...@hotmail.com wrote:
Replace by
Hey Matt,
OK, let's get started
However, there hasnt been any discussion on this
mailing list in several years as far as I can tell.
Probably because this list is not a good place for making progress or
reaching decisions. Those are triggered by pull requests (sometimes).
If you're
On Thu, May 07, 2015 at 12:59:13PM -0400, Gavin Andresen wrote:
Fee dynamics seems to come up over and over again in these discussions,
with lots of talk and theorizing.
I hope some data on what is happening with fees right now might help, so I
wrote another blog post (with graphs, which
The only answer to this that anyone with a clue should give is it
will very, very likely be able to support at least 1MB blocks roughly
every 10 minutes on average for the next eleven years, and it seems
likely that a block size increase of some form will happen at some point in
the next
On Thu, May 7, 2015 at 3:31 PM, Alan Reiner etothe...@gmail.com wrote:
(1) Blocks are essentially nearing full now. And by full he means
that the reliability of the network (from the average user perspective) is
about to be impacted in a very negative way
Er, to be economically precise,
Instead of raising the block size to another static number like 20MB, can
we raise it dynamically?
Make the max block size something like:
pow(2, nHeight/10) * 1MB; //double every ~2 years
--
One dashboard for
Just to add to the noise, did you consider linear growth?
Unlike exponential growth, it approximates diminishing returns (i.e. tech
advances become slower with time). And unlike single step, it will give
people time to adapt to new realities.
E.g. 2 MB in 2016, 3 MB in 2017 and so on.
So in 20
On Thu, May 7, 2015 at 3:03 PM, Matt Corallo bitcoin-l...@bluematt.me
wrote:
More generally, consider the situation we're in now. Gavin is going off
pitching this idea to the general public (which, I agree, is an
important step in pulling off a hardfork) while people who actually
study the
On 05/07/15 11:29, Mike Hearn wrote:
Can you please elaborate on what terrible things will happen if we
don't increase the block size by winter this year?
I was referring to winter next year. 0.12 isn't scheduled until the end
of the year, according to Wladimir. I explained where
Any proposal to switch to a new hardcorded value so we have time to
*really* figure out later what's next and all implications, is a road
to a gigantic issue later when we want to switch to that next.
Sure we would have more time to think about, research all
implications, simulate, discuss, etc.
It seems to me like some (maybe most) of the pressure is actually external
from companies that might release something that dramatically increases
adoption transaction rates (and that the data on historic rate of
adoption slumps is somewhat disconnected from their interests in a quick
roll-out)?
Hearn m...@plan99.net
Date: Friday, 8 May, 2015 2:06 am
To: Btc Drak btcd...@gmail.com
Cc: Bitcoin Dev bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Block Size Increase
I think you are rubbing against your own presupposition that people must find
and alternative
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/07/2015 09:54 PM, Jeff Garzik wrote:
By the time we get to fee pressure, in your scenario, our network
node count is tiny and highly centralized.
Again, this assertion requires proof.
Simply saying things is not the same as them being true.
I have written up an explanation of what I think will happen if we run out
of capacity:
https://medium.com/@octskyward/crash-landing-f5cc19908e32
Looks like a solid description of what would happen.
I fail to see how this description wouldn't be applicable also to a
20MB-network in some
On Thu, May 7, 2015 at 6:43 PM, Mike Hearn m...@plan99.net wrote:
And I'll ask again. Do you have a *specific, credible alternative*?
Because so far I'm not seeing one.
I think you are rubbing against your own presupposition that people must
find and alternative right now. Quite a lot here do
I'm presuming that schedule is just an example, as you'd end up with
insanely large block sizes in a few years.
Absolutely, yes, an increase schedule is an option if people agree on
it, and I think the better option, as the current limit too low, but
jumping straight to a value big enough for
This *is* urgent and needs to be handled right now, and I believe Gavin
has the best approach to this. I have heard Gavin's talks on increasing
the block size, and the two most persuasive points to me were:
(1) Blocks are essentially nearing full now. And by full he means
that the reliability
On Thu, May 7, 2015 at 6:59 PM, Gavin Andresen gavinandre...@gmail.com wrote:
Fee dynamics seems to come up over and over again in these discussions, with
lots of talk and theorizing.
I hope some data on what is happening with fees right now might help, so I
wrote another blog post (with
I think you are rubbing against your own presupposition that people must
find and alternative right now. Quite a lot here do not believe there is
any urgency, nor that there is an immanent problem that has to be solved
before the sky falls in.
I have explained why I believe there is some
These statements may even be true, but they're no logical conclusions
even if they seem obvious to you.
I don't think those claims are strictly true, specially because they
involve predictions about what people will do.
But if they're true they require some proof or at least some explanation.
Can I just add my own support for this - as has been stated elsewhere in
this discussion, hard forks are difficult, and risky. The earlier we
have a decision, and the earlier the change goes into the code, the
easier that is.
Even if the decision was the actual block size change is fine to
On Thu, May 7, 2015 at 7:40 PM, Gavin Costin slashdevn...@hotmail.com
wrote:
Can anyone opposed to this proposal articulate in plain english the worst
case scenario(s) if it goes ahead?
Some people in the conversation appear to be uncomfortable, perturbed,
defensive etc about the proposal ….
The appropriate method of doing any fork, that we seem to have been
following for a long time, is to get consensus here and on IRC and on
github and *then* go pitch to the general public
So your concern is just about the ordering and process of things, and not
about the change itself?
I
On Thu, May 7, 2015 at 5:11 PM, Mike Hearn m...@plan99.net wrote:
Right now there is this nice warm fuzzy notion that decisions in Bitcoin
Core are made by consensus. Controversial changes are avoided. I am
trying to show you that this is just marketing.
Consensus is arrived when the people
Hi Matt,
I agree that starting discussion on how to approach this problem is
necessary and it's difficult taking positions without details on what is
being discussed.
A simple hard 20-megabyte increase will likely create perverse
incentives, perhaps a method can exist with some safe transition.
On 5/7/2015 12:54 PM, Jeff Garzik wrote:
In the short term, blocks are bursty, with some on 1 minute intervals,
some with 60 minute intervals. This does not change with larger blocks.
I'm pretty sure Alan meant that blocks are already filling up after long
inter-block intervals.
2)
On Thu, May 07, 2015 at 10:02:09PM +, Matt Corallo wrote:
OK, so lets do that. I've seen a lot of I'm not entirely comfortable
with committing to this right now, but think we should eventually, but
not much I'd be comfortable with committing to this when I see X. In
the interest of
OK, so lets do that. I've seen a lot of I'm not entirely comfortable
with committing to this right now, but think we should eventually, but
not much I'd be comfortable with committing to this when I see X. In
the interest of ignoring debate and pushing people towards a consensus
at all costs, ( ;)
I am more fazed by PR 5288 and PR 5925 not getting merged in, than by this
thread. So, casting my ballot in favor of the block size increase. Clearly,
we're still rehearsing proper discourse, and that ain't gonna get fixed
here and now.
On Thu, May 7, 2015 at 9:29 PM, Matt Corallo
Having observed the customer support nightmare it tends to cause for a
small exchange service when 100% full blocks happen, I've been thinking
that the limit really should be dynamic and respond to demand and the
amount of fees offered. It just doesn't feel right when it takes ages to
burn through
Can you please elaborate on what terrible things will happen if we
don't increase the block size by winter this year?
I was referring to winter next year. 0.12 isn't scheduled until the end of
the year, according to Wladimir. I explained where this figure comes from
in this article:
On Thu, May 7, 2015 at 1:29 PM, Mike Hearn m...@plan99.net wrote:
I was referring to winter next year. 0.12 isn't scheduled until the end of
the year, according to Wladimir. I explained where this figure comes from in
this article:
On Thu, May 07, 2015 at 11:25:04AM +0200, Mike Hearn wrote:
Certainly a consensus in this kind of technical community should be a
basic requirement for any serious commitment to blocksize increase.
I'm afraid I have come to disagree. I no longer believe this community can
reach consensus
I'm mainly just an observer on this. I mostly agree with Pieter. Also, I
think the main reason why people like Gavin and Mike Hearn are trying to
rush this through is because they have some kind of apps that depend on
zero conf instant transactions, so this would of course require more
traffic on
On 5/7/2015 7:09 PM, Jeff Garzik wrote:
G proposed 20MB blocks, AFAIK - 140 tps
A proposed 100MB blocks - 700 tps
For ref,
Paypal is around 115 tps
VISA is around 2000 tps (perhaps 4000 tps peak)
I ask again: where do we want to go? This is the existential
question behind block size.
On Thu, May 7, 2015 at 9:40 PM, Tom Harding t...@thinlink.com wrote:
On 5/7/2015 12:54 PM, Jeff Garzik wrote:
2) Where do you want to go? Should bitcoin scale up to handle all the
world's coffees?
Alan was very clear. Right now, he wants to go exactly where Gavin's
concrete proposal
On Thu, May 07, 2015 at 03:31:46PM -0400, Alan Reiner wrote:
We get asked all the time by corporate clients about scalability. A
limit of 7 tps makes them uncomfortable that they are going to invest
all this time into a system that has no chance of handling the economic
activity that they
On 5/7/2015 6:40 AM, Jorge Timón wrote:
Known: There's a major problem looming for miners at the next block reward
halving. Many are already in a bad place and without meaningful fees then
sans a 2x increase in the USD:BTC ratio then many will simply have to leave
the network, increasing
I have a lot more written down, a WIP; here are the highlights.
- The 1MB limit is an ancient anti-spam limit, and needs to go.
- The 1MB limit is economically entrenched at this point, and cannot be
removed at a whim.
- This is a major change to the economics of a $3.2B system. This change
On Thu, May 7, 2015 at 9:05 AM, Mike Hearn m...@plan99.net wrote:
Maybe you dislike that idea. It's so centralised. So let's say Gavin
commits his patch, because his authority is equal to all other committers.
Someone else rolls it back. Gavin sets up a cron job to keep committing the
On Thu, May 07, 2015 at 04:05:41PM +0200, Mike Hearn wrote:
Peter: your hypocrisy really is bottomless, isn't it? You constantly
claim to be a Righteous Defender of Privacy, but don't even hesitate before
publishing hacked private emails when it suits you.
Satoshi's hacker had no illusions
On Thu, May 7, 2015 at 1:55 PM, Dave Hudson d...@hashingit.com wrote:
Known: There has been a steady trend towards the mean block size getting
larger. See
https://blockchain.info/charts/avg-block-size?timespan=allshowDataPoints=falsedaysAverageString=7show_header=truescale=0address=
Looking at
If his explanation was I will change my mind after we increase block
size, I guess the community should say then we will just ignore your
nack because it makes no sense.
Oh good! We can just kick anyone out of the consensus process if we think
they make no sense.
I guess that means me and
On 05/07/15 19:34, Mike Hearn wrote:
The appropriate method of doing any fork, that we seem to have been
following for a long time, is to get consensus here and on IRC and on
github and *then* go pitch to the general public
So your concern is just about the ordering and
That strikes me as a dangerous path forward.
I don't actually think there is anything wrong with this: everybody
eventually gets tired of arguing angels-dancing-on-the-head-of-a-pin, and
we're left with the status quo
What gives Bitcoin value aren't its technical merits but the fact that
people
What gives Bitcoin value aren't its technical merits but the fact that
people believe in it.
Much of the belief in Bitcoin is that it has a bright future. Certainly the
huge price spikes we've seen were not triggered by equally large spikes in
usage - it's speculation on that future.
I quite
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/07/2015 05:04 PM, Jeff Garzik wrote:
heh - I tend to think people here want bitcoin to succeed. My
statement refers to picking winners and losers from within the
existing bitcoin community stakeholders.
Success is not a sufficiently
On Thu, May 7, 2015 at 11:12 AM, Mike Hearn m...@plan99.net wrote:
That's why I conclude the opposite - if there is no fork, then people's
confidence in Bitcoin will be seriously damaged.
Yes, that is a possibility.
If it's impossible to do something as trivial as removing a temporary
On Thu, May 7, 2015 at 11:16 AM, Justus Ranvier justusranv...@riseup.net
wrote:
To be extremely specific: should Bitcoin development intenionally
limit the network's capabilities to leave room for other projects, or
should Bitcoin attempt to be the best system possible and let the
other
Dear list,
Apparently my emails are being marked as spam, despite being sent from
GMail's web interface. I've pinged our sysadmin. Thanks for letting
me know.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
On Thu, May 7, 2015 at 3:05 PM, Mike Hearn m...@plan99.net wrote:
Maybe you dislike that idea. It's so centralised. So let's say Gavin
commits his patch, because his authority is equal to all other committers.
Someone else rolls it back. Gavin sets up a cron job to keep committing the
On Thu, May 7, 2015 at 11:33 AM, Justus Ranvier justusranv...@riseup.net
wrote:
In summary, I asked a question neither you, nor Peter Todd, want to
answer and want to actively discourage people from even asking at all.
Incorrect; your question included built-in assumptions with which I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/07/2015 05:47 PM, Jeff Garzik wrote:
Bitcoin needs to be the best it can be (Layer 1), but all solutions
cannot and should not be implemented at Layer 1.
I can provisionally agree with that statement as long as all
solutions cannot and should
In my personal opinion, this does make some sense to me, assuming I
understood Gavin.
I suppose it could be done with a new flag (like the P2SH flag) which
displays miner support for larger blocks. The new rules would apply when
a large majority of miners support the new rules by counting the
It is an argument against my admittedly vague definition of
non-controversial change.
If it's an argument against something you said, it's not a straw man, right
;)
Consensus has to be defined as agreement between a group of people. Who are
those people? If you don't know, it's impossible to
Dear list,
Apparently my emails are being marked as spam, despite being sent from
GMail's web interface. I've pinged our sysadmin.
It's a problem with the mailing list software, not your setup. BitPay could
disable the phishing protections but that seems like a poor solution. The
only real
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/07/2015 03:35 PM, Jeff Garzik wrote:
Raising the block size limit then becomes a *human decision* to
favor some users over others, a *human decision* to prevent an
active and competitive free fee market developing at 1MB, a *human
decision*
On Thu, May 7, 2015 at 4:52 PM, Gavin Andresen gavinandre...@gmail.com wrote:
I would very much like to find some concrete course of action that we can
come to consensus on. Some compromise so we can tell entrepreneurs THIS is
how much transaction volume the main Bitcoin blockchain will be able
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/07/2015 04:04 PM, Jeff Garzik wrote:
- This is a major change to the economics of a $3.2B system. This
change picks winners and losers. There is attendant moral hazard.
This is exactly true.
There are a number of projects which aren't
On Thu, May 7, 2015 at 10:38 AM, Justus Ranvier justusranv...@riseup.net
wrote:
On 05/07/2015 04:04 PM, Jeff Garzik wrote:
- This is a major change to the economics of a $3.2B system. This
change picks winners and losers. There is attendant moral hazard.
This is exactly true.
There are
On Thu, May 07, 2015 at 05:13:34PM +0200, Justus Ranvier wrote:
On 05/07/2015 04:49 PM, Peter Todd wrote:
I think we'll find an basic assumption of civility to be more
productive, until proven otherwise. (e.g. NSA ties)
I'm not sure why you'd construe my post as having anything to do
100% agree, RE hard forks should be hard.
However, it is the paradox of growth, morale and adoption that bitcoin
might never reach the point where it is saturated expensive to the point
where larger blocks are demanded by 95%+... simply because people and
companies chose not to adopt bitcoin in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/07/2015 04:49 PM, Peter Todd wrote:
I think we'll find an basic assumption of civility to be more
productive, until proven otherwise. (e.g. NSA ties)
I'm not sure why you'd construe my post as having anything to do with
accusations like
It is a trivial *code* change. It is not a trivial change to the
economics of a $3.2B system.
Hmm - again I'd argue the opposite.
Up until now Bitcoin has been unconstrained by the hard block size limit.
If we raise it, Bitcoin will continue to be unconstrained by it. That's the
default
1 - 100 of 131 matches
Mail list logo
