path: root/a7/8e48c54b6facfbd8bd469e8069e3f58a4cd334

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <dave@hashingit.com>) id 1Yrit2-0007gc-94
	for bitcoin-development@lists.sourceforge.net;
	Mon, 11 May 2015 08:16:28 +0000
Received-SPF: softfail (sog-mx-1.v43.ch3.sourceforge.com: transitioning domain
	of hashingit.com does not designate 89.145.69.228 as permitted
	sender) client-ip=89.145.69.228;
	envelope-from=dave@hashingit.com; helo=heron.directrouter.co.uk;
Received: from heron.directrouter.co.uk ([89.145.69.228])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1Yrisz-0007Yq-DS
	for bitcoin-development@lists.sourceforge.net;
	Mon, 11 May 2015 08:16:28 +0000
Received: from host109-155-54-156.range109-155.btcentralplus.com
	([109.155.54.156]:52660 helo=[192.168.1.82])
	by heron.directrouter.co.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256)
	(Exim 4.85) (envelope-from <dave@hashingit.com>)
	id 1Yrisr-000Reu-V4; Mon, 11 May 2015 08:16:18 +0000
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_ACE953B9-3758-4DA2-AAA3-021039D5B024"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Dave Hudson <dave@hashingit.com>
In-Reply-To: <BAY403-EAS184981B0219DEB969D407CC2DB0@phx.gbl>
Date: Mon, 11 May 2015 09:16:17 +0100
Message-Id: <4C4AB2DC-CB50-4733-B341-7B7A6B7AD801@hashingit.com>
References: <BAY403-EAS184981B0219DEB969D407CC2DB0@phx.gbl>
To: Thy Shizzle <thyshizzle@outlook.com>
X-Mailer: Apple Mail (2.2098)
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - heron.directrouter.co.uk
X-AntiAbuse: Original Domain - lists.sourceforge.net
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - hashingit.com
X-Get-Message-Sender-Via: heron.directrouter.co.uk: authenticated_id:
	dave@hashingit.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Spam-Score: 2.0 (++)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1Yrisz-0007Yq-DS
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Reducing the block rate instead of
	increasing	the maximum block size
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 11 May 2015 08:16:28 -0000


--Apple-Mail=_ACE953B9-3758-4DA2-AAA3-021039D5B024
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I proposed the same thing last year (there's a video of the presentation =
I was giving somewhere around). My intuition was that this would require =
slowly reducing the inter-block time, probably by step reductions at =
particular block heights.

Having had almost a year to think about it some more there are a few =
subtleties:

1) I think it could discourage decentralisation if the nominal 2 week =
period per difficulty retarget is retained. If we reached 4032 blocks =
and a 5 minute block time then there would be 2x as many blocks at any =
given difficulty which increases the odds of a smaller pool finding a =
block and thus getting a reward. Block rewards would have to drop in =
proportion to the reduced interval to keep the total schedule of 21M =
coins on track though, but the reduction in variance is a win for =
smaller miners.

2) There are limits to the block time. The speed of light is an =
ultimately limiting factor here, but we would want to avoid excessive =
orphan rates.

3) There would be some amount of confusion about numbers of =
confirmations. I actually think that confirmation numbers are a really =
misleading idea anyway and it would be safer to think in terms of =
"minutes of security". A zero conf transaction has "zero minutes", while =
right now 1, 2, 3 and 6 would be "ten minutes", "twenty minutes", =
"thirty minutes" and "sixty minutes" respectively. If our block time =
were 5 minutes then 8 confirmations would be "forty minutes" of =
security; if the block time was 2.5 minutes then 8 confirmations would =
be "twenty minutes" of security. The "minutes of security" measure =
indicates the mean number of minutes of the entire network's hash rate =
would be required to undo a transaction.

4) Reducing the inter-block time reduces the variance in reaching that =
"sixty minutes" of security level. The variance around finding 6 blocks =
with a ten minute interval is much wider than the variance for finding =
12 blocks with a 5 minute interval.



