Ai uitat sa pui :
1-We see the need for a modest block size increase in order to move the Bitcoin project forward, but we would like to do it with minimal risk, taking the safest and most balanced route possible. SegWit is almost ready and we support its deployment as a step in scaling.
3-In the next 3 weeks, we need the Bitcoin Core developers to work with us and clarify the roadmap with respect to a future hard-fork which includes an increase of the block size. Currently we are in discussions to determine the next best steps. We are as a matter of principle against unduly rushed or controversial hard-forks irrespective of the team proposing and we will not run such code on production systems nor mine any block from that hard-fork. We urge everyone to act rationally and hold off on making any decision to run a contentious hard-fork (Classic/XT or any other).
1-We see the need for a
modest block size increase in order to move the Bitcoin project forward, but we would like to do it with
minimal risk, taking the safest and most balanced route possible. SegWit is almost ready and we support its deployment as a step in scaling.
3-In the next 3 weeks, we need the Bitcoin Core developers to work with us and clarify the roadmap with respect to a future hard-fork which includes an increase of the block size. Currently we are in discussions to determine the next best steps.
We are as a matter of principle against unduly rushed or controversial hard-forks irrespective of the team proposing and we will not run such code on production systems nor mine any block from that hard-fork.
We urge everyone to act rationally and hold off on making any decision to run a contentious hard-fork (Classic/XT or any other).
Deci problema cat se poate de reala ..si aia cu modest increase prin SigWit e " just kick the can down the road"...tot la un hard fork se va ajunge
http://bitcoinfees.com/https://bitcoinfees.21.co/The fastest and cheapest transaction fee is currently 20 satoshis/byte, shown in green at the top.
For the median transaction size of 272 bytes, this results in a fee of 5,440 satoshis.
http://qntra.net/2015/01/the-hard-fork-missile-crisis/There have only ever been two hard forks of the blockchain in the history of Bitcoin, and both nearly killed Bitcoin. The first was overseen by Satoshi in an attempt to fix the worst Bitcoin bug seen to date, and an unforeseen fork in which BerkeleyDB was replaced with LevelDB to allow for blocks greater than 512kb to be accepted by the network. The latter fork however didn't disenfranchise older clients by forcing them to use LevelDB over BerkeleyDB – a one line workaround resolves the bug in clients still running with BerkeleyDB.
[bitcoin]$ git show 5e650d6d2dbfc284c300668e71188e663d8f0a45
commit 5e650d6d2dbfc284c300668e71188e663d8f0a45
Author: Mike Hearn
Date: Mon Jun 25 11:17:22 2012 +0200
Import LevelDB 1.5, it will be used for the transaction database.
Let's go over a shorter but more comprehensive history of Mike's "contributions":
BitcoinJ, a software library in Java created for and still featured in some Bitcoin SPV clients.
Contributions to "Bitcoin" v0.82 where two changes pushed by Hearn were introduced:
Blockchain handling databased changed to LevelDB, leading to the Fork of March 2013.
Bloom Filters, which lead to several means to remotely crash bitcoin nodes serving them, and presented a perennial annoyance to nodes not serving them until recently.