> On 11 May 2015, at 08:30, Thy Shizzle <thyshizzle@outlook.com> wrote:
>=20
> Yes This!
>=20
> So many people seem hung up on growing the block size! If gaining a =
higher tps throughput is the main aim, I think that this proposition to =
speed up block creation has merit!
>=20
> Yes it will lead to an increase in the block chain still due to 1mb ~1 =
minute instead of ~10 minute, but the change to the protocol is minor, =
you are only adding in a different difficulty rate starting from hight =
blah, no new features or anything are being added so there seems to me =
much less of a security risk! Also that impact if a hard fork should be =
minimal because there is nothing but absolute incentive for miners to =
mine at the new easier difficulty!
>=20
> I feel this deserves a great deal of consideration as opposed to =
blowing out the block through miners voting etc!!!!
> From: Sergio Lerner <mailto:sergiolerner@certimix.com>
> Sent: =E2=80=8E11/=E2=80=8E05/=E2=80=8E2015 5:05 PM
> To: bitcoin-development@lists.sourceforge.net =
<mailto:bitcoin-development@lists.sourceforge.net>
> Subject: [Bitcoin-development] Reducing the block rate instead of =
increasing the maximum block size
>=20
> In this e-mail I'll do my best to argue than if you accept that
> increasing the transactions/second is a good direction to go, then
> increasing the maximum block size is not the best way to do it. I =
argue
> that the right direction to go is to decrease the block rate to 1
> minute, while keeping the block size limit to 1 Megabyte (or =
increasing
> it from a lower value such as 100 Kbyte and then have a step =
function).
> I'm backing up my claims with many hours of research simulating the
> Bitcoin network under different conditions [1].  I'll try to convince
> you by responding to each of the arguments I've heard against it.
>=20
> Arguments against reducing the block interval
>=20
> 1. It will encourage centralization, because participants of mining
> pools will loose more money because of excessive initial block =
template
> latency, which leads to higher stale shares
>=20
> When a new block is solved, that information needs to propagate
> throughout the Bitcoin network up to the mining pool operator nodes,
> then a new block header candidate is created, and this header must be
> propagated to all the mining pool users, ether by a push or a pull
> model. Generally the mining server pushes new work units to the
> individual miners. If done other way around, the server would need to
> handle a high load of continuous work requests that would be difficult
> to distinguish from a DDoS attack. So if the server pushes new block
> header candidates to clients, then the problem boils down to =
increasing
> bandwidth of the servers to achieve a tenfold increase in work
> distribution. Or distributing the servers geographically to achieve a
> lower latency. Propagating blocks does not require additional CPU
> resources, so mining pools administrators would need to increase
> moderately their investment in the server infrastructure to achieve
> lower latency and higher bandwidth, but I guess the investment would =
be low.
>=20
> 2. It will increase the probability of a block-chain split
>=20
> The convergence of the network relies on the diminishing probability =
of
> two honest miners creating simultaneous competing blocks chains. To
> increase the competition chain, competing blocks must be generated in
> almost simultaneously (in the same time window approximately bounded =
by
> the network average block propagation delay). The probability of a =
block
> competition decreases exponentially with the number of blocks. In =
fact,
> the probability of a sustained competition on ten 1-minute blocks is =
one
> million times lower than the probability of a competition of one
> 10-minute block. So even if the competition probability of six =
1-minute
> blocks is higher than of six ten-minute blocks, this does not imply
> reducing the block rate increases this chance, but on the contrary,=20
> reduces it.
>=20
> 3, It will reduce the security of the network
>=20
> The security of the network is based on two facts:
> A- The miners are incentivized to extend the best chain
> B- The probability of a reversal based on a long block competition
> decreases as more confirmation blocks are appended.
> C- Renting or buying hardware to perform a 51% attack is costly.
>=20
> A still holds. B holds for the same amount of confirmation blocks, so =
6
> confirmation blocks in a 10-minute block-chain is approximately
> equivalent to 6 confirmation blocks in a 1-minute block-chain.
> Only C changes, as renting the hashing power for 6 minutes is ten =
times
> less expensive as renting it for 1 hour. However, there is no shop =
where
> one can find 51% of the hashing power to rent right now, nor probably
> will ever be if Bitcoin succeeds. Last, you can still have a 1 hour
> confirmation (60 1-minute blocks) if you wish for high-valued =
payments,
> so the security decreases only if participant wish to decrease it.
>=20
> 4. Reducing the block propagation time on the average case is good, =
but
> what happen in the worse case?
>=20
> Most methods proposed to reduce the block propagation delay do it only
> on the average case. Any kind of block compression relies on both
> parties sharing some previous information. In the worse case it's true
> that a miner can create and try to broadcast a block that takes too =
much
> time to verify or bandwidth to transmit. This is currently true on the
> Bitcoin network. Nevertheless there is no such incentive for miners,
> since they will be shooting on their own foots. Peter Todd has argued
> that the best strategy for miners is actually to reach 51% of the
> network, but not more. In other words, to exclude the slowest 49%
> percent. But this strategy of creating bloated blocks is too risky in
> practice, and surely doomed to fail, as network conditions dynamically=20=

> change. Also it would be perceived as an attack to the network, and =
the
> miner (if it is a public mining pool) would be probably blacklisted.
>=20
> 5. Thousands of SPV wallets running in mobile devices would need to be
> upgraded (thanks Mike).
>=20
> That depends on the current upgrade rate for SPV wallets like Bitcoin
> Wallet  and BreadWallet. Suppose that the upgrade rate is 80%/year: we
> develop the source code for the change now and apply the change in Q2
> 2016, then  most of the nodes will already be upgraded by when the
> hardfork takes place. Also a public notice telling people to upgrade =
in
> web pages, bitcointalk, SPV wallets warnings, coindesk, one year in
> advance will give plenty of time to SPV wallet users to upgrade.
>=20
> 6. If there are 10x more blocks, then there are 10x more block =
headers,
> and that increases the amount of bandwidth SPV wallets need to catch =
up
> with the chain
> =20
> A standard smartphone with average cellular downstream speed downloads
> 2.6 headers per second (1600 kbits/sec) [3], so if synchronization =
were
> to be done only at night when the phone is connected to the power =
line,
> then it would take 9 minutes to synchronize with 1440 headers/day. If =
a
> person should accept a payment, and the smart-phone is 1 day
> out-of-synch, then it takes less time to download all the missing
> headers than to wait for a 10-minute one block confirmation. Obviously
> all smartphones with 3G have a downstream bandwidth much higher,
> averaging 1 Mbps. So the whole synchronization will be done less than =
a
> 1-minute block confirmation.
> =20
> According to CISCO mobile bandwidth connection speed increases 20% =
every
> year. In four years, it will have doubled, so mobile phones with lower
> than average data connection will soon be able to catchup.
> Also there is low-hanging-fruit optimizations to the protocol that =
have
> not been implemented: each header is 80 bytes in length. When a set of
> chained headers is transferred, the headers could be compressed,
> stripping 32 bytes of each header that is derived from the previous
> header hash digest. So a 40% compression is already possible by =
slightly
> modifying the wire protocol.
> =20
> 7. There has been insufficient testing and/or insufficient research =
into
> technical/economic implications or reducing the block rate
> =20
> This is partially true. in the GHOST paper, this has been analyzed, =
and
> the problem was shown to be solvable for block intervals of just a few
> seconds. There are several proof-of-work cryptocurrencies in existence
> that have lower than 1 minute block intervals and they work just fine.
> First there was Bitcoin with a 10 minute interval, then was LiteCoin
> using a 2.5 interval, then was DogeCoin with 1 minute, and then
> QuarkCoin with just 30 seconds. Every new cryptocurrency lowers it a
> little bit. Some time ago I decided to research on the block rate to
> understand how the block interval impacts the stability and capability
> of the cryptocurrency network, and I came up with the idea of the =
DECOR+
> protocol [4] (which requires changes in the consensus code). In my
> research I also showed how the stale rate can be easily reduced only
> with changes in the networking code, and not in the consensus code.
> These networking optimizations ( O(1) propagation using headers-first =
or
> IBLTs), can be added later.
> =20
> Mortifying Bitcoin to accommodate the change to lower the block rate
> requires at least:
> =20
> - Changing the 21 BTC reward per block to 2.1 BTC
> - Changing the nPowTargetTimespan constant
> - Writing code to hard-fork automatically when the majority of miners
> have upgraded.
> - Allow transaction version 3, and interpret nLockTimes of transaction
> version 2 as being multiplied by 10.
>=20
> All changes comprises no more than 15 lines of code. This is much less
> than the number of lines modified by Gavin's 20Mb patch.
> =20
> As a conclusion, I haven't yet heard a good argument against lowering
> the block rate.
>=20
> Best regards,
>  Sergio.
> =20
> [0] https://medium.com/@octskyward/the-capacity-cliff-586d1bf7715e =
<https://medium.com/@octskyward/the-capacity-cliff-586d1bf7715e>
> [1] https://bitslog.wordpress.com/2014/02/17/5-sec-block-interval/ =
<https://bitslog.wordpress.com/2014/02/17/5-sec-block-interval/>
> [2] http://gavinandresen.ninja/time-to-roll-out-bigger-blocks =
<http://gavinandresen.ninja/time-to-roll-out-bigger-blocks>
> [3]
> =
http://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-=
networking-index-vni/white_paper_c11-520862.html =
<http://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual=
-networking-index-vni/white_paper_c11-520862.html>
> [4] https://bitslog.wordpress.com/2014/05/02/decor/ =
<https://bitslog.wordpress.com/2014/05/02/decor/>
>=20
> =
--------------------------------------------------------------------------=
----
> One dashboard for servers and applications across =
Physical-Virtual-Cloud=20
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable =
Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y =
<http://ad.doubleclick.net/ddm/clk/290420510;117567292;y>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development =
<https://lists.sourceforge.net/lists/listinfo/bitcoin-development>
> =
--------------------------------------------------------------------------=
----
> One dashboard for servers and applications across =
Physical-Virtual-Cloud=20
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable =
Insights
> Deep dive visibility with transaction tracing using APM Insight.
> =
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___________________=
____________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--Apple-Mail=_ACE953B9-3758-4DA2-AAA3-021039D5B024
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div class=3D"">I proposed the same thing last year (there's =
a video of the presentation I was giving somewhere around). My intuition =
was that this would require slowly reducing the inter-block time, =
probably by step reductions at particular block heights.</div><div =
class=3D""><br class=3D""></div><div class=3D"">Having had almost a year =
to think about it some more there are a few subtleties:</div><div =
class=3D""><br class=3D""></div><div class=3D"">1) I think it could =
discourage decentralisation if the nominal 2 week period per difficulty =
retarget is retained. If we reached 4032 blocks and a 5 minute block =
time then there would be 2x as many blocks at any given difficulty which =
increases the odds of a smaller pool finding a block and thus getting a =
reward. Block rewards would have to drop in proportion to the reduced =
interval to keep the total schedule of 21M coins on track though, but =
the reduction in variance is a win for smaller miners.</div><div =
class=3D""><br class=3D""></div><div class=3D"">2) There are limits to =
the block time. The speed of light is an ultimately limiting factor =
here, but we would want to avoid excessive orphan rates.</div><div =
class=3D""><br class=3D""></div><div class=3D"">3) There would be some =
amount of confusion about numbers of confirmations. I actually think =
that confirmation numbers are a really misleading idea anyway and it =
would be safer to think in terms of "minutes of security". A zero conf =
transaction has "zero minutes", while right now 1, 2, 3 and 6 would be =
"ten minutes", "twenty minutes", "thirty minutes" and "sixty minutes" =
respectively. If our block time were 5 minutes then 8 confirmations =
would be "forty minutes" of security; if the block time was 2.5 minutes =
then 8 confirmations would be "twenty minutes" of security. The "minutes =
of security" measure indicates the mean number of minutes of the entire =
network's hash rate would be required to undo a transaction.</div><div =
class=3D""><br class=3D""></div><div class=3D"">4) Reducing the =
inter-block time reduces the variance in reaching that "sixty minutes" =
of security level. The variance around finding 6 blocks with a ten =
minute interval is much wider than the variance for finding 12 blocks =
with a 5 minute interval.</div><div class=3D""><br class=3D""></div><div =
class=3D""><br class=3D""></div><br class=3D""><div><blockquote =
type=3D"cite" class=3D""><div class=3D"">On 11 May 2015, at 08:30, Thy =
Shizzle &lt;<a href=3D"mailto:thyshizzle@outlook.com" =
class=3D"">thyshizzle@outlook.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D"">

<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8" =
class=3D"">

<div class=3D"">
<div class=3D"">
<div style=3D"font-family: Calibri,sans-serif; font-size: 11pt;" =
class=3D"">Yes This!<br class=3D"">
<br class=3D"">
So many people seem hung up on growing the block size! If gaining a =
higher tps throughput is the main aim, I think that this proposition to =
speed up block creation has merit!<br class=3D"">
<br class=3D"">
Yes it will lead to an increase in the block chain still due to 1mb ~1 =
minute instead of ~10 minute, but the change to the protocol is minor, =
you are only adding in a different difficulty rate starting from hight =
blah, no new features or anything are being
 added so there seems to me much less of a security risk! Also that =
impact if a hard fork should be minimal because there is nothing but =
absolute incentive for miners to mine at the new easier difficulty!<br =
class=3D"">
<br class=3D"">
I feel this deserves a great deal of consideration as opposed to blowing =
out the block through miners voting etc!!!!</div>
</div>
<div dir=3D"ltr" class=3D"">
<hr class=3D"">
<span style=3D"font-family: Calibri,sans-serif; font-size: 11pt; =
font-weight: bold;" class=3D"">From:
</span><span style=3D"font-family: Calibri,sans-serif; font-size: 11pt;" =
class=3D""><a href=3D"mailto:sergiolerner@certimix.com" class=3D"">Sergio =
Lerner</a></span><br class=3D"">
<span style=3D"font-family: Calibri,sans-serif; font-size: 11pt; =
font-weight: bold;" class=3D"">Sent:
</span><span style=3D"font-family: Calibri,sans-serif; font-size: 11pt;" =
class=3D"">=E2=80=8E11/=E2=80=8E05/=E2=80=8E2015 5:05 PM</span><br =
class=3D"">
<span style=3D"font-family: Calibri,sans-serif; font-size: 11pt; =
font-weight: bold;" class=3D"">To:
</span><span style=3D"font-family: Calibri,sans-serif; font-size: 11pt;" =
class=3D""><a href=3D"mailto:bitcoin-development@lists.sourceforge.net" =
class=3D"">bitcoin-development@lists.sourceforge.net</a></span><br =
class=3D"">
<span style=3D"font-family: Calibri,sans-serif; font-size: 11pt; =
font-weight: bold;" class=3D"">Subject:
</span><span style=3D"font-family: Calibri,sans-serif; font-size: 11pt;" =
class=3D"">[Bitcoin-development] Reducing the block rate instead of =
increasing the maximum block size</span><br class=3D"">
<br class=3D"">
</div>
<div class=3D"BodyFragment">
<div class=3D"PlainText">In this e-mail I'll do my best to argue than if =
you accept that<br class=3D"">
increasing the transactions/second is a good direction to go, then<br =
class=3D"">
increasing the maximum block size is not the best way to do it. I =
argue<br class=3D"">
that the right direction to go is to decrease the block rate to 1<br =
class=3D"">
minute, while keeping the block size limit to 1 Megabyte (or =
increasing<br class=3D"">
it from a lower value such as 100 Kbyte and then have a step =
function).<br class=3D"">
I'm backing up my claims with many hours of research simulating the<br =
class=3D"">
Bitcoin network under different conditions [1].&nbsp; I'll try to =
convince<br class=3D"">
you by responding to each of the arguments I've heard against it.<br =
class=3D"">
<br class=3D"">
Arguments against reducing the block interval<br class=3D"">
<br class=3D"">
1. It will encourage centralization, because participants of mining<br =
class=3D"">
pools will loose more money because of excessive initial block =
template<br class=3D"">
latency, which leads to higher stale shares<br class=3D"">
<br class=3D"">
When a new block is solved, that information needs to propagate<br =
class=3D"">
throughout the Bitcoin network up to the mining pool operator nodes,<br =
class=3D"">
then a new block header candidate is created, and this header must be<br =
class=3D"">
propagated to all the mining pool users, ether by a push or a pull<br =
class=3D"">
model. Generally the mining server pushes new work units to the<br =
class=3D"">
individual miners. If done other way around, the server would need to<br =
class=3D"">
handle a high load of continuous work requests that would be =
difficult<br class=3D"">
to distinguish from a DDoS attack. So if the server pushes new block<br =
class=3D"">
header candidates to clients, then the problem boils down to =
increasing<br class=3D"">
bandwidth of the servers to achieve a tenfold increase in work<br =
class=3D"">
distribution. Or distributing the servers geographically to achieve a<br =
class=3D"">
lower latency. Propagating blocks does not require additional CPU<br =
class=3D"">
resources, so mining pools administrators would need to increase<br =
class=3D"">
moderately their investment in the server infrastructure to achieve<br =
class=3D"">
lower latency and higher bandwidth, but I guess the investment would be =
low.<br class=3D"">
<br class=3D"">
2. It will increase the probability of a block-chain split<br class=3D"">
<br class=3D"">
The convergence of the network relies on the diminishing probability =
of<br class=3D"">
two honest miners creating simultaneous competing blocks chains. To<br =
class=3D"">
increase the competition chain, competing blocks must be generated in<br =
class=3D"">
almost simultaneously (in the same time window approximately bounded =
by<br class=3D"">
the network average block propagation delay). The probability of a =
block<br class=3D"">
competition decreases exponentially with the number of blocks. In =
fact,<br class=3D"">
the probability of a sustained competition on ten 1-minute blocks is =
one<br class=3D"">
million times lower than the probability of a competition of one<br =
class=3D"">
10-minute block. So even if the competition probability of six =
1-minute<br class=3D"">
blocks is higher than of six ten-minute blocks, this does not imply<br =
class=3D"">
reducing the block rate increases this chance, but on the contrary, <br =
class=3D"">
reduces it.<br class=3D"">
<br class=3D"">
3, It will reduce the security of the network<br class=3D"">
<br class=3D"">
The security of the network is based on two facts:<br class=3D"">
A- The miners are incentivized to extend the best chain<br class=3D"">
B- The probability of a reversal based on a long block competition<br =
class=3D"">
decreases as more confirmation blocks are appended.<br class=3D"">
C- Renting or buying hardware to perform a 51% attack is costly.<br =
class=3D"">
<br class=3D"">
A still holds. B holds for the same amount of confirmation blocks, so =
6<br class=3D"">
confirmation blocks in a 10-minute block-chain is approximately<br =
class=3D"">
equivalent to 6 confirmation blocks in a 1-minute block-chain.<br =
class=3D"">
Only C changes, as renting the hashing power for 6 minutes is ten =
times<br class=3D"">
less expensive as renting it for 1 hour. However, there is no shop =
where<br class=3D"">
one can find 51% of the hashing power to rent right now, nor probably<br =
class=3D"">
will ever be if Bitcoin succeeds. Last, you can still have a 1 hour<br =
class=3D"">
confirmation (60 1-minute blocks) if you wish for high-valued =
payments,<br class=3D"">
so the security decreases only if participant wish to decrease it.<br =
class=3D"">
<br class=3D"">
4. Reducing the block propagation time on the average case is good, =
but<br class=3D"">
what happen in the worse case?<br class=3D"">
<br class=3D"">
Most methods proposed to reduce the block propagation delay do it =
only<br class=3D"">
on the average case. Any kind of block compression relies on both<br =
class=3D"">
parties sharing some previous information. In the worse case it's =
true<br class=3D"">
that a miner can create and try to broadcast a block that takes too =
much<br class=3D"">
time to verify or bandwidth to transmit. This is currently true on =
the<br class=3D"">
Bitcoin network. Nevertheless there is no such incentive for miners,<br =
class=3D"">
since they will be shooting on their own foots. Peter Todd has argued<br =
class=3D"">
that the best strategy for miners is actually to reach 51% of the<br =
class=3D"">
network, but not more. In other words, to exclude the slowest 49%<br =
class=3D"">
percent. But this strategy of creating bloated blocks is too risky in<br =
class=3D"">
practice, and surely doomed to fail, as network conditions dynamically =
<br class=3D"">
change. Also it would be perceived as an attack to the network, and =
the<br class=3D"">
miner (if it is a public mining pool) would be probably blacklisted.<br =
class=3D"">
<br class=3D"">
5. Thousands of SPV wallets running in mobile devices would need to =
be<br class=3D"">
upgraded (thanks Mike).<br class=3D"">
<br class=3D"">
That depends on the current upgrade rate for SPV wallets like Bitcoin<br =
class=3D"">
Wallet&nbsp; and BreadWallet. Suppose that the upgrade rate is 80%/year: =
we<br class=3D"">
develop the source code for the change now and apply the change in Q2<br =
class=3D"">
2016, then&nbsp; most of the nodes will already be upgraded by when =
the<br class=3D"">
hardfork takes place. Also a public notice telling people to upgrade =
in<br class=3D"">
web pages, bitcointalk, SPV wallets warnings, coindesk, one year in<br =
class=3D"">
advance will give plenty of time to SPV wallet users to upgrade.<br =
class=3D"">
<br class=3D"">
6. If there are 10x more blocks, then there are 10x more block =
headers,<br class=3D"">
and that increases the amount of bandwidth SPV wallets need to catch =
up<br class=3D"">
with the chain<br class=3D"">
&nbsp;<br class=3D"">
A standard smartphone with average cellular downstream speed =
downloads<br class=3D"">
2.6 headers per second (1600 kbits/sec) [3], so if synchronization =
were<br class=3D"">
to be done only at night when the phone is connected to the power =
line,<br class=3D"">
then it would take 9 minutes to synchronize with 1440 headers/day. If =
a<br class=3D"">
person should accept a payment, and the smart-phone is 1 day<br =
class=3D"">
out-of-synch, then it takes less time to download all the missing<br =
class=3D"">
headers than to wait for a 10-minute one block confirmation. =
Obviously<br class=3D"">
all smartphones with 3G have a downstream bandwidth much higher,<br =
class=3D"">
averaging 1 Mbps. So the whole synchronization will be done less than =
a<br class=3D"">
1-minute block confirmation.<br class=3D"">
&nbsp;<br class=3D"">
According to CISCO mobile bandwidth connection speed increases 20% =
every<br class=3D"">
year. In four years, it will have doubled, so mobile phones with =
lower<br class=3D"">
than average data connection will soon be able to catchup.<br class=3D"">
Also there is low-hanging-fruit optimizations to the protocol that =
have<br class=3D"">
not been implemented: each header is 80 bytes in length. When a set =
of<br class=3D"">
chained headers is transferred, the headers could be compressed,<br =
class=3D"">
stripping 32 bytes of each header that is derived from the previous<br =
class=3D"">
header hash digest. So a 40% compression is already possible by =
slightly<br class=3D"">
modifying the wire protocol.<br class=3D"">
&nbsp;<br class=3D"">
7. There has been insufficient testing and/or insufficient research =
into<br class=3D"">
technical/economic implications or reducing the block rate<br class=3D"">
&nbsp;<br class=3D"">
This is partially true. in the GHOST paper, this has been analyzed, =
and<br class=3D"">
the problem was shown to be solvable for block intervals of just a =
few<br class=3D"">
seconds. There are several proof-of-work cryptocurrencies in =
existence<br class=3D"">
that have lower than 1 minute block intervals and they work just =
fine.<br class=3D"">
First there was Bitcoin with a 10 minute interval, then was LiteCoin<br =
class=3D"">
using a 2.5 interval, then was DogeCoin with 1 minute, and then<br =
class=3D"">
QuarkCoin with just 30 seconds. Every new cryptocurrency lowers it a<br =
class=3D"">
little bit. Some time ago I decided to research on the block rate to<br =
class=3D"">
understand how the block interval impacts the stability and =
capability<br class=3D"">
of the cryptocurrency network, and I came up with the idea of the =
DECOR+<br class=3D"">
protocol [4] (which requires changes in the consensus code). In my<br =
class=3D"">
research I also showed how the stale rate can be easily reduced only<br =
class=3D"">
with changes in the networking code, and not in the consensus code.<br =
class=3D"">
These networking optimizations ( O(1) propagation using headers-first =
or<br class=3D"">
IBLTs), can be added later.<br class=3D"">
&nbsp;<br class=3D"">
Mortifying Bitcoin to accommodate the change to lower the block rate<br =
class=3D"">
requires at least:<br class=3D"">
&nbsp;<br class=3D"">
- Changing the 21 BTC reward per block to 2.1 BTC<br class=3D"">
- Changing the nPowTargetTimespan constant<br class=3D"">
- Writing code to hard-fork automatically when the majority of miners<br =
class=3D"">
have upgraded.<br class=3D"">
- Allow transaction version 3, and interpret nLockTimes of =
transaction<br class=3D"">
version 2 as being multiplied by 10.<br class=3D"">
<br class=3D"">
All changes comprises no more than 15 lines of code. This is much =
less<br class=3D"">
than the number of lines modified by Gavin's 20Mb patch.<br class=3D"">
&nbsp;<br class=3D"">
As a conclusion, I haven't yet heard a good argument against lowering<br =
class=3D"">
the block rate.<br class=3D"">
<br class=3D"">
Best regards,<br class=3D"">
&nbsp;Sergio.<br class=3D"">
&nbsp;<br class=3D"">
[0] <a =
href=3D"https://medium.com/@octskyward/the-capacity-cliff-586d1bf7715e" =
class=3D"">https://medium.com/@octskyward/the-capacity-cliff-586d1bf7715e<=
/a><br class=3D"">
[1] <a =
href=3D"https://bitslog.wordpress.com/2014/02/17/5-sec-block-interval/" =
class=3D"">https://bitslog.wordpress.com/2014/02/17/5-sec-block-interval/<=
/a><br class=3D"">
[2] <a href=3D"http://gavinandresen.ninja/time-to-roll-out-bigger-blocks" =
class=3D"">http://gavinandresen.ninja/time-to-roll-out-bigger-blocks</a><b=
r class=3D"">
[3]<br class=3D"">
<a =
href=3D"http://www.cisco.com/c/en/us/solutions/collateral/service-provider=
/visual-networking-index-vni/white_paper_c11-520862.html" =
class=3D"">http://www.cisco.com/c/en/us/solutions/collateral/service-provi=
der/visual-networking-index-vni/white_paper_c11-520862.html</a><br =
class=3D"">
[4] <a href=3D"https://bitslog.wordpress.com/2014/05/02/decor/" =
class=3D"">https://bitslog.wordpress.com/2014/05/02/decor/</a><br =
class=3D"">
<br class=3D"">
=
--------------------------------------------------------------------------=
----<br class=3D"">
One dashboard for servers and applications across Physical-Virtual-Cloud =
<br class=3D"">
Widest out-of-the-box monitoring support with 50+ applications<br =
class=3D"">
Performance metrics, stats and reports that give you Actionable =
Insights<br class=3D"">
Deep dive visibility with transaction tracing using APM Insight.<br =
class=3D"">
<a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" =
class=3D"">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br =
class=3D"">
_______________________________________________<br class=3D"">
Bitcoin-development mailing list<br class=3D"">
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" =
class=3D"">Bitcoin-development@lists.sourceforge.net</a><br class=3D"">
<a =
href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development" =
class=3D"">https://lists.sourceforge.net/lists/listinfo/bitcoin-developmen=
t</a><br class=3D"">
</div>
</div>
</div>

=
--------------------------------------------------------------------------=
----<br class=3D"">One dashboard for servers and applications across =
Physical-Virtual-Cloud <br class=3D"">Widest out-of-the-box monitoring =
support with 50+ applications<br class=3D"">Performance metrics, stats =
and reports that give you Actionable Insights<br class=3D"">Deep dive =
visibility with transaction tracing using APM Insight.<br class=3D""><a =
href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___________=
____________________________________" =
class=3D"">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y________=
_______________________________________</a><br =
class=3D"">Bitcoin-development mailing list<br =
class=3D"">Bitcoin-development@lists.sourceforge.net<br =
class=3D"">https://lists.sourceforge.net/lists/listinfo/bitcoin-developmen=
t<br class=3D""></div></blockquote></div><br class=3D""></body></html>=

--Apple-Mail=_ACE953B9-3758-4DA2-AAA3-021039D5B024